[Mesa-dev] vdpau_interop extension oddities

[Thomas Hellstrom]

Hi, Christian!

Thanks for your reply. I'll look through the code again!

/Thomas


On 02/01/2017 04:22 PM, Christian König wrote:
> 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
>>
>>
>>
>>
>>