04:34 <eiln> nvm figured it out was a platform resource issue (why does this always happen right after..)

04:35 <eiln> "tethered" 1+2 on the ane https://bashify.io/images/n1Xz3i

04:35 <eiln> 4200 is half precision for 3 btw ;))

04:35 <eiln> "tethered" bc needs to reboot after every run

04:35 <eiln> engine aic irq wants to go to dart for whatever reason

08:26 <lumen> would something like this be unnecessarily detailed to get into kernel development? https://github.com/0xAX/linux-insides/blob/master/SUMMARY.md i assume chapter "Initialization" and onwards would be the most useful. apologies for the cross-post between channels, asked here as well so i don't clutter the other channel.

08:28 <lumen> any other suggestions?

08:28 <lumen> was also thinking of reading some of "Linux Kernel in a Nutshell" by Greg Kroah + "Linux Kernel Development" by Robert Love.

08:32 <apxmachit> im not part of asahi development but i find that way of thinking usually doesn't work for me. What specifically are you trying to contribute to Asahi?

08:35 <lumen> i don't have something specific in mind at the moment, just looking for a challenge and a learning experience

08:40 <apxmachit> hmm idk then. Usually for me I have something in mind I want to do, and I build the learning and the experience around that to keep me motivated. Like if I wanted to get into asahi I would probably download it and use it as much as possible, get involved with issues and bugs, and find something to jump in on. Try to have some sort of goal. But yeah those resources look good so do what is best for you

08:41 <lumen> yeah that was one approach i wanted to take - use the system extensively till something breaks, then go and fix it, etc.

08:42 <lumen> thank you

09:06 <marcan> jannau: is it possible "opaque" actually means "premultiplied alpha"?

09:07 <marcan> that would mean that for a black background, alpha is effectively irrelevant

09:08 <marcan> but it would show through the Apple logo-shaped remnant of surface[0] as an additive blend when alpha=0 (which I think is what happens in SDDM) for a surface[1] above it

09:09 <marcan> only for argb formats of course, with a=0, since opaque formats like 10-bit would implicitly have a=1

09:10 <marcan> we should still clear surface[0] of course, since even if we make [1] opaque that still wastes power

09:10 <marcan> but we need to find another way of implementing XRGB formats

09:10 <marcan> I think there is a color component thing that might let us implement a color swizzle?

10:20 <jannau> marcan: possibly although it appears little strange that it is required for overlaying YUV formats. I put it on my todo list for testing. I think it's also worth checking if there's a global alpha field in the surface struct

10:44 <marcan> jannau: confirmed, it's a premultiplied flag

12:21 <kettenis_> looks like powering off the wifi chip (through the SMC gpio) saves a bit over 0.1 W in power

12:32 <kettenis> putting the p-Cluster in the "deep WFI" state also saves a bit more than 0.1 W

12:42 <marcan> kettenis: putting the p-cluster in deep WFI should save quite a lot more than 0.1 W

12:42 <marcan> we are currently burning power on static leakage in the CPU clusters

12:43 <marcan> and also dynamic power on the uncore areas

12:43 <marcan> I'm pretty sure deep WFI should actually power down the cluster

12:44 <kettenis> "deep WFI" is the state where it loses the GPRs but otherwise stays alive

12:45 <kettenis> (I write code similar to what you wrote for m1n1 when you were experimenting with the turbo states)

12:45 <kettenis> s/write/wrote/

12:46 <kettenis> but yes, we really want to power down the cluster completely for suspend

12:58 <jannau> did you test that on m1 pro / max as well? those have currently an unreasonable idle power use of ~5W, m2 is more reasonable with less than 1W assuming PHPC measures more or less the same things

13:01 <kettenis> this is on M2

13:02 <kettenis> PHCP reports something like 0.77W when I come out of "suspend" with one e-core running code

13:03 <kettenis> PSTR reports ~1.9W

13:03 <kettenis> can try this code on m1 pro

13:10 <kettenis> SYS 5405363

13:10 <kettenis> CPU 2501957

13:10 <kettenis> SYS=PSTR, CPU=PHCP

13:10 <kettenis> before suspend this was

13:10 <kettenis> SYS 14909630, CPU 3311439

13:11 <kettenis> machine idle, with the display on

13:12 <kettenis> guess your 5W is from m1 max?

13:14 <jannau> yes, from a m1 max. is suspend with both p clusters in deep WFI?

13:16 <kettenis> my current OpenBSD hack puts all cores in this "deep WFI" state

13:16 <kettenis> but obviously at the point I call the SMC code the primary CPU (an e-core) is running, so no longer into that deep state

13:19 <kettenis> oh, actually those figures were measured with a usb cable connected causing the machine to think power is connected

13:20 <kettenis> SYS 4574661, CPU 2538621

13:20 <kettenis> when suspended

13:20 <kettenis> SYS 6643164, CPU 3820596

13:20 <kettenis> when idle (now with the screen off)

