HLSL Compiler and d3dcompiler_xx.dll
tijnema at gmail.com
Wed Apr 14 12:22:44 CDT 2010
On Wed, Apr 14, 2010 at 6:47 PM, Matteo Bruni <matteo.mystral at 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?
More information about the wine-devel