06:30 <icecream95> Uh oh... it appears that the wait for soft-stop completion can be bypassed while jobs are still active?

06:31 <icecream95> panfrost_active_slots doesn't seem to be getting called at all, but maybe GCC inter-procedural optimisations moved some of the code up into panfrost_reset

07:12 <icecream95> Is it correct for JOB_INT_JS_STATE to be read?

07:12 <icecream95> According to kbase it is a "snapshot from last JOB_IRQ_CLEAR"

07:24 <icecream95> Here's a question: Do we really need to stop all jobs when only one job needs reset? Can't the job causing the reset be stopped, then other jobs get stopped only if the first job doesn't soft-stop?

07:27 <icecream95> Sticking in a `job_write(pfdev, JOB_INT_CLEAR, 0x70007)` before cancelling the jobs fixes all this, but I don't know if it's the right solution

07:40 <icecream95> 'Exception Status: 3' The soft-stop worked! But panfrost_job_handle_err never gets called to take care of it

08:26 <stepri01> icecream95: Panfrost's handling of errors isn't great - there is no need to reset the GPU in most cases (e.g. kbase only does it on certain GPUs due to errata). However job faults are usually very rare (and point to user space bugs) so the current situation is usually fine

08:27 <stepri01> the JOB_INT_JS_STATE in readl_poll_timeout certainly looks suspicious - as you say the register is latched on the last JOB_IRQ_CLEAR so polling on it doesn't seem right

15:15 <alyssa> panvk is creating 468 shaders on start!

15:16 <alyssa> no wonder startup time hurts so much :(

15:16 <alyssa> s/creating/compiling/

15:18 <macc24> alyssa: can i now test some vulkan programs and complain^W report if they don't work on panvk?