[PATCH 1/2] wined3d: Correctly parse SM4 dcl_immediateConstantBuffer opcode.

[Henri Verbeet]

On 4 December 2015 at 13:06, Józef Kucia <joseph.kucia at gmail.com> wrote:
> This patch meant to be a minimal patch to prevent the infinitive loop.
> It's mostly for bug 39153 which is "implement enough D3D11 to run Tomb
> Raider 2013 without disabling d3d11 again" ;-) It allows the game to
> crash properly instead of looping indefinitely. It crashes because of
> some unsupported texture format with this patch. In order to make the
> patch small I haven't added WINED3DSIH_ entry for this opcode yet.
> Otherwise, I would have to reindent opcode tables also in shader.c,
> arb_program_shader.c and glsl_shader.c. The subject should actually be
> "wined3d: Correctly calculate length for SM4
> dcl_immediateConstantBuffer opcode."
>
But it doesn't actually allow the application to run, right? There's
certainly something to say for limiting the scope of patches during
the code freeze, but that's not necessarily the same as limiting the
number of lines you touch. I think that for d3d10+ the potential for
regressions is fairly limited at the moment, so in that regard adding
the WINED3DSIH_ entry wouldn't concern me much. On the other hand,
since (as far as I can tell) the patch doesn't make a substantial
difference for the application in question, it could just as well be
argued that the patch shouldn't go in at all during the code freeze.

> I think I still need some additional code to handle this case before
> len is added to *ptr. WINED3D_SM4_INSTRUCTION_LENGTH is 0 for
> DCL_IMMEDIATE_CONSTANT_BUFFER opcodes. In the result we are adding
> 4294967295 to the pointer. I could use other type than DWORD so it
> would effectively decrement pointer pointer also on 64 bit but I doubt
> we want that. I could also check if len is 0 before decrementing it
> but it is not right for other opcodes than
> DCL_IMMEDIATE_CONSTANT_BUFFER.
You're probably right. Still, it all seems pretty suspicious. For
every other instruction so far the length is properly set. I suppose
the issue is that the maximum size of immediate constant buffers
(4096) is larger than the maximum value of the instruction length
field. What does the actual bytecode look like? Any unrecognized
flags?