HLSL Compiler and d3dcompiler_xx.dll

Matijn Woudt tijnema at gmail.com
Wed Apr 14 12:55:14 CDT 2010


On Wed, Apr 14, 2010 at 7:30 PM, Roderick Colenbrander
<thunderbird2k at gmail.com> wrote:
> 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
>

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.



More information about the wine-devel mailing list