Created attachment 141984 =
[details]
rv610 sbdump
I'm debugging some graphics corruption in Chromium on an iMac7,1 with rv610
graphics. Basically an area of the application has randomish blocks of colo=
r,
like it's reading from an uninitialized texture.
I've narrowed the problem down to a fragment shader:
varying mediump vec2 _uv_texCoord;
uniform lowp sampler2D _ulut_texture;
uniform mediump float _ulut_size;
mediump vec4 _uLUT(in lowp sampler2D _usampler, in mediump vec3 _upos, =
in
mediump float _usize){
(_upos *=3D (_usize - 1.0));
mediump float _ulayer =3D min(floor(_upos.z), (_usize - 2.0));
(_upos.xy =3D ((_upos.xy + vec2(0.51234001, 0.51234001)) / _usize));
(_upos.y =3D ((_upos.y + _ulayer) / _usize));
return mix(texture2D(_usampler, _upos.xy), texture2D(_usampler, (_upo=
s.xy
+ vec2(0, (1.0 / _usize)))), (_upos.z - _ulayer));
}
void main(){
mediump vec2 _utexCoord =3D _uv_texCoord;
mediump vec4 _utexColor =3D texture2D(_us_texture, _utexCoord);
if ((_utexColor.w > 0.0))
{
(_utexColor.xyz /=3D _utexColor.w);
}
(_utexColor.xyz =3D _uLUT(_ulut_texture, _utexColor.xyz, _ulut_size).=
xyz);
(_utexColor.xyz *=3D _utexColor.w);
(gl_FragColor =3D vec4(_utexColor.xyz, 1.0));
}
(Note that in the original shader "0.51234001" is just "0.5&=
quot;, I just changed it
to make grepping easier.) I played around with changes to the _uLUT functio=
n,
and I found that any mixing of the two samples seems to trigger the bug, e.=
g. I
can mix with a constant 0.5 and the bug still happens. I also tried replaci=
ng
"mix" with an explicit a*(x-1)+b*x; no change.
I found that disabling SB fixed the issue, and in particular just commenting
out the "if_conversion" SB pass fixes the issue.
I've attached the full sbdump output. Please let me know if there are more
details I can provide that would help.