On 24.06.2016 16:42, Alejandro Piñeiro wrote:
On 24/06/16 12:17, Nicolai Hähnle wrote:
Hi Alejandro,
Hi, thanks for the quick answer, more comments below.
my understanding of the spec is that the test should be correct as
originally written, i.e. with glTextureBarrier only between full
rectangle draws.
FWIW, radeonsi passes the test as-is
So on radeon-si all the 48 subtests (parameter combination of the base
test) passes correctly?
Yes, I ran piglit -t .*arb_texture_barrier.* and it reported 48 passes.
(though I reduced the GLSL version requirement, which I'd ask you to
change as well before you push the test).
It is ok to reduce the GLSL requirement from 440 to 400? If not I would
need to change the loop on the shader.
Yes, that works for me (and I guess nouveau as well).
Nicolai
Cheers,
Nicolai
On 24.06.2016 11:14, Alejandro Piñeiro wrote:
Gets the test passing for cases with low resolution, high amount
of triangles and more than one glDrawRangeElements (drawing_passes).
---
Just to catch attention, this issue also affects the failing CTS test
GL44-CTS.texture_barrier_ARB.same-texel-rw-multipass on Intel gen7+.
And sorry for the cross-posting, but usually questions related about
specs are more suited for mesa-dev.
The test I have just sent to piglit list fails in the following
scenario:
* Low resolution
* High amount of triangles on the square draw
* More than one glDrawRangeElements to render the square.
As this patch shows, the problem gets solved if I move the
glTextureBarrier call just after glDrawRangeElements, instead of
having it after each full square drawn.
But Im not sure if this should be needed if we strictly follow the
spec. The spec [1] even include a example of when the barrier would
not be needed on Issue 1. If what you are drawing doesn't intersect to
what you have been drawing before, you don't need to call
glTextureBarrier. Being strict, the test is drawing non intersecting
elements, as the triangles are independent one from the other. But it
is also true that this is somewhat debatable as the borders of the
triangles are shared, so with low resolution and a high amount of
triangles it can cause these artifacts.
So, opinions? Is this patch correct so the problem was on the piglit
test? Or this patch should not be needed so the problem is on the
implementation of arb_texture_barrier?
[1] https://www.opengl.org/registry/specs/ARB/texture_barrier.txt
tests/spec/arb_texture_barrier/blending-in-shader-arb.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/tests/spec/arb_texture_barrier/blending-in-shader-arb.c
b/tests/spec/arb_texture_barrier/blending-in-shader-arb.c
index 76822da..c84cfaf 100644
--- a/tests/spec/arb_texture_barrier/blending-in-shader-arb.c
+++ b/tests/spec/arb_texture_barrier/blending-in-shader-arb.c
@@ -318,6 +318,7 @@ draw_rect_tex()
glDrawRangeElements(GL_TRIANGLES, first, first +
count, count,
GL_UNSIGNED_INT,
BUFFER_OFFSET(first * sizeof(GLuint)));
+ glTextureBarrier();
first += count;
}
}
@@ -330,8 +331,6 @@ piglit_display(void)
glViewport(0, 0, width, height);
for (i = 0; i < blend_passes; i++) {
- if (i != 0)
- glTextureBarrier();
draw_rect_tex();
}
_______________________________________________
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
