Take the 2-minute tour ×
Game Development Stack Exchange is a question and answer site for professional and independent game developers. It's 100% free, no registration required.

Bear with me, because I will raise several questions at once. I still feel, though, that overall this can be treated as one question that may be answered succinctly.

I recently dove into solidifying my understanding of the assembly language, low-level memory operations, CPU structure, and program optimizations. This also sparked my interest in how higher-level shading languages, GLSL and HLSL in particular, are compiled and optimized, as well as what formats they are reduced to before machine code is generated (assuming they are not converted directly into machine code).

After a bit of research into this, the best resource I've found is this presentation from ATI about the compilation of and optimizations for HLSL. I also found sample ARB assembly code.

This sort of addressed my original curiosity, but it raised several other questions. The assembler code in the ATI presentation seems like it contains instructions specifically targeted for the GPU, but is this merely a hypothetical example created for the purpose of conceptual understanding, or is this code really generated during shader compilation? If so, is it possible to inspect it, or even write it in place of the higher-level syntax? My initial searches for an answer to the last question tell me that this may be disallowed, but I have not dug too deep yet.

Also, along the same lines, are GLSL shader programs compiled into ARB assembly code before machine code is generated, and is it possible to write direct ARB assembly?

Lastly, and perhaps what I am most interested in finding out: are there comprehensive resources on shader compilation and low-level GPU code? I have been unable to find any thus far.

I ask simply because I am curious :)

share|improve this question

1 Answer 1

up vote 4 down vote accepted

The assembler code in the ATI presentation seems like it contains instructions specifically targeted for the GPU, but is this merely a hypothetical example created for the purpose of conceptual understanding, or is this code really generated during shader compilation?

PIX and other vendor-specific graphical debugging tools can show you the assembly code your HLSL breaks down into. You can also use these assembly instructions (various versions of which are documented here). The presentation you linked seems to focus mostly on the ps_2_0 version of this assembly language. Compiling HLSL into this vendor-agnostic assembly code is handled by Microsoft's libraries (D3DX I believe) which is then given to the driver via D3D to further process into vendor/gpu-specific code (labeled in the presentation as microcode... I'm inclined to believe they haven't faked the one snippet of ATI microcode they've shown, but that's just a guess.)

If so, is it possible to [...] even write it in place of the higher-level syntax?

You may be able to write your own bytecode (either through encoding it manually yourself or using asm {} blocks for some targets), but it's discouraged, at least for production. Harder to read, forces you to rewrite to take advantage of the latest opcodes, not even allowed in more modern versions of HLSL, etc. Getting a handle on what your HLSL ends up turning into is all fine and dandy, of course.

Also, along the same lines, are GLSL shader programs compiled into ARB assembly code before machine code is generated, and is it possible to write direct ARB assembly?

GLSL has generally been compiled directly by vendor specific drivers, lacking an official GLSL-to-bytecodes compiler and a driver model forcing people to use it, resulting in some unfortunate variation where some vendors will compile GLSL that others won't. Similarly, they may or may not compile to ARB as an intermediate step -- it wouldn't surprise me if they translate both GLSL and ARB assembly directly into some vendor-specific intermediate representation before giving it to the underlying kernel-land driver and ultimately the GPU.

Vendors and vendor tools are ultimately going to be the ultimate authority on how their GPUs will perform at a low level. They have a vested interest in providing game developers with the tools they need to make their games perform well on their hardware. Check them out and dig in:

https://developer.nvidia.com/tools

http://developer.amd.com/tools/graphics-development/

share|improve this answer
    
Thanks! Very thorough answer. –  ktodisco Dec 13 '12 at 4:01

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.