Originally posted by Sonadow
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 Ansla View PostMy Acer XF270HU works fine here over DP with either RX 480 or the onboard GPU of Kaveri. Except for audio or freesync, of course. If it doesn't work over HDMI it probably has to do with missing HDMI 2.0 support.
Well, some users (including myself) have reported about this problem at least with Hawaii and also Tonga, iirc.
Interesting that it works for you with Kaveri, whose DCE is a few iterations older than Hawaii's and Tonga's. Could you tell me which exact kernel version you are using? Are you using radeon or amdgpu for Kaveri?
Comment
-
Originally posted by Sonadow View PostBridgman:
Can you tell us what this will mean moving forward for upcoming and future AMD hardware? Now that upstream has made clear their intent to never mainline AMDGPU DC, what kind of loss in functionality cab the average user expect? Will it mean that newer and future hardware will take a much longer time to just light up on Linux?
For example, when Zen is released I intend to assemble a Zen-powered computer and a 1440p monitor with a mid-range GPU (probably also an AMD) for live streaming some browser games over Twitch and Facebook using OBS (Intel is getting a tad expensive over here). What can I expect to not work? Will my card be able to light up the display and start KMS, with at least basic OpenGL acceleration for the DE on launch day? Will I be able to get native resolution over HDMI and DP?
Will future releases take much longer to at least be capable of lighting up the display, activate KMS and attain OpenGL acceleration to at least drive the desktop GUI? And out of the above, how many of these minimum of must-work features can we expect to see supported on Linux of the hardware's launch day?
I will rather not use Windows since I have reached a point where I am much more comfortable on Linux than on Windows, and not needing to buy a copy of Windows is money that is saved for other uses but by Jove, i will sink that money into a copy of Windows if I have to do so in order to use my new hardware at a baseline level of functionality.
Comment
-
Originally posted by Sonadow View PostCan you tell us what this will mean moving forward for upcoming and future AMD hardware? Now that upstream has made clear their intent to never mainline AMDGPU DC, what kind of loss in functionality cab the average user expect? Will it mean that newer and future hardware will take a much longer time to just light up on Linux?
For example, when Zen is released I intend to assemble a Zen-powered computer and a 1440p monitor with a mid-range GPU (probably also an AMD) for live streaming some browser games over Twitch and Facebook using OBS (Intel is getting a tad expensive over here). What can I expect to not work? Will my card be able to light up the display and start KMS, with at least basic OpenGL acceleration for the DE on launch day? Will I be able to get native resolution over HDMI and DP?
Will future releases take much longer to at least be capable of lighting up the display, activate KMS and attain OpenGL acceleration to at least drive the desktop GUI? And out of the above, how many of these minimum of must-work features can we expect to see supported on Linux of the hardware's launch day?
I will rather not use Windows since I have reached a point where I am much more comfortable on Linux than on Windows, and not needing to buy a copy of Windows is money that is saved for other uses but by Jove, i will sink that money into a copy of Windows if I have to do so in order to use my new hardware at a baseline level of functionality.
- initial code pushed for public review
- lots of issues raised
- we're working on implementing changes that address the issues raised
- in the meantime we are lighting up new hardware with DC anyways
- as we resolve initially identified issues it's likely new ones may be identified
- we don't know how long it will take before we can get upstream but are continuing to work on it
After this dramatic event, the situation is :
- initial code pushed for public review
- lots of issues raised
- we're working on implementing changes that address the issues raised
- in the meantime we are lighting up hardware with DC anyways
- as we resolve initially identified issues it's likely new ones may be identified
- we don't know how long it will take before we can get upstream but are continuing to work on it
(in case it's not obvious, nothing has changed)
A lot of the confusion here is that DC has two meanings - it's the big chunk of developer effort & code we want to re-use across platforms for all kinds of good reasons, and it is also a very specific abstraction layer inside that code. It's the second meaning that Dave and Daniel have concerns about, because it internalizes things that they feel should be part of the driver rather than part of what is effectively a blob (despite being publicly developed open source) to them. We understand that.
Again, this was primarily a miscommunication, so other than making for some good reading it doesn't mean much.
Michael really needs to change the article - seems like everyone is posting and getting all worried based on the article and not reading any of the comments before going ahead and making things even worse. I'm trying to be on vacation and can't spend all day responding to basically the same "I didn't read the other comments so this looks bad what do I do" posts over and over again.Last edited by bridgman; 09 December 2016, 12:41 PM.Test signature
- Likes 14
Comment
-
Gee, and people wonder why Nvidia doesn't open source anything. It's exactly moments like this why I support closed-source software. I'm not saying AMD should close this source code and I'm not saying closed-source is better, but if they approached this in a closed-source manner, they wouldn't be in this situation.
As an AMD user, I don't blame Dave for his decisions - AMD should have known what they were getting into. Yes, this situation sucks, but they put themselves in it.
- Likes 1
Comment
-
-
Originally posted by bridgman View Post
The situation before was:
- initial code pushed for public review
- lots of issues raised
- we're working on implementing changes that address the issues raised
- as we resolve initially identified issues it's likely new ones may be identified
- we don't know how long it will take before we can get upstream but are continuing to work on it
After this dramatic event, the situation is :
- initial code pushed for public review
- lots of issues raised
- we're working on implementing changes that address the issues raised
- as we resolve initially identified issues it's likely new ones may be identified
- we don't know how long it will take before we can get upstream but are continuing to work on it
A lot of the confusion here is that DC has two meanings - it's the big chunk of developer effort & code we want to re-use across platforms for all kinds of good reasons, and it is also a very specific abstraction layer inside that code. It's the second one that Dave and Daniel have concerns about, because it internalizes things that they feel should be part of the driver rather than part of what is effectively a blob (despite being publicly developed open source) to them. We understand that.
Again, this was primarily a miscommunication, so other than making for some good reading it doesn't mean much.
What I meant was that without the DC abstraction layer, what will the state of hardware support for AMDGPU be? I don't own any GCN hardware right now so it's not like I can even fool around with the driver to see what works and what doesn't. I'm more interested in knowing whether without the DC layer, will AMDGPU still be capable of providing launch-day (or close to launch day) compatibility with Linux, assuming the latest kernel is used? Or will it take much longer for AMD to get new hardware to at least activate KMS on Linux?
And if it does light up, what works, and what won't work without the DC layer? 1440P over HDMI achievable?
Comment
-
Originally posted by Sonadow View PostThanks, but I think you misunderstood me.
What I meant was that without the DC abstraction layer, what will the state of hardware support for AMDGPU be? I don't own any GCN hardware right now so it's not like I can even fool around with the driver to see what works and what doesn't. I'm more interested in knowing whether without the DC layer, will AMDGPU still be capable of providing launch-day (or close to launch day) compatibility with Linux, assuming the latest kernel is used? Or will it take much longer for AMD to get new hardware to at least activate KMS on Linux?
And if it does light up, what works, and what won't work without the DC layer? 1440P over HDMI achievable?
We will also still be lighting up hardware with "DC the code" whether or not it is upstream at the moment.Test signature
- Likes 2
Comment
-
Originally posted by bridgmanSo "open source is hard, particularly if you ignore the benefits, so we shouldn't do it" ?
Comment
Comment