[Piglit] [Mesa-dev] [RFC PATCH] arb_texture_barrier: call glTextureBarrier after each glDrawRangeElements
Alejandro Piñeiro
apinheiro at igalia.com
Mon Jun 27 10:36:57 UTC 2016
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.
BR
More information about the Piglit
mailing list