09:17 <tomeu> lynxeye: wonder what is the best way to refuse to create an EGL context on a NPU

09:23 <tomeu> it's funny how vivante goes to great lengths to obfuscate the programming of the HW, then have to add comments to help themselves make sense out of the code

09:34 <lynxeye> tomeu: I think we'll end up exposing the NN/TP core number as device parameters in the UAPI. Then it should just be a matter of checking those for != 0 in the etnaviv winsys to avoid creating EGL contexts on those cores.

09:35 <lynxeye> Yea, I think their obfuscator just ignores comments, so they go through unfiltered.

09:53 <tomeu> ok, makes sense

09:53 <tomeu> btw, I'm trying to figure out why we don't get interrupts when a job finishes, as that is making running test suites very slow

09:54 <tomeu> I'm decoding the ops in gckWLFE_Event as I suspect that is what the blob uses to signal job fences

10:00 <lynxeye> tomeu: Did you try sending the event from the FE? Normally we use events from PE, but I can't remember if this works with the NPU cores.

10:00 <tomeu> that's what I'm trying to figure out right now

10:01 <tomeu> guess that should be done with etnaviv_sync_point_queue

10:03 <lynxeye> tomeu: Nope, sync points are only used for the performance profiling. What you want to look at is the event queued in etnaviv_buffer_queue()

10:04 <tomeu> ah, I see

10:04 <tomeu> so VIVS_GL_EVENT_FROM_PE might not be correct in this case

10:05 <lynxeye> tomeu: right. Maybe the NPU can not send the event from PE, as technically there is no PE. Sending from FE should work.

10:07 <lynxeye> However the FE might reach that send event command before the core is done with whatever it is doing.

10:08 <lynxeye> So you might need to insert a FE stall until the NN cores are done.

10:08 <tomeu> hmm, interesting, will check that galcore does

10:25 <tomeu> damn

10:26 <tomeu> so I don't know why, but this doesn't happen with the code that was sent to the ml

10:26 <tomeu> only on my 5.17 branch

10:26 <tomeu> with the main difference being the power up sequence

10:29 <lynxeye> Huh? What are you doing differently in the power up sequence?

10:32 <tomeu> lynxeye: this is how I was doing it before cleaning up for upstreaming: https://gitlab.freedesktop.org/tomeu/linux/-/commit/af365186ab305d2fa3e91145ac79d2569b9df2a5

10:39 <lynxeye> Ah, I have no idea how the power domains on Amlogic SoCs are working. But PDs are always "fun" to deal with.

10:39 <tomeu> yeah, or maybe it has been some side effect of the code reorganization

14:08 <tomeu> lynxeye: I think the difference might be something in hdwb

14:08 <tomeu> *hwdb