On 2016-12-13 08:50 PM, Michel Dänzer wrote: > On 13/12/16 09:59 PM, Daniel Vetter wrote: >> 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. > > The pipe dream is replacing our Xorg drivers with -modesetting. I fully > agree with you Daniels when it comes to non-Xorg userspace. > > >> 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. > > Right, I think I clearly stated before both internally and externally > that the current amdgpu-pro FreeSync support isn't suitable for upstream > (not even for xf86-video-amdgpu). > > Thanks, DanielS, DanielV, and Michel for the insight. Michel is actually one of the strongest voices at AMD against any ABI stuff that's not well thought-out and might get us in trouble down the road. Harry
