00:55karolherbst[d]: mhhhh nir_opt_offsets doesn't look through u2u64...
00:55karolherbst[d]: maybe I should just run it again lol...
00:56karolherbst[d]: the result is beautiful
00:57karolherbst[d]: https://gist.github.com/karolherbst/c5475975de9ca2e6088c10f684fe7261
00:57karolherbst[d]: instr/cycles/gprs: 855/2365/112 -> 575/1285/88
00:58karolherbst[d]: finally my work is paying off hard 😄
00:58karolherbst[d]: but also why isn't shit vectorized 😄
01:02karolherbst[d]: mhh let me try something
01:04karolherbst[d]: ahh yeah using uldc runs into the prepass issue again.. rough
01:04karolherbst[d]: or rather.. sometimes the result is used in a vector op...
01:04karolherbst[d]: I have to optimize for it...
01:05karolherbst[d]: yeah.. I'll just run nir_opt_offsets after folding the GPR+UGPR source (and potentially dropping a u2u64) so I can fold even more constants in...
01:05karolherbst[d]: or I could teach nir_opt_offsets about u2u64...
01:06karolherbst[d]: but not sure I could do that in common code...
01:06karolherbst[d]: like it can impact overflows and stuff..
01:06karolherbst[d]: I probably have to do an uub check or something?
01:07karolherbst[d]: yeah.. I think I have to...
01:08karolherbst[d]: in which case it would be better to handle it explicitly inside nir_opt_offsets
01:08karolherbst[d]: it already has all the code for it
01:36karolherbst[d]: mhh sadly not many shaders benefit from this one, but oh well 😄
01:38karolherbst[d]: all the related opts together I haven't landed yet:
01:38karolherbst[d]: Totals:
01:38karolherbst[d]: CodeSize: 9458124656 -> 9321961152 (-1.44%); split: -1.46%, +0.02%
01:38karolherbst[d]: Number of GPRs: 47358138 -> 46630454 (-1.54%); split: -1.54%, +0.01%
01:38karolherbst[d]: SLM Size: 5409024 -> 5408136 (-0.02%); split: -0.02%, +0.00%
01:38karolherbst[d]: Static cycle count: 6129436959 -> 6052038590 (-1.26%); split: -1.38%, +0.12%
01:38karolherbst[d]: Spills to memory: 44453 -> 43465 (-2.22%); split: -2.63%, +0.41%
01:38karolherbst[d]: Fills from memory: 44453 -> 43465 (-2.22%); split: -2.63%, +0.41%
01:38karolherbst[d]: Spills to reg: 186365 -> 201672 (+8.21%); split: -0.35%, +8.56%
01:38karolherbst[d]: Fills from reg: 226976 -> 234602 (+3.36%); split: -0.28%, +3.64%
01:38karolherbst[d]: Max warps/SM: 50638804 -> 50914624 (+0.54%); split: +0.55%, -0.00%
08:18mangodev[d]: karolherbst[d]: the spills to reg are… 😳
08:18mangodev[d]: but no. GPRs, static cycle count, and spills/fills from memory look nice!
08:18mangodev[d]: viva la NVK!
10:23karolherbst[d]: well spills to reg are not really relevant
17:01fomys: Does this error ring a bell to someone? It seems related to nouveau driver, probably introduced in a recent ubuntu update (6.17 compiled mid january according to uname). There is no obvious "common factor" between crashes (It can happen just after login, 30 minutes later or not at all). It is "reproducible" on multiple machines (it is in an university, ≈100 identical computer, bug can happen on any of them).
17:02fomys: [ 3855.251679] nouveau 0000:01:00.0: gr: TRAP ch 3 [00ffa93000 Xorg[1383]]
17:02fomys: [ 3855.251693] nouveau 0000:01:00.0: gr: GPC0/TPC0/SM0 trap: global 00000004 [MULTIPLE_WARP_ERRORS] warp b180020 []
17:02fomys: [ 3855.251698] nouveau 0000:01:00.0: gr: GPC0/TPC0/SM1 trap: global 00000004 [MULTIPLE_WARP_ERRORS] warp b100020 []
17:02fomys: [ 3855.251704] nouveau 0000:01:00.0: gr: GPC0/TPC1/SM0 trap: global 00000004 [MULTIPLE_WARP_ERRORS] warp b040020 []
17:02fomys: [ 3855.251709] nouveau 0000:01:00.0: gr: GPC0/TPC1/SM1 trap: global 00000004 [MULTIPLE_WARP_ERRORS] warp b0b0020 []
17:02fomys: [ 3855.251715] nouveau 0000:01:00.0: gr: GPC1/TPC0/SM0 trap: global 00000004 [MULTIPLE_WARP_ERRORS] warp b100020 []
17:02fomys: [ 3855.251721] nouveau 0000:01:00.0: gr: GPC1/TPC0/SM1 trap: global 00000004 [MULTIPLE_WARP_ERRORS] warp b1c0020 []
17:02fomys: [ 3855.251728] nouveau 0000:01:00.0: gr: GPC1/TPC1/SM0 trap: global 00000004 [MULTIPLE_WARP_ERRORS] warp b0c0020 []
17:03fomys: [ 3855.251733] nouveau 0000:01:00.0: gr: GPC1/TPC1/SM1 trap: global 00000004 [MULTIPLE_WARP_ERRORS] warp b100020 []
17:03fomys: [ 3855.251738] nouveau 0000:01:00.0: gr: GPC1/TPC2/SM0 trap: global 00000004 [MULTIPLE_WARP_ERRORS] warp b0e0020 []
17:03fomys: [ 3855.251742] nouveau 0000:01:00.0: gr: GPC1/TPC2/SM1 trap: global 00000004
17:03fomys: [MULTIPLE_WARP_ERRORS] warp b070020 []
17:03fomys: [ 3855.251763] nouveau 0000:01:00.0: fifo: fault 00 [VIRT_READ] at 0000003fe68b0000 engine 40 [gr] client 01 [GPC1/T1_1] reason 02 [PTE] on channel 3 [00ffa93000 Xorg[1383]]
17:03fomys: [ 3855.251768] nouveau 0000:01:00.0: fifo:000000:0003:[Xorg[1383]] rc scheduled
17:03fomys: [ 3855.251770] nouveau 0000:01:00.0: fifo:000000: rc scheduled
17:03fomys: [ 3855.251777] nouveau 0000:01:00.0: fifo:000000:0003:0003:[Xorg[1383]] errored - disabling channel
17:03fomys: [ 3855.251781] nouveau 0000:01:00.0: Xorg[1383]: channel 3 killed!
17:04karolherbst: fomys: using modesetting or the nouveau X driver?
17:04fomys: good question, I will check
17:04mhenning[d]: also what video card do you have
17:13fomys: I leaved the university (problem was yesterday) and the vpn is not working, but I will follow up tomorrow with a full report. Can you at least confirm me that it seems to be a driver / X11 bug and not a random userspace application ?
17:14mhenning[d]: Yes, the fact that it's xorg crashing suggests it's likely a driver bug or an xorg bug
17:15karolherbst: though on older systems it might report Xorg as the causer, because that's how things were
17:18fomys: okk, I will try to isolate more specifically the issue
17:18fomys: thanks!
19:40esdrastarsis[d]: mohamexiety[d]: Is there any progress in your local tree? I was taking a look in your branch on gitlab (nice work, btw)
19:55mohamexiety[d]: esdrastarsis[d]: there's a little bit i havent pushed but overall not really, need to think more about some stuff more:
19:55mohamexiety[d]: - there are some important parameters that are missing from the rusd interface, so have to look for them (voltage and fans)
19:55mohamexiety[d]: - so far i didn't do anything for writing values (e.g. setting a specific PL or such) only reading, so that's missing
19:55mohamexiety[d]: - the stuff not covered by hwmon will need its own interface (+hwmon itself is kinda suboptimal for the way the GSP stuff works so it's probably preferable to have the other interface anyways)
19:55mohamexiety[d]: - this is for when all is working but have to figure out a good way to handle an app reading multiple sensors/groups since the current way in the wip branch would be very bad
19:55mohamexiety[d]: - cleanup
19:55mohamexiety[d]: i'll get back to it in a bit when i progress more on the perfetto stuff
21:35esdrastarsis[d]: mohamexiety[d]: Does the temperature reading works?
21:36mohamexiety[d]: esdrastarsis[d]: not yet. little bit of cleanup left for that but i thought to look into the rest of the stuff first