arb_shader_image_load_store/shader-mem-barrier: Add explicit memoryBarrier to volatile subtest.

This makes sure that reads and writes of the volatile-qualified images
occur in the expected order.  It's unclear whether the GLSL volatile
qualifier was intended to have the required memory ordering
implications as it would in C.  I've bugged Khronos about it [1], but
because I haven't seen any update on the bug report for a while, this
changes the test temporarily to behave as expected regardless of what
the resolution of the spec bug is.  This avoids some annoying
intermittent failures on the i965 driver which doesn't provide any
special memory ordering guarantees for volatile-qualified memory.

[1] https://cvs.khronos.org/bugzilla/show_bug.cgi?id=15875

Tested-by: Mark Janes <mark.a.janes@intel.com>

1 files changed, 3 insertions, 3 deletions

diff --git a/tests/spec/arb_shader_image_load_store/shader-mem-barrier.c b/tests/spec/arb_shader_image_load_store/shader-mem-barrier.c
index ed086403b..0c83ab726 100644
--- a/tests/spec/arb_shader_image_load_store/shader-mem-barrier.c
+++ b/tests/spec/arb_shader_image_load_store/shader-mem-barrier.c
@@ -31,8 +31,8 @@
  * locations until an inconsistency is observed or the test runs to
  * completion.
  *
- * The test is repeated for the "volatile" qualifier with no barriers,
- * for all execution stages and for different relative arrangements of
+ * The test is repeated for the "volatile" qualifier, for all
+ * execution stages and for different relative arrangements of
  * producer and monitor threads to account for implementations with
  * varying levels of parallelism and with caches of different sizes.
  *
@@ -84,7 +84,7 @@ struct image_test_info {
 const struct image_test_info image_tests[] = {
         { "control", "", "", true },
         { "'coherent' qualifier", "coherent", "memoryBarrier()", false },
-        { "'volatile' qualifier", "volatile", "", false },
+        { "'volatile' qualifier", "volatile", "memoryBarrier()", false },
         { 0 }
 };