[RFC] Using DC in amdgpu for upcoming GPU

[Daniel Stone]

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