Screen sometimes flickring

dragonation commented 3 years ago

Some builtin games will flickring, such as blockattack. And in gmenu2x, after pressed [power + vol_up] and [power + vol_down], sometimes the left top corner and right top corner of screen will flickring, too. Version: master branch at 2020-10-13, commit 99dcecba965ef742566858ebdad4f9cff67b8181 Device: RG350M Host Environment: Docker[debian:buster-slim] Building:

make rg350m_defconfig BR2_EXTERNAL=board/opendingux:opks

glebm commented 3 years ago

Yeah, this is the main issue preventing a release.

Here are the results of previous investigation:

Happens on all SDL2 applications.
Happens only when userland is built with GCC >= 5.
Upgrading SDL2 doesn't fix the flicker (tried in the old upd-sdl branch).
rRootage doesn't flicker, despite using OpenGL heavily (doesn't use SDL2)!

dragonation commented 3 years ago

Yeah, this is the main issue preventing a release.

Here are the results of previous investigation:

Happens on all SDL2 applications.

Happens only when userland is built with GCC >= 5.

Upgrading SDL2 doesn't fix the flicker (tried in the old upd-sdl branch).

rRootage doesn't flicker, despite using OpenGL heavily (doesn't use SDL2)!

I see, it means that, some optimization of gcc may cause the strange behavior in SDL2, may be driver. Another guess, may be some codes of double buffer flipping is broken or disabled via flags check after compiler updated?

glebm commented 3 years ago

Yeah, all of these are possible, help is welcome :)

dragonation commented 3 years ago

Yeah, all of these are possible, help is welcome :)

I am planning to make a very simple test for sdl2 later, but still struggling with sparrow3d, failed to make that package with the latest commit

dragonation commented 3 years ago

I have written a very small example(82 lines of c code) to trace how the SDL2 make the screen flickering. The code is quite simple, just copied from official site, with a little changes to add animation to tell us that the app is running well. I will try to dig into SDL2 codes to find why it happened.

By the way, gmenu2x is based on SDL, not SDL2. and it seldom flickering at the two top corner of the screen, which may implies that it may be a driver issue, or OpenGL issue?

The compiled test-sdl2.opk, and source codes is attached after

test-sdl2.zip

What's more, the tester app only play animation, accept no inputs. So reset the device if you want to quit...

glebm commented 3 years ago

Power + Select force quits any app

dragonation commented 3 years ago

Power + Select force quits any app

Ok, now I learnt it, good.

It is just the second day, I got the device, and started to engage such a project combined with linux kernel, build root for cross compiling and a monster with so many merged git... There are a lot of thing I needed to study and research, programming is a funny job.

dragonation commented 3 years ago

Just some info from the SDL2 code:

we haven't installed opengles, and opengles2, because we disabled mesa3d
according to the code, it seems software renderer has no double buffer supports. calloc memory with only 1x size, not 2x

glebm commented 3 years ago

we haven't installed opengles, and opengles2, because we disabled mesa3d

Great! mesa3d should be enabled, we have BR2_PACKAGE_MESA3D_ETNA_VIV=y, strange

dragonation commented 3 years ago

we haven't installed opengles, and opengles2, because we disabled mesa3d

Great! mesa3d should be enabled, we have BR2_PACKAGE_MESA3D_ETNA_VIV=y, strange

Yes, very strange. the entire video building and calling chain is very strange, hard to trace.

mesa3d is disabled, but enta_viv is enabled
according to sdl2.mk, some macro will be undefined if opengles or egl not available
the implementation of fbvideo.c in sdl2 enforced to use opengles to render framebuffer, and it seems works but flickering
sdl seems do not touch any parts of opengles, maybe this is the difference part why sdl2 flickering
the flickering is caused by hardware or driver issue, i think. after long time flickering, the four corners of the screen will dim. and if you enter any ui using sdl, not sdl2. the four corners will be keep flickering for a few minutes, even power off and restart the device again
i have tried each of opengles, opengles2, and software renderer driver combined with fbdev video driver in sdl2, no one could ignore the flickering. so the bug is caused by fbdev or layers below. but fbdev is based on egl context, not direct framebuffer. i am thinking about using directfb instead of fbdev as video driver
so the flickering happens at the moment of swapping two egl context, i guess. maybe we need to check the code of mesa or etna_viv?

