On 24/06/16 20:59, Ilia Mirkin wrote: > On Fri, Jun 24, 2016 at 2:56 PM, Alejandro Piñeiro <apinhe...@igalia.com> > wrote: >> On 24/06/16 17:15, Ilia Mirkin wrote: >>> On Fri, Jun 24, 2016 at 10:42 AM, Alejandro Piñeiro >>> <apinhe...@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 _______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
