12:43 <leio> hmm, after another systemctl poweroff that didn't quite work with the hdmi out kernel, it also ran hot overnight in that state

13:25 <maz> v6.7-rc1 booted on M2 pro with a minimal merge of essential features only. the only ugly corner was the iommu changes.

14:05 <janneg> leio: sounds like oops on dcp unload/poweroff which blocks shutdown

15:16 <leio> and guess something spinlocks or similar to keep CPU busy then

15:17 <leio> should I be trying asahi-wip with all the merges?

15:37 <leio> at least I'm seeing a "[ 4.415052] apple-dcp 2289c00000.dcp: dcp_enable_dp2hdmi_hpd: DP2HDMI HPD connected:0" now; maybe I should connect a HDMI cable again now :)

15:40 <leio> when plugging in the HDMI after it booted without any: kernel: apple-dcp 2289c00000.dcp: DP2HDMI HPD connected:1 kernel: apple-dcp 2289c00000.dcp: DPTXPort: acking unhandled call 22

15:44 <leio> but no DP2HDMI message when booting with hdmi connected at the start; some i2c minute timeout before network came up too - https://bpa.st/Y7GA

15:47 <leio> and with it not connected at start, but connected later: https://bpa.st/5QRA /me goes back to waiting mode :)

15:48 <leio> I probably never tried booting hdmi disconnected with dptx-fixes and there's probably actually no diff in behaviour here

16:09 <janneg> leio: it's strange that you don't see any "DP2HDMI HPD" messages if you boot with hdmi cable connected

16:13 <leio> it looks like the previous boot froze at one point as well, but I can't see anything interested in journalctl -b-1

16:13 <leio> oh, it might have s2idle and I didn't wake it up

16:15 <leio> need to finally figure out elfutils splitdebug issues to free up rootfs space and not have the journal aggressively cleaned up

17:33 <eric_engestrom> is eiln on this channel? I just saw that there's a Mesa merge request to add a "TensorFlow Lite delegate that can make use of NPUs to accelerate ML inference" and hook it up to etnaviv (https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/25714)

17:33 <eric_engestrom> to my untrained eye, that seems related to eiln's work on the apple neural engine, so they might want to take a look at that MR, to maybe hook it up to asahi as well and make sure the api that ends up landing is compatible with what asahi can do, so that we don't end up with one api per vendor :]

17:37 <PaulFertser> Yes, with nick eiln but not right atm.

17:37 <janneg> eric_engestrom: yes, eiln usually checks logs if not present

17:52 <eric_engestrom> awesome, they'll see this then :)

23:55 <eiln> eric_engestrom: I haven't seen that PR actually, thank you for the link :)

23:55 <eiln> I'll admit my mind has been in video world and it's been some time since all this, but ANE is a FP16 MAC unit, it descended from the DSP block of the camera; it's basically ISP got out of hand. It can only do one thing -- and though it can do that one thing pretty efficiently -- it's in turn extremely inflexible and opinionated. As much as I'd like to, hardware limitations make it

23:55 <eiln> very difficult to expose ANE as a generic compute node.

23:55 <eiln> When ANE support happens, the first feature will be the ability to run any pre-compiled CoreML model imported from macOS. This is easy for us because all we need to do is do the kernel-side submission dance e.g. IOMMU-mapping. CoreML support means we're forced to write a bespoke layer for Linux, but there's no other way here.

23:55 <eiln> Apple already has a (somewhat) developed ecosystem, and we have no problem running those Stable Diffusion models that Apple themselves compiled and released -- and I personally don't want to waste my compilation cache -- so I'm fine with some vendor-specific logic here.

23:55 <eiln> We could write a TF delegate backend too, though I'm thinking this is for more simpler kernels e.g. tanh (unary), matmul (binary). Should be a lot easier if it's already there :).

23:55 <eiln> I have to go to $work in 5 minutes, will reply later tonight