00:23 orowith2os: is ajax here on IRC?
00:30 dwfreed: Not seen them in here recently by that nick, but it sounds familiar
00:30 dwfreed: last logged in 3 years ago
00:31 orowith2os: they picked up https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/2684 a few years ago and I wanted to bother them with some questions about it 🙃
00:32 orowith2os: still active, just not sure about on IRC.
01:20 kode54: so, how about that Synaptics mess
01:36 orowith2os: so apparently Intel is setting DRM_SCHED_PRIORITY_KERNEL for realtime Vulkan apps and I'm not sure how much I like that 🙃
01:36 orowith2os: found it when I was throwing together https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/45040
01:37 orowith2os: I would expect them to add uapi for this, not use KERNEL, especially because I'd expect KERNEL to be reserved for, well, internal kernel details...
07:55 MoeIcenowy: strange, gitlab.fd.o/mesa/mesa has a white background assigned to the `macOS` label
07:55 MoeIcenowy: looks weird
07:55 MoeIcenowy: (I use white background for my web pages
07:58 MoeIcenowy: tzimmermann: could you help me to check the plane state pointer swap usage of https://lore.kernel.org/dri-devel/20261003090006.4e29fdce9913-1-archwse@gmail.com/ ?
07:58 MoeIcenowy: The patch itself seems to be okay, but I am not sure whether the original driver's approach is okay now...
08:03 tzimmermann: MoeIcenowy, can't you just delete that function entirely?
08:04 tzimmermann: AFAIU async_commit are for legacy (i.e., non-atomic) changes to the cursor. https://elixir.bootlin.com/linux/v7.2.9/source/drivers/gpu/drm/drm_atomic_helper.c#L1126
08:04 tzimmermann: i don't think we want to encourage anyone to use those
08:15 pq: What are the "deep color specifications" mentioned in the X.org BoD meeting minutes?
08:16 MoeIcenowy: tzimmermann: interesting
08:16 MoeIcenowy: isn't async change exposed for atomic too?
08:19 tzimmermann: MoeIcenowy, the code I linked to is the only I could find that sets state->async_update. without that flag, async_commit will not run.
08:20 tzimmermann: there are a few drivers that implement async_commit, but not that many https://elixir.bootlin.com/linux/v7.2.9/A/ident/atomic_async_update
08:20 tzimmermann: at least i can say that i never bother implementing it for ast, and i never got any bug reports about it.
08:21 MoeIcenowy: I didn't implement it for verisilicon either ;-)
08:21 tzimmermann: you may want to contact one of the rsp. driver maintainers and ask about details
08:21 tzimmermann: maxime, vc4 maybe ^
08:25 MoeIcenowy: tzimmermann: it looks like the atomic_async_check is also called from drm_atomic_uapi.c
08:25 MoeIcenowy: when doing async flip
08:27 MoeIcenowy: oh it looks like swapping fb pointer is okay according to the check of drm_atomic_helper_async_commit()
08:29 MoeIcenowy: strange, the call to atomic_async_update can be traced only back to state->async_update
08:30 tzimmermann: see https://elixir.bootlin.com/linux/v7.2.9/source/include/drm/drm_modeset_helper_vtables.h#L1392
08:32 tzimmermann: AFAIU, there are two features that async_check is used for: async_flip and async_update.
08:32 MoeIcenowy: interesting
08:32 tzimmermann: confusing
08:32 MoeIcenowy: so async_check isn't always paired with async_update
08:32 MoeIcenowy: yes, confusing
08:32 tzimmermann: apparently, but my expertise on this is limitted
08:33 tzimmermann: the async_update part is the legacy one
08:45 austriancoder: does ci_run_n_monitor work for anyone? It start, but is chilling in the middle now for about 40 minutes
08:49 MoeIcenowy: emmm... is it required to clear the BO when a GEM is created?
08:49 MoeIcenowy: it looks like only drm/loongson does it now?
08:53 MoeIcenowy: well drm/imagination does it too, but it seems that this is for rendering?
09:06 airlied: rodrigovivi: fell down a travel hole, pushed it out now
15:19 karolherbst: the anv-jsl-angle job seems to hit some nfs bugs: https://gitlab.freedesktop.org/mesa/mesa/-/jobs/112230614 might be worth investigating what's going on there
15:20 karolherbst: or maybe that's just networking being slow?
15:20 daniels: karolherbst: yeah, check the lines above (5283 onwards), the NIC for some reason completely dropped off the bus and then reappeared, NFS is very confused
15:21 daniels: valentine: ^ nfs-stall WARNs might be a good one to add to the list to check and abort on
15:21 karolherbst: that seems to have happened also earlier in the log I think
15:24 valentine: yeah, we can add that to the list so the job restarts quicker instead of waiting for the timeout to be a bit smarter about that
15:25 karolherbst: nooot sure it's going to solve it, because that seems like a thing that randomly happens in the job.. I've seen 3 instances of that alone in that log I've posted. Happened just now again
15:25 daniels: there could also maybe be some value in enabling the restart-on-hung knob?
15:25 karolherbst: feels like something is odd on a hw level?
15:26 daniels: yeah, that machine has been kicked out of the rotation now
15:27 valentine: ouch, looks like I had a few jobs stuck on those devices due to that crnm bug again
15:28 valentine: crnm either doesn't work at all or triggers all jobs in the pipeline 🙈
15:29 karolherbst: rerunning the job to see if that's now better with the machine removed
15:40 robclark: austriancoder: for me it seems to start the jobs but then hang not showing any progress
15:41 daniels: yeah, it’s been unusable whilst fd.o has been returning 500 to most of its requests
15:43 karolherbst: that issue should be solved now.. apparently we had a node with faulty RAM
15:43 robclark: oh, yeah, that seems like it could trip it up
15:43 alyssa: daniels: guessing that's related to a660 disappearing temporarily?
15:46 valentine: that's probably also because jobs that weren't supposed to run were taking up those runners, yes
15:47 alyssa: that'll do it :(
15:58 zmike: mareko: https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/45029 for the review pile
15:58 zmike: FIXED and R64 are a cancer
16:01 mareko: I have just realized why the txl optimization improves perf so much
16:02 zmike: 🤔
16:03 mareko: any tex affecting coordinates of a dependent tex needs to run for helper invocations, so that's up to 4x more memory traffic for the first tex
16:03 mareko: by switching to txl, the helper invocations no longer execute
16:04 karolherbst: oof..
16:04 mareko: not executing helpers saves a crazy amount of memory bandwidth for the 3D ray-marching tests
16:05 karolherbst: yeah that certainly is going to help a lot..
16:06 zmike: makes sense
16:06 zmike: good find
16:06 zmike: on track to delete radeonsi next week for sure
16:09 mareko: so any shader that has any loads feeding a dependent tex that calculates implicit derivatives should get a shader variant where tex is replaced by txl(lod=0) if the sampler state doesn't use mip filters
16:11 karolherbst: on nv we have this kind of optimization on all tex instruction
16:11 karolherbst: but we have to flip a bit for it in the instruction
16:14 mareko: the opt should be applied to all shaders that have (memory load)->tex indirections, not just GL_CLAMP
16:15 zmike: are we about to get P E R F ?
16:18 mareko: it already makes one workload 2-3x faster
16:18 zmike: yeah
16:19 mareko: I guess nobody's thinking about VK_EXT_gl_clamp now
16:20 glehmann: karolherbst: you mean the skip helper bit? The issue here isn't being able to do that, it's knowing when helpers aren't needed
16:21 karolherbst: glehmann: nah, we have a flag on tex instruction that makes them not do anything in helper invocations
16:22 glehmann: yes
16:22 glehmann: that's eaxtly the bit that I was talking about
16:22 karolherbst: though we have to do the analysis in the compiler
16:23 glehmann: we already do that, but when the user is a tex instead of txl there's nothing the compiler can do
16:23 karolherbst: mhh right, I guess that's the bit we'd be missing as well...
16:23 glehmann: alyssa: reminds me that you probably want to revisit https://gitlab.freedesktop.org/mesa/mesa/-/blob/main/src/intel/compiler/jay/jay_nir.c#L1188
16:23 alyssa: glehmann: It's on the list
16:24 alyssa: I'm just in "pre-branchpoint panic" mode lol
16:25 mareko: who's got XDC flu
16:25 glehmann: alyssa: the trick is to add one bug for every improvement you want to land during rcs, then you can claim that everything needs to be backported as a regression fix
16:25 zmike: this guy backports.
16:26 alyssa: glehmann: In the interest of a smooth release, let's disable CI on Tuesday
16:26 alyssa: then we can ram everything in, and backport fixes
16:26 alyssa: Any takers? /s
16:27 glehmann: I think you are one step ahead because there are no jay jobs in CI
16:27 alyssa: Drat you've discovered my diabolical plot
16:30 mareko: we could also transform FS to: if (all_samplers_no_mipmap(sampler_list)) { FS_without_helpers(); } else { FS(); }
16:30 mntirc: ah woops, my messages here went to the void because i wasn't identified
16:31 mntirc: what i wanted to write: i found a bug in lp_build_fill_mattrs that caused SIGILL on this very special cortex-x3-sans-sve (qcs8550), #if DETECT_ARCH_ARM is not firing on this platform in lp_build_fill_mattrs, and mattrs end up empty. problem fixed by changing to #if DETECT_ARCH_ARM || DETECT_ARCH_AARCH64
16:31 mntirc: patch https://gitlab.freedesktop.org/mesa/mesa/-/work_items/13314#note_3703896
16:59 alyssa: mareko: Is the extra branch & push constant & state tracking worth it?
17:00 alyssa: For Intel, I think we can control whether helpers are spawned from the command buffer side
17:01 alyssa: So just disabling helpers there is cheaper here than monkeying about shaders, I think
17:01 alyssa: Mali works similarly
17:04 mareko: alyssa: there may be better ways, like conditionally enabling helpers, but the 2-3x perf improvement would be there even with the control flow because the limiting factor is the memory bandwidth and taking the non-helper branch reduces it 2-3x
17:05 mareko: maybe we should only conditionally enable helpers by reading sampler states in shaders, which we can do on AMD
17:07 alyssa: mareko: Yeah.. the way helpers work on Intel is kind of silly anyway
17:08 alyssa: Mostly just "this wouldn't be a common code thing"
17:08 alyssa: Reading sampler in shader is interesting, since that could make this workable for bindless
17:09 alyssa: (the driver-side trick wouldn't work for update-after-bind. we could do it for GL, I guess.)
17:09 mareko: since enabling helpers is done with ALU on AMD, it can be conditional
17:09 alyssa: Sure
17:13 mareko: BTW this perf improvement has been discovered by LLM
17:14 alyssa: I got that
17:14 glehmann: also the reason why it helps?
17:14 alyssa: glehmann: making skip_helpers much more aggressive
17:15 glehmann: my question was if the LLM "understood" why it helped, I'm aware of the skip helper thing
17:15 alyssa: ah
17:18 mareko: actually no, this optimization was both suggested and then explained why it works by me :D but Mike's LLM use led me to it
17:18 zmike: cyborg optimization
17:20 mareko: intelligence augmentation
17:20 zmike: heh
17:38 soreau: mareko: that's right on the nose - s/AI/IA/
17:43 alyssa: soreau: la francisation continue
18:38 alyssa: 3
22:30 karolherbst: turns on VVL.. bugs goes away *sigh*