[virglrenderer-devel] regarding ARGB_copy_image and 3 component textures

Gert Wollny gert.wollny at collabora.com
Tue Jul 10 13:16:45 UTC 2018


Am Dienstag, den 10.07.2018, 12:37 +0200 schrieb Gert Wollny:
> 
> I was wrong, I just realized that arb_copy_image-formats was not part
> of my test-set and it still fails because it allocates one texture as
> four component and the other as three component. 

I found the issue in Gallium: When allocating a texture with GL_RGB32F
(and other formats) it tries to optimize by trying to allocate a
texture with the render target flag enabled, and since this format is
not supported as render target on Intel(*), Gallium picks RGBA32F. For
the integer formats Gallium doesn't do this guessing ahead, and
therefore, the texture is allocated as requested.

I'll send an RFC to mesa to disable this kind of optimization for
virgl, although I'm afraid that this is only part of the equation. On
one hand the piglits arb_copy_image-formats still hits the assertion
with a RGB 8 bit format (when I replace these with RGBX it doesn't
crash anymore), and on the other hand and the tests involving RGB32*
included in this piglit still fail.

best, 
Gert 

(*) This is a bit surprising, because the Intel driver advertises
OpenGL 4.5 and the standard says that RGB32* should be color
renderable. 




More information about the virglrenderer-devel mailing list