04:12zackr: airlied: on top of the va space for each vm or on top of the physical memory?
04:16airlied: zackr: top of the va space for each vm
04:19zackr: airlied: ah, that's neat. what manages the placement in that region? (i.e. what figures our the range for gem buffers in that region)
04:27airlied: zackr: for nouveau there is a driver internal mm range manager
04:28airlied: kernel_managed_addr/size init it
04:42zackr: ah, perfect, it's always nice when someone else solved the very problem you're working on. it's quite nice how majority of drm drivers are converging on a very similar userspace ioctl interface nowadays
05:00zzyiwei: Hi, any volunteer to review https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/35924 for common Android ANB and AHB support? any comments and opinions would be very welcome as well
05:49anholt: zmike: is there anything in particular you think I'd need to do to capture fossils from zink? (trying to beef up my fossils collection. and make a tool for others to do so as well)
05:57anholt: oh. oh no. that fossilize build is unreasonably old.
07:36zzyiwei: Let me try a different approach...I made up a few options. Feel free to click on the emoji number for your choice: https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/35924#note_3026068
11:32zmike: anholt: uhhhhh I'm not sure I've ever tried it
11:33zmike: let me think on that cuz if you just run it by default you'll end up fossilizing all the unoptimized pipelines too, and probably you don't want that
12:03zmike: anholt: try out https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/36375 and merge if it works for you
15:47mareko: has anybody used DEQP_TARGET=surfaceless? is it better than x11_egl?
15:48zmike: that's what ci uses
17:42alyssa: glehmann: delighted we got there in the end ^^
17:49glehmann: yeah, only took 1.5 years
18:03jenatali: Thanks for the prod, sorry for the delay :)
18:12alyssa: =D
19:54anholt: zmike: I think I'm pretty OK with that, actually. As long as it deterministically does both the optimized and unoptimized.
19:54zmike: anholt: up to you
19:54zmike: deterministically...like in what sense
19:57alyssa: mareko: i use surfaceless ~exclusively, helps to match mesa ci :)
19:59anholt: zmike: nothing like "oh, we deleted the program before optimized async compile finished, guess I'll just let it die without passing it down to vulkan" or whatever. We're setting nobgc already, but i don't know if there might be anything else.
19:59zmike: ah
20:00zmike: I think it should fence on the compile thread in that case
20:00zmike: there were bugs related to it
20:00zmike: if you meant like you needed the compile orders to be identical every time then that's trickier with threads
20:03alyssa: I'm very curious how zink doing the async DXVK thing compares to how e.g. radeonsi approaches the same problem
20:03alyssa: I assume zink+radv ends up compiling more binaries in exchange slightly better code
20:04zmike: it's probably worse than radeonsi because I always use dynamic vertex input
20:04zmike: and also smh you mean dxvk doing the zink thing
20:04zmike: I was there first
20:07mareko: alyssa: I get some failures with surfaceless that I don't get with x11_egl
20:07alyssa: mareko: which?
20:09mareko: alyssa: https://gitlab.freedesktop.org/freedesktop/snippets/-/snippets/7851
20:10zmike: I think the only functional difference is that there's no depth buffer most of the time?
20:10mareko: not sure if I tested fbo or pbuffer window type
20:11alyssa: odd.
20:11mareko: pbuffer seemed more broken
20:21mareko: hm, maybe I made some mistakes