It Looks Like AMDGPU DC (DAL) Will Not Be Accepted In The Linux Kernel

[oooverclocker]

Damn, can't find the time to read through almost 200 posts.
Someone able to help out with a summary?

DC(DAL) is not ready to land in the Kernel yet and needs further rework to be accepted. I know - It sounds like the apocalypse.

[duby229]

Once we get to that point I expect we should see our Linux development work become at least a bit more efficient (by virtue of working with the HW devs when they actually remember something about the chip we are trying to bring up, and being able to identify HW plans that don't work for Linux or open source), and I believe that will give us an opportunity to start working outside of the driver again.

Thank you, for me this pretty much clears up the situation. I can fully understand how you guys are presented with dilemmas you have no control over that derive strictly from that fact. I think in the end this will ultimately help AMD produce better drivers because the hardware design will have happened with a linux driver exposing behaviors of our preferred platform.

A great step in the right direction for certain.

[bridgman]

LOL at this email:

https://lists.freedesktop.org/archiv...er/126684.html

The AMD employee is acting all self-entitled over this, I'm glad he didn't get his way or it would have been a mess.

LOL indeed. I hope it was intentional, but yours was the funniest post I have seen so far.

Alex and Dave have been working together on ATI/AMD Linux drivers for 10+ years, and are maybe the most effective team I have seen in my entire career. That usually involves some arguing back and forth until everyone agrees on a direction. You just don't get to see most of it.

[dungeon]

Maybe Michael should write another article about now this Alex's message... also these nearly two hundreds comments here gets difficult to read

It is a bit provocative, so has all the elements to be perfect for clickbait

[bridgman]

Maybe Michael should write another article about now this Alex's message... also these nearly two hundreds comments here gets difficult to read

It is a bit provocative, so has all the elements to be perfect for clickbait

Yep... although I would rather the next article be about Daniel's message, which is a pretty good summary:

https://lists.freedesktop.org/archiv...er/126698.html

It is also a pretty good description of what we did as part of the radeon->amdgpu re-architecture effort.

IMO what people are forgetting is that the traditional open source development process has been something like:

- go to conference
- have big face-to-face arguments about important topics
- drink a lot of beer and try to write down outcome of arguments
- go home and adjust your work to align with what got written down
- repeat

Unfortunately travel budgets are getting smaller (boo !) and Linux development teams are getting larger (yay !) so relatively more of the arguments end up on email. There's probably a climate change analogy in there.

[dungeon]

I can only say Bridgman, good that you have blob driver I never forget that everybody has different POV on what actually the destop is

Ask 100K people, everybody will tell you something else... only with 100K beers they are the same

[indepe]

Sounds like it would be difficult to write a native "linuxy" driver which would intelligently interface with platform-independent code, instead of being a dumb HAL instance.

[dungeon]

Yeah, things getting complicated as Linux is not just Linux... one think Android, some wanna CrOS, other wanna LibreOS, etc, etc...

[bridgman]

Sounds like it would be difficult to write a native "linuxy" driver which would intelligently interface with platform-independent code, instead of being a dumb HAL instance.

We did it with amdgpu but yeah it's not easy. If you look at the amdgpu code you'll see low-level HW IP block handlers (which can potentially be shared across OSes) used and controlled by a Linux-specific top-level driver. It's never as easy or clean as one would like though.

That is also how I expect we will end up organizing DAL/DC (portable IP-block handlers connected by Linux-specific driver code), but it's hard to make that work right now until we finish reorganizing drivers for the other OSes along the same IP-block lines that amdgpu uses today.

[bridgman]

For what it's worth, I think people are starting to run radv on amdgpu + SI. Not sure how well it's working yet though.

Don't see it happening on 6870 though...