HLSL Compiler and d3dcompiler_xx.dll

Matijn Woudt tijnema at gmail.com
Wed Apr 14 12:48:25 CDT 2010


On Wed, Apr 14, 2010 at 7:29 PM, Henri Verbeet <hverbeet at gmail.com> wrote:
> 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 think I should go for exact bytecode as long as it is possible, it's
the only way we can be sure the implementation is 100% right for each
test case.

>
> 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.
>

Right, it's probably better to go ahead first, and implement LLVM once
we find it necessary (if ever).



More information about the wine-devel mailing list