AMDGPU DC Pull Request Submitted For Linux 4.15: Finally The New Display Stack

[duby229]

Yeesss!!!

[DrYak]

Being heavily based on AMD's internal Windows code there's obviously going to be style differences between that and what the kernel uses.

- to me, sounds like they just took a big chunk of code from fglrx, and said "here, merge this in" - didn't bother integrating with the kernel's DRM stack at all.

Again, for the umpteenth time :
As several AMD phoronix-forum dwellers have explained, the current AMDGPU stack is *NOT* a direct port of the Windows code.
(unlike Nvidia's binary driver which is basically a recompile of their Windows code and is the explanation of why although the Nvidia proprietary driver works on workstation and compute nodes, it utterly sucks on laptops).
Similarly, it shares very little with the former FGLRX (basically, the binary openGL userland library of AMDGPU-PRO is derived from the former FGLRX).

The current stack is basically a rewritten from the ground up at AMD with the target of being a common multi-platfrom base. (i.e.: It was designed from the ground up to compile on Linux AND on Windows AND on the countless embed platforms).
That means clear and evident cross-platform benefits to AMD.
But that also means that, whereas the older Linux code (Radeonsi, etc.) was written by Linux veteran (who are used to produce great kernel-quality-grade code) (but which in the end only serves the Linux drivers), the current new code is written be people who are relatively new to the platform.

Hence the much lower overall quality of the code, lots of problems, lots of places were it just abstracts things into whatever internal API was used in the conception of this new "multi-platform core" instead of doing it the proper linux way.
Hence the initial rejection of DAL and the long process of fixing it until the "the code formely known as DC" ends up as an upstreamable patch.

But it also means that now all improvement of the driver code can be mutually benefiting among all platforms : which means that the linux amdgpu stack is going to see an even faster pace of bugfixes and improvement, and it's easier for AMD to justify their costs as they are not any more developing only for a niche market, but for a common multiplatform core.

Raven Ridge laptops should be out by Christmas and Phoronix needs an evaluation model to test (so I don't get stuck with a buggy one.) hint, hint

Michael : you should consider making a pool to collect money to buy laptops for benchmarking (e.g.: whatever the successor of Lenovo A475 is going to be called)

[bridgman]

Back on topic:
Don't get me wrong, because I started using exclusively AMD GPUs ever since AMD resumed their open source efforts and they all work absolutely marvelous (to the point that I no longer even consider nVidia and actively discourage anyone else from using their binary crap), but how on Earth was this "display code" CLEANED UP from some 100kLOC ("93kLOC to run the displays when whole drivers don't even come close") to almost 130kLOC during at least 414 workdays (594 calendar days) of "this time trying real hard to get it absolutely right"⁈

In parallel with cleaning up we added support for Raven (which has a significantly different display controller and so needs a new set of HW-specific bits) and also some additional features IIRC.

There may also be some code which is no longer required for Linux (as of very recently, as a consequence of using Linux-specific drm helper functions etc...) but still required for all the other platforms and so still in the internal tree (remember the goal is common code across platforms for all the HW-specific bits). There may be some of that clean-up still happening (obviously the code couldn't be removed until the new Linux-specific code had been written). I don't think there is much of that though.

[finalzone]

My AMD A10-7400P laptop running with Kaveri and Hainan card is awaiting.

[GreatEmerald]

The current stack is basically a rewritten from the ground up at AMD with the target of being a common multi-platfrom base. (i.e.: It was designed from the ground up to compile on Linux AND on Windows AND on the countless embed platforms).
That means clear and evident cross-platform benefits to AMD.
But that also means that, whereas the older Linux code (Radeonsi, etc.) was written by Linux veteran (who are used to produce great kernel-quality-grade code) (but which in the end only serves the Linux drivers), the current new code is written be people who are relatively new to the platform.

Hence the much lower overall quality of the code, lots of problems, lots of places were it just abstracts things into whatever internal API was used in the conception of this new "multi-platform core" instead of doing it the proper linux way.
Hence the initial rejection of DAL and the long process of fixing it until the "the code formely known as DC" ends up as an upstreamable patch.

You know... This kind of suggests that the best way to write cross-platform code is to start with writing Linux-specific code, because they have the highest code quality standards. Windows doesn't care, whereas other OSs are too small to do anything about it.

[Marc Driftmeyer]

You know... This kind of suggests that the best way to write cross-platform code is to start with writing Linux-specific code, because they have the highest code quality standards. Windows doesn't care, whereas other OSs are too small to do anything about it.

Thanks for the laugh. I see you don't include OS X in your highest code quality.

[smitty3268]

You know... This kind of suggests that the best way to write cross-platform code is to start with writing Linux-specific code, because they have the highest code quality standards. Windows doesn't care, whereas other OSs are too small to do anything about it.

I'll probably get flamed for not just agreeing, but it's not really about having the highest code quality standards. It's about the fact that all the code is shared. On windows, the driver needs to include it's own functionality for a bunch of stuff, which is why those abstractions were all baked into the DC code to begin with. On linux, you're expected to use the common code if it's already out there rather than having your own flavor, in order to minimize maintenance costs. That's the case even if the shared code is technically worse than what you have - you need to improve the common code then rather than just not using it.

[Luke_Wolf]

Don't get me wrong, because I started using exclusively AMD GPUs ever since AMD resumed their open source efforts and they all work absolutely marvelous (to the point that I no longer even consider nVidia and actively discourage anyone else from using their binary crap), but how on Earth was this "display code" CLEANED UP from some 100kLOC ("93kLOC to run the displays when whole drivers don't even come close") to almost 130kLOC during at least 414 workdays (594 calendar days) of "this time trying real hard to get it absolutely right"⁈

Not associated with the project at all, but I can speak from experience that code that is less abstract isn't going to be smaller generally, quite the opposite as appropriately applied abstraction tends to be DRYer when a project scales vs a less abstract approach.

As an example let's say I've got an application designed in the MVC pattern, the controller could be designed in such a way that it's not abstract and when a command is invoked on it it runs through a gigantic conditional tree which quickly becomes an unmaintainable mess, or I could abstract the code and put all the commands into a container which I can then either loop through and activate based on what supports the command or use functional containers/LINQ/whatever to filter out the ones I want and use just them, and never have to touch that code again if I want to add more functionality with like 5-10 LOC vs a minimum 3*n + 3, where n is the number of commands needed to be supported.

Another easy example, abstracting algorithms such as binary search means only having to deal with 1 copy as opposed to n copies for n types in a concrete implementation.

The problem is not all abstractions are good abstractions, and not all languages are good at writing abstractions in. C in particular isn't too great at this, it can be done but you have to force it on the language. Hence why "muh UNIX Philosophy" is a thing to address this particular shortcoming of the language.

[GreatEmerald]

Thanks for the laugh. I see you don't include OS X in your highest code quality.

I don't know enough about its standards. Does Apple have a public vetting process where they only accept high quality closely-integrated code the way Linux does? I assumed it was more like Windows, where everything is closed and nobody cares.

I'll probably get flamed for not just agreeing, but it's not really about having the highest code quality standards. It's about the fact that all the code is shared. On windows, the driver needs to include it's own functionality for a bunch of stuff, which is why those abstractions were all baked into the DC code to begin with. On linux, you're expected to use the common code if it's already out there rather than having your own flavor, in order to minimize maintenance costs. That's the case even if the shared code is technically worse than what you have - you need to improve the common code then rather than just not using it.

Yes, by my point was that you can start by writing Linux code and then build up abstractions from there, rather than doing it the other way round.

[L_A_G]

Could you please stop arguing with the kernel devs please? The last thing you should be trying to do is make them feel salty. They have good reasons to feel the way they do. But I think there has to be a middle ground somewhere. And these conversations have to be civil and polite so that we have a real chance to figure out where that middle ground is. Right now your just sidetracking that AND WE -REALLY- NEED THAT TO BE ON THE MAIN TRACK INSTEAD.

If you want to be super professional on the subject, then that's what the official mailing lists are for (you know, the ones where everyone uses their real names and not pseudonyms). Public forums (including Usenet groups), article comments sections and non-developer mailing lists have always been a peanut gallery and will probably continue to be that for the foreseeable future. If the maintainers can't stand having to put up with a peanut gallery, then they would do well to stay away from from the previously mentioned places.