ChanServ changed the topic of #asahi-gpu to: Asahi Linux: porting Linux to Apple Silicon macs | GPU / 3D graphics stack black-box RE and development (NO binary reversing) | Keep things on topic | GitHub: https://alx.sh/g | Wiki: https://alx.sh/w | Logs: https://alx.sh/l/asahi-gpu
capta1nt0ad has quit [Quit: Konversation terminated!]
user982492 has joined #asahi-gpu
capta1nt0ad has joined #asahi-gpu
<bluetail>
Assuming this belongs in GPU since I have not found it in my monitors EDID: Is temporal dithering a feature of the GPU one can turn on or off? If so, is it something that can be achieved with relatively low effort? If it is not possible, are there other options possible, such as limiting the range of colors by software?
capta1nt0ad has quit [Remote host closed the connection]
<marcan>
bluetail: We've already talked about this. Dithering is a feature of monitors themselves, there is no way to control it from software. Given the same signal timings and colorspace settings, monitors will react identically regardless of what device is on the other side.
<yuka>
alyssa: feel free to use those screenshots
<yuka>
If you want you can also tag @yuka@fedi.yuka.dev
<bluetail>
marcan I ask since I was able to disable dithering on my other nvidia machine and it affected the display output in the way that was required
<bluetail>
the other system I talk about has a nvidia card...
<bluetail>
( I did recommend to search in the nvidia settings to disable temporal dithering, fixing the same issue
<marcan>
That looks like a workaround for crappy monitors
<marcan>
The GPU is *not* supposed to be doing 6-bit dithering except on some embedded panels
<marcan>
I'm not aware that Macs do that, they shouldn't, it doesn't make any sense
<marcan>
it's the monitor's job to dither 8-bit or 10-bit input appropriately for its panel
<bluetail>
I see. So I can state two things now: 1. I am only happy with "crappy" displays 2. I am having difficulties with 'good' displays often times and fail to set them to behave like the 'crappy' ones. 3. I am particularly unhappy with apple style displays, assuming PWM flicker to be the cause.
<bluetail>
s/two/three
user982492 has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
<bluetail>
I guess it makes no sense to further discuss my issue, because its pretty niche
<bluetail>
I just brought it up because the other day I could fix somebody with the same issue
<marcan>
If you don't want the flickering, get a true 8-bit IPS panel. 6-bit panels will always have dithering or banding, depending on whether you can find a way to turn the built-in dithering off or have to rely on GPU dithering.
<marcan>
bluetail: Apple tends to use high quality displays these days. I am not detecting any flicker, PWM nor temporal dithering, nor any banding, on my M1 Air, with my phone recording in slow-mo mode.
<bluetail>
marcan what difference does a 'new tech' apple display and a EIZO EV2785 have? I can adjust brightness downwards on the EIZO and do not see 'flies' or get headache. And they are less reflective. I only wished the EIZO's were truly matte! I tried different brands and they appeared to be similar to apple. As much as I like the discussion, I'd like to
<bluetail>
visit a eye specialist. But to my dismay, they do NOT provide any support.
<bluetail>
I have no knowledge about the newer apple displays. But what I can say my issues do not apply to smartphones and tablets. I do not know any of the reasons.
<marcan>
bluetail: That is an 8-bit IPS panel, which is the same technology apple uses
<marcan>
smartphones and tablets also tend to use IPS displays
<bluetail>
So the >only< difference might be the coating and the maximal amount of nits?
<bluetail>
Or is there difference in backlighting as well?
<marcan>
they both use LEDs, how those leds are driven varies. monitors don't exactly list that in their spec sheet.
<marcan>
as I said, I am not detecting any PWM flicker on this one with a phone in high speed mode. I can try with my Blackmagic.
<bluetail>
nono
<bluetail>
the PWM flicker was meant for older apple-tech. I cannot either on the newer ones
<bluetail>
I'm sorry I was being unclear
<marcan>
then what's your concern with the backlight?
<bluetail>
Its that if I turn down brightness to 60% on the EV2785 that I can still see everything and do not see flies on a white background. I do the same things on a macbook pro 2016 or a imac 2019, I see flies. I visited the eye specialist, said everything okay. I asked him if he has some explanation about why I am so sensitive to light and particular see
<bluetail>
flies if I look into newer apple displays... Or even slightly into the sun. And they did not provide an answer or a solution. I tried some glasses and it didnt help. The only thing that seems to work are 'some' monitors. This seems to be a medical issue, yes.
<marcan>
did you compare the EV2785 and the Apple displays side by side in the same setting?
<bluetail>
I did
<marcan>
displaying the same image, like a white background with the white balance adjusted similarly?
<bluetail>
Yes. I set it to 5000K. The issue got worse the more 'cold' the whitepoint was
<marcan>
that sounds like you might be more sensitive to certain wavelengths
<marcan>
the Eizo only has sRGB color gamut. Apple displays have significantly more.
<marcan>
that means they need to use more saturated primaries
<marcan>
it sounds like that might be causing a problem for you, at the wavelength level (not the color mix level)
<bluetail>
Just remembered: I used the sRGB profile on the EIZO because I preffered it
<bluetail>
Thank you for your thorough explanation, I appreciate it!
<marcan>
the Eizo claims 98% sRGB and 75% Adobe RGB. Modern Apple displays are more like ~100% sRGB and 94% Adobe RGB.
<marcan>
this is just conjecture, but it's the only steady-state difference in output that I think you'd get in a plain white image, once you eliminate the backlight modulation as a factor.
<marcan>
bluetail: have you tried Night Mode type stuff to reduce the blues? does that help?
<marcan>
you might also find blue-cut glasses to be an improvement, if blue is the problem (although green purity is where most of the color gamut difference is, blue is more physiologically relevant)
<bluetail>
It does help yes. I might have tried the wrong glasses before. I will try some more.
SSJ_GZ has joined #asahi-gpu
<yuka>
not a complaint, just an info for other people who want to try things: running chromium or minecraft xwayland quickly crashes the compositor, while running as native wayland client usually works fine
<yuka>
but maybe this is specific to the nixos setup I have here
capta1nt0ad has joined #asahi-gpu
capta1nt0ad has quit [Remote host closed the connection]
capta1nt0ad has joined #asahi-gpu
<jannau>
I would in genral recommend to use wayland with dcp/appledrm since it's 1) much closer to how macOS uses it 2) better tested
<jannau>
this seems to be unrelated though
<kode54>
is this with gpu tree?
<kode54>
I assume that junky frame rate is software rendered
thepigguy has joined #asahi-gpu
<yuka>
minecraft 1.19 runs too 🎉
bluetail has quit [Ping timeout: 480 seconds]
bluetail has joined #asahi-gpu
chadmed has quit [Ping timeout: 480 seconds]
thepigguy has quit [Quit: thepigguy]
Dcow has quit []
jlco has joined #asahi-gpu
Dcow has joined #asahi-gpu
Dcow has quit [Remote host closed the connection]
ah- has joined #asahi-gpu
fallenchromium has joined #asahi-gpu
bisko has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
bisko has joined #asahi-gpu
bisko has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
bisko has joined #asahi-gpu
Dcow has joined #asahi-gpu
<Dcow>
could someone share .config from kernel with DRM_ASAHI?
<Dcow>
I want kernel closest to -edge + GPU
bisko has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
<ah->
I'd love that too, just managed to build a kernel on gpu/rust-wip with DRM_ASAHI=y but even though the gpu is in the device tree it doesn't seem to probe
<Dcow>
you also need to update m1n1.bin with dtbs
<Dcow>
I've done that and been able to boot kernel with GPU, but only without initramfs
<ah->
yep, I'm using m1n1 from lina/gpu-wip
<ah->
and "dtc -I fs /sys/firmware/devicetree/base" shows the gpu node, but I can't find anything related to it in dmesg
bisko has quit [Read error: Connection reset by peer]
bisko has joined #asahi-gpu
siontx has joined #asahi-gpu
<ah->
oh interesting, so my kernel halfway boots, but the last log line with any reference to asahi/gpu is "asahi 406400000.gpu: MMU: Kernel page tables created", it then just continues with "nvme-apple 393cc0000.nvme: RTKit: Initializing (protocol version 12)"
<ah->
on a j316c
fallenchromium has joined #asahi-gpu
jlco has quit [Ping timeout: 480 seconds]
jlco has joined #asahi-gpu
Glanzmann has quit [Quit: n8]
gustav8 has quit [Quit: Quit]
fallenchromium1 has joined #asahi-gpu
fallenchromium has quit [Read error: Connection reset by peer]
fallenchromium2 has joined #asahi-gpu
erik3424 has quit [Quit: erik3424]
fallenchromium1 has quit [Ping timeout: 480 seconds]
amarioguy2 has joined #asahi-gpu
amarioguy2 has quit [Remote host closed the connection]
bisko has quit [Read error: Connection reset by peer]
bisko has joined #asahi-gpu
user982492 has joined #asahi-gpu
siontx has quit []
Dcow has joined #asahi-gpu
<ah->
hmm, as far as I can tell it gets stuck in the inner UAT handoff init, probably the magic? maybe the FW doesn't run as expected or it's reading from the wrong address?
<yuka>
Very weirdly what made the difference for getting the gpu-enabled kernel to boot was loglevel
<yuka>
nixos sets loglevel=4 by default and just changing that to loglevel=7 seemingly fixed the boot
<ah->
yuka: !!! i can confirm, mine boots as well with loglevel=7