HLSL compiler

[Matteo Bruni]

2016-08-31 2:43 GMT+02:00 Fabian Maurer <dark.shadow4 at web.de>:
> I'd like to take a try at Directx10 support, firstmost hacking the HLSL
> compiler (namely implementing "fx_4_0").

Cool!
Notice that fx_4_0 is the effects stuff. You probably want to start
with plain shaders (i.e. vs_4_0 and the like).

> First, is there already someone working on this? Don't wanna duplicate the
> effort again.

I have a lot of code for SM2/3 shaders but it's nowhere near in shape
for upstreaming and I probably won't have time for cleaning that up in
the foreseeable future.
I could publish the code somewhere as-is but, actually, ignoring my
code's existence and restarting from what's upstream now is probably
better anyway. I can give you (or anyone else interested) pointers and
suggestions along the way though, to try and avoid the same pitfalls
and issues I encountered while writing my code.

> Second, since there already is an existing parser: Did you plan to simply
> extend it and make one parser for all HLSL versions, or to duplicate the code
> and have it separate for each version like the official compiler did it? I think
> I'd just add it to d3dcompiler_43.

Yep, d3dcompiler API is supposed to handle all shader versions and the
plan was to have one parser and really one compiler for everything
(splitting out only the strictly necessary stuff, e.g. for writing SM4
bytecode vs SM1 bytecode), sitting in d3dcompiler_43.dll. Ideally
d3dx9, d3d10, d3dx10 and d3dx11 should all forward to d3dcompiler and
everything should work fine. In reality that's not quite true, e.g.
newer versions of d3dcompiler don't really accept fx_2_0 HLSL effects,
IIRC they flag syntax errors for function targets (because some other
newer, incompatible syntax rule was introduced). Alas, I don't recall
the exact details.

To handle that the idea is to exploit the fact that each
d3dcompiler_xx version is compiled separately now (thanks to
Alistair's recent PARENTSRC / Makefile patches) to add #ifdefs where
necessary. That way we can support divergent behaviors without
replicating everything. We might need to have behavior changes between
d3dx9_xx versions (I'm not sure ATM) which would require something
like multiple PARENTSRC dirs but we'll cross that bridge when we'll
get there.