On 11.01.2018 12:22, Ilia Mirkin wrote:
On Thu, Jan 11, 2018 at 3:51 AM, Gert Wollny <[email protected]> wrote:
Am Donnerstag, den 11.01.2018, 08:09 +0100 schrieb Gert Wollny:
Am Mittwoch, den 10.01.2018, 15:27 -0500 schrieb Ilia Mirkin:
[...]
If your hardware executes all the vertices in parallel, then a
barrier should be unnecessary.
My first try for this patch did not include forcing the barrier into
slot x, which in turn resulted in failing piglits, e.g.
tcs-output-array-float-index-rd-after-barrier
and I'm quite confident that the LDS r/w order was not broken - also
because just forcing the barrier into slot x fixed it, so I guess not
all vertices are always processed in parallel, which is also no
surprise since the number of shader units attributed to the TCS stage
is limited.
Dropping the barrier altogether doesn't have an impact on the
tesselation/barrier piglits, but I still wonder what happens if there
are more vertices to be processed than there are shader units so that
they can not be processes in parallel ...
The max vertices in a patch is 32, so that is generally within a
hardware's ability to do in a single wave. If it's not, then you
definitely need a barrier.
At least on GCN, tessellation control shaders run multiple waves
together in a workgroup, and if the number of invocations per patch
doesn't cleanly divide 64 (the wave size), the patch will cross a wave
boundary. Not sure if that applies to pre-GCN chips as well, but it
could contribute to explaining some of the perceived weirdness.
Cheers,
Nicolai
-ilia
_______________________________________________
mesa-dev mailing list
[email protected]
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
--
Lerne, wie die Welt wirklich ist,
Aber vergiss niemals, wie sie sein sollte.
_______________________________________________
mesa-dev mailing list
[email protected]
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
