ASM vs HLSL Shaders

Well I have used both ASM and HLSL shaders and to be honest I can't see any performance difference. I use HLSL exclusively because it is so easy to develop for. Also you can have the shader compiler generate the assembly source of the HLSL shader for comparison with your own assembler routines.

Thx like hearing from someone who has experenced both. That was the same reason I thinking about picking up HLSL for ease of use. I just didnt want it to take a performance hit. Thx I think I will pick up a book on HLSL now...

No problem, if you do take a performance hit it is more to do with your algorithm and or the way you are programming the shader in your code. I always check the generated assembler source to make sure the HLSL shader is doing what it should.

I prefer HLSL since it's relatively easier for me (since it blends with C), but I don't mind a little ASM every now and then, which is useful if you're working with D3D8 for some reason.

This book is what I used to get my feet wet with shaders. First it goes into detail of ASM shaders then begins to teach HLSL, providing several examples after and then a reference in the back.

The only reason to use ASM is if you have to make ps 1.x shaders. Otherwise use HLSL.

Quote:

Original post by Matt Aufderheide The only reason to use ASM is if you have to make ps 1.x shaders. Otherwise use HLSL.

Yea perty much I've decided to not support out of date systems already considering this project still has a few years till finish... actauly have a comment in my system enum check. "//No shader support... sucks to be you(exit)" So it looks like I got some reading ahead of me HLSL should be fun to learn...

If I ever get that message I will know who to strangle =)

Quote:

"//No shader support... sucks to be you(exit)".

All games should have that.. mine has somehting similar as well for less than 2.0 support..

From what I've seen the HLSL compiler produces very good code. You'll be pushed to outcode it in asm.

Use HLSL, if you really feel you need to optimise in assembly then take a look at the assembly output from the HLSL compiler and see what you can do from there instead of starting from scratch.

Another reason to use HLSL, from my D3D docs:

Quote:

Differences between Direct3D 9 and Direct3D 10: Unlike in earlier Direct3D 9 Shader Models, where shaders could be authored in an intermediate assembly language, Shader Model 4.0 shaders are only authored in HLSL. Offline compilation of shaders into device-consumable bytecode is still supported, and recommended for most scenarios.

ASM for non-trivial ps1.x shaders (instruction count limitations rather than performance). I've used both (in shipped games that have been tested on a wide range of hardware) and in my experience there is usually always a bigger bottleneck (usually CPU on PC) than shader cycles. Basically what the others said. [smile]


I think it's worth pointing out that shader 'ASM' on PC is actually just an intermediate language that represents a the common set of what GPUs can do, it isn't what the GPU actually uses directly. The graphics card device driver translates that intermediate language into a real form the GPU can use (native microcode, combiner setup, both).

GPU native microcode is often simpler than shader ASM with a single ASM 'instruction' translating into multiple real microcoded ones.

Extremely tightly hand tuned intermediate shader ASM can actually result in microcode that uses more [real] instructions (slower) than ASM produced from HLSL source. The HLSL (/Cg/GLSL) compiler is often more consistent in how it generates and optimises code than a human and so the driver writers can tune their ASM->microcode traslation for common HLSL->ASM code generation patterns.


Long story short: I'd use HLSL until I had to work on shader 1.x hardware or my profiler told me shader cycles were a serious [non-algorithmic] issue.