glebm commented 3 years ago

Why do you think that mesa3d is disabled? Note that we're using a fork of mesa3d (mesa3d-etna_viv).

dragonation commented 3 years ago

Why do you think that mesa3d is disabled? Note that we're using a fork of mesa3d (mesa3d-etna_viv).

Ok, maybe my mistake. I need to do a clean build and check again later

I traced the software video driver calling chain as below, which has the lowest flickerings: -> SDL_RenderPresent(renderer): which caused flickering, even no other api calls -> renderer->RenderPresent(renderer) ---> SW_RenderPresent(renderer) -> SDL_UpdateWindowSurface(window) -> SDL_UpdateWindowSurfaceRects(window, rect, 1) -> renderer->UpdateWindowFramebuffer(renderer, window, rects, 1) ---> SDL_UpdateWindowTexture -> SDL_RenderPresent(renderer) ---> GLES2_RenderPresent(renderer) -> SDL_GL_SwapWindow(window) -> device->GL_SwapWindow(device, window) ---> FB_GLES_SwapWindow -> SDL_EGL_SwapBuffers(device, egl_surface) -> egl_data->eglSwapBuffers(egl_display, egl_surface) --> eglSwapBuffers @ libEGL.so.1

OpenGLES 2 calling chain (after 10 frames to make buffer not empty, only SDL_RenderPresent called in a dead loop, still keep flickering) -> SDL_RenderPresent(renderer) -> renderer->RenderPresent(renderer) ---> GLES2_RenderPresent(renderer) -> SDL_GL_SwapWindow(window) -> device->GL_SwapWindow(device, window) ---> FB_GLES_SwapWindow -> SDL_EGL_SwapBuffers(device, egl_surface) -> egl_data->eglSwapBuffers(egl_display, egl_surface) --> eglSwapBuffers @ libEGL.so.1

it seems, eglSwapBuffers caused the flickering? I will dig deeper into mesa-etna_viv

dragonation commented 3 years ago

Why do you think that mesa3d is disabled? Note that we're using a fork of mesa3d (mesa3d-etna_viv).

You are right. the fork is in the board/opendingux, and I missed that before.

I think the issue is caused by mesa's code or below.

What's more, I noticed a new issue. At noon, I placed the handheld facing down, with only gmenu2x open. after about an hour back to office, the gmenu2x's screen flickering too. It seems like current pulse caused resonance, for example, some resets repeats in a very small interval. maybe the eglSwapBuffers just did something like this

dragonation commented 3 years ago

I checked the code of sdl, and the mentioned game rRootage. Neither of them used egl to createSurface or context. So, to my opinion, egl part from mesa has something caused the bug.

glebm commented 3 years ago

Output with EGL_LOG_LEVEL=debug:

$ EGL_LOG_LEVEL=debug opkrun /media/data/apps/blockattack.opk 
libEGL debug: Native platform type: fbdev (build-time configuration)
libEGL debug: EGL search path is /usr/lib/egl
libEGL debug: added /usr/lib/egl/egl_gallium.so to module array
libEGL debug: added egl_dri2 to module array
libEGL debug: dlopen(/usr/lib/egl/egl_gallium.so)
libEGL info: use FBDEV for display (nil)
fbdev_display succesful
Kernel: Vivante GPL kernel driver 4.6.6.1381
Physical address of internal memory: 00000000
* Video memory:
  Internal physical: 0x00000000
  Internal size: 0x00000000
  External physical: 00000000
  External size: 0x00000000
  Contiguous physical: 0x8c7f1800
  Contiguous size: 0x00400000
