00:38 Company: mort_, lina: re the discussion about cursor latency on reddit: Is it possible to update the cursor plane independent from the rest of the planes?
00:38 Company: then you could do a compositor that does vsync for the main image and low latency for the cursor
00:44 zamundaaa[m]: Company: KWin already does that, as far as KMS allows
00:44 zamundaaa[m]: An AMEND flag to allow you to amend the last atomic state even after the pageflip has happened (whenever possible) has been talked about before, but never went anywhere unfortunately
00:45 Company: would that mean that kwin should have lower latency in mort_'s test?
00:46 Company: or do the drivers eat that benefit?
01:41 zamundaaa[m]: Company: possibly. I haven't looked into it too far yet
01:42 zamundaaa[m]: I did build myself a latency measurement thing for a different reason though, so I may test legacy vs atomic cursor movement soon-ish
01:45 Company: I'd be interested in that
05:11 DemiMarie: Does Linux have any analog to D3D12’s concept of reserved resources? The Windows kernel implementation is apparently designed to have the GPU update its own page tables, which seems rather strange and tricky because it requires the kernel driver to generate GPU commands to do that.
08:04 mlankhorst: DemiMarie: Xe does that.. O:)
08:11 phasta: agd5f, thx. Is there a list of AMD GPUs that should run on Linux?
08:26 DemiMarie: phasta: It is safe to assume that Linux supports an AMD GPU unless you have a reason to believe otherwise.
08:27 DemiMarie: mlankhorst: Interesting! Does it actually have a kernel-mode JIT or does it just use the DMA engine?
08:28 MrCooper: yep, the list is basically "every released AMD GPU"
08:37 phasta: Just yesterday I discovered this crazy Vulkan issue on AMD, where you have to use vulkan-radeon instead of amdvlk. Seems the usermode driver is broken at times? https://wiki.archlinux.org/title/AMDGPU#Installation
08:40 HdkR: phasta: Most people here would recommend radv over amdvlk anyway
08:41 HdkR: Which is what the vulkan-radeon package is
08:41 phasta: HdkR, but why? And why are they even interchangeable?
08:42 HdkR: phasta: Because there are two Vulkan drivers for Radeon hardware. AMD's proprietary driver (amdvlk) and the mesa based one (radv)
08:42 phasta: He. Open 1:0 Proprietary
08:43 HdkR: The proprietary one is also technically open-source :)
08:43 psykose: they're both 'usermode' (in userspace)
08:43 HdkR: That too
08:43 glehmann: but throw-over-the-wall opensource
08:44 glehmann: and there is also the proprietary amdvlk-pro (which shares everything but the compiler with amdvlk non-pro)
08:54 phasta: Is there still an amdgpu-pro? Or maybe I confuse it with amdvlk-pro
08:57 MrCooper: what do you mean by "amdgpu-pro"?
09:35 mlankhorst: DemiMarie: DMA engine + fencing, it's asynchronous so if you want to wait for completion you have to wait on the fence.
09:37 DemiMarie: glehmann: does the amdvlk driver have any advantages at all?
09:37 DemiMarie: mlankhorst: Makes sense!
09:40 glehmann: DemiMarie: better ray tracing maybe, and for native Vulkan games it's more likely to work on release because game devs test on windows (which has basically amdvlk-pro)
09:41 DemiMarie: glehmann: what is different about the amdvlk-pro compiler?
09:42 glehmann: afaiu it's shared with windows gl/d3d9-12 instead of the LLVM based stack
09:44 DemiMarie: Where does ACO fit in?
09:44 glehmann: ACO is what radv uses now, it's part of mesa
09:45 glehmann: -pro has faster compile time than LLVM (not hard), higher ones than ACO. Tends to produce better asm than LLVM, sometimes also better than aco
09:46 glehmann: but ACO also does somethings a lot better than either of the other two, mainly control flow and divergence things
09:46 glehmann: I'm also biased as I work on ACO :P
09:47 DemiMarie: Is LLVM only used for amdvlk (non-pro), ROCm, and OpenGL?
09:49 glehmann: I think so, radv has an debug option to use LLVM but that's mostly unmaintained and just for testing.
09:49 pixelcluster: alyssa: yeah pretty much exactly what you said, "scratch" is really just space in per-function stack
09:50 pixelcluster: that's what the ACO implementation of "real" function calls does too, it just adds the current shader->scratch_size to each function's stack
15:19 alyssa: thinking these must be trace flakes? https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/33242#note_2754521
15:20 alyssa: I don't see how that MR can possibly affect any driver other than intel & asahi
15:21 zmike: alyssa: at least some of those are https://gitlab.freedesktop.org/mesa/mesa/-/issues/12465
15:21 alyssa: zmike: ok, makes sense
15:21 zmike: v3d didn't render anything at all
15:21 alyssa: the v3d is the one that killed the merge
15:22 alyssa: but like
15:22 alyssa: i don't think that MR could have possibly affected v3d
15:22 zmike: it didn't
15:22 zmike: the runner just fucked up and didn't render anything
15:22 zmike: look at the output
15:22 alyssa: yeehaw
15:22 alyssa:again wants to kill premerge trace jobs but is too exhausted to care
15:22 alyssa: back into the marge queue it goes
15:23 zmike: I think this is probably a different issue than the typical fuzzy rendering
15:27 daniels: 'error: drawable failed to resize: expected 640x480, got 32x32'
15:45 tzimmermann: jfalempe, about the ast series: you mention the switch in patch 13, but don't complain about the one in patch 10. shall i replace both of them?
16:01 zmike: kusma: on that mipmap issue, if you're satisfied with the answer can you close the ticket
16:24 jfalempe: tzimmermann: yes you can replace both of them. The switch makes it more complex to read (at least to my eyes).
16:26 tzimmermann: jfalempe, ok
17:44 jenatali: Do folks here have anything to do with apitrace? I suspect there's some overlap
17:45 zmike: somewhat
17:46 jenatali: I was hoping to use it on my arm64 laptop but it looks like the injector doesn't handle Windows arm64 nicely
17:46 jenatali: I guess I can probably just file an issue, nevermind :)
18:02 zmike: dcbaker: here's one for you https://github.com/mesonbuild/meson/issues/14197
18:02 zmike: mesa cross-compile is broken
18:02 dcbaker: zmike: you too have hit a problem that I have been trying to solve for the better part of two years :)
18:03 zmike: ah good
18:03 zmike: glad we're finally on the same page
18:05 dcbaker: Meson's subprojects are always built for the host machine, which is because the people who drove that basically wanted to be able to build a GTK/Gnome SDK. I have been slowly landing the refactors so that Meson can get to build subprojects for both the host and the build machine at the same time, which is what rust needs
18:05 dcbaker: Hopefully I'll eventually get everything in for that, we're getting there!
18:08 zmike: 😬
18:08 zmike: dcbaker: is there any kind of quick hack to just make it build with a set compiler?
18:08 zmike: something I could do locally...
18:10 dcbaker: zmike: It's unfortunately a design issue with Meson... Let me see if I have a branch somewhere that works, you might be able to take that + some hacks
18:10 zmike: no rush, I gotta clock it for today
18:11 dcbaker: Okay. It really is on my list of things to do, it's just a really deep change to the core of Meson, and there's a bunch of stuff that has to happen.
18:13 zmike: sure
18:16 alyssa: dcbaker: is this related to the clc cross build mess?
18:16 dcbaker: yes it is
18:17 dcbaker: it's all one big happy family of issues :D
18:17 dcbaker: As idr would say: cross compiling is hard, news at 11
18:38 alyssa: real
18:38 alyssa: https://www.phoronix.com/news/LLVM-20-SPIR-V-Official-Target is good news for us C:
18:38 alyssa: tangentially related to that mess
18:40 HdkR: They might even break GPU targets less if spirv is an official target :D
18:40 alyssa: that's my hope ye
18:51 dj-death: alyssa: how many dependencies do we get to drop with that? ;)
18:54 alyssa: dj-death: spirv-llvm-translator
19:24 jenatali: dj-death: The big thing is that Clang can enable optimizations. The SPIRV-LLVM-Translator can't consume optimized LLVM IR
20:41 Lyude: OFTC#dri-devel | <sima> Lyude, I guess we should move vkms to subsys_virtual_register? ← sorry I didn't see this until now! and yeah - I've been looking at how to actually do this
20:42 Lyude: oh wait they're not online right now lol
23:56 jenatali: zmike: Trying to use zink to rule out my bug / mesa bug / app bug, hit a crash, with an end-of-frame flushing trying to access a null context ptr
23:59 jenatali: Er, ctx->needs_present->obj is a garbage pointer