A fix is merged now.
Your GPU is a RTX 4090, mine is a RTX 5070 Ti… Just saying.
Also, do you experience low idle GPU clock speed when the driver is set for Performance mode ?
I won’t be surprised if the corrupted mesh issue was related to a modified boost algorithm, or modified VFT curves, or perhaps even modified clock stretching algorithm (though, I’d expect the latter to be wired logic, not software controlled). Such corruptions can be seen when you push the GPU frequency too high (at which point there are calculation errors happening, which corrupts vertices coordinates) , however my GPU doesn’t boost higher with v580 than it does with v575, and even at stock clock speed (no OC on GPU neither VRAM), I’m still seeing the corruptions with v580.
In the very first v580 beta release (580.65.06), there’s a line in the release notes that might be related with boost algorithm changes:
Updated GPU clock value reporting in nvidia-settings, NVML, and nvidia-smi to show clocks before thermal and idle slowdowns for better consistency with the equivalent functionality on Windows.
Also, that first beta release was terrible and the mesh corruptions were happening almost instantly, while they happen after several minutes in newer v580 releases…
Could you guys maybe release a patch that allows 575 to be compiled with the 6.17 kernel? It’s pretty clear that 580 is DoA and proves that vibecoding gpu drivers does not work. How many human work hours have gone into fixing the mess that a few dozen hours of vibecoding caused with the 580 driver?
Thank you to all of the developers for your stellar work, up until the 580 driver. :)
Here you go: patch for Linux 6.17 and 575.64.05 GPL modules
My thankfulness is unlimited!
It didn’t work for me, but at least it’s better than nothing :)
You probably did not apply it properly. I can assure you it does work for me.
I too am using 580.105.08, on Fedora 42 with DE: GNOME 48.6 WM: Mutter (X11), and have not experienced corrupted meshes while using Cool VL Viewer. My HW is: CPU: AMD Ryzen 7 3700X (16) @ 4.43 GHz GPU: NVIDIA GeForce GTX 1080 Ti [Discrete]. I also have the viewer’s frame limiter set to 60hz because my card can’t drive more than that on my new ‘big monitor’.
A few years ago (before 580), I did see what looked like some meshes’ vertexes suddenly ‘pushing out passed their normal positions’. This looked similar to dinosaur’s screen cap…but not quite. More like someone pinched and pulled a vertex to distort the mesh item. I attributed that behavior to a bad meshes as I haven’t seen in a very long time.
Yup, did something wrong. Seems to work now. Thank you very much!
That’s got nothing to do with nVidia.
It’s purely a Mesa/RADV issue. Did you bother to read the bug report?
Again, not a RTX 5070 Ti like in my case…
This is likely a hardware-specific bug.
The bug was discovered using mesa/radv yes, but the validation error was purely a bug in GTK. Other drivers just haven’t “hit” that bug yet (unless Nvidia did back when GTK apps crashed, who knows).
RADV implemented a workaround for it, waiting for the GTK fix to hit mainstream, the bug wasn’t in RADV.
The Vulkan validation errors should occur using any driver, hence the change on the GTK side as well.
The GPU reset issue was specific to the open source RADV AMD driver.
Can you reproduce a GPU reset with the STR in the OP of the report using the nVidia driver? I cannot.
It was the way RADV code did things that caused the bug to be visible, it’s all described in the GTK MR. Nvidia might have patched it too (remeber the gtk crashes in the first beta release?).
Speculating that an issue affecting different hardware/driver may have potentially been preemptively mitigated by a previous nVidia’s driver fix is wild.
Also a moot point as this implies it’s already fixed. Why even mention this here?
If you are able to reproduce the issue, please do capture and submit an nVidia bug report.
For reference, here are two GTK4-related crashes that were indeed known and fixed nVidia driver issues:
I never did, I said this…
This is referred to as FUD.
Yeah it was speculation or a theory. Since when is that so bad? I honestly don’t get it.
There’s certainly nothing inherently wrong or ‘bad’ with either.
My sole point is there is no reason to suggest an issue not known to affect nVidia users on the nVidia forum.
Nitpick-ey perhaps, but these and other support forums are often filled with misinformation and conjecture.
Troubleshooting is always welcome. Nothing personal.
Also, do you experience low idle GPU clock speed when the driver is set for Performance mode ?
This is a long standing bug with PowerMizer. Nvidia has been made aware of it but like many other bugs, they ignore the bug report. Now the NVML APIs requires the app changing PowerMizer to be open.
In the very first v580 beta release (580.65.06), there’s a line in the release notes that might be related with boost algorithm changes:
No, it’s just what the API reports and it isn’t even clear what they did. If clock values were now being reported “before idle slowdowns”, they would show at minimum base clocks 24/7. They don’t. I’m not sure if Nvidia’s own employees know what they changed.
I won’t be surprised if the corrupted mesh issue was related to a modified boost algorithm, or modified VFT curves, or perhaps even modified clock stretching algorithm (though, I’d expect the latter to be wired logic, not software controlled). Such corruptions can be seen when you push the GPU frequency too high (at which point there are calculation errors happening, which corrupts vertices coordinates) , however my GPU doesn’t boost higher with v580 than it does with v575, and even at stock clock speed (no OC on GPU neither VRAM), I’m still seeing the corruptions with v580.
The GPU clock reported is not the “effective” clock. And there are about a dozen different clocks on any given GPU.
(Not the full list and GPC = Graphics Clock.)
With the 580.105.08, this is still an issue but unplugging the DP cable and plugging it back no longer works. I had to do a hard reset to get it to it to detect again.