81 Fresh Patches For AMDGPU's DC (DAL) Display Code

[Snaipersky]

Well, that's the point. Don't they at least comment "this is still not sufficient because of XYZ", or they just silently reject it?

I haven't seen any continued tirades from maintainers, so looks like they just keep saying "nope".

[Mystro256]

Fun fact, for RPM/DEB distros, you should be able to just download the DKMS package from the Pro package, which is open source, and run that with the open source stack that comes with your distro. YMMV on kernel version.

But with that said, i'm going to throw this all in one place:

Ubuntu and derivatives (and Debian?):

https://github.com/M-Bab/linux-kernel-amdgpu-binaries

Fedora:

https://copr.fedorainfracloud.org/coprs/mystro256/amd-staging-kernel

Arch:

https://aur.archlinux.org/packages/linux-amd-staging-git

Source:

https://cgit.freedesktop.org/~agd5f/linux/tree/?h=amd-staging-4.11

[bridgman]

I am probably misunderstanding what DC is, but isn't it supposed to be an abstraction layer for advanced display configuration? If so then in my eyes that means DC itself was never even an option from conception. Am I wrong?

We are trying to get everyone to stop calling it DC (since that is the name of the abstraction layer) or DAL (since that stands for Display Abstraction Layer) since neither of those make sense when we are de-mid-layering the display code. Let's just call it display code, OK ?

(the use of DC/DAL came from a desire to distinguish between this display code and the more limited display code already upstream, but probably not worth the confusion)

[bridgman]

I find pointing out "bug fixes" to be funny, seeing as pretty much nobody has access to the hardware to experience the bugs in the first place (unless these bugs are why the code has been rejected). It's kind of like selling a used car to someone saying "the tires have been replaced twice" as though the owner will be affected by the first tire change.

Why would we leave out the bug fixes ? That would just mean a bunch of extra work to maintain a second copy of the tree containing arch changes but not bug fixes.

[franglais125]

Found a funny patch from the future, year 2217:

https://cgit.freedesktop.org/~agd5f/linux/commit/?h=amd-staging-4.11&id=17f7e29bd0870fd0f43ba1acde3c6c1b65aee734

[shmerl]

We are trying to get everyone to stop calling it DC (since that is the name of the abstraction layer) or DAL (since that stands for Display Abstraction Layer) since neither of those make sense when we are de-mid-layering the display code. Let's just call it display code, OK ?

So what is your plan exactly? To refactor current code not to be an abstraction layer anymore? Are these recent patches already doing it, or not quite yet?

[R41N3R]

Maybe a completely new name would help then :-) Based on the effort by AMD this thing deserves a better one ;-)

[c2h5oh]

bridgman So what is the roadmap right now? I vaguely remember Dave being asked for some feedback on the current state of things about 2 months ago, but while the request was on gfx group the actual feedback/discussion was either private or on IRC - I'd love to know how close this is.

I'm guessing changes to make a next stab at being mainlined by 4.14 merge window close are slim? (I hope I'm wrong)

[bridgman]

Maybe a completely new name would help then :-) Based on the effort by AMD this thing deserves a better one ;-)

We're not very good at coming up with names. Probably better to keep it simple ("display"). We thought about naming it after the display HW block but we're in the process of changing that as well (Raven and subsequent parts have DCN while earlier HW had DCE). The "DC" name was partially an attempt to bridge over the DCE/DCN transition but unfortunately it was also the name of the abstraction layer we need to largely eliminate (at least for Linux).

bridgman So what is the roadmap right now?

Pretty much what you would expect... we keep pushing changes out to a public repo until we think it's worth the maintainers taking another in-depth look, we send out an RFC, everyone gnaws on the code for a while, then we either make a few more changes and get accepted upstream or we make a whole whack of additional changes and try again.

We still have some more work to do before we get to the "take an in-depth look please" point.

[smitty3268]

We still have some more work to do before we get to the "take an in-depth look please" point.

Can you let us know what that entails or is the list still too long to go over in detail?

My understanding from the last go-round was that Dave wanted you guys to port everything to use the atomic modesetting helpers that intel and nouveau are using, and that was going to be a big change, right?