[PATCH 1/2] drm: Add DRM_CAP_PRIME_SCANOUT.
Daniel Vetter
daniel at ffwll.ch
Wed Apr 5 06:27:54 UTC 2017
On Wed, Apr 05, 2017 at 12:20:46AM +0000, Christopher James Halse Rogers wrote:
> On Tue, Apr 4, 2017 at 9:53 PM Daniel Vetter <daniel at ffwll.ch> wrote:
>
> > On Tue, Apr 4, 2017 at 12:43 PM, Lucas Stach <l.stach at pengutronix.de>
> > wrote:
> > >> 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.
> >
> > The even better solution for this is to push the backports through
> > upstream -stable kernels. This stuff here is simple enough that we can
> > do it. Same could have been done for the fairly minimal fencing fixes
> > for i915 (at least some of them, the ones in the page-flip).
> >
> > Otherwise we'll end up with tons IM_NOT_BUGGY and
> > IM_SLIGHTLY_LESS_BUGGY and IM_NOT_BUGGY_EXCEPT_THIS_BOTCHED_BACKPORT
> > flags where no one at all knows what they mean, usage between
> > different drivers and different userspace is entirely inconsistent and
> > they just all add to the confusion. They're just bugs, lets treat them
> > like that.
> >
>
> It's not *quite* DRM_CAP_PRIME_SCANOUT_NOT_BUGGY - while the relevant
> hardware allegedly supports it, nouveau/radeon/amdgpu don't do scanout of
> GTT, so the lack of this cap indicates that there's no point in trying to
> call addfb2.
>
> But calling addfb2 and it failing is not expensive, so this is rather niche.
>
> In practice I can just restrict attempting to scanout of imported buffers
> to i915, as that's the only driver that it'll work on. By the time
> nouveau/radeon/amdgpu get patches to scanout of GTT the fixes should be old
> enough that I don't need to care about unfixed kernels.
"I'll only run on i915" sounds like a rather risky assumption. You're sure
no one will install ubuntu on e.g. rasperry with Eric's shiny new pl111
driver?
I really think that if you want to rely on this, backporting the fixes is
perfectly fine.
-Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
More information about the dri-devel
mailing list