Re: [RFC] Using DC in amdgpu for upcoming GPU

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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

+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
_______________________________________________
dri-devel mailing list
dri-devel@xxxxxxxxxxxxxxxxxxxxx
https://lists.freedesktop.org/mailman/listinfo/dri-devel




[Index of Archives]     [Linux DRI Users]     [Linux Intel Graphics]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]     [XFree86]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Linux Kernel]     [Linux SCSI]     [XFree86]
  Powered by Linux