02:18 airlied: rodrigovivi: thanks, just one comment on it, but yes rc6 is fine
09:37 MrCooper: sigh, vulnerability disclosure cross-posted to security@kernel.org and public lists
10:17 fufexan: MrCooper do you have any idea about the SDR/HDR+WCG issues?
10:19 MrCooper: not really offhand, other than maybe no info packet is sent or an incorrect one
10:22 pq: fufexan, it would not be the first time amdgpu mishandles some info packet for some version of the hardware.
10:23 fufexan: weird that it only happens on OLEDs, LCDs are unaffected
10:24 pq: how many OLEDs and LCDs were tested?
10:25 pq: https://gitlab.freedesktop.org/drm/amd/-/work_items/3358 has some example pictures in the "spoilers" of what I saw in the past.
10:25 fufexan: tested it on two different LCDs (MSI and GIGABYTE) and one OLED (alienware) and we've got two folks on discord say the same about their oleds
10:26 pq: okay
10:26 pq: I was thinking that some monitors might take some of the info packet data imply more than it should, causing or masking the problem.
10:28 pq: also HDMI vs. DisplayPort can be a factor
10:30 fufexan: I am on exclusive DP, I can ask the two guys
10:33 pq: I think amdgpu should have some debugfs files showing the metadata sent?
10:33 fufexan: one of the guys is also on DP but their monitor has a known firmware issue and needs a modeset to clear, but I have an AW2725Q and there are no known defects on it
11:05 dolphin: airlied, sima: no drm-intel-next-fixes this week either, nothing picked up by DIM
11:20 melissawen: fufexan, maybe I didn't fully understand the issue, but hdr output metadata going from/to null requires modeset, as in: https://gitlab.freedesktop.org/agd5f/linux/-/commit/b232d4ed
11:22 melissawen: although I don't know if modeset is actually needed to just update infopacket, but intel also requires it AFAIK
11:27 pq: melissawen, does that also detect metadata that gets the EOTF changed between SDR and HDR? As opposed to just enabling or disabling the metadata completely.
11:28 pq: I mean, the HDR static metadata packet can be used to indicate SDR.
11:32 melissawen: I see, this case didn't force modeset, and needs to reprogram the stream... does this problem only happen on AMD?
11:35 melissawen: If so, I'd try to partially revert this https://gitlab.freedesktop.org/agd5f/linux/-/commit/8c076bc8d731 to reintroduce the is_hdr_static_meta_changed() part
11:37 melissawen: btw, if this is an AMD driver bug, better open an issue on amd issue tracker
11:57 fufexan: I am not sure how it's supposed to work, all I know is that going to HDR without a modeset looks fine, but coming back is broken. I can't test any other gpu, only have AMD.
11:57 fufexan: if it requires a modeset so be it, as long as it works
11:57 fufexan: I am unsure, but KDE and Hyprland both repro this despite being very very different compositors and it only happens on one OLED (mine, which does not modeset between changes, the other one does modeset) so I doubt it's the compositor cuz at least hyprland doesn't even know if a panel is oled or not
12:00 pq: fufexan, I think there might be some confusion about what "modeset" is. Modeset is when the display controller reprograms the stream, which means the stream will break up for a moment, and the monitor will lose picture during that time. However, a monitor may also blank out for a moment even without a modeset. Switching between SDR and HDR signalling is one that is known cause it on some monitors, but
12:00 pq: probably not all.
12:01 MrCooper: fufexan: what does drm_info show for the HDR_OUTPUT_METADATA property when HDR is supposed to be disabled again but effectively isn't?
12:02 pq: Particularly when the SDR/HDR switch is just a few bits on the info packets while the stream continues.
12:04 fufexan: MrCooper: HDR_OUTPUT_METADATA is 0
12:36 pq: enunes, could stop your client from yoyoing, please?
12:36 pq: enunes, could stop your client from yoyoing, please?
12:45 enunes[m]: pq: I stopped it now, sorry for the noise
13:00 alyssa: pendingchaos: will 27.0 be the year of the linux opt_reassociate
13:00 karolherbst: *peeks*
13:01 alyssa: there are now open commits for the big 3
13:01 alyssa: *MRs
13:02 karolherbst: yeah.. I saw. I really need to look into opt_reassoc for nvk again, but any time I did it was always a net negative
13:02 alyssa: it seems slightly positive for intel
13:02 alyssa: but the compile-time impact is serious
13:02 alyssa: so i have reservations there tbh
13:03 alyssa: nir_opt_reassociate itself isn't especially slow but for best results you need to run it in a loop with dce/cse/etc a bunch of times.
13:03 karolherbst: we have a constant factor on fmul and opt reassoc can also really help there...
13:04 karolherbst: though mostly for the "move constants somewhere together" part
13:05 karolherbst: ohh right.. maybe I look into the clamp thing instead of figuring out how to enable subgroups on zink without fp64 🙃 sounds like more fun tbh
13:10 pendingchaos: it only really decreased instruction count by ~0.1%, so the loop didn't seem worth the 20% increase in compile time
13:10 pendingchaos: though I got that to 14% be adjusting the nir_opt_algebraic/etc loop in the function a bit, and I haven't benched again after "nir/opt_reassociate: skip if sort_by_rank=false and CSE heuristic fails"
13:16 alyssa: i'll keep my eyes peeled
13:16 alyssa: I'd be happy to delete the loop in favour of 0.1% hit if that's all it is, lol
13:17 alyssa: and maybe there are better ways to get the benefit, idk
13:21 pendingchaos: I also want to maybe somehow to optimize for better fma to replace nir_opt_reassociate_for_fma and to improve CSE of chains with both add and mul: https://www.irccloud.com/pastebin/W2gCoHqF/
13:23 alyssa: could be cool
13:23 pendingchaos: the motivation to add it to radv though, was I was changing some reassociation optimizations in nir_opt_algebraic so they weren't done if they didn't help (because they can make register usage explode in a shader), and it turned out they were helping CSE a little in our fossil-db
13:24 alyssa: Yeah
13:24 alyssa: nir_opt_reassociate exists to make CSE more effective
13:25 alyssa: everything else grew from there
13:25 alyssa: but CSE in general blows up reg pressure
13:27 pq: enunes[m], thank you!
13:27 alyssa: pendingchaos: https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/36088 if you want a history lesson
13:36 pendingchaos: I wonder if DCE was run before CSE in https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/36147#note_3011570
13:36 pendingchaos: I noticed that was pretty bad for reg pressure, because if the pass was run with the CSE heuristic, it would create create clones of the chains at the root, moving the srcs downwards
13:38 pendingchaos: more precisely, if the CSE hueristic was enabled but it didn't end up finding a best_pair
13:51 glehmann: pendingchaos: I think we should also look into improving the CSE heuristic for cmat addressing, iirc the current one isn't perfect for FSR4
14:14 dcbaker: karolherbst: On the staging/26.3 branch I pulled in one other commit (not yours) to get your queue work to apply cleanly (it seemed more correct than me basically reimplementing the patch. I noticed only 3 of the patches were tagged for backport in that series, also want to verify that's correct and you didn't want all 4
14:24 karolherbst: dcbaker: there are only three patches, but the first one had a Fixes tag
14:25 karolherbst: ohh you mean 45330
14:25 karolherbst: yeah that was intentional
14:25 dcbaker: cool, just wanted to make sure
18:55 karolherbst: anybody knows a good list of common float numbers shaders are clamping values to? like in the form of clamp(x, -c, c)
18:55 karolherbst: wondering what common c there are
20:44 karolherbst: do we have any helpers to make writing code like this any easier/cleaner? https://gitlab.freedesktop.org/karolherbst/mesa/-/commit/86b9cf93f1344751e92054d14f0093a5d7be0c4d
20:45 zmike: easier yes but you're not gonna like my answer
20:45 karolherbst: :D
20:45 zmike: :D
20:45 karolherbst: not going to make it easier to read tho...
20:46 karolherbst: the alternative idea I had to deal with those things are just nir search helpers...
20:47 karolherbst: then I wouldn't have to write the rewrite rule.. just write a pattern matcher
20:47 karolherbst: (or somebody reviews https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/41678)
20:48 karolherbst: guess there needs some clean ups to figure out how we want to deal with constant types there
20:49 karolherbst: yeah.. I think I'll just use a custom nir_search_helper thing and.. then make my lifer a lot easier
21:57 mhenning: yeah, a search_helper might be reasonable
22:00 karolherbst: well.. it seems like 90% of the matches are against 1.0.. oh well
22:10 karolherbst: mhh one fs clamps to +-100000.000000... interesting