i965/vec4: Fix the source register for indexed samplers

Previously when setting up the sample instruction for an indirect
sampler the vec4 backend was directly passing the pseudo opcode's
src0. However vec4_visitor::visit(ir_texture *) doesn't set the
texture operation's src0 -- it's left as BAD_FILE, which when
translated into a brw_reg gives the null register. In brw_SAMPLE,
gen6_resolve_implied_move() inserts a MOV from the inst->base_mrf and
sets the src0 appropriately. The indirect sampler case did not have a
call to gen6_resolve_implied_move().

The fs backend avoids this because the platforms that support dynamic
indexing of samplers (IVB+) have been converted to not use the
fake-MRF hack, and instead send from proper GRFs.

This patch makes it call gen6_resolve_implied_move before setting up
the indirect message. This is similar to what is done for constant
sampler numbers in brw_SAMPLE.

The Piglit tests for sampler array indexing didn't pick this up
because they were using a texture with a solid colour so it didn't
matter what texture coordinates were actually used. The tests have now
been changed to be more thorough in this commit:

http://cgit.freedesktop.org/piglit/commit/?id=4f9caf084eda7

With that patch the tests for gs and vs are currently failing on
Ivybridge, but this patch fixes them. There are no other changes to a
Piglit run on Ivybridge.

On Skylake the gs tests were failing even without the Piglit patch
because Skylake needs the source registers to work correctly in order
to send a message header to select SIMD4x2 mode.

(The explanation in the commit message is partially written by Matt
Turner)

Tested-by: Anuj Phogat <[email protected]>
Reviewed-by: Matt Turner <[email protected]>

0 files changed, 0 insertions, 0 deletions