[RFC] Using DC in amdgpu for upcoming GPU

[Alex Deucher]

On Tue, Dec 13, 2016 at 7:22 AM, Daniel Stone <daniel at fooishbar.org> 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.

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