Ken,
The defect depends on details of the shader compiler reusing registers.
Old register values are sometimes left in some channels when the
write-after-write hints are used.
Further reducing the GLSL test case would be tricky because the reuse of g8
would be likely to be changed.
I did already spend quite a long time reducing a larger shader to this
relatively small example.
The GLSL is not anyone's source code. It results from at least two levels
of machine translation and my own rewrite.
The difference in the resulting native code is now very simple.
The only difference from my patch is the presence of NoDDClr and NoDDChk
hints on the three math opcodes.
The results are then used by an opcode without any NoDDChk hinting.
With math data dependency hints in place the results are often incorrect.
They clearly don't work reliably.
(assign (x) (var_ref R_2) (swiz x (expression vec4 exp2 (swiz xxxx
(var_ref R_1) )) ))
0x00000570: math exp(8) g8<1>.xF g7<4,4,1>.xF null
{ align16 WE_normal NoDDClr 1Q };
(assign (y) (var_ref R_2) (swiz y (expression vec4 exp2 (expression
vec4 + (swiz yyyy (var_ref R_1) )(constant float (0x1.5798eep-27)) ) ) ))
0x00000580: add(8) g81<1>F g7<4,4,1>.yF 1e-08F
{ align16 WE_normal 1Q };
0x00000590: math exp(8) g8<1>.yF g81<4,4,1>F null
{ align16 WE_normal NoDDClr,NoDDChk 1Q };
(assign (z) (var_ref R_2) (swiz z (expression vec4 exp2 (swiz zzzz
(var_ref R_1) )) ))
0x000005a0: math exp(8) g8<1>.zF g7<4,4,1>.zF null
{ align16 WE_normal NoDDChk 1Q };
(assign (xyz) (var_ref gl_FrontColor) (expression vec3 * (swiz xyz
(var_ref R_2) )(constant vec3 (0.999999 0.999999 0.999999)) ) )
0x000005b0: mul(8) g4<1>.xyzF g8<4,4,1>.xyzzF 0.999999F
{ align16 WE_normal 1Q };
On Tue, Mar 18, 2014 at 4:05 PM, Kenneth Graunke <kenn...@whitecape.org>wrote:
> On 02/28/2014 02:35 PM, Mike Stroyan wrote:
> > Matt,
> >
> > You haven't replied to my mail with an updated shader test that shows
> > the math instructions alone causing trouble.
>
> I don't think Matt has time to do that. Could you please trim down your
> shader test to a smaller case which demonstrates the problem? As is,
> it's pretty large. It also looks like it was ripped directly out of
> someone's application, which makes us nervous about copyright infringement.
>
> > Do you now agree that my patch avoiding math instructions in
> > opt_set_dependency_control is the appropriate fix?
>
> I see no documentation indicating that there are bugs with dependency
> control and math instructions. I also don't see any workarounds for
> that in the Windows driver.
>
> --Ken
>
>
--
Mike Stroyan - Software Architect
LunarG, Inc. - The Graphics Experts
Cell: (970) 219-7905
Email: m...@lunarg.com
Website: http://www.lunarg.com
_______________________________________________
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
