09:08 dviola: typo: https://gitlab.freedesktop.org/mesa/mesa/-/blob/main/src/mesa/main/bufferobj.c?anubis_answer=lemon&ref_type=heads#L497
09:08 dviola: "the the UNSYNC"
15:17 soreau: if loading times are an issue, is there a reason why graphics boards can't have persistent storage of some type and size that could cache whatever it would normally spend uploading to the gpu, which is recurring each app restart?
15:18 soreau: such that if you use mainly one or two apps, the caching will make them load faster
17:44 BlueMatt: awww man the xdc livestream is dead :(
17:47 BlueMatt: oh no just lunch lol
20:29 BlueMatt: alyssa: following up on the question from the room today about comparison - has there been any attempt to compare opencl compiled/run with intel's compute-runtime on linux to rusticl+brw/jay? obviously the extra opencl layer on top is gonna add some (lots of?) noise and opencl has fewer sample apps to benchmark from but at least its an honest mesa-vs-intel-closed-stack comparison.
20:51 orowith2os: is accessing `dri2_dpy->vtbl` for the existence of certain function pointers not valid?
20:51 orowith2os: erhm, in dri2_setup_screen
20:53 orowith2os: I seem to be segfaulting when doing so (setting an extension's existence to EGL_TRUE based on the existence of a function pointer in that vtable)
21:02 alyssa: BlueMatt: I haven't looked in a while
21:02 alyssa: Jay's priority is very much Vulkan / Proton
21:02 alyssa: GL & CL should both work but it's not where the optimization effort is going (at least right now)
21:11 soreau: orowith2os: in e.g. dri2_display_destroy() it null-checks the vtbl before trying to use it
21:15 orowith2os: soreau: gdb says it's valid
21:15 orowith2os: vtbl is valid as well, as is the function pointer
21:16 soreau: orowith2os: what does the trace look like then
21:17 orowith2os: let me do a clean build and I'll show what GDB says
21:17 orowith2os: is there a preferred service for text/screenshots (both?)
21:18 orowith2os: or I can just send them to matrix and have the bridge handle it.
21:18 soreau: then irc folks won't be able to see it
21:18 soreau: https://sharey.org/
21:19 orowith2os: ack, one sec. Building right now
21:25 soreau: orowith2os: when I print the vtbl pointer (using weston-simple-egl), it's nil in dri2_setup_screen()
21:26 orowith2os: oh, odd.
21:27 orowith2os: oh, wait, that's the GBM backend.
21:27 orowith2os: it was printing nil for me on that too.
21:27 orowith2os: uhhhh, I don't know what the hell I was doing a couple minutes ago, because it's printing nil now too...
21:28 soreau: orowith2os: it looks like you should be using pscreen->caps somehow?
21:29 orowith2os: mmhh...
21:29 orowith2os: here's the line I was using (that's segfaulting):
21:29 orowith2os: `disp->Extensions.EXT_swap_control_tear = dri2_dpy->vtbl->request_tearing ? EGL_TRUE : EGL_FALSE;`
21:30 orowith2os: and then the individual EGL drivers (platform_wayland, platform_x11) will set that pointer to something non-null and I would ideally check for the existence of that pointer to set the ext as available
21:31 soreau: orowith2os: but it's almost as if you should drop a bool in src/gallium/include/pipe/p_defines.h and set it to true in wherever driver supports it, then check that in dri2_setup_screen()
21:31 orowith2os: graphics driver or EGL driver?
21:32 orowith2os: this wouldn't concern radeonsi or zink, it's based on capabilities of the EGL driver (like the Wayland compositor's exposed protocol extensions)
21:36 soreau: orowith2os: you already have HAVE_*_PLATFORM, so why not just #ifdef in egl_dri2.c to set it to true
21:36 soreau: if it's just based on whether one of those platforms built-in..
21:37 orowith2os: mmh, true I suppose. I already make the actual function for the extension return EGL_FALSE if it's not supported for whatever reason.
21:37 orowith2os: if you want to see what I have right now, it's https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/44749/diffs?commit_id=6b87eea4f299634392d5711443593ab46843f867
21:37 soreau: idk if you need an actual runtime check so that it doesn't affect non-wl/x11 platforms but uh
21:38 orowith2os: the function exposed to clients checks for the actual existence of the function pointer in the vtable, so it shouldn't be a problem even if all platforms got it set to true
21:38 orowith2os: they'd just get an EGL_FALSE that tells them that the platform doesn't support controlling tearing for whatever reason
21:38 soreau: well there ya go
21:38 orowith2os: which is well within the boundaries of how I defined it in the extension
21:40 orowith2os: anyways, pushing changes now, thanks soreau
21:40 orowith2os: :)
21:41 soreau: np
21:41 orowith2os: now I guess I can go through and clean things up
21:41 orowith2os: not sure if I need so many error checks down the pipeline
21:42 orowith2os: maybe I can move that forced environment variable handling out of eglSwapInterval itself too...?
21:45 soreau: I wouldn't get too hasty..
21:46 orowith2os: :P
21:46 orowith2os: just cleanups
21:46 orowith2os: I'll probably leave things as is for now until someone comes along and reviews my PR and/or my EGL extension proposal, and maybe fiddle with xdg-desktop-portal