05:36 <daniels> alyssa: l for low-power or lite?

09:49 <icecream95> alyssa: I'm sometimes also seeing barrier_shared when using highp: https://gitlab.freedesktop.org/snippets/1021/raw

13:54 <alyssa> daniels: Possible, yeah

13:55 <alyssa> icecream95: hrm

14:38 <alyssa> icecream95: Well, there goes my theories :|

14:38 <alyssa> Could be another source, but I doubt it.

14:39 <alyssa> Could control out-of-order execution.

14:54 <alyssa> I'm super suspecting out-or-order execution, tbh.

14:54 <alyssa> BASE_HW_FEATURE_OUT_OF_ORDER_EXEC began with T760

14:54 <alyssa> (And then through the rest of Malis)

15:04 <alyssa> Ahhhhh yes!

15:04 <alyssa> Notice after a .barrier_buffer is *always* a ld/st

15:04 <alyssa> and after a .barrier_shared is *always* an ALU

15:05 <alyssa> and we know that the limited ooo execution is tex simultaneous with alu or ld/st

15:05 <alyssa> and that the next bundle in marked ones don't have a dependency on that last tex op

15:06 <alyssa> actually no

15:06 <alyssa> https://gitlab.freedesktop.org/snippets/1020/raw

15:06 <alyssa> ^ first shader here pokes a whole in that

15:06 <alyssa> *hole

15:07 <alyssa> well, sort of

15:07 <alyssa> The next op there reads only from the first tex, so the ALU/ldst distinction is wrong

15:07 <alyssa> but the ooo semantic is still ok

15:10 <alyssa> texture.2d.cont hr28', texture3, fsampler3, r28.zwzz,

15:10 <alyssa> vmul.fmul hr24.xyzw, hr0.xyzwefgh, hr29.efghefgh

15:10 <alyssa> lut.fmul hr0.xyzw, hr24.xyzwefgh, hr28.xyzwefgh

15:10 <alyssa> ^ This one pokes a whole in *that*. But maybe the dependency is at a register level. So even though it doesn't actually depend, it still needs to wait for hr28 to flush completely to be safe.

15:13 <alyssa> Oh, and then .barrier_shared is indicating ALU followed by ldst, neither of which depends

15:13 <alyssa> (though the ldst may depend on the ALU)

15:21 <alyssa> Ahhh, even better.

15:21 <alyssa> I managed to trigger both buffer and shared at once

15:21 <alyssa> when there were 3 ops (all ALU in this case) pending

15:21 <alyssa> so it's really a 2-bit field counting how many cycles ahead it's safe to proceed.

15:41 <austriancoder> short question regarding perfcounters: I am correct with the following statement: the gpu gets configured (wanted counters and bo address) and you can trigger read-out via register and/or cmd stream and gpu stores all the values into the configured buffer?

16:11 <alyssa> austriancoder: register, and yes.

16:11 <alyssa> global, not per-process/job/draw anything

16:52 <austriancoder> alyssa: do you have a perfetto trace somewhere you can share? Would like to see how such a trace looks in the UI (with panfrost perf counter)

16:52 <daniels> shadeslayer: ^ also

16:53 <alyssa> austriancoder: personally I don't have it setup but yes I have shadeslayer 's somewhere

17:04 <alyssa> panfrost-t760-gles2:armhf: success

17:04 <alyssa> \o/

17:19 <nlhowell> congrats! :D

17:19 <daniels> wooha

17:19 <daniels> is this barrier opt, or?

17:20 <alyssa> daniels: fp16

17:20 <daniels> neato!

17:20 <alyssa> which I can land now if I weren't distracted with Manhtaan

17:20 <alyssa> *Manhattan