Originally posted by leigh123linux
View Post
Announcement
Collapse
No announcement yet.
It Looks Like AMDGPU DC (DAL) Will Not Be Accepted In The Linux Kernel
Collapse
X
-
Originally posted by bridgman View PostActually this is more about maintainability than stability - DAL/DC code will be more stable than current native code by virtue of being used earlier and by more people.
There is obviously some overlap area (if/when re-factoring in the core code happens there is greater chance of breakage if the restructuring has to include a vendor-specific HAL) but that work tends to happen outside of core kernel development anyways.
Key issue is long term maintainability and that *is* important.
Comment
-
Yep, I thought Christian (deathsimple) summed it up best - something like "we asked for comments, we got comments, everything is proceeding"
BTW Dave didn't say anything yesterday that had not been said before, he was just more explicit about it. It was the "DC the code" vs "DC the interface" ambiguity that made for good television.
If Dave had said "you can't share code and I'm not accepting any of this code even if you reorganize it" that would have been a Really Bad Thing, but that's not what happened.Last edited by bridgman; 09 December 2016, 05:45 PM.Test signature
- Likes 4
Comment
-
I find it quite amusing how big the span of possible meanings is, that can be interpreted into what David wrote. Because I'm one of those who thought that we are all going to die while zombies are eating our brains at
No HALs. We don't do HALs in the kernel.
But what I found quite interesting was, what Daniel mentioned about AMD's mindset regarding work beside anything directly relevant to AMD's interests.
Could you (@bridgman) maybe elaborate a bit about if you think what he mentioned was accurate regarding this matter?
How is the mindset regarding Linux at the management level? Do they see it as wasting money?
Comment
-
Originally posted by Beherit View PostMy questions were quite specific, but I can summarize it down to one question: There is an open source driver from AMD and a closed source driver from AMD, what features does each one have that the other is lacking?
That answer is as useful as an ashtray on a motorcycle. I never asked what "might" work, as I wanted to avoid useless speculations. Both drivers are released and can be tested by those using AMD gfx, making the point moot of guessing what "might" work and not.
Sure, and so can Windows. And Apple computers, and cars, and .. well, pretty much anything. But expectations have little to do with my questions.
I've been able to find out that there are 4 different Linux drivers for AMD cards:- Catalyst, obsolete and doesn't work with newer cards, kernels nor X servers
- AMDGPU, the open source driver from AMD for cards released in 2014 and beyond (HD 7700+)
- AMDGPU-PRO, closed source variant of AMDGPU
- ati, radeonsi, xf86-video-ati or radeon (hard to find what it's actually named), the older open source driver for pre HD7700 cards, does not work with newer cards
Catalyst while being oboslete does not work with Polaris cards only, but should work with anything GCN else. It is X bound up to the version 1.17, but should work with newer kernels even with current 4.9 after patching.
AMDGPU driver was released first with 4.2 kernel, AFAIK that is released august 30. in year 2015. that is far off of 2014. when it was first mentioned First implemented with GCN 1.1 bring up driver and then else newer, but GCN 1.0 will be released only now with kernel 4.9... so only now it support all GCNs.
AMDGPU and AMDGPU-PRO are the two relevant ones for those buying a new gfx card, hence my curiosity what features the closed source driver provides that aren't implemented in the open source one.
PRO GL part it is much more stable overal, supports professional chips much better, support compatability profiles, has shader cache, supports threaded GL and a whole lot more.
Opensource drivers were traditionaly simple and generic drivers really, and by design easier to maintain ... but that involved by the time to be more and more usable, competative and that will be continued.
So after 18 months of amdgpu release, it is much better now than it was at beggining - time fix most of the things, you just need to work on it It is not that just couple AMD devs involved in that, but 40+ maybe we are safe to say 50 if Bridgman approve the numberLast edited by dungeon; 09 December 2016, 07:29 PM.
Comment
-
Originally posted by bridgman View PostYep, I thought Christian (deathsimple) summed it up best - something like "we asked for comments, we got comments, everything is proceeding"
BTW Dave didn't say anything yesterday that had not been said before, he was just more explicit about it. It was the "DC the code" vs "DC the interface" ambiguity that made for good television.
If Dave had said "you can't share code and I'm not accepting any of this code even if you reorganize it" that would have been a Really Bad Thing, but that's not what happened.
Comment
-
Originally posted by seijikun View PostWhile the communication after that suddenly sounded like that of three quarreled brothers talking of each other's problems and solving them together with a huge load of cooperativeness and brother-love despite their loyalty to hostile camps. And everyone lived happily ever after:
Communication is always a challenge for geographically separated people working together on big complex code without having ever met each other or having any common management... and it only works as well as it does because over time everyone gets to know each other. Until that happens, a bit of yelling sometimes helps.
Everyone had their chance to vent, everyone tweaked their words a bit to avoid misunderstanding or unintended offence, and everyone carried on.
Originally posted by seijikun View PostBut what I found quite interesting was, what Daniel mentioned about AMD's mindset regarding work beside anything directly relevant to AMD's interests.
Could you (@bridgman) maybe elaborate a bit about if you think what he mentioned was accurate regarding this matter?
How is the mindset regarding Linux at the management level? Do they see it as wasting money?
What we have been doing with any developer time we could spare is starting Linux work much earlier in the HW development cycle than before, with a goal of actually having Linux drivers running first (by sharing code with our diags teams) rather than last as has been the case until now.
Vega was the first chip where we started testing Linux drivers on emulated HW before we had silicon back (in case you were wondering what I have been doing for the last ~8 months). It was just a start, but we are now ready to implement & test Linux in lock-step with other OSes for future generations.
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.Last edited by bridgman; 10 December 2016, 12:06 AM.Test signature
- Likes 5
Comment
Comment