Succesfully opened device
libEGL info: created a pipe screen for etna
libEGL debug: the best driver is Gallium
native_fbdev: 2 buffers of 640x480
Framebuffer format: 6, flip_rb=0
Framebuffer format: 6, flip_rb=0

dragonation commented 3 years ago

I found that, sdl will call ioctl(FBIOPUT_VSCREENINFO) at least once to ensure framebuffer has correct xres_virtual and yres_virtual and other configs for framebuffer screeninfo.

But mesa never did this, the only one comment is as below in native_fbdev.c:

/* Pan framebuffer in y direction.
 * Android uses FBIOPUT_VSCREENINFO for this; however on some hardware this does a
 * reconfiguration of the DC every time it is called which causes flicker and slowness.
 * On the other hand, FBIOPAN_DISPLAY causes a smooth scroll on some hardware,
 * according to the Android rationale. Choose the least of both evils.
 */

So, i guess that mesa doesn't correct the framebuffer screen info, maybe. laterly, i will have a try to verify this point.

dragonation commented 3 years ago

what's more, i found a comment in sdl

 // The GCW Zero kernel waits for vsync as part of the pan ioctl.

i don't know how the mesa care about this, i will check it later

dragonation commented 3 years ago

New progress:

It seems, the screen flickering happens at the function below in mesa3d


boolean
resource_surface_present(struct resource_surface *rsurf,
                         enum native_attachment which,
                         void *winsys_drawable_handle)
{
   struct pipe_resource *pres = rsurf->resources[which];

   if (!pres)
      return TRUE;

   rsurf->screen->flush_frontbuffer(rsurf->screen,
         pres, 0, 0, winsys_drawable_handle);

   return TRUE;
}

dragonation commented 3 years ago

More deep than we think, but it match the situation why upgrading gcc cause the flickering. Code in mesa3d as below caused the bug:


    /* Kick off RS here */
    struct compiled_rs_state copy_to_screen;
    etna_compile_rs_state(ctx, &copy_to_screen, &(struct rs_state){
                .source_format = translate_rt_format(rt_resource->base.format, false),
                .source_tiling = rt_resource->layout,
                .source_addr[0] = rt_resource->pipe_addr[0],
                .source_addr[1] =  rt_resource->pipe_addr[1],
                .source_stride = rt_resource->levels[level].stride,
                .dest_format = drawable->rs_format,
                .dest_tiling = ETNA_LAYOUT_LINEAR,
                .dest_addr[0] = etna_bo_gpu_address(drawable->bo),
                .dest_stride = drawable->stride,
                .downsample_x = msaa_xscale > 1,
                .downsample_y = msaa_yscale > 1,
                .swap_rb = drawable->swap_rb,
                .dither = {0xffffffff, 0xffffffff}, // XXX dither when going from 24 to 16 bit?
                .clear_mode = VIVS_RS_CLEAR_CONTROL_MODE_DISABLED,
                .width = drawable->width * msaa_xscale,
                .height = drawable->height * msaa_yscale
            });
    etna_submit_rs_state(ctx, &copy_to_screen);

The etna_submit_rs_state and etna_compile_rs_state is from enta_viv package.

Project Etnaviv is an open source user-space driver for the Vivante GCxxx series of embedded GPUs.

glebm commented 3 years ago

Interesting, how did you find that this function is responsible for flickering?

&(struct rs_state) {
  ...
}

Is that passing the address of a temporary? That's undefined behaviour.

By the way, here is a PR that upgrades the versions of both mesa and etna a bit but it doesn't fix the flicker https://github.com/od-contrib/buildroot-rg350-old-kernel/pull/15

dragonation commented 3 years ago

Interesting, how did you find that this function is responsible for flickering?
&(struct rs_state) {
  ...
}
Is that passing the address of a temporary? That's undefined behaviour.

By the way, here is a PR that upgrades the versions of both mesa and etna a bit but it doesn't fix the flicker #15

