09:28 <cy8aer> I expected the E core stuff would be "just in" the kernel. So I run without them because of CONFIG_UCLAMP_TASKS. I will build it in with the 6.6-15 and the actually in a merge request hanging new mesa.

09:29 <j`ey> cy8aer: UCLAMP allows userspace to give hints to the kernel

09:30 <cy8aer> But I habe a question for that too: "so pipewire can run on the E cores" - is that a global thing then because pipewire does/will do the video streaming stuff in future too. Ok with hardware acceleration that would work but without...

09:31 <cy8aer> j`ey: ah I see.

09:34 <j`ey> chadmed: is the uclamp stuff for the whole of pipewire?

09:34 <j`ey> or just the dsp stuff

09:35 <j`ey> btw the E cores can decode 1080p happily

09:38 <chadmed> j`ey: it will affect all of pipewire and wireplumber if set

09:39 <chadmed> which is fine because again the ecores are more than happy doing up to 24/192

10:17 <leio> I guess the question is - will it be fine doing 4K screen sharing and libcamera integration

10:42 <cy8aer> As I understand is videopiping ok with pipewire. The problems are with the sinks. And if they use hardware acceleration (@eiln is working on it) the whole video stuff will be low power too and would work fine with higher resolutions IMHO.

10:51 <eiln> ye avd can do up to 4K (I think M2 had 8K?). though I feel the bigger gains with avd are power savings

10:51 <eiln> avd can't do everything though. we still have to do some things ourselves e.g. vp9 probability adaptation/merging (apple didn't add silicon for that). all that can stick to an e-core. I don't think apple does fancy scheduling for video

10:51 <eiln> I've also talked to m arcan about zero-copy frame dma out (which would be natural if this does end up on the mesa side)

10:56 <j`ey> yay for even less CPU usage

11:16 <u154ss> #j'ey/cy8aer who will build the newest mesa to match linux 6.6-15? I tried Glanzmann's script bumping the release using tag asahi-20231213. It is still producing version 22.x.x .debs however. The Fedora fc39 is already using mesa version 24.x.x as far as I can see.

11:18 <u154ss> Backgroung being I want to run Debian/XFCE on my M2 Mini. Fedora FC39 works on the M2 Mini, but I do not want this setup, prefer Debian...

11:19 <u154ss> Backgroung = background.

11:19 <cy8aer> I would build it if it "is out" - as I see the merge request is still open. And my mesa version will be 24 - as my 20231213 too. But my naming is not really right I guess.

11:19 <cy8aer> So actually I am "on hold" and waiting for the mesa patch

11:20 <cy8aer> https://gitlab.freedesktop.org/asahi/mesa/-/merge_requests/252

11:21 <u154ss> @cy8aer using tag 20231213 why are version 22.x.x .debs being produced then? Scratches head..

11:22 <u154ss> @cy8aer I saw the merge request already. Thanks.

11:25 <cy8aer> The package version depends on https://git.g3la.de/repos/m1-debian/src/branch/baer/mesa.sh line 31. And I try to be higher than the last debian package there. Probably I will follow the fedora version numbers in future time.

11:26 <cy8aer> The used patches are out of the official version numbering so it is a bit nifty to give a plausible version number

11:27 <cy8aer> Mesa version itself is 24.0.0-devel

11:30 <u154ss> @cy8aer the script https://git.g3la.de/repos/m1-debian/src/branch/baer/mesa.sh is more or less the same as Glanzmann's script. There is no guarantee should I build kernel 6.6-15 and the latest mesa stuff that XFCE/X11 will run on the M2 Mini. My thoughts..

11:32 <j`ey> u154ss: yes -15 won't fix anything there, pretty sure

11:32 <cy8aer> I am working with a fork of the Glanzmann scripts. And the 20231213 is a bit backported to the Glanzmann repo because there were some documentation files missing which I just kicked out of the packaging.

11:37 <u154ss> @j'ey - to recap - on the M2 Mini using Fedora fc39, KDE(Plasma) and XFCE/X11 work, Debian/XFCE does not (libunwind -10 segfault etc.). I am wondering whether Debian/XFCE will ever run on the M2 Mini. Again, Fedora/KDE is too bloated/top-heavy for me.

11:38 <u154ss> @cy8aer I see that. Gut.

11:38 <j`ey> u154ss: No idea, but it won't run unless a) it's solved by accident b) someone figures it out

11:39 <j`ey> depends what's more important for now, Debian/???? or Fedora/XFCE

11:39 <u154ss> @j'ey my thoughts/worst fears exactly.

11:40 <j`ey> we know that it's possible since Fedora/XFCE works, so it's hard to tell where the exact issue would be, lots of different packaging differences

11:41 <u154ss> @j'ey not that I am resistant to change, but I prefer to run lean-and-mean anyway. My mainframe mentality.

11:42 <j`ey> that's fine :)

11:45 <u154ss> This is my memory usage/allocation, just after startup on the M1 Mini - Memory: 243568K/16287488K available (6976K kernel code, 770K rwdata, 1520K rodata, 704K init, 418K bss, 230912K reserved, 0K cma-reserved)

