05:25imirkin: anholt: oh this is very unfortunate. on screen destroy we wait for the hardware to get to a fence. ugh
05:25imirkin: it's a driver-side fence, so we don't know which bo it's in
05:29imirkin: what's a way for the LD_PRELOAD shim to make something available to the "main" library? like a weak symbol or something?
06:11imirkin: really we shouldn't be waiting on the fence, and instead just run all the cleanup and exit, huh
06:12imirkin: oh well, a task for tomorrow
06:43mareko: the TGSI frontend needs to go, it's a no brainer at this point
06:53imirkin: i see it as a no brainer to just leave it alone
06:54mareko: we also leave all of Mesa alone, no new commits ever from now on :)
06:55mareko: *we could
06:57imirkin: we could
06:57imirkin: but i'm not proposing that
06:57imirkin: i'm proposing leaving a feature-complete piece of code alone which works well and has been tested for ages
06:58mareko: yes, it's subjective
09:05doras: Can the new async page flipping support in i915 theoretically allow implementing an async atomic commit UAPI where commits to different planes can be done in parallel with each finishing on its own time? I'm specifically asking because of this commit message: https://lists.freedesktop.org/archives/intel-gfx/2021-January/257498.html
09:10doras: And if such a UAPI was introduced, could it allow cursor plane updates to occur independently of primary plane updates?
14:56MrCooper: doras: don't think it's related really
14:56MrCooper: zackr: hey, long time no see!
16:37kallisti5: dcbaker: if you get some free time, https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/8323 should be a pretty easy review
18:41dcbaker: kallisti5: i don't know if I'll get to it before Monday, but I will look at it by then
18:49kallisti5: dcbaker: no worries. thanks!
19:39imirkin: anholt: mareko: i'm seeing some leaks on exit from e.g. glxgears with nvc0: https://hastebin.com/ohapisuzic.yaml