HLSL Compiler and d3dcompiler_xx.dll

[Henri Verbeet]

On 14 April 2010 17:19, Matijn Woudt <tijnema at gmail.com> wrote:
> I have thought about using LLVM, but I don't like it because of:
> 1) Having another wine dependency (~40MB for me on ubuntu)
> 2) Code generated by LLVM will most likely not generated exactly the
> same bytecode as native compiler does, even though the shader has same
> effect on both. This makes it really hard to verify the HLSL compiler
> is working. My idea was to make wine's hlsl compiler produce exactly
> the same bytecode as native does. We might even find bugs in the
> native compiler, and either fix or duplicate these bugs.
>
> LLVM might be useful if we needed a really fast compiler, but native
> compiler isn't really fast AFAIK. Once games are calling it a few
> hundred times it might be worth the effort.
>
I think you want to test if the compiled shader works instead of the
exact bytecode. Generating the same bytecode is probably way too hard,
fragile to test, and most likely not worth the effort.

I'm not sure about LLVM. On one hand I don't think we want to be
writing and maintaining all the optimizations that LLVM can do inside
the d3d compiler dll. On the other hand, it would be a pretty large
dependency, and it's not clear if it would gain us anything at all.
It's not entirely unlikely that if the driver we're running on has a
good GLSL compiler we're not going to see much of a benefit from
generating good d3d bytecode. (I can already hear the Mesa people
laughing about that one though.) Either way, it would probably already
be a good start to have a parser, and generate some basic unoptimized
bytecode from that, or even just print an AST.