Re: [Piglit] [PATCH 0/23] Port glsl1 Glean test to Piglit

[Brian Paul]

On 11/23/2017 01:44 PM, Fabian Bieler wrote:

This series replaces the "glsl1" Glean test with some Piglit tests.

Most tests were replaced by shader_runner tests.

The tests for built-in-uniform state were extended.

Some of the preprocessor tests were modified to make them stricter.

To port some texture tests shader_runner had to be extended with
"texture rgbw 1D" and "texture rgbw 3D" commands.
These (and the underlying piglit-util-functions) are very basic and
don't allow for variable texture size or pixel format. If desired, I can
remedy that.

Some tests ("Global vars and initializers", "Global vars and
initializers (2)", "Swizzle", "Writemask") are pretty trivial. I doubt
they would break without some existing, more complex Piglit test
failing, too. However, I opted to port them regardless since I couldn't
find an existing simple Piglit test for the feature in question.

Attached is a list of all Glean GLSL subtests with the location of the
new or existing Piglit test that replaces it.

Patch 23 fixes an unrelated test.


I did a quick read-through and the series looks OK to me.  I presume 
there's no compiler warnings and all the tests pass/fail as the glean 
tests did.


If there's no other comments in a few days, I can push the series.

Reviewed-by: Brian Paul 

___
Piglit mailing list
Piglit@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/piglit

[Piglit] [PATCH] cl: Add test for MUBUF access with a negative vaddr

[Matt Arsenault]

Explanation in test comment.
---
 .../program/execute/amdgcn-mubuf-negative-vaddr.cl | 62 ++
 1 file changed, 62 insertions(+)
 create mode 100644 tests/cl/program/execute/amdgcn-mubuf-negative-vaddr.cl

diff --git a/tests/cl/program/execute/amdgcn-mubuf-negative-vaddr.cl 
b/tests/cl/program/execute/amdgcn-mubuf-negative-vaddr.cl
new file mode 100644
index 0..21f11bf66
--- /dev/null
+++ b/tests/cl/program/execute/amdgcn-mubuf-negative-vaddr.cl
@@ -0,0 +1,62 @@
+>/*!
+
+[config]
+name: MUBUF stack addressing behavior
+clc_version_min: 10
+
+[test]
+name: MUBUF negative buffer offsets
+kernel_name: negative_mubuf_vaddr
+dimensions: 1
+global_size: 16 0 0
+
+arg_out: 0 buffer int[16]\
+  5 5 5 5 \
+  5 5 5 5 \
+  5 5 5 5 \
+  5 5 5 5
+
+!*/
+
+// Prior to gfx9, MUBUF instructions with the vaddr offset enabled
+// would always perform a range check. If a negative vaddr base index
+// was used, this would fail the range check. The overall address
+// computation would compute a valid address, but this doesn't happen
+// due to the range check. For out-of-bounds MUBUF loads, a 0 is
+// returned.
+//
+// Therefore it should be safe to fold any VGPR offset on gfx9 into
+// the MUBUF vaddr, but not on older subtargets which can only do this
+// if the sign bit is known 0.
+kernel void negative_mubuf_vaddr(global int* out0)
+{
+volatile int array[16];
+
+int id = get_global_id(0);
+for (int i = 0; i < 16; ++i)
+{
+array[i] = i + 1;
+}
+
+// Directly addressing the same buffer address works without using vaddr:
+//
+// buffer_load_dword v2, off, s[0:3], s11 offset:20
+// out0[id] = array[4];
+
+
+// But having a negative computed base index would fail:
+// v_mov_b32_e32 v0, -8
+// v_lshlrev_b32_e32 v0, 2, v0
+// v_add_i32_e32 v0, vcc, 4, v0
+// buffer_load_dword v2, v0, s[0:3], s11 offen offset:48
+
+#ifdef __AMDGCN__
+// Obscure the value so it can't be folded with other constant or
+// make known bits assumptions.
+int offset;
+__asm volatile("v_mov_b32 %0, -8" : "=v"(offset));
+#else
+int offset = -8;
+#endif
+out0[id] = array[offset + 12];
+}
-- 
2.11.0

___
Piglit mailing list
Piglit@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/piglit