No Error Context causes driver crash
haubna opened this issue · 3 comments
Bug Description
It seems like some users with Physics Mod + Iris + Sodium experience crashes when this is enabled. The crash doesn't seem to generate any log file so maybe it is a driver crash. Here is the report of a user:
Hi! I'm having a crash on world load with Physics Mod Pro v169 and shaders enabled. If I disable shaders first, join the world and then enable shaders back - everything works perfectly. This is on Minecraft 1.20.1 with Iris 1.7. I've also tried with other mods disabled (Vivecraft and Journeymap), but it was the same. I've included the latest log, but I don't see any info about a crash there. My friend with a similar setup has the same problem. Thanks!
Thank you! Updating drivers and changing shaderpacks didn't help... But while randomly changing video settings I've found out that disabling "Use No Error Context" in the Performance menu helped and the game is no longer crashing even with shaders enabled 😮
Reproduction Steps
I wasn't able to reproduce it on my end, but simply enabling shaders before joining a world causes it in some rare cases.
Log File
Here is the corresponding latest.log file: latest.log
Crash Report
No crash log got generated.
This is not a bug with the option to use a No Error Context. It's just turning what was previously undefined/broken behavior into a crash.
Probably, Physics Mod is doing something wrong when it comes to uploading textures. We've found a lot of broken mods which use async texture uploads incorrectly (as the Minecraft interfaces for recording render calls is very error prone), but unfortunately without access to sources, it would take too much time for us to try and find the issue.
It may be helpful to enable a Debug Context so that the driver is more likely to produce useful diagnostics. Failing that, one needs to look at the JVM crash dump to figure out what API calls are crashing. This may not produce useful information at all with certain proprietary graphics drivers.
Also see past examples of problems like this, which were caused by secondary threads inserting render commands into the main render thread in an unpredictable manner, leading to corruption of the graphics state.