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). -- Earthling Michel Dänzer | http://www.amd.com Libre software enthusiast | Mesa and X developer
