I NEEDED to make a new post to get an answer for the old one because anything older than 20 hours (which is not cared about by enough people) falls into the Memory Hole.
.
Inb4 anyone asks “why can’t you just google” or “just spam the Devs”:
I have already “just google’d”, ONLY other forum posts asking for help WITH NO RESULTS came up.
Spamming the Devs will just get me banned, and it’s asshole behavior.
Regressing the Mesa drivers to the latest Mesa 24 release MAY just solve this, but I don’t want to do that for obvious reasons (which I STILL have to preventively list):
Newer Fedora KDE releases may need something from newer Mesa releases.
It’s very hot where I live so I missread the previous post, going off an assumption.
It’s been a while since last time I worked on that PC because I have been busy.
Now too it’s too hot for me to “digest” what is said here:
Long story short:
Since I don’t care about “the deep lore” of Linux incantations, ESPECIALLY NOW that it’s almost 30 italian degrees where I live, can I just get a set of instructions which are SURE to work and a short description about what they do?
What this does is update your bootloader (GRUB) to pass radeon.cik_support=0 and amdgpu.cik_support=1 to the Kernel, which tells radeon driver to not initialize and let amdgpu take over for your hardware.
I don’t know why the default is not to use amdgpu for these old hardware, but there might be issues when you switch over. If you want to undo the changes, run:
If you could not boot (i.e. black screen), you can edit the kernel command line at GRUB screen by pressing e and manually remove the two added parameters, then press Ctrl-X to boot. Afterwards run the above command to clear them out permanently.
With that said, if this issue was caused by an upgrade (and ideally you verified it), please file a bug so the problem can be fixed by Fedora maintainers.
I’ll apply it as soon as the other PC becomes available once again.
In regards of the “bug report” I’ve already filed a couple, but to MESA themselves, as I got told that “this issue is with them, not the Fedora teams”.
.
The issue was partially fixed in Mesa 25.0.x (something), but then it just came right back again.
I made this post here because, other that the quote down here, the second MESA report ended up having no further communications on it, so I didn’t get the answer I sought, which you may have just brought me.
Anyhow, with the parameters added, can you post the output of sudo journalctl -b 0 -k?
In case the output is too long, you can redirect it into a file then upload it to pastebin using: sudo journalctl -b 0 -k | fpaste, then send the link here.
I’d like to have the output of fpaste --sysinfo --printonly as well.
It’ll be some time before I can get to work on that PC again.
In the meantime please click on the second MESA link in Message_5; there already are a lot of files on there which shouldn’t have changed at all since when I uploaded them.
My first post on the Mesa website got an update (comment) and among the things which got suggested, there was this one:
Still, as I said down there in my response: “I argue that “the switch” or whatever should have happened automatically, be it Mesa’s or Fedora’s fault (that may be discovered later).”
The new driver is not a perfect replacement for old GPUs like yours, which was why the kernel developers hasn’t flipped the switch upstream. A case can be made to convince Fedora developers to flip the switch downstream by opening an issue with the project, if you choose to do so (ideally after we verify that the other driver works well for you).
Please collect the required logs after you’ve set the kernel command line as instructed earlier. I’ve seen your prior logs but they don’t have these parameters and as such you weren’t using the driver required for hardware-acceleration.
I’d also note that the “switch to another driver” requirement has always existed for your hardware, so your issue stems from the CPU-based driver being buggy, which is unfortunate. But as you might guess, not a lot of developers play games on that driver and won’t be too interested in providing a timely fix.
Let’s focus on getting your system onto the accelerated driver and see if that solves this issue for you.
If you want me to run the other commands again, then ok, but I need to know which incantations I have to punch in and when yo punch them in to collect the data correctly.
If instead I don’t need to redo that and “just have to collect a log file” then tell me how.
As I said before there has been a change at the release of Mesa 25, there and then support got dropped.
I do not know how the software works, but I don’t see any reason why such great iGPU should not be able to run modern Mesa. That’s why I guess it was a mistake, like a typo or something, from the part of the Devs.
If dmesg output is too long, run dmesg | fpaste and send the link here instead.
There has never been hardware acceleration for Vulkan for your GPU by default to begin with (OpenGL is supported, however). This is AMD not doing the work to make their new driver fully compatible with older GPUs. That’s changing thanks to a Valve developer, but this will still take ~6 months to a year before your system is supported by default, assuming that the patches land during 6.17 and 6.18 kernel cycles.
Refer to the previous post for how to undo the change if needed. ↩︎
The hardware supports Vulkan, but I’m talking about Linux support, which AMD has not finished for your hardware, and thus not enabled by default.
That issue you had then was different, where OpenGL driver was broken, which has now been fixed. You were running the radeon kernel driver then as well, which has never been supported by RADV.
If anything I believe that under Mesa 24 it did actually work.
.
Btw, notice how on each issue I created on the MESA website, the tags “RADV” and “radeonsi” were imposed onto them without asking nor explaining why.
Edit:
I didn’t have long, not enough time, to test all I wanted to on that other computer, but still, Vulkan was working, if even just a little.
So does that mean that this
was you implying that “it was not supported on Linux alone”? Because if I were to install Windows 10 on that computer it’d just work (even if I had to install older drivers).
Does the quote“[…] the modern AMDGPU kernel graphics driver by default is used for GCN 1.2 graphics cards and newer – up through the latest RDNA4 graphics.” mean that “Graphics Core Next 2”, being the 2nd generation, is “GCN 1.1”?
I am asking this directly to confirm it because I don’t want to assume anything.
“But the article already says it” isn’t enough because there are no linked sources, and Wikipedia too calls it just and only “GCN 2nd gen microarchitecture”.
Yes, that’s what I meant. AMD software stack is different for Windows and Linux, and older hardware support on the Linux side is not as good. IIRC GCN is around the time they actually started putting serious money into Linux development.
I believe you were using the CPU-based driver, which is used as a fallback when no hardware-accelerated drivers are available. While it should work, it’s not free of defects as it’s not as well tested as the hardware-accelerated drivers.
That’s correct. AMD naming for this stuff is pretty confusing, but here’s a source reporting what corresponds to what (emphasis mine)
AMD debuted its first generation GCN architecture with the Radeon HD 7000 series, notably the “Tahiti” silicon. Its second-generation, GCN 2.0, (reported in the press as GCN 1.1), debuted with the R9 290 series, notably the “Hawaii” silicon. The third-generation, GCN 3.0 (reported in the press as GCN 1.2), debuted with the R9 285, notably the “Tonga” silicon; making “Polaris” the fourth-generation. GCN 4.0 will form the core micro-architecture of the “Arctic Islands” family of GPUs, which make their debut in mid-2016.
That maybe was true for games, even if they did perform better with Mesa 24 (I can downgrade and test it again another time) but the desktop was totally hardware accelerated.
In fact, my first issue here was because the desktop would struggle to run even at 800x600. Now it’s still LLVMPIPE (both in system’s description, and VulkanCUBE), but it runs much better.
Note