01:11 Lyude: Is anyone familiar with zeus?
01:21 HdkR: Only through Hercules and Hades.
01:34 dwfreed: Jeremy_Rand_Talos_: o/
01:34 dwfreed: :)
01:38 Jeremy_Rand_Talos_: Hi! I'm confused about the LLVMpipe code paths in lp_linear_fastpath.c.
01:38 Jeremy_Rand_Talos_: lp_linear_check_fastpath() checks shader->kind for LP_FS_KIND_BLIT_RGBA and LP_FS_KIND_BLIT_RGB1, but llvmpipe_fs_analyse_nir doesn't include any code paths that set either of those kinds.
01:38 Jeremy_Rand_Talos_: Grepping for both of those kinds didn't yield any hits where they're set. Is the fastpath actually reachable? If so, how?
01:43 Jeremy_Rand_Talos_: Orthogonally, I see "banning tor temporarily" in logs, which resulted in me getting kicked. This was quite a long time ago. How "temporary" is that ban intended to be? Is it still necessary?
01:45 Jeremy_Rand_Talos_: karolherbst: scrolling through logs it looks like you may have been the one who banned Tor users from this channel? Any chance that ban could be removed?
01:47 airlied: it just brings back our estonian friend more often
01:47 airlied: Jeremy_Rand_Talos_: the fastpath shader code never got rewritten for nir
01:48 Jeremy_Rand_Talos_: airlied: Is the spammer still active these days? Many spammers get bored after a month or two, but I don't claim to know this specific spammer's habits...
01:48 karolherbst: maybe if people stop using it for ban evasion
01:48 airlied: Jeremy_Rand_Talos_: 10-15 years and going
01:48 airlied: he's lasted longer spamming channels that most devs writing drivers
01:48 airlied: than
01:48 Jeremy_Rand_Talos_: airlied: impressive. And there I was thinking the Hungarian spammer who likes stalking my channels for the last 3-4 years was unusually persistent
01:49 karolherbst: I kinda wished I could ban all VPNs as well :')
01:49 Jeremy_Rand_Talos_: Well, please do keep in mind that there are plenty of very nice people who don't spam and also use Tor
01:50 Jeremy_Rand_Talos_: Many of whom would like to contribute
01:50 karolherbst: yeah.. but IRC is the wrong protocol for that
01:50 Jeremy_Rand_Talos_: Anyway
01:50 karolherbst: if messages could be deleted, etc.. then maybe
01:50 Jeremy_Rand_Talos_: airlied: ok, so my assessment was accurate that the code is unreachable right now?
01:50 airlied: Jeremy_Rand_Talos_: yes at least that particular fast path
01:51 airlied: it was all very windows dwm specific anyways
01:51 Jeremy_Rand_Talos_: airlied: ok thanks. So then I guess I probably won't be productive trying to port it over to ppc64le
01:53 airlied: no not much use in that
01:54 Jeremy_Rand_Talos_: IIRC I zeroed in on that code because it's one of the few places in LLVMpipe where SSE is used. Are there any other notable usages of SSE that are actually reachable, which would be productive to port over to ppc64le VSX?
01:56 airlied: outside of the rasterizer which I think is already ppc64le ported, the shaders are all handled by LLVM
01:56 Jeremy_Rand_Talos_: airlied: ok, and LLVM presumably already knows about SIMD for all major arches without doing anything special in LLVMpipe?
01:57 airlied: there might be some specific paths in gallivm that could have ppc64 specifics where LLVM might do a bad thing, but tracking down those is really a matter of caring about a very specific workload
01:58 airlied: Jeremy_Rand_Talos_: I assume so, I've never really checked what code LLVM produces for ppc64le, but I assume it uses altivec when it should
02:01 Jeremy_Rand_Talos_: airlied: makes sense, thanks.
12:59 MrCooper: Company: FWIW, the client's GPU work for the next frame being executed before mutter's GPU work for the previous frame would be more likely to happen if mutter sent frame events at the start of a frame update
13:01 MrCooper: it's more likely to happen with clients using the FIFO protocol as well
13:04 MrCooper: ultimately solving this requires proper high-priority GPU contexts with good preemption
13:05 pac85: Or compute compositing
13:07 MrCooper: is that a general solution though, without reserving GPU execution units for compute?
13:13 MrCooper: brb
13:42 Company: MrCooper: I think it's just a case of luck if it happens or not
13:42 Company: because there's $X CPU time preparing the update followed by $Y GPU time
13:42 MrCooper: yep, don't try to avoid it
13:43 Company: what is fascinating to me is that it's 100% reproducible
13:43 Company: but only in this one case on this one machine with this one kind of settings
14:21 pac85: MrCooper: on AMD you can make the compute queue high priority, but in general even if there's some latency, resource sharing between compute and gfx queues works at a workgroup granularity so probably better than the latency you'd get with preemption on gfx which has to happen at certain command boundaries. All in all a compositor realistically would need to support both things because some GPUs have preemption but not async compute and
14:21 pac85: vice versa or which one works better for this is different (on MSM/freedreno/turnip we have preemption working very well upstream so this problem shouldn't be a thing for any compositor that simply requests an high priority context however no async compute (yet, patches coming), on AMD high priority async compute is available upstream). Also preemption has higher overhead since switching context is not free and it has to happen at least
14:21 pac85: once and at most twice per refresh cycle (which can add up with modern displays that go up to 500hz).
14:22 pac85: So I don't think one is strictly better than the other, though async compute might be more widely available and consistent perhaps across devices
14:24 MrCooper: at last year's XDC there was a talk about using compute for VR reprojection, IIRC they could only make it work reliably on that setup by reserving some GPU execution units for the high-priority compute work
14:30 haagch: very interesting, do you know what the title of the talk was?
14:36 haagch: ah got it https://indico.freedesktop.org/event/10/contributions/421/
14:39 Company: pac85: is there anything clients can do to allow more preemption boundaries?
14:40 Company: create more command buffers, vkQueueSubmit() with finer granularity, or whatever else
14:42 MrCooper: it'll depend on the HW / drivers, and it'll hurt other things, so I wouldn't bother
15:05 karolherbst: is .gitlab-ci/bin/ci_run_n_monitor.py broken also for others?
15:09 karolherbst: ohh my regex was broken, nvm
15:46 pac85: Company: the compositor is not what's being preempted so it doesn't matter, what matters is what apps do which you can't really control in general. Also it's very HW dependent, on adreno preemption happens at a bin or draw boundary (depending on whether binning is enabled or not for that pass). The driver can actually optimize for latency by picking smaller bin sizes for example but an application has too little control even if you
15:46 pac85: targeted that GPU specifically.
15:48 Company: pac85: I develop GTK, so I want to make compositors lives easier if there's some easy methods
15:49 pac85: Company: I'd say it depends on whether you have a more specific problem (like an app/HW combination you wanna tackle), I don't think there's any general advice to give there unfortunately
15:51 Company: I'll be an optimist and be happy that there's one less thing to worry about
19:06 karolherbst: zmike: I'm seeing a regression since "zink: always flush specified memory access for glMemoryBarrier calls" in e.g. "test_conformance/events/test_events out_of_order_event_waitlist_single_queue" but not quite sure yet who is to blame for this
19:07 zmike: I'm fixing a lot of sync bugs, so odds are if something breaks it's the test
19:08 karolherbst: test is accessing the same memory across different pipe_contexts, not sure if rusticl needs to use memory barriers more often or not...
19:09 karolherbst: maybe "PIPE_BARRIER_GLOBAL_BUFFER" handling missing in some places in zink?
19:10 zmike: could be
19:10 zmike: is that new?
19:10 karolherbst: no
19:11 zmike: 🤔
19:11 karolherbst: I'll debug and see if I figure something out
19:12 zmike: is that just PIPE_BARRIER_SHADER_BUFFER ?
19:12 zmike: maybe just add it to the case there and see if that's enough
19:13 karolherbst: basically yes
19:13 karolherbst: yeah, will try that
19:13 zmike: if it works then rb on merging it
19:14 karolherbst: yeah.. seems like that fixes it. Will do a full run to be sure, because you never know with those sync related issues
19:16 zmike: does anyone handle it as anything that isn't SHADER_BUFFER?
19:17 zmike: if not then probably worth doing an api cleanup and deleting
19:17 karolherbst: yeah.. I'm kinda considering it. I'd have to check with r600 if it matters or not
21:48 robclark: karolherbst: don't suppose you see nir validation errors w/ math_bruteforce on ToT?
21:51 robclark: https://www.irccloud.com/pastebin/ynPcyAKP/
21:56 karolherbst: robclark: I actually do, but it seems to be new
21:56 karolherbst: smells like some memory corruption going on
21:58 robclark: I did also pull latest cts ... and switch over to f44 on new x2e laptop (vs debian on CRD)... so a few moving pieces..
22:01 karolherbst: do you want to bisect?
22:02 robclark: was kinda debugging something else, just noticed it when attempting to test a MR that made float/round related changes
22:03 robclark: if you don't get to it before me, I will.. but won't be today
22:03 karolherbst: I guess I can run the script
22:52 karolherbst: if I'm unlucky I have to rebuild LLVM for that bisect...