Mathias Boulay

[fork with shaderconv](https://github.com/Mathias-Boulay/gl4es/tree/vgpu_upstream)

[tombstone_01.zip](https://github.com/ptitSeb/gl4es/files/9176205/tombstone_01.zip)

@ptitSeb For the exercice, I did port the shaderconv to upstream (visible [here](https://github.com/Mathias-Boulay/gl4es/tree/gl4es-upstream-shaderconv)) 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

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...

I guess I should ask myself the question the other way: How do we detect a detached VBO ?

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 👀)*

both can be used iirc, it is even called zswap

Samsung started advertising swap as extended ram too