i965/fs/generator: Change a comment as per jordan's suggestion

diff --git a/src/mesa/drivers/dri/i965/brw_fs_generator.cpp b/src/mesa/drivers/dri/i965/brw_fs_generator.cpp
index 70ca7cd..34d40e9 100644 (file)
--- a/src/mesa/drivers/dri/i965/brw_fs_generator.cpp
+++ b/src/mesa/drivers/dri/i965/brw_fs_generator.cpp
@@ -916,18 +916,10 @@ fs_generator::generate_tex(fs_inst *inst, struct brw_reg dst, struct brw_reg src
                        brw_imm_ud(inst->offset));
          } else if (stage != MESA_SHADER_VERTEX &&
                     stage != MESA_SHADER_FRAGMENT) {
-            /* In the vertex and fragment stages, the hardware is nice to us
-             * and leaves g0.2 zerod out for us so we can use it for headers.
-             * However, in compute, geometry, and tessellation stages, the
-             * hardware is not so nice.  In particular, for compute shaders on
-             * BDW, the hardware places some debug bits in 23:15.  As it
-             * happens, bit 15 is the alpha channel mask.  This means that if
-             * you use a texturing instruction with a header in a compute
-             * shader, you may randomly get the alpha channel randomly
-             * disabled.  Since channel masks affect the return length of the
-             * sampler message, this can lead the GPU to expect a different
-             * mlen to the one you specified in the shader (probably 4 or 8)
-             * and this, in turn, hangs your GPU.
+            /* The vertex and fragment stages have g0.2 set to 0, so
+             * header0.2 is 0 when g0 is copied. Other stages may not, so we
+             * must set it to 0 to avoid setting undesirable bits in the
+             * message.
              */
             brw_MOV(p, get_element_ud(header_reg, 2), brw_imm_ud(0));
          }