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. Cheers, Daniel
