The i965 driver has a pass that merges comparisons with zero into the
instruction that generated the result. For example:
add tmp x y
cmp.ge.f0 null tmp 0.0
is optimized into
add.ge.f0 tmp x y
If the types of tmp are different in the add and cmp, comparisons
against zero might not work the same. For instance if the addition is on
unsigned integers, they may generate a result of 0x80000000 which is
-0.0 reinterpreted as a float.
I think this test triggers the same bug as this bug report.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=89317
---
...s-unsigned-comparison-negative-zero.shader_test | 37 ++++++++++++++++++++++
1 file changed, 37 insertions(+)
create mode 100644
tests/shaders/glsl-fs-unsigned-comparison-negative-zero.shader_test
diff --git
a/tests/shaders/glsl-fs-unsigned-comparison-negative-zero.shader_test
b/tests/shaders/glsl-fs-unsigned-comparison-negative-zero.shader_test
new file mode 100644
index 0000000..13c224f
--- /dev/null
+++ b/tests/shaders/glsl-fs-unsigned-comparison-negative-zero.shader_test
@@ -0,0 +1,37 @@
+[require]
+GLSL >= 1.30
+GL_ARB_shader_bit_encoding
+
+[vertex shader passthrough]
+
+[fragment shader]
+#extension GL_ARB_shader_bit_encoding: require
+
+out vec4 frag_color;
+
+uniform uint a, b;
+
+void main()
+{
+ /* Adding a + b yields 0x80000000, which when reinterpreted as a float
+ * is -0.0. -0.0 == +0.0 is true, but if we did the comparison against
+ * the unsigned value it would incorrectly be false.
+ */
+ if (uintBitsToFloat(a + b) == 0.0)
+ frag_color = vec4(0.0, 1.0, 0.0, 1.0);
+ else
+ frag_color = vec4(1.0, 0.0, 0.0, 1.0);
+}
+
+[vertex data]
+piglit_vertex/float/2
+-1.0 -1.0
+ 1.0 -1.0
+ 1.0 1.0
+-1.0 1.0
+
+[test]
+uniform uint a 0x40000000
+uniform uint b 0x40000000
+draw arrays GL_TRIANGLE_FAN 0 4
+probe all rgba 0.0 1.0 0.0 1.0
--
2.0.5
_______________________________________________
Piglit mailing list
Piglit@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/piglit
