Hi,
I've been fiddling around trying to debug this for the last couple of weeks and have run out of ideas. I'm just throwing it out here to see if anyone else has encountered anything similar or has any ideas.
A few weeks ago, I upgraded my graphics card from a GTX 260* to a GTX 1060 (given to me by a friend, otherwise it would have been a Radeon). Having updated the drivers to get the card working, the frame rate in the Sevtech Ages modpack I've been playing through for some months tanked from a very playable 35-ish average to a 1-2fps slide-show. Other things seem to work fine (my first thought was that 3D acceleration was broken for some reason) - I've been able to max out everything in X-Plane 10, whereas it was close to minimum before, for example.
(Example screenshots, via Google Drive, from last week, having cloned my root FS to a spare hard drive and rolled back the drivers: GTX 260 and GTX 1060)
For the GTX 260, I'm using a patched nvidia-{drivers,kmod}-340.108 from the nvidia-legacy overlay (https://gitlab.com/shibotto/nvidia-legacy.git) plus extra patches for kernel 6.6 compatibility obtained from Arch (https://aur.archlinux.org/packages/nvidia-340xx-dkms) and the libGL patchelf hack described here.
For the GTX 1060, I started off with nvidia-drivers-535.113.01 then updated to 545.x following ~amd64.
I'm at the point now of considering things like putting both cards into the system and either dual-booting or passing the 260 through to a dedicated VM just so I can get my fix of Minecraft a bit more easily than having to dismantle the PC and swap cards and drives!
So, any suggestions?
Thanks,
Stephen
* Actually, it's a bit more complicated than this - I had a 460 in this PC and a 260 in my old PC at my parents' house; I moved the 460 down and recovered the 260 which I then put into this system to test after discovering the problem with Minecraft.
[SOLVED] Minecraft low fps with new GPU
Message
[SOLVED] Minecraft low fps with new GPU
Last edited by molletts on Wed Dec 20, 2023 1:12 pm, edited 1 time in total.
Having had a bit more time over the last few days to really get stuck into this, I've just cracked it.
tl;dr: Disable Foamfix's texture patches in the mod's config file.
It seems to be down to either some kind of odd interaction between the newer NVIDIA drivers and the texture-related optimisations in the Foamfix mod or some oddity in the drivers' handling of texture spilling (which shouldn't be happening anyway as I'm nowhere near filling the video RAM).
Profiling showed that 95% of the game's time was spent in the "tick" code, and 90% of that time was spent on texture handling. I had also noticed that the PCIe bus utilisation was constantly at 4-5% on the GTX 1060, whereas it was almost always 0% on the GTX 260. Knowing how sub-optimally Minecraft handles animated textures, I went into video settings and turned off all animations. Bus utilisation dropped to zero and the frame rate immediately went back to a sensible value, confirming my hypothesis that animated texture uploads were to blame.
Knowing that Foamfix and Optifine both include texture-related optimisations, I initially tried turning off Optifine's smart animated textures in video settings, which didn't restore the frame-rate but, interestingly, caused the bus utilisation to drop to 3% - the opposite of what I'd expected. I then disabled Foamfix and found that it did, indeed, resolve the issue. I re-enabled it but disabled its texture optimisation in its config file; the framerate stayed high.
It's an interesting problem because, as I understand it, the Foamfix faster animated texture optimisation is supposed to eliminate texture uploads for animated textures by uploading them once then flipping frames rather than uploading a fresh set of textures on every tick. Optifine's smart animated textures optimises the default behaviour by only uploading those textures which are currently in use (probably a very small subset in big modpack like Sevtech Ages), which is why I expected that disabling it would increase bus utilisation. I found that increasing the value for the maximum number of cacheable frames in Foamfix's config caused the bus usage to increase (the opposite of what should happen as long as spilling doesn't occur) and simply turning the faster animation option off had no effect while forcing it to "always on" made the problem worse, although the logs indicate that it's being used when it's left on automatic, so there's something else in play too.
Maybe sometime when I'm feeling brainier I'll dig really deep and try to work out exactly what's going on.
tl;dr: Disable Foamfix's texture patches in the mod's config file.
It seems to be down to either some kind of odd interaction between the newer NVIDIA drivers and the texture-related optimisations in the Foamfix mod or some oddity in the drivers' handling of texture spilling (which shouldn't be happening anyway as I'm nowhere near filling the video RAM).
Profiling showed that 95% of the game's time was spent in the "tick" code, and 90% of that time was spent on texture handling. I had also noticed that the PCIe bus utilisation was constantly at 4-5% on the GTX 1060, whereas it was almost always 0% on the GTX 260. Knowing how sub-optimally Minecraft handles animated textures, I went into video settings and turned off all animations. Bus utilisation dropped to zero and the frame rate immediately went back to a sensible value, confirming my hypothesis that animated texture uploads were to blame.
Knowing that Foamfix and Optifine both include texture-related optimisations, I initially tried turning off Optifine's smart animated textures in video settings, which didn't restore the frame-rate but, interestingly, caused the bus utilisation to drop to 3% - the opposite of what I'd expected. I then disabled Foamfix and found that it did, indeed, resolve the issue. I re-enabled it but disabled its texture optimisation in its config file; the framerate stayed high.
It's an interesting problem because, as I understand it, the Foamfix faster animated texture optimisation is supposed to eliminate texture uploads for animated textures by uploading them once then flipping frames rather than uploading a fresh set of textures on every tick. Optifine's smart animated textures optimises the default behaviour by only uploading those textures which are currently in use (probably a very small subset in big modpack like Sevtech Ages), which is why I expected that disabling it would increase bus utilisation. I found that increasing the value for the maximum number of cacheable frames in Foamfix's config caused the bus usage to increase (the opposite of what should happen as long as spilling doesn't occur) and simply turning the faster animation option off had no effect while forcing it to "always on" made the problem worse, although the logs indicate that it's being used when it's left on automatic, so there's something else in play too.
Maybe sometime when I'm feeling brainier I'll dig really deep and try to work out exactly what's going on.