Issues with Mesa 24.3.x and amdgpu Vega graphics

lpr1 · 2025-01-24 15:07:11

seth wrote:

A bunch of developers were taken from the maintainer list because they work for companies that are under sanction for unrelated global events that are completely out of the kernel maintainers control. This was in the news, maybe get off social media for your world view.
This is however completely unrelated to mesa having a bug or Linus having agreed to no longer rant at people - and having an opinion on any of that isn't "politically incorrect" but simply vastly off topic.
Speaking of which, what's the status quo here?
The patched build provided by Lone_Wolf solves some problem but not all?
Do the remainders get the same backtraces or are they now different?

Oh, I see, no I don't really follow all that nonsense, politics is garbage and I don't want to waste my time with it. Yes, mesa is a separate project with separate people, I understand that, I was talking about linux kernel. What I do not understand however, is why would anyone ban contributors, regardless for whom they work, if license is under GPL, and since they do not work for linux foundation, they are not a subject to any sanctions imposed by country where organisation is registered. But, it's their decision and their lost regardless.
My view is, that governments do not have jurisdiction over what I do with my free time and to who I'm helping by contributing, code, water, bread, whatever..., I really fail to see how that can be legal even since we are on the topic.

"The patched build provided by Lone_Wolf solves some problem but not all?"
I just didn't have time to test his patch, I have to compile it myself, but from what others said, it seems that patch provided by Lone_Wolf solves the freezing issue, tho., some people reported crashes with it, but only 2 so far and after 24+ hours or so.

SnowF · 2025-01-24 15:35:32

It turns out that I decided to try /etc/X11/xorg.conf.d/20-amdgpu.conf default no options.
And it crashed 15 minutes after starting the system.

Adding the following gives me a smooth experience under any type of load.
mesa 24.3.4

Section "OutputClass"
     Identifier "AMD"
     MatchDriver "amdgpu"
     Driver "amdgpu"
     Option "EnablePageFlip" "off"
     Option "TearFree" "false"
EndSection

It hasn't crashed (GNOME), KDE is still unstable.
I suspect it has something to do with tearfree / vertical sync good point @lpr1

I suspect it's probably related to the "EnablePageFlip" "off"

Last edited by SnowF (2025-01-24 15:50:07)

lpr1 · 2025-01-24 15:42:49

SnowF wrote:

It turns out that I decided to try /etc/X11/xorg.conf.d/20-amdgpu.conf default no options.
And it crashed 15 minutes after starting the system.
Adding the following gives me a smooth experience under any type of load.
Section "OutputClass"
     Identifier "AMD"
     MatchDriver "amdgpu"
     Driver "amdgpu"
     Option "EnablePageFlip" "off"
     Option "TearFree" "false"
EndSection
It hasn't crashed (GNOME), KDE is still unstable.
I suspect it has something to do with tearfree / vertical sync.
mesa 24.3.4

I've added exact same config, and will see tomorrow if it makes any difference while working with Blender. If it does, I suspect it's probably related to the "EnablePageFlip" "off", you can remove tearfree and see if it makes any difference for you since you already tested with it. I disable vblank via .drirc, so it shouldn't be related with v-sync, unless all of us who do have issues run it without v-sync, but that wouldn't explain wayland.

seth · 2025-01-24 16:24:45

Still crashes after "hw_done or flip_done timed out"?
Does either of you have a https://wiki.archlinux.org/title/Variable_refresh_rate capable output?
And is it the same with https://bbs.archlinux.org/viewtopic.php … 1#p2220871 ?

NuSkool · 2025-01-24 19:45:32

I switched to mesa mesa 1:24.3.4-1 from the extra/testing repo in extra repo now.
Been running it for around 24HR without issues.

$ pacman -Q mesa llvm-libs linux linux-firmware amd-ucode 
mesa 1:24.3.4-1
llvm-libs 19.1.7-1
linux 6.12.10.arch1-1
linux-firmware 20250109.7673dffd-1
amd-ucode 20250109.7673dffd-1

