pan/mdg: Refuse to schedule CSEL.vector to SMUL

Even if we only mask a single component from the result of CSEL.vector, in our IR we treat its semantics as vector which causes trouble with when scheduled to a scalar unit.

The problematic bundle looks like this:

vmul.MOV.i32 R31, TMP0.xxxx, R0.yzww sadd.MAX.i32 TMP0.y, R0.y, #65408 smul.CSEL.vector.i32 R0.y, TMP0.y, #127 (closed)

As the comment in midgard.h illuminates, these CSEL instructions are actually operating per-bit, lining up with the all-1's booleans in Midgard. The Bifrost analogue is MUX.i32.bit, not CSEL.i32. We should probably rename the Midgard instruction to make that clear.

Anyhoo, on the scalar unit, CSEL/MUX operates on the bottom 32-bits of its source. That's ok for the usual r31.w case, because that's secretly replicating to its nonexistent register, I think? But that doesn't work with the CSEL.vector (MUX.vector) form, because the condition it's actually muxing on is r31.x, which here is R0.y, not the intended R0.x.

Rather than adding more special cases to the already overcomplicated scheduler (for the dubious benefit of avoiding a small shaderdb regression), just avoid scheduling CSEL.vector to smul.

With the next patch, fixes:

dEQP-GLES31.functional.draw_buffers_indexed.random.max_required_draw_buffers.1

Signed-off-by: Alyssa Rosenzweig alyssa@collabora.com