12:47 <marcan> alyssa, lina: BTW, does asahi handle multiplanar formats yet? DCP supports a bunch of those (and we're going to need them for some use cases), and Apple use multiplanar RGB10+A8 by default for UI stuff (compressed) so I assume it's supported by the hardware somehow (or is that just effectively "lol MRT"?)

12:49 <marcan> in particular kwin seems to prefer alpha formats over alphaless, but right now we only *actually* support X2R10G10B10 as a 10-bit format (we claim A2 also but it's a lie). so right now kwin picks the A2 format even though it has no real alpha. we should offer it a proper 2-plane 10-bit alpha format as the best choice.

12:53 <jannau> did you test "w40a" 40-bit single plane ARGB10? I think I saw that as supported as well but it was missing from dcp_surfaces.txt

14:10 <jannau> w40a works for dcp but is despite its name 64 bit per pixel

14:13 <dottedmag> Is it 10-bit with 6-bit unused per channel?

14:18 <dottedmag> Also Wayland implicitly implies that all the buffers are single-planar in wl_shm constructor. Nobody uses this constructor for anything useful, but well.

14:22 <jannau> yes, 6 bit padding per component. I guess handling 40 bit per pixels is annoying on HW side as well. the kwin code in question uses zlinux_dmabuf

14:28 <dottedmag> dmabuf _seems_ not to hardcode assumptions: width/height/format plus a number of weird flags (y invert, interlaced, bottom-first-interlaced), so it might work with multiplanar if they are advertised.

14:36 <jannau> multi-planar YUV works with dmabuf without issues

16:05 <daniels> single-planar also works fine with wl_shm, you just don’t get to choose your chroma offset or stride

16:45 <marcan> jannau: w40a is in there (#4), and I would expect it works but it's such a massive waste of memory bandwidth... not a good idea for the main framebuffer

16:45 <marcan> bi-planar formats are much nicer because the alpha is going to be all 0xff 99% of the time, which should compress down to ~nothing with framebuffer compression

16:47 <marcan> so in practice w40a is going to be close to ~2x the memory bandwidth of w18p or b3a8

16:53 <eric_engestrom> lina: any chance that "apple logo" at boot is its own hardware plane and it's missing a clear in your driver's init?

16:53 <eric_engestrom> I'm getting leftover text from the linux console in the shape of an apple in the middle of my screen, and it's above everything else (including the cursor), but it's like it's rendered with a single value used for all channels (only grey, and the opacity seems to match the luminosity, black being fully transparent), so I'm guessing it might have been missed because if there's no text that happens to be right there, it will

16:53 <eric_engestrom> appear fully transparent

16:53 <eric_engestrom> also, just tried to take a screenshot: the cursor is included, the apple logo isn't (not sure what info that really adds though)

16:54 <marcan> that's fixed in the 6.2-rc2 rebase I just pushed

16:54 <eric_engestrom> (using grim for the screenshot)

16:54 <eric_engestrom> marcan: are you replying to me? awesome :)

16:54 <jannau> eric_engestrom: fixed in 9e3157ab6af08531191f25709dc3494eb2c65f0a

16:54 <eric_engestrom> thanks both :)

16:54 <marcan> and yes, that happened when we switched to plane 1 because plane 0 seems to be special on t600x, combined with the lack of alphaless formats (which we were unknowingly cheating by marking them as premultiplied)

16:55 <jannau> screenshot will not work since it's blended in the display controller

16:55 <marcan> the apple shape is the original iBoot alpha, which interestingly does not actually apply on boot because DCP does some optimization where fullscreen single planes end up ignoring alpha anyway

16:55 <marcan> which is why the iBoot framebuffer works as intended, but then the apple comes back later when we enable another plane

16:55 <marcan> it's all pretty cursed

16:56 <eric_engestrom> yup, just read the commit message and that's exactly what I'm experiencing :)

16:56 <marcan> I'm still quite annoyed that there isn't a "turn off alpha" bit anywhere as far as I can tell, and no XRGB8888 support at all

16:57 <marcan> we can cheat that with premultiplication for the bottommost planes, but not any overlay planes

16:57 <marcan> *bottommost plane

16:57 <marcan> (also obviously the hardware supports it, it's just DCP firmware that doesn't because I guess Apple never needed it for macOS?)

16:57 <marcan> (still feels really weird though)

16:58 <marcan> see https://gist.github.com/marcan/d93ebdffce5b36be9aaa06079a60503f for what I've been able to find about supported pixel formats

17:16 <marcan> jannau: btw, now that I noticed, I think there's one missing thing still. when layers are removed, they should have their bits set in swap_enabled

17:16 <marcan> it's not really "enabled", more like "update/request"

17:16 <marcan> AIUI if a bit is set there and the surface is NULL, the plane is removed

17:16 <marcan> not that it really matters right now since we only support a single plane anyway...

17:22 <jannau> marcan: I think it is there, each plane's update bit gets set if the plane was changed, see the for_each_oldnew_plane_in_state() loop in dcp_flush

17:25 <marcan> jannau: you're right, sorry... misread the patch

17:25 <marcan> I should get some sleep :p

17:27 <jannau> np, I think without it dcp/disp0 would crash instantly crash on fb unmap

23:50 <alyssa> GL_CLAMP in hardware on agx (wrap=4) wat?!

23:55 <alyssa> border colour 3 is definitely for custom

23:56 <alyssa> sampler, 7fff 3fff 1fff ffff

23:56 <alyssa> those.. aren't floats are they..

23:57 <alyssa> ah lol

23:57 <alyssa> rgba16 unorm texture

23:57 <alyssa> so the custom border colour is packed in the actual format

23:57 <alyssa> what a delight

23:59 <alyssa> though it seems to still apply the API swizzle specified maybe