On Wed, Apr 14, 2010 at 7:30 PM, Roderick Colenbrander thunderbird2k@gmail.com wrote:
On Wed, Apr 14, 2010 at 7:22 PM, Matijn Woudt tijnema@gmail.com wrote:
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?
Also remember that perhaps based on gpu capabilities (even on different SM3.0 capable GPUs) some different code might get generated.
One good reason for not having the same code is vertex / pixel shader constants. For some games d3d9x selects uniforms constants which are close to the SM3.0 limits (wined3d eats a number of constants) and this can cause major issues especially on Geforce6/7 and AMD cards (even modern AMD cards only report SM3.0 limits using glsl; you need UBOs to get more). When we have our own compiler we can 'schedule' the constants in such a way that we might be able to avoid these issues. This leads to different shaders.
It is not something to worry about now. I think you just want to focus on rendering tests to see if the shader does the right thing.
Roderick
I think, for now, we should pass D3DXSHADER_SKIPVALIDATION to the compiler, so the code won't be checked for GPU capabilities. I'm not sure if different code is generated when GPU capabilities are low, but I think it's safe to fail if we request too many constants. In test cases we could check D3DCAPS9 and skip if needed.