Drivers & Software

[straylightning]

After a great deal of investigating dead ends, I finally have a workaround for a Vulkan device loss issue on newer AMD devices when running my application.  The application runs for (say) between 1 and 100 frames, and then reports (most often) a device loss before triggering a driver reset.  I am running on an RX 460 with 2GB on Windows 10 x64, using Radeon 18.3.4 drivers (the latest at the time of writing.)

My current workaround can be seen here:

https://github.com/StrayLightning/aeolius/blob/b2305f9f08e0e9c97ba4c080c39609c181047351/res/land/2-l...

This is basically how I am restricting the inner and outer tessellation parameters in my tessellation control shaders:

        if (tessellation_hack) {

            li = clamp(li, 4.0, 64.0);

            lo0 = lo1 = lo2 = li;

        }

After applying this, I've had the application running for more than 15 minutes without problems.

I am running with Vulkan validation layers enabled, and there are no problems reported with the workaround disabled (until the device loss event.)

These restrictions are unexpected, and they seem to go against the documentation in chapter 21 of the Vulkan specification.  They are not required for NVIDIA devices, Intel devices, and older AMD devices that I have tried.

Can anyone identify any documentation I have missed or alternatively confirm that this looks like a bug?

The full source code of the Rust application and framework can be found here:

https://github.com/StrayLightning/aeolius

Further history of my investigation can be found here:

https://github.com/StrayLightning/aeolius/issues/32

[straylightning]

Just to add further details: The tessellation inner and outer parameters can normally be all zero to cull the face entirely, but this workaround prevents that from happening.

In fact, the restrictions can be relaxed further:

if (tessellation_hack) {

    li = clamp(li, 2.0, 64.0);

    lo0 = clamp(lo0, li, 64.0);

    lo1 = clamp(lo1, li, 64.0);

    lo2 = clamp(lo2, li, 64.0);

}

gl_TessLevelInner[0] = li;

gl_TessLevelOuter[0] = lo1;

gl_TessLevelOuter[1] = lo2;

gl_TessLevelOuter[2] = lo0;

However, removing the 2.0 minimum on li makes the problem come back.  Removing the restriction on lo{0,1,2} being at least as great as li also causes the problem to come back.

Please also note that these problems don't occur when using the GLSL in OpenGL mode in the same environment.

[elstaci]

I believe this post might be better answered at GITHUB: Issues · GPUOpen-Drivers/AMDVLK · GitHub

[straylightning]

Thanks.  I am aware of AMDVLK.  It is the official open source Vulkan driver for AMD GPUs on Linux.  I don't think they would take too kindly to me reporting problems relating to running applications on Windows there :-)

While I have made efforts in the past to test this application on AMD GPUs under Linux (e.g. aeolius/radv.md at master · StrayLightning/aeolius · GitHub​) in both OpenGL and Vulkan, it currently means maintaining multiple Linux installs and the cost/benefit doesn't work out wonderfully.  As it can be quite bleeding edge, it often involves a lot of experimenting and reinstalling everything from scratch to ensure a clean configuration, which is then vastly out of date the next time I boot into that config.  I can happily report that the application does run fine on the official closed source NVIDIA drivers on Fedora, though.

[elstaci]

Open an email Support ticket with AMD Support and link this thread so that they can see the technical part of the problem: Email Form .

[straylightning]

Okay, this turns out to be far more involved than I had initially expected.  Characterising the problem is turning out to be tricky.  While the additional clamps make the problem go away, it is not just the values of the tessellation parameters that are important, but also the control flow around the culling.  So it may be a complex interaction involving the GLSL to SPIR-V compilation that glslangValidator performs and the transformation that the Radeon driver performs between SPIR-V and GCN4.