ChanServ changed the topic of #zink to: official development channel for the mesa3d zink driver || https://docs.mesa3d.org/drivers/zink.html
fahien has joined #zink
fahien has quit [Ping timeout: 480 seconds]
<Soroush> a question about kopper: what exactly is the job of zink_kopper_acquire_readback? from the name I expect that it acquires the next swapchain image and then presets it so it can then be readback.
<Soroush> but then it only breaks out of the loop if zink_kopper_present_readback fails, not when it succeeds.
fahien has joined #zink
<zmike> it acquires the last-presented image
Akari has quit [Quit: segmentation fault (core dumped)]
Akari has joined #zink
ajax has joined #zink
<ajax> kusma: #6685, what configuration are you seeing that with? i'm not seeing it with Xwayland and either radv or anv
<zmike> I see it on Xorg
<zmike> with ANV
<ajax> ngh
<ajax> i guess my anv is behind prime so maybe
LexSfX has quit []
LexSfX has joined #zink
<Soroush> zmike: In zink_surface_swapchain_update, surface->dt is never set to anything but 0 when calloc'd. It feels to me a surface->dt = cdt; was missed in that code path
<zmike> hm
<zmike> I think I meant to set it in init_surface_info
<zmike> but also I don't think this conditional is valid anymore with the current state of kopper
<Soroush> hm, I don't know enough about the state of kopper, so I'll just leave that with you then.
<zmike> 👍
fahien has quit [Ping timeout: 480 seconds]
<ajax> zmike, kusma: if you can repro the deadlock in #6685, can you post the backtrace from all the threads?
<zmike> sec
<ajax> i mean, it's !16730, really. but.
<ajax> except, in vulkan. you get me.
<zmike> yep
<zmike> 100% with you
<zmike> still got your old reverted patches in my local branch to avoid it
<ajax> i kind of doubt it but does !17634 happen to help
<zmike> incredibly it does
<ajax> f yeah
<ajax> it keeps us inside the while (x) xcb_wait loop less, so it probably increases the odds that we bomb out naturally from the wsi_queue_pull at the top
<zmike> hell yeah hitting that uncertainty just right
<ajax> now i just get to find out that it breaks unigine or something
<zmike> surely it must
<ajax> i think, with that fix, we could re-do the "poll and get_geometry" trick to catch the window destroy race without the extra cpu load from #6537
<zmike> uh oh
<ajax> gettin all ambitious over here
<zmike> good thing it's early in the week
<zmike> ci coming back with lots of green
<zmike> great way to kick off the week
<ajax> would be funny if it helped framerate too
<zmike> haha
<zmike> ajax: any chance this might give you an idea for making !16730 viable
<zmike> would like to get that resolved in this upcoming release if possible
<ajax> well
<ajax> the "issue" michel mentions was the cpu overhead
<zmike> right, which was #6537
<zmike> and I'd guess it's a similar sort of scenario
<ajax> so i'm not sure the (gl) dri3 code would have the same issue
<ajax> because i don't think we have a similar wait. anyway, checking.
<zmike> it's been documented that this can (in extreme corner cases) deadlock, so it'd be great if we could figure out how to make it work
<ajax> enh. there's a WaitMscOML entrypoint or something, isn't there?
<zmike> I'm paged out, so I'd have to look
<ajax> just need that to submit its present_notify_msc in parallel with someone closing the window
<ajax> (this is to say i see how it could happen)
<zmike> sure
<ajax> pshooo
<ajax> starting to feel like it's easier for me to fix Present first
<zmike> avg trip into wsi
<ajax> well there's one way out here, i think
<ajax> which is you can be pretty assured of being able to get a notifymsc event from the root window, instead of the app window.
<zmike> * ajax has left the channel (so long suckers!)
<ajax> so what you do, roughly, is you ask for notifymsc on the root for N frames in the future, and then you ask for the thing you really want from the app window
<ajax> and if you get the watchdog msc before the app window one, the window is dead, go ahead and fail
<zmike> seems plausible
<ajax> except ngh you can only get events for one window from a single xge listener i think?
<ajax> ugh yeah dammit
<ajax> well, okay. drain the event loop, then if you're still in need, notifymsc(0, appwin), notifymsc(0, root), wait_for the event for the root, poll_for the app window
<ajax> because sequentiality means if you got the event for the root window then either you got one for the app window or it died.
<ajax> well that's a strategy, at least. now to type it.