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

Ilia Mirkin imirkin at alum.mit.edu
Mon Jun 27 16:12:34 UTC 2016

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.


More information about the Piglit mailing list