04:06 <cphealy> For those working on Panfrost (or Panthor), nvtop now works with these GPUs with a sufficiently new kernel: https://github.com/Syllo/nvtop/pull/235

04:23 <HdkR> Nice

19:12 <electricworry> I'm trying to get mesa to work on an Orange Pi Zero 3 (Mali G31). I've got a mesa build that allows me to do software rendering (`GALLIUM_DRIVER=softpipe kmscube`). How can I force mesa to use the panfrost driver?

21:18 <FLHerne> What kernel do you have? You'll need the panfrost kernel module as well as userspace

21:19 <soreau> I have mesa working on Mali G31 with Mesa 21.1.0-devel (git-14b2dc0013)

21:19 <soreau> as long as you have the drivers installed, it should work, yea

21:20 <FLHerne> perhaps check for this https://wiki.debian.org/PanfrostLima#Troubleshooting <- see the bit about devfreq; not sure under what circumstances it matters

21:54 <pbrobinson> also it doesn't look like the DT support is complete upstream for that device so it may be that the device tree needs to be expanded out to ensure the GPU is enabled

22:02 <electricworry> Thanks I'm just getting started with this. I've built kernel 6.1.31 with a bunch of vendor patches and I can see the gpu in /sys/firmware/devicetree/base/soc/gpu@1800000 (which shows as compatible "allwinner,sun50i-h616-maliarm,mali-bifrost"). And I built mesa with "-Dgallium-drivers=panfrost,kmsro". But when I run panfrost_texfeatures I get "No panfrost device". So I've got something fundamental wrong I think. Using

22:02 <electricworry> mesa 23.2.1.

22:07 <electricworry> This tells me "drmOpenWithType("panfrost", NULL, DRM_NODE_RENDER);" in panfrost_texfeatures is returning an error. What's a good approach for a complete driver beginner to figure out what's missing? I'm ready to spend some time digging into the problem but some shortcuts would be appreciated.

22:12 <electricworry> In dmesg, no reference to panfrost anywhere, but `rmmod panfrost` tells me it's a builtin.

23:42 <robmur01> electricworry: if the kernel driver's present but not even trying to probe, then it's most likely either a DT issue (e.g. disabled node or messed-up non-matching compatible) or a missing dependency (e.g. power domain/clock/regulator driver) causing probe deferral