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.
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
_______________________________________________
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
