Originally posted by pal666
View Post
Announcement
Collapse
No announcement yet.
AMD Submits Radeon/AMDGPU DRM Updates Slated For Linux 4.13
Collapse
X
-
Originally posted by geearf View PostDo the staging branches get the stable updates from upstream? It seems to still be on 4.11 while upstream is on 4.11.4 (Well let's say .3 is 4 is so new...).
Right now moving to a new kernel base is fairly disruptive, but as we bring the open/hybrid/rocm trees closer together this will get easier.Test signature
- Likes 5
Comment
-
Originally posted by debianxfce View PostAMD, KISS. Remove SI and CIK support from the radeon driver. This is/was AMDs plan.
... but before we can do that we have to get amdgpu support for those parts far enough along to be a good replacement.Test signature
- Likes 2
Comment
-
Originally posted by bridgman View Post
Just major kernel versions at the moment, typically every 1 or 2 kernel releases.
Right now moving to a new kernel base is fairly disruptive, but as we bring the open/hybrid/rocm trees closer together this will get easier.
Do you expect most update patches to apply though?
If I can still manually apply patches, it's not a big deal.
Thank you for the quick reply!
Comment
-
Originally posted by debianxfce View PostFor the A8-7600 the CIK support has been excellent for years. It is better to start testing the amdgpu driver with SI and CIK support now and not later. Hiding working code with kernel config flags is stupid.
Changing the kernel config defaults so that everyone is forced from radeon to amdgpu (whether the driver is ready or not) is even more stupid IMO. We might get away with it for CIK (although IIRC we would lose HDMI audio among other things) but it would be a Really Bad Thing for SI users.Test signature
Comment
-
Originally posted by geearf View PostOoooooh, that's not really good for fixes/security though :/
Do you expect most update patches to apply though?
If I can still manually apply patches, it's not a big deal.
That said, I think we are looking at a "driver only" install model going forward rather than "build this entire kernel tree", so keeping the entire tree in a ready to use form (stable patches, probably CPU patches as well) would be more of a fallback plan.Test signature
Comment
-
Originally posted by debianxfce View Post
Current amdgpu driver does not have hdmi audio either. For that you have the amd-staging-11 branch. A high end gaming pc uses hifi quality speakers and does not waste cpu cycles to hdmi audio. It looks like some stupid marketing strategy to delay amdgpu support for old gpus. People will buy nvidia card more easily with your current marketing strategy.
"(whether the driver is ready or not)"
When I bought my first RX460, I thought it was broken when using the same custom agd5f kernel that I used with A8-7600. It took a week to figure correct kernel settings, enabling virtualization and KVM support is essential for stability. Then there was a mesa bug that destroyed performance, it took 2 weeks to fix.
- Likes 1
Comment
-
Originally posted by debianxfce View PostIt looks like some stupid marketing strategy to delay amdgpu support for old gpus. People will buy nvidia card more easily with your current marketing strategy.
Comment
-
Originally posted by bridgman View Post
I don't think we are making any changes which would impact stable patch application.
That said, I think we are looking at a "driver only" install model going forward rather than "build this entire kernel tree", so keeping the entire tree in a ready to use form (stable patches, probably CPU patches as well) would be more of a fallback plan.
The driver only model seems a lot better indeed for that purpose
Thanks!
Comment
-
Originally posted by bridgman View Post
We are testing it, as are community users - in both open source and hybrid (AMDGPU-PRO) scenarios.
Changing the kernel config defaults so that everyone is forced from radeon to amdgpu (whether the driver is ready or not) is even more stupid IMO. We might get away with it for CIK (although IIRC we would lose HDMI audio among other things) but it would be a Really Bad Thing for SI users.
Comment
Comment