02:09 <cphealy> mntmn: interesting. This is the first I've even heard of RCW.

11:28 <mntmn> LS1028ARM actually lists a bunch of GPU control registers. it also states the GPU might be GC7000L or "GC700LVX"

11:28 <mntmn> > The GC7000L/GC7000LVX has 4 such vec4 shaders.

11:29 <mntmn> but the docs for product ID register say > Grade Level indicator:: 3 indicates UltraLite.

11:29 <mntmn> so, that's conflicting, cphealy

11:43 <mntmn> chuckled > The chip's commitment to low power begins with the decision to fabricate the chip in 28 nm bulk CMOS technology

11:43 <mntmn> pretty sure it's GC7000UL btw

13:07 <mntmn> almost... [ 4.143018] mali-dp f080000.display: failed to bind f200000.display (ops cdns_mhdp_imx_ops): -6

13:08 <mntmn> [ 4.069381] [drm] found ARM Mali-DP500 version r1p2

13:08 <mntmn> interesting > [ 4.137492] [drm:__cdns_dp_probe] *ERROR* NO dp FW running

13:09 <mntmn> also > [ 4.129741] [drm:cdns_mhdp_firmware_init_imx8qm.part.0] *ERROR* NO HDMI FW running

13:09 <mntmn> quite the mixed bag, this platform

13:13 <cphealy> The UL is what I was thinking it was too, though I don't recall the full details of why beyond it having a lower fill rate and lack of Vulkan support, IIRC.

13:14 <mntmn> i ported over the HDP driver code, and now wondering why it thinks there is no firmware

13:32 <mntmn> ok the firmware is just rows of > a0000000: deadbeef deadbeef deadbeef deadbeef

13:36 <mntmn> ok, works now > [ 4.132417] [drm] HDP FW Version - ver 23029 verlib 20560

13:45 <cphealy> Has etnaviv already been successfully used with the GC7000UL on different SoCs?

13:50 <lynxeye> cphealy: mntmn: I guess that's the same GPU as on the i.MX8MP. Basically a 2 shadercores/single pipe version of the GC7000 without the BLT engine.

13:52 <lynxeye> I haven't had time to figure out the new RS supertiling bits, so currently you need to force disable supertiling. Other necessary changes are in a WIP Mesa MR.

13:53 <cphealy> lynxeye: Would the TS optimization in https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/9780 apply with the GC7000UL?

13:54 <cphealy> I assume the ARM Mali display controller does not support the Vivante tile or compression formats but it would still be useful for wayland GPU composition use cases, correct?

13:55 <lynxeye> cphealy: Sure, why not? You just won't get any benefit on the display side with any display engine other than the DCSS, as I'm not aware of any other display unit supporting DEC400.

13:57 <mntmn> lynxeye: ok, interesting

13:57 <mntmn> lynxeye: with some basic headless tests i currently get "Recover hung GPU", so not sure what's wrong

13:58 <lynxeye> mntmn: You probably need the HWDB entry for the specific core. Without this the kernel driver will likely try to start the GPU using the wrong registers.

13:59 <mntmn> lynxeye: oh!

13:59 <lynxeye> The feature registers on the new GPU cores are just blatant lies.

13:59 <mntmn> ahh, i see ^^

14:00 <mntmn> i get:

14:00 <mntmn> [ 4.234691] etnaviv-gpu f0c0000.gpu: model: GC7000, revision: 6202

14:00 <mntmn> [ 4.241205] [drm] Initialized etnaviv 1.3.0 20151214 for etnaviv on minor 1

14:01 <mntmn> i guess that's meant as 0x6202?

14:06 <lynxeye> mntmn: Yep, that's hex. model/rev/vendor are reliable and then used to match the HWDB entry to get the feature registers.

14:09 <mntmn> ok, i'm gonna try these with 6202 https://www.spinics.net/lists/dri-devel/msg290275.html

14:13 <mntmn> no dice, but it changes the behavior:

14:13 <mntmn> [ 81.400810] etnaviv-gpu f0c0000.gpu: MMU fault status 0x00000002

14:13 <mntmn> [ 81.406848] etnaviv-gpu f0c0000.gpu: MMU 0 fault addr 0x00000000

14:13 <mntmn> [ 82.463403] etnaviv-gpu f0c0000.gpu: recover hung GPU!