• Advertisement
Sign in to follow this  

DX11 D3DXAssembleShader for D3D11 ?

This topic is 2192 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

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.

Share this post


Link to post
Share on other sites
Advertisement
There is no hlsl assembly language assembler in D3D11. You must write hlsl or upload already compiled shader binary.

Share this post


Link to post
Share on other sites
Thanks Marins, for your answer.

Before i fire up IDA Pro, and work on extracting such functionality from their DLLs, Is there any alternative method that someone here knows?

Regards,
Yoel..

Share this post


Link to post
Share on other sites
Why do you need to compile shaders from Asm instead of from HLSL?

Note that in DX11/SM5, [url="http://msdn.microsoft.com/en-us/library/windows/desktop/ff471420(v=vs.85).aspx"]dynamic linking[/url] capabilities were added, which allows the driver itself to perform splicing of different chunks of Asm code together.

Share this post


Link to post
Share on other sites
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

Share this post


Link to post
Share on other sites
Ok found something nice:
d3d11TokenizedProgramFormat.hpp
It's in the WDK.
It's supposed to contain all the info i need.

Share this post


Link to post
Share on other sites
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?

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
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...
[quote]full control of exactly what shaders they create is another[/quote]This isn't really true -- D3D's shader assembly language is only an intermediate language (like [url="http://en.wikipedia.org/wiki/Common_Intermediate_Language"]MSIL[/url] 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 ([i]and in the process, may perform it's own optimisation/rescheduling pass over your code[/i]).
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 ([i]and then tweaking the HLSL to produce the assembly that you want[/i]).

Share this post


Link to post
Share on other sites
[quote name='yoelshoshan' timestamp='1326826154' post='4903719']
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.
[/quote]
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 "[url="http://code4k.blogspot.com/2011/11/advanced-hlsl-using-closures-and.html"]Advanced HLSL using closures and function pointers[/url]")

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
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 ;)

Share this post


Link to post
Share on other sites
Sign in to follow this  

  • Advertisement
  • Advertisement
  • Popular Now

  • Advertisement
  • Similar Content

    • By AxeGuywithanAxe
      I wanted to see how others are currently handling descriptor heap updates and management.
      I've read a few articles and there tends to be three major strategies :
      1 ) You split up descriptor heaps per shader stage ( i.e one for vertex shader , pixel , hull, etc)
      2) You have one descriptor heap for an entire pipeline
      3) You split up descriptor heaps for update each update frequency (i.e EResourceSet_PerInstance , EResourceSet_PerPass , EResourceSet_PerMaterial, etc)
      The benefits of the first two approaches is that it makes it easier to port current code, and descriptor / resource descriptor management and updating tends to be easier to manage, but it seems to be not as efficient.
      The benefits of the third approach seems to be that it's the most efficient because you only manage and update objects when they change.
    • By evelyn4you
      hi,
      until now i use typical vertexshader approach for skinning with a Constantbuffer containing the transform matrix for the bones and an the vertexbuffer containing bone index and bone weight.
      Now i have implemented realtime environment  probe cubemaping so i have to render my scene from many point of views and the time for skinning takes too long because it is recalculated for every side of the cubemap.
      For Info i am working on Win7 an therefore use one Shadermodel 5.0 not 5.x that have more options, or is there a way to use 5.x in Win 7
      My Graphic Card is Directx 12 compatible NVidia GTX 960
      the member turanszkij has posted a good for me understandable compute shader. ( for Info: in his engine he uses an optimized version of it )
      https://turanszkij.wordpress.com/2017/09/09/skinning-in-compute-shader/
      Now my questions
       is it possible to feed the compute shader with my orignial vertexbuffer or do i have to copy it in several ByteAdressBuffers as implemented in the following code ?
        the same question is about the constant buffer of the matrixes
       my more urgent question is how do i feed my normal pipeline with the result of the compute Shader which are 2 RWByteAddressBuffers that contain position an normal
      for example i could use 2 vertexbuffer bindings
      1 containing only the uv coordinates
      2.containing position and normal
      How do i copy from the RWByteAddressBuffers to the vertexbuffer ?
       
      (Code from turanszkij )
      Here is my shader implementation for skinning a mesh in a compute shader:
      1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 struct Bone { float4x4 pose; }; StructuredBuffer<Bone> boneBuffer;   ByteAddressBuffer vertexBuffer_POS; // T-Pose pos ByteAddressBuffer vertexBuffer_NOR; // T-Pose normal ByteAddressBuffer vertexBuffer_WEI; // bone weights ByteAddressBuffer vertexBuffer_BON; // bone indices   RWByteAddressBuffer streamoutBuffer_POS; // skinned pos RWByteAddressBuffer streamoutBuffer_NOR; // skinned normal RWByteAddressBuffer streamoutBuffer_PRE; // previous frame skinned pos   inline void Skinning(inout float4 pos, inout float4 nor, in float4 inBon, in float4 inWei) {  float4 p = 0, pp = 0;  float3 n = 0;  float4x4 m;  float3x3 m3;  float weisum = 0;   // force loop to reduce register pressure  // though this way we can not interleave TEX - ALU operations  [loop]  for (uint i = 0; ((i &lt; 4) &amp;&amp; (weisum&lt;1.0f)); ++i)  {  m = boneBuffer[(uint)inBon].pose;  m3 = (float3x3)m;   p += mul(float4(pos.xyz, 1), m)*inWei;  n += mul(nor.xyz, m3)*inWei;   weisum += inWei;  }   bool w = any(inWei);  pos.xyz = w ? p.xyz : pos.xyz;  nor.xyz = w ? n : nor.xyz; }   [numthreads(1024, 1, 1)] void main( uint3 DTid : SV_DispatchThreadID ) {  const uint fetchAddress = DTid.x * 16; // stride is 16 bytes for each vertex buffer now...   uint4 pos_u = vertexBuffer_POS.Load4(fetchAddress);  uint4 nor_u = vertexBuffer_NOR.Load4(fetchAddress);  uint4 wei_u = vertexBuffer_WEI.Load4(fetchAddress);  uint4 bon_u = vertexBuffer_BON.Load4(fetchAddress);   float4 pos = asfloat(pos_u);  float4 nor = asfloat(nor_u);  float4 wei = asfloat(wei_u);  float4 bon = asfloat(bon_u);   Skinning(pos, nor, bon, wei);   pos_u = asuint(pos);  nor_u = asuint(nor);   // copy prev frame current pos to current frame prev pos streamoutBuffer_PRE.Store4(fetchAddress, streamoutBuffer_POS.Load4(fetchAddress)); // write out skinned props:  streamoutBuffer_POS.Store4(fetchAddress, pos_u);  streamoutBuffer_NOR.Store4(fetchAddress, nor_u); }  
    • By mister345
      Hi, can someone please explain why this is giving an assertion EyePosition!=0 exception?
       
      _lightBufferVS->viewMatrix = DirectX::XMMatrixLookAtLH(XMLoadFloat3(&_lightBufferVS->position), XMLoadFloat3(&_lookAt), XMLoadFloat3(&up));
      It looks like DirectX doesnt want the 2nd parameter to be a zero vector in the assertion, but I passed in a zero vector with this exact same code in another program and it ran just fine. (Here is the version of the code that worked - note XMLoadFloat3(&m_lookAt) parameter value is (0,0,0) at runtime - I debugged it - but it throws no exceptions.
          m_viewMatrix = DirectX::XMMatrixLookAtLH(XMLoadFloat3(&m_position), XMLoadFloat3(&m_lookAt), XMLoadFloat3(&up)); Here is the repo for the broken code (See LightClass) https://github.com/mister51213/DirectX11Engine/blob/master/DirectX11Engine/LightClass.cpp
      and here is the repo with the alternative version of the code that is working with a value of (0,0,0) for the second parameter.
      https://github.com/mister51213/DX11Port_SoftShadows/blob/master/Engine/lightclass.cpp
    • By mister345
      Hi, can somebody please tell me in clear simple steps how to debug and step through an hlsl shader file?
      I already did Debug > Start Graphics Debugging > then captured some frames from Visual Studio and
      double clicked on the frame to open it, but no idea where to go from there.
       
      I've been searching for hours and there's no information on this, not even on the Microsoft Website!
      They say "open the  Graphics Pixel History window" but there is no such window!
      Then they say, in the "Pipeline Stages choose Start Debugging"  but the Start Debugging option is nowhere to be found in the whole interface.
      Also, how do I even open the hlsl file that I want to set a break point in from inside the Graphics Debugger?
       
      All I want to do is set a break point in a specific hlsl file, step thru it, and see the data, but this is so unbelievably complicated
      and Microsoft's instructions are horrible! Somebody please, please help.
       
       
       

    • By mister345
      I finally ported Rastertek's tutorial # 42 on soft shadows and blur shading. This tutorial has a ton of really useful effects and there's no working version anywhere online.
      Unfortunately it just draws a black screen. Not sure what's causing it. I'm guessing the camera or ortho matrix transforms are wrong, light directions, or maybe texture resources not being properly initialized.  I didnt change any of the variables though, only upgraded all types and functions DirectX3DVector3 to XMFLOAT3, and used DirectXTK for texture loading. If anyone is willing to take a look at what might be causing the black screen, maybe something pops out to you, let me know, thanks.
      https://github.com/mister51213/DX11Port_SoftShadows
       
      Also, for reference, here's tutorial #40 which has normal shadows but no blur, which I also ported, and it works perfectly.
      https://github.com/mister51213/DX11Port_ShadowMapping
       
  • Advertisement