HLSL Compiler and d3dcompiler_xx.dll

[Matijn Woudt]

On Thu, Apr 15, 2010 at 11:23 AM, Stefan Dösinger
<stefandoesinger at gmx.at> wrote:
>
> Am 14.04.2010 um 20:45 schrieb Jason Green:
>> FYI, we encountered a game a while back which used a few shaders that depended on being compiled with a particular version for d3dx9_##.dll.  There was a compiler bug which the game engine knew about and accounted for.  If you tried to use the compiled shader from a newer d3dx9_##.dll, then the rendering wouldn't look quite right on certain objects.
>>
>> So, there's one argument for identical bytecode compatibility, but it's likely that very few apps will exhibit behavior like this.
> I think it's only an argument that we may need some specific tests that check for identical bytecode. And by your description it sounds like the compiler bug can be detected by looking at the rendering output. I still think that having the majority of tests check the generated bytecode is a bad idea:
>
> * It will be hard to implement the same compiler result

As long as it is possible, I think we should do.

> * It will make our own optimizations impossible(the MS compiler is very good optimization wise, so that point is mostly moot)
> * It will be hard to maintain the tests when we're moving them to a newer MS compiler version

Tests should fail if a newer version of MS compiler is used and
different code is produced. Or, if you prefer, win_skip if version is
newer than what the tests expect.


> * There are things that can be translated into different bytecodes, and all are equally valid and optimal, like constants ordering.
>

Same as your first concern.