Give MS priority over LOD in Image opcodes

[mikusp]

A draft as I'm not sure it is sound, but I'd like to get CTR ingame. One shader there hits ASSERT(!inst_info.has_lod || !has_ms);, and looking at the offending shader, it does image_load_mip with T# describing a Color2DMsaa image. That looks incorrect, but I'm not sure if the cause is an issue with shad or the original hardware ignores the _mip part and goes on.

With this change, the game progresses further and can get into a race with graphical glitches

[squidbus]

Do you have any info on where the mip level for the instruction comes from in the shader? If it's always 0 maybe we can detect it and it should work as if it's a regular image load?

[StevenMiller123]

Where would that be, given this image_load_mip?

/*00000000006c*/ image_load_mip  v[0:3], v[0:3], s[0:7] dmask:15

[StevenMiller123]

For what it's worth, v2 is a hardcoded 0 (v_mov_b32 v2, 0), everything else has some calculation involved.

[squidbus]

I believe it would be v2 in that case, yes. So I believe a solution would be to walk back through the arg to its source and detect the constant 0, and then use that to ignore has_lod (if both has_lod and has_ms are true).

Although personally I'm not sure if we need to bother checking or we should just ignore has_lod if has_ms is true, and just assume that its the 0 case. Basically I think what this PR is doing should be a fine place to start if you don't want to bother with that method, although I think the warning message could be simplified a bit, just need to indicate that we hit a MIP instruction with a multisampled texture and that we're assuming the mip level is 0. As far as I know you can't have multiple levels on a multisampled texture anyway, although I don't know how hardware would behave if someone actually tried.

[mikusp]

I see that indeed, arg.IsImmediate() there returns true and the value is 0.

You mention that the check is not essential there, however, if we ignore has_lod, the argument passed for mipid would be interpreted as fragid according to the current code and Table 8.8 in AMD Sea Islands Instruction Set Architecture document. If that is fine I can simplify the warning message and mark the PR as ready for review

[squidbus]

That's true, it may be worth checking out the v3 value here as well and seeing if somehow we have x, y, mipid, fragid or something.

[mikusp]

Yes, v3 is also set but the value is not an immediate there

/*000000000014: 4a06006a         */ v_add_i32       v3, vcc, vcc_lo, v0

[squidbus]

Doesn't need to be an immediate. I think the logic would be, if has_lod && has_mip and the mipid is an immediate 0, ignore the mipid and read fragid from the next one. If mipid is not immediate 0, we have a problem.