[Mesa-dev] vdpau_interop extension oddities
thomas at shipmail.org
Wed Feb 1 15:39:37 UTC 2017
Thanks for your reply. I'll look through the code again!
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
>> 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
> Could be that we accidentally set layer_override in the new code path
> as well, but that would clearly be a bug.
More information about the mesa-dev