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 _______________________________________________ mesa-dev mailing list [email protected] https://lists.freedesktop.org/mailman/listinfo/mesa-dev