$ sudo dmesg | grep gfx 
....
[    6.223962] [drm] add ip block number 6 <gfx_v9_0>

An overview of testing...
Everything(1) freezes/crashes for me so far except Lone_Wolf's patched mesa and this latest version.(2)

It's been a few days since I've updated this system so will do after posting.

1) All mesa repo vesions, various mesa-git versions, and Lone_Wolf's unpatched mesa.
2) Excluding my custom compiled 'mesa 1:24.3.3-2', which was against 'llvm-libs 18.1.8-5'.

Last edited by NuSkool (2025-01-24 20:27:54)

bernd_b · 2025-01-24 20:51:34

NuSkool wrote:

I switched to mesa mesa 1:24.3.4-1 from the extra/testing repo in extra repo now.
Been running it for around 24HR without issues.

No luck here. It took only a short time and the pc literally was doing nothing. When I came back to it after about 2h, I switched on my screen and it kept being black. Keyboard frozen.

I'll give a patched mesa-git a try, but the best so far for me was to use mesa <= 24.2.8.

NuSkool · 2025-01-24 21:37:01

OK, took a bit longer and just recovering from a mesa 1:24.3.4-1 freeze/crash.

So that now makes Lone_Wolf's patched version of mesa the only one available that doesn't freeze for me.

This post is getting very long for a thorough review without taking notes at this point....
Here's Lone_Wolfs post of the patched mesa for anyone just finding this: https://bbs.archlinux.org/viewtopic.php … 3#p2220233
Download the link labeled: mesa trunk commit 94da1edbe49
Here's the installed package details: mesa-test-git 25.0.0_devel.200085.94da1edbe49-1

Should we consider a standardized format or template for reports moving forward with links to pkgs including details on the name/version?

@Lone_Wolf, Any advantage in recompiling against later releases since you posted this? If this bug doesn't get fixed in the near future, perhaps an AUR package that uses the mesa-git build, using repo llvm-libs + the patch applied? It appears to me that things are at a standstill on this bug due to the mesa dev not being able to reproduce the freeze on his hardware?

Here's a few mesa issue reports I started monitoring. Any others to add that are possibly related to our issues here?
https://gitlab.freedesktop.org/mesa/mesa/-/issues/12310
https://gitlab.freedesktop.org/mesa/mesa/-/issues/12457

@everyone, Please correct anything I get wrong here....

@bernd_b Yea I've tested two versions of the AUR 'mesa-git' package using repo 'llvm-libs' built in clean chroot. Both locked up for me...
Looking like Lone_Wolfs patched mesa may be the only viable pre-build option.
IIRC, I started getting some laggy mouse behavior with this version, but never looked into it before moving onto testing different versions.
I am sure this is the only version that hasn't froze my system though.

Last edited by NuSkool (2025-01-24 22:30:11)

Iced-Dolphin · 2025-01-24 23:03:17

Hi all, I've been lurking in this thread from page 6, I am relatively new to Linux so forgive me if I do not know much, I am also unsure if I can post here due to me not running arch. My specs are Ryzen 3 3200G A320M-HDV R4.0 ( latest available bios :AM4 AGESA Combo V2 PI 1.2.0.Cc ) 16gig ram

The first time I ever encountered this bug was when I was running Linux mint as a daily driver back in June of 2024, I didn't know about journalctl back then so I cannot confirm whether it is the same bug as now or not, But they visually and mechanically are the same

I kept running the computer despite the occasional freezes until late December in which I made the switch to Kubuntu 24.10, I am running KDE with Wayland,
Kernel Linux 6.11.0-13-generic
the freezes do occur with journalctl displaying the following :
amdgpu 0000:06:00.0: amdgpu: ring gfx timeout, signaled seq=3099996, emitted seq=3099998
amdgpu 0000:06:00.0: amdgpu: Process information: process plasma-systemmo pid 34363 thread plasma-sys:cs0 pid 34367

