gl4es
gl4es copied to clipboard
ptitSeb
Vbo being unbound causing Clouds to crash after a few seconds on MC 1.18.2
Hey there ! I've been trying to track down a bug for some time with the gl4es, sadly nothing so far.
While running minecraft 1.18.2, activating fancy clouds will make the game crash in a few seconds. While at first, my custom shader conversion was to blame, applying it to gl4es 1.1.4 instead of the current upstream works wonderfully. This means there is a regression of some kind with the current upstream.
EDIT: The behavior has been observed on a snapdragon 845 (adreno 630)
Welp, I failed to generate the logs for 1.1.4, but it may not be that important
1.1.5 logs are enough, don't bother with 1.1.4. I'll check all that later, thanks
Minecraft 1.18.2 vanilla works with 2856e133 and glslang on my device Mali GPU.
Minecraft 1.18.2 vanilla works with
2856e133and glslang on my device Mali GPU.
The crashing behavior was not observed on all gpu vendors actually :thinking: @CosineMath maybe I could test your version and test how my gpu reacts ?
I just remembered, and I dunno if it is linked to the current issue or if it is a separated issue, but the text appeared darker on mali/power vr gpus, and not on adreno ones
I just realized today that I didn't upload the code, nor the tombstone file, let me get that real quick
@ptitSeb For the exercice, I did port the shaderconv to upstream (visible here) and the tombstone is the same, regardless of whether I'm porting to #version 320es or #version 100
@ptitSeb Porting the shader convertion to 6e05e716a401ba25910bf9b5df80f3123cd6b768, exact same tombstone, a NPE. I guess the faulty commit isn't so far now 🤔
Okay, finally nailed down the commit. It was sadly what I expected: https://github.com/ptitSeb/gl4es/commit/0b173f318dd8a0a4232300cb5264487fb7d17415
Oh, yeah, it's a big commit, and quite usefull IIRC.
I guess at some point there is an issue and the VBO get unattached or something like that, making the GPU Driver crash by seeking data that don't exist anymore :(
The question being, when does the buffer get detached without gl4es realizing ? I've seen the commits made to help #238 but they didn't fix the problem, since it has been reproduced on the current upstream
I guess I should ask myself the question the other way: How do we detect a detached VBO ?
It's difficult, but I suppose you can track when VBO are attached / detached.
Isn't this the partially point of the "used" integer inside the bind_buffers_t struct ?
btw, discord might be easier for communication (or rather me asking questions 👀)