00:00 psykose: didn't llvm say config is deprecated now with cmake preferred :D
00:00 alyssa: q
00:05 kisak: mareko: Debian packaging just sticks the llvm-config you want right under its nose so that it matches early https://salsa.debian.org/xorg-team/lib/mesa/-/blob/debian-experimental/debian/rules#L15-17
00:08 airlied: https://paste.centos.org/view/62163e3d was my local change
00:08 airlied: dcbaker: mareko: ^
00:08 airlied: when I updated to meson 1.2.0
00:09 jtatz[m]: I didn't even know it, but it's been deprecated since 2018? https://reviews.llvm.org/D51714
00:11 dcbaker: Sigh. I need to go fight them that if they’re going to drop llvm-config they need pkg-config
00:13 mareko: airlied: thanks, that did it
00:14 dcbaker: I’ll also file a bug against meson tomorrow. That’s a big change without a big fat warning that your build will be broken by upgrade
00:31 jtatz[m]: what's weird is that it looks like cmake has always been the default method for meson's llvm dependency factory
00:33 airlied: maybe the cmake path just never worked properly before
00:43 dcbaker: jtatz: definitely wasn’t always. I wrote that code :)
00:48 jtatz[m]: I'm going through the git history, and I think you might have done it when you switched llvm to DependencyFactory, since methods is ordered, as _factory was the one deciding the order before? https://github.com/mesonbuild/meson/commit/29b6d3e63ce6b18fa159a9d36de77c4f78c8bcc9
00:49 airlied: dcbaker: also I tried using some of the cmake path env vars to pick up the cmake files from one of my llvm installs, and I didn't make that work
01:11 jtatz[m]: ok, found when the change happened, meson would skip cmake entirely if shared-llvm was requested until January this year, https://github.com/mesonbuild/meson/commit/89146e84c9eab649d3847af101d61047cac45765
03:25 mareko: "This patch is trying to acheive feature parity between config-tool searching of LLVM and CMake-based one, which is arch-agnostic." - so that's why cmake is trying link a 64-bit mesa with 32-bit llvm, it's "arch-agnostic"
03:25 mareko: they can't fail more than that
07:20 serjosna: what we found out is just amazing, like whoa, i really made it through all riddles finally! It turns out that gpio from cpu and dma writes are different in terms of dma parameter loading, internal dma can corrupt the condition, cause it thought it already decremented the count, but it's adjusted back on. But as the descriptor moves ahead contiguously it hits the condition where full addition is made without transferring any bytes. so they have
07:20 serjosna: super computers yeah, what i was really expecting when they sell that technology onto people doorstep. I am also shocking dummy at times.
07:44 serjosna: currently i am just looking at the best way to expose subtract as minor addition of functionality to cornell pic32 , other stuff i know it leads to success entire success, there is maybe some other method than changing the addressing mode to decremental.
07:54 serjosna: provided that likely dma hardware reinits internal registers flushes/invalidates, there is maybe such way, depending on where in the pipeline it is, mark nbytes as bigger than source size and byte mask all the results out, than it must do some early skipping on the chip, currently searching for such pointers from the web
08:30 pq: MrCooper, my question about hiding pipelines was explicitly about the all-blob design. We already have a solution more or less for the new KMS object type design. The all-blob proposal said nothing about it.
08:32 pq: swick[m], my issue about the adding props question is adding a new prop to an existing and otherwise understood colorop. IMO, userspace cannot use a colorop (must be bypassed or not present) if userspace does not understand all props it has.
08:33 pq: emersion, I don't think new props on an otherwise known colorop can be ignored, who knows what state they are in, or what it did before the prop was added. Do you have a solution to that? I *really* do not want to fall into the "same as other KMS props" horrors.
08:33 pq: emersion, actually, "the same as other KMS props" solution is the same: do no use a pipeline at all, if it has any detail you don't understand.
08:34 pq: it all seems to converge on the same rules even when we are not "solving" the "trash in unknown properties" problem.
08:45 pq: all this means that adding a new prop into an old colorop would stop userspace from using that colorop, meaning it's practically equivalent to a whole new colorop if it had users relying on it.
09:33 dottedmag: Is there any syscall that returns sync_file unrelated to any dma-buf buffer? Or are all sync_files available to userspace always originate from a buffer and obtained using DMA_BUF_IOCTL_EXPORT_SYNC?
09:44 sima: dottedmag, atomic display ioctl and many execbuf/comman submission ioctl can return a sync_file too
09:44 dottedmag: sima: thanks
09:49 sima: dottedmag, you can also use sync_file to get fences in/out of drm_syncobj
09:51 dottedmag: sima: aha, this is the next piece of puzzle I was going to untangle, thanks
10:23 swick[m]: pq: I think in general you're right. Read-only props are one exception. Otherwise, we would need that reset mechanism.
10:27 pq: swick[m], read-only props are not obviously harmless. Someone might try to use a read-only prop to squash two different ops into a single colorop type.
10:28 pq: That should be stopped at kernel patch review, but...
10:28 swick[m]: yeah, was gonna say, that's true, but we should not allow stuff like this in the first place
10:29 pq: what if a read-only prop is added for hardware that does the original operation, but with reduced precision? which might not satisfy old userspace
10:29 swick[m]: so we could make a guarantee that read-only props must not introduce incompatibility
10:30 swick[m]: I would say: not allowed, needs a new op type
10:30 pq: I wonder, what kind of detail userspace would be interested to know, but also cannot cause incompatibility?
10:30 swick[m]: but yes, you're right, it's not generally true that any read-only prop is harmless
10:31 pq: ...maybe something like a LUT that allows more sizes than usual
10:31 swick[m]: we really have to write all of that down and think about it hard
10:31 pq: or flags increased precision
10:31 swick[m]: well, if precision was unspecified and then gets specified with a r/o thing
10:32 swick[m]: anything that exposes more information that was previously unspecified basically
10:33 pq: for userspace that wants to be more picky than it previously could, yeah
13:07 zmike: anyone know how I get an xserver instance to pick a different libGLX? glvnd seems to always load my system install
13:10 MrCooper: different filename, or just different path?
13:10 zmike: path
13:10 zmike: it's using /usr/ prefix and I want it to use /usr/local
13:10 MrCooper: LD_LIBRARY_PATH then?
13:10 zmike: tried that and it doesn't work
13:12 MrCooper: did you double-check that the Xorg process picked up the envvar?
13:15 zmike: hmm
13:15 zmike: indeed it doesn't seem to be
13:19 zmike: not sure what to do about that if it's getting sanitized out by the loader scripts
13:19 pq: is it not sanitized out by setuid-root bits?
13:20 pq: do you actually need Xorg, or could e.g. Xwayland do?
13:21 zmike: I can't get a functional wayland system compositor to start on this machine for various reasons, so I'm working with what I've got
13:22 pq: would headless do?
13:23 zmike: ideally not
13:24 pq: on my machine, /usr/bin/Xorg seems to be a script that launches /usr/lib/xorg/Xorg.wrap which is set-gid root. Maybe that explains why LD_LIBRARY_PATH is dropped.
13:24 pq: and setuid root
13:25 pq: maybe trying /usr/lib/xorg/Xorg directly might help?
13:26 pq: or moving Xorg.wrap out or poking the script, assuming you don't actually need root
13:29 zmike: oh ho
13:29 zmike: I think that did it
13:31 zmike: yea it did, thanks
13:33 MrCooper: I'd argue that if /usr/local/lib* doesn't take precedence over /usr/lib*, the system is broken
13:33 zmike: shrug
13:34 zmike: pretty close to stock fedora
13:34 zmike: who can say
13:34 MrCooper: indeed, I added /etc/ld.so.conf.d/aa_local.conf for this
13:50 emersion: pq, i don't really agree, but am on leave rn, so won't reply
13:52 pq: better to continue in email anyway
14:18 austriancoder: is/should pep8 be used for python files in mesa?
14:21 koike: austriancoder: we should have checks in the lint stage, let me see
14:23 zmike: MrCooper: probably a q for you: why does my system refuse to use wayland for any of its sessions?
14:23 zmike: gdm uses xorg and even the default gnome session uses xorg
14:24 koike: austriancoder: looks like we don't, but if you grep for pep you can see a few comments on docs/relnotes, so I guess so
14:28 austriancoder: koike: 👍🏻
14:35 hakzsam: to simplify some code in RADV, I would like to use sync2 in wsi but not all drivers seem to support it (like pvr). Would it be OK to use sync2 conditionally in WSI?
15:04 MrCooper: zmike: usually it's because gnome-shell fails to come up in Wayland mode for some reason; I'd look for gnome-shell messages in "journalctl -b0"
15:07 zmike: looks like 'Running GNOME Shell (using mutter 44.3) as a X11 window and compositing manager' is the first message I get
15:20 MrCooper: zmike: is the `WaylandEnable=false` line in /etc/gdm/custom.conf uncommented perhaps? Or is there an Nvidia GPU in the system?
15:20 zmike: no and no
15:20 zmike: I even set that option to true just to check
15:21 MrCooper: weird; in a VT console, does "dbus-run-session gnome-shell --wayland" work?
15:22 zmike: "unsupported session type"
15:22 zmike: is it not installed by default?
15:23 zmike: I thought it was at this point
15:27 MrCooper: certainly is
15:29 MrCooper: hmm, I can only find that string in Firefox/Thunderbird's libxul, so it might be a red herring; try redirecting stdout+stderr to a file
15:30 zmike: stdout+stderr from dbus-run-session?
15:30 MrCooper: yes
15:30 zmike: it's just that one line
15:31 MrCooper: huh, how about just "mutter --wayland" ?
15:31 MrCooper: (without dbus-run-session)
15:32 zmike: seems like it worked?
15:32 zmike: yeah I can launch stuff into it from ssh
15:33 zmike: that's good enough for me
15:34 MrCooper: k, so there's something weird with dbus-run-session on your system, not sure it's directly related to the original issue though
15:35 zmike: I just wanted some kind of wayland system compositor to run for testing, so this solves that problem
15:36 zmike: thanks for the ideas
15:37 MrCooper: no worries
15:38 MrCooper: FWIW, my grep failed because the string in mutter is "Unsupported session type"
15:45 MrCooper: zmike: in that VT console, does 'echo $XDG_SESSION_TYPE' print anything?
15:46 zmike: tty
15:51 MrCooper: k, not sure what's going on there :/
15:52 MrCooper: zmike: jadahl might be able to tell more if you show him the output of journalctl -b0
15:53 zmike: it seems to work fine on another machine I have here, so I'm gonna assume this one is just broken somehow
15:53 zmike: it's a test machine and I'm not too upset
15:54 MrCooper: yeah, my best guess is that maybe some environment variable is hardcoded system wide and messes up things
15:55 jadahl: that env var should be set by systemd or logind or something
15:55 jadahl: or no, it shouldn 't even be set IIRC
15:55 jadahl: it's something used to override what systemd tells us
15:56 Company: question for the nvidia experts: When I'm doing Vulkan stuff and my shader does invalid memory accesses, AMD GPUs reset themselves and take down my compositor and force me to reboot, while Intel just shrugs and I get VK_ERROR_DEVICE_LOST
15:57 Company: which makes Intel a lot less catastrophic to work with
15:57 Company: where is nvidia hardware on that spectrum?
15:57 MrCooper: jadahl: FWIW, a VT shell on F38 has $XDG_SESSION_TYPE=tty for me as well, and 'dbus-run-session gnome-shell --wayland' works
16:00 jadahl: MrCooper: interesting!
16:00 jadahl: I probably dreamt that it wasn't a real thing then
16:03 zmike: nvidia usually recovers fine
16:44 karolherbst: on nvidia you just need a new context and everything is fine
16:45 karolherbst: they have hardware level isolation and all that stuff, even the VM is independent from the allocated GPU context
16:45 karolherbst: so on the driver level, you can allocate a new context and keep all your memory even and just continue (in theory)
16:46 karolherbst: there are some rare cases where the nvidia driver can't recover from a GPU fault
16:46 karolherbst: anyway, don't take AMD as a baseline for GPU recovery, they are afaik the worst in this regard across the big players
16:47 Company: I was mainly asking that question to judge which GPUs to recommend to other developers
16:47 Company: who want to work with Vulkan stuff
16:47 karolherbst: if you are risking crashing the GPU a lot, then I'd advise to not use AMD
16:48 Company: I guess for now nvidia isn't the best choice anyway because Mesa doesn't support it well
16:48 karolherbst: mhh yeah, that's fair
16:48 Company: yeah, but if you want to make sure your code is solid, test it on AMD
16:48 karolherbst: intel is solid enough, never had any issue with the driver (- some kernel data race which I've fixed) while hacking on OpenCL on the harwdare
16:49 karolherbst: yeah, testing should definetly be done on all relevant GPU drivers
16:49 karolherbst: just the developer experience isn't the greatest
16:49 karolherbst: it's very unfortunate, but that's how it is
16:50 karolherbst: and nothing the driver team can do much about as that's mostly due to lack on the hardware side
16:50 Company: yeah
16:50 Company: just good to know in advance when somebody asks
16:51 Company: as there's more and more stuff happening on the lower layers around gnome
16:51 karolherbst: nvidia is really good on the hardware side here as they have strong isolation between GPU contexts and normally you only have to remove the faulty one and all the others can continue their job
16:51 Company: with GTK4 going GL and Cairo being on its way out
16:51 karolherbst: yeah, fair
16:52 Company: most of the stuff that's happening so far is people trying to pass images around
16:53 Company: like the virtio stuff that the spice people have been doing
16:53 Company: or various video stuff with pipewire/gstreamer
16:53 Company: and there's a few custom shaders, but that's usually just simple copy/paste from shadertoy
17:27 Lynne: while working on the vulkan video stuff there was a time I was doing 20 reboots a day on my main and only system, this was not fun
17:28 Lynne: airlied: did you get a 7900?
18:07 Company: Lynne: a thing I did onmy desktop is get a ryzen with embedded GPU - so theoretically I have 2 GPUs in this thing, but I'm not sure how well it isolates the GPUs
18:08 Company: it works when I do stuff that causes OOMs or (near) infinite loops - I can keep using my box while the other one goes bad
18:08 Company: but I feel like the memory sharing between the GPUs causes instabilities
18:53 airlied: Lynne: it's in the same country as me at least
19:05 DemiMarie: karolherbst: how good is Intel regarding isolation?
19:06 karolherbst: no idea
19:07 DemiMarie: suggestions for who to ask?
19:07 karolherbst: maybe to people on #intel-gfx or #intel-3d?
19:11 dj-death: DemiMarie: there is an actual set of pagetables per graphics context (usually)
19:12 dj-death: DemiMarie: so it's kind of hard to overwrite another process' data
19:12 dj-death: DemiMarie: that's on Broadwell+ only
19:15 DemiMarie: dj-death: what about registers and other state? is that flushed between contexts?
19:15 agd5f: memory isolation works fine on AMD as well since SI when we got vmid support. What's problematic is when you have multiple jobs executing on the GPU at the same time. If you have to reset the 3D engine, you lose the engine state for all processes that have jobs on that engine when it gets reset. That largely gets solved with per process queues (like ROCm uses today).
19:16 dj-death: DemiMarie: it should
19:17 dj-death: DemiMarie: we tend to get workaround where things don't work as expected
19:17 dj-death: DemiMarie: but it's not so much the state leaking as the HW hanging so...
19:17 Lynne: airlied: my opinion is that until the doorbell rings, it's on the moon
19:19 DemiMarie: dj-death: Are those workarounds enforced by the kernel to prevent cross-process information leak? HW hanging is “just” denial of service, which is not great but also not necessarily a complete dealbreaker.
19:20 DemiMarie: agd5f: why does graphics not use per process queues?
19:20 dj-death: DemiMarie: it's all over, part kernel part userspace driver
19:20 DemiMarie: dj-death: that is potentially a problem, then
19:20 agd5f: DemiMarie, they didn't exist until rdna3
19:20 mattst88: if, hypothetically, the answer was "isolation is terrible and everything is broken", what would you do with that information?
19:20 mattst88: (I don't understand the purpose of the questions)
19:21 dj-death: DemiMarie: given what I just read on this channel, it's a problem everywhere :)
19:21 DemiMarie: mattst88: trying to figure out if Qubes OS will ever be able to enable GPU acceleration, because GTK4 performance without it is garbage and the GTK4 developers are not interested in improving it.
19:22 dj-death: DemiMarie: if you expect a userspace driver not to be able to hang the HW, I think you can forget about any GPU stuff
19:23 karolherbst: "hanging" the machine is mostly just a question of how quickly you want to reap misbehaving jobs (stuck in an infinite loop) though
19:23 DemiMarie: dj-death: are you saying that GPUs do not have instruction-level preemption? Again, hangs are just denial of service, which while not great is not something Qubes OS would need to issue a security bulletin for. Information leaks and privilege escalation are.
19:24 karolherbst: DemiMarie: no GPU has it for evertyhinng
19:24 karolherbst: and instruction level preemption is quite expensive
19:24 DemiMarie: karolherbst: why do GPUs not have instruction-level preemption?
19:24 karolherbst: because it's a huge perf hit
19:24 agd5f: DemiMarie, they do for compute, but not for other engines like GFX and multimedia
19:24 DemiMarie: how big?
19:24 DemiMarie: do they have it for compute at least?
19:24 agd5f: fixed function hardware is the issue
19:24 karolherbst: yeah, for compute that's easier to do
19:25 DemiMarie: agd5f: multimedia I don’t care one iota about
19:25 karolherbst: and modern GPUs generally support it, at least I know that Nvidia (and also AMD?) supports it in compute
19:25 agd5f: yeah, with ROCm you can debug in gdb and single step through GPU programs
19:25 mattst88: "how big?" -- impossible to answer
19:25 karolherbst: but yeah.. it's mostly a debugging feature
19:26 karolherbst: though I guess for qubes OS it could be enabled always if it's an issue
19:26 karolherbst: just makes it slower
19:26 karolherbst: but processes can also DOS the machine by OOMing it
19:26 DemiMarie: otherwise the answer is likely to be “blow the context away, file bugs against the software that can’t handle a GPU reset, and ban that VM from using GPU acceleration until the user says otherwise”
19:26 DemiMarie: karolherbst: isn’t it also needed for memory management for long running compute workloads?
19:26 karolherbst: you just configure proper thresholds so you won't notice
19:27 DemiMarie: bingo
19:27 karolherbst: you could kill stuck jobs after one second and see if it's good enough
19:27 karolherbst: or something
19:27 agd5f: DemiMarie, yeah, that's why it's table stacks for ROCm. For GFX, the extra die area is too big a tradeoff for performance
19:28 karolherbst: I would honestly not worry too much about preemption and hanging the machine, that's always something you can let users decide how critical they thing it is
19:28 karolherbst: information leaks on the other hand are more critical :)
19:28 DemiMarie: karolherbst: exactly!
19:28 DemiMarie: hence why I need to know if the kernel enforces state clearing at GPU context switch, and if not, what would be needed
19:28 DemiMarie: IIUC this was the infamous “iGPU leak” bug
19:30 karolherbst: I think the problem you are having is, that you can't rely on any userspace bits, so if context switching requires userspace to play nice in order to not leak information you kinda can't use it. I don't know if intel is _that_ terrible, but "involves userspace" is kinda a red flag (probably)
19:31 karolherbst: but not sure what was meant with that precisly
20:28 gfxstrand: Anyone familiar with deqp-runner: Does it support the multi-level testlists?
20:29 gfxstrand: The Vulkan CTS no longer has everything in deqp-vk-defaul.txt and that's now just a reference to a bunch of other .txt files
20:29 Sachiel: gfxstrand: deqp-runner works fine with that
20:29 gfxstrand: Okay. I just re-built, maybe that'll fix it
20:30 Sachiel: yeah, it needed fixing but it was done a while ago
20:30 gfxstrand: Okay. I don't think I've pulled in a wahile
21:02 gfxstrand: Sachiel: I'm seeing piles of "Failure getting run results: No results parsed. Is your caselist out of sync with your deqp binary?"
21:02 gfxstrand: Sachiel: I've never seen so many before
21:02 alyssa: mattst88: I'd like to use intel_clc-like stuff for non-Intel drivers .. not sure I have a question yet but this relates with !24983
21:03 Sachiel: gfxstrand: cts main by any chance?
21:03 gfxstrand: But also I just updated my deqp like 2 hours ago
21:03 gfxstrand: Sachiel: Yeah
21:03 gfxstrand: Sachiel: Do I need to "build" the caselist or somethign?
21:03 Sachiel: gfxstrand: you need https://gerrit.khronos.org/c/vk-gl-cts/+/12492 that just got merged
21:05 gfxstrand: Sachiel: That'll do it...
21:05 Sachiel: yeah, sorry, I forgot everything was busted
21:06 gfxstrand: My fault for thinking updating the CTS would fix things. :-P
21:07 alyssa:is stuck trying to figure out if we should be spitting out serialized NIR at build-time or just SPIR-V
21:16 alyssa: probably SPIR-V until proven otherwise
21:18 gfxstrand: Yeah
21:18 gfxstrand: IDK how I feel about checking in serialized NIR
21:19 karolherbst: yeah.. we probably shouldn't
21:20 alyssa: gfxstrand: only the .cl is checked in to tree, I will NAK people checking in even SPIR-V if nobody else does :p
21:20 gfxstrand: alyssa: Ohk, for sure
21:20 alyssa: the question is whether we run NIR passes at build-time (like intel_clc does)
21:20 gfxstrand: I mean't building in, sorry
21:20 karolherbst: would be kinda funny to write stuff in SPIR-V if you are into that kinda stuff
21:20 alyssa: oh, yeah, ok, we're on the same page then
21:20 alyssa: karolherbst: i will NAK it so hard you'll think it was an awesome nvidia kompiler
21:21 karolherbst: great, looking forward to it
21:21 zmike: gfxstrand: there's also a lot of broken query-related tests that crash on main now
21:21 karolherbst: I still have this plan to come up with a cl-meta and.....
21:21 gfxstrand: zmike: Oh, great...
21:22 zmike: I filed a ticket but it'll probably be a month or two before it's fixed
21:22 Sachiel: zmike: that's not good, there's a release planned soon
21:22 Sachiel: those tests need to be fixed by then
21:22 zmike: I started looking at all the problems after doing a full run the other day but then I've been preempted by other stuff
21:22 gfxstrand: zmike: GL or VK query tests?
21:23 zmike: vk
21:23 zmike: glcts is always in good shape because I run it nonstop on a loop to generate entropy
21:23 Sachiel: yeah, I added the agenda tag
21:23 Sachiel: hopefully that makes someone fix them next week
21:24 gfxstrand: Breaks somewhere in CreateShaderModule
21:24 gfxstrand: Oh, this should be easy
21:24 Sachiel: is it shader objects related?
21:25 gfxstrand: ish
21:25 gfxstrand: It's trying to fetch a shader that didn't get compiled
21:27 zmike: vkcts in very bad shape now, so imo just blame all your fails on cts bugs and claim conformance
21:28 airlied: gfxstrand: I see that missing warning when my gpus stop handing out vmm from gsp
21:29 airlied: but I haven't seen it explode like that pre-gsp
21:33 gfxstrand: zmike: I've got a fix
21:33 gfxstrand: I think
21:33 gfxstrand: C++ default parameters considered harmful
21:34 gfxstrand: zmike: Where's the issue you filed?
21:34 Sachiel: https://gitlab.khronos.org/Tracker/vk-gl-cts/-/issues/4643
21:34 gfxstrand: I love how this test wraps twice on my 2560 monitor
21:40 gfxstrand: https://gerrit.khronos.org/c/vk-gl-cts/+/12516
21:40 gfxstrand: Sachiel, zmike ^^
21:41 gfxstrand: I'm really not liking how deqp-runner thinks this CTS run is going to take 2h.....
21:42 Sachiel: yup, that's the new normal
21:42 Sachiel: used to take 1:10 on my regular dg2 test system before shader objects, now it's 2h
21:42 Sachiel: 50 extra minutes of NotSupported
21:42 gfxstrand: :facepalm:
21:43 zmike: remember that time I complained about it and nobody cared
21:43 Sachiel: I'm sure it runs really fast on a Nintendo Switch
21:44 zmike: I'm positive they just throw 10,000 switches at it and run distributed
21:44 gfxstrand: Okay, after 5m, it's now down to 1:43:36 left. Maybe it's going to be less than 2h? Probably not by much. :-/
21:45 gfxstrand: I could just make my deqp runner denylist all shader object tests
21:45 gfxstrand: I think I'm goign to do that
21:47 gfxstrand: From a quick grep, that cuts the test list by 30% or so
21:47 gfxstrand: Already faster!
21:47 zmike: now just never implement it
21:47 gfxstrand: :P
21:47 gfxstrand: Oh, we're gonna implement it
21:47 gfxstrand: We're gonna implement the shit out of it
21:47 karolherbst: it's literally like 5 minutes of work :P
21:47 karolherbst: wasn't there an MR for it already? no?
21:47 gfxstrand: We need it if NVK is ever going to become the #1 driver on Switch, after all.
21:48 karolherbst: yep
21:49 karolherbst: that reminds me....
21:49 karolherbst: I do wonder if anybody already started to use nvk on it
21:49 gfxstrand: Not as far as I know but I wouldn't be surprised
21:49 gfxstrand: I'm planning to play around one of these days
21:50 karolherbst: :)
22:28 DemiMarie: karolherbst: mind if I DM you?
22:28 karolherbst: feel free to
22:41 DavidHeidelberg[m]: airlied: I haven't found anywhere in CI fails `GL46.gtf21.GL.mat3.mat3arraysimple_frag`, any chance https://gitlab.freedesktop.org/mesa/mesa/-/issues/5953 is resolved already?
22:41 zmike: those tests are from the confidential suite
22:42 zmike: we don't run it in ci because ci is public
22:43 jimc: hey all, 1stimer here. https://patchwork.freedesktop.org/series/121583/ has failed, I cannot grok why, help ?
22:53 airlied: jimc: probably false positives in the igt test run
23:17 mattst88: alyssa: cool, I hope the MR is ultimately useful for you
23:19 gfxstrand: 243 crashes in my NVK run is NOT cool.... Not cool, CTS, not cool....
23:33 HdkR: Betrayed by CTS
23:44 gfxstrand: Yeah, I just need to fix tessellation query tests harder
23:55 alyssa: mattst88: sort of orthogonal, just maybe subconciously made me think to give intel_clc another looksie :)
23:55 epony: from above