06:22daniels: lumag: thanks, hopefully mupuf can get the executor fixed
06:28mupuf: yep! I rebooted the gateway and things started working again
06:28mupuf: can't wait to give the gitlab runner the 👢
08:25airlied: glehmann: https://github.com/KhronosGroup/SPIRV-Registry/pull/375 fyi
17:16ngcortes: anholt, qq; does deqp-runner have built-in gpu hang recovery for testing?
17:16anholt: ngcortes: no, gpu hang recovery is the job of the kernel.
17:17ngcortes: anholt, right, I meant more like if other tests are running when a gpu hang occurs one one job thread, wouldn't there be a period of time in which any other tests running would fail until the gpu resets?
17:18anholt: ngcortes: unless your kernel is actually processing multiple queues simultaneously such that an innocent and guilty app can get reset at the same time, then that shouldn't be possible.
17:19anholt: though I can see how implementations not using the common gpu scheduler might be bad at killing innocent apps
17:20ngcortes: anholt, this is all vis a vis the anvil driver
17:20ngcortes: which I'm currently testing with deqp-runner
17:21anholt: so, with a good kernel, the case that things leak from one test into another is setting some gpu state that doesn't get reset properly on process switch (you forgot to set some state in your init function). basically all we could offer in that case is logging which caselists are running simultaneously for a flaked test, so you could try just running those in parallel again to reproduce the flake.
17:21anholt: I think there's an issue open for that, or something closely related, but nobody's stepped up.
17:23anholt: (for me, I usually just run the flake test in a loop alongside a whole CTS deqp-runner run, and often a corresponding flake will show up in the CTS for the associated test)
17:28ngcortes: anholt, thanks. that makes sense!
17:32ngcortes: anholt, when you say "init" function are you referring to the driver or the initial conditions of the test run?
17:33anholt: ngcortes: meaning the chunk of command stream you do for setting up the gpu for your process. (though sometimes it's a piece of command stream you don't always need, but is referenced by some other enable bit, so it's not always the init command stream).
17:35ngcortes: anholt, I see, thanks