gallium: fix tgsi SAMPLE_L opcode to use separate source for explicit lod

It looks like using coord.w as explicit lod value is a mistake, most likely
because some dx10 docs had it specified that way. Seems this was changed though:
http://msdn.microsoft.com/en-us/library/windows/desktop/hh447229%28v=vs.85%29.aspx
- let's just hope it doesn't depend on runtime build version or something.
Not only would this need translation (so go against the stated goal these
opcodes should be close to dx10 semantics) but it would prevent usage of this
opcode with cube arrays, which is apparently possible:
http://msdn.microsoft.com/en-us/library/windows/desktop/bb509699%28v=vs.85%29.aspx
(Note not only does this show cube arrays using explicit lod, but also the
confusion with this opcode: it lists an explicit lod parameter value, but then
states last component of location is used as lod).
(For "true" hw drivers, only nv50 had code to handle it, and it appears the
code was already right for the new semantics, though fix up the seemingly
wrong c/d arguments while there.)

v2: fix comment, separate out other changes.

Reviewed-by: Jose Fonseca <[email protected]>

1 files changed, 1 insertions, 1 deletions

diff --git a/src/gallium/auxiliary/tgsi/tgsi_exec.c b/src/gallium/auxiliary/tgsi/tgsi_exec.c
index 6da7d42455c..03f19420986 100644
--- a/src/gallium/auxiliary/tgsi/tgsi_exec.c
+++ b/src/gallium/auxiliary/tgsi/tgsi_exec.c
@@ -2154,7 +2154,7 @@ exec_sample(struct tgsi_exec_machine *mach,
          control = tgsi_sampler_lod_bias;
       }
       else if (modifier == TEX_MODIFIER_EXPLICIT_LOD) {
-         FETCH(&c1, 0, TGSI_CHAN_W);
+         FETCH(&c1, 3, TGSI_CHAN_X);
          lod = &c1;
          control = tgsi_sampler_lod_explicit;
       }