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

[Alejandro Piñeiro]

On 27/06/16 18:12, Ilia Mirkin wrote:
> On Mon, Jun 27, 2016 at 6:36 AM, Alejandro Piñeiro <apinheiro at igalia.com> wrote:
>>
>> On 27/06/16 12:33, Alejandro Piñeiro wrote:
>>> On 27/06/16 03:08, Grazvydas Ignotas wrote:
>>>> On Sat, Jun 25, 2016 at 4:54 PM, Alejandro Piñeiro <apinheiro at igalia.com> wrote:
>>>>> 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.
>>>> Perhaps this is somehow related to this bug:
>>>> https://bugs.freedesktop.org/show_bug.cgi?id=96624
>>>> There a texture problem shows up after one of glDrawRangeElements
>>>> calls with a lot of primitives.
>>> Not sure if they are related. Note that the issue I mention gets fully
>>> solved with glTextureBarrier and additionally, it happens on haswell too.
>>>
>>> In any case, reading that bug gave me an idea. I have been toying with
>>> MESA_DEBUG=flush (that until your email I didn't know that exists).
>>> Looking at the code, it adds the equivalent to a glFlush after each
>>> drawing call. Using it gets the test (all 48 subtests) passing. So right
>>> now Im more biased to think that is an issue on glTextureBarrier.
>> Another hint towards being an issue on glTextureBarrier implementation:
>> if instead of using MESA_DEBUG=flush, I replace glTextureBarrier for
>> glFlush on the original test (so one full flush after all the square,
>> but not after each drawing call) all the subtests keep passing too.
> I flipped ARB_texture_barrier on for i965 based on comments that
> others made about how the hw worked. I don't think anyone was *too*
> sure that it was correct, but the tests (at the time) passed, so I
> don't think anyone gave it much more thought. Commit 71e187430c, ftr.

Yes, I already found that one while researching. I found more
interesting the annotate section when you sent the patch:
https://lists.freedesktop.org/archives/mesa-dev/2015-August/091632.html

On that section you mention that the test passes even without the flush.
FWIW, with the new detailed test I sent last week to the mailing list,
if the glTextureBarrier call on the test is removed, it goes from 5-6
failed subtest to 12 failed subtests (out of 48). So I think that that
patch was a step in the correct direction.

FWIW2, if I replace the call to brw_emit_mi_flush with a call to
intel_batchbuffer_flush all the subtests passes correctly, but probably
that is an overkill. Before suggesting that change, I will check if it
is possible to solve it on the call of brw_emit_mi_flush.

BTW, this is a way to say that I NAK my own piglit patch. At this moment
I think that it is something to be solved on the mesa side.

BR