On Tue, Dec 13, 2016 at 7:22 AM, Daniel Stone <daniel@xxxxxxxxxxxxx> 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@xxxxxxx> wrote: >> On 2016-12-11 09:57 PM, Dave Airlie wrote: >>> On 8 December 2016 at 12:02, Harry Wentland <harry.wentland@xxxxxxx> 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. For clarity, as Michel said, the freesync stuff we have in the pro driver is not indented for upstream in either the kernel or the userspace. It's a short term solution for short term deliverables. That said, I think it's also useful to have something developers in the community can test and play with to get a better understanding of what use cases make sense when designing and validating the upstream solution. Alex _______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/dri-devel