Firstly, I wrote a simple test-sdl2 app, it just render 10 frames, and after 10 frames, just keep calling SDL_RenderPresent() in a dead loop, but the screen keep flickering after 10 frames. So it means that the SDL_RenderPresent() api will cause flickering. There must be somehing wrong which make it happen at least.

Secondly, I traced into sdl2, mesa3d, egl. Until the api call resource_surface_present() as above. Here, I did another thing to make the tracing more convenient. Because low level api has been called too many times, and some essential call is need to prepare correct buffer and other things. So I start a counter to count api call of etna_screen_flush_frontbuffer(), which is rsurf->screen->flush_frontbuffer() in the resource_surface_present(), just keep first 10 call normally, but the rest ignored. and the flickering disappeared. So it means that etna_screen_flush_frontbuffer() has something related to flickering.

Digging more deeply, until I find that the two api call in user-land enta_viv package will cause the flickering. What's more, I search all the code of buildroot, and its related packages, only the mesa3d has the api calls. As a result, only mesa3d apps will have flickering, and only sdl2 games will have flickering...

By the way, the enta_viv package is a user-land driver, and usually a driver is sensitive to the version of gcc, libc, and kernel, for any strange bitwise usage, syscall() logic, or any struct layout align difference. And it explained why sometimes, even gmenu2x will have screen flickering, or anything like hardware issues.

Maybe we need more time to review every line of the driver part to ensure no more issues are introduced by the upgrade of gcc. Currenly, I haven't any idea about how to deal with the part of driver. I am not good at hardware and driver, perhaps I will search for a chip spec?

dragonation commented 3 years ago

What's more, I found that, entaviv user-land driver has been implemented directly in the mesa3d after 2017. and some port of RG350M kernel has enabled DRM, which may change the driver part of mesa3d, may be can make a walkaround.

I am reading the code of latest mesa3d, finding any useful info about the driver part

dragonation commented 3 years ago

Or, can we directly use the latest mesa3d code, and drop the enta_viv and mesa-enta_viv?

dragonation commented 3 years ago

While reading the code history and codes of lib etnaviv, I noticed the text below

etnaviv library is no longer necessary. Use DRM upstream, it includes functionality for sending command buffers to Vivante hardware using the DRM Linux kernel driver (also upstream). If you really need a shim to access the Vivante kernel driver use the dedicated repository: https://github.com/etnaviv/libetnaviv

And the mesa readme on entaviv

The etnaviv MESA driver has been merged upstream: https://cgit.freedesktop.org/mesa/mesa/

This repository, and its branches, exists for historical purposes only.

glebm commented 3 years ago

Amazing investigation!

Or, can we directly use the latest mesa3d code, and drop the enta_viv and mesa-enta_viv?

I looked into using the latest mesa3d with DRM but the issue is backporting the etnaviv DRM kernel driver. The DRM version in the old kernel is so different, it'd be difficult to backport. It might even be easier to backport linkdev to the new kernel and just use the new kernel.

glebm commented 3 years ago

