shaders in assembly vs HLSL
Author
Hi,i was wondering if there is a particular advantage in writing shaders in assembly rather than HLSL. I started learning HLSL but everything seems so unintuitive, I dont see where the entry point is, some weird labels that I can't tell which ones are user specified and which ones are built in etc (Maybe i just haven't spend enough time with it). Anyways I feel really comfortable with assembly so i though id try that out. But I don't know where to start, first of all which processor do I write for, isn't the GPU's processor going to be running the code, if so where do I get the processor info/architecture/instruction set. Also do i assemble it to an exe (I plan to use the shaders with my existing engine which is mostly written in DX, so i guess the shader would have to work work with it) I tried googling assembly shaders but nothing useful came up, so does anyone know any tutorials, example, books where the topic is covered? And I was also wondering if its going to be a lot of work to produce a shader, and make it interface with existing DX code, purely in assembly, like is it going to be thousands of lines of asm, vs 200 in HLSL, thanks, Tim.
ASM shaders existed before HLSL was created. Support for them still exists in the API as it did back then.
You can write ASM shaders in any tool, then compile them at runtime using the API. Alternatively, you can compile them as a preprocess (using fxc.exe) and then use the binary files in the API, to speed up loading (by very little, most likely).
As for instruction sets, there are plenty. In general, your code "runs on the GPU", and therefore uses a special instruction set. There are several shader models, each expanding the instruction set, adding new a better features. You can read about the models and instructions in the SDK documentation.
Lastly, I'd recommend you steer clear of ASM shaders if you don't have much experience. They are more complicated than HLSL, and are more difficult to learn. To top it off, you're not likely to get anything by using them, especially not with shaders becoming longer and longer these days.
As a final note, consider that ASM shader support has completely been removed from D3D10 (or, so I understand). This means if you'll ever want to use D3D10, you'll need to learn HLSL.
Hope this helps.
You can write ASM shaders in any tool, then compile them at runtime using the API. Alternatively, you can compile them as a preprocess (using fxc.exe) and then use the binary files in the API, to speed up loading (by very little, most likely).
As for instruction sets, there are plenty. In general, your code "runs on the GPU", and therefore uses a special instruction set. There are several shader models, each expanding the instruction set, adding new a better features. You can read about the models and instructions in the SDK documentation.
Lastly, I'd recommend you steer clear of ASM shaders if you don't have much experience. They are more complicated than HLSL, and are more difficult to learn. To top it off, you're not likely to get anything by using them, especially not with shaders becoming longer and longer these days.
As a final note, consider that ASM shader support has completely been removed from D3D10 (or, so I understand). This means if you'll ever want to use D3D10, you'll need to learn HLSL.
Hope this helps.
Shader ASM is still useful for pixel shader 1.1, as it's really limited, and the compiler often has trouble optimizing for it. Once you hit ps.2.0, I'd stick with HLSL. I know the plan with D3D10 was to no even allow ASM, but I'm not sure if that happened or not.
You should use FX files rather than shaders directly. FX files wrap around shaders to make them incredibly easy to use.
You can use FXC to compile the shaders offline, or compile in your app using D3DXCreateEffectFromFile.
Grab FX composer from nVidiafor sample FX files, and an only somewhat working (though currently the best) shader development environment.
You should use FX files rather than shaders directly. FX files wrap around shaders to make them incredibly easy to use.
You can use FXC to compile the shaders offline, or compile in your app using D3DXCreateEffectFromFile.
LPD3DXEFFECT fx;HRESULT hr = D3DXCreateEffectFromFile(pDevice, "myshader.fx", 0, 0, 0, 0, &fx, 0);if (FAILED(hr)) return;UINT pass, passes;// Choose which technique of the FX file to use.fx->SetTechnique("Technique name");// Setup constants (matrices, lights, colors, textures, etc.)fx->SetMatrix("worldViewProj", world * view * proj);// Start the effect (sets vertex and pixel shaders, and constants)if (FAILED(fx->Begin(&passes, 0))) return;for (pass = 0; pass < passes; pass++){ // Start a specific pass of the technique. Most are only 1 pass if (SUCCEEDED(fx->BeginPass(pass))) { // draw stuff here DrawIndexedPrimitive(...); fx->EndPass(); }}fx->End();Grab FX composer from nVidiafor sample FX files, and an only somewhat working (though currently the best) shader development environment.
Author
Thanks for the replies, i have a few questions
How can they be removed from DX10, isnt HLSL compiled into assembly?
@Namethatnobodyelsetook
I do know how to use FX files, passes etc, and I'm actually currently using that for some of my shader rendering, its just that I find it hard to code in, like for example how to make a sheet bend like a sine wave ( as in the DX SDK example) i mean i know how I would do it in C++ and asm but then translating it into HLSL is somewhat puzzling to me. But if its been removed from DX10 and there is no purpose in using asm then I guess I'll be learning HLSL. Thanks )
Quote:Original post by sirob
As a final note, consider that ASM shader support has completely been removed from D3D10 (or, so I understand). This means if you'll ever want to use D3D10, you'll need to learn HLSL.
How can they be removed from DX10, isnt HLSL compiled into assembly?
@Namethatnobodyelsetook
I do know how to use FX files, passes etc, and I'm actually currently using that for some of my shader rendering, its just that I find it hard to code in, like for example how to make a sheet bend like a sine wave ( as in the DX SDK example) i mean i know how I would do it in C++ and asm but then translating it into HLSL is somewhat puzzling to me. But if its been removed from DX10 and there is no purpose in using asm then I guess I'll be learning HLSL. Thanks )
Quote:Original post by VanillaSnake21
How can they be removed from DX10, isnt HLSL compiled into assembly?
Assuming this actually happened, they'd simply remove all the API functions that take ASM shaders as input. You can't call the functions, so you can't compile ASM shaders.
Again, I'm not sure if this happened or not.
Indeed, D3D10 does not support asm shaders as input. However, you can view the assembly resulting from the HLSL code by using the reflection interfaces, in order to verify that the compiler has successfully captured your intentions expressed in HLSL.
Author
Quote:Original post by Nik02
Indeed, D3D10 does not support asm shaders as input. However, you can view the assembly resulting from the HLSL code by using the reflection interfaces, in order to verify that the compiler has successfully captured your intentions expressed in HLSL.
I'm sure its hackable, there'll be some tools to reverse the porocess to go from asm to fx. Thanks for replies everyone, Id better start mastering HLSL then. :)
Quote:Original post by VanillaSnake21Maybe Demirug will step in here as I know he looked into this (in)directly. The shader byte code emitted by the compiler and received by the driver is digitally signed (or similar) which means you can't easily intercept or modify the package...
I'm sure its hackable, there'll be some tools to reverse the porocess to go from asm to fx.
I think it was at the '05 MVP Summit where one of the D3D team mentioned that the motivation was one of validation. That is, if a signed and verified package arrives at the driver's door then it *knows* it's good to go and a trustworthy source. Also, for GPU-specific optimization done in the driver having a consistent 'form' of assembly is a good thing for them - allowing arbitrary ASM direct from the application isn't quite so clean and tidy..
SM4 shaders are getting pretty big in some cases such that micro-managing the code down to ASM is a pretty big piece of work. We're not talking 10-20 line ASM functions anymore [smile]
To be honest, I highly doubt it'll be high on anyone's priority list.
Cheers,
Jack
Quote:Original post by VanillaSnake21
Thanks for the replies, i have a few questionsQuote:Original post by sirob
As a final note, consider that ASM shader support has completely been removed from D3D10 (or, so I understand). This means if you'll ever want to use D3D10, you'll need to learn HLSL.
How can they be removed from DX10, isnt HLSL compiled into assembly?
Nope. HLSL compiles into an intermediate/abstract D3D byte-code; the device driver provided by the GPU manufacturer then translates this intermediate byte-code into micro-code native to the GPU (or in the case of pixel shaders on some 1.x cards, a fixed function register combiner equivilent).
The micro-code used by the GPU may or may not be similar to D3D's byte code - that's up to the GPU's manufacturer and usually proprietary/secret information.
D3D shader assembly language is just a human readable/writable form of D3D's intermediate shader byte-code.
IMO knowledge of shader assembly language is still very useful for understanding the limitations of each shader model, debugging problems and checking out whether the HLSL compiler has produced optimal code.
As Namethatnobodyelsetook said, for pixel shader 1.x, for non-trivial shaders, you may be forced to use assembly.
HLSL first, assembly if only really necessary.
Quote:Original post by jollyjeffers
Maybe Demirug will step in here as I know he looked into this (in)directly. The shader byte code emitted by the compiler and received by the driver is digitally signed (or similar) which means you can't easily intercept or modify the package...
From all I have seen it looks like a MD5. But I am not sure which parts are includes to calculate it and if there is anything else done to ensure integrity. In any case if the hash key is wrong the shader won’t go through the door.
Anyway the new shader format doesn’t only contain the shadercode itself. It contains the signature any resource usage lists too. Especial n the case when you use structures this can become very complex. Therefore a simple assembler will no longer do the job.
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
