GZDoom crashes on r600g with Mesa 18.0 due to overassumption

Guest · Post by **Guest** » Wed Apr 11, 2018 2:56 pm

Symptom log: https://ghostbin.com/paste/7575k

After chatting with Mesa devs on this issue, I've managed to arrive to the conclusion that this condition does a slight over-assumption on availability of shader storage buffers: https://github.com/coelckers/gzdoom/blo ... e.cpp#L369

As per mentioned discussion with imirkin between 20:07-20:18 log time ( https://people.freedesktop.org/~cbrill/ ... 2018-04-05 ), just because the driver reports shader storage buffer support, doesn't guarantee there are available buffers for vertex shader storage (ref: https://www.khronos.org/registry/OpenGL ... object.txt ctrl-f for "New Implementation Dependent State"), so it requires additional checks before being used.

Linux distribution is Arch Linux, GPU is Radeon HD 7660G (from the A10-4600M APU).

Guest · Post by **Guest** » Wed Apr 11, 2018 3:05 pm

Just following up on a few details - GZDoom version is 3.3.1, passing `-glversion 3` or making using Mesa overrides of GL to 4.1 and GLSL to 1.3 (I think? don't remember) mitigates this behavior.

Post by **Graf Zahl** » Wed Apr 11, 2018 3:17 pm

just because the driver reports shader storage buffer support, doesn't guarantee there are available buffers for vertex shader storage

Sounds like a broken driver to me. What's the point in reporting the feature if it doesn't work. More importantly, how can this be checked?

But it figures that stuff like this only happens with Mesa drivers. It's not the first time there were problems with them not acting in a sane fashion.

Guest · Post by **Guest** » Wed Apr 11, 2018 3:30 pm

Well, as the log states, fragment shader storage buffers are available, just not vertex shader storage ones, so I'm guessing this largely depends on how strict/loose one wants to be with the SSBO spec and hardware feature availability.

Post by **Graf Zahl** » Thu Apr 12, 2018 12:33 am

To be honest I am at a loss for words.

This sounds like some incompetents were trying to meet the bare minimum of the spec, screw any usability issues.
The best that can be done here is actually forcing '-glversion 3' and disable all those 'modern' features. To me the driver is broken by design, there's no need to sugarcoat that.

Guest · Post by **Guest** » Thu Apr 12, 2018 3:36 am

Ok, that's fine by me, since I'm reporting this as a user. At least I know where both parties stand on this corner case, thanks!

ZDoom