15:09 <bbrezillon> alyssa: pancsf is definitely at fault here

15:09 <bbrezillon> I'll try to reproduce locally

15:11 <alyssa> bbrezillon: thanks :)

15:46 <alyssa> bbrezillon: In general, given the state of brokennness on our mesa tree, deqp-runner is an excellent way to fuzz pancsf ;)

15:48 <bbrezillon> fair enough

15:49 <bbrezillon> just didn't get that far yet

15:49 <alyssa> understood yeah

17:06 <bbrezillon> alyssa: don't know if that solves your problem, but I messed up when transitioning the group pool to an xarray => https://gitlab.freedesktop.org/bbrezillon/linux/-/commit/a1eb75c4906507a2e14dd2f057707fe503967059

18:03 <alyssa> alright, thanks :-)

18:50 <bbrezillon> alyssa: got a full deqp-gles2 run passing without a hang

18:50 <cphealy> When comparing the Mali DDK with Mesa on Mali G52, I'm seeing that GL_SAMPLES supports 16, 8, and 4 as valid values with the Mali DDK while Mesa is only advertising support for 4. Is this due to a constraint with Mesa or just that 4x is the only one ever tested with and implemented?

18:51 <alyssa> !!!

18:51 <alyssa> wait, passing?

18:51 <bbrezillon> no, not passing

18:51 <alyssa> okay yeah that's what I thought, I saw a lot of flakes

18:51 <bbrezillon> I mean, no platform hang

18:51 <alyssa> :+1:

18:52 <alyssa> (Unsure if the flakes are kernel or mesa, tbh.)

18:52 <alyssa> (Although I think it was slightly less flaky on kbase..)

18:53 <bbrezillon> alyssa: Pass: 7037, Fail: 3200, Warn: 40, Skip: 84, Timeout: 4, Flake: 6094, Duration: 45:27, Remaining: 0

18:53 <alyssa> 45 minutes?!

18:57 <bbrezillon> don't know if that's related, but no devfreq in pancsf, didn't check what the default GPU clk freq is

18:59 <bbrezillon> 198MHz

18:59 <bbrezillon> how long does it take on kbase?

19:03 <bbrezillon> kbase being less flaky could be explained by the fact we consider the group as faulty/unusable as soon as one timeout or fatal fault happens, and we don't have code to recover in mesa (we should destroy the group and create a fresh one when that happens)

19:07 <alyssa> Hmm, I think I was seeing flakiness even without faults

19:07 <alyssa> Just running a few deqp test back to back, pass/fail would flake around

19:08 <alyssa> missing synchronization is my guess, or maybe cache coherency

19:15 <bbrezillon> hm, I see you had a CACHE_FLUSH instruction before the CALL in the kbase drm-shim

19:15 <bbrezillon> I definitely don't have that kernel side

19:16 <bbrezillon> might be worth trying to map all BOs GPU_UNCACHED

19:17 <alyssa> yeah, the CACHE_FLUSH before the CALL was necessary

19:17 <bbrezillon> (the CS buffers should be mapped UNCACHED already)

19:18 <bbrezillon> well, the CACHE_FLUSH is needed if buffers are mapped GPU-cacheable, but I kept things simple and mapped those buffers uncacheable

19:19 <bbrezillon> *if CS buffers are mapped GPU-cacheable

19:21 <alyssa> I, uh, I do recommend caching the linear buffers :-p

19:30 <bbrezillon> I'm not saying they shouldn't be cached, just pointing out that they were not in my branch

23:17 <cphealy> Does the Panfrost shader compiler support the use of "fma" even though the GLSL version is 3.10?