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? > (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. > > 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
