02:53 <MoeIcenowy> https://github.com/Icenowy/thead-kernel/tree/etnaviv-exp my code to run GC620 (unfortunately it's based on the downstream kernel

02:53 <MoeIcenowy> the mainline th1520 support still lacks clock tree driver

08:45 <tomeu> I'm seeing substantial flakiness after having implemented a cache in my test suite that means that jobs are submitted much faster to the NPU

08:45 <tomeu> this flakiness increases as I increase parallelism in deqp-runner

08:47 <tomeu> has anybody else noticed this? wonder how often people have more than one job queued in the kernel

08:54 <tomeu> hmm, guess that with deqp, the HW is quite idle as the tests first sw render to have something to compare the HW results with

08:55 <tomeu> there was some thoughts on caching the deqp golden renders, but I don't know if anybody started working on that

11:32 <tomeu> ok, seems to be correlated to jobs submitted in quick succession, as it doesn't happen right after boot or after dropping the fs caches

11:32 <tomeu> as the cache is on NFS along with the rest of the rootfs, I guess having to access the cache via the network serializes things enough to not hit the bug

11:34 <tomeu> so "echo 3 > /proc/sys/vm/drop_caches" before running deqp-runner gives me reliable runs

11:45 <tomeu> this is on 5.17, btw