I have tried most of the proposed fixes that exist in this thread (amdgpu.gpu_recovery=0 MESA_SHADER_CACHE_DISABLE=true) none solving the issue.
I have not been able to test the patched mesa by Lone_Wolf due to me not knowing how to install it on my machine.
I also have not been able to downgrade to mesa 24.2.7 for the same reason.
I am currently running and staying up to date with Oibaf's Mesa releases https://launchpad.net/~oibaf/+archive/u … cs-drivers
at the time of writing I am running mesa : 25.0~git2501240600.09f730~oibaf~o
running sudo cat /sys/kernel/debug/dri/1/amdgpu_gpu_recover on this mesa has mutliple results: freezes , returns 0, returns 0 and crashes KDE
the following freezes happen on this mesa

The system does freeze on resizing Steam, opening an image in Flatpak GIMP
Most of my freezes occur when I am in discord calls with Flatpak Vesktop and running Librewolf, Firefox
disabling hardware acceleration from my experience does help but does not solve the issue.
the only game freeze I seem to get is from "Slay the Princess" 20 Minutes+ playtime and a freeze occurs( Maybe Ren'Py games? ), other games run fine and are playable for extended periods of time (8h+)
Editing .txt 's in Kate may be a point of a freeze as it froze twice whilst I am writing this.

I apologize if this post has added confusion to an already confusing topic.

seth · 2025-01-24 23:56:17

The first time I ever encountered this bug was when I was running Linux mint as a daily driver back in June of 2024

Hardly, the one here is a regression in mesa 24.3, released first on November 21, 2024

I have not been able to test the patched mesa by Lone_Wolf due to me not knowing how to install it on my machine.

On Ubuntu? "Not", you'll probably run into ABI incompatibilities/resolution failures, certainly if your distro doesn't use LLVM 19.

the freezes do occur with journalctl displaying the following :

amdgpu 0000:06:00.0: amdgpu: ring gfx timeout, signaled seq=3099996, emitted seq=3099998
amdgpu 0000:06:00.0: amdgpu: Process information: process plasma-systemmo pid 34363 thread plasma-sys:cs0 pid 34367

That's the plasma system monitor.

https://gitlab.freedesktop.org/drm/amd/-/issues/3707
https://gitlab.freedesktop.org/drm/amd/-/issues/3761

Both are voltage/VRAM clock related.

lpr1 · 2025-01-25 06:26:47

SnowF wrote:

It turns out that I decided to try /etc/X11/xorg.conf.d/20-amdgpu.conf default no options.
And it crashed 15 minutes after starting the system.
Adding the following gives me a smooth experience under any type of load.
mesa 24.3.4
Section "OutputClass"
     Identifier "AMD"
     MatchDriver "amdgpu"
     Driver "amdgpu"
     Option "EnablePageFlip" "off"
     Option "TearFree" "false"
EndSection
It hasn't crashed (GNOME), KDE is still unstable.
I suspect it has something to do with tearfree / vertical sync good point @lpr1
I suspect it's probably related to the "EnablePageFlip" "off"

Unfortunately, I can't confirm this workaround, just got crash working in Blender and standard Firefox as an background process, I had exact same config and mesa version as you have.

lpr1 · 2025-01-25 06:29:27

seth wrote:

Still crashes after "hw_done or flip_done timed out"?
Does either of you have a https://wiki.archlinux.org/title/Variable_refresh_rate capable output?
And is it the same with https://bbs.archlinux.org/viewtopic.php … 1#p2220871 ?

I think it's completely unrelated to the VRR, the reason is simple, I have it disabled in the monitor itself, so it's reported as not supported to xrandr, but, regardless if it's enabled or disabled, freezes happen sadly.

seth · 2025-01-25 08:38:37

Next question: is everyone here using xf86-video-amdgpu or are there modesetting/wayland users?

bernd_b · 2025-01-25 09:44:40

pacman -Qs xf86
local/lib32-libxxf86vm 1.1.5-2.1
    X11 XFree86 video mode extension library (32-bit)
local/libxxf86vm 1.1.6-1.1
    X11 XFree86 video mode extension library
local/xf86-input-libinput 1.5.0-1.1 (xorg-drivers)
    Generic input driver for the X.Org server based on libinput

So If I got this right I use the kernel driver itself and not the xf86-xxx driver?!

NotAnArchUser · 2025-01-25 10:02:40

Hello everyone, Void Linux user here. We've experienced these bugs too.

And just like in Arch the problem was somewhat solved by downgrading mesa. In our case maintainers did it by reverting mesa in repository to version 24.2.8_2.

seth wrote:

Next question: is everyone here using xf86-video-amdgpu or are there modesetting/wayland users?

I am myself sway user and I've seen reports from dwl users. Both are wayland compositors of course.

Lone_Wolf · 2025-01-25 10:53:59

bernd_b wrote:

So If I got this right I use the kernel driver itself and not the xf86-xxx driver?

No, on X there are 2 options :
use a dedicated DDX (xf86-video-* ) OR the X modesetting driver from xorg-server package .

Both use the same kernel module and fully support Kernel Mode Setting

NuSkool wrote:

@Lone_Wolf, Any advantage in recompiling against later releases since you posted this? If this bug doesn't get fixed in the near future, perhaps an AUR package that uses the mesa-git build, using repo llvm-libs + the patch applied? It appears to me that things are at a standstill on this bug due to the mesa dev not being able to reproduce the freeze on his hardware?

https://docs.mesa3d.org/release-calendar.html indicates that in 4 days trunk will go to 25.1 and mesa 25.0 will be branched off to become next stable .
I'll upload a new binary tomorrow.

Worst case scenario :
upstream devs won't be able to reproduce the problem and the patch won't be added to mesa trunk/stable anytime soon .

The patch itself has this line

bool is_gfx9_apu = sscreen->info.gfx_level == GFX9 && !sscreen->info.has_dedicated_vram;

It will only affect gfx 9 chipset with dedicated vram and is definitely unique for gfx9 (vega) .
There should be no effect at all on non-amd videocards and older amd-chipsets like RX 400/500 series or newer amd-chipsets like RX 5000 (Navi) series .

Arch devs sometimes add patches to solve issues, how to increase the chance they will add this patch ?

I think/hope 2 packages tracking mesa 25.0 rc-candidates based on repo mesa/lib32-mesa packages tested by users (preferably with and without gfx9) will help to achieve that .

The packages could be hosted on AUR and be taken down when when mesa 25.0.x enters testing-repos with the patch .

NuSkool wrote:

Should we consider a standardized format or template for reports moving forward with links to pkgs including details on the name/version?

Yes, good idea.

Looks like 2 roles need to be fulfilled
- someone to submit/maintain those packages
- someone that coordinates a structured approach
Those roles could offcourse be done by 1 individual.

(I will continue to help, but am not willing to take on either of those roles)

If users from other distros can setup something similar for their distros, it would increase the chances of getting this solved/accepted upstream.

pacmancrashedagain · 2025-01-25 11:05:20

seth wrote:

Next question: is everyone here using xf86-video-amdgpu or are there modesetting/wayland users?

I'm on xf86-video-amdgpu and use qtile on xorg.

lpr1 · 2025-01-25 12:50:57

seth wrote:

Next question: is everyone here using xf86-video-amdgpu or are there modesetting/wayland users?

Same as @pacmancrashedagain, I'm using xf86-video-amdgpu, but it's a good idea to try modesetting.

Just got freeze (using just GIMP) with modesetting driver, so it's likely not ddx, at least not on X11.

Last edited by lpr1 (2025-01-25 13:08:53)

seth · 2025-01-25 13:52:34

Ftr, the culprit is the kernel module or libmesa no matter what - the only question would have been whether the DDX is the trigger (and you could sidestep the problem this way)

Lone_Wolf wrote:

upstream devs won't be able to reproduce the problem and the patch won't be added to mesa trunk/stable anytime soon

So what? Even if *they* cannot reproduce it, there's ample evidence that this is a problem and apparently also confirmation for the patch fixing it.
Since this seems flipping related it might require specific output setups to trigger this.

Speaking of which: so it's not VRR, but does the monitor then run at 60Hz or a (much) higher frequency (100, 144, 160, 240) and what if you constrain it to 60Hz?

NotAnArchUser · 2025-01-25 14:13:52

NotAnArchUser wrote:

And just like in Arch the problem was somewhat solved by downgrading mesa. In our case maintainers did it by reverting mesa in repository to version 24.2.8_2.

As I've said "somewhat" solved. Just got another freeze right now.

And there is more reports still showing up in Void issues. Like this one for example: https://github.com/void-linux/void-pack … sues/54052

I don't know if that is important but I have to say that I'm experiencing similarly behaving freezes with my integrated gfx9 (Athlon 300U) at least since July 2024 (I don't have earlier logs). And before "hw_done or flip_done timed out" it's all started with these kind of errors:

2024-07-30T07:01:05.25361 kern.err: [59204.172442] [drm:amdgpu_job_timedout [amdgpu]] *ERROR* ring gfx timeout, signaled seq=1135687, emitted seq=1135688

I hope this information will help to investigate current issue.

lpr1 · 2025-01-25 14:47:53

seth wrote:

Ftr, the culprit is the kernel module or libmesa no matter what - the only question would have been whether the DDX is the trigger (and you could sidestep the problem this way)
Speaking of which: so it's not VRR, but does the monitor then run at 60Hz or a (much) higher frequency (100, 144, 160, 240) and what if you constrain it to 60Hz?

DDX doesn't seem to make any difference, freezes with both amdgpu and modesetting, if it's of any help, I run constant 60Hz (makes little sense to run 100Hz with integrated graphics, plus, all LCDs blur stuff even at billion hertz).

flemingfleming · 2025-01-25 20:00:00

Testing the build 25.0.0_devel.200085.94da1edbe49 provided by Lone_Wolf and it seems to be working great, without any freezes after two days.

However, reading from

/sys/kernel/debug/dri/1/amdgpu_gpu_recover

still crashes the system on both the official arch build of mesa (24.3.3) and the patched version I'm currently running. This is despite setting the environment variable

MESA_SHADER_CACHE_DISABLE="true"

and

amdgpu.gpu_recovery=0

as a kernel command-line parameter as was suggested. Neither of these prevented the freezes on the bugged versions of mesa either.

So I think that the crash you can induce that way is an entirely separate bug not related to the freezes?

Note, this is on a Ryzen 5 2500U APU (Raven Ridge/Vega). And I'm on Wayland (KDE)

NuSkool · 2025-01-25 20:24:43

Next question: is everyone here using xf86-video-amdgpu or are there modesetting/wayland users?

Not using /etc/X11/xorg.conf.d/20-amdgpu.conf

I knew I wasn't using xf86-video-intel xf86-video-amdgpu or any related manual configurations, then AFAIK the modesetting driver will automatically be used....
I think there are more options too, but it gets somewhat confusing to me and seems to lead way down a deep rabbit hole.
My use case is just web browsing, watching vids, don't care about gaming, screen tearing, maximizing GPU performance, etc...

Would something like this provide enough info to answer every ones questions about hardware and software for xorg users?

$ sudo dmesg | grep gfx ; pacman -Qsq xf86 ; inxi -G ; grep -i 'modesetting' ~/.local/share/xorg/Xorg.0.log

[    6.534966] [drm] add ip block number 6 <gfx_v9_0>
[    6.774362] amdgpu 0000:0a:00.0: amdgpu: ring gfx uses VM inv eng 0 on hub 0
libxxf86vm
xf86-input-libinput
Graphics:
  Device-1: Advanced Micro Devices [AMD/ATI] Raven Ridge [Radeon Vega Series
    / Radeon Mobile Series] driver: amdgpu v: kernel
  Display: unspecified server: X.org v: 1.21.1.15 with: Xwayland v: 24.1.4
    driver: X: loaded: modesetting dri: radeonsi gpu: amdgpu
    resolution: 1920x1080~60Hz
  API: EGL v: 1.5 drivers: kms_swrast,radeonsi,swrast
    platforms: gbm,x11,surfaceless,device
  API: OpenGL v: 4.6 compat-v: 4.5 vendor: amd mesa v: 25.0.0-devel
    renderer: AMD Radeon Vega 11 Graphics (radeonsi raven ACO DRM 3.59
    6.12.10-arch1-1)
  Info: Tools: api: eglinfo,glxinfo de: xfce4-display-settings
    gpu: radeontop x11: xdriinfo, xprop, xrandr
[    32.544] (==) Matched modesetting as autoconfigured driver 1
[    32.545] (II) LoadModule: "modesetting"
[    32.545] (II) Loading /usr/lib/xorg/modules/drivers/modesetting_drv.so
[    32.546] (II) Module modesetting: vendor="X.Org Foundation"
[    32.546] (II) modesetting: Driver for Modesetting Kernel Drivers: kms

EDIT: Correct xf86-video-* package per lpr1 (TY!) pointing out it was wrong.
Yea, the xf86-video-intel package wouldn't do anything for an AMD GPU AFAIK.
Must have copied pasted the wrong one or was thinking of my other newish mini system w/ an N100 CPU.

Last edited by NuSkool (2025-01-26 06:15:34)

Mechanicus · 2025-01-25 23:17:17

Just for reminder: problems with pageflip timeout started not in December, but about a year ago.
https://gitlab.freedesktop.org/drm/amd/-/issues/2950
https://community.amd.com/t5/pc-drivers … d-p/723574
https://www.reddit.com/r/archlinux/comm … p_timeout/
https://www.reddit.com/r/AMDHelp/commen … imeout_on/
https://bugs.kde.org/show_bug.cgi?id=493277
https://lists.freedesktop.org/archives/ … 46656.html
https://github.com/M-Bab/linux-kernel-a … /issues/48
https://forums.freebsd.org/threads/amdg … set.89229/

The most interesting outcome is the last comment from the last provided link:

For me, a recent DRM update of "latest" package tree, has solved the issue.

What means that the problem is not is mesa. It goes deeper, to DRM and firmware binaries.
Since the "fix" you're trying to apply changes only the state of compute queues, I think we can try to force them to be handled by CPU by adding amdgpu.vm_update_mode=3 kernel parameter (see documentation).
The next thing to try is Enable Micro Engine Scheduler via amdgpu.mes=1
Anyway the fix that disables half of the GPU functionality should be the last solution.

lpr1 · 2025-01-26 04:12:11

NuSkool wrote:

Not using /etc/X11/xorg.conf.d/20-amdgpu.conf
I knew I wasn't using xf86-video-intel or any related manual configurations, then AFAIK the modesetting driver will automatically be used....
I think there are more options too, but it gets somewhat confusing to me and seems to lead way down a deep rabbit hole.

To help clarify things, it's actually quite simple, if you install xf86-video-amdgpu package, it will be used automatically as you said, if you remove it modesetting will be used instead, no need for any manual configuration. AFAIK you can't use xf86-video-intel for example on AMD or vice versa, I could be wrong on this one, but even if I am, it would be not something one wants to do.

Mechanicus wrote:

What means that the problem is not is mesa. It goes deeper, to DRM and firmware binaries.
Since the "fix" you're trying to apply changes only the state of compute queues, I think we can try to force them to be handled by CPU by adding amdgpu.vm_update_mode=3 kernel parameter (see documentation).
The next thing to try is Enable Micro Engine Scheduler via amdgpu.mes=1
Anyway the fix that disables half of the GPU functionality should be the last solution.

Does amdgpu.mes=1 work with vega?

Last edited by lpr1 (2025-01-26 04:17:29)

pacoandres · 2025-01-26 07:44:53

I've been testing mesa 24.3.4 for a couple of days and I can say that it's still buggy.

I've also discover a way to freeze my computer: changing windows (alt+tab) very quick leads to a freeze with the buggy versions when there's a browser opened.
I can't get the freeze when using the patched version.

Now I'm trying to compile 24.3.4 with the patch and see what happens.

Arch Linux

#251 2025-01-24 15:07:11

Re: Issues with Mesa 24.3.x and amdgpu Vega graphics

#252 2025-01-24 15:35:32

Re: Issues with Mesa 24.3.x and amdgpu Vega graphics

#253 2025-01-24 15:42:49

Re: Issues with Mesa 24.3.x and amdgpu Vega graphics

#254 2025-01-24 16:24:45

Re: Issues with Mesa 24.3.x and amdgpu Vega graphics

#255 2025-01-24 19:45:32

Re: Issues with Mesa 24.3.x and amdgpu Vega graphics

#256 2025-01-24 20:51:34

Re: Issues with Mesa 24.3.x and amdgpu Vega graphics

#257 2025-01-24 21:37:01

Re: Issues with Mesa 24.3.x and amdgpu Vega graphics

#258 2025-01-24 23:03:17

Re: Issues with Mesa 24.3.x and amdgpu Vega graphics

#259 2025-01-24 23:56:17

Re: Issues with Mesa 24.3.x and amdgpu Vega graphics

#260 2025-01-25 06:26:47

Re: Issues with Mesa 24.3.x and amdgpu Vega graphics

#261 2025-01-25 06:29:27

Re: Issues with Mesa 24.3.x and amdgpu Vega graphics

#262 2025-01-25 08:38:37

Re: Issues with Mesa 24.3.x and amdgpu Vega graphics

#263 2025-01-25 09:44:40

Re: Issues with Mesa 24.3.x and amdgpu Vega graphics

#264 2025-01-25 10:02:40

Re: Issues with Mesa 24.3.x and amdgpu Vega graphics

#265 2025-01-25 10:53:59

Re: Issues with Mesa 24.3.x and amdgpu Vega graphics

#266 2025-01-25 11:05:20

Re: Issues with Mesa 24.3.x and amdgpu Vega graphics

#267 2025-01-25 12:50:57

Re: Issues with Mesa 24.3.x and amdgpu Vega graphics

#268 2025-01-25 13:52:34

Re: Issues with Mesa 24.3.x and amdgpu Vega graphics

#269 2025-01-25 14:13:52

Re: Issues with Mesa 24.3.x and amdgpu Vega graphics

#270 2025-01-25 14:47:53

Re: Issues with Mesa 24.3.x and amdgpu Vega graphics

#271 2025-01-25 20:00:00

Re: Issues with Mesa 24.3.x and amdgpu Vega graphics

#272 2025-01-25 20:24:43

Re: Issues with Mesa 24.3.x and amdgpu Vega graphics

#273 2025-01-25 23:17:17

Re: Issues with Mesa 24.3.x and amdgpu Vega graphics

#274 2025-01-26 04:12:11

Re: Issues with Mesa 24.3.x and amdgpu Vega graphics

#275 2025-01-26 07:44:53

Re: Issues with Mesa 24.3.x and amdgpu Vega graphics

Board footer