https://bugs.freedesktop.org/show_bug.cgi?id=71944
--- Comment #2 from Vadim Girlin <pt...@yandex.ru> --- (In reply to comment #0) > If I revert that commit the test passes with SB, but I'm pretty sure that > commit only exposed a bug that weren't hit before. Yes, I think you are right. > > I looked at the shader dumps and the only thing I found that looked a little > strange was this. > > before: 7ae9cc71f097af5ae1f83f77f75de2198849faca > z: SETE T0.z, R[2+AR].y, KC0[2].y > w: SETE T1.w, R[2+AR].z, KC0[2].z > x: SETE T1.x, R[2+AR].x, KC0[2].x > > after: 7ae9cc71f097af5ae1f83f77f75de2198849faca > w: SETE_DX10 T0.w, R[2+AR].z, KC0[2].z > z: SETE_DX10 T0.z, R[2+AR].y, KC0[2].y > x: SETE_DX10 T1.x, R[0+AR].x, KC0[2].x > > Is R[0+AR].x correct in the last line or should it be R[2+AR].x? It's not necessarily incorrect, IIRC components of the indirectly addressed array are considered as separate arrays by sb, they are allocated independently and may have different base GPR indices, e.g. yz components of the original array may be stored in R2.yz-R10.yz (if R0.yz and/or R1.yz are used for something else) and x component in R0.x-R8.x. AFAICS the problem is here: 0106 12 x: MOV R1.x, [0x40800000 4].x 0108 y: MOV R2.y, [0x40000000 2].y 0110 z: MUL T0.z, KC0[3].w, R1.x 0112 w: MUL T1.w, KC0[3].z, R1.x 0114 40800000 0115 40000000 0116 13 x: MOV R0.x, 1.0 0118 y: MUL T0.y, KC0[3].x, R1.x Instruction 0106 writes 4 to R1.x, but instruction 0118 in the next group expects old value in R1.x (the value that was in R1.x before 0106). So it looks like scheduler failed to handle that data dependency correctly for some reason, instruction 0118 should be scheduled in the same group as 0106 or earlier. Please attach the output with R600_DEBUG=vs,sbdump -- You are receiving this mail because: You are the assignee for the bug.
_______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
