Is there a way to use assembly hand-coded shaders instead of using GLSL on iPhone?

Question

I would like to use hand-coded assembly language vertex and fragment shaders in order to program very optimized shaders on iPhone with OpenGL ES 2.0.

I googled around but I can't find an example or even if it is allowed by apple sdk.

Answer 1

On the iPhone, there is no way to hand tune shaders. It's worth noting that on the iPhone in particular, there are no optimizations that you can do that a compiler can't. That said, the GLSL compiler will probably beat or match your hand-tuned assembly.

On the PC, however, I personally do not have faith in the driver to know that a looping shader should use fewer registers and more instructions in order to achieve greater throughput through higher occupancy. Drivers simply don't have enough context to make the right choice all of the time. Data-specific compile-time optimizations are a great example of this problem.

As someone who has actually looked at the GLSL compiler's assembly output and tried to game the compiler's register allocation strategy, I can tell you that not having assembly access absolutely does hurt performance (on the PC, there are some publicly available tools from NVidia and AMD that allow you to do this). The trade-off to using assembly is that every shader needs to be hand tuned for every supported part in order to achieve the maximum possible performance. While this is a bit extreme, if I want to invest my own time into fine tuning a rendering back-end for each video card my products support, then I should be able to do so. A more practical example would be hand-tuning for low-end video cards, but letting the GLSL compiler do it's job on more high-end video cards.

Further, offline compilers provide a safety mechanism. Many video games today rely on drivers to emulate a lot of the functionality available in modern graphics APIs. As a game developer who works in the game-as-a-service space on the PC, I can tell you that it's extremely upsetting to get a call in the middle of the night because of a minor GLSL bug in a newly released graphics driver. Driver bugs severely impact the overall player experience. Most players simply think that your game is broken, and you can actually lose players as a result (and we probably have). Being able to compile once for each supported video card and hand-tune after the fact would be a huge win in this regard. It simply means that the driver would have to do less work. Code is evil, so the less code that executes is better =).

As a side note, I made the following demo using the 'compile'-'view assembly'-'modify'-'repeat' approach: http://www.youtube.com/watch?v=km0DpZUgvbg . I can tell you with 100% certainty that I could further improve the performance of this ray-tracer with assembly language, and AFAIK, it's the fastest voxel ray-tracer whose existance has been published (that was the case as of Mar 2012, but is likely no longer true). Unsurprisingly, each time a new driver would come out, I would see this demo's performance go from 125-130 fps down to 30 fps - all because the driver didn't know how to optimize my shader correctly. That means I'd have to repeat my optimization process each time a new driver came out, which caused me to simply mothball the project (ACK!). Even though my voxel raytracer can support a large variety of hardware in a performant manner, drivers are currently making it impossible to support this technology in a full product. I simply do not have the weight to put this technology in action because it would require driver vendors to know the ways in which they need to optimize my shader. How many other technologies would be possible if we simply had direct assembly shader access? This implies that lacking assembly access is actually a serious cost. For anyone else in this position, I recommend the following: Use NVidia's assembly language when possible and fallback to GLSL when it's not. If we show the advantage of assembly over GLSL, then hopefully we'll get first-class assembly support from all vendors =).

And finally, not to pick on another author, but I want to point out that the argument made by 'Nicol Bolas' is almost entirely fallacious (sorry Nicol, I have nothing against you, but I wanted to point out some popular arguments that simply don't hold up to an ethics test). Please note that a fallacious argument does not mean that a particular conclusion is incorrect -- just that the argument posited is simply fallacious.

"Why? You don't trust the compiler to do it's job? Do you really think that you know enough about the GPU in question to be able to consistently beat the compiler?"

• This is not an argument. This is simply a question that a lot of people can't think of a real answer to. Therefor, they come to the conclusion that they should just trust the compiler. This prevents people from further investigating the ramifications of trusting the compiler, and prevents logical discourse of the actual pros and cons from taking place. Furthermore, the use of the word "really" in your second question implies that someone answering yes must be deluded. This also hints at what you think about yourself, Nicol -- it implies that you value your opinion above all others, and anyone who doesn't think like you must have something wrong with them (not that they are wrong, but that they have something wrong with them - big difference). That said, you might want to take some time to think about your thought process, your feelings, and your emotional state. Taking this approach will seriously limit your ability to learn, as you won't be challenging your own ideas with enough rigor. Please stop using this argument. It's not healthy or ethical.

"Ultimately, you're just going to have to trust the compiler made by the people who built your GPU. Nobody else has a problem with that these days."

• I have a problem with it. Also, even if no one did have a problem with it, that still wouldn't matter. The fact is that there might still be some benefit to allowing assembly shaders. That said, a consensus does not mean correctness. Further, this argument is especially unethical because there is an implied "Nobody else has a problem with that these days so if you have a problem with it, you must be weird or out of date in your thinking". People have a natural desire to fit in, and using this argument is a way of dividing people on this issue and persecuting people that don't think like you. That said, this argument is especially insidious because of it's implications. Please don't use this argument.

Nicol, both of your fallacies imply that you are right and normal, and anyone who doesn't agree with you is wrong and has something wrong with them. These are extremely unhealthy viewpoints, and you should examine them rigorously for your own mental health and career.

For future reference: http://en.wikipedia.org/wiki/List_of_fallacies#Formal_fallacies

Thanks!