[Mesa-stable] [Mesa-dev] [PATCH] st/vdpau: allow progressive video surface with interop

[Christian König]

Am 07.05.2018 um 15:03 schrieb Leo Liu:
>
>
> On 05/07/2018 05:10 AM, Christian König wrote:
>> Am 02.05.2018 um 16:51 schrieb Leo Liu:
>>> mpv now interop with video surface instead of output surface 
>>> previously,
>>> so it fails with "vlVdpVideoSurfaceDMABuf", this's fine for Mesa GL, 
>>> since
>>> the code path will fall back to "vlVdpVideoSurfaceGallium", but this's
>>> not the case for others
>>>
>>> Signed-off-by: Leo Liu <leo.liu at amd.com>
>>> Cc: Christian König <christian.koenig at amd.com>
>>> Cc: "18.1 18.0" <mesa-stable at lists.freedesktop.org>
>>
>> That won't work correctly.
>>
>> The NV_VDPAU_interop extension we implement with that needs 
>> interlaced layout or otherwise can't correctly work with the surfaces.
> I thought the same way in the beginning, then later I asked myself why 
> it's working with Mesa interop, then I found it resolved with:
>
> static struct pipe_resource *st_vdpau_video_surface_gallium(struct 
> gl_context *ctx, const void *vdpSurface,
> ...
>
>    samplers = buffer->get_sampler_view_planes(buffer);
>    if (!samplers)
>       return NULL;
>
>    sv = samplers[index >> 1];
>    if (!sv)
>       return NULL;
>
>    pipe_resource_reference(&res, sv->texture);
> }
>
> The above code gave me the hint for this patch, and the patch is 
> tested okay with Mesa GL and other GL.

That is just a hack I introduced for testing which also doesn't work 
correctly. E.g. it won't sample correctly from the odd/even fields and 
instead interpolate from the whole frame. In other words you get an more 
or less correct output with that, it's just not binary identical.

But for the DMA-buf interop case that won't work because the importer 
expects for surfaces with X height and not two with 2*X height. That you 
don't get a corrupted picture in your test properly pure coincident 
because of how we share the DMA-buf tilling data in the background.

When you want to work with DMA-buf sharing the exported surface *MUST* 
be in interlaced form.

That either leaves us with copying from the progressive to the 
interlaced form during export, or change the firmware to directly decode 
everything into the interlaced format.

Regards,
Christian.

>
> Regards,
> Leo
>
>
>>
>> It's probably pure coincident that you don't get a messed up picture 
>> with that.
>>
>> Christian.
>>
>>> ---
>>>   src/gallium/state_trackers/vdpau/surface.c | 5 ++++-
>>>   1 file changed, 4 insertions(+), 1 deletion(-)
>>>
>>> diff --git a/src/gallium/state_trackers/vdpau/surface.c 
>>> b/src/gallium/state_trackers/vdpau/surface.c
>>> index 012d303641..d63e761350 100644
>>> --- a/src/gallium/state_trackers/vdpau/surface.c
>>> +++ b/src/gallium/state_trackers/vdpau/surface.c
>>> @@ -513,12 +513,15 @@ VdpStatus 
>>> vlVdpVideoSurfaceDMABuf(VdpVideoSurface surface,
>>>      }
>>>        /* Check if surface match interop requirements */
>>> -   if (p_surf->video_buffer == NULL || 
>>> !p_surf->video_buffer->interlaced ||
>>> +   if (p_surf->video_buffer == NULL ||
>>>          p_surf->video_buffer->buffer_format != PIPE_FORMAT_NV12) {
>>>         mtx_unlock(&p_surf->device->mutex);
>>>         return VDP_STATUS_NO_IMPLEMENTATION;
>>>      }
>>>   +   if (!p_surf->video_buffer->interlaced)
>>> +      plane >>= 1;
>>> +
>>>      surf = 
>>> p_surf->video_buffer->get_surfaces(p_surf->video_buffer)[plane];
>>>      if (!surf) {
>>>         mtx_unlock(&p_surf->device->mutex);
>>
>
> _______________________________________________
> mesa-dev mailing list
> mesa-dev at lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/mesa-dev