locked
How to instead D3DCompile2 interface in Metro app

    Question

  • Hi, all

          In destop development document, it is said the D3DCompile2 interface can just used in develop, but can't use it in apps that I submit to windows strore. 

    • "Note  You can use this API to develop your Windows Store apps, but you can't use it in apps that you submit to the Windows Store."

    I have a lot of hlsl, and it maybe need compiled in runtime, so I want to compile the raw hlsl source, Does the D3DCompile2  have instead

    interface? how to do it?

        thank you for your help

    Tuesday, September 11, 2012 5:43 AM

Answers

  • The basic rule is that you can use D3DCompile APIs during development, but you can't include the DLL with your app when you submit it to the Windows Store. This means you can't call D3DCompile in your 'final' build of your app.

    How you handle this limitation is up to you. You have a number of options

    * You can make use of the various 'stock' shaders provided in DirectXTK or some other Windows Store app library rather than writing your own.

    * You can do all the compilation at build time using FXC.EXE and never call D3DCompile APIs in your app. You can generate C++ code headers rather than shader binary files. These are compiled into your code so there's nothing to include in your package. This is what DirectXTK does.

    * You can do all compliation at build time using FXC.EXE and never call D3DCompile APIs in your app. You instead include the binary shader files in your app package.

    * You can have your application build shaders at runtime with D3DCompile and 'cache' the results in a file. You then make your final app always use the 'cache' instead of calling the D3DCompile APIs. You just submit the 'cache' file with your app. This is the approach that Epic Unreal Engine 3 and other games have used for years. This does mean you have to be able to exercise all shaders your application can generate to ensure the cache is actually completely filled out before you ship.

    Not being able to use the D3DCompile DLL at runtime in your submitted Windows Store app does have some additional complexities. If you use D3DReflect to get metadata, you have to cache this information along with the shader in some custom form. You also can't make use of Effects 11 (in the DirectX SDK) which requires both D3DCompile and D3DX11 DLLs at runtime, neither of which can be submitted to the Windows Store. It also means you can't have "User Generated Content" that includes uncompiled HLSL source.

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





    Tuesday, September 11, 2012 5:35 PM

All replies

  • The basic rule is that you can use D3DCompile APIs during development, but you can't include the DLL with your app when you submit it to the Windows Store. This means you can't call D3DCompile in your 'final' build of your app.

    How you handle this limitation is up to you. You have a number of options

    * You can make use of the various 'stock' shaders provided in DirectXTK or some other Windows Store app library rather than writing your own.

    * You can do all the compilation at build time using FXC.EXE and never call D3DCompile APIs in your app. You can generate C++ code headers rather than shader binary files. These are compiled into your code so there's nothing to include in your package. This is what DirectXTK does.

    * You can do all compliation at build time using FXC.EXE and never call D3DCompile APIs in your app. You instead include the binary shader files in your app package.

    * You can have your application build shaders at runtime with D3DCompile and 'cache' the results in a file. You then make your final app always use the 'cache' instead of calling the D3DCompile APIs. You just submit the 'cache' file with your app. This is the approach that Epic Unreal Engine 3 and other games have used for years. This does mean you have to be able to exercise all shaders your application can generate to ensure the cache is actually completely filled out before you ship.

    Not being able to use the D3DCompile DLL at runtime in your submitted Windows Store app does have some additional complexities. If you use D3DReflect to get metadata, you have to cache this information along with the shader in some custom form. You also can't make use of Effects 11 (in the DirectX SDK) which requires both D3DCompile and D3DX11 DLLs at runtime, neither of which can be submitted to the Windows Store. It also means you can't have "User Generated Content" that includes uncompiled HLSL source.

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





    Tuesday, September 11, 2012 5:35 PM
  • Hi, chuck

        Did you mean , I can't compile shader at runtime . And I must precompile all the shader before the application run?  I hava a lot of shader, so I must compile the shader one by one ?

    Wednesday, September 12, 2012 6:22 AM
  • You cannot compile shaders at runtime on end-user's machines. You can compile at runtime on development/test machines before you submit to the Windows Store.

    Wednesday, September 12, 2012 6:32 PM
  • hi, chuck

           Now my shader generate according to the render state and compile it at runtime . If it cannot do, I must precompile hundreds of shaders, that is crazy. So Why did you have this limitaion for cannot compile shaders at runtime on end-user's machines?

    Thursday, September 13, 2012 1:33 AM
  • Runtime compliation of HLSL shaders has been discouraged for a very long time as it has always had a negative impact on performance.

    Why do you need to change your shader for every change of render state? Even feature level 9.1 devices have static branching in shaders.

    There are certainly some techniques which are limited without having runtime shader compliation on end-user systems, but your solution sounds like you are already relying too heavily on shader permutations which can be handled far better with constants, braches, etc.

    Thursday, September 13, 2012 8:04 PM
  • Note that for Windows Store apps on Windows 8.1 Preview, the D3DCompile APIs are now available for production use. The D3DCompile_47.DLL is included with Windows 8.1 so you don't included it in your AppX package.

    See MSDN
    Tuesday, July 16, 2013 8:23 PM