08:40 MrCooper: Lynne: rgb24 isn't trivial to handle in HW, that's why non-ancient HW tends not to support it; I'd assume at least the 32 bpc variant to be supported though
08:41 Lynne: fair enough
10:05 luc: Hi! I'm trying to understand how syncobjs work. Does anyone know why creating a pipe_fence_handle (like panfrost_fence_create) requires 1) ExportSyncFile ctx->syncobj 2) Create a new syncobj 3) ImportSyncFile the exported syncobj into the new one again, rather than directly assign ctx->syncobj to newly-allocated pipe_fence_handle *f->syncobj? Is that because it requires the kernel to replace the fence which adheres to original
10:05 luc: ctx->syncobj?
10:36 MrCooper: luc: FWIW, drm_syncobjs and sync_files are completely different beasts, so " 3) ImportSyncFile the exported syncobj into the new one again" doesn't make sense
10:38 MrCooper: in some cases, one has to transfer the sync_file from a non-0 syncobj timeline point to timeline point 0 of a separate syncobj, because some syncobj ioctls operate only on timeline point 0
10:42 luc: 3) ImportSyncFile refers to drmSyncobjImportSyncFile() here https://gitlab.freedesktop.org/mesa/mesa/-/blob/main/src/gallium/drivers/panfrost/pan_fence.c#L101
10:46 luc: what I don't understand is why not assign the original ctx->syncobj to f->syncobj directly there
11:05 MrCooper: luc: a syncobj is a container which can have multiple timeline points, each of which can hold a fence (which is what a sync_file represents)
11:08 MrCooper: the sequence you described sounds like creating a new syncobj which holds the same fence as the original one, maybe the original one can't be used directly for some reason
11:21 luc: MrCooper: thanks very much!
15:15 MrCooper: hmm, is there really no EGL way to determine if a GPU is integrated or discrete?
15:17 emersion: MrCooper: https://github.com/KhronosGroup/EGL-Registry/issues/206
15:37 MrCooper: thanks
15:52 tomba: I have the bootloader setting up an area of memory for a splash screen, which is then on the screen when Linux boots up. I was thinking that it would be nice if the Linux DRM driver could create the fbdev and tell it to use that piece of memory as the buffer. Is this something that can be achieved without implementing it all in the driver?
15:55 mripard: tomba: so there's two "features" in your question. The first one is exposing a bootloader splash screen to Linux, and x86 has something kind of like that through ACPI, which is supported by plymouth and all through a sysfs file iirc. Adding a similar DT mechanism would be pretty easy.
15:55 mripard: then, you also want to have a seamless transition between both, and that will require both driver and framework changes as of todya
15:57 javierm: mripard: /sys/firmware/acpi/tables/BGRT is the sysfs entry you meant
15:57 mripard: javierm: thanks
15:58 javierm: tomba: and yeah, having a flicker-free boot on ARM with DT like we can have with ACPI using BGRT would be pretty cool
15:59 mripard: javierm: like I said, flicker free boot isn't just about getting the splash screen
15:59 mripard: that's the easy part actually :)
16:07 tomba: mripard: what does the ACPI stuff do there? in my WIP branch, I just mark the memory as reserved in the DT. as a hack, I then modified tidss driver to create the DRM fbdev, and copy the memory from the bootloader's fb to the newly allocated DRM fb. this was ugly, but it "worked".
16:10 tomba: although I guess this is all somewhat platform specific. in the tidss case we have lots of trouble related to the powerdomains in this scenario, where we want to keep the display HW enabled even if we don't have a driver yet in control.
16:14 tomba: as for the second part, I think it should be fine if the first modeset we get is for the fbdev (preferably with bootloader's fb). but again, platform specific, in tidss case we need to be careful with what we do in probe to not mess things up.
16:15 tomba: but as I don't have things properly working, I'm sure I might be missing some details =)
16:21 tomba: one problem I also faced was that if the main driver (tidss) is a module, but we want to use simpledrm as an early driver to allow boot time apps to show something, then there can problem at the time the simpledrm is removed (drm_aperture_remove_framebuffers or such), which, I think, should preferably be done before adding the new DRM fbdev.
16:41 mripard: tomba: it provides the splash screen BMP(?) to the OS
16:42 mripard: tomba: https://lore.kernel.org/all/CAKMK7uHtqHy_oz4W7F+hmp9iqp7W5Ra8CxPvJ=9BwmvfU-O0gg@mail.gmail.com/
16:43 mripard: tomba: basically, for it to work properly, to need to create a mode test that matches what your hardware is currently running when you probe
16:47 tomba: mripard: yes, I can just check the display subsystem registers to find out what the bootloader has set up
16:48 mripard: s/mode test/state/ sorry
16:50 dcbaker: alyssa: I would continue to do so just to be in the habit, since hopefully we'll reach a day that you can just say "use the official releases, uAPI is stable"
16:50 alyssa: dcbaker: yeah... I mean the flip side is that I really appreciate being able to do my own releases
16:51 alyssa: but obviously eventually debian stable or whatever should be able to run with the upstream releases
16:51 alyssa: ..slowly
16:51 dcbaker: Its always a tradeoff between what's easiest for upstream and what's easiest for downstream isn't it?
16:58 dcbaker: So, speaking of releases. We have one open blocker, which is extra symbols exposed on MacOS from osmesa. That was caused by @zmike, who is on vacation the rest of the year. Does anyone care enough to fix it or to keep it as a blocker, or can I remove it and make 24.3.0 this week? https://gitlab.freedesktop.org/mesa/mesa/-/issues/11659
17:02 alyssa: given the state of mesa on macOS, I don't see why that should block release imho
17:05 daniels: I think it's reasonable to ask the people who use + develop + care about Mesa on macOS to fix that one, rather than hoping someone can figure it out by manpages, googling, and throwing patches out for someone to test
17:26 alyssa: 💯
17:28 tzimmermann: tomba, i915 sort of reads out the pre-existing display config. https://elixir.bootlin.com/linux/v6.12/source/drivers/gpu/drm/i915/display/intel_fbdev.c#L310 might be a good starting point
18:11 DemiMarie: alyssa: Is Debian Stable really suitable for a desktop, given the short lifecycles of desktop components?
20:24 alyssa:writing OpenCL bindings for NIR itself, yes that NIR
20:28 cmarcelo: alyssa: what do you mean?
20:43 alyssa: texels[i] = nir_bindless_image_load(handle, c_sa, 0, 0, GLSL_SAMPLER_DIM_2D, true, 0, ACCESS_IN_BOUNDS_AGX, nir_type_uint32);
20:43 alyssa: cmarcelo: ^ real OpenCL code from my branch
20:45 jenatali: alyssa: That sounds like it should be paired with a "they've played us for absolute fools" meme
20:45 cmarcelo: alyssa: oh, another way to frame is you adding new "intrinsics" to OpenCL...?
20:46 alyssa: jenatali: stop doing nir_builder
20:46 alyssa: cmarcelo: sure
21:18 Kayden: dcbaker: agree with the others, I don't think macos symbols should be a release blocker esp. given we don't have really anybody developing that these days
21:23 glehmann: alyssa: so when are you going to write a nir C frontend to remove the llvm dependency
21:50 alyssa: glehmann: you know, I've thought about it.
22:04 karolherbst: ah yeah, the magical C nir frontend we talk about every 6 months
22:08 karolherbst: alyssa: though the issue is simply that you need custom functions which translate to custom intrinsics, no? We can already do that
22:08 karolherbst: or well.. it would be trivial to add
22:21 jenatali: Seems like the point is to remove manual steps and just write nir intrinsics directly?
22:25 karolherbst: sure, but you can do that already
22:27 karolherbst: like you could add internal functions and resolve them at link time, then you just need a lib to link against. I think you can even add more builtins at the clang API level to make that a bit nicer
22:29 jenatali: Sure, it's just promoting all (or more realistically some) nir functions to do that automatically I presume
22:33 karolherbst: yeah
22:33 karolherbst: functions starting with __ are considered internal stuff, so we could use them to do whatever we want
22:33 alyssa: karolherbst: it's just a nir pass that runs at link time to resolve nir_* functions to opcodes&intrinsics
22:34 karolherbst: yeah
22:34 karolherbst: it shouldn't be too hard to do
22:34 alyssa: I already did it lol
22:34 karolherbst: ahh
22:34 karolherbst: lol
22:34 alyssa: i should start posting MRs
22:34 alyssa: you down for reviewing an absurd # of cross-tree patches? :P
22:34 karolherbst: sadly we can't tell the translator to emit a custom extinst set
22:34 karolherbst: that would allow for more funky/cleaner things
22:35 karolherbst: alyssa: uhhh... sure
22:35 alyssa: :>
22:37 karolherbst: though I'd like to have a more streamlined way of adding builtin functions. The pain point obviously is to deal with compile time constants, but I think we might even be able to create something nice with most of it just being generated code
22:38 alyssa:taps her branch
22:38 alyssa: glehmann: https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32199/diffs?commit_id=cab6d1808b0f2c8c113368c9013ab7148e5f2e8d
22:38 alyssa: Is this non-harmful on amd / hw with native int64?
22:38 alyssa: I assume so but want to check if I should be predicating on lower_int64
22:39 karolherbst: ohh right, one of your patches broke llvmpipe 🙃
22:39 alyssa: um
22:39 karolherbst: but like...
22:40 karolherbst: in a "llvmpipe was already broken" way
22:41 karolherbst: something with corotines and functions and being in a weird state
22:42 Company: once you fix llvmpipe, you can also fix it on Windows
22:42 glehmann: alyssa: ugh, it's better for amd hw (or at least not worse for the SALU). But the question is if aco's RA gets in the way (but even if it does, I think the patch is okay as is)
22:44 alyssa: good enough for me :P
22:44 alyssa: thx
22:45 glehmann: might make sense to also add a <= UINT32_MAX, a < (UINT32_MAX + 1) and (UINT32_MAX + 1) >= a?
22:46 Company: alyssa: btw, I noticed hk is missing from features.txt - is that an oversight or on purpose?
22:46 alyssa: glehmann: maybe? Idk if any apps will hit these patterns, it's just something that NIR generates internally when lowering opencl
22:47 glehmann: fair
22:47 glehmann: also TIL nir_intrinsic_convert_alu_types exists
22:47 alyssa: Company: on purpose, features.txt is silly
22:47 glehmann: why is it not alu though
22:48 alyssa: because then someone would need to write constant folding..
22:48 alyssa: Company: https://vulkan.gpuinfo.org/displayreport.php?id=34688#properties
22:49 Company: alyssa: I use mesamatrix.net to get a quick overview about extension support across the board
22:49 alyssa: see https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/28054
22:49 Company: gpuinfo has too much noise
22:49 alyssa: just assume hk supports everything (((:
22:50 HdkR: Yes yes. It supports all the things
22:51 alyssa: * except RT
22:51 glehmann: mesh shaders?
22:52 glehmann: DGC?
22:52 Company:doesn't care about fancy GPU stuff
22:52 Company: I want WSI stuff
22:54 Company: that reminds me I wanted to check what goes on with vkPresent() blocking on Windows
22:55 alyssa: glehmann: ok not yet but probably in 2025
22:55 alyssa: apparently i'm supposed to do my day job or something sometimes though
22:58 alyssa:has to run but will continue opening MRs tomorrow (:
23:57 karolherbst: airlied: mind figuring out why 2a3f133fd0538cc3a8cde314b8cf5b23bff7f12a broke "non_uniform_work_group/test_non_uniform_work_group non_uniform_1d_atomics" with llvmpipe?
23:58 karolherbst: I _think_ it's just bad luck with how functions are implemented and the compiler hitting a barrier while the coro stuff isn't set up yet