On Wed, Apr 14, 2010 at 7:30 PM, Roderick Colenbrander <thunderbir...@gmail.com> wrote: > On Wed, Apr 14, 2010 at 7:22 PM, Matijn Woudt <tijn...@gmail.com> wrote: >> 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? >> > > 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.