On Wed, Apr 14, 2010 at 6:47 PM, Matteo Bruni <matteo.myst...@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?