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.
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.
