09:19 <bbrezillon> alyssa: I'm not sure I understand how raw tile-buffer writes work on Midgard. Looks like the same fragout (brndout) instruction is used for both cases, the only difference being that raw writes happen in a blend shader, so I guess the FF blend unit is bypassed in that case and the output values are written directly to the tile buffer

09:36 <bbrezillon> alyssa: ah, nevermind, if blend_shader and load_destination are false, blending is skipped and the output is written directly to the tile buffer (I guess the float -> unorm conversion still happens if internal_format != RAWxx)

13:14 <warpme_> guys: i'm trying to get working mali g31 on allwinner h616 (a "new" version of well working h6). i'm on mesa 21.1.1 and 5.12.7 kernel. all works perfectly on h6. but on h616 panfrost loads, reports reasonable caps. but when my app starting to use gpu i see in dmesg every 60sec logs like this:

13:15 <warpme_> https://www.irccloud.com/pastebin/ODoiAH94/

13:29 <alyssa> bbrezillon: Oh err..

13:30 <macc24> i now have a suzyqable

13:31 <macc24> let the flashing commerce >:D

13:39 <warpme_> maybe somebody has some hints how to investigate root cause of job timeouts on h616?

13:39 <macc24> warpme_: can you give full dmesg?

13:39 <warpme_> sure

13:40 <warpme_> here it is: https://pastebin.com/ck6259cS

13:41 <warpme_> my app reports g31 as ok:

13:42 <macc24> >kernel finished booting in 3 seconds

13:42 <warpme_> https://www.irccloud.com/pastebin/IkliPSXU/

13:43 <warpme_> also interrupts from gpu seem looks ok:

13:43 <warpme_> https://www.irccloud.com/pastebin/BMNOykh1/

13:44 <macc24> can you try mesa main branch?

13:44 <warpme_> do you mean current master?

13:44 <warpme_> oh master->main....

13:44 <macc24> they renamed master branch to main

13:46 <warpme_> sure. let me try. btw: all works perfectly for h6 (h616 soc is in many aspects v.similiar to h6. also all works on my other soc with g31: amlogic sm1)

13:46 <macc24> yea g31 is fine

13:48 <macc24> umm

13:48 <macc24> doesn't h6 have mali t720?

13:49 <macc24> according to https://linux-sunxi.org/H6 it has

13:49 <warpme_> yes. gpu in h6 soc is t720

13:50 <macc24> where are kernel sources of stock firmware?

13:50 <macc24> my guess for now is that something's wrong in mesa driver or there is some quirk in h616

13:52 <bbrezillon> warpme_: cache coherency issues? (we've had problem during the G52+amlogic bringup because of that)

13:54 <bbrezillon> warpme_: do you have a dma-coherent prop under the gpu node?

13:54 <warpme_> bbrezillon: well. i have no idea. panfrost error output is too criptic for me.....

13:55 <macc24> bbrezillon: https://github.com/torvalds/linux/blob/master/arch/arm64/boot/dts/allwinner/sun50i-h6.dtsi#L168 i don't see it

13:55 <macc24> neither in https://github.com/torvalds/linux/blob/master/arch/arm64/boot/dts/allwinner/sun50i-h6-tanix-tx6.dts#L70

13:56 <bbrezillon> assuming both your amlogic and allwinner SoC embed the same GPU (G31), and one works while the other doesn't, I'd bet on a kernel side issue (PM or cache related)

13:57 <warpme_> bbrezillon: well - i have working well g31 but on dfferent soc (amlogic)

13:59 <warpme_> bbrezillon: sorry. read your mgs too quick :-)

14:00 <warpme_> as driver seems report ok caps - PM should be rather ok?

14:00 <macc24> bbrezillon: i think if it would be pm it would either throw serror(look i learned new word :D) or just not render anything

14:02 <warpme_> ....or hang soc. h616 has undocumented bit in PM registers. without proper setting bits in those reg. modprobe of panfrost hangs soc.

14:04 <bbrezillon> macc24: dunno what happens if the OPP are slightly off

14:04 <macc24> bbrezillon: "if the OPP are slightly off"???????

14:05 <warpme_> currently i disabled opp. gpu runs on safe 432MHz.

14:06 <warpme_> also i tried increase vgpu to 1.08v

14:07 <warpme_> maybe it is worth to try apply g52 cache-coherency on h616 (as soc quirk)?

14:08 <macc24> warpme_: as a hack you can try changing compatible to amlogic,meson-gxm-mali in sun50i-h6.dtsi

14:08 <macc24> but i don't know if it would make sense or not

14:12 <warpme_> macc24: probably you mean "compatible = "amlogic,meson-g12a-mali", "arm,mali-bifrost";" - this is what amlogic sm1 uses for working g31 ?

14:13 <macc24> warpme_: yea whatever just amlogic,something-mali

14:13 <bbrezillon> adding the dma-coherent prop should do the trick, I don't think you want the amlogic quirks

14:13 <macc24> warpme_: ^

14:14 <narmstrong> The dma coherent

14:14 <narmstrong> Stuff was only for G52

14:15 <narmstrong> I thought G31 didn’t support cache coherency

14:15 <narmstrong> On amlogic, the G31 & G52 runs at a lower freq than the T820 and Mali450

14:17 <warpme_> bbrezillon: so something like this? :

14:17 <warpme_> https://www.irccloud.com/pastebin/WgDgZVy9/

14:19 <warpme_> of course without <..>

14:24 <warpme_> hmm - with added dma coherent prop i started to get in dmesg:

14:24 <warpme_> https://www.irccloud.com/pastebin/gjC878L1/

14:30 <alyssa> tomeu: You want more kernel patches? Here are more kernel patches https://rosenzweig.io/foo.patch

18:06 <jernej> narmstrong, macc24: I compared vanilla ARM bifrost driver with BSP H616 one and diff is pretty unremarkable: http://ix.io/3oa8

18:07 <jernej> two special registers in PRCM and SMC are already set in U-Boot

18:08 <alyssa> Rendered 1335 frames in 179.289 secs, average of 7.44609 fps

18:08 <alyssa> that's good right?

18:11 <narmstrong> jernej: what about GPU_POWEROFF_GATING_REG and the SMC reg used for protected mode ?

18:11 <jernej> as I said, those two are set in U-Boot :)

18:11 <jernej> for testing purposes, anyway

18:12 <jernej> except there is one suspicious reset in mali_kbase_pm_driver.c

18:12 <narmstrong> Oh ok I missed it, was looking at the patch ^^

18:14 <narmstrong> Did you try /disabling/ protected mode ?

18:14 <narmstrong> Maybe it’s enabled by default

18:15 <jernej> yeah, that's in SMC register set in U-Boot :)