[PATCH] drm/amdgpu: fix drm leases being broken on radv
Daniel Vetter
daniel at ffwll.ch
Thu Apr 18 09:11:29 UTC 2019
On Thu, Apr 18, 2019 at 10:52 AM Michel Dänzer <michel at daenzer.net> wrote:
>
> On 2019-04-18 10:26 a.m., Daniel Vetter wrote:
> >
> > Ok correction: amd has stuck out in the past too, there was some vblank vs
> > pageflip stuff where we needed to do some pretty clever tricks to both
> > have the new stricter semantics for everyone, while keeping the amd ddx
> > happy still. This aint new at all, we fixed up the regressions and moved
> > on.
>
> That sounds like something I would have been involved in, but I'm not
> sure what you mean...
>
> I fixed the amdgpu/radeon kernel drivers to obey the general KMS rules
> for vblank vs page flips, and added DRM_MODE_PAGE_FLIP_TARGET to allow
> userspace to take advantage of our hardware's capabilities to avoid
> delaying a page flip by one refresh cycle in some cases. That's all.
That's the one I meant. At least I remember quite a pile of
discussions around why i915 gets to define how this stuff works, and
amdgpu/radeon having to follow.
> > tldr; You're categorical rejection doesn't make sense to me.
> > Slightly over the top, but this feels like gut reaction to radv being a
> > thorn for amd.
>
> That's a weird insinuation. If RADV was a "thorn for AMD", surely we'd
> be having a party about this regression instead of insisting that it be
> fixed thoroughly.
It is fixed. The discussion is who we can evolve the uapi for primary
nodes in an imo useful way (Emil explained the motivations much better
than me), without breaking radv. Christian's take that we flat out
never do that kind of (risky, but it's a trade-off) uapi evolution
just isn't true. And the radv hack under discussion here also isn't
the worst hack we've ever shipped I think in the past to handle the
occasional fallout.
Some other examples that score pretty high on the awful scale:
- legacy context hack for nouvea. Leaves a bunch of root-holes open
for nouveau, in the name of backwards compat. Dave just posted a patch
to at least close those on modern distros
- adfb hack for nouveau 10 bpc rbg formats
- the native endian trickery from Gerd Hoffman
- the vblank vs flip clarifiation that required new uapi and upgraded
amd ddx (really not pretty if we have to somewhat break a performance
feature for some users)
- ...
That's just the ones I remember from the top of my mind, because they
all still leave a gross aftertastes behind. This stuff is pretty
common. Many of these took a few rounds to get there and catch all the
fallout and handle it somehow, and occasionally we just drop it and
live with uapi that's a bit ill-defined or inconsistent across drivers
or not as useful as we'd like it to be. This is the first time I get
an unconditional Nack on such an effort.
-Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
More information about the dri-devel
mailing list