[Mesa-dev] vdpau_interop extension oddities

Christian K├Ânig deathsimple at vodafone.de
Wed Feb 1 15:22:48 UTC 2017


Hi Thomas,

I'm on sick leave, but will try to quickly answer your questions.

But don't be disappointed if you don't hear back from me before Monday.

Am 01.02.2017 um 15:56 schrieb Thomas Hellstrom:
> Hi, Christian,
>
> I'm looking through the mesa vdpau interop code and found something that
> looks strange to me:
>
> (dmabuf part)
>
> For video surfaces, it looks like vdpau exports a handle to a 2D_ARRAY
> texture.
> Later in the mesa state tracker, that handle is used to back a "fake"
> single slice 2D texture from which we create views like if it were an
> array texture, using the layer_override. I guess this would cause
> numerous problems when trying to render to these textures or using
> texSubImage etc.

Hui? That's not how I remembered it.

For the dma-buf part we export one layer of a 2D_ARRAY texture and then 
import that as "normal" 2D texture.

The layer_override is only for the old code path used by Nouveau, e.g. 
exporting the pipe objects directly and then access only a certain layer.

> Wouldn't the correct solution be to have vdpau export a single layer of
> the array texture (using the whandle offset pointing to the layer start)
> which is then reinterpreted by the driver, not the state tracker, as a
> true non-array texture.

Actually that is exactly as it should be, yes.

> And if for some reason the driver doesn't support reinterpreting and
> offseting like this wouldn't it be possible to hide the layer_override
> inside the driver for surface, sampler_view and transfer object
> purposes, as part of the texture internal format?

As noted above the layer_override should only be used for the old code path.

Could be that we accidentally set layer_override in the new code path as 
well, but that would clearly be a bug.

Regards,
Christian.

>
> Thanks,
>
> Thomas
>
>
>
>
>



More information about the mesa-dev mailing list