On Wed, Apr 5, 2017 at 4:27 PM, Daniel Vetter <dan...@ffwll.ch> wrote:
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 <dan...@ffwll.ch>
wrote:
> On Tue, Apr 4, 2017 at 12:43 PM, Lucas Stach
<l.st...@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.
Oh, no! I mean *check* that I'm running on i915, and only use the
no-copy path if I am.
Backporting the patches would indeed be sensible. I guess I should have
CC: stable'd at the time.
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
