Is it possible to assemble a shader in D3D11 ? (as opposed to compiling it) ?
It was possible in D3D9, i've used it.
If not, can you offer alternative methods to do it ?
Perhaps there is a way the hlsl assembly to the D3DX11 compile function somehow?
Edit: i DO NOT have access to the shaders hlsl code.
Thanks,
Yoel.
0
12 replies to this topic
Ad:
#4 Moderators - Reputation: 13506
Posted 17 January 2012 - 05:39 AM
Why do you need to compile shaders from Asm instead of from HLSL?
Note that in DX11/SM5, dynamic linking capabilities were added, which allows the driver itself to perform splicing of different chunks of Asm code together.
Note that in DX11/SM5, dynamic linking capabilities were added, which allows the driver itself to perform splicing of different chunks of Asm code together.
#5 Members - Reputation: 192
Posted 17 January 2012 - 07:23 AM
The reason i need to compile shaders from Asm, is that i have some project in which I hook d3d functions, and patch hlsl shaders.
It perfectly works in DX9, and now i'm searching for a DX11 solution.
The project is related to Intel Article about "Dynamic Resolution": http://software.intel.com/en-us/articles/dynamic-resolution-rendering-article/
I don't know how will i handle dynamic linking, i want to support base level first.
PS - i'm checking the DDI level now (the level in which D3D talks with the driver, it's similar to D3D but lower level), perhaps there are hints there
It perfectly works in DX9, and now i'm searching for a DX11 solution.
The project is related to Intel Article about "Dynamic Resolution": http://software.intel.com/en-us/articles/dynamic-resolution-rendering-article/
I don't know how will i handle dynamic linking, i want to support base level first.
PS - i'm checking the DDI level now (the level in which D3D talks with the driver, it's similar to D3D but lower level), perhaps there are hints there
#7 Members - Reputation: 3801
Posted 17 January 2012 - 12:05 PM
This is explicit in the D3D11 documentation and was originally removed by D3D10 - check out the "Direct3D 9 to Direct3D 10 Considerations" topic in your SDK.
If you do decide to proceed with this in a production program you will be releasing something that will land you in support difficulties. If anything goes wrong you'll be on your own, and the first thing you will be told is "use HLSL instead".
Speaking of which - any particular reason to not use HLSL?
If you do decide to proceed with this in a production program you will be releasing something that will land you in support difficulties. If anything goes wrong you'll be on your own, and the first thing you will be told is "use HLSL instead".
Speaking of which - any particular reason to not use HLSL?
It appears that the gentleman thought C++ was extremely difficult and he was overjoyed that the machine was absorbing it; he understood that good C++ is difficult but the best C++ is well-nigh unintelligible.
#8 Members - Reputation: 192
Posted 17 January 2012 - 12:49 PM
Hi mhagain, thanks for your reply.
I'm aware that it's officially not supported and i do not expect any official support for this.
The reason that i can't use hlsl, is that i need to patch shaders to change their behaviour in a certain way.
It's significantly easier to do it for assembly code, than for hlsl code due to many reasons. One of the reasons is how easy it is to write an hlsl assembly parser in comparison with writing a parser for hlsl.
Generally there are obvious reasons to why people use assembly, optimizations are some, full control of exactly what shaders they create is another.
I'm aware that it's officially not supported and i do not expect any official support for this.
The reason that i can't use hlsl, is that i need to patch shaders to change their behaviour in a certain way.
It's significantly easier to do it for assembly code, than for hlsl code due to many reasons. One of the reasons is how easy it is to write an hlsl assembly parser in comparison with writing a parser for hlsl.
Generally there are obvious reasons to why people use assembly, optimizations are some, full control of exactly what shaders they create is another.
#9 Moderators - Reputation: 13506
Posted 17 January 2012 - 05:52 PM
Are you patching shaders that you've made yourself, or patching the shaders of other games?
The ability to create 'variations' of a particular HLSL shader is something that almost every game engine needs to implement -- this isn't a unique feature. And AFAIK, not many people would resort to unofficial binary hacking to get this core feature working...
Even on the xbox360, where developers do have access to the real GPU microcode format, Microsoft still recommends using HLSL and then reading the output to check whether the compiler is doing what you want (and then tweaking the HLSL to produce the assembly that you want).
The ability to create 'variations' of a particular HLSL shader is something that almost every game engine needs to implement -- this isn't a unique feature. And AFAIK, not many people would resort to unofficial binary hacking to get this core feature working...
This isn't really true -- D3D's shader assembly language is only an intermediate language (like MSIL compared to x86 asm). Every different GPU model has its own asm language, which you don't have access to, and the graphics driver will compile your D3D assmebly into real GPU assembly at some point (and in the process, may perform it's own optimisation/rescheduling pass over your code).full control of exactly what shaders they create is another
Even on the xbox360, where developers do have access to the real GPU microcode format, Microsoft still recommends using HLSL and then reading the output to check whether the compiler is doing what you want (and then tweaking the HLSL to produce the assembly that you want).
#10 Members - Reputation: 518
Posted 18 January 2012 - 01:33 AM
It sounds like a very unreliable and complicated way to post-patch the generated assembler code to change the behavior of a shader. Despite "Dynamic Linking" is working only with SM5.0 profile, you could probably use other techniques to achieve similar goals, like using OOP features introduced with D3D11 which are backward compatible to SM3.0 profile (check for example "Advanced HLSL using closures and function pointers")The reason that i can't use hlsl, is that i need to patch shaders to change their behaviour in a certain way.
It's significantly easier to do it for assembly code, than for hlsl code due to many reasons. One of the reasons is how easy it is to write an hlsl assembly parser in comparison with writing a parser for hlsl.
#11 Members - Reputation: 192
Posted 19 January 2012 - 01:18 AM
Hodgman:
There's a BIG difference between gpu assembly (vendor specific and no public headers available) and hlsl assembly (cross vendor and public headers).
Would you rather that i replace "full control" with "Higher level of control" ? I agree in that case
What i meant is full control while remaining cross vendor.
I don't change my own shaders, i would probably not use this method to change my own shaders.
This method worked very well on DX9 and tested on many games ;) (Full game playthrough)
I wish i had a more reliable way as i had in DX9, but currently,
i don't see any other choice, and no one offered an alternative so far.
There's a BIG difference between gpu assembly (vendor specific and no public headers available) and hlsl assembly (cross vendor and public headers).
Would you rather that i replace "full control" with "Higher level of control" ? I agree in that case
What i meant is full control while remaining cross vendor.
I don't change my own shaders, i would probably not use this method to change my own shaders.
This method worked very well on DX9 and tested on many games ;) (Full game playthrough)
I wish i had a more reliable way as i had in DX9, but currently,
i don't see any other choice, and no one offered an alternative so far.
#12 Members - Reputation: 1989
Posted 19 January 2012 - 02:02 AM
Some of the SM5 (and SM4) instruction set's new instructions are very complex compared to SM3. Armed with only the tokens, I would estimate that the reverse engineering would take more time than it takes for D3D12 to come out (not that it has been announced yet).
Consider that in SM5 you have five different shader types, read-write buffers, structured buffers, queue-type buffers, read-write textures, a whole lot of instructions for casting, integer instructions, dynamic linking (as mentioned previously) and a lot of other stuff as compared to SM3.
Consider that in SM5 you have five different shader types, read-write buffers, structured buffers, queue-type buffers, read-write textures, a whole lot of instructions for casting, integer instructions, dynamic linking (as mentioned previously) and a lot of other stuff as compared to SM3.
Niko Suni
Software developer
Software developer
#13 Members - Reputation: 192
Posted 19 January 2012 - 12:02 PM
Nik02:
I only need to change Pixel shaders, so, while still remaining a challenge, it becomes a more feasible one imho.
It's very easy to say that something is impossible, i doubt that this is impossible, i've seen more complicated challenges completed and shipped.
I estimate that as challenging as it is, a single person well skilled in reversing and familiar with 3d APIs concepts can finish it in around 6 months of fully dedicated work ;)
I only need to change Pixel shaders, so, while still remaining a challenge, it becomes a more feasible one imho.
It's very easy to say that something is impossible, i doubt that this is impossible, i've seen more complicated challenges completed and shipped.
I estimate that as challenging as it is, a single person well skilled in reversing and familiar with 3d APIs concepts can finish it in around 6 months of fully dedicated work ;)
