HLSL Compiler and d3dcompiler_xx.dll

[Roderick Colenbrander]

On Wed, Apr 14, 2010 at 7:22 PM, Matijn Woudt <tijnema at gmail.com> wrote:
> 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?
>

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