Patching the address-of-temporary issue did not fix flicker (https://github.com/od-contrib/buildroot-rg350-old-kernel/pull/15/commits/28836f133d07baa7688adce7c5efe1c5ed916507)

glebm commented 3 years ago

By the way, the new kernel with RG350m device tree can be found here: https://github.com/OpenDingux/linux/tree/jz-5.9

glebm commented 3 years ago

This is the thing in the old kernel that handles input devices:

If you can port this to the new kernel we can probably just switch to it. The alternative is adding support for input device merging into SDL2 itself (this is the plan for upstream OpenDingux).

dragonation commented 3 years ago

This is the thing in the old kernel that handles input devices:

https://github.com/tonyjih/RG350_linux/blob/master/include/linux/platform_data/linkdev.h

https://github.com/tonyjih/RG350_linux/blob/master/drivers/input/linkdev.c

https://github.com/tonyjih/RG350_linux/blob/e1448818b3f630fbac72c10ae843213d4eb89c87/arch/mips/jz4770/board-gcw0.c#L697

If you can port this to the new kernel we can probably just switch to it. The alternative is adding support for input device merging into SDL2 itself (this is the plan for upstream OpenDingux).

So, the situation is:

Kernel 5.9 already supported RG350M
Input part is different with the old kernel

The solution could be one of these two:

reimplement the old input into new kernel, makes sdl2 no change
modify the sdl2 to accept inputs from new kernel

Am I right?

dragonation commented 3 years ago

I reviewed the difference between gcc 4 and gcc 5. I noticed that if we want to use gcc 4, we need to check BR2_MIPS_FP32_MODE_32. So maybe the real difference is something related to soft float and hard float in compiled driver?

And I found the code below:

#define SET_STATE(addr, value) cs->addr = (value)
#define SET_STATE_FIXP(addr, value) cs->addr = (value)
#define SET_STATE_F32(addr, value) cs->addr = f32_to_u32(value)
void etna_compile_rs_state(struct etna_ctx *restrict ctx, struct compiled_rs_state *cs, const struct rs_state *rs)

But there is no code using SET_STATE_F32()

dragonation commented 3 years ago

Reading the release changes of GCC 5.

The o32 ABI has been modified and extended. The o32 64-bit floating-point register support is now obsolete and has been removed. It has been replaced by three ABI extensions FPXX, FP64A, and FP64. The meaning of the -mfp64 command-line option has changed. It is now used to enable the FP64A and FP64 ABI extensions.

The FPXX extension requires that code generated to access double-precision values use even-numbered registers. Code that adheres to this extension is link-compatible with all other o32 double-precision ABI variants and will execute correctly in all hardware FPU modes. The command-line options -mabi=32 -mfpxx can be used to enable this extension. MIPS II is the minimum processor required.
The o32 FP64A extension requires that floating-point registers be 64-bit and odd-numbered single-precision registers are not allowed. Code that adheres to the o32 FP64A variant is link-compatible with all other o32 double-precision ABI variants. The command-line options -mabi=32 -mfp64 -mno-odd-spreg can be used to enable this extension. MIPS32R2 is the minimum processor required.
The o32 FP64 extension also requires that floating-point registers be 64-bit, but permits the use of single-precision registers. Code that adheres to the o32 FP64 variant is link-compatible with o32 FPXX and o32 FP64A variants only, i.e. it is not compatible with the original o32 double-precision ABI. The command-line options -mabi=32 -mfp64 -modd-spreg can be used to enable this extension. MIPS32R2 is the minimum processor required.

The new ABI variants can be enabled by default using the configure time options --with-fp-32=[32|xx|64] and --with(out)-odd-sp-reg-32. It is strongly recommended that all vendors begin to set o32 FPXX as the default ABI. This will be required to run the generated code on MIPSR5 cores in conjunction with future MIPS SIMD (MSA) code and MIPSR6 cores.

I will have a try to adjust floating point mode of gcc, to check if it works

glebm commented 3 years ago

The solution could be one of these two:

That's exactly right!

I will have a try to adjust floating point mode of gcc, to check if it works

Ah, I remember that I had to backport some floating point mode stuff in the old kernel to make it work when compiled with newer binutils (https://github.com/tonyjih/RG350_linux/pull/6). Sounds like you're on the right track!

dragonation commented 3 years ago

Well, I have tried almost every kind of methods to resolve the bug directly (no touching on kernel), but no more progress gained.

Currently, I just confirmed the information as below:

The screen flickering at the moment etna_flush(), which consumes the GPU commands into GPU registers, only the RS_CONFIG and the 4 more registers(RS_SOURCE_ADDR, RS_SOURCE_STRIDE, RS_DEST_ADDR, RS_DEST_STRIDE) after it will makes the flickering. The 5 registers must be refreshed together the make the GPU works, otherwise it will hang
I have read the manual and spec of Vivante GC860, but nothing is incorrect implemented as far as I can see
I have dumped the command we push into GPU, all runtime data and encoding is correct according the the spec and manual I got
I have dumped the viv_conn to ensure chip information from kernel is correct, and there is nothing strange
I have traced the initialization of etna_pipe_screen, and viv_conn, no error reported, nothing seems strange, either
I have made the floating point register layout correct, the same as kernel, fp32.
I have enabled the hard floating point support in mipsel on both kernel and userland (JZ4770 support hard floating point, I noticed).

However, after 6 and 7, the performance is optimized, to my opinion. And SDL is more stable than it was before. At least, SDL never flickers again, while SDL2 never stops flickering.

What's more, I remember that the GC860 support 800x480 at most (may be 480x800). However, our screen is 640x480, is it possible that we need to rotate the screen to ensure all pixels inside the range? However, I reduced the size twice, and GPU hang at last... I don't know whether it may be a new point to be checked again. Or anyone else can tell me whether the screen flickering in RG350 (Not M, which all dimensions are below 480, impossible to overflow)?

I decided to try on the new kernel... although, I am not familiar with the kernel building, and bootloader part. the procedure of making an image of this repo seems heavily modified to the OpenDingux one.

glebm commented 3 years ago

Thanks, can you please send a PR with 6 and 7? It seems like a step in the right direction. I wonder if other FP modes can fix this (if changed both here and in the kernel).

This repo is built a bit differently from upstream OpenDingux: The kernel is compiled with a separate buildroot config, because we want to compile the userland with the latest GCC but the kernel is stuck on older GCC.

To update the kernel, this config needs to be changed: https://github.com/od-contrib/buildroot-rg350-old-kernel/blob/master/configs/rg350m_kernel_only_defconfig

This version of the new kernel has the rg350m devicetree. There are still some minor issues with the RG350m panel driver as well in the new kernel. https://github.com/OpenDingux/linux/archive/f17121199d35a0c81a59253f55841373e59697a6.tar.gz

The upstream Linux defconfig is in the buildroot repo instead of the kernel repo: https://github.com/OpenDingux/buildroot/blob/opendingux/board/opendingux/gcw0/linux_defconfig

devicetree must be configured in the buildroot kernel config, e.g. like this:

BR2_LINUX_KERNEL_DTS_SUPPORT=y
BR2_LINUX_KERNEL_INTREE_DTS_NAME="ingenic/rg350 ingenic/rg350m"

The kernel here is built as part of make_initial_image.sh (unless a built kerenel is already present on-disk):

https://github.com/od-contrib/buildroot-rg350-old-kernel/blob/8bcc9e1cadeae6f1e1a2d202951b296f846b34e5/board/opendingux/gcw0/make_initial_image.sh#L18-L26

dragonation commented 3 years ago

I am reading the code of uclibc, for the libc api ioctl.

I don't know whether it is ok in all situations while we upgrade the userland gcc from 4 to 10. especially, the va_start(), va_arg() and va_end() macros to deal with the variable argument list.

dragonation commented 3 years ago

Just tried compile kernel 3.12 with GCC 10, compiled, but hang while starting up.

I wil make a PR for enforce hardware floating point and 32bit float register align later.

glebm commented 3 years ago

When I tried compiling the kernel with newer GCC: GCC 5 works but GCC 6+ hangs on boot (black screen).

glebm commented 3 years ago

I'm trying with GCC5 for the kernel, and BR2_MIPS_FP32_MODE_XX for both, and some kernel config flags from upstream OpenDingux (https://github.com/glebm/RG350_linux/commit/6a5e05edb386bd137e1692287dde3b0bac7c4bff)

glebm commented 3 years ago

That did not fix the flickering

dragonation commented 3 years ago

My last try to upgrading to kernel 5.9 is broken by some scripting error, which deleted all my codes and local git history...

I tried the opendingux build, found that it only support opengles with sdl2, no supports on opengles2 (which may just clear the background, nothing else done). And its gmenu2x will make screen tears while start opks. haven't touched the input part.

glebm commented 3 years ago

I've cleaned up the build scripts somewhat, so now the easy way to rebuild the kernel is:

rm -rf output-kernel-rg350m/build/linux-custom && \
  board/opendingux/gcw0/build_kernel.sh rg350m && \
  board/opendingux/gcw0/make_initial_image.sh rg350m

dragonation commented 3 years ago

I've cleaned up the build scripts somewhat, so now the easy way to rebuild the kernel is:
rm -rf output-kernel-rg350m/build/linux-custom && \
  board/opendingux/gcw0/build_kernel.sh rg350m && \
  board/opendingux/gcw0/make_initial_image.sh rg350m

No, no, it is not your fault. It was my mistake to directly use the post build script from opendingux, and changed the folder layout of the entire buildroot to make it clear to rg350m, but the result is unexpected, haha

I am adjusting the script of buildroot, make-initial-image.hs and od-imager to avoid deleting building file. You can try using make xxx_defconfig O=output_dir to make the config file in customized output dir, not the default output. and cd to the new output dir, execute make.

glebm commented 3 years ago

Yeah, this is what I've done in https://github.com/od-contrib/buildroot-rg350-old-kernel/commit/bbf5818463c9fa76a78e5543f57aa4fb30ca22df

dragonation commented 3 years ago

Back to the issue, I have a possible solution to resolve the issue directly:

Currently, the etna_viv use RG_CONFIG to flush the internal buffer into the offscreen buffer of framebuffer, and mesa3d use yoffset to flip the framebuffer to make it visible to user

According the official manual(Only GC320, not GC860) and some docs via reverse-engineering (from project etna_viv), The function of register RS_CONFIG is not clear, it seems like a blit, but not only a blit operation, it can also clear the region, convert pixel format, swap channels, and etc. The behavior of RS_CONFIG currently in the build seems like a pixel region overflowed, (but actually not, I've confirmed that with a little smaller region center in screen, no overflow in the test). I guess somewhere it makes a reset of some circuit units, flags or TFT panel. (I have tried to disable the yoffset flipping, but the flickering remains, so not the issue of framebuffer)

So, may be we directly use a blit operation instead of the RS_CONFIG maybe a walk around to make the flickering disappear. And I have checked the latest mesa3d's code in the opendingux build. It use kmsdrm driver, not fbdev one, which seems no call to RS_CONFIG register to flush the screen. And I will try to use the latest mesa3d with fbdev driver (which has combined the latest etna_viv userland driver internally) to see whether it solve the issue. If not, I will try directly use the blit engine of GPU to flush the screen later

glebm commented 3 years ago

And I will try to use the latest mesa3d with fbdev driver (which has combined the latest etna_viv userland driver internally)

Interesting, I thought the latest mesa didn't have an fbdev driver for etnaviv

glebm commented 3 years ago

Or anyone else can tell me whether the screen flickering in RG350 (Not M, which all dimensions are below 480, impossible to overflow)?

RG350 doesn't flicker (it never did). I have just confirmed this with the current master (https://github.com/od-contrib/buildroot-rg350-old-kernel/releases/tag/2020-11-02-rg350-beta).

dragonation commented 3 years ago

Or anyone else can tell me whether the screen flickering in RG350 (Not M, which all dimensions are below 480, impossible to overflow)?

RG350 doesn't flicker (it never did). I have just confirmed this with the current master (https://github.com/od-contrib/buildroot-rg350-old-kernel/releases/tag/2020-11-02-rg350-beta).

I remembered that I had read some refereences about GC860, or JZ4770, which told me that it only support 480x800 screen resolution. However, I cannot find the reference again. Maybe I need to check it again

dragonation commented 3 years ago

i found the data from the ds of jz4770, however, it seem not related to the issue, maximum sizes of alpha-osd is 800x480.

dragonation commented 3 years ago

Will it be an issue of NV3052C driver part in kernel?

od-contrib / buildroot-rg350-old-kernel

Screen sometimes flickring #11