[Mesa-dev] [RFC PATCH] arb_texture_barrier: call glTextureBarrier after each glDrawRangeElements

[Alejandro Piñeiro]

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();
>>           }
>>
>>
>