dx 11 hlsl, mapping source to assembly

Started by
4 comments, last by MJP 10 years, 2 months ago

Hi,

In my simple shader editor i want to add the ability to look at shader's source code and corresponding assembly output for selected line or region. I know in a debug mode i can get line numbers in dissasembly but they are very innacurate (I have line 9 and next 20 for example). Anywas i want to have something similar i release mode. I know that code got reorganized a lot in the optimization process so this can be hard and it wont be accurate. Any ideas how to do this?

I guess it would be quite easy with volatile (is it still ignored by the compiler? was it ever working? why won't they just remove this keyword?). Do you know any other instruction I could use as a "marker". I mean it shouldn't do anything that would change normal shader execution and it shouldn't be optimized by a compiler so it's still visible in the assembly output?

cheers

Advertisement
Disable compiler optimization. There's simply no other way to get accurate source location information. D3DCOMPILE_DEBUG|D3DCOMPILE_OPTIMIZATION_LEVEL0. One does not automatically imply the other.

Sean Middleditch – Game Systems Engineer – Join my team!

As i said I know that, but these line numbers in debug assembly are not useful at all because they are so innacurate, not to mention it doesn't make sense to analyse debug assembly output. In c++ to analyse disasm in release mode i just used to put few volatile variables or __asm nop. Is there really nothing similar in hlsl?


In c++ to analyse disasm in release mode i just used to put few volatile variables or __asm nop. Is there really nothing similar in hlsl?
That's the same as disabling optimization -- it's not actually a release build any more if you do that, and you're still basically looking at a debug build...


In c++ to analyse disasm in release mode i just used to put few volatile variables or __asm nop. Is there really nothing similar in hlsl?
That's the same as disabling optimization -- it's not actually a release build any more if you do that, and you're still basically looking at a debug build...

How is that? Why two volatile variables that are not used in the actual code would disable code optimization, e.g:

volatile int marker = 34;

for(int i = (etc etc)

(few lines of code here doing something important)

volatile int marker2 = 777;

The HLSL compiler will aggressively inline, unroll, and reorder your code, much moreso than a C++ compiler. It can do this because the language is simple and generally free of side effects, and also because the virtual ISA provided by HLSL assembly is relatively simple. Anything you would do to prevent the compiler from doing this could potentially have a large effect on resulting performance, hence Hodgman's comment about it not actually being a Release build anymore.

This topic is closed to new replies.

Advertisement