On Tue, Sep 6, 2016 at 9:19 PM, Christian König <deathsim...@vodafone.de> 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?
The flag is virtually useless because all textures can be shared using the EGL DMABUF extension. Marek _______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
