[virglrenderer-devel] [PATCH 2/3] vrend: If available use glCopyImageSubData to execute memcopy like blits

[Gert Wollny]

Am Dienstag, den 26.06.2018, 09:27 -0700 schrieb Gurchetan Singh:
...
> > I have to admid, I kind of ignored this, but now that you point it
> > out: the reason why I came up with using glCopyImageSubData is
> > because that's what is actually used by the tests I'm trying to fix
> > with these patches, and these are from the GLES31 set. So if
> > glCopyImageSubData is not available on the host, one can not expect
> > these tests to pass, right?  In any case, does the hardware you're
> > using not expose one of the *_copy_image extensions?
> 
> I found this relevant snippet in es31fCopyImageTests.cpp:
> 
>         if (!isES32 && !ctxInfo-
> >isExtensionSupported("GL_EXT_copy_image"))
>                 throw tcu::NotSupportedError("Extension
> GL_EXT_copy_image not supported.", "", __FILE__, __LINE__);
> 
> Does the guest advertise glCopyImageSubData when we shouldn't?  

When I run Qemu with 

  MESA_EXTENSION_OVERRIDE=-GL_ARB_copy_image 

then GL_*_copy_image is not advertised  in the guest (as it should be),
so having a code path in the host that uses this extenstion when
evailable shouldn't pose a problem, we only have to make sure that the
there are no regressions with the old code path. 

In any case, this makes me wonder why these tests are in the GLES31 set

Best, 
Gert