[RFC] Using DC in amdgpu for upcoming GPU

Wed Dec 14 01:50:45 UTC 2016

On 13/12/16 09:59 PM, Daniel Vetter wrote:
> On Tue, Dec 13, 2016 at 12:22:59PM +0000, Daniel Stone 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.
>>
>> 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.
> 
> +1 on everything Daniel said here. And I'm a bit worried that AMD is not
> realizing what's going on here, given that Michel called the plan that
> most everything will switch over to a generic kms userspace a "pipe
> dream". It's happening, and in a few years I expect the only amd-specific
> userspace left and still shipping will be amdgpu-pro for
> enterprise/workstation customers.

The pipe dream is replacing our Xorg drivers with -modesetting. I fully
agree with you Daniels when it comes to non-Xorg userspace.

> In the end AMD missing that seems just another case of designing something
> pretty inhouse and entirely missing to synchronize with the community and
> what's going on outside of AMD.
> 
> And for freesync specifically I agree with Daniel that enabling this only
> in -amdgpu gives us a very high chance of ending up with something that
> doesn't work elsewhere. Or is at least badly underspecified, and then
> tears and blodshed ensues when someone else enables things.

Right, I think I clearly stated before both internally and externally
that the current amdgpu-pro FreeSync support isn't suitable for upstream
(not even for xf86-video-amdgpu).

-- 
Earthling Michel Dänzer               |               http://www.amd.com
Libre software enthusiast             |             Mesa and X developer