[RFC] Using DC in amdgpu for upcoming GPU

Tue Dec 13 12:59:53 UTC 2016

On Tue, Dec 13, 2016 at 12:22:59PM +0000, Daniel Stone wrote:
> Hi Harry,
> I've been loathe to jump in here, not least because both cop roles
> seem to be taken, but ...
> 
> On 13 December 2016 at 01:49, Harry Wentland <harry.wentland at amd.com> wrote:
> > On 2016-12-11 09:57 PM, Dave Airlie wrote:
> >> On 8 December 2016 at 12:02, Harry Wentland <harry.wentland at amd.com> wrote:
> >> Sharing code is a laudable goal and I appreciate the resourcing
> >> constraints that led us to the point at which we find ourselves, but
> >> the way forward involves finding resources to upstream this code,
> >> dedicated people (even one person) who can spend time on a day by day
> >> basis talking to people in the open and working upstream, improving
> >> other pieces of the drm as they go, reading atomic patches and
> >> reviewing them, and can incrementally build the DC experience on top
> >> of the Linux kernel infrastructure. Then having the corresponding
> >> changes in the DC codebase happen internally to correspond to how the
> >> kernel code ends up looking. Lots of this code overlaps with stuff the
> >> drm already does, lots of is stuff the drm should be doing, so patches
> >> to the drm should be sent instead.
> >
> > Personally I'm with you on this and hope to get us there. I'm learning...
> > we're learning. I agree that changes on atomic, removing abstractions, etc.
> > should happen on dri-devel.
> >
> > When it comes to brand-new technologies (MST, Freesync), though, we're often
> > the first which means that we're spending a considerable amount of time to
> > get things right, working with HW teams, receiver vendors and other partners
> > internal and external to AMD. By the time we do get it right it's time to
> > hit the market. This gives us fairly little leeway to work with the
> > community on patches that won't land in distros for another half a year.
> > We're definitely hoping to improve some of this but it's not easy and in
> > some case impossible ahead of time (though definitely possibly after initial
> > release).
> 
> Speaking with my Wayland hat on, I think these need to be very
> carefully considered. Both MST and FreeSync have _significant_ UABI
> implications, which may not be immediately obvious when working with a
> single implementation. Having them working and validated with a
> vertical stack of amdgpu-DC/KMS + xf86-video-amdgpu +
> Mesa-amdgpu/AMDGPU-Pro is one thing, but looking outside the X11 world
> we now have Weston, Mutter and KWin all directly driving KMS, plus
> whatever Mir/Unity ends up doing (presumably the same), and that's
> just on the desktop. Beyond the desktop, there's also CrOS/Freon and
> Android/HWC. For better or worse, outside of Xorg and HWC, we no
> longer have a vendor-provided userspace component driving KMS.
> 
> It was also easy to get away with loose semantics before with X11
> imposing little to no structure on rendering, but we now have the twin
> requirements of an atomic and timing-precise ABI - see Mario Kleiner's
> unending quest for accuracy - and also a vendor-independent ABI. So a
> good part of the (not insignificant) pain incurred in the atomic
> transition for drivers, was in fact making those drivers conform to
> the expectations of the KMS UABI contract, which just happened to not
> have been tripped over previously.
> 
> Speaking with my Collabora hat on now: we did do a substantial amount
> of demidlayering on the Exynos driver, including an atomic conversion,
> on Google's behalf. The original Exynos driver happened to work with
> the Tizen stack, but ChromeOS exposed a huge amount of subtle
> behaviour differences between that and other drivers when using Freon.
> We'd also hit the same issues when attempting to use Weston on Exynos
> in embedded devices for OEMs we worked with, so took on the project to
> remove the midlayer and have as much as possible driven from generic
> code.
> 
> How the hardware is programmed is of course ultimately up to you, and
> in this regard AMD will be very different from Intel is very different
> from Nouveau is very different from Rockchip. But especially for new
> features like FreeSync, I think we need to be very conscious of
> walking the line between getting those features in early, and setting
> unworkable UABI in stone. It would be unfortunate if later on down the
> line, you had to choose between breaking older xf86-video-amdgpu
> userspace which depended on specific behaviours of the amdgpu kernel
> driver, or breaking the expectations of generic userspace such as
> Weston/Mutter/etc.
> 
> One good way to make sure you don't get into that position, is to have
> core KMS code driving as much of the machinery as possible, with a
> very clear separation of concerns between actual hardware programming,
> versus things which may be visible to userspace. This I think is
> DanielV's point expressed at much greater length. ;)
> 
> I should be clear though that this isn't unique to AMD, nor a problem
> of your creation. For example, I'm currently looking at a flip-timing
> issue in Rockchip - a fairly small, recent, atomic-native, and
> generally exemplary driver - which I'm pretty sure is going to be
> resolved by deleting more driver code and using more of the helpers!
> Probably one of the reasons why KMS has been lagging behind in
> capability for a while (as Alex noted), is that even the basic ABI was
> utterly incoherent between drivers. The magnitude of the sea change
> that's taken place in KMS lately isn't always obvious to the outside
> world: the actual atomic modesetting API is just the cherry on top,
> rather than the most drastic change, which is the coherent
> driver-independent core machinery.

+1 on everything Daniel said here. And I'm a bit worried that AMD is not
realizing what's going on here, given that Michel called the plan that
most everything will switch over to a generic kms userspace a "pipe
dream". It's happening, and in a few years I expect the only amd-specific
userspace left and still shipping will be amdgpu-pro for
enterprise/workstation customers.

In the end AMD missing that seems just another case of designing something
pretty inhouse and entirely missing to synchronize with the community and
what's going on outside of AMD.

And for freesync specifically I agree with Daniel that enabling this only
in -amdgpu gives us a very high chance of ending up with something that
doesn't work elsewhere. Or is at least badly underspecified, and then
tears and blodshed ensues when someone else enables things. At intel we've
already stopped enabling kms features only in -intel, and instead using
weston, -modesetting or drm_hwcomposer as userspace demonstration vehicles
for new stuff. And I'll be pushing everyone else into that direction, too.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch