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 <apinhe...@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 _______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
