00:06jenatali: gfxstrand: Not sure I have too much opinion on the unstructured nir patch in general, but I'll try to find some time to review
00:09jenatali: DXIL is technically unstructured though I don't know of anything that emits anything complicated
07:46Ermine: Big kudos to people who put up a list of talks and slides in drm docs!
08:49pq: Ermine, awesome to hear they helped :-) (not taking credit here, I don't remember who collected them)
08:51daniels: I think it was sima
08:52javierm: pq: you should take some credit because it was your idea :) I posted the patch but you suggested it
08:52sima: daniels, I think I only provided some encouragement ...
08:53javierm: Ermine: glad to know that it was useful for you!
11:16karolherbst: jenatali: fyi, you might want to take another look at https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/26800
11:16karolherbst: it became quite the nice cleanup now
12:23Hazematman: Hello all, I've had this MR sitting on the queue for a bit now and recently got all the CI issues with it resolved. I would appreciate if anyone could give it a review. I've highlighted two sections I'm not 100% confident on and would appreciate feedback on https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/27805
13:16tonyk: emersion: could you review this series? :) https://lore.kernel.org/dri-devel/20240308145553.194165-1-andrealmeid@igalia.com/
13:27JoshuaAshton: Slowly going insane over the Wayland explicit sync requirement that release point can be signalled before acquire point if the compositor doesn't want your buffer aaAAaaAAaaaAAaaAAaaAAA
13:36MrCooper: the compositor having to wait for the acquire point to signal first isn't great either, so let's not rush for that but wait a bit more for a reasonable client-side solution
13:39MrCooper: offhand not seeing why threads would be required with eventfds
13:39JoshuaAshton: We need two things
13:39JoshuaAshton: 1) The GPU work for the acquire point to actually be done
13:39JoshuaAshton: 2) The release point to be signalled
13:40MrCooper: you can get an eventfd which becomes readable when a fence is available for the acquire point, and can poll for that along with the other fds
13:40JoshuaAshton: So essentially we need to merge two drmSyncObj points into one and then use that for our wait list
13:41JoshuaAshton: Yeah, but we need to essentially make that wait an `if ((a1 && r1) || (a2 && r2) || ...)`
13:41pq: what's the problem with that?
13:41JoshuaAshton: drmSyncobjWait is any or all
13:42MrCooper: it's just polling for a bunch of fds until the minimum requirements are met for acquiring a VkImage, not really seeing the big issue
13:42pq: use eventfd instead?
13:43JoshuaAshton: I guess we could wait on all of them, accept any wakeup and track stuff, then remove from the wait. That still kinda sucks but I guess it works.
13:44MrCooper: sounds like a run-of-the-mill event loop to me
13:44JoshuaAshton: Sure
13:44JoshuaAshton: Oh
13:44JoshuaAshton: but we also need to handle that for the GPU side semaphore
13:44JoshuaAshton: That was the other part
13:45JoshuaAshton: vkAcquireNextImage can signal a VkSemaphore (the temporary part in Mesa) with that
13:45JoshuaAshton: which also needs to be r && a
13:46dj-death: anybody knows the right meson options to have mesa generate a libGL.so.1 ?
13:46dj-death: somehow it only creates a libGLX_mesa.so
13:46pq: dj-death, a wild guess: disable glvnd support
13:47JoshuaAshton: So yes, we still need to actually merge them into a drmSyncObj if we want to keep non-linear timelines
13:47MrCooper: dj-death: -Dglvnd=false
13:48dj-death: thanks a lot
13:48dj-death: I thought I had it built
13:48pq: dj-death, usually it comes from the glvnd project rathen than Mesa.
13:49MrCooper: JoshuaAshton: can't vkAcquireNextImage just wait for the acquire point to signal, then use the release point fence for semaphore?
13:50JoshuaAshton: MrCooper: That's really interesting to think about actually
13:50MrCooper: I guess waiting for the acquire point to signal isn't ideal, should only need to wait for a fence in principle
13:51JoshuaAshton: I think you would end up just getting the same image over and over again
13:51JoshuaAshton: If we did that naiively
13:51JoshuaAshton: wait
13:51JoshuaAshton: no
13:51MrCooper: no, also need to wait for a fence for the release point
13:51JoshuaAshton: that'd be fine
13:51JoshuaAshton: You might not want the same image over and over again though that could be held by the compositor
13:52JoshuaAshton: but we could keep pushing forward I guess
13:52JoshuaAshton: but you could end up stalling on GPU with an image held by the compositor
13:52JoshuaAshton: rather than skipping over it if it did that
13:52MrCooper: no, because there's no fence for the release point in that case
13:53zamundaaa[m]: You can make that work more nicely if you first check if any images exist where acquire and release points have already been signaled
13:54zamundaaa[m]: If so, use that one. If not, use the one that's been committed to the compositor the earliest to maximize the chance of it being signaled soon
13:55JoshuaAshton: MrCooper: You mean wait for the release point to be signalled rather than materialise in Acquire
13:55JoshuaAshton: ?
13:55JoshuaAshton: Seems to defeat the benefit of explicit sync
13:55MrCooper: no, I mean what I wrote :)
13:55MrCooper: if the compositor holds a buffer, there's no fence for its release point
13:55JoshuaAshton: Then I don't get what you mean :frog:
13:56JoshuaAshton: oh
13:56MrCooper: since the client must wait for a fence for the release point before re-using the buffer, it won't re-use a held buffer
13:56JoshuaAshton: got it
13:59JoshuaAshton: I don't think that works though, if there is no fence materialised for it's release point, we have nothing to export on the VkSemaphore
13:59zamundaaa[m]: JoshuaAshton: if there's no fence materialized yet, you just have to wait for that to happen
13:59zamundaaa[m]: There's no way around that
13:59JoshuaAshton: Now we are back to the a && r problem :D
14:00zamundaaa[m]: I don't really follow
14:00MrCooper: JoshuaAshton: vkAcquireNextImage can't acquire an image before a fence has materialized for the release point
14:01zamundaaa[m]: When you pick an image to give to the application, afaiu you'd want to... (full message at <https://matrix.org/_matrix/media/v3/download/matrix.org/aYSarfELexXmrZTshVmbyjyB>)
14:01zamundaaa[m]: I hope that message is somewhat readable on IRC
14:02MrCooper: not really, it's mostly an URL
14:03MrCooper: anyway, I'd say that's it more or less
14:04MrCooper: might also want to prefer images where the acquire point is signaled / has a fence, everything else being equal
14:05zamundaaa[m]: yeah
14:31zmike: is there a nir pass that vectorizes shader_in/shader_out loads and stores with lowered io?
15:16mareko: zmike: I couldn't find one
15:17mareko: it should be easy though because it would just be an instruction merging pass
15:17zmike: me neither
15:17zmike: yeah I'm maybe sorta giving it a shot
15:18zmike: I have some test failures that are too hard to figure out with all the scalarized io
15:34tleydxdy: where can I find some docs for handling gpu reset in vulkan?
15:34tleydxdy: not sure what's the keyword to search for
15:35mareko: device lost
15:39tleydxdy: yeah, google is not giving me much, just some reddit posts and people reporting issues with GPU crash
15:42tleydxdy: is the expectation that UMD would be able to recover from a reset? or each application (maybe game engine) need to handle it themselves
15:52DemiMarie: tleydxdy: You need to handle it yourself. The driver will give `VK_ERROR_DEVICE_LOST`.
15:56pq: tleydxdy, https://dri.freedesktop.org/docs/drm/gpu/drm-uapi.html#device-reset has some general hand-waving.
16:14DemiMarie: pq: does that mean that debugging a hung GPU context is generally only possible for compute workloads?
17:01Hazematman: <Hazematman> "Hello all, I've had this MR..." <- This MR adds the extensions to import/export dma bufs to both lavapipe and llvmpipe FYI
17:42JoshuaAshton: freedesktop dead?
17:43karolherbst: mhh?