Am Donnerstag, den 11.01.2018, 08:18 +1000 schrieb Dave Airlie: > > > The number of writes is the same though, and as far as I can tell > > from the TGSI, the values written to LDS before the barrier are not > > read back within the shader - which makes me wonder whether the > > barrier is actually necessary.
It is as I suspected, if sb is not run, removing the barrier by just not emitting it in the "from_tgsi" stage doesn't have a visual impact on the built-in Tomb Raider 2013 benchmark, but enabling sb creates a lot of artefacts. (The performance did not really improve, btw). In fact, removing the barrier like this doesn't have an impact on any of the tessellation/barrier piglits, they all still pass. On the other hand, if I allow the barrier to be scheduled in any slot it breaks all of these piglits, probably because I get some scheduling like: 000fa07c 00002284 34 M x: PRED_SETNE_INT __.x, T0.x, T1.x 80000000 20002a00 y: GROUP_BARRIER __.y (That's why I thought forcing it into slot X is required). > probably needs a dep on the LDS_RW stuff. This is what I also expected and I was surprised that the piglits actually passed with my simple fix, now I gather that Ilia is right, and the barrier can be dropped altogether - at least for TCS. Best, Gert _______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
