Never mind, the problem is probably with the GPUSkinningBlock. Sorry, I got fooled by the different behaviour of different drivers and versions.
It should be an array of structs containing an array of matrices, but I've made it just an array of structs containing a single matrix. It works depending on the buffer layout, but it's wrong.
However, I wonder how I can solve that with the different behaviour regarding GL_TOP_LEVEL_ARRAY_STRIDE between AMD and Nvidia drivers. I would like to avoid doing a driver enumeration in the code and using different code depending on the driver vendor (and maybe even the version of the driver).
Actually what I mentioned above did not cause the crashes or at least wasn't the only reason. I'm quite sure there's still a bug that got introduced in one of these driver versions, especially now that I've found a workaround.
Here's a workaround for this crash on newer AMD drivers: Workaround for yet another AMD driver bug. · Yves-G/0ad@43110f2 · GitHub
And there's my solution for the problem mentioned above: Allow arrays of structs and arrays of single values in blocks. · Yves-G/0ad@707f55d · GitHub
Unfortunately this only got rid of the crashes on one test-map with a single model and the crashes still occur for other maps and in different shaders. It seems like something causes corruption in the driver that can be affected by many different modifications in the shaders, but it's very hard to find the root cause.
Now I'm trying to make a smaller sample program with the same issues.
OK, I've spent this weekend investigating the issue and figured out quite a bit.
Here's a small reduced example that causes the crash:
It's a single file to be used with the OpenGL superbible examples, which should make it very easy to build and run. More information in the file description on github.
I realised that I had a very similar issue before. It seems it wasn't fixed but just disappeared for a while:
For now I've found a tedious but reliable workaround for my GL4 branch of 0ad. I just have to ensure that all the blocks which are declared in the vertex shader stage are also in the fragment stage and in the same order as in the fragment stage. The order is defined alphabetically by the block name.
In addition to the crash, my OpenGL 4 branch of 0ad on github also hangs on some maps. This is a separate issue and I think it's the one described here: Crashes when using GL_ARB_bindless_texture with AMD drivers
- It does not hang before the commit that introduced bindless textures
- It does not hang on small maps with few trees buildings and units (few different textures)
- The example program there hangs for me too
I hope some AMD driver developer could have a look at these issues. I've done my best to make the example program as simple and self-explaining as possible and it should be very easy to test it quickly without spending too much time on the setup.
1 of 1 people found this helpful
Thank you very much for your feed-back. I can confirm we have a fix pending for this issue. Please re-check with the next driver release or the one that follows.
Very good news, thanks a lot!
The other issue which is apparently related to bindless textures still remains, but I've observed a difference between my Linux system and the Windows system (same hardware, different driver versions). It does not hang on the Linux system. I'm going to investigate some more by comparing the behaviour on Windows and Linux and with different driver versions. I'm also going to test the difference between that minimised test case posted in the other thread and my 0ad GL4 branch to confirm if it's really the same issue.
I should have some more information to add to the other thread by Friday or Saturday.