00:09airlied: karolherbst4: is there an issue filed, would be good to the the GALLIVM_DEBUG=ir dumps,
00:12karolherbst: airlied: I haven't filed an issue, it's just a regression I've found like last week
00:13karolherbst: airlied: https://gist.githubusercontent.com/karolherbst/a53b7e798c110963266ea2c736de1001/raw/2a8c4ef2500d37847e5802747870de25a70eb7c8/gistfile1.txt
00:14karolherbst: crashes on sus_info being NULL
00:15airlied: and that pattern broke it like that?
00:19karolherbst: yep
00:23airlied: can you get the IR dump with that reverted?
00:48karolherbst: airlied: https://gist.githubusercontent.com/karolherbst/e5cf5e739090c3eba30e5250ed7b3e24/raw/07e2d0378fc94e858ac1353b152260c9c72e75c5/gistfile1.txt
00:48karolherbst: mh
00:48karolherbst: maybe I need to get a different version of it 🙃
00:50karolherbst: airlied: this one actually: https://gist.githubusercontent.com/karolherbst/1515466739da14f426a9a6a5505575f9/raw/3bc71f9f5622fa74acad39e7c1d8d1a041f0f7ab/gistfile1.txt
00:50karolherbst: uhhh
00:50karolherbst: why is copy&past broken...
00:52karolherbst: but anyway.. I think the different is that something doesn't get inlined anymore
00:54karolherbst: airlied: anyway.. this version should compare better to the one crashing https://gist.githubusercontent.com/karolherbst/ad7258d5b721ec2f15b38a00c2239622/raw/e212ddec2d4bcf84cff0d244ed5e8fb53f2dc192/gistfile1.txt
01:16airlied: karolherbst: ah yeah not getting inlined might explain it
01:17airlied: since barrier in functions won't work
01:28karolherbst: yeah...
01:28karolherbst: airlied: any ideas on how to deal with it?
01:42airlied: karolherbst: not sure why the inliner would suddenly stop inlining, maybe tweak the inliner params
01:43airlied: nir_function_can_inline
01:43airlied: though maybe I should detect barriers in a function and force inline
01:47airlied: https://paste.centos.org/view/5d114f3a that might fix it?
01:59karolherbst: airlied: nope
02:08airlied: karolherbst: bumping ssa_alloc to 60 works
02:08karolherbst: not sure I like that solution
02:11karolherbst: airlied: could also force inlining all functions with barriers, but....
02:12karolherbst: what's the problem with making barriers work in functions?
02:12karolherbst: besides that being hard with LLVM apparently
02:13airlied: karolherbst: https://paste.centos.org/view/raw/2fee3cae
02:13airlied: got very little to do with LLVM
02:14airlied: barriers have to store a bunch of coroutine state, and functions don't have access to that when you compile them
02:15karolherbst: mhh I see
02:15karolherbst: well at least that patch works
02:22airlied: karolherbst: https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32204
02:23karolherbst: thanks
03:36alyssa: airlied: btw, something I've noticed with the libagx approach is that there's a nontrivial memory footprint to keeping the nir_shader * library around for linking
03:36alyssa: I'm wondering if it's feasible to have some sort of "link with serialized NIR" mode
03:36alyssa: deserializing just the relevant function on the fly
03:37alyssa: (since serialized NIR is much smaller than unserialized, and also is rodata & can be swapped out for "free")
03:39alyssa: on main right now, it's about 3MB for libagx
03:39alyssa: on my wip branch (that precompiles shaders to hw binaries at mesa build time, so that libagx only needs symbols actually linked at runtime) it's 422KB
03:40alyssa: which is much better but still nontrivial and expected to grow over tiem
03:40alyssa: *time
04:38airlied: alyssa: linking serislized sounds tricky, but maybe if we could split the stream into per-function chunks, with function decls
04:38RAOF: Huh, do I have this right? wp_linux_drm_syncobj requires me to signal a timeline point when the buffer may be reused.
04:40RAOF: If I want to use "OUT_FENCE_PTR", KMS will give me a sync _file_ with a fence that signals when scanout is done.
04:40alyssa: airlied: yeah, i haven't looked yet into what would be entailed
04:41alyssa: precompiling is bad enough and cut the footprint 90% so
04:42RAOF: To get that into the client's sync_obj_ at the right timeline point, I need to (a) import the sync file from KMS into a (binary?) syncobj, then transfer the 0-timeline point from that imported syncobj to the client's syncobj at the right timeline point?
04:42alyssa: airlied: ..and now my perfectionism has me thinking about perfect hash tables (:
08:18MrCooper: RAOF: plugging the fence from OUT_FENCE_PTR directly into the syncobj release point is a bad idea: the client might pick the buffer which is still being scanned out for its next frame, which means its GPU work for the next frame can't start before the atomic commit completes; it gets even worse if the atomic commit misses a refresh cycle
10:00tzimmermann: arnd, hi. will you send an update to the Kconfig fix?
10:25karolherbst: alyssa: everybody knows the only perfect hash table is the one POSIX has :P
10:25karolherbst: emphasis on has table, not hash tables
10:26karolherbst: *hash
10:57karolherbst: mhhh, my toy and hobby project turns into something people seriously consider using, it's over for me now: https://gitlab.freedesktop.org/mesa/mesa/-/issues/12177#note_2664951
10:59mripard: karolherbst: you're screwed. you'll have jira tickets now
11:01karolherbst: yeah....
11:01karolherbst: and here I thought I managed to escape Jira hell
12:09Ermine: will drm-misc-next make it into linux 6.13? I guess no
13:40tzimmermann: Ermine, the current drm-misc-next will be in 6.14
14:57mlankhorst: Ermine: if you want it, you need to put it in next-fixes, needless to say only fixes. :-)
14:57mlankhorst: or -fixes
15:08Ermine: mlankhorst: no, it's just my first and I'm excited. No need to put it in -fixes
15:26alyssa: karolherbst: you know they could.. implement it and send an MR..
15:27karolherbst: I know...
15:31mlankhorst: Share with OpenGL to export to Vulkan. :D
15:36karolherbst: I mean, most of the stuff is already implemented anyway, might just need a lot of moving code around or something
15:44alyssa: yeah it's just.. prop mesa forks floating around do not spark joy :(
15:46sima: alyssa, from my kernel experience, as long as upstream moves fast enough and brings enough new stuff people want the forks suffer to no end until they start doing the right thing
15:46sima: and with things like europe's product regulations it's even more reasons
15:47sima: at least if mesa becomes it's own cna and turns up the cve firehose to 11 like the kernel :-P
15:48alyssa: sima: yeah.. although there's still the blunt GPL vs MIT difference there
15:48alyssa: I have often wishes Mesa was LGPL or something but.. a bit late for that by 30 years
15:48sima: yeah, but I honestly think the longer I'm in this pit the more I think that part doesn't matter really
15:49daniels: I wouldn’t expect them to ship a proprietary fork; they don’t for other MIT things like Weston
15:49sima: like for the kernel I don't think the gpl matters that much, it's dri-devel having principles of what it takes before we merge
15:50alyssa: sima: yeah, that's very fair
15:50alyssa: daniels: oh, nice :+1:
15:51sima: alyssa, and large chunks of drm are still dual licensed, despite that that's frowned upon in the kernel
15:54pac85: alyssa: wait how do you ship hw binaries, does your backend support linking?
15:55alyssa: pac85: ?
15:56pac85: alyssa: referring to your message from yesterday where you say that you ship linagx as an hw binary
15:56pac85: libagx*
16:01alyssa: pac85: Binaries are for standalone driver shaders (e.g. the prefix sum kernels, the tessellator kernels)
16:02alyssa: Runtime library support is still serialized NIR (e.g. the GenXML-based implementation of textureSize)
16:02pac85: Aaah makes sense
16:02alyssa: It turns out the standalone shaders make up most of libagx, so the memory footprint of libagx shrinks 90% if you get rid of them by precompiling
16:04pac85: Interesting
16:25alyssa: pac85: tbf the tessellator is huge.
16:34pac85: 1600loc of math heavy code I can it imagine it would be a big chunk of it
16:46jenatali: sima: That reason is exactly why Microsoft's Mesa-based code is upstream
16:46alyssa: jenatali: \o/
16:46jenatali: If it was GPL licensed, we probably wouldn't have touched it
16:47alyssa: jenatali: and Microsoft's Mesa code is the reason NIR-based CL is as far along as it is
16:47alyssa: which is how my entire stack works
16:47jenatali: Yeah. I'd like to think we're overall a positive for the community
16:47sima: jenatali, yeah gpl tends to scare people away from even starting with a fork
16:47daniels: the circle of life
16:47jenatali: Despite our reputation
16:48alyssa: quick, someone tell Phoronix that Microsoft brought GL4.6+VK1.3 to the M1
16:48jenatali: :P
16:48sima: so they never get to the realization of why going upstream is best
16:48jenatali: I mean it's also the reason that at least one (probably multiple at this point) GL titles have shipped on Xbox
16:48jenatali: Never would've happened if we did something proprietary
16:48sima: jenatali, hey there's reasons I really wanted you on the sponsor lineup, you belong :-)
16:48jenatali: ^.^
16:48alyssa: jenatali: not that i'm complaining but why does anyone want to ship GL titles on Xbox
16:48ccr: alyssa, the comment section of that article would be a smoldering blast pit in a few hours
16:49jenatali: ¯_(ツ)_/¯
18:56mareko: who is maintaining vc4?
18:58alyssa: mareko: Maybe Juan Suarez
18:59alyssa: Igalia, at any rate
19:15mareko: alyssa: can you please review the remaining 2 commit here if you have time? https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32173
19:34anholt: mareko: rb for the vc4 patch
19:43linkmauve: Hi, I see DRM_FORMAT_C1..DRM_FORMAT_C8 exist, but how do I set the palette for a given buffer?
19:43alyssa: mareko: oops, I thought I did
19:44DemiMarie: sima: I am extremely grateful that the DRM code is dual-licensed, because it makes it possible for the BSDs to ship code based on it and therefore allows them to have any GPU support at all.
19:44alyssa: done
19:47DemiMarie: jenatali: has Microsoft considered providing OpenGL 4.6, OpenCL 3.0, and Vulkan 1.3 as Windows OS components, implemented using Mesa on top of the vendor-provided Direct3D12 driver? It seems that would solve a (perhaps significant) duplication of effort between various IHVs.
19:47DemiMarie:hopes her comments are useful and not a waste of anyone’s time
19:49DemiMarie: sima: As someone who is into security I think having Mesa start issuing a CVE firehose would be good for WebGPU and WebGL security, especially on stable distros like Debian. (Disclaimer: opinions my own, not Invisible Things Lab’s or anyone else’s.)
19:49jenatali: Demi: GL4.6 is done, CL3.0 is done, and Vk1.2 is done
19:49jenatali: They're not OS components, but are available from https://apps.microsoft.com/detail/9nqpsl29bfff?hl=en-US&gl=US
19:51jenatali: GL is officially conformant at 3.0. Microsoft is an adopter to 4.4, but we haven't done the work to chase down IHV driver bugs to try to get an official conformance for 4.4 yet. We'd need a significant reason to pay for the 4.6 adopter capability
19:51jenatali: CL and Vk aren't officially conformant. They're both pretty close though
19:51jenatali: We are also CL (3.0) and Vk adopters
20:27MrCooper: linkmauve: the gamma LUT?
20:28linkmauve: Oh, makes sense.
20:28linkmauve: But then it’s per-CRTC instead of per-plane?
20:30MrCooper: I guess
20:32linkmauve: And then it’s only useful for DRM display, not as a generic Wayland buffer.
20:32linkmauve: Or GL or Vulkan or whatever.
20:34DemiMarie: jenatali: Any plans for Vk1.3?
20:34jenatali: It's close, but there's some gaps and spec wording that needs to be addressed
20:37DemiMarie: I wonder if it would be useful to try running Dozen in Wine/Proton (on D3DVK). Would be interesting, at least 😆
20:54feaneron: is rusticl enabled for the amdgpu driver by default these days?
21:44alyssa: feaneron: no
21:44feaneron: hrm, okay
21:45feaneron: and i suppose things may explode in spectacular ways if i try to force rusticl to use radeonsi
21:56karolherbst: feaneron: it shouldn't blow up tho
22:06glehmann: konstantin: can you take a look at the debug info commit here, I have no idea why nir_instr_def and nir_instr_get_def_def didn't do the same before. Probably just an oversight but I'm not really familar with debug info https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32235
22:25feaneron: the funny thing is that `RUSTICL_ENABLE=amdgpu clinfo` doesn't seem to list my amd card
22:27feaneron: i must be missing something, isn't RUSTICL_ENABLE suppose to forcefully make rusticl use a certain driver?
22:28RAOF: MrCooper Huh. I thought OUT_FENCE_PTR was signalled _after_ the buffer had been fully scanout-ed?
22:28glehmann: feaneron: you need RUSTICL_ENABLE=radeonsi
22:28feaneron: yeah RUSTICL_ENABLE=radeonsi makes rusticl list my graphics card
22:29glehmann: radeonsi is the gallium driver for modern amd gpus
22:29RAOF: MrCooper So what fence _should_ I put in the syncobj for the release point?
22:30RAOF: And, I guess, an alternate question: if OUT_FENCE_PTR _doesn't_ signal when the FB is safe for reuse, what is its purpose?
22:30feaneron: glehmann: what puzzles me is that apparently - according to `lspci -k` - the gpu is using the amdgpu driver. thus why i assumed that mixing a radeonsi userspace app with an amdgpu kernel driver could go badly.
22:31feaneron: 2f:00.0 VGA compatible controller: Advanced Micro Devices, Inc. [AMD/ATI] Navi 21 [Radeon RX 6950 XT] (rev c0)
22:31feaneron: Kernel driver in use: amdgpu
22:31feaneron: perhaps those are two completely different things, and i'm just erroneously mixing it all up
22:33glehmann: amdgpu is the kernel driver for modern amd gpus. radeonsi is an userspace driver and supports both amdgpu and its predecessor radeon
22:33glehmann: naming isn't the greatest for sure
22:34feaneron: hehe
22:34feaneron: thanks for clarifying this
22:34zamundaaa[m]: RAOF: it is safe, the problem is that it's quite early
22:35zamundaaa[m]: hmm, if the client behaves sanely, it shouldn't matter
22:36zamundaaa[m]: as long as it prefers to pick buffers where the release point is signaled and not just materialized
22:54RAOF: Ah, yeah, you can tell the difference there, can't you.
22:57anholt: ------*
23:46karolherbst: maybe I should add more alias names 🙃