[Mesa-dev] [RFC PATCH 1/2] r600/sb: Set flags for GROUP_BARRIER instruction and force it into slot X

[Nicolai Hähnle]

On 11.01.2018 12:22, Ilia Mirkin wrote:
> On Thu, Jan 11, 2018 at 3:51 AM, Gert Wollny <gw.fossdev at gmail.com> 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
> mesa-dev at lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/mesa-dev
> 


-- 
Lerne, wie die Welt wirklich ist,
Aber vergiss niemals, wie sie sein sollte.