6 Replies Latest reply on Jun 14, 2016 3:13 PM by yves

    Crash introduced in driver 15.11



      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.



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

        • Re: Crash introduced in driver 15.11

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

          • Re: Crash introduced in driver 15.11

            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:

            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.

              • Re: Crash introduced in driver 15.11

                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.

                1 of 1 people found this helpful
                  • Re: Crash introduced in driver 15.11

                    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.