11:51 <la-s> I am trying to use panfrost with an amlogic S922X (mali G52) (aware that the support may be very elementary), but running kmscube just uses llvmpipe, and I see nothing about panfrost in dmesg. I have compiled the kernel with DRM_PANFROST enabled, and I can see that /sys/bus/platform/drivers/panfrost exists, and I am using a mesa I compiled two days ago, so I'm not sure what I did wrong. /sys/devices/platform/soc/ffe40000.gpu

11:51 <la-s> also exists, but it doesn't have a driver symlink.

11:51 <la-s> I am using linux-next for 2020-04-23, and the actual board is an ODROID N2. Did I fuck up my kernel somehow, or am I missing something basic? I would appreciate it if I could get any pointers, thanks.

11:57 <tomeu> la-s: the device is probably not probing

11:58 <tomeu> you need some code not in mainline yet, for example: https://github.com/superna9999/linux/commits/amlogic/v5.8/bifrost

12:01 <la-s> tomeu: dude, thanks. I have been spending days on thin thinking it works on mainline lol

12:02 <tomeu> la-s: sorry, it will take a while, as you will find soon the hw isn't acting stably with that branch

12:02 <tomeu> we don't know yet why

12:02 <la-s> thanks

12:03 <tomeu> echo "on" to /sys/devices/platform/soc/ffe40000.gpu/power/control so it is "almost" stable

12:58 <tomeu> alyssa: the first problem I saw in -brefract is that when blitting to the last mipmap level, the gpu tries to write past the end of the framebuffer/texture

12:58 <tomeu> have already checked that it's not checksumming

12:58 <tomeu> any ideas?

13:02 <tomeu> ah, the framebuffer_stride for the small levels needs to be 64, not 0

13:02 <tomeu> let's check

13:16 <tomeu> actually, 0, not 64 :)

14:05 <alyssa> la-s: Also, a few patches are still waiting for merge. getting there tho :)

14:15 <alyssa> tomeu: See, you don't even need me :p

14:15 <tomeu> alyssa: that didn't made any difference, so I disabled mipmapping and moved on :p

14:15 <tomeu> as the blob does mipmapping very differently

14:16 <alyssa> tomeu: Indeed, there's a mechanism for doing blits with FRAGMENT jobs without involving the rest of the chip. New to bifrost :-)

14:16 <tomeu> yep

15:29 <alyssa> So gl_FragCoord is passed as u16s into (R59.x, R59.y)

15:29 <alyssa> Those get convered to floats and 0.5 is added (some rounding detail I guess)

15:29 <alyssa> Finally, the blob applies an arbitrary affine transformation (in R^2), passed in via uniforms

15:30 <alyssa> For GL on screen, the transform just flips everything upside down, to account for GL goofiness.

15:30 <alyssa> I'm not entirely sure what other transform would be needed beside that and identity; regardless, Mesa takes care of that for us I believe.

15:32 <alyssa> gl_FragCoord.z is loaded with `LD_VAR.32.flat.v1 T1, fragz, 0.x, R0`

15:32 <alyssa> and likewise `LD_VAR.32.flat.v1 T1, fragw, 0.x, R0`

15:33 <alyssa> also preload_regs | 0x10 to get R59 in

16:16 <Ke> Las: as I understand platform devices are just something listed in the device tree, so having them listed just means they are in the device tree file, not that any software has run any code to detect it

16:16 <Ke> afaik device tree is just there, because probing functionality has not been designed to the hardware itseld

16:17 <la-s> huh, thanks

16:18 <cwabbott> alyssa: iirc the 0.5 thing is because in GL, the center of the (0, 0)'th pixel is defined to be (0.5, 0.5)

16:18 <alyssa> cwabbott: makes sense, I guess :)

16:19 <daniels> cwabbott: did the flag to optionally have that be (0,0) make it into ES or is it a GL-only ext?

16:19 <cwabbott> no idea

16:19 <daniels> (as well as DX)

16:19 <Ke> so you don't even theoretically know, whether all the logical ports in the die would be broken or missing, though this would be absolutely unlikely

16:20 <Ke> in that ip block

23:45 <yawniek> i'm on the rockpro64 with some manjaro image thats using panfrost. somehow i am only getting a 1024x768 resolution. is that to be expected or is there a way to fix this?