Question Compute shaders give blank output on GTX 700 series / Rx 200 series or older

Hi,

our game is using a few different Compute Shaders to edit textures. I've attached the simplest example - a shader that can draw some lines on a texture and blur them. I've attached the script that makes use of the shader as well.

The issue is that all these shaders return a blank texture if used on systems that run an NVIDIA GTX 700 series or older / Radeon Rx 200 series or older (both released in 2013). Almost all newer cards work - we only caught a GTX 920M not working. No exception or warning is printed anywhere.

We tried investigating, but we can't figure out what was introduced in the GTX 900 series / Radeon Rx 300 series that could made a difference. We're not even sure it's due to the compute shader or the functions we're using in Unity, since both GTX 700 and Rx 200 in theory support compute shaders.

Any help from a compute shader pro here is appreciated. Thank you!

 

Lower end GTX 700 series GPUs are Kepler based, which are not fully Direct3D 11.1 compliant. Basically rebranded GTX 600 GPUs. The GTX 920M happens to be a rebranded GTX 720M, which is itself a rebranded GTX 635.

But I don’t know why anything to do with a compute shader wouldn’t work, though I haven’t looked at the files in the zip. There are some somewhat cryptic comments about Kepler not supporting “UAV in non-pixel-shader stages”, but I have to assume they omitted mentioning compute shaders since UAV support for those are a required part of DirectX 11.0 which they supposedly fully support.

My other guess, again totally off the cuff and having not looked at the files you uploaded, is maybe the format of the render textures aren’t supported on those GPUs. I believe D3D11 only requires support for UAV reading / writing to SFloat, SInt and UInt formats from a compute shader, so if you’re trying to read from or write to a RWTexture that’s another format, it might not work. You can use Sample or Load to read from a Texture2D of other formats, but might not be able to write out to anything else. So if you’re using a ARGBHalf render texture, try using ARGBFloat?

 

Hi, thank you for the insights! The GPUs we've had issues with seem to be Kepler-based or older indeed. Yet we can't find a reason why those wouldn't work. We've tried barebone versions of the shader with most features removed, but those don't work either. At this point we are thinking the issue must be in the C# code, but we have no idea what it may be.

Could you maybe have a look at the actual files? Many thanks again

 

Unfortunately my experience with compute shaders isn't that thorough, so I didn't see anything that jumped out at me as being especially wrong between the two.

The only thing I might suggest is add some checks in the c# to make sure everything you're doing is supported by the current computer your user has.
https://docs.unity3d.com/ScriptReference/SystemInfo.html
https://docs.unity3d.com/ScriptReference/SystemInfo-supportsComputeShaders.html
https://docs.unity3d.com/ScriptReference/SystemInfo-copyTextureSupport.html
https://docs.unity3d.com/ScriptReference/SystemInfo-supportedRandomWriteTargetCount.html
https://docs.unity3d.com/ScriptReference/SystemInfo.SupportsRenderTextureFormat.html

Unfortunately I don't see a way to check if a format is available for UAV or RW structured buffer, though I would expect Unity to log a warning or error that and most of the things above. Either way I would try and log as much information as you can and have your users run the game with those, then send you the log to see what information you can get from that.

The only other thing is I seem to remember having had some problems with

enableRandomWrite

sometimes not working 100% for temporary render textures.

 

Like @bgolus said about temporary textures with enableRandomWrite on, I've had issues with them working not with compute shaders at random times. The ways I've gotten around it is to call the render texture's create function after the GetTemporary call or just forgo using temporary textures and pre-allocate them the usual way.