00:59marex: Hi, can you think of any reason why dma_alloc_wc() would fail for some 4 MiB allocation, while it would work just fine for 1 MiB allocation ?
00:59marex: the system is freshly booted, so I dont think fragmentation is the problem
02:13airlied: gfxstrand: is that legal as a function temp in nir? decl_var INTERP_MODE_NONE none uvec4[] temp_A
02:24airlied: something in var splitting seems to fall over when it hits it
07:21kchibisov: Does anyone know about the way to ensure that update reached the screen with GLX/X11 stuff? We basically have an issue that when we draw without vsync (even with vsync sometimes) the update doesn't really reach the screen on X11 in some cases, even though we've drawn everything. The same doesn't happen on e.g. Wayland.
07:22kchibisov: it mostly happens with llvmpipe driver, and nvidia driver has the same issue sometimes.
07:26airlied: kchibisov: does the frame get dropped or something?
07:27kchibisov: it's like never shown until I try to draw one more time.
07:27airlied: okay you call swapbuffers and it never appears?
07:27kchibisov: yes.
07:27airlied: when you call another swapbuffers, you get the undisplayed frame or the newest one?
07:28kchibisov: If I call without any drawing?
07:28kchibisov: so just swapBuffers(), swapBuffers()?
07:28airlied: that or with drawing something different
07:28kchibisov: I think I get newest if I get drawing.
07:29airlied: can't really think of anywhere llvmpipe might screw up there, could be a dri3/present issue I suppose
07:29kchibisov: it just happens mostly with llvmpipe, but it seems like dri/present.
07:30kchibisov: Hence I ask who to figure out whether it was presented oro not.
07:30kchibisov: it's like really easy to repro on gnome though, because it's not something _rare_.
07:30airlied: not sure there is anything you can ask
07:30airlied: I suppose does it happen in an uncomposited desktop?
07:31airlied: it could be a compositing manager bug
07:31airlied: where it doesn't see the update
07:31kchibisov: I'm actually not certain about it.
07:32airlied: MrCooper: might have some better debugging ideas or possible failure cases
07:33airlied: like llvmpipe doesn't really do any double buffering on the GLX path
07:33airlied: it just does a PutImage to a MIT-SHM pixmap if its there
07:34kchibisov: I think the issue is also present with EGL.
07:34kchibisov:goes to retest it.
07:40kchibisov: So, swap_buffers() -> glFinish() -> freeze; glFinish() -> swap_buffers() -> freeze; swap_buffers() -> swap_buffers() (no drawing) -> no freeze.
07:40kchibisov: And just swap_buffers is also freeze.
07:40kchibisov: Freeze, as in frame is not getting to display.
07:40kchibisov: the app is running and polling the X connection.
07:41kchibisov: And the bug is the same on EGL and fix is exactly the same (do swap_buffers(); swap_buffers()).
07:45kchibisov: And I can not repro that on i3 with/without compositor, so looks a bit like a gnome/mutter bug.
07:57airlied: yeah or some damage posting bug
08:02kchibisov: it's X11 and we don't do damage there ¯\_(ツ)_/¯
08:51pq: kchibisov, but the compositing manager might, I guess
09:30MrCooper: kchibisov: if it happens in GNOME x11 but not in GNOME Wayland, a mutter issue seems most likely
09:34kchibisov: Any suggestions on how to report it?
09:36kchibisov: I can share how to repro (given that you likely don't have to build anything), but that's about it.
10:30robmur01: marex: yes, smells of MAX_ORDER
10:49MrCooper: kchibisov: filing an issue with repro steps at https://gitlab.gnome.org/GNOME/mutter/-/issues should be a good start
15:33gfxstrand: eric_engestrom: ci_run_n_monitor isn't working again. :weary:
15:35gfxstrand: Or maybe it's just not un-canceling jobs properly?
15:36gfxstrand: I guess --force-manual got things running again?
15:36gfxstrand: I don't think that's actually what I want to do but it unblocked stuff
15:39gfxstrand: I swear, we need CI for ci_run_n_monitory.py. :-P
15:39gfxstrand: Or a CTS or something
15:39gfxstrand: Sometimes it does what I want but a lot of times it just.... doesn
15:39gfxstrand: 't
15:44eric_engestrom: gfxstrand: in a (very long) meeting now, but yeah I noticed yesterday that jobs were not cancelled properly
15:45eric_engestrom: I just checked, there hasn't been any changes to the script recently (last change merged was on 2024-02-29) so it must be a change on the server side
15:45eric_engestrom: gitlab server, I mean
15:46eric_engestrom: I'l ask on #freedesktop if there's been any update recently
15:57gfxstrand: They're cancelled. They're not uncanceling
16:17tomeu: is any driver doing anything in their generated register setter macros for warning about field overflows?
16:18tomeu: I keep forgetting about these and end up scratching my head for way too long when there is a mismatch between the blob's value and mine
16:39alyssa: tomeu: genxml pack functions assert that there's no overflow
16:39alyssa: this found a LOT of bugs in panfrost back in the day
16:39tomeu: heh, yeah
16:39tomeu: thanks, will take a look
16:51eric_engestrom: gfxstrand: ah, so it's retry that's failing for you
16:51eric_engestrom: I had noticed cancel not cancelling
16:52eric_engestrom: talking with bentiss we think it's a new gitlab bug
16:52eric_engestrom: I'll make tests tomorrow
23:49marex: robmur01: I got further when I onforced intel_iommu=on (sigh)