Reflection interfaces

Henri Verbeet hverbeet at gmail.com
Tue Oct 19 05:25:02 CDT 2010


2010/10/18 Rico Schüller <kgbricola at web.de>:
> What's the preferred way to implement the different interfaces?
>
> 1. Implement a parser which parses the shader (RDEF, STAT), and implement 4
> independent interfaces (each in its own dll). Only reuse the parser.
> 2. Like 1, but all 4 implementations have there own parser, which leads to a
> lot of duplicated code. But it is the most flexible way. It could easily
> parse all possible shader blobs (theoretically they could differ from
> version to version, I have no test for that, yet).
> 3. Forward all interfaces to d3dcompiler_43.dll and this will contain all
> interfaces and the parser. This way the codebase is the smallest possible
> one, but it will offer all interfaces, which isn't what native does. Also
> all further interfaces would go to d3dcompiler_43.dll. This could get
> tricky.
>
I'm not sure. The problem with 3 is that it will prevent using the
native d3dcompiler to work around e.g. the missing HLSL compiler
because it doesn't implement ID3D10ShaderReflection etc. Perhaps we
don't care in the long term, but at least in the short term that would
be a problem. Option 1 would require d3dcompiler to have some private
interface or entry point, and you'd still have the same problem as
with option 3. Option 2 leads to duplicated code.

There may be an option 4 though, which would be to implement the older
interfaces on top of ID3D11ShaderReflection. I.e., you'd use the
information you get from the ID3D11ShaderReflection interface to
construct constant buffers and variables for the other interfaces,
instead of parsing the shader bytecode yourself. It would need some
investigation to determine how feasible this option is.



More information about the wine-devel mailing list