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

[Alejandro Piñeiro]

On 24/06/16 20:59, Ilia Mirkin wrote:
> On Fri, Jun 24, 2016 at 2:56 PM, Alejandro Piñeiro <apinheiro at igalia.com> wrote:
>> On 24/06/16 17:15, Ilia Mirkin wrote:
>>> On Fri, Jun 24, 2016 at 10:42 AM, Alejandro Piñeiro
>>> <apinheiro at igalia.com> 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?
>>>>
>>>>> (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.
>>> Why not just use 330 so that it can run on all Intel GPUs? You just
>>> need GL_ARB_gpu_shader5 right (for "indirect" texture access)? That's
>>> supported on IVB+, and does not require fp64 support.
>> Sounds good, thanks for the suggestion. Just sent a v2 patch to the
>> piglit list downgrading the GLSL version need. Having said so, my
>> question about the spec is still in the air, although after Nicolai
>> feedback, it seems that the problem is on mesa for Intel drivers. Next
>> Monday will try to run the test with other drivers and cards, with and
>> without the patch.
> I haven't carefully read what your test does. But what
> NV_texture_barrier (and ARB_texture_barrier which is identical) do is
> allow you to rasterize each pixel at most once in between barriers,
> and still have the expectation that everything is OK. If your test
> causes any pixels to have overdraw, then that is going into undefined
> territory. If each pixel is only ever rasterized once between
> barriers, the output should be well-defined.

In theory they don't overdrawn. The test has a square formed by N
non-overlapping triangles. With just one call to glDrawRangeElements,
this always works. But if we split it in M subsets, so M calls to
glDrawRangeElements with N/M triangles per call, with low resolutions
and a high amount of triangles, some texels start to fail. And not
always the same amount of texels (so as you mentioned, undefined
territory). Although it is a guess, I assume that is cause for artifacts
on the triangle borders when drawing with so low resolution.

BR

BR