locked
D3D11 in Metro doesn't support D3DReflect? (Why Not?)

    General discussion

  • D3D11 in Metro doesn't support D3DReflect...

    My API uses this to dynamically get the constant buffer sizes of shaders.
    **Is there any other way to get a constant buffer size dynamically in D3D11 without a ID3D11ShaderReflection object?**  Or get the constant variables by name??

    What if I wanted to make a shader compiler tool for Metro... nope guess not.
    What is I wanted to make an Art application that allowed you to dynamically generate complex brushes that requires shader generation... not guess not.

    Does Windows(Desktop), OSX, Linux, iPhone or Android have these shader limitations?? No, so why on earth does Metro??


    Wednesday, August 29, 2012 9:53 PM

All replies

  • yes, it confuses developers a little, however, you could refer this document:

    http://msdn.microsoft.com/en-us/library/windows/desktop/dd607334(v=vs.85).aspx

    it allows us to do it, but we can't use it in apps that you submit to the Windows Store.


    Stay hungry, stay foolish

    Thursday, August 30, 2012 8:47 AM
  • It says you can yes, but fails to load any library that tries to use it.

    Also because you can't use it in the store, it basically makes it unusable and greatly limits the types of tool apps that could be put on the market.

    Giving people a tool set, then turning around and turning off fundamental features of it is just wrong.

    Thursday, August 30, 2012 5:00 PM
  • I have developed a shader compiler that can spit out glsl/hlsl from C# code.  From there I can also compile out my own shader reflection file.  I must have the ability to get shader constants by name for my cross platform API (yes MS I actually care about generating code for other platforms).

    Its stupid MS seems to be trying to force people to develop something around there narrow view of what constitutes valid shader code.  Until someone can suggest a valid non ambiguous reason for MS actions here I can only speculate on all the conspiracies that run through my mind...

    Sorry for the frustration here but I feel I have valid reason to be, .. well frustrated.

    Thursday, August 30, 2012 5:37 PM
  • Essentially you can use D3DReflect (and D3DCompile) at runtime during development, but you have to cache all information you need for runtime usage in some other form.

    http://blogs.msdn.com/b/chuckw/archive/2012/05/07/hlsl-fxc-and-d3dcompile.aspx

    Monday, September 10, 2012 7:06 PM
  • Nobody has answered the question of "why" this limitation exists. If it's a security concern, I kinda get that - but if it was just a feature that got cut due to schedule pressure, that's really lame. I kinda suspect the same reason for why D3DX and the Effects framework was dropped, and managed access to DX.

    My use case - which I think is not uncommon - is that I have a cross-platform product that needs to set shader uniform variables by name since they may be represented differently on different platforms. From what I can tell, my only option is to write something that iterates through all of my shaders offline, loads them, uses reflection to get the constant buffers and variable locations, flatten that data to a file, and then load and reference that file whenever trying to set a variable in my app. And I need to make sure that flattened data gets updated whenever I change or add a shader.

    All of my uniforms are updated infrequently, so performance in setting them is not a big concern in my case. Am I wrong? Is there some other, less fragile approach that could work?

    So, I can spend a week trying to get that working reliably - or just give up on Windows Store apps and limit my product to desktop-only. Seriously, my product supports DirectX 9 -11, OpenGL 2 - 4, and OpenGL ES 2.0. No other graphics API requires these sorts of gymnastics.

    Tuesday, October 23, 2012 7:58 PM
  • I get that you are meant to provide pre-built shaders, but I have a question00 I have not yet converted my DirectX application to Windows Store / Windows Store App form, but as the code relies on the user being able to provide at least part of the HLSL for a compute shader (for scientific/algorithmic computing), what would the solution be in this instance if I can't use the D3DCompileXXX or related APIs and I wanted to go on the Windows Store? (apologies if I have missed something fundamental here, I've not yet invested significant time in the Windows 8 / Store part yet).
    Saturday, November 10, 2012 12:18 AM
  • If it's a performance issue problem, then have the compiled shader and reflection data were stored in the cache directory.  Then subsequent compiles of the same source code would go to that same data.  That would still achieve most of the startup speedup and not force pre-compiled shaders.
    Wednesday, November 21, 2012 9:17 PM
  • Note that D3DCompile API is now supported for Windows Store apps on Windows 8.1 Preview

    Wednesday, August 21, 2013 6:22 AM