[PATCH 1/2] drm: Add DRM_CAP_PRIME_SCANOUT.

Lucas Stach l.stach at pengutronix.de
Tue Apr 4 10:43:00 UTC 2017


Am Dienstag, den 04.04.2017, 20:27 +1000 schrieb Christopher James Halse
Rogers:
> On 4 April 2017 6:31:12 pm AEST, Daniel Vetter <daniel at ffwll.ch> wrote:
> >On Tue, Apr 04, 2017 at 06:13:20PM +1000, raof at ubuntu.com wrote:
> >> From: Christopher James Halse Rogers <raof at ubuntu.com>
> >> 
> >> Until recently, on (at least) nouveau, radeon, and amdgpu attempting
> >to scanout of an
> >> imported dma-buf would silently result in the dma-buf sharing being
> >broken.
> >> 
> >> While the hardware is capable of scanning out of imported dma-bufs
> >(at least in some circumstances),
> >> these drivers do not currently implement it, so attempts to scan out
> >of such buffers will never succeed.
> >> 
> >> Add a userspace-visible drm capability and associated driver_feature
> >so that userspace can discover
> >> when scanning out of an imported dma-buf can work.
> >> 
> >> Signed-off-by: Christopher James Halse Rogers
> ><christopher.halse.rogers at canonical.com>
> >
> >This seems like an awful specific special case. Why can't you do the
> >entire dance upfront, i.e. import buffer, addfb2? None of that has any
> >visible effect, and it will also allow you to check runtime constraints
> >which can't be covered with this here.
> >-Daniel
> 
> No, because addfb2 doesn't (or, rather, didn't) actually check any
> runtime constraints.
> 
> The problem only appeared when the buffer is actually *used* in a
> modeset - otherwise I could do a (reasonably) cheap
> import/addfb/render on exporter/read out on importer dance to detect
> it.
> 
> To be clear - this is trying to solve the problem “how can I tell if
> it's safe to addfb/pageflip rather than do a GL copy to a GPU-local
> buffer and flip from that?”.
> 
> If I could guarantee that I'd only ever run on 4.13-or-later kernels
> (I think that's when the previous patches will land?), then this would
> indeed be mostly unnecessary. It would save me a bunch of addfb calls
> that would predictably fail, but they're cheap.

I don't think we ever had caps for "things are working now, as they are
supposed to". i915 wasn't properly synchronizing on foreign fences for a
long time, yet we didn't gain a cap for "cross device sync works now".

If your distro use-case relies on those things working it's probably
best to just backport the relevant fixes.

Regards,
Lucas



More information about the dri-devel mailing list