08:27 airlied: jani: is this known upstream https://bugzilla.redhat.com/show_bug.cgi?id=2564724
09:39 lucaceresoli: Hi, while applying some drm-misc patches I got a drm-tip merge failure due to conflicts on 2 intel files (intel_psr.c and intel_dp.c), totally unrelated to what I was applying.
09:40 lucaceresoli: Who should fix that conflict?
09:40 lucaceresoli: I can do my best but I don't know that code, not sure I'd dix it correctly.
09:42 lucaceresoli: ^ jani or rodrigovivi ?
09:49 lucaceresoli: s/dix it/fix it/ -- hmmm, how can I fix it if I can't even write "fix it" properly? XD
10:30 jani: lucaceresoli: works for me, please try again?
10:34 tzimmermann: PSA: With the merge window ended, drm-misc-next-fixes is now closed again. After -rc1, relevant fixes go into drm-misc-fixes. Patches in -fixes branches should be small and have a Fixes tag. New features always go into drm-misc-next.
10:35 lucaceresoli: jani: indeed, works now, thanks for looking at it
10:36 jani: lucaceresoli: I didn't do anything, but no problem :D
10:40 dolphin: lucaceresoli: I fixed the merge conflict in between
10:41 dolphin: it was a silent conflict causing build failure, so took bit more detective work to figure out
10:41 dolphin: s/was/had/
10:42 lucaceresoli: dolphin: ah, thanks!
10:42 dolphin: don't thank me, I also caused the breakage when cherry-picking drm-intel-fixes :)
10:42 dolphin: you just happened to be pushing at the same time
10:42 lucaceresoli: dolphin: :-)
16:46 jenatali: Hey all, I wanted to give folks a heads up. The XBOX and DirectX teams at Microsoft have been taking a look at ACO and we have seen some pretty exciting results using it to compile shaders for XBOX consoles, and we are going to start including it as an option for developers to use in the GDK.
16:47 jenatali: We want to help contribute to the community and I'll be onboarding new long term contributors and helping to advise how to get contributions flowing.
16:49 zmike: sweatytowelguy
16:51 kisak: This is quite funny in certain ways. Hope it goes well.
16:56 Hazematman: wow that's super exciting!
17:03 jani: mlankhorst: mripard: tzimmermann: ack for merging patches 1-2 through drm-intel? the only users are in i915 anyway. https://lore.kernel.org/r/4469a3881155f067bd127fcaa21b7b2ec8d2fb48.1793361738.git.jani.nikula@intel.com and https://lore.kernel.org/r/6d75f01075e2ea41fde8620677b3182bcdaabff7.1793361738.git.jani.nikula@intel.com
17:04 tzimmermann: jani, ack
17:09 jani: tzimmermann: thanks
17:10 glehmann: jenatali: cursed
17:14 glehmann: I'm kind of curious how you want to integrate aco anywhere outside of mesa because shader ABI is currently largely defined in RADV code
17:15 jenatali: It's a separate ABI for the XBOX driver
17:15 jenatali: XBOX does offline compilation separate from the driver stack so it's had a stable driver ABI
17:16 karolherbst: I guess this could be a tool inside mesa that implements that ABI on top of ACO?
17:17 jenatali: Yeah I think that's basically how it's hooked up, it's built as a DLL right now for the GDK
17:17 glehmann: do you only want to use ACO, or the full vtn-> radv opts -> aco stack?
17:17 jenatali: Right now it's dxil-spirv -> vtn -> opts -> aco
17:18 jenatali: I've not been too closely involved but I'm going to get more involved as people figure out how upstream works
17:20 karolherbst: sounds like a fun project
17:21 jenatali: Apparently it can improve GPU perf by quite a bit compared to what we built based on LLVM. I think I saw a 2-16% claim depending on the shader
17:22 glehmann: well, we try to make things fast :D
17:27 karolherbst: but how much slower can it be?
17:27 karolherbst: filling the gaps would be interesting I assume
17:45 pac85: That's interesting
17:46 pac85: I imagined offline compilation on consoles could afford more expensive optimizations
17:56 alyssa: jenatali: oh boy
17:56 alyssa:gets a bag of popcorn and a glass of sparkling grape juice
18:01 jenatali: :)
18:02 pac85: I guess what's gonna be upstreamed is improvements to the compiler itself?
18:03 pac85: Or changes to make it into a standalone offline compiler?
18:03 pac85: (or both ig.)
18:03 jenatali: Yeah as I understand it, some of the studios that tried it out have some improvements to contribute. If people are interested, I think we'd like to contribute the ABI support and ability to build the offline compiler
18:04 pac85: I can imagine it makes sense on your side to avoid having a diverging branch and having to rebase constantly yeah
18:05 jenatali: Yeah, exactly
18:21 karolherbst: offline compilation is also kinda interesting for rusticl, but I kinda postpone dealing with this once shiva is ready 🙃
18:42 jenatali: karolherbst: in case you missed it, D3D is requiring all vendors to do offline compilation nowadays
19:07 glehmann: karolherbst: do you remember why nir_fmad_or_ffma is a thing in lower_doubles? why not just use ffma_weak?
19:08 karolherbst: glehmann: I think so that the pass is self-contained and doesn't rely on opt_algebraic
19:08 karolherbst: yeah.. something like that was going on
19:08 karolherbst: not every driver has it in an opt loop
19:08 karolherbst: Should probably have added a comment there
19:13 karolherbst: anyway.. I wouldn't mind fixing drivers, but... probably good to keep CPU overhead in mind
19:22 dcbaker: zmike: There's a series of backports starting with 2cb9c86bbc, and they're over my head to backport (all from the same MR: https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/45723). Not sure what you want to do with those
19:24 dcbaker: @gfxstrand: To get "nir/lower_goto_ifs: Track outside blocks separately from break" pulled into staging/26.3 I had to pull most of that series. I would appreciate a double check that everything there looks okay if you have a moment
19:28 zmike: dcbaker: my availability this week is limited so I'll just say "use your judgment"
19:28 dcbaker: zmike: Punt them till after 26.3.0[-rc4]?
19:29 zmike: or just punt permanently, up to you
19:30 dcbaker: I'll ask you again next week, if you're still too busy I'll drop them permantently
19:42 jenatali: jackell (Jack) is one of the primary engineers behind the ACO XBOX effort in case people have any technical questions. I think Adam might also be here or will be here
19:46 zmike: dcbaker: this is my last week for the year, so you'll have to wait till january
19:48 alyssa:assumed Friday was your last day
19:48 zmike: friday was last real day
19:49 zmike: this week I am only aroundish
19:49 jackell: Hey everyone, I'm a dev on D3D and Xbox. Adam and I have been driving the ACO on Xbox project, it's been a really fun and interesting project and we are grateful for the quality community has created. Happy to answer any questions you may have about the project.
19:49 alyssa: jackell: radv on xbox when???
19:50 alyssa:ducks
19:51 karolherbst: I'm pretty interested in that project more from a ecosystem perspective. Like if we could build up proper offline compilation infrastructure as a core mesa thing, that would be kinda cool
19:51 jackell: This project does actually leverage RADV a bit, we actually stand up a NULL RADV driver with the Xbox GPU characteristics and then use vulkan to compile the pipelines
19:51 karolherbst: there are some interesting applications, like apparently it's a thing some CL impls also ship (allowing to create CL binary objects offline)
19:52 dcbaker: zmike: Oh, right, your yearly disapearance :D
19:52 dcbaker: I'll drop them
19:52 karolherbst: and there are also some drivers that pre compile binaries at build time... might make sense to streamline all of that if we get more into offline compilation
19:52 karolherbst: (for internal shaders)
19:57 alyssa: jackell: Oh, cool. So you are using radv's optimizations then..?
19:57 alyssa: jenatali: didn't think so (comment at 12:17 eastern)
19:57 alyssa: unless i'm confused
19:57 jackell: Yup! Initially I tried to just use ACO in isolation but I figured RADV is already really good so I tried to just leverage all of that
19:58 jackell: So it's kind of a weird setup where RADV is used to create the full pipeline and then it gets translated to an Xbox pipeline
20:05 Kayden: very cool!
20:22 alyssa: entertaining
20:23 alyssa: now just to go the rest of the way ;)
20:26 alyssa: karolherbst: honestly vulkan drivers + drm-shim + EXT_shader_object ...
20:27 mareko: wow, incredible
20:31 jackell: A good chunk of the Xbox driver lives on the GPU CP so we would lose a lot of CPU perf if we went full RADV
20:58 airlied: jackell: so you write your own CP firmware that offloads a bunch of work, nice
21:03 karolherbst: might be something fun to add to mesa as well...
21:03 karolherbst: though I also wouldn't be surprised if that matters more to consoles
21:10 jenatali: zmike: Wow
21:12 zmike: daniels made me
21:13 airlied: karolherbst: it requires custom firmware, which maybe mareko could figure out :-)
21:17 glehmann: zmike: can you tell your LLM that commit hashs in MR descriptions are not useful because they are going to change with mesa's rebase workflow
21:18 zmike: glehmann: it's fine if I never rebase
21:19 zmike: I told it to do exactly what you see
21:19 jenatali: The description can also be regenerated after rebase pretty easily
21:19 zmike: yep
21:26 mareko: I've thinking of throwing the CP FW at my static analyzer to estimate the execution time of all packets from FW disassembly
21:28 mareko: only gfx11-12 FW though
21:31 ajmiles: Hello all, "Adam" here. I worked with Jack on the ACO-on-Xbox effort. Lots of 'fun' weeks debugging all manner of GPU corruption but super pleased with the results at the end of it. Looking forward to many more developers taking advantage of it in the coming months and years.
21:31 Venemo: jenatali: looks like jackell quit. when you say lives on the GPU CP, do you really mean custom firmware or something like DGC?
21:32 jenatali: Really custom firmware
21:32 jenatali: (We don't really use IRC over here, I think he was on webchat and had to step away)
21:32 ajmiles: The origin of that was the Xbox One era when the Jaguar CPUs were incredibly weak and we wanted to offload as much as possible from the CPU
21:33 austriancoder: zmike: maybe you can have a second look at !45509 before your break?
21:35 zmike: I'll try
21:36 Venemo: ajmiles: I see. Does that mean y
21:37 Venemo: ajmiles: I see. Does that mean you have a few custom PM4 commands or something else entirely?
21:38 ajmiles: More than a few. I'm not sure how much of the OG firmware actually still gets used.
21:39 ajmiles: The most impactful ones are probably custom packets for SetPipelineState and ExecuteIndirect
21:42 Venemo: If you can find a good way to support those in RADV in some way, I think we'd be receptive to that
21:48 ajmiles: We have a handful of bug fixes in ACO that are probably good gateways to us starting to build our contributions. Speaking for myself at least, contributing back to open source projects is a new thing, so I'm sure I'll be asking Jesse and folks here for advice as we go!
21:50 Venemo: sure
21:50 Venemo: we are looking forward to it
21:50 Venemo: :)