<lina>
It looks like that pixel format itself is inherently wide gamut, so what you need is another pixel format
<jannau>
lina: yes, I already noticed. dcp says the two other linear uncompressed 30-bit pixel formats are not supported
<lina>
Maybe you need to use the matrix stuff to correct it then?
<jannau>
which is strange since it is supported in the iboot ep
<lina>
Yeah... maybe that endpoint automatically sets that conversion factor?
<jannau>
dcp starts with w30r with an identity matrix but macos probably uses wide gamut not that it matters much for the boot process
<marcan>
I have an idea
LinuxM1 has joined #asahi-gpu
LinuxM1 has quit [Quit: Leaving]
<marcan>
jannau: interesting. so it's not w30r, it's w18p. I dumped the surface descriptor from DCP memory.
<marcan>
2 planes, no idea what the second one is? it's 8bpp and has the bootup apple (and has had always had it with simpledrmfb and I don't see any apple-shaped artifacts so...)
<marcan>
however... using that and faking the second plane, KDE is still crunched.
<marcan>
so that's not it.
<marcan>
let me see if I find any other unknowns around here...
<jannau>
I think the second plane is 8-bit alpha
<marcan>
if so the apple isn't quite opaque, which is interesting
<jannau>
no w18p but I guess the 'w' would indicate wide gamut as well
<marcan>
aand fixed it.
<marcan>
let me clean this up.
bcrumb has joined #asahi-gpu
<marcan>
wait no sec
* marcan
confused himself
<marcan>
nope, not that :(
<jannau>
any other interesting things set in the surface descriptor?
<marcan>
nope... I think I have it copied exactly at this point
<alyssa>
mood
<jannau>
also it is converted correctly on external displays as long as the color mode uses gamma-SDR as EOTF
<jannau>
the only issue is that the single color mode on the mbp 14 is bogus since that seems to be only populated from edid
<marcan>
jannau: do you think it's possible iBoot issues a set_matrix? (that is a thing in the iboot interface too)
iaguis has quit [Quit: leaving]
<jannau>
I would think
<jannau>
that's unlikely
<jannau>
but who knows
systwi has quit [Ping timeout: 480 seconds]
systwi has joined #asahi-gpu
<alyssa>
note to self: optimizing scissor_enable may improve perf slightly
<marcan>
jannau: so I tried the iboot interface from python and it works fine, the image looks normal (with w30r) after doing a swap
<alyssa>
pass type has a huge impact on perf
<alyssa>
not that we can do much about that, but
<marcan>
ohh. but.
<jannau>
marcan: I guess you could try to set an identity matrix and see if that breaks it
<jannau>
I suspect it's the gamma SDR EOTF which makes it work
Dcow has joined #asahi-gpu
Dcow has quit [Ping timeout: 480 seconds]
<jannau>
any use for inverted or greyscale rendering? set_color_remap_mode does that
<jannau>
huh, I completely missed splc_{get,set}_brightness
bcrumb has quit [Quit: WeeChat 3.7.1]
<alyssa>
bah, screw this, let's just play supertuxkart :-p
<marcan>
jannau: ok, so for w18p the extra plane is alpha, and the interesting thing is that we can't see it in the boot FB because there is some kind of optimization where if the plane covers the whole screen alpha is disabled
<marcan>
if I change the bounding box, the apple alpha mask shows up
<marcan>
but also, the colorspace stuff is working properly in iboot
<marcan>
... so why isn't it working in the main dcp?
Dcow has joined #asahi-gpu
<marcan>
... oh ffs.
<marcan>
jannau: it works on surface 1. it does not work on surface 0.
<marcan>
somehow.
<jannau>
dcp_iboot.py with 'IBootLayerInfo.colorspace = Colorimetry.DCIP3' looks similar
<marcan>
but iBoot nominally uses surface 0, I *think*, though there is some weird allocation-ish stuff that might have me confused
Dcow has quit [Ping timeout: 480 seconds]
<jannau>
rustc 1.66 is too new for rust4linux / asahi (yes I know 1.62 is the blessed version but 1.65 was working)
<marcan>
yes, we talked about that on the fedora channel
<alyssa>
ruh roh
<jannau>
no surface[1] has still off colors for me with xfer_func = 13, colorspace = 2
<marcan>
but I don't understand why it works in iBoot with what I believe is surface 0 (unless this changed in a newer firmware, I'm looking at an old one)
<marcan>
I guess I should switch to 12.3 to double check...
<jannau>
I was testing the same with colorspace = 2
<marcan>
but as far as I can tell in iboot it works with all planes, though I *think* I saw it glitch into bad colors at some point but I couldn't reproduce...
<marcan>
so maybe it's a firmware bug?
<marcan>
FWIW iBoot maps the EOTFs 1->13, 2->16 and the colorspaces 1->0, 2->12, 3->9
<marcan>
I guess it's possible we're missing some swap flags to make the colorspace properly effective? dunno, maybe I should see if I can find the iBoot swap struct in RAM too...
* marcan
sleeps
Dcow has joined #asahi-gpu
<alyssa>
marcan: nini
<jannau>
fix confirmed. what an annoying bug
<alyssa>
let's do uhhh
<alyssa>
transform feedback!
<alyssa>
everyone's least favourite GL feature
Dcow has quit [Ping timeout: 480 seconds]
<jannau>
wonderful, using surface[3] results in black screen on t6001
Dcow has joined #asahi-gpu
Dcow has quit [Ping timeout: 480 seconds]
<marcan>
jannau: I think only 0-2 are supposed to work?
Gues__________________________ has joined #asahi-gpu
Gues__________________________ is now known as evtyz
dottedmag has quit [Quit: QUIT]
evtyz has quit []
Gues__________________________ has joined #asahi-gpu
dottedmag has joined #asahi-gpu
Gues__________________________ has quit []
<alyssa>
Hmmm I wonder if I should be too clever for my own good
<alyssa>
panfrost's code here is dumb but I really don't want to copy it
swaggie has joined #asahi-gpu
<alyssa>
oh I see why the panfrost code is silly
<alyssa>
yeah let's not do that.
Dcow has joined #asahi-gpu
Dcow has quit [Ping timeout: 480 seconds]
Dcow has joined #asahi-gpu
Gues__________________________ has joined #asahi-gpu