12:39 <chewitt> Hello folks :)

12:40 <chewitt> mesa 25.1 appears to introduce a new dependency on LLVM for panfrost

12:41 <chewitt> it looks related to clc ?

12:42 <chewitt> which I'm guessing is related to OpenCL support?

12:42 <chewitt> If yes, is there a way to disable that at build time?

12:43 <chewitt> as we have no need/use for OpenCL support and pulling LLVM into the build process has a large cumulative impact on our distro CI pipelines

12:44 <linkmauve> chewitt, many drivers in Mesa have started to use clc to implement extensions that aren’t present in hardware, such as geometry or tesselation shaders. I don’t know if this is the case for panfrost, but it is for instance for asahi.

12:45 <chewitt> sounds plasible

12:45 <chewitt> plausible .. (fat thumbs today)

12:47 <linkmauve> There is src/panfrost/libpan/query_pool.cl for instance.

12:49 <linkmauve> But apparently that’s used only before v10, but I’m not aware of a way to build panfrost for only a specific architecture.

12:55 <chewitt> I don't see 'src/panfrost/libpan/query_pool.cl' in mesa source anywhere

12:56 <chewitt> I do find mentions of clc under src/asahi/clc

12:56 <linkmauve> It’s here: https://gitlab.freedesktop.org/mesa/mesa/-/blob/main/src/panfrost/libpan/query_pool.cl

13:03 <chewitt> ahh, I reset my 'main' branch against the wrong remote (was out of date)

13:07 <chewitt> I also need to report a probably long-standing regression with T820 support

13:07 <chewitt> the kernel driver loads, then

13:07 <chewitt> panfrost d00c0000.gpu: GPU Fault 0x00ff0388 (GPU_SHAREABILITY_FAULT) at 0x000000759dedce40

13:07 <chewitt> followed by this (repeating every 60 seconds)

13:07 <chewitt> [ 19.832891] panfrost d00c0000.gpu: shader power transition timeout

13:07 <chewitt> [ 19.834924] panfrost d00c0000.gpu: tiler power transition timeout

13:07 <chewitt> [ 19.836948] panfrost d00c0000.gpu: l2 power transition timeout

13:09 <chewitt> actually not ever 60 secs, looks to be some kind of exponential back-off

13:09 <chewitt> see https://paste.libreelec.tv/trusting-toucan.log

13:10 <chewitt> this is on Linux 6.14.5 with mesa 25.1 but I know the fault has been around for a while (more than a year possibly)

13:11 <chewitt> so it's probably something specific to Midgard, and a difference between T860 and T820

13:11 <chewitt> (as Rockchip folks have an eye on T860 support, and nobody has an eye on Amlogic S912 support)

13:13 <chewitt> I did experiment with extending the shader/tiler/l2 timeout values in the kernel driver, but moving from 2000ms (current) to 5000ms makes no difference

13:13 <linkmauve> chewitt, for this kind of issue, it might be useful to bisect the kernel to determine which version or commit broke it exactly.

13:14 <chewitt> I know .. I'd love to avoid that task though :)

13:15 <chewitt> I've seen comments about 'midgard being broken' from folks before though, so I might hold out to see if there's a memory jog or known issue in the back of people's minds first

13:17 <chewitt> the GPU seems to be working okay for our use-case (running Kodi) .. no visual glitches or artefacts in the GUI

13:19 <chewitt> and I have a hunch the issue is on the mesa side not the kernel side (the driver didn't change much for aeons)

13:20 <linkmauve> chewitt, ah, when you say it happens right on boot, do you actually start using the GPU at this point? Could you try without doing that?

13:22 <chewitt> exactly .. the fault occurs when Kodi starts some time after the driver probes

13:22 <chewitt> the journal is better for seeing that https://paste.libreelec.tv/helping-chipmunk.log

13:23 <chewitt> tracing what happens inside mesa is probably more productive than bisecting the kernel

13:23 <chewitt> I might need pointers on how to do that .. it's been a while

13:23 <linkmauve> Maybe try with another compositor first?

13:24 <chewitt> not really possible in the distro without major work

13:25 <linkmauve> Maybe try another distribution then?

13:25 <chewitt> there's no desktop environment at all in LibreELEC, we run Kodi directly on GBM buffers

13:27 <chewitt> but I can set environment variables to dump stuff to the journal

14:56 <alyssa> chewitt: fwiw it's a build-time dependency, not a runtime one

14:56 <alyssa> i.e. you don't need to ship llvm with libreelec images, you just need the right toolchain when building mesa

14:57 <alyssa> see https://docs.mesa3d.org/drivers/panfrost.html#building

14:57 <chewitt> historically only our x86_64 image needs to build LLVM for mesa

14:57 <chewitt> now most of the aarch64 images need it too

14:58 <chewitt> it means our current roster of images only just builds (all) in under 24h, where before they'd be done way under the limit

14:59 <chewitt> our CI isn't that sophisticated, but it's cost-effective given we're compiling an entire embedded distro image (x13 or so)

14:59 <alyssa> aarch64 is playing with the big kids now \shrug/

15:01 <alyssa> see also https://eldritch.cafe/@alyssa/113572943830849614 (fr)

15:03 <chewitt> une opportunité pour utiliser ma Français de l'ecole :)

15:05 <alyssa> I admit that libreelec is the sort of use case that slips thru the cracks here but i'm looking at a much bigger stack of cards here

15:07 <alyssa> and clc is/will be a huge boon for panfrost's abililty to be a competent/credible alternative to the DDK (which uses glsl to a similar effect, iirc)

15:17 <CounterPillow> It appears LE currently builds the entire distribution for each device again, even though things like the toolchain could be shared?

15:21 <chewitt> on some level it's all about optimisation

15:22 <chewitt> different hardware targets have different silicon supporting different features and the original idea is to compile with optimisation

15:23 <chewitt> so the buildsystem compiles the toolchain for that target and then everything else

15:24 <chewitt> in theory we could build and cache the toolchain (until some toolchain element is updated) .. but we don't currently do that (we never needed to go that far)

15:26 <chewitt> in our dev branch we track current/latest versions and bump toolchain items frequently enough that we'd need to rebuild it pretty regularly

15:26 <chewitt> there's nothing to say we can't change; but in the history of the project we've never needed to (and have avoided) taking that step

15:28 <chewitt> the penalty is compile time, but it also means we don't need to pay any special attention to bumping/merging and tracking toolchain stuff

15:30 <chewitt> and we have only a handful of staff compared to a typical Debian derivative, so being relaxed has value

15:31 <chewitt> anyway.. i'm waffling

15:32 <CounterPillow> I'm not advocating for you doing a complex packaging system here with tracking ABIs and such, I'm just saying your actions run that's currently like 13 different full builds could have another job that feeds into those 13 which provides the toolchain for all of them.

15:33 <CounterPillow> at that point, you don't have to track the toolchain separately, it's still built in the same go, just only once.