[Mesa-dev] [PATCH 2/2] implement NV_vdpau_interop v3

Christian König deathsimple at vodafone.de
Sat Oct 26 16:26:24 CEST 2013

Merged the fixes and pushed the result this morning.

Thanks for the help,

Am 26.10.2013 01:25, schrieb Marek Olšák:
> On Sun, Oct 20, 2013 at 11:57 AM, Christian König
> <deathsimple at vodafone.de> wrote:
>> Hi Marek,
>> I've just send out a v6 of the patch, please take a second look. Most things
>> are fixed now, but there are still a couple of open issues:
>>> 3) There should also probably be some checking for
>>> GL_ARB_texture_non_power_of_two, but the spec doesn't say what we
>>> should do (probably return GL_INVALID_OPERATION).
>> Actually I thing VDPAU hold the answer to this. The specification there
>> states that the different surfaces creation function should round up the
>> width/height to supported values (which can then be queried later by the
>> application). So we always will end up with correct values independent of
>> GL_ARB_texture_non_power_of_two.
>>> 6) Registered and mapped VDPAU textures are not allowed to be
>>> re-specified by TexImage, TexSubImage, TexImage*Multisample,
>>> CopyTexImage, CopyTexSubImage, TexStorage, TexStorage*Multisample, and
>>> similar functions. This should be properly handled in those functions
>>> and GL errors should be returned.
>> I would rather like to avoid touching those functions, cause they are not
>> directly related to the spec and I don't want to risk breaking anything
>> there.
>> Would it valid so set/clear the immutable flag instead (honestly I don't
>> have the slightest idea how the frontend handling works in this code)?
> Yes, it seems to be sufficient.
>>> 7) The extension spec says that all VDPAU textures should be
>>> y-inverted. Is that actually the case here?
>> Uhm, no idea? It does seems to work, but where is that information stored?
> It means that a VDPAU surface is upside-down when it's used as an
> OpenGL texture. I don't remember whether we need to a blit or whether
> OpenGL textures are y-inverted by default (then we don't have to do
> anything). If we do the same thing as NVIDIA, it's probably okay.
> Please review and squash the attached patch with your version 6, and
> feel free to push it.
> Marek

More information about the mesa-dev mailing list