Originally posted by Kivada
View Post
A big sticking point for a pure D3D reimplementation is that the binary shader format for newer HLSL shader models is no longer documented, _and_ the d3dcompiler_xx.dll is no longer part of the "public" API. I took a DX developer to task over this at the bar last Wednesday; their excuses boil down to (a) they don't want to have to maintain compatibility, which is stupid (and I told them so), they have to maintain compatibility _anyhow_, and can continue to do so with binary DLLs on Windows, and (b) their division is massively understaffed for how critical DX is to all of Windows now and they don't have spare cycles to maintain any more documentation. As is no surprise here, interoperability is not at all the highest item on their list of priorities, or even on their list of priorities right now. Unfortunately, drunkenly berating core developers in a bar has no effect on managerial prioritization. The shader compiler thing isn't just for GL compatibility, though; it bars a lot of useful and cool kinds of apps from the app store because they can only use precompiled shaders. Shader development apps, toys, or user-modifiable graphcs pipelines are impossible on the app store without the ability to programmatically generate shaders. It's like banning all scripting languages, except for the GPU.
I also pointed out that if Win8 wants to make any inroads into tablets and phones, it's now in the unfortunate position where it has to acomomadate Khronos' crap. Which doesn't mean adding OpenGL|ES support necessarily, but making it easier to write complete wrappers would help. That means making the HLSL compiler part of the full API (it's barred on Win8 store apps as an internal-only feature) or documenting the binary interface, as well as adding configuration calls to make the few places where D3D and GL are incompatible (screen coordinates, depth buffer ranges, etc.) be able to be set to a GL-compatible mode. (It's completely stupid that Khronos, with the extensible GL, hasn't done the reverse already, especially since in a few cases the D3D approaches are quantitatively more correct, but MS either needs to play ball if they want to make it easy for devs to port their existing apps over quickly.) Maybe that argument will get up to a high-ranking PM and they'll act on it. Probably not, but here's hoping.
Comment