09:18 <lynxeye> austriancoder: Did you hit the blitter recursion on GC2000? If so, the first patch from !19991 will probably fix it.

10:28 <austriancoder> lynxeye: it fixes the problem I have seen and started to look into - thanks

11:36 <lynxeye> tomeu: Do you know if there is a specific feature bit for the NN cores being present, which is what makes a NPU a NPU instead of a GPGPU. IIRC the downstream driver just has a separate entry in the HWDB for the number of NN cores.

11:37 <tomeu> hmm, I think I saw something like that, let me check

11:41 <tomeu> else if (gckHARDWARE_IsFeatureAvailable(hardware, gcvFEATURE_NN_ENGINE)

11:41 <tomeu> || gckHARDWARE_IsFeatureAvailable(hardware, gcvFEATURE_TP_ENGINE)

11:41 <tomeu> )

11:41 <tomeu> {

11:41 <tomeu> hardware->type = gcvHARDWARE_VIP;

11:41 <tomeu> }

11:43 <tomeu> in the downstream driver I have, TP_ENGINE is used

11:43 <tomeu> which I think corresponds to:

11:43 <tomeu> drivers/gpu/drm/etnaviv/common.xml.h:#define chipMinorFeatures10_TP_ENGINE 0x00000800

11:44 <tomeu> I might need to add some new mechanism to figure out that a job finished executing, as with this HW the Idle register is almost never idle, and we don't get interrupts when a job finishes

11:45 <lynxeye> tomeu: thanks. I see NN_ENGINE is set when NNCoreCount > 0. NNCoreCount is not something we currently have in the etnaviv hwdb.

11:47 <lynxeye> tomeu: Huh? The FE should still be able to generate events. I would guess that we just need some way to sync the FE with the NN cores.

11:47 <tomeu> well, the downstream kernel also doesn't get interrupts on job finish

11:48 <tomeu> they commented out the warning when a job times out...

11:49 <tomeu> from what I saw, userspace relies on the kernel adding EVENT # opcodes, which then triggers an interrupt with that #

11:50 <lynxeye> wtf? I need to recheck this with the NPU on the 8MP, but iirc my NOP cmdstreams triggered the event/irq from the FE as expected.

11:51 <lynxeye> Do you get fault irqs when accessing a non mapped address with the compute engine?

11:55 <tomeu> hmm, I think I did

15:19 <lynxeye> austriancoder: I'm a bit startled by https://gitlab.freedesktop.org/mesa/mesa/-/blob/main/src/etnaviv/ci/etnaviv-gc2000-flakes.txt#L57 If readpix-sanity is really flaky then a lot of the other piglit tests would also be affected, as so many of the tests use readpix to check the result. I have never seen this test fail in any of my piglit runs.

15:19 <lynxeye> Do you know why it has been marked as flaky?

15:21 <austriancoder> lynxeye: I did about 20 run and it tend to be flaky. If your recent MRs landed I will update that list and the world might look better.

15:29 <lynxeye> I'm not sure if any of my recent changes do make a difference there. If this test is really flaky then this is a serious issue and we should investigate it. To be fair I'm only as surprised as I usually don't run piglit through the CI test, but doing piglit runs on my local systems and have never seen the test fail here.

15:31 <austriancoder> lynxeye: I got your point .. but as this process takes some time from my side I want to have at least 19958 landed

16:26 <austriancoder> lynxeye: so for the moment I would ignore it and trust your local runs