Originally posted by Dukenukemx
View Post
Announcement
Collapse
No announcement yet.
AMD Quietly Working On New Linux GPU Driver Support Block By Block
Collapse
X
-
Originally posted by Aeder View Post
There's nothing stopping anyone from porting the old drivers to this modular architecture though?
- Likes 5
Comment
-
Originally posted by eyesore View Post
VRAM down clocking is there for RDNA1, and I'm quite sure it's there for RDNA2 too (but don't quote me on that). Do you perhaps use a display with a niche refresh rate like 165Hz? Higher refresh rates besides 120 and 144 (maybe 240Hz too) have non-standard timings for the most part and cause drivers to push mem clock to max in order to avoid black screen and/or crash.Last edited by middy; 18 February 2022, 02:40 PM.
Comment
-
Originally posted by middy View Postit doesn't matter. it does not down clock. but works just fine on windows since that one driver a year ago that brought frequency scaling for vram on 6xxx series. including 165hz.
I just in case ping agd5f as he has (obviously) a lot more in-depth knowledge about the behaviour such as this and could possibly offer an explanation for this.
EDIT: If it indeed clocks down on Windows but doesn't on Linux, then you should open a bug report (and possibly offer and recording/screenshots if they can't reproduce this on their HW and available RR modes).Last edited by eyesore; 18 February 2022, 03:13 PM.
- Likes 1
Comment
-
Originally posted by eyesore View Post
Same goes for me except that every other RR besides the 144Hz causes VRAM to clock @ max (be that 24, 60, 120 etc.. Hz). An idiosyncrasy of my monitor model's EDID I believe. This is consistent on both Windows and Linux. Have you checked other refresh rate modes too?
I just in case ping agd5f as he has (obviously) a lot more in-depth knowledge about the behaviour such as this and could possibly offer an explanation for this.
Phoronix: AMD Quietly Working On New Linux GPU Driver Support Block By Block AMD's Linux graphics driver engineers have been working on the driver support for new graphics processors and now the patches are at the earliest stages of publishing. However, due to driver handling changes, it's sharply different this time around
Comment
-
Originally posted by Anux View PostNot sure if this is the reason. Having multiple configurations of IP blocks combined and giving each a single PCI ID is a huge mess. The new approach will lead to much better/easier code reuse.Last edited by bridgman; 18 February 2022, 07:43 PM.Test signature
- Likes 4
Comment
-
Originally posted by Dukenukemx View PostThis just means us older GPU owners, you know most people who can't afford these insane GPU prices, won't be able to use the new drivers.
If you look at the commit you can see the per-chip hard-coded lists of IP blocks that were removed:
https://github.com/torvalds/linux/co...b23f85bd8e09a4
The actual driver logic changed from per-chip to per-IP-block when we moved from radeon to amdgpu... in fact the primary reason for introducing a new driver was to build it around IP blocks from the start.Last edited by bridgman; 18 February 2022, 05:14 PM.Test signature
- Likes 6
Comment
-
Originally posted by eyesore View Post
Same goes for me except that every other RR besides the 144Hz causes VRAM to clock @ max (be that 24, 60, 120 etc.. Hz). An idiosyncrasy of my monitor model's EDID I believe. This is consistent on both Windows and Linux. Have you checked other refresh rate modes too?
I just in case ping agd5f as he has (obviously) a lot more in-depth knowledge about the behaviour such as this and could possibly offer an explanation for this.
EDIT: If it indeed clocks down on Windows but doesn't on Linux, then you should open a bug report (and possibly offer and recording/screenshots if they can't reproduce this on their HW and available RR modes).
with windows, memory speeds drops all the way down to 14mhz with 165hz at 1440p freesync enabled and it very dynamic based on load. 1629197030638.jpgLast edited by middy; 18 February 2022, 04:06 PM.
- Likes 1
Comment
Comment