cancel
Showing results for 
Search instead for 
Did you mean: 

Archives Discussions

yves
Adept I

Crash introduced in driver 15.11

Hello,

The following change causes a segfault in fglrx 15.302 (yes, that's actually the most recent one you get for Linux):

Storage block reorganization, cleanup and driver difference/bug worka… · Yves-G/0ad@5db4d9a · GitHub

For now I've downgraded to fglrx_15.201, which does not have this issue. There are no issues on my Nvidia test machine either (besides the other one I've worked around with this changeset and reported here). On Windows I also get a crash. The first driver version that crashes is 15.11 there. It still crashes with 16.5.3.

And a more general question...

I sometimes wonder if I'm the only one who has such a hard time implementing things in a way that works on all drivers. I've triggered quite a few driver bugs in this development branch already and actually loose way too much of my time debugging driver related issues. How do you guys proceed in such situations? Don't touch the dev system until you're done with the development and then deal with issues on different platforms? Or is that just how it is? It's not like OpenGL 4.3 is bleeding edge technology.

EDIT:

I've tested on Windows and updated the problem description above.

1 Solution

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.

View solution in original post

6 Replies
yves
Adept I

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

0 Likes

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

0 Likes

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.

0 Likes
yves
Adept I

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:

https://gist.github.com/Yves-G/ee590dbfa690f0c7a9c6cf30017c36fa

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:

Crash in driver: OpenGL and SSBOs

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

... because:

  1. It does not hang before the commit that introduced bindless textures
  2. It does not hang on small maps with few trees buildings and units (few different textures)
  3. 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.

0 Likes

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.

0 Likes