Summary: | [gen7][gen8] glmark2 -b jellyfish misrendered | ||
---|---|---|---|
Product: | Mesa | Reporter: | Ville Syrjala <ville.syrjala> |
Component: | Drivers/DRI/i965 | Assignee: | Ian Romanick <idr> |
Status: | RESOLVED DUPLICATE | QA Contact: | Intel 3D Bugs Mailing List <intel-3d-bugs> |
Severity: | normal | ||
Priority: | medium | CC: | eero.t.tamminen, siglesias |
Version: | git | ||
Hardware: | x86-64 (AMD64) | ||
OS: | Linux (All) | ||
URL: | https://dri.freedesktop.org/wiki/I965Errata | ||
Whiteboard: | |||
i915 platform: | i915 features: | ||
Attachments: |
Correct rendering on gen4
Incorrect rendering on gen7 glmark2 jellyfish vertex shader patch |
Description
Ville Syrjala
2014-11-26 21:31:12 UTC
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. |
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.