15:33 <marcan> kettenis: I expect the cluster to actually power down in deep WFI (that's why it loses state)

15:33 <marcan> it wouldn't lose state if it didn't actively shut down power to something

15:36 <marcan> jannau: https://gist.github.com/marcan/d93ebdffce5b36be9aaa06079a60503f tried to work out more of the DCP formats. I don't see an alpha enable nor any non-alpha 8bit RGB formats.

15:39 <marcan> it could still be somewhere other than the IOSurface struct though

15:48 <sven> thunderbolt-applesoc 501f00000.nhi: RTKit: IOP power state transition: 0x0 -> 0x20 <-- I think I was at that point before sometime last year but I'm still gonna count this as progress :)

15:55 <jannau> marcan: thanks. we have two u32 arrays which seem to contain flags for each surface in the swap struct

15:57 <jannau> any idea what the '[' in the fourcc means? '&' signifies tiled formats

15:59 <marcan> no idea

15:59 <marcan> those are just aliases as far as the pixel format is concerned

16:00 <marcan> now I'm just trying random stuff

16:00 <marcan> unk_10c in the swap_rec is bg_color, which if nothing else is useful to test the alpha

16:01 <ChaosPrincess> is there some way to export pins from pinctrl_ap to userspac ?

16:11 <kettenis> I can't think of a good reason why you'd want to do so

16:11 <kettenis> but beyond exporting gpios, I don't think linux has any infrastructure for this

16:13 <ChaosPrincess> i want a gpio exported to do some userspace driver prototyping

16:14 <ChaosPrincess> basically, there is a spi device which seems to require an external cs pin

16:16 <kettenis> exporting gpios to userland is certainly possible in Linux, but it may require a little bit of additional code to the relevant drivers

16:17 <ChaosPrincess> yea, the problem is that there is no 'export' sysfs device anywhere near pinctrl

16:17 <ChaosPrincess> s/sysfs device/sysfs file/

16:19 <kettenis> if you can't find someone who knows how this works in Linux, you might want to take a look at the gpio drivers for the SoCs used on $FRUIT pi boards

16:28 <marcan> ChaosPrincess: use the chardev interface

16:28 <marcan> the sysfs interface is deprecated and no longer buildable without CONFIG_EXPERT

16:30 <marcan> jannau: can't find anything :(

16:32 <jannau> I didn't spot anything obvious in the unused Calls. color_remap_mode has 2 bits for invert and luminance only

16:34 <kettenis> marcan: I'm fairly confident my secondary cores are in WFI with the "ok2pwrdn_force_down" bits set in SYS_IMP_APL_CYC_OVRD

16:35 <kettenis> that gives somewhere between 0.1 and 0.15 W extra power savings I'd say, but indeed I'd expect more if the whole cluster was powered down

16:36 <kettenis> but we only lose (most of) the GPRs in that state; not the system registers, TLBs and caches

16:36 <kettenis> so that doesn't make me think this is a really deep idle state

16:38 <jannau> there's A006/A007 set_csc_mode / set_op_mode, A044 set_blendout_CSC_mode, A111 vftg_set_color_channels which are tangentially related

16:40 <jannau> I pity that macos' window sytem doesn't support overlays. not even the native media player or safari are using underlays or overlays for video

16:40 <marcan> kettenis: we know at least uncore is clocked in shallow WFI mode since it burns significantly more power on higher pstates, so I still expect more savings since it should at the very least stop the clock to the cluster entirely if all cores are in deep idle

16:40 <jannau> s/I/A/

16:41 <marcan> jannau: safari is supposed to (at least with the right codecs)

16:41 <marcan> someone benchmarked it as having the GPU completely off while playing video

16:42 <jannau> they output yuv surfaces for fullscreen video

16:42 <jannau> via dcp

16:42 <marcan> but not windowed?

16:43 <kettenis> marcan: note that my measurements are with the clusters already in their lowest P-state

16:45 <jannau> I haven't seen yuv surfaces with windowed video playback

16:47 <marcan> aw, I guess I was giving apple too much credit

16:53 <ChaosPrincess> marcan: tyvm, config_expert was the thing i was missing

16:54 <jannau> marcan: either I tested only with the media player or I misremember things. safari with vp9 video from youtube uses '&8v0' tiled 8-bit nv12

17:03 <jannau> enabling the yuv overlay looks a little strange. the UI switches from surface 0 to surface 1, surface 0 is cleared and unk_10c/bg_color in swap rec is set to 0xff000000 (it is usually 0x0)

17:09 <jannau> and premultiplied is set for the yuv surface

17:34 <sven> kettenis: all the thunderbolt tunables are 32bit masks as well so I’ll stick to the current atcphy format

17:45 <kettenis> sven: great, thanks

23:40 <marcan> jannau: I'm getting the feeling surface 0 is a special "passthrough/optimized" surface and that's why it doesn't do full colorspace conversion on t6k

23:40 <marcan> so then you're expected to use surfaces 1/2 for compositing