11:46 <u154ss> @j'ey, I would prefer to keep thing that way on the M2 Mini also. I have 24GB on the M2 Mini.

11:46 <mps> I've made mesa-asahi 24.0.0_pre20231213 version for alpine

11:46 <j`ey> u154ss: Im not really sure what to say, you pretty much just have 2 options

11:47 <u154ss> @j'ey - or no options.. :)

11:47 <u154ss> @j'ey - at the moment.

11:55 <u154ss> @mps have you tested your setup (24.0.0_pre20231213) on a M2 Mini?

11:55 <mps> u154ss: no, I don't have M2

11:55 <u154ss> @mps OK.

11:56 <mps> but on M1 and M1pro it works fine

11:56 <u154ss> @mps the M2 Mini is a different (hardware) beast methinks.

11:57 <mps> yes

11:57 <mps> but if fedora works I don't see reason why debian will not

11:58 <u154ss> @mps different distribution/mesa version/kernel/hardware - a lot of variables there.

11:59 <mps> IDK if anyone run alpine on M2 to ask

12:00 <j`ey> Im not sure what that will give you anyway, if it works on alpine.. then what? :)

12:01 <mps> and alpine uses different libc than others but anyway everything works, no one posted bug report at least

14:27 <RoundDuckKira> does asahi use rust code as part of the development of the Asahi drivers

14:27 <RoundDuckKira> I have a feeling void linux doesn't use rust by default

14:27 <j`ey> yes for the GPU

14:28 <j`ey> most distro's wont enable rust in the kernel yet

14:28 <j`ey> I would just run without the GPU to start with

14:28 <RoundDuckKira> oh shit

14:29 <RoundDuckKira> I may need to ask the void devs if it's possible to change the template to allow rust compile

14:29 <RoundDuckKira> the GPU is a big one

14:29 <j`ey> well youre going to need a 'fork' of the kernel anyway for some time, so you dont really need to modify upstream void for that yet

15:03 <RoundDuckKira> well idk how the fedora kernel is made that's for sure\

15:03 <RoundDuckKira> btw patching the void kernel was where it failed it

15:03 <RoundDuckKira> it failed to patch

15:03 <RoundDuckKira> oof

15:04 <RoundDuckKira> what's asahi-6.6-15 supposed to be

15:04 <RoundDuckKira> v6.6 is the pure 6.6.0 kernel right?

15:05 <RoundDuckKira> and asahi-6.6-15 is the modified one with the latest asahi patches right?

15:06 <j`ey> yes

15:08 <j`ey> -15 needs some mesa changes for GPU, but I think you can ignore that if you just go for software rendering to start off

15:10 <RoundDuckKira> yeah I just am focusing on booting into a tty merely at first

15:10 <RoundDuckKira> tho I do want kernel side gpu support working

15:10 <RoundDuckKira> just get that mess out of the way

15:21 <RoundDuckKira> hey btw j`ey, you know lactose here right? The thing is we both started projects to get weird Linux distros working on Asahi, she's a friend of mine from discord. The reason I am asking is I'm asking that did she ever say about how she got the Asahi kernel working with slackware, I wonder if there's some info I can glean to help me with this task

15:22 <j`ey> RoundDuckKira: I cant remember what they did in the end

15:23 <j`ey> tbh most of the kernel build is pretty easy, and you can probably boot to a tty without many special options

15:23 <j`ey> and then you can slowly add more as you go

15:25 <j`ey> I think starting by just building the tree directly, rather than trying to get the diff and patch a tree is also good to start with

15:27 <RoundDuckKira> j`ey: https://termbin.com/j8tb here's the output of my patch attempt and fialure

15:27 <RoundDuckKira> this is me patching the 6.6.13 kernel with the asahi 6.6-15 stuff

15:28 <j`ey> yeah, I think this is a good example of why it's better to focus on building the asahi tree directly first

15:28 <j`ey> that's the important bit

15:28 <RoundDuckKira> well I can build that fine with dependenciesz

15:28 <RoundDuckKira> I just want it to work on a newer kernel base

15:29 <j`ey> it sounded like you hadn't gotten a kernel working at all yet?

15:31 <j`ey> but yeah, 6.6.13 changed that file, and so has asahi, that's why it conflicts

15:34 <j`ey> RoundDuckKira: fedora is based on 6.6.3 it seems, that change conflicted since 6.6.7

15:34 <j`ey> you could try base it on v6.6.6

15:54 <RoundDuckKira> yeah I don't have a working kernel

15:55 <RoundDuckKira> and v6.6.6 lol

15:55 <RoundDuckKira> 666

15:55 <RoundDuckKira> the satanic linux lol

15:55 <j`ey> :-)

22:42 <RoundDuckKira> j`ey: I tried 6.6.6 and still a conflict there oof

22:42 <RoundDuckKira> gonna try 6.6.3

22:44 <j`ey> 6.6.6 didnt look it should, but .3 def shouldnt

22:44 <RoundDuckKira> ye since asahi uses it

22:47 <RoundDuckKira> what the heck, even 6.6.3 fails

22:47 <RoundDuckKira> wat

22:50 <j`ey> same file?