ChanServ changed the topic of #zink to: official development channel for the mesa3d zink driver || https://docs.mesa3d.org/drivers/zink.html
Akari has quit [Quit: segmentation fault (core dumped)]
<zmike> kusma: is your comment on https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/20585 some form of ack
<kusma> It's an r-b!
<zmike> 👍
<zmike> while you're rbing
<kusma> I'll take a look tomorrow, I'm out of the office now
<zmike> np
<zmike> at least in the scenario you provided I see the old swapchain getting pruned pretty early
<anholt> cool! I completely don't follow the lifetime requirements for these, so I don't think I can provide an ack
<zmike> the lifetime reqs are very stupid
<zmike> without that EXT there's no way to know when a present is "done"
<zmike> hence the current architecture
<zmike> I need to wrangle ajax back in here....
<anholt> so if you don't know when a present is done, how is it valid to prune?
<zmike> because if present 2 occurs then present 1 must have finished
<zmike> or at least that's the current reasoning
JoshuaAshton has quit []
JoshuaAshton has joined #zink
JoshuaAshton has quit []
JoshuaAshton has joined #zink
<anholt> zmike: you may enjoy this https://github.com/anholt/apitrace/tree/loopsecs
<anholt> with that I could easily measure a 1.3% win in traces-db that I couldn't using --loop=200.
<zmike> anholt: 🤔
<zmike> you just add --loopsecs ?
<anholt> --loopsecs=N, like the commit message suggests
<zmike> ah right
<zmike> nice
<anholt> unfortunately zink is still -26% on this trace.
Akari has joined #zink
<zmike> :/
<anholt> hmm, lots of CmdClearAttachments instead of clear loadops. but not sure that that's actually meaningfully different on anv.
* anholt needs to sort out how to do perfetto, anyway, instead of just poking around
Akari has quit [Quit: segmentation fault (core dumped)]
<zmike> you could try out ZINK_DEBUG=rp to get that renderpass optimizing going which should clear out some of those