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

[Nicolai Hähnle]

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