| Summary: | [NVE0+] Failure to insert texbar under some circumstances (causing bad colors in Terasology) | ||
|---|---|---|---|
| Product: | Mesa | Reporter: | Ilia Mirkin <imirkin> |
| Component: | Drivers/DRI/nouveau | Assignee: | Nouveau Project <nouveau> |
| Status: | RESOLVED FIXED | QA Contact: | Nouveau Project <nouveau> |
| Severity: | normal | ||
| Priority: | medium | ||
| Version: | git | ||
| Hardware: | Other | ||
| OS: | All | ||
| Whiteboard: | |||
| i915 platform: | i915 features: | ||
| Attachments: | terasology.tgsi | ||
Should be fixed by commit a2af42c1d2dc91f4c31e25ff9fff15a89a9b6ead Author: Ilia Mirkin <imirkin@alum.mit.edu> Date: Fri Jun 12 16:09:05 2015 +0200 nvc0/ir: fix collection of first uses for texture barrier insertion One of the places we have to insert texbars is in situations where the result of the tex gets overwritten by a different instruction (e.g. in a conditional statement). However in some situations it can actually appear as though the original tex itself is an overwriting instruction. This can naturally never really happen, so just ignore the tex instruction when it comes up. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=90347 Signed-off-by: Ilia Mirkin <imirkin@alum.mit.edu> Cc: "10.5 10.6" <mesa-stable@lists.freedesktop.org> |
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.
Created attachment 115602 [details] terasology.tgsi The problem is that the attached shader compiles to: ... 34: mov u32 $r0 $r3 (8) 35: mov u32 $r1 $r5 (8) 36: tex 2D $r0 $s0 f32 $r0t $r0d (8) 37: join mov u32 $r7 $r1 (8) BB:3 (4 instructions) - idom = BB:0, df = { BB:4 } -> BB:4 (forward) 38: mov u32 $r0 $r3 (8) 39: mov u32 $r1 $r5 (8) 40: tex 2D $r1 $s0 f32 $r0t $r0d (8) 41: join mov u32 $r7 $r1 (8) ... And there is no texbar before the mov happens. This causes funky rendering in Terasology. Somehow things get merged during RA s.t. the findFirstUses logic decides that the tex itself is a use (it isn't!) and so it never picks up on the actual use in that BB (since there's a check to make sure that we only pick the earliest use in a BB). This much shorter shader reproduces a similar issue as well: FRAG DCL IN[0], COLOR, COLOR DCL OUT[0], COLOR DCL OUT[1], COLOR[1] DCL SAMP[0] DCL SAMP[1] DCL TEMP[0..4], LOCAL IMM[0] FLT32 { 0.0010, 1.0000, 0.0000, 2.5000} 5: MOV TEMP[0].xy, IN[0].xyxx 7: FSLT TEMP[2].x, IMM[0].yyyy, IN[0].xxxx 10: UIF TEMP[2].xxxx :0 30: TEX TEMP[1], TEMP[0], SAMP[0], 2D 32: ELSE :0 34: TEX TEMP[1], TEMP[0], SAMP[1], 2D 36: ENDIF 47: UIF TEMP[2].xxxx :0 50: MUL TEMP[1], TEMP[1], IMM[0].xyyy 54: ENDIF 84: MOV TEMP[0].xyz, TEMP[1].xyzx 93: MOV TEMP[1].xyz, TEMP[0].wwww 94: MOV OUT[0], TEMP[0] 95: MOV OUT[1], TEMP[1] 97: END