As one of many frustrated developers right now trying to debug things that want to use a lot of compute we have hit too many problems that we simply can't debug in reasonable time frames. So right now unfortunately it looks like we will have to switch to CUDA + GL (Swapping from GLSL to CUDA C++ for all compute), and later CUDA + Vulkan, so we can actually debug things properly. When we can compile C/C++ shaders to Vulkan on AMD then we will look at supporting AMD again.
I know from industry friends we are not the only ones looking to do this now.
There is an unholy mess across the different compute API's right now. I know it's a period of transition but there are some things that are way past due - and I am not saying these are all AMD's fault either, and of course this is all non trivial stuff.
The combination of factors that lead to this are:
1) GL Compute shaders that were added to the spec in 2012 cannot be step by step debugged in either CodeXL or Nsight. It's really hard to know sometimes whether we are dealing with driver bugs (which we have found plenty of recently) or our own mistakes without this a lot of the time. As compute usage is getting that complicated - games want to use more compute in a sane manner it's not just for scientists. Same situation for Vulkan. This is a shortcoming of both AMD and NVidia so far.
2) Direct3D isn't an option for us as it has to be OpenGL or Vulkan, and Vulkan is what we want to move totally over to later this year. We also eventually want to move to a C++ subset for shaders instead of GLSL so we can more easily share code across the CPU/GPU which we do a lot already. It's somewhat unfortunate as there is actually a lot of C++ baggage we don't need or indeed desire - it's almost like a cross vendor GLSL+ would have been the better short term solution.
3) We can't debug our compute shaders in CodeXL if we took the OpenCL2 path as it doesn't support atomic's right now. So we can't justify fudging some sort of #ifdef'd around CUDA/OpenCL2 + GL short term solution anyway.
4) AMD OpenGL doesn't support 64bit atomics which we need. You do in OpenCL though! We need ballot() etc which requires later then OpenCL1.2 which is the only version nvidia currently support.
In the ideal world there would only be well supported GL/CL/Vulkan so I feel somewhat frustrated that we will have to go the CUDA route for now. But as soon as we do we will certainly hold off moving on from that during prototyping to catch up for lost time.
Unless AMD or NVidia releases a stepthrough GLSL debugger that works this week I don't see this changing now unfortunately. A shame as my shiny new RX480, which deserves more attention, will probably now sit there unused for a long time.
