00:27 alyssa: mediump was a mistake
00:28 zmike: A 🙏 M 🙏 E 🙏 N
01:02 alyssa: uh oh
01:06 anholt_: https://gitlab.freedesktop.org/anholt/mesa/-/jobs/37374180
01:06 anholt_: (gotta love the pass)
01:06 anholt_: but, hey. work's done for the day, going to have to finish deleting 1000 lines another day.
01:20 alyssa: :-D
04:41 mareko: daniels: done
04:45 alyssa: https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/21672
04:45 alyssa: this might be the most horrifying NIR lowering I've ever written
04:45 alyssa: well. so far ;)
05:00 mareko: I've written a design document for a new input/output linker to replace nir_link_opt_varyings and nir_compact_varyings, but I guess I'll keep it to myself for now
05:01 alyssa: :eyes:
05:32 mareko: 13 years ago: let's do everything in a proper compiler IR - the GLSL IR! Now: Let's stop doing things in that nasty GLSL IR!
05:38 alyssa: 7 years ago: Wow, we built an IR that's massively more competent than what we had before and can beat LLVM! Now: Let's use the state-of-the-art IR we built!
06:32 daniels: mareko: thanks!
07:07 ccr: so, it turned out that the "intermediate representation" was .. intermediate. *badabum tsssh*
07:24 mlankhorst: airlied: ping?
08:01 hch12907: <alyssa> "7 years ago: Wow, we built an IR..." <- can't wait for NIR 2: electric boogaloo
08:56 hakzsam: CTS update landed \o/
09:04 daniels: hakzsam: thanks for doing that!
09:04 hakzsam: np
10:25 airlied: mlankhorst: ?
10:39 mlankhorst: airlied: has there been any discussion about cgroups in drm?
10:39 MrCooper: yes, there has
10:42 javierm: mlankhorst: there are a few patch-sets in dri-devel that attempt to cover only the memory accounting part, there was also a discussion about it in plumbers last year
10:42 javierm: mlankhorst: https://airlied.blogspot.com/2022/09/lpc-2022-gpu-bof-user-console-and.html has some notes from airlied
10:44 javierm: mlankhorst: and there is also a patch-set proposed for the scheduling part
10:47 javierm: mlankhorst: I believe https://lore.kernel.org/lkml/20220420235228.2767816-1-tjmercier@google.com/T/ and https://lore.kernel.org/lkml/Y9wWTspETnYYodDc@slm.duckdns.org/T/ are the latest iterations
11:00 mlankhorst: ah
11:10 airlied: mlankhorst: yup all of the above, thanks javierm
11:18 mlankhorst: seems like 2 different sets, tvrtko's handles gpu scheduling time time, Mercier's for GPU resources?
12:24 javierm: mlankhorst: yes, that's correct
15:02 Hazematman: Could someone with the appropriate permissions update the labels on my MR (https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/21654#note_1803757). Based on the feedback I added support for get_screen_fd to all the gallium drivers that are missing it, but the MR is only labeled for gallium right now
15:21 Hazematman: Looks like zmike added them, thank you very much!
15:53 jadahl: when doing eglGetProcAddress() on libEGL from libglvnd, do the function pointer I get point directly into the vendor EGL implementation? if so, how do I affect what vendor's version I get?
15:54 emersion: i don't think it does
15:55 jadahl: looking at a backtrace it looks like it
15:55 emersion: libglvnd does the dispatching to the backend EGL impl I think
15:55 jenatali: You could just be seeing a tail call optimization?
15:55 emersion: libglvnd may be doing some magic here, i wouldn't trust a stack trace
15:55 jadahl: if I load eglInitialize() it'll go directly into libEGL_mesa, if I break on eglInitialize on a path that doesn't use eglGetProcAddress it'll stop in libEGL.so
15:56 emersion: but it'
15:56 emersion: s supposed to be usable with multiple EGL backends
15:56 emersion: so if i have two EGLSurfaces, one from backend A, another from backend B
15:56 emersion: when i call eglSwapBuffers, depending on the EGLSurface, glvnd needs to dispatch to the correct backend
15:57 emersion: afaiu
15:57 jadahl: hrm, I'm let me write a tiny test case and inspect what address space the pointer leads to
16:20 jadahl: so, yea it does seem to go via the dispatcher
19:18 DavidHeidelberg[m]: eric_engestrom: what about the meson-test section. tbh I would like to have only one uncollapsed section per job; what do you think?
19:29 DavidHeidelberg[m]: Attention please: review of THIS commit would be appreciated: https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/21668/diffs?commit_id=c8bd72792ced4bf2948f25a4b64cbb40f93b97aa
19:30 DavidHeidelberg[m]: What changes: we track the fails and flakes. Flakes happens. More job we add, more flakes will appear. Having to re-run Marge-bot is costly in terms of developers time, so we have report (here: https://gitlab.freedesktop.org/mesa/mesa/-/issues/?sort=created_date&state=opened&label_name%5B%5D=CI%20daily ) which shows fails and flakes.
19:31 zmike: r fucking b
19:32 DavidHeidelberg[m]: This change MAY prolong discovering of fails. When the job fails, now it'll try twice to run it before it reports failure. This is unlucky. But still better than having to watch Marge-bot dying cause some rare flake.
19:33 DavidHeidelberg[m]: One thing I'm still considering is specifying retry: 1, because 2 seems to be too excessive. On other hand I cannot define retry: 2 for runner_system_failure which would make sense to keep that way.
19:43 DavidHeidelberg[m]: zmike: would you be still R-b with retry: 1? I think 2 would take too long on failing job
19:43 zmike: yeah 1 retry is enough to cover all my babysitting
19:43 DavidHeidelberg[m]: zmike: cool, thx!
22:05 mi6x3m: hey, is it possible to use Mesa's Vulkan without the standard overlays?
22:05 mi6x3m: I get a segfault for CreateCommandPool in vkcube if I don't load any layers
22:06 mi6x3m: supposedly because vk_device_dispatch_table_load is never called which seems to be the task of the overlay layer
22:20 bnieuwenhuizen: you shouldn't need layers for (most?) Mesa Vulkan drivers
22:27 mi6x3m: well that's weird because a getprocaddress for CreateControlPool returns NULL
22:27 mi6x3m: and the only place vk_device_dispatch_table_load is called is in the overlay-layer
22:28 Sachiel: no, it's not. It's called from the generated entry points code
22:29 mi6x3m: ehm
22:30 mi6x3m: Sachiel, do you happen to know which function?
22:34 Sachiel: no, I misread
22:34 Sachiel: but you definitely don't need the layers
22:36 mi6x3m: where i still dont get where the table is supposed to be initialized
22:42 Sachiel: by vk_device_dispatch_table_get_if_supported
22:43 Sachiel: in src/vulkan/runtime/vk_device.c or src/vulkan/runtime/vk_instance.c
22:44 Sachiel: what even is CreateControlPool? grep for that shows nothing
22:45 mi6x3m: Sachiel: CreateCommandPool sorry
22:45 mi6x3m: my bad
22:45 Sachiel: ah, my bad, you said that one first
22:45 Sachiel: yeah, that one should always be there
22:45 mi6x3m: :) by vk_device_dispatch_table_get_if_supported seems to return an index, 72, but table[72] is then NULL :/
22:48 Sachiel: I'm not awake enough to follow this generated code
22:53 Sachiel: what driver?
22:55 Sachiel: mi6x3m: ok, this time I got the right function: vk_device_dispatch_table_from_entrypoints.
22:56 mi6x3m: Sachiel, intel_hasvk
22:56 mi6x3m: thanks a lot, let me look into it!
22:57 mi6x3m: thanks a lot!!