On Wed, Apr 14, 2010 at 7:29 PM, Henri Verbeet hverbeet@gmail.com wrote:
On 14 April 2010 17:19, Matijn Woudt tijnema@gmail.com wrote:
I have thought about using LLVM, but I don't like it because of:
- Having another wine dependency (~40MB for me on ubuntu)
- 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).