On Wed, Apr 14, 2010 at 6:47 PM, Matteo Bruni matteo.mystral@gmail.com wrote:
dlls/wineshader doesn't exist in that tree?
Check if you are in the correct branch (should be the "compiler" branch in his tree).
Right, my mistake.
Lastly, a bit on testing the compiler. I'm not sure trying to get exactly the same bytecode as native is a feasible objective: while for an assembler program there is only one correct translation, this is not true for a compiler. Moreover I expect each iteration of the Microsoft compiler could produce a different output with the same shader program, so there isn't a "right" implementation to compare with. I agree, this makes testing the compiler much harder...
I think that with a lot of testing, the logic behind can be figured out. Then the compiler can be built around this logic. This could possibly even work for a lot of optimizations.
What I mean is that there could not be a single logic behind, I expect to find differences between the various d3dcompiler_xx dlls, expecially regarding the optimizations. You could just pick a version to compare against and try to stick with that, but maybe this is not the best thing to do. On the other hand, with optimizations disabled maybe this doable (but then you aren't testing the optimizer).
It should be same as the latest version available (currently version 42). Changes in the logic when a new version comes out will be caught by test cases. We probably shouldn't directly fail, but perhaps mark it todo_wine when it fails with newer version?