[Mesa-dev] [PATCH 3/3] etnaviv: Check extended format availability on GPU

Philipp Zabel p.zabel at pengutronix.de
Tue May 16 14:33:34 UTC 2017


Hi Wladimir,

On Tue, 2017-05-16 at 10:42 +0200, Wladimir J. van der Laan wrote:
> Current information shows that both extended texture/render formats
> and texture swizzling were introduced with the HALTI0 feature bit,
> available on GC2000/GC3000.

With this patch applied, trying to import R8_UNORM dma-buffers via
EGLImage results in an endless recursion:

etna_copy_resource -> etna_blit -> util_try_blit_via_copy_region ->
util_resource_copy_region -> etna_transfer_map -> etna_copy_resource ->
etna_blit -> ...

I think the problem is that etna_blit fails to blit via RS because of
missing compatible RS formats and falls through to call
util_blitter_blit, which in turn tries to map the resource to blit into
it in software using etna_transfer_map, which uses etna_copy_resource to
create a transfer copy, which calls etna_blit, and so on ...
I'm not exactly sure where the loop should be broken if the RS doesn't
support copying the format at all.

Is there any single-byte pixel format that could be returned from
etna_compatible_rs_format for PIPE_FORMAT_R8_UNORM ?

The only thing that looks remotely related is RS_FORMAT_R8I, but that is
marked as extended format in rnndb and doesn't fit into
RS_CONFIG_SOURCE/DEST_FORMAT. Is it even possible to tile R8/A8/L8
textures in hardware?

regards
Philipp



More information about the mesa-dev mailing list