Game crashes when using NVIDIA drivers version 526.47 or later
Saxostevesaxo opened this issue · 107 comments
MODERATOR EDIT
NVIDIA drivers (version 526.47) are known to cause crashes with Sodium. We are applying a workaround to get around this problem, by tricking the drivers on what version of the game is running.
For more details, please read here, and consider sending a bug report to NVIDIA so that we might have a chance of getting this fixed.
The original issue as reported by Saxostevesaxo...
Version information
sodium-fabric-mc1.19.2-0.4.4+build.18
Reproduction Steps
- install NVIDIA Drivers version 526.47 issue date 27/10/2022 (using gtx 1650)
- load fabric with sodium installed
- when you go through a nether portal the game crashes/closes
- running fabric without sodium doesn't crash the game when going through a portal
- rolling back the driver and running sodium everything works fine.
Crash Report file
a crash report wasnt created, the game just closes
Additional information
nothing else to report
Someone else was able to confirm this today, which is probably a bad sign. The lack of a crash report indicates the JVM is crashing outside of Java code, which almost conclusively points to the NVIDIA drivers being broken.
Look for an hs_err_pid****.log file in the .minecraft folder or launcher directory. It might contain additional information about the crash, but chances are there is nothing we can do about it.
i have searched my whole disk drive for this file and i dont have one im afraid. good to know that others are having the same issue and not just me.
I just updated yesterday and had to do an hour of troubleshooting to find the mod causing the crash. I have confirmed the issue is related to sodium itself, nothing else.
The client log files do not provide any stacktraces or error logs, the game simple shuts down. I have attached a file that was mentioned in a comment above by @jellysquid3 below, maybe it can help
[MODERATOR EDIT: Removed sensitive information from log file.]
hs_err_pid8364.log
Note: If you are uploading hs_err_pid****.log files, please make sure to redact sensitive information from the log file. Notably, the command line arguments included in the log will contain a temporary access token for your account, which could allow people to login to other Minecraft servers with your account for a short while.
If you need help with this, please join the Discord server so that we can walk you through redacting the information. Do not upload these log files to other users until you have redacted the information.
Pinning this since we're seeing a lot of reports with the latest NVIDIA drivers.
My only recommendation to people right now is to downgrade to the last-working version of the NVIDIA driver. We unfortunately haven't been able to find a cause of the problem yet, but given that NVIDIA mentions in the changelog "improved Minecraft Java Edition performance", it's pretty obvious something has gone wrong on their end.
I can also confirm this is happening, just spent most of the morning and afternoon wondering why I can't use portals and decided to try my mods one by one and can also confirm that I did update my Nvidia drivers yesterday.
Note: If you are uploading
hs_err_pid****.logfiles, please make sure to redact sensitive information from the log file. Notably, the command line arguments included in the log will contain a temporary access token for your account, which could allow people to login to other Minecraft servers with your account for a short while.If you need help with this, please join the Discord server so that one of our staff members can walk you through that process. Do not upload these log files to other users until you have redacted the information.
Ok, I didn't know that. You didn't mention it above either - Thanks for the warning!
I'm getting this issue too, although it only happens with litematica installed as well as sodium. Also nvida graphics card with 526.47 drivers
Can confirm same as all other comments, however, this was caused on my side by Litematica only. Sodium works perfectly fine when installed alone with Lithium, and Starlight. When I add Litematica thats when the issues start. Downgrading fixes both, but weird that I only see it with Litematica.
edit: hs_err logs are just a garbled mess saying the jvm crashed outside the machine, which leads to an nvidia driver issue as described elsewhere.
Still broken with version 526.86 released today
EDIT:
[RTX 2080 SUPER]
only have issues with sodium + litematica
Having the same issues, when I travel between Dimensions. Updated to 526.86 and still having Issue. 2070 Super and Ryzen 7.
It's possible that we might have a developer who can look into this, with the right hardware to reproduce the problem. But I don't believe there's going to be any patch available from our side which can fix the issue in NVIDIA's drivers. The best we can do is try to submit a bug report upstream, and hope that users are able to generate enough noise on it.
I have simply downgraded my NVIDIA Driver, as suggested in this comment in a related issue thread.
This seems to have solved the problem for me, so it's at least a temporary solution to the Problem until it can be fully resolved on NVIDIAs side
saw in the release notes of the 526.98 driver that Older versions of Minecraft Java Edition show corruption on screen [3870232] is an open issue now... this might be related to the sodium crashes?
Also, i'm guessing 526.98 doesn't fix the sodium crashes, though i can't test it for now.
I don't think issue 3870232 on NVIDIA's side has anything to do with Sodium, rather it's a problem with particularly old versions of the game (i.e. Minecraft 1.8.9) which happens without any mods installed.
I just updated yesterday and had to do an hour of troubleshooting to find the mod causing the crash. I have confirmed the issue is related to sodium itself, nothing else. The client log files do not provide any stacktraces or error logs, the game simple shuts down. I have attached a file that was mentioned in a comment above by @jellysquid3 below, maybe it can help
[MODERATOR EDIT: Removed sensitive information from log file.] hs_err_pid8364.log
As I have stated before, for me at least, this has nothing to do with Litematica as removing it does not fix the issue. I have tested a fabric installation with ONLY fabricAPI and sodium installed, which still caused a graphics-related crash (which if I remember correct included a specific exit code, not just 1) to occur. This might be different depending on your computer and operating system exactly or maybe one of the newer versions of the NVIDIA Driver has caused this to change. Please try testing a clean fabric installation with only Sodium installed in this matter and say if it does or doesn‘t cause a crash to occur in that instance
GPU driver version 527.37
Minecraft 19.2
Hi I have the same problem when I enter the nether portal the game crash with exit cod 1
temporally fix for it remove Litematica mod.
I think the problem happened when Nvidia updated the drivers they changed something that made sodium and Litematica crash. it is maybe something between the 2 mods is broken.
this problem can be fixed if @jellysquid3 and Litematica dev looked into it together and see what went wrong
For those who use version 526.47 and newer, Launch Minecraft with Vanilla launcher, Sodium, and Litematica simultaneously
Open NVIDIA Control Panel > Manage 3D settings > Program Settings > Select Minecraft (net.minecraft.client.main.main), and Change Threaded optimization to Auto or Off.
It should stop crashing when you teleport to another dimension or reload all chunks.
In 522.25, The default value is Auto, but even after changing it to On, It seemed won't crash.
Open NVIDIA Control Panel > Manage 3D settings > Program Settings > Select Minecraft (net.minecraft.client.main.main), and Change Threaded optimization to Auto or Off.
Only Off works for me - seems like a viable workaround to me for now though
Edit: (RTX 2080 Super, 527.56)
Just popping in to let people know, when i first encountered the problem and diagnosed it, i reached out to nvidia helpdesk, and they are aware of the problem and working on a fix. Ive had 3 driver updates since and they all havent fixed the issue for me, but at least they are aware of it.
Also, when i just copy all my mods over to AT launcher, it magicly just works, even though its the exact same mod setup. Weird xd
Also, when i just copy all my mods over to AT launcher, it magicly just works, even though its the exact same mod setup.
Could the issue be some kind of interaction with MultiMC, specifically the -XX:HeapDumpPath=MojangTricksIntelDriversForPerformance_javaw.exe_minecraft.exe.heapdump argument?
Unfortunately, we still don't have a solution for this. We had some developers with a RTX 2000/3000 series GPU, but their time is very limited, and they haven't been able to reproduce the problem.
In the past we've had very bad luck with trying to get driver vendors to fix regressions or other issues. We can try to write emails and tell them there's a problem, but at our team's size they will only be ignored. Even on rare occasion that we can find a contact who knows the right people, we haven't been able to get resolutions.
If you are affected by this problem, your only option is to contact NVIDIA to make them aware of this issue (provide a link to this issue), and downgrade to driver version 522.25.
Weather update: It seems you can also work around this by not using the vanilla launcher. Prism Launcher for example has no issues.
I think what's going on here is that the newer NVIDIA drivers try to detect whether the application is Minecraft so that it can apply some optimization, and it doesn't detect anything other than the vanilla launcher.
We were also able to reproduce it after switching launchers, though we still don't know why the crash is happening. For some reason it appears the NVIDIA driver is trying to call into the Vulkan ICD (nvoglv64!vk_icdNegotiateLoaderICDInterfaceVersion) and crashes.
I just want to be clear that literally the only thing we did was change the window title of the game.
That's it. There's nothing else.
wait, since you said so, anyone with a mod that could change the window title is considerable fixed the problem? Just like this?
they haven't been able to reproduce the problem
Are they using a combination of Litematica and Sodium? It works 100% of the time when you use these together.
My working theory is that NVIDIA tried to "optimize" something related to surface presentation, and that some issue occurs in their driver when the renderer gets reloaded (such as when teleporting dimensions). We noticed that the crashes without Litematica have a pretty consistent theme where rendering related to the entity outline buffer (i.e. for spectral arrows) will cause crashes.
What's more interesting about this crash related to the framebuffer is that it ends up with the NVIDIA driver trying to call into the Vulkan ICD from an OpenGL application.
We've seen modifications for Minecraft and other OpenGL games where the surface presentation is modified to use Vulkan or DirectX 11 to get around performance issues in OpenGL drivers. It would not be surprising if NVIDIA did something similar for Minecraft, hence why we see the call to Vulkan in code surrounding the framebuffer.
With Litematica, we've seen different crashes, and it's not clear what's going on. They may be the same issue, but we can only work with one problem right now, and dealing with Sodium standalone is the first place to start.
From what we know of the driver revision history:
Driver 526.47 fixed "[RTX 30 series] Lower performance in Minecraft Java Edition [3702953]"
Driver 526.98 opened issue "Older versions of Minecraft Java Edition show corruption on screen [3870232]"
Driver 527.56 fixed "Older versions of Minecraft Java Edition show corruption on screen [3870232]"
It's been broken since driver 526.47. The on-screen corruption they reported in 526.98 is a bug we've seen when trying to modify the surface presentation code in Sodium, or when people try to apply the aforementioned DX/VK patches to their game. This does not look good.
The Litematica issue has been confirmed by us to have a different cause.
apologies then, just assumed they were the same. Since my game has never crashed on the latest drivers without litematica.
as for the NVIDIA calling the Vulkan stuff, is it possible to just prevent NVIDIA calling that with sodium?
If you are affected by this issue, please try this build of Sodium.
No idea if it'll work. But worth a shot.
If you are affected by this issue, please try this build of Sodium.
No idea if it'll work. But worth a shot.
will try
Asked my friend on GTX1650 with 527.56 driver version and ran fine
Video: https://streamable.com/buxjpu
Log: 2022-12-13-1.log
If you are affected by this issue, please try this build of Sodium.
No idea if it'll work. But worth a shot.
seems to have fixed, thanks
I just want to be clear that literally the only thing we did was change the window title of the game.
That's it. There's nothing else.
I just want to be clear that literally the only thing we did was change the window title of the game.
That's it. There's nothing else.
Is this just tricking NVIDIA lol??
also, would we be able to get a 1.19.2 version as that is where the original problem occurred?
If you are affected by this issue, please try this build of Sodium.
This does appear to work alongside litematica (yes I'm aware they might be separate), however as my previous comment suggested, a 1.19.2 might have different results
So long as you hide the version number from the title, it should work. NVIDIA appears to parse the window title and it looks for a specific version.
We'll publish new releases of Sodium here soon (likely tomorrow) with the workaround. It will include a pop-up message on first launch which looks like this.
After the game restarts, the window title will be changed, and it should stop the crashes.
Unfortunately it is probably going to cause performance regressions since NVIDIA is probably relying on being able to detect Minecraft to improve performance. We can't do anything about that. We can only hope that with enough user reports to NVIDIA, that they will fix the issue.
If you are a user...
You should report this issue to NVIDIA (click here). The more noise we can make, the better. Please make sure you provide a link to this issue so that they have a way to find more information and/or get in contact with us.
Relevant details you'll need to fill out your bug report:
Regression: Issue started happening after upgrading NVIDIA driver
API: OpenGL
Screen Mode: Happens in both exclusive full screen and window/borderless windowed
Description: The game crashes after a while, or when teleporting dimensions. A bug report exists here.
Steps to reproduce: Use the official Minecraft launcher, install version 0.14.11 of Fabric Loader for Minecraft 1.19.3, and install version 0.4.6 of Sodium into the mods directory. Open the game, create a new world, and press F3+A to reload the render (simulate a player action). The game should crash after a few attempts.
Frequency: Frequently
We still don't know exactly what the issue is. The leading theory is that NVIDIA is trying to modify the surface presentation behavior to "improve performance" and is severely breaking the game in the process. We are seeing crashes in other mods like Litematica as well, and apparently this was crashing older versions like Minecraft 1.8.9.
Seemingly, they are aware of this problem, because they special cased the driver to not apply the optimization if an older version of Minecraft is being used. This is how Sodium gets around the problem, by hiding the version information from the driver.
However, this is less than ideal, and we really need a fix from NVIDIA here, especially so that users can take advantage of any driver optimizations NVIDIA can provide.
So long as you hide the version number from the title, it should work. NVIDIA appears to parse the window title and it looks for a specific version.
Not really, just don't have the Minecraft* (version) as the title
The Litematica issue has been confirmed by us to have a different cause.
@IMS212 can you drop your wisdom in the Litematica bug discussion? We'd really appreciate it so we can fix it :)
Thank you to those who submitted a driver feedback. I have filed a bug so that our team can look into this issue.
Manuel
NVIDIA Forums Rep
Open NVIDIA Control Panel > Manage 3D settings > Program Settings > Select Minecraft (net.minecraft.client.main.main), and Change Threaded optimization to Auto or Off.
Worked on RTX3050 with GraalVM Enteprise Edition, thanks
setting threaded optimization to auto stopped the crashing but started capping my fps at 60. any way around this?
just made an account for this.
changing threaded optimization to auto worked halfway for me. before, it wouldn't launch with sodium or litematica. after changing the setting, it would launch with sodium, and the previous behavior of going through portals wouldn't break it anymore. however, it still wouldn't even launch with litematica
i found a separate fix for this through a discord server: https://www.curseforge.com/minecraft/mc-mods/litematica/files/4259738 is an updated iteration of the 1.19 version of litematica (i play 1.19) and using this new iteration of the 1.19 version of litematica worked for me. I can now launch the game with litematica again, and go through portals, and game won't crash. everything seems normal again.
also, one tiny detail that may have helped but I can't be sure, I updated my java on my computer to the latest version too before doing all this. it didn't fix the issue on its own, but I'm not sure it didn't contribute to everything else working on top of it.
Announcement from masa:
Litematica got some bug fixes for Christmas 🎄 🎁
Most notably there is a fix for the crash with recent AMD and nVidia GPU drivers that has been a very common issue people have been experiencing lately.
-> Parts of the renderer and the placement manager were rewritten to drastically reduce the number of VBOs the mod allocates, and also the allocation is now lazy and they won't all get allocated immediately on renderer load/reload. The recent drivers now for some reason have a new(?) certain limit for the number of allocated buffers, after which everything breaks or the game just crashes immediately.
The 1.18.2 and 1.19.0 versions also have a bunch of the newer commits from the 1.19.2+ branch cherry-picked in (see the changelog on the files on CF).
The new versions are:
1.18.2-0.11.5 https://www.curseforge.com/minecraft/mc-mods/litematica/files/4259736
1.19.0-0.12.1 https://www.curseforge.com/minecraft/mc-mods/litematica/files/4259738
1.19.2-0.12.6 https://www.curseforge.com/minecraft/mc-mods/litematica/files/4259743
1.19.3-0.13.1 https://www.curseforge.com/minecraft/mc-mods/litematica/files/4259746
christ this bug is bigger then I thought. ive personally seen complaints from people who use litematica having this issue, never thought it was this.. bad.
I had this problem, which I posted about in the Discord (https://discord.com/channels/602796788608401408/1042489493074231386/1047428971417051136). Based on what others were saying, I backloaded the NVidia driver I had before the problem started and the problem went away.
I am getting the notification that my version of the driver is affected by the bug and the remediation is being applied. But my version predates the problem version listed. (using v512.15) There appears to be an issue with the detection of the NVidia version used. Is there any issue I need to worry about here? No worries if it's just a cosmetic issue and nothing will be different.
I have been having Heap memory crashes that just started when I updated everything to the 1.19.3 versions 2 days ago, so I was hoping this update is addressing that. I haven't ever had a Heap memory crash so I'm fairly certain something in this new batch of updates is the cause.
I just updated yesterday and had to do an hour of troubleshooting to find the mod causing the crash. I have confirmed the issue is related to sodium itself, nothing else. The client log files do not provide any stacktraces or error logs, the game simple shuts down. I have attached a file that was mentioned in a comment above by @jellysquid3 below, maybe it can help
[MODERATOR EDIT: Removed sensitive information from log file.] hs_err_pid8364.log
I literally only updated my driver because it was outdated with Adobe Premiere Pro and now i cant use sodium wtf 😭😭😭
This is weird. I didn't have any crashes using Sodium 0.4.6, though my NVIDIA driver version is 527.56 (Studio Driver) and when using 0.4.7 it warns me about the crash workaround. Is it only for the Game Ready driver or is it fixed already?
Is there any way to turn off the workaround so that I can test the setting change in the NVIDIA driver that other's have posted? I've tried:
"workarounds": {
"issue1486_hide_window_title_to_evade_nvidia_drivers": false
}
but then the workaround runs again and changes this setting back to true. I tried making the file read-only but that cause a crash.
@djlawler There is no way to disable it. You can compile from source and stub out this line in DriverWorkarounds if you need to.
We didn't implement a driver version check since it largely did not matter. We cannot reliably detect whether a user will encounter this problem even if we know their driver version. Many people we've tried to have reproduce this problem cannot do so with the newer drivers.
So ultimately, the difference was either 60% of users (w/o driver checks) or 50% of users (w/ driver checks) receiving an unnecessary warning.
The reality here is that, yes, the warning screen is obnoxious, loud, and is going to be shown to a lot of people who may have never experienced the problem. But we don't have any other options here. Nobody's been able to find a clear cause to these problems, and we still don't have comment/resolution from NVIDIA.
And yes, the popup is necessary. We can only detect the OpenGL driver once it's been loaded into the process, and the NVIDIA driver changes the behavior if it detects a certain window title during OpenGL initialization, so we can't change the title after the window has appeared.
Additionally, since other drivers may be relying on detecting a Java.exe window titled with "Minecraft", we cannot just hide the window title during early init, and change it later to the real thing. We still need to detect the driver to prevent breaking other vendor's optimizations for Minecraft.
Understood! I just dropped back to sodium-fabric-mc1.19.3-0.4.6+build.20.jar and will see if the NVIDIA settings change works (or not). Thanks!
My game crashed and redirected me here. I'm using a GT 620 with these drivers:
Version: | 391.35 WHQL
please fix i need my Minecraft villager torture
Even with the version hidden from the driver, the game does not launch with sodium 0.4.7 and iris 1.5 together. Sodium 0.4.6 had no problems with iris 1.4.6, and sodium 0.4.7 launches fine without iris, but as soon as I put iris 1.5 in the mods folder, shit hits the fan and my computer starts freezing with java and even sometimes task manager going unresponsive
Nvidia 527.56
Quilt Loader 0.18.1 beta 25
game crashed just after a second of loading it (no singleplayer) and i got redirected to here
fabric sodium 0.4.7 this happened after just instaling iris 1.5
the game exiting with a funny little info message box telling me something that i didnt read
NVIDIA GeForce 527.56 <- released on 12/08/2022
Fabric 0.14.11
I'm locking this issue. The problems people are reporting in this thread has nothing to do with the problem at hand, and I think people are just posting here because it's what opened in their web browser.
If you are experiencing crashes or other issues only with Iris installed then you need to report the problem to them. This is not a general bug ticket.
If anyone has more information on the actual problem at hand or someone from NVIDIA needs to get in contact with us, please join our Discord server (see the #dev-sodium channel) or write me an email.
If the game randomly closed without a message and sent you to this page, just restart your game. It is fine.
Apparently, there is a bug with the TinyFileDialogs library we are using. The dialog box you are supposed to see does not open correctly, and the game immediately closes instead while directing the user to this page. It's probably a race condition of some sort, but we really don't want to debug this library.
As a result, we will have to implement an in-game screen to get around this. That means users will have to wait for the game to finish loading just so that they can restart it. But we don't have any easier way to present a message to the user, and suddenly closing the game without a word is just going to make users think their game crashed.
This is officially the dumbest bug we've ever encountered or tried to work around.
Everything has gone wrong.
We made a mistake building computers.
We released Sodium 0.4.8 which improves the driver detection and manages to workaround the problem without the need for a pop-up window or game restart. It's much more complicated under the hood and took a lot of time to get right, but it's less annoying for users now.
However, it does not change which users will receive this workaround, and you still cannot disable the workaround via the in-game settings. If you must disable it for whatever reason, which we really don't encourage you to do, you can modify the sodium-mixins.properties file in your config directory, and add the following line.
mixin.workarounds.issue1486=false
Seems the issue still occurs even with this added to my config.
crashing upon launch.
nvidia driver 528.02
We released Sodium 0.4.8 which improves the driver detection and manages to workaround the problem without the need for a pop-up window or game restart. It's much more complicated under the hood and took a lot of time to get right, but it's less annoying for users now.
However, it does not change which users will receive this workaround, and you still cannot disable the workaround via the in-game settings. If you must disable it for whatever reason, which we really don't encourage you to do, you can modify the sodium-mixins.properties file in your config directory, and add the following line.
mixin.workarounds.issue1486=false
Seems the issue still occurs even with this added to my config. crashing upon launch. nvidia driver 528.02
We released Sodium 0.4.8 which improves the driver detection and manages to workaround the problem without the need for a pop-up window or game restart. It's much more complicated under the hood and took a lot of time to get right, but it's less annoying for users now.
However, it does not change which users will receive this workaround, and you still cannot disable the workaround via the in-game settings. If you must disable it for whatever reason, which we really don't encourage you to do, you can modify the sodium-mixins.properties file in your config directory, and add the following line.
mixin.workarounds.issue1486=false
You've read that wrong, adding that to the config DISABLES the workaround, of course it's still crashing then.
tl-logger10926384111760627165.txt
Drivers 528.24 have been released, the problem is still not solved. If you redraw chunks, the game crashes. The old drivers didn't have this error.
Still have issues with NVIDIA 528.49 & Sodium 0.4.9. Additionally, whatever changes were made in 0.4.7 and up appears to cause other mods (JsModules) to fail to render objects (such as boxes created with Draw3D). Works fine under v0.4.6
appears to cause other mods
Dont know if this is related, but using a free cam mod while streaming minecraft on discord causes the game to crash when leaving free cam
Doesn't happen as of the latest Nvidia drivers on Windows.
I added mixin.workarounds=false to sodium-mixins.properties and it fixed it, and I can confirm the workarounds were disabled
[16:19:35] [main/WARN]: Force-disabling mixin 'workarounds.MixinRenderSystem' as rule 'mixin.workarounds' (added by user configuration) disables it and children
[16:19:35] [main/WARN]: Force-disabling mixin 'workarounds.issue1486.MixinMinecraftClient' as rule 'mixin.workarounds' (added by user configuration) disables it and children```
No issue on 531.18 however, only Fabric and Sodium was installed and ran together
Will test using my usual Modpack choices, on 1.19.3 with the latest drivers. and workaround disabled. Will edit post with results.
EDIT: 11:43am 01/03/23: Seems the issue is fixed, I can also confirm the latest nvidia driver works as expected with Sodium and the workaround disabled. Not yet tested with Litematica but i'd also assume its fine there. Mentioning @jellysquid3 so he's aware.
Log File to show it successfully loads / Runs as expected, as well as showing I have the Mixin disabled: https://pastebin.com/NU4eiP0k
Not sure why it says enabled when just above it force disables it, but sure. I see 1.19.3 in Window, and its not applying the fix.
Will test using my usual Modpack choices, on 1.19.3 with the latest drivers. and workaround disabled. Will edit post with results.
EDIT: 11:43am 01/03/23: Seems the issue is fixed, I can also confirm the latest nvidia driver works as expected with Sodium and the workaround disabled. Not yet tested with Litematica but i'd also assume its fine there. Mentioning @jellysquid3 so he's aware.
Log File to show it successfully loads / Runs as expected, as well as showing I have the Mixin disabled: https://pastebin.com/NU4eiP0k
Not sure why it says enabled when just above it force disables it, but sure. I see 1.19.3 in Window, and its not applying the fix.
Can also confirm that the latest driver 531.18 also fixes the crashing problem for the 1.19.2 versions of Sodium when switching dimensions.
I'm still getting the occasional crash when going through portals, Exit Code 1, even with the 531.18 drivers and workaround disabled. I am running Litematica though.
To clarify some things, we believe this issue still exists in the latest NVIDIA driver (version 531.18).
If you are experiencing crashes with the workaround enabled (which is the default in Sodium version 0.4.8 and later) then it probably has nothing to do with this bug report. Try updating Litematica (if installed), since it seems to cause crashes that look very similar to this.
If you are experiencing crashes with the workaround disabled (which requires you to edit the config file manually) then that is expected, because the bug in NVIDIA's driver has still not been fixed. You really shouldn't disable the workaround unless you are absolutely certain your system is not affected by the bug, which is not exactly easy to test for.
Unfortunately, we've heard of nothing from NVIDIA regarding whether or not this issue is being worked on. And if I'm being entirely honest, I do not think NVIDIA is going to fix the issue either. Trying to detect the presence of Sodium (or other mods) is difficult, and it is extremely unlikely they're going to revert the problematic optimization when it benefits the audience they actually care about.
In other words, users with a NVIDIA GPU (especially on muxless laptops) are just going to experience sub-optimal performance with Sodium installed, and the burden of fixing this lands squarely on NVIDIA.
Does this workaround have an external config? I have an nvidia card and I was wondering if I could try it with and without the work around. I've noticed that with the work around, my system seems to use a lot more CPU/GPU.
My two cents: it will be a lot more likely for NVidia to take the bug seriously once you pin down what the bug actually is, as you can explain how the bug is potentially problematic outside the scope of Sodium.
When you just say that "there is this bug that is specifically affecting one or two mods in a game of Minecraft", that is something that the company will ignore. Not necessarily due to the perceived lack of importance of the mod, but due to how little information (that they would need) is provided in the bug report.
Personally, this feels less like a bug (as it appears to be understood here) and more of an unfortunate conflict of calls.
When something significant changes in how a program or game operates, that introduces a chaotic possibility of erratic bugs. This is not solely up to specific drivers; that is just the reality of doing things outside of established norms.
I am not attacking your choice of doing things; it is something to be aware of.
That is frankly a needlessly cynical way to look at this.
Especially "breaking established specifications". There is this thing about real world development; there is only a point where these so called specifications are followed by programmers and coders, in the bigger picture. And it is interesting that you bring up OpenGL and Vulkan, as both of the languages are rife with technical problems and bruh design decisions when left to the by-the-books implementations. For instance, Vulkan's implementation of HDR leaves a lot to be desired. There is a reason why a vast majority of OpenGL products (including Minecraft) implement seemingly strange hacks like using Vulkan ICD which is quite commonplace on its own.
What NVidia is doing is not breaking specifications, per se. What they do is that they follow along with games as they are implemented and work around that.
Going by-the-books does not exactly ensure compatibility, as far as drivers go.
We provided information about what we know. The problem is with the NVIDIA drivers changing how image presentation works, and for some reason that causes crashes on what appears to be any draw call once a world reload has happened. Something is immediately putting the driver into an invalid state when that happens (maybe because the framebuffer objects get re-created?) and we can't really debug it further.
NVIDIA is aware of this issue, and I believe there is enough evidence to say they know exactly what the problem is, because older versions of Minecraft are affected by a similar bug, and they went out of their way to blacklist those versions from receiving the problematic optimization. This is why Sodium can work around the problem: we're just lying to the drivers about what version is actually running.
To be expressly clear, we did work for weeks on trying to figure out what the problem is. The issue is that I don't own any NVIDIA hardware, nor a computer with a spare slot for a PCI-e GPU. Furthermore, NVIDIA's terms of service strictly forbids me from trying to reverse engineer the problem at hand here, and I'd rather not burn whatever working relationship we do have trying to figure it out.
Who's "fault" this problem is largely does not matter to me. It's just that we don't have the people with the skills or time to be trying to fix this problem. It is NVIDIA's responsibility to ensure software is compatible with their drivers, and we have gone out of our way to both diagnose the issue and report it to them.
@ColonelGerdauf bad take.
You don't understand the nature of what happened and what Nvidia does.
Nvidia often implements "game specific optimizations" to improve performance in popular games in an attempt to get ahead of the competition and better utilize their hardware.
Unfortunately, these game specific "optimizations" aren't really optimizations at all. They are Nvidia systematically breaking established specifications (opengl, vulkan, etc) for specific games of specific versions in ways that improve performance and does not break the game in their testing.
This is where the trouble starts. Nvidia added one such "game specific optimization" in their driver to Minecraft in version 526.47 and made a note of it in their driver release notes. Nvidia knows exactly what functions they changed, we don't and are not the people to tell them. Nvidia's job is simple here, actually run sodium with and without their optimization enabled and debug their driver.
Furthermore, NVIDIA's terms of service strictly forbids me from trying to reverse engineer the problem at hand here
Just wanted to correct this misinterpretation of the license. License states:
you may not: ...
(b) decompile, reverse engineer, or disassemble software Materials except and only to the extent permitted by applicable law or unless specifically licensed to do otherwise by NVIDIA in writing or as allowed by any license terms which accompany or are provided with individual Materials
This is common clause in many pieces of software and the "applicable law" statement is key. In both the EU and USA decompilation/reverse engineering have already been tried in court and the precident has been set as being legal and permitted. The EU goes further to make it explicit that decompilation for the purpose of ensuring interoperability of software is legal (exactly what you would intend to do here). So yes, there is no debate on the legality of decompilation/reverse engineering the Nvidia GPU drivers for the purpose of game development. It is fully legal and not a breach TOS because of so.
jellysquid3's further points stand ofc and plenty enough information has been provided and communicated to Nvidia for them to fix the problem on their side.
In case you didn't read it, the reason for saying that was because I didn't want to burn anyone over at NVIDIA, not that I particularly find such a clause legally enforceable.
I don't expect Nvidia to be offended by you exercising what their license allows you to do.
Regardless, is there a filed bug report at https://forums.developer.nvidia.com/c/gaming-and-visualization-technologies/general-topics/drivers/175? @pidge2k did you create a forum topic somewhere on the Nvidia forum for this issue or only an internal bug report? If only an internal bug report, please write the internal bug report number so that it can be tracked easier across support forums.