08:04tjaalton: what does one gain from enabling atomic-ops in libdrm?
08:23MrCooper: tjaalton: a bunch of per-driver libdrm_* libraries require them, see with_atomic in the toplevel meson.build
08:24tjaalton: MrCooper: yes, but that gets enabled even if atomic_ops itself isn't found
08:25tjaalton: if the compiler is good enough?
08:26MrCooper: ah, not sure offhand
08:28tjaalton: looking at xf86atomic.h more closely, it's clear that there's probably no reason to end up using AO_* if the platform supports atomics otherwise
10:21mairacanal: do we have some example of a shmem driver using a multi-level MMU?
10:34sima: mairacanal, like different iommu for different parts of the chip that are all under one driver?
10:35mairacanal: i mean like a page table that points to a second page table
10:40lynxeye: mairacanal: I guess there should be multiple examples. etnaviv mmu v2 uses two-level pagetables
10:41mairacanal: hum, thanks for the suggestion! i'll take a look at it
10:57sima: mairacanal, I think all the big desktop gpus have like 3-4 levels now or something like that
10:57sima: but they don't use the iommu abstraction, so not sure that applies for armsoc drivers
13:20zmike: is there any sort of policy about what kinds of shaders can be added for piglit tests? e.g., if I have a problematic shader from a game, can this be dropped in directly?
14:11graphitemaster: What is the status on subgroup operation support in the d3d12 gallium driver?
14:12graphitemaster: Running latest mesa with GLon12 on Windows and well ARB_shader_ballot doesn't seem to be supported but I'm curious if that's just because it hasn't been enabled and it is actually supported. I mean it reports GL4.6 support but GL4.6 definitely requires ARB_shader_ballot.
14:15agd5f: robclark, FWIW, I filed a bug in gmail and within a few days, mailing lists started working reliably again with my gmail.
14:19HdkR: graphitemaster: Shader subgroup arithmetic is part of a different extension that base ARB_shader_ballot though?
14:24jenatali: graphitemaster: hello again :P
14:29graphitemaster: Bonjure :D
14:33graphitemaster: Building llvm first before I can build mesa XD
14:35jenatali: graphitemaster: LLVM isn't required for gallium/GL
14:40kisak: graphitemaster: generally speaking, there's a summary of what supports what at https://mesamatrix.net/
14:46robclark: agd5f: oh, interesting.. I wonder if it is a per-account fix or they just allow-listed lists.fd.o?
14:48agd5f: robclark, not sure. I got feedback, just magically started working
14:48agd5f: *no feedback
14:49robclark: hmm, ok
15:00kisak: If someone with privledges has a spare moment, https://gitlab.freedesktop.org/mesa/mesa/-/tree/10553-intermittent-compiler-failures-when-building-valhall-tests looks like a misclick at https://gitlab.freedesktop.org/mesa/mesa/-/issues/10553#note_2274307 which would be nice to clean up.
15:01jenatali: kisak: it's protected somehow
15:03kisak: Hence the request for somewone with a bigger hammer to take a look.
15:04kisak:sighs at their own excess typos.
15:09kisak: (Done, thanks mystery admin)
15:11daniels: yw
18:54karolherbst: compiler-wrapper.sh being broken here: https://gitlab.freedesktop.org/mesa/mesa/-/jobs/54811620 what can I do to fix this?
23:39DemiMarie: Mershl: nope, that is sharing with the project devs who have not signed the NDA. Use the official forums provided for the purpose, and if you need to report a bug in third-party software, either find a reproducer that can be shared publicly or try paying for support from someone else who has signed the NDA.
23:39DemiMarie: Confidential issues are usually used for security vulnerabilities IIUC.
23:42DemiMarie: Is it feasible to emulate non-native virtio-GPU on top of native contexts in e.g. a stubdomain or nested virt scenario? I’m asking because OpenBSD has virtio-GPU support and such support will also be added to Windows at some point, but I don’t see either getting native context support any time soon.
23:42Sachiel: looks like someone is not identified and messages are not making it to irc?
23:43DemiMarie: probably, and with absolutely no warning of it either
23:43DemiMarie:wishes that OFTC supported SASL
23:44DemiMarie: Is it feasible to emulate non-native virtio-GPU on top of native contexts in e.g. a stubdomain or nested virt scenario? I’m asking because OpenBSD has virtio-GPU support and such support will also be added to Windows at some point, but I don’t see either getting native context support any time soon.
23:44DemiMarie: Alternatively, could the user-space driver parts be run in a WebAssembly based sandbox?
23:45dj-death: alyssa: kind of curious how you generate the serialized NIR for the opencl functions on the gitlab CI
23:46dj-death: alyssa: a bunch of cross-compiling stuff just doesn't seem to support that
23:46jenatali: Demi: Windows has had paravirtualization, which is pretty much the same as native contexts, for a few years now
23:46DemiMarie: jenatali: but can that be used with a non-Windows host?
23:47jenatali: Ah, no, I thought you were saying Windows host, non-Windows guest
23:47DemiMarie: Other way around
23:50ccr: w
23:51DemiMarie: jenatali: Use case is Windows gaming on Qubes OS without PCI passthrough (which especially for GPUs is full of security problems) or SR-IOV (which is only found in Intel iGPUs and unobtanium enterprise GPUs)
23:52jenatali: Yeah I get it
23:55tleydxdy: it should be possible if you can get M$ to sign your drivers