On Wed, Sep 7, 2016 at 5:36 PM, Ilia Mirkin <imir...@alum.mit.edu> wrote: > 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.
PIPE_BIND_SHARED means texture_get_handle is expected to be used on the resource, meaning that inter-API, inter-process, or inter-device sharing is possible. All window back buffers should have the flag. If they don't, it's a bug. If the flag causes nouveau to put the buffer in GART, it's a bug too. There is no reason to use GART for inter-API and inter-process sharing like VDPAU and DRI3 are. To be honest, the flag is pratically useless with respect to EGL and VDPAU, which allow sharing almost any texture. I suggest you fix nouveau. The first step would be to become less dependent on BIND flags whose existence is already questionable. Marek _______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
