17:40mhenning[d]: phomes_[d]: For the performance comparison tool that you wrote, is that based on renderdoc? That kind of analysis would be useful for pinpointing why https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/38874 regresses lego builder's journey (but also renderdoc doesn't support raw_access_chains yet)
17:56glehmann: karolherbst: https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/40541#note_3386486 makes me think you are not using nir_opt_peephole_select properly
17:56karolherbst: glehmann: possibly
17:57karolherbst: I should look at it, but I also don't know what could go wrong there?
17:57karolherbst: mhh
17:57karolherbst: limit is set to 0
17:59mhenning[d]: Oh yeah, I've been meaning to increase the limit on peephole_select but haven't found the time to figure out the right value
17:59glehmann: yeah that's basically the empty block only mode
17:59karolherbst: mhenning[d]: I can do some testing on it.. but I also won't have time until mid next month :D
17:59karolherbst: but yeah...
17:59karolherbst: I think that should help a lot
18:02karolherbst: mhenning[d]: I was wondering if instruction predication based on bcsel would be an interesting approach... just predicate the two trees producing those values up to hitting common stuff or so
18:03phomes_[d]: mhenning[d]: yes it is just a visualization of renderdoc's duration timer. I can run the test or put the "tool" somewhere. It is just a streamlit app with a reader for renderdocs text expoert
18:52mhenning[d]: phomes_[d]: yeah, if you could put it somewhere that would be useful
18:54mhenning[d]: karolherbst[d]: I guess the question is: what is the point of predicating the two sides of the bcsel? I don't expect that adding predicates alone will make anything faster.
18:56mhenning[d]: If you can allocate variables from each half of the predicate to the same register then you'll get a register pressure improvement, but I don't know concretely how to deal with that in our register allocator (or any tree-scan allocator for that matter)
19:10siggi_: So, my K2100M (NVE6 (GK106)) with the artifacts. I'm a dog on a bone (sorry karolherbst :)
19:12siggi_: Is it reasonable to think that the problem might be with the crtc setup?
19:13siggi_: (flickering on the right-hand side of the LCD, occasional whole-screen shearing)
19:14karolherbst[d]: mhenning[d]: fewer registers used?
19:14siggi_: I'm only really familiar with old-school CRT signals, where you might see similar problems if the horizontal (or vertical) timings are off
19:14karolherbst[d]: ah you mentioned it
19:14karolherbst[d]: yeah.. I guess for RA we need a different construct then...
19:19siggi_: I've been looking at the vbios, and while I can see how it'd set up registers
19:19siggi_: I don't see how it would set up the (what I think of as) a conventional crtc for a particular mode
19:21siggi_: ... time passes ...
19:22siggi_: so, EDID communicates the built-in panels native resolution?
19:23siggi_: can anyone sic me at some overview docs on "how things work"(TM) and put me out of my misery?
19:26airlied[d]: I don't think we really have any good docs. Does it happen in fbcon?
19:26siggi_: ... and then the GPU provides various available resolutions listed in vbios?
19:27airlied[d]: You read the EDID, configure the crtc timing, set the planes up, configure the encoder for LVDS and off it gord
19:28siggi_: I'd like to understand enough to be able to dump and compare the relevant register sets between nvidia and nouveau for my broken card
19:28airlied[d]: As it ever worked on nouveau?
19:28siggi_: how do you go from EDID to crtc register settings?
19:28siggi_: As far as I know it's always artifacted
19:28siggi_: but I'm new to this
19:29siggi_: so that's hearsay
19:29siggi_: from my CRT timing experience, it looks like some kind of timing issue
19:30siggi_: flickering strips on the right-hand side of the LCD
19:30siggi_: and occasional whole-screen shearing
19:30siggi_: reported for a couple of years on K2100M and someone above sees it on K2000M as well
19:32siggi_: (I wrote an FB driver back in the nineties, and a replacement driver for an Apple video card before then (Monitor Expander)), so my "experience" is quite dated :(
19:44airlied[d]: I'm not too up on where kepler is in the modesetting evolution, but dispnv50 has the classes for each evo channel revision, evo then does the modeset in fw
19:44airlied[d]: so it's not really a traditional register poking in the driver at least, it uses the evo firmware
20:29Siggi: arlied: Thanks. Would the firmware be written for https://envytools.readthedocs.io/en/latest/hw/falcon/intro.html? 20:30Siggi: I guess if I can disassemble the firmware, I can triangulate to the registers?
20:32Siggi: Since the card works fine with the nvidia proprietary driver, it'd be my guess that there's either a problem in the firmware the nvidia driver works around, or perhaps there's a problem in interfacing to the firmware?
20:50Siggi: <airlied[d]: also in my case it's ePD, IDK that it matters for the crtc?
20:50Siggi: airlied[d]: also in my case it's ePD, IDK that it matters for the crtc?
20:54airlied[d]: oh eDP is different than LVDS, usually for eDP the crtc gets a different timing, but the code should handle all of that, and the encoder gets programmed different since it needs to setup DP
20:56airlied[d]: https://lore.kernel.org/nouveau/20251201202502.1591252-1-airlied@gmail.com/ does that help at all? probably not
21:03Siggi: everything helps, as I'm starting nowhere :)
21:04Siggi: I built envytools, so I can get the vbios and I can (hyptothetically) disassemble the bios code - assuming I can pull it with vbios and that the ISA is covered by nvdis