On Wed, Sep 7, 2016 at 4:08 AM, Michel Dänzer <mic...@daenzer.net> wrote: > 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.
Any suggestions that don't involve rewriting nouveau bo handling at every level (kernel, ddx, mesa)? Otherwise I'll send a revert for this change. -ilia _______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
