This is related to #1816.

The problem is that the NVIDIA drivers cannot detect the presence of Minecraft when it is ran using Prism Launcher, which prevents certain optimizations from being applied. Furthermore, because these optimizations are now causing crashes in the recent drivers, we'll need to disable them outright, which means this issue will soon apply to all launchers.

We should try to figure out what these are, and make up for the difference by incorporating new patches into Sodium.

im having this issue too, i just upgraded my pc from an AMD build to one with an RTX 3070ti and sodium actively decreases my performance, even on prism launcher. it really sucks since i was so exited to get my new pc but am somehow getting worse performance in mc than my old one. is downgrading my gpu drivers a possible solution? or is that even something you can do or not?

@enzanki-ars The problem you are experiencing has nothing to do with this problem. We've had other user reports excessive time in GLFW.glfwPollEvents() and it's caused by buggy mouse drivers trying to force a 1000 Hz polling rate, notably the Razer Synapse software.

im having this issue too, i just upgraded my pc from an AMD build to one with an RTX 3070ti and sodium actively decreases my performance, even on prism launcher. it really sucks since i was so exited to get my new pc but am somehow getting worse performance in mc than my old one. is downgrading my gpu drivers a possible solution? or is that even something you can do or not?

Join the discord to find a dev jar that contains the fix or download from GitHub actions.

It seems like Threaded Optimization is the culprit of performance issues. This creates a second thread with a command queue which is used to actually perform the work of OpenGL commands. When you call any OpenGL function, it gets put into this work queue and processed asynchronously.

The problem is that any calls to glGet... will have to also be placed in the work queue, and the application thread will become blocked until the worker thread can process the command. For Minecraft, this creates significant slowdowns in shader binding, because it calls glGetUniformLocation for every single uniform, every time a draw call is performed.

Sodium also calls glGetInteger in some places in order to figure out what the current OpenGL state is, so that we can restore it back to what Minecraft was using. However, this seems unnecessary in MC 1.20, and we can more easily restore state without a glGetInteger call.

As to what the NVIDIA driver is doing, it's trying to detect the presence of Minecraft, and then it applies a specific workaround to make some of these calls cacheable and non-blocking. These workarounds are not the cause of the crashing, it only makes NVIDIA's "Threaded Optimization" actually usable.

So I'm not sure it makes sense to try and optimize these things, because we'll need to disable Threaded Optimization to fix the crashes, therefore these performance issues are not a problem any more.

I've written some patches for Minecraft/Sodium that eliminate these glGet... calls and it seems to make a minor improvement to performance even when Threaded Optimization is disabled, though we have only a few samples. More testing is needed to know for sure.

So the TLDR of the issue is thread racing causing lockouts?

It's probably something like that... maybe we're hitting a pathological case in their driver.

A user helped contribute some performance data (from a desktop computer with an Intel Core i5-10500T and NVIDIA GTX 1050 Ti), and we found the following with the current release of Sodium 0.4.10 for Minecraft 1.20.

Threaded Optimization is disabled: ~151 FPS avg (Spark profile, Screenshot]
Threaded Optimization is enabled (default): ~54 FPS avg (Spark profile, Screenshot).

Using the information from that, I tried to wrote some performance patches to try and mitigate the extreme slowness of the latest driver, but we only managed a minor success... These were the results:

Threaded Optimization is disabled: ~152 FPS avg (Spark profile, Screenshot]
Threaded Optimization is enabled (default): ~80 FPS avg (Spark profile, Screenshot).

Chances are good that I am misreading and misunderstanding the data, but isn't the disabled numbers swapped with the enabled?

@ColonelGerdauf There is no error. Enabling the setting for "Threaded Optimizations" causes a significant slowdown. The NVIDIA drivers attempt to do this automatically (and forcefully) when it detects Minecraft, but the detection doesn't work when an alternative launcher is being used.

Enabling "Threaded Optimizations" also causes the crashes described in #1816.

Oh... I thought there was something odd with how I understood the data.

Both of the use cases were with Sodium. Turned out that I was assuming vanilla settings and instances despite knowing as much.

This seems fixed in 8ae68cf, which prevents the driver from applying the "Threaded Optimization" setting which we observed made performance worse.

Sorry actually, as the more I look at that spark graph, the more I think this is unrelated to Minecraft/NVIDIA, and instead there is something going on with the GLFW.glfwPollEvents() call, which is unrelated to this issue I believe. I'll leave this here though incase I am wrong, as I continue to investigate the freezes I am experiencing.

Looking at the commit, the following is noted:

It is worth noting that this problem only affected the Vanilla
launcher, since the Fabric Installer chose to include a reference
to the Minecraft entry point on purpose so that the NVIDIA drivers
could continue detecting it. As far as we know, Prism Launcher does
not do this, hence it is not affected by the issue.

Yet, I believe that this might still be occurring. I am running Prism Launcher 7.1, and I have ensured "Threaded Optimization" is off in the NVIDIA Control Panel, both globally and for Java, and am running NVIDIA Driver 536.23. Attached are two videos of this issue, both in a 1.20.1 superflat creative peaceful seed 0 world, one unmodded, and one with the latest Fabric and Sodium releases:

Strangely, this only happened when the mouse is moved, which is why I focused on small mouse movements in both. This issue has also existed in 1.19.4. Not 100% sure if it's related to this issue, but it seems to be, and would sort of make sense.

After recording those two videos, I also loaded spark and ran a profiler, not sure if this helps: https://spark.lucko.me/iV2t3TURMy

Finally, I also ran it on the most recent commit (ab81959), only one after the referenced commit (8ae68cf), and not much improvement, if any there.

I can move this all to a new issue if desired, if this is not related to this performance issue.

I use the legacy Minecraft Launcher (to skip downloading from microsoft store) and can confirm. Upon reading this thread, I went straight to Nvidia Control Panel and disabled threaded optimization. I'm not necessarily getting more frames but they are infinitely more stable, no stuttering. I hadn't even noticed I wasn't getting expected performance. I don't know if performance has always been affected for me or if this is a recent development.