Thanks for that. There is in interesting link from MS in that thread that talks about a DLL from Microsoft that does alot of this (but its an separate DLL you'd need to distribute with your app ): http://msdn.microsof...y/ee416644.aspx
I actually came up with a pretty simple solution to this. I use LoadLibrary to verify if the d3d11.dll exists, but I never use it. I just gracefully exit if its not found without calling any DX functions. As the DX DLL is delay-loaded this works fine, and if DirectX 11 does not exist on the computer my code is run on, then none of the delay loaded functions are executed, and I don't hit any errors.
That is my understanding too. That there is magic going on behind the scenes when you compile a pixel shader that converts the pixel shader code into low-level GPU instructions that use shared memory and the like (basically everything you have to do yourself when you write CS or Cuda code).
I have used DeviceMemoryBarrier() in a pixel shader, the documentation is VERY sketchy. As I understand it this is basically a hint to tell the compiler all the GPU threads in the current block should finish accessing globak memory before continuing. Used correctly this should reduce the memory access overhead associated with different threads accessing global memory. But without a coherent description of exactly what this means in the context of pixel shader its difficult to know if I'm using it correctly. Does anyone know of a good description of what this function means in the context of a pixel shader ?
Since I'm obviously new to this whole world of programming and skimming through various tutorial libraries I don't see a lot of discussion on this, I have another question. Is it possible to contain this within the binary? Keep everything nice and self contained, etc.
The way I describe above (where the shader binary is embeded in the C header file) will do this
As demonstrated by my rather dumb post I am embeding my shader files directly in my C headers. This avoids any runtime loading/compiling, which makes life easier (of course you usually need this for other games assets, shaders are a weird intermediate step between code and assets).
Of course runtime loading/compiling can be a godsend if you want to edit shaders on the fly and see the results in real time.