Could you attach screenshot of correct and incorrect rendering?

Created attachment 110170 [details]
Correct rendering on gen4

Created attachment 110172 [details]
Incorrect rendering on gen7

Thanks.  Happens also on BYT.  I'm pretty sure Jellyfish looked like that on GEN7 already last winter, so if this is a regression, it's an old one.

Now my chv is showing the same rendering errors as gen7. I had my older Mesa branches still around, so I tried to go back, but I still see the broken rendering. I'm pretty sure the problem wasn't present on chv when I filed the bug. The only explanation I can come up with is that it might be somehow related to configure options, cflags, or toolchain or library versions, or some other external variable that changed in the meantime.

I tried compiling Mesa with -O0, switched to an old branch of the ddx, tried 'blt' AccelMethod only, disabled the null state stuff in the kernel, etc. Nothing helped. So I can't really explain the change if behaviour on my BSW with anything else than the fact that I upgraded the hardware in between. The other option is that I only imagined that it rendered correctly originally.

Created attachment 113982 [details] [review]
glmark2 jellyfish vertex shader patch

I confirm that this is happening in SNB (gen6) too.

I modified the jellyfish vertex shader (attached patch) to have the sin() function argument to be within the range of [0, 2*PI) radians by using the modulo operation. In this case, it renders fine.

I think this is the same problem explained here:

http://lists.freedesktop.org/archives/mesa-dev/2014-December/072429.html

(In reply to Samuel Iglesias from comment #7)
> Created attachment 113982 [details] [review] [review]
> glmark2 jellyfish vertex shader patch
> 
> I confirm that this is happening in SNB (gen6) too.
> 
> I modified the jellyfish vertex shader (attached patch) to have the sin()
> function argument to be within the range of [0, 2*PI) radians by using the
> modulo operation. In this case, it renders fine.
> 
> I think this is the same problem explained here:
> 
> http://lists.freedesktop.org/archives/mesa-dev/2014-December/072429.html

Oh, I hadn't noticed your comment here. I came to the same conclusion just today when I was wondering about this again. I actually went and read throught the entire asm the vertex shader looking for an error, and when I didn't find one I figured it could be the sin(), so I cooked up some kind of kludge to fix it on the Mesa side. I could hve avoided all that if I'd checked this bug first :) But it was a good exercise anyway, learning a bit of gen asm and looking at the i965 compiler a bit.

Here's my hack for anyone interested:

diff --git a/src/mesa/drivers/dri/i965/brw_vec4_visitor.cpp b/src/mesa/drivers/dri/i965/brw_vec4_visitor.cpp
index 26a3b9f..85c8f69 100644
--- a/src/mesa/drivers/dri/i965/brw_vec4_visitor.cpp
+++ b/src/mesa/drivers/dri/i965/brw_vec4_visitor.cpp
@@ -343,8 +343,19 @@ vec4_visitor::emit_math(enum opcode opcode,
                         const dst_reg &dst,
                         const src_reg &src0, const src_reg &src1)
 {
-   vec4_instruction *math =
-      emit(opcode, dst, fix_math_operand(src0), fix_math_operand(src1));
+   vec4_instruction *math;
+
+   if (opcode == SHADER_OPCODE_SIN || opcode == SHADER_OPCODE_COS) {
+      dst_reg tmp = dst_reg(this, glsl_type::vec4_type);
+      emit(MUL(tmp, src0, brw_imm_f(1.0 / (2.0 * M_PI))));
+      emit(RNDZ(tmp, src_reg(tmp)));
+      emit(MUL(tmp, src_reg(tmp), brw_imm_f(2.0 * M_PI)));
+      emit(ADD(tmp, src0, negate(src_reg(tmp))));
+      math = emit(opcode, dst, fix_math_operand(src_reg(tmp)), fix_math_operand(src1));
+   } else {
+      math = emit(opcode, dst, fix_math_operand(src0), fix_math_operand(src1));
+   }
 
    if (brw->gen == 6 && dst.writemask != WRITEMASK_XYZW) {
       /* MATH on Gen6 must be align1, so we can't do writemasks. */

Oh and I should also note that glmark2 seems a bit silly here since it basically does something like "sin(gettimeofday() % ~28 hours)", meaning you get different looking results when you run it at different times. Which explains why my gen8 results were so inconsistent.

I'm going to mark this as a duplicate of bug 89634, after documenting the "errata" on the wiki.

*** This bug has been marked as a duplicate of bug 89634 ***