03:10 MoeIcenowy: https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/46048 should llvmpipe have architecture-and-LLVM-version-specific code for optimizing the performance?
03:12 airlied: MoeIcenowy: yes seems fine, not that I like it, but if we can't make the arch specific path be generically useful then do it
04:26 karolherbst: maybe we should just require llvm-15 or.. 18... is there any reason why we support _that_ old of llvm?
04:45 MoeIcenowy: karolherbst: this sounds reasonable but bumping LLVM still sounds something deserves caution
04:46 MoeIcenowy: BTW review wanted on https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/37945 , which is now a dependency of !46048
05:05 karolherbst: MoeIcenowy: yeah.. but we kinda require llvm-15 across a couple of drivers already...
05:06 karolherbst: so maybe we should do llvm-15 as the lowest and get rid of everything else
05:19 airlied: karolherbst: I think vmware still build against some wierd old things, but not sure
06:05 MoeIcenowy: karolherbst: yes, for orcjit support 15 is also baseline
06:06 MoeIcenowy: well the baseline for amd_with_llvm now is 18; but considering the existence of ACO maybe some people will choose to disable amd_with_llvm instead of bumping LLVM?
09:02 dolphin: dim: 67d474fb061f ("Merge remote-tracking branch 'drm-xe/drm-xe-fixes' into drm-tip"): merge commit justification missing.
09:04 dolphin: looks like dim broke since last commit
09:10 dolphin: now I am getting amdgpu test conflicts
09:10 airlied: dolphin: drm-xe-fixes was in a bad state last week
09:10 airlied: had rebased commits from Linus' tree in
09:10 airlied: I was tempted to git reset --hard it to Linus and let someone else sort it out, but didn't get to it
09:11 dolphin: hmm, I just rebased drm-intel-fixes to -rc2 to verify no patches were left over and then getting strange conflicts and and error message like that
09:11 dolphin: maybe I wait for Rordigo to wake up and fix it
09:13 airlied: yes I think it's xe-fixes breaking thing
09:18 airlied: ah screw it, I'll fix it
09:18 airlied: prepare for lots of me in signoffs
09:21 airlied: okay I've overridden the branch with all the patches rebased and signed off
09:21 airlied: doing tip reubild
09:42 airlied: dolphin: drm-tip is working, though there was an iouring patch I had to drop in intel ci topic
09:56 dolphin: airlied: thanks!
10:08 pendingchaos: karolherbst: I don't think !45745 would affect ACO
10:08 pendingchaos: ACO has a imad instruction, but it's for optimizing within ACO, so has_imad isn't set, and I don't think using it would be faster than that algebraic pattern
10:08 pendingchaos: so I think the commit is fine (glehmann: assuming you have no plans to set has_imad)
10:09 glehmann: for 32bit no, but I think we want to combine 64bit imad in NIR
10:10 glehmann: (with is_used_once only though)
11:23 karolherbst: pendingchaos: right... I guess some hw have slow imad/imul. I did consider adding an option that says "has_fast_imul" to better reflect what's happening there, but I'm also happy to go with the current change I have. Not quite sure, opts like that can be highly hw specific, so I was wondering
12:11 karolherbst: glehmann: yeah.. I thought about that. In that MR I'm doing it in the backend for now, but I could also add an has_imad64 option or something and move it into core
12:12 karolherbst: though it's also too late to do in late_algebraic...
12:12 karolherbst: so it wouldn't be useful to us anyway
12:18 glehmann: I want to implement it in the backend for aco, mostly because we have full 64bit mul as one SALU instruction
12:18 karolherbst: a real full 64 bit mul? impressive
12:19 karolherbst: though I guess it's a matter of how fast it is..
12:19 karolherbst: our imad is as fast as ffma, and imad_2x32_64 is half rate
12:51 glehmann: oh, it's a mess
12:51 glehmann: s_mul_u64 takes 5 cycles, s_mul_u32 takes one cycle, our 32bit VALU mad replacement takes 3 cycles, 24bit mad takes 1 cycle, 32 * 32 + 64 mad takes 4 cycles
13:18 karolherbst: .... impressive
13:19 karolherbst: so I guess I'll go with "it's the backends problem" 🙃
13:23 karolherbst: and here I'm considering using imad for the address calc bits, because the shifts + iadds are more expensive, but that will require proper nuw handling on the offset or something..
14:21 alyssa: glehmann: imagine knowing cycle counts for your hw platform
14:23 glehmann: I mean, amd doesn't tell anyone. So the best we have is partially incorrect LLVM cost model code, benchmarks and marketing slides
14:23 karolherbst: ...
14:24 alyssa: ah, so the same as we have :]
14:25 karolherbst: anyway.. I'm happy to make this all the backends problems to figure out how fast their imul/imad is :D
14:26 glehmann: sometimes I think even internal docs don't have enough cost info, otherwise why didn't someone think of this before: https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/45619
14:26 karolherbst: heh.. yeah...
14:26 karolherbst: that reminds me.. we still have to add XMAD support to NAK
14:27 karolherbst: though that only matters for archs we can't change clocks, sooo.... whatever really
14:27 glehmann: does that still exist on turing+?
14:27 karolherbst: nope
14:27 karolherbst: there we get an actual fast imad :D
14:28 glehmann: nvidia imad throughput is kind of insane compared to every other desktop gpu
14:28 karolherbst: well.. it matters for compute somehow
14:29 glehmann: iirc intel only has fast 32*16 multiplications
14:29 karolherbst: all we know is, that imad is considered an fma operation :)
14:30 karolherbst: but yeah...
14:31 karolherbst: I have to add support for .reuse to NAK.. that gives us like 20% more throughput as well (or vkpeak perf for fp32)
14:31 karolherbst: should also help with imad
15:56 alyssa: karolherbst: oh, yeah, .reuse is a big deal for agx too
15:56 alyssa: intel's accumulators are basically .reuse but software-managed (:
15:58 karolherbst: yeah... I... have some code to start it, I want to finish it until the end of the year for reasons
16:00 alyssa: the agx pass is really naive
16:05 karolherbst: the thing is... hw details 🙃
16:06 karolherbst: I kinda know how it's supposed to work, but it's a bit messy
16:06 karolherbst: the bits mean something else depending on instruction types, so that's a lot of fun
16:07 karolherbst: and depending on the type of stall
17:15 lucaceresoli: lumag_: I was about to add a non-drmm variant of drmm_connector_hdmi_cec_notifier_register(), because it's needed for the hotplug work...
17:15 lucaceresoli: ...but I noticed it has a single user, the drm_bridge_connector, and it never had any other
17:16 lucaceresoli: so I was wondering whether it still makes sense to have it as a separate piece of code, or not
17:16 lucaceresoli: do you expect more users of that helper?
17:18 lucaceresoli: BTW it's a lot of boilerplate code (66 lines, some 25-ish are actual code, not counting the include file) so moving the actual code to its only user appears reasonable at first sight, unless there are more expected users
17:19 CounterPillow: I reckon all non-bridge-connectors that aren't The Two Usual Suspects will be moved to bridge connectors, and The Two Usual Suspects will make their own helpers
17:51 lucaceresoli: CounterPillow: interesting POV :)
23:05 airlied: mlankhorst: just realised one of the misc-next pulls that was probably for 7.5 got into 7.4, my bad :-) the 16/10 one