Is there a way to write HLSL 5 Assembly? I don't really like the instructions the HLSL compiler compiles. I could hand optimize about 30% of the instructions if I could directly write the assembly instructions.
Just a simple dumb example:
[source lang="cpp"]mov r0.y, l(-8.656170)
mul r1.z, r0.x, r0.y[/source]
r0.y never gets used again after these instructions.
Or that:
[source lang="cpp"]mul r0.y, r0.w, r0.y
mul r0.x, r0.z, r0.x[/source]
instead of:
[source lang="cpp"]mul r0.xy, r0.zw, r0.xy[/source]
Is there a way to write HLSL 5 Assembly?
AFAIK, HLSL5 assembly is only intended for debugging purposes. I guess you could reverse engineer the byte-code format though...
Keep in mind, this is just an intermediate-assembly format, and the driver will compile it again into real GPU assembly. Also, modern GPUs don't operate on 4-wide vectors any more, so scalar code is competitive.
Usually you can massage your HLSL code to get it to produce the results you want. Can you post some code that compiles to obviously bad assembly?
Keep in mind, this is just an intermediate-assembly format, and the driver will compile it again into real GPU assembly. Also, modern GPUs don't operate on 4-wide vectors any more, so scalar code is competitive.
Usually you can massage your HLSL code to get it to produce the results you want. Can you post some code that compiles to obviously bad assembly?
Keep in mind that whatever you see for "assembly" on PC for shaders is not really assembly. The driver is going to recompile and optimize the crap out of it on its own, to make it match what the GPU hardware in that card actually uses.
For the former sequence, I don't think mul can take a literal, and if it can, it can't do that on every system.
For the latter sequence, I imagine the driver is going to compile that into the single instruction anyways.
For the former sequence, I don't think mul can take a literal, and if it can, it can't do that on every system.
For the latter sequence, I imagine the driver is going to compile that into the single instruction anyways.
The driver is going to recompile and optimize the crap out of it on its own, to make it match what the GPU hardware in that card actually uses.
From what I recall I get the impression from some driver writers that they want MORE contextual information than the semi-compiled HLSL bytecode they get as its hard to optimise for the hardware given the VM HLSL targets.
The only thing further is something akin to the GL * program extensions. I don't recall if AMD's bothered keeping their low level ones up to date, don't know if intel had any to begin with. NVidia's been updating their gpu_program extensions, so if you switched to GL you'd have the option of using that if you wanted to write nvidia specific shaders for everything. That would mean about as much as the above though, since nvidia's hardware hasn't stayed the same over the last decade either.
Hi CryZe,
Unfortunately no, in DirectX 9 it was something you could do, but starting from DirectX 10 upwards you are not able to write shaders in assambly langage anymore, just to read their instructions... It's a pain, I know.. but we'll have to stick to it.
Here's the reference from MSDN:
Is there a way to write HLSL 5 Assembly? I don't really like the instructions the HLSL compiler compiles. I could hand optimize about 30% of the instructions if I could directly write the assembly instructions.
Unfortunately no, in DirectX 9 it was something you could do, but starting from DirectX 10 upwards you are not able to write shaders in assambly langage anymore, just to read their instructions... It's a pain, I know.. but we'll have to stick to it.
Here's the reference from MSDN:
Porting Shaders
Direct3D 10 Shaders are Authored in HLSL
Direct3D 10 limits the use of assembly language to that of debugging purposes only, therefore any hand written assembly shaders used in Direct3D 9 will need to be converted to HLSL.[/quote]
Cheers!...
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
