On 07/09/16 04:19 AM, Christian König wrote: > Am 06.09.2016 um 21:05 schrieb Ilia Mirkin: >> On Tue, Sep 6, 2016 at 2:22 PM, Christian König >> <deathsim...@vodafone.de> wrote: >>> Am 06.09.2016 um 16:23 schrieb Ilia Mirkin: >>>> On Mon, Sep 5, 2016 at 2:48 AM, Michel Dänzer <mic...@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 >>>>>> <deathsim...@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. >> Because the buffer goes into GART. And then you try to blend on it, >> which involves readback from GART (that's how the functions OSD is >> based on work, I believe). We normally don't allocate renderable >> surfaces or textures in GART. >> >>> 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. >> OK, so SHARED != GART? With nouveau, buffers are placed statically in >> either VRAM or GART, so I think that if it's shared it has to end up >> in GART, no? > > As far as I understand it no. Shared just means that we can share it > between applications, doesn't it? Or does it mean the buffer should be > shareable between GPUs? > > Could be that my understanding was wrong and so if it's the later feel > free to provide a patch to just remove the flag. > >> I'm pretty weak on all these concepts, as well as how the DRI3 stuff >> works, unfortunately. > > I have to confess I'm not so deeply into this stuff either. Marek, > Michel what exactly is the meaning of the flag?
According to src/gallium/docs/source/screen.rst: * ``PIPE_BIND_SHARED``: A sharable buffer that can be given to another process. It's also used e.g. for buffers shared via DRI3. So I'm afraid this is something nouveau has to deal with better. -- Earthling Michel Dänzer | http://www.amd.com Libre software enthusiast | Mesa and X developer _______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev