[Mesa-dev] All-black X windows on glamor with etnaviv

Michel Dänzer michel at daenzer.net
Thu Jul 4 09:50:38 UTC 2019


On 2019-07-04 5:28 a.m., Jiaxun Yang wrote:
> Hi folks,
> 
> We had some reports that glamor is not working correctly with etnaviv
> mesa driver for long time. Previously Lukas Hartmann wad proposed a
> patch [1] replacing linear rendering buffer with a tiled buffer and it
> do works but giving scrambled output. We just dig the issue deeper and
> managed to let it give out a normal output.
> 
> Since Vivante hardware doesn't actually support tiled surface/texture,
> once the driver accpet a imported buffer or called to create a resource,
> it will make a shadow tiled buffer, and convert the content in tiled
> buffer to the content it linear buffer when  etna_flush_resource in
> mesa/src/gallium/drivers/etnaviv/etnaviv_clear_blit.c is called.
> However, it was never been called with glamor. By contrast other
> applications like kmscube or weston using EGL GLES have correct behavior.
> 
> Our solution is just flush the buffer everytime , it's not a elegant
> way, but it works. Since GC1000 is only giving OpenGL 1.4 rather than
> 2.1 as minimal requirement of glamor. We also have to force glamor work
> with GLES.
> 
> Any idea if we can solve this issue correctly?

I suspect etna_resource_get_handle needs to check for
PIPE_HANDLE_USAGE_EXPLICIT_FLUSH. If it's not set, the caller will not
call the flush_resource hook for this resource. This needs to be
recorded in struct etna_resource. Then in etna_flush, if this was
recorded for the resource backing any of the cbufs in the current
pipe_framebuffer_state, etna_flush_resource needs to be called for that
resource.

It might be possible to optimize this somewhat, e.g. maybe etna_flush
only needs to do this when it's called with certain PIPE_FLUSH_* flags
(not) set corresponding to glFlush, but not for other internal flushes.


-- 
Earthling Michel Dänzer               |              https://www.amd.com
Libre software enthusiast             |             Mesa and X developer


More information about the xorg-devel mailing list