[RFC] Using DC in amdgpu for upcoming GPU

[Harry Wentland]

On 2016-12-13 08:50 PM, Michel Dänzer wrote:
> 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).
>
>

Thanks, DanielS, DanielV, and Michel for the insight.

Michel is actually one of the strongest voices at AMD against any ABI 
stuff that's not well thought-out and might get us in trouble down the road.

Harry