[Mesa-dev] [PATCH 09/10] st/vdpau: implement the new DMA-buf based interop

[Christian König]

Am 06.09.2016 um 16:23 schrieb Ilia Mirkin:
> On Mon, Sep 5, 2016 at 2:48 AM, Michel Dänzer <michel at daenzer.net> wrote:
>> On 05/09/16 04:37 AM, Ilia Mirkin wrote:
>>> On Tue, Mar 8, 2016 at 7:21 AM, Christian König <deathsimple at vodafone.de> wrote:
>>>> @@ -80,7 +82,7 @@ vlVdpOutputSurfaceCreate(VdpDevice device,
>>>>      res_tmpl.depth0 = 1;
>>>>      res_tmpl.array_size = 1;
>>>>      res_tmpl.bind = PIPE_BIND_SAMPLER_VIEW | PIPE_BIND_RENDER_TARGET |
>>>> -                   PIPE_BIND_LINEAR;
>>>> +                   PIPE_BIND_LINEAR | PIPE_BIND_SHARED;
>>> Hi Christian,
>>>
>>> This change appears to have semi-broken vdpau on nouveau. Whenever I
>>> flip on the OSD in mplayer, the rendering becomes *extremely* slow.
>>> However regular up-scaling without the OSD is plenty fast. This
>>> effectively is forcing the output surfaces to live in GART instead of
>>> VRAM.
>> Strictly speaking, they'd only need to be forced to GART while they're
>> actually being shared between different GPUs. That's how it works with
>> the amdgpu and radeon kernel drivers.
> Any suggestions on how to handle this? Perhaps reallocate + copy the
> surface in st/vdpau when actual dmabuf sharing is requested?
>
> To be clear - with this change, vdpau with nouveau is unusable in the
> presence of an OSD in mplayer. The OSD comes up whenever you seek
> around in the video, so in effect, it's unusable. Used to work great.

Well I think you should clearly figure out why adding PIPE_BIND_SHARED 
has such dramatic effect.

We not only need this for DMA-buf based interop, but also for the DRI3 
based sharing of buffers with X.

So that clearly sounds like a bug in nouveau to me.

Regards,
Christian.

>
>    -ilia