00:02fdobridge: <gfxstrand> Ugh... Let me try that again
00:07fdobridge: <gfxstrand> Okay, fixed.
00:08fdobridge: <redsheep> Much better, thanks
00:15fdobridge: <Misyl with Max-Q Design> ah, shouldn't be a problem for Gamescope then
00:15fdobridge: <Misyl with Max-Q Design> no EGL involved there
00:22fdobridge: <redsheep> Had to use Sid's PKGBUILD since mine makes it a real pain to change where I get the source, but I have finally got a viable build in progress. I am going to shoot straight for the moon and put `export NOUVEAU_USE_ZINK=1` in my /etc/environment right away and hope for the best
00:25fdobridge: <redsheep> Oh something else I am hoping for, until now not only has it always been 5 fps to run a zink session, but wayland has always resulted in a crashed session. I will update soon, rebooting now to test
00:40fdobridge: <redsheep> I can confirm that resulted in a stable and wonderfully performant zink plasma-x11 session
00:41fdobridge: <redsheep> Hmmm plasma Wayland still explodes.
00:45fdobridge: <redsheep> It messes up switching to a virtual terminal and my screens go black so it's kernel or maybe even the hardware that is giving up. I can also tell from my external CPU temp read out that it's getting stuck spinning on something pretty hard
00:46fdobridge: <redsheep> I'll see if I can recover kernel logs
00:53fdobridge: <redsheep> Gamescope is working on the x11 session, still working on logs
00:59fdobridge: <redsheep> Looks like I got a load of spam like this:
00:59fdobridge: <redsheep> ```May 08 18:43:56 jared-linux kwin_wayland_wrapper[1211]: MESA: error: zink: display server doesn't support DRI3 modifiers and driver can't handle INVALID<->LINEAR!
00:59fdobridge: <redsheep> May 08 18:43:56 jared-linux kwin_wayland[1211]: kwin_scene_opengl: Error creating EGLImageKHR: "EGL_BAD_ALLOC"
00:59fdobridge: <redsheep> May 08 18:43:56 jared-linux kwin_wayland[1211]: kwin_wayland_drm: Failed to find a working setup for new outputs!```
01:01fdobridge: <redsheep> Here's the only other relevant section
01:01fdobridge: <redsheep> ```May 08 18:43:57 jared-linux kcminit_startup[1216]: qt.qpa.wayland: Creating a fake screen in order for Qt not to crash
01:01fdobridge: <redsheep> May 08 18:43:57 jared-linux ksplashqml[1214]: qt.qpa.wayland: Creating a fake screen in order for Qt not to crash
01:01fdobridge: <redsheep> May 08 18:43:57 jared-linux kcminit_startup[1216]: Initializing "/usr/lib/qt6/plugins/plasma/kcms/systemsettings/kcm_mouse.so"
01:01fdobridge: <redsheep> May 08 18:43:57 jared-linux kcminit_startup[1216]: Initializing "/usr/lib/qt6/plugins/plasma/kcms/systemsettings/kcm_style.so"
01:01fdobridge: <redsheep> May 08 18:43:57 jared-linux kernel: Module nvidia is blacklisted
01:01fdobridge: <redsheep> May 08 18:43:57 jared-linux ksplashqml[1214]: mesa: Kopper interface not found!
01:01fdobridge: <redsheep> May 08 18:43:57 jared-linux ksplashqml[1214]: Ensure the versions of libEGL_mesa and libGLX_mesa built with this version of Zink are
01:01fdobridge: <redsheep> May 08 18:43:57 jared-linux ksplashqml[1214]: in your library path!
01:01fdobridge: <redsheep> May 08 18:43:57 jared-linux ksplashqml[1214]: libEGL warning: egl: failed to create dri2 screen```
01:09fdobridge: <redsheep> @gfxstrand ^ there are your results. In summary, gamescope works, plasma x11 works, plasma wayland blows up an dnothing notable ends up in the equivalent of dmesg, but plasma complains plenty about modifiers. Maybe a plasma bug, but hard to be sure until somebody has tested mutter. The performance of the session itself seems to be very slightly better, which gets games running a few percent faster, but nothing crazy huge.
01:09fdobridge: <Sid> I've got a test in 3h, but after that I can try out both i3wm and sway on NVK+zink
01:09fdobridge: <redsheep> To be clear I mean better than nvc0 session performance
01:09fdobridge: <Sid> and maybe sway vulkan renderer on nvk natively
01:10fdobridge: <redsheep> The session perf vs zink before is at least 20x improvement
01:11fdobridge: <gfxstrand> That's an interesting Zink message. I'll look into it tomorrow.
01:15fdobridge: <gfxstrand> @zmike. What's up with `can_do_invalid_linear_modifier_swap`?
01:16fdobridge: <gfxstrand> We might be able to set that for NVK
01:17fdobridge: <gfxstrand> @redsheep Try it with the patch I just pushed.
01:17fdobridge: <gfxstrand> @zmike. can explain to us in the morning what that does. 😅
01:20fdobridge: <redsheep> Alright cooking up some fresh mesa builds now
01:22fdobridge: <zmike.> basically if the driver can do implicit modifiers successfully
01:23fdobridge: <redsheep> That resulted in a really crazy looking corrupt screen for a few moments before backing out to sddm
01:23fdobridge: <zmike.> i.e., the driver gets INVALID and magically selecting a modifier works
01:23fdobridge: <redsheep> I'll take it over having to reboot but not ideal
01:32fdobridge: <redsheep> The attempted plasma wayland session didn't kick out anything in dmesg
01:34fdobridge: <redsheep> I am no expert of course but the corruption looks a lot like there's a tiled vs linear mismatch
01:35fdobridge: <redsheep> It's visually similar to the previously broken gamescope screenshots
01:50fdobridge: <redsheep> Hmm the old zink corruption on discord server icons is still here. Not sure if anyone has replicated with radv to see if that was nvk specific
01:50fdobridge: <redsheep> https://cdn.discordapp.com/attachments/1034184951790305330/1237944662673723504/image.png?ex=663d7d4f&is=663c2bcf&hm=887da0d23d8bd48ef1c4948995b90c285c819ed80183d98921c8d6ddcce7fc6c&
01:50fdobridge: <Sid> oh yeah, zink+nvk also has massive artifacting if MSAA is enabled
01:50fdobridge: <Sid> which didn't exist on nvc0
01:51fdobridge: <gfxstrand> Ah. I might be able to make that work (ish)
01:52fdobridge: <Sid> granted, I was running 8x MSAA on both cases.. I should be able to try 2x MSAA as well
01:57fdobridge: <redsheep> Yeah it's not like all the bugs magically went away, this session now gets heaven and valley flashing blue by default, and my Konsole seems to be doing a little bit of a rave party from time to time, flashing between the last two frames.
01:58fdobridge: <redsheep> Probably best not to merge something that defaults zink until some of that is ironed out, but none of that is new to this branch
01:58fdobridge: <Sid> alternatively, call it party mode and say it's always on to celebrate the release of the driver /j
01:58fdobridge: <Sid> :SCrainBowDance:
02:01fdobridge: <zmike.> really it needs a vk extension to allow querying the buffer to select the modifier, but that's SI
02:03fdobridge: <gfxstrand> I think plumbing modifiers is the better easy
02:03fdobridge: <gfxstrand> I think plumbing modifiers is the better way (edited)
02:09fdobridge: <zmike.> you can't really "plumb" modifiers for this
02:09fdobridge: <zmike.> it's implicit
02:11fdobridge: <gfxstrand> But why is it implicit?
02:11fdobridge: <gfxstrand> Or is this for ancient X11 nonsense?
02:12fdobridge: <zmike.> this is the first dmabuf extension
02:12fdobridge: <zmike.> the one that doesn't allow explicit modifier selection
02:12fdobridge: <zmike.> so the api says "gimme a dmabuf" and the driver is supposed to export a dmabuf with $modifier that the importer can then query and select the right modifier off
02:14fdobridge: <gfxstrand> I mean, if you just want INVALID to mean dealers choice, I can do that.
02:15fdobridge: <zmike.> it's not that either?
02:15fdobridge: <gfxstrand> But I thought old school dma-buf is more magic
02:15fdobridge: <zmike.> it is
02:15fdobridge: <zmike.> that's what I'm describing
02:15fdobridge: <zmike.> the driver uses a kernel interface to query the buffer and detect which modifier to use for import
02:15fdobridge: <gfxstrand> Yeah, I can do the more magic, too. It's not great but whatever.
02:15fdobridge: <zmike.> with INVALID, zink just selects the first valid modifier and yolos it on both export and import
02:16fdobridge: <zmike.> so if both ends are always zink+nvk then this should be fine in theory
02:16fdobridge: <gfxstrand> Right
02:16fdobridge: <zmike.> but then if you try to do something like multiple gpus probably you're screwed
02:16fdobridge: <zmike.> because it might choose a different modifier for different gpu gen
02:16fdobridge: <gfxstrand> Multiple GPUs are screwed without modifiers anyway
02:17fdobridge: <zmike.> oh tremendous
02:17fdobridge: <zmike.> then it might work out
02:17fdobridge: <zmike.> conceptually anyway
02:18fdobridge: <redsheep> I am not using multiple gpus
02:19fdobridge: <redsheep> Unless something is broken with NOUVEAU_USE_ZINK=1 absolutely everything on my system should be nvk and zink
02:19fdobridge: <zmike.> you're holding it wrong probably
02:21fdobridge: <redsheep> Let me try MESA_LOADER_DRIVER_OVERRIDE=zink instead
02:23fdobridge: <redsheep> Yeah no change, it flashes a corrupt desktop a few times and then gives up and goes back to sddm
02:24fdobridge: <gfxstrand> Are there any tests for this back door?
02:28fdobridge: <redsheep> I don't think I am holding it wrong, glxinfo and vulkaninfo all show the right commit
02:30fdobridge: <redsheep> I wonder how hard it would be to patch kwin to not use the implicit selection. I can't imagine it would be huge, but it's probably pointless since that ideally should be able to work if people are using it
02:31fdobridge: <gfxstrand> It may not be possible if there's enough X11 in the way
02:31fdobridge: <gfxstrand> Or maybe it needs modifiers? 🤷🏻♀️
02:32fdobridge: <redsheep> Not certain which message you are responding to, but plasma x11 is certainly helped by working modifiers considering it fixed the performance
02:33fdobridge: <zmike.> the test is to run all the piglit dmabuf tests
02:34fdobridge: <zmike.> if they pass you're probably good
02:34fdobridge: <gfxstrand> Okay. That's probably doable
02:34fdobridge: <zmike.> really nothing should use this path anymore
02:35fdobridge: <zmike.> dri3 exists with explicit modifier selection
02:35fdobridge: <zmike.> if you're using a modern piece of software and you see that error, file a ticket with the app
02:45fdobridge: <redsheep> I tried to find something about the state of this in kwin wayland, and I found this issue: https://invent.kde.org/plasma/kwin/-/issues/139
02:46fdobridge: <redsheep> So with 6.2 they seem to be planning a split that would include not even using dri3, let alone dri2, if I am reading this right.
02:47fdobridge: <redsheep> Not sure if that interpretation even makes sense, there was very little mention of that part
02:56fdobridge: <redsheep> Oh there's also this https://invent.kde.org/plasma/kwin/-/issues/92
03:01fdobridge: <zmike.> yep that'll do it
03:02fdobridge: <redsheep> They claim all that code is already merged though, long ago
06:11fdobridge: <airlied> haven't tested it yet, but did a f40/rawhide v24.1-rc3 build with modifiers and nvk/zink defaulted on for turing+ https://copr.fedorainfracloud.org/coprs/airlied/mesa-nvk/build/7428248/
06:23fdobridge: <Sid> the things I do for testing
06:23fdobridge: <Sid> `[sidpr@constructor ~]$ sudo pacman -S plasma gnome`
06:24fdobridge: <Sid> make that
06:24fdobridge: <Sid> plasma-desktop and gnome-shell
06:24fdobridge: <Sid> because I really want minimal environments I can test in and uninstall .-.
06:25fdobridge: <Sid> :wolfFIRE:
08:06fdobridge: <Sid> I tried to start a session on ziNVK without NVK installed
08:06fdobridge: <Sid> < so smart
08:06fdobridge: <Sid> :clueless:
08:32fdobridge: <Sid> okay, getting any kind of logs out of this is gonna be painful, I'll do it when I'm in the mood to screw around my systen
09:00karolherbst: Lyude: okay, apparently it's a thing that some users get a broken edid: https://gitlab.freedesktop.org/drm/nouveau/-/issues/356
09:45fdobridge: <mohamexiety> welp, ~ 10 hours of memtest later, no errors. so RAM should be fine. CPU is also fine at both sustained heavy and light workloads, so I wonder if that ICE popped up due to improper LLC default from the motherboard (motherboard essentially undervolting the CPU). compiler work is transient heavy so it'd make sense to expose something like this
09:45fdobridge: <mohamexiety> this is reassuring at least
09:46fdobridge: <karolherbst🐧🦀> @gfxstrand using any static inline functions on the rust side? I'm going to cleanup and merge https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/25265 soonish, so I'll bump to meson 1.4 and bindgen 0.65
09:48fdobridge: <mohamexiety> oo, static inline now being generateable is really nice and convenient
09:49fdobridge: <karolherbst🐧🦀> yeah
09:49fdobridge: <karolherbst🐧🦀> it's an "experimental" feature in bindgen but they don't seem to break the interface so far
09:52fdobridge: <karolherbst🐧🦀> but like.. it's literally doing the same I've done more or less
09:52fdobridge: <karolherbst🐧🦀> just being smarter about it
09:53fdobridge: <karolherbst🐧🦀> they use `link_name` in the generated rust file
09:53fdobridge: <karolherbst🐧🦀> and append `__extern`
09:54fdobridge: <karolherbst🐧🦀> but anyway, the nice meson integration makes it really nice to use 🙂
10:11fdobridge: <marysaka> oh that's awesome
12:05fdobridge: <gfxstrand> We're not using that right now, no. The like 3 things NIL needed I just reimplemented. For NAK and NIR, I almost always wanted something different and more rusty anyway.
12:28fdobridge: <karolherbst🐧🦀> yeah, entirely fair
12:30fdobridge: <gfxstrand> A lot of the NIR ones exist so we can assert things. The Rust wrappers I made return `Option<_>` instead.
12:36fdobridge: <karolherbst🐧🦀> yeah.. fair
12:37fdobridge: <karolherbst🐧🦀> I just need a lot of those `glsl_type` things
12:37fdobridge: <karolherbst🐧🦀> though... could probably also just inline the code
12:38fdobridge: <karolherbst🐧🦀> but I kinda want to stick with the interface and not make it painful to rework things later
12:55fdobridge: <gfxstrand> Yeah, probably for the best there.
12:56fdobridge: <gfxstrand> The one that really annoyed me was `drm_fourcc()` which is all function-like macros. 🤦🏻♀️
12:57fdobridge: <gfxstrand> In the end, I said "this is all fixed in stone. I can just reimplement."
12:57fdobridge: <karolherbst🐧🦀> yeah
13:02fdobridge: <gfxstrand> IDK what we'll do about ioctls when the time comes. Those I want to pull from headers.
13:02fdobridge: <karolherbst🐧🦀> use the `libc` crate?
13:02fdobridge: <gfxstrand> I may have to write my own parser of some sort.
13:03fdobridge: <gfxstrand> Honestly, you can probably run the C preprocessor on rust code... Oh, this is cursed...
13:03fdobridge: <karolherbst🐧🦀> heh
13:03fdobridge: <karolherbst🐧🦀> I used php once as a preprocessor in C :ferrisUpsideDown:
13:05fdobridge: <gfxstrand> So, yeah. You have a rust file which has a `#include` at the top and a bunch of `const FOO: u32 = MACRO;` and then run cpp on it. 🤔 You'd have to postprocess somehow up strip out any structs it defines but that could be done.
13:05fdobridge: <gfxstrand> Thanks, I hate it.
13:05fdobridge: <karolherbst🐧🦀> that exists already I think
13:07fdobridge: <karolherbst🐧🦀> @gfxstrand https://github.com/zdimension/embed-c
13:08fdobridge: <karolherbst🐧🦀> `C2Rust` is just cursed
13:08bencoh: o.O
13:23fdobridge: <mohamexiety> huh I didnt know this was possible o_o
13:52fdobridge: <babblebones> Neat, also spooky
14:02fdobridge: <gfxstrand> It's very unclear what that would actually look like when you need to define constants, invoke macros, etc.
14:37fdobridge: <karolherbst🐧🦀> people parse SQL queries in proc macros and make sure it's all valid
16:03Lyude: karolherbst: thank you for reminding me - I'll tty taking a look at that asap
16:13fdobridge: <gfxstrand> Just installed on my desktop and it's rebooting now. Soon we'll see just how much of a mess this is. 😅
16:16fdobridge: <redsheep> Do you use the discord app? I'm curious if you will see the icon corruption
16:18fdobridge: <redsheep> Provided mutter is using explicit modifiers I would expect it just to work, my x11 session was solid
16:18fdobridge: <redsheep> Aside from the usual zink bugs that you can replicate on a normal session
16:22fdobridge: <gfxstrand> No, I just have discord in FF
16:22fdobridge: <gfxstrand> And I'm not running any of that on my laptop where I do actual work.
16:23fdobridge: <redsheep> Fair, though you could install the flatpak of you want to avoid infesting your system with gamerness
16:23fdobridge: <gfxstrand> Well, this is entertaining... I'm getting X11 and not Wayland in my session now. 😬
16:23fdobridge: <Sid> and then there's me, running code to test on my only machine e-e
16:24fdobridge: <Sid> like, filesystem code at that
16:24fdobridge: <gfxstrand> Oh, that's probably because that copr has 24.1-rc3 and not my branch
16:25fdobridge: <gfxstrand> Still, should have reasonable Zink
16:25fdobridge: <redsheep> Maybe it's not a plasma issue causing Wayland to fail then? And yeah before and after that branch I got the same result with Wayland
16:26fdobridge: <redsheep> The only think that changes behavior was your later patch for invalid
16:30fdobridge: <redsheep> Best as I could figure after a few more hours of digging into kwin I think we're somehow ending up in a fallback we should not be. Kwin is not supposed to use implicit modifiers
16:38soreau: gfxstrand: does 'reasonable zink' mean doesn't require modifiers?
16:38HdkR: t/15
16:40fdobridge: <gfxstrand> I mean it's got lots of bugs fixed
16:48fdobridge: <zmike.> an average day in zink
17:18fdobridge: <gfxstrand> Oh, good... We have a use-after-free in Zink when it's used for XWayland.
17:19fdobridge: <zmike.> @gfxstrand I'm testing my new parallel conformance script and I think it might actually work
17:21fdobridge: <zmike.> it's for sure slower than my deqp-runner splitter script, but it does theoretically generate a legitimate output that can be used for a submission package
17:22fdobridge: <gfxstrand> More specifically, Zink is calling `GetMemoryFdKHR` on destroyed memory objects. Either that or we've got a crazy stack smash going on. Use-after-free seems more likely.
17:22fdobridge: <zmike.> 🤔
17:23fdobridge: <zmike.> that seems like a problem in the frontend if it's happening
17:23fdobridge: <gfxstrand> Yeah, it feels really unlikely
17:23fdobridge: <gfxstrand> Refcounting bug, maybe?
17:23fdobridge: <zmike.> also feels very unlikely
17:24fdobridge: <zmike.> I've never seen it though, so who knows
17:41fdobridge: <zmike.> https://gist.github.com/zmike/e8eec8fdb6eb1d264828b2affede993b
17:44fdobridge: <zmike.> this should generate all the same files you'd get from using cts-runner normally
17:44fdobridge: <zmike.> and the resulting package should pass verification
17:44fdobridge: <zmike.> ...I think
17:47fdobridge: <zmike.> cc @airlied if you want to test for llvmpipe^
17:47fdobridge: <zmike.> looks like it'll take about an hour on a 32 core machine on radv
17:51fdobridge: <gfxstrand> Is that going to be an officially valid way to run CTS?
17:52fdobridge: <zmike.> yes, the WG agreed on it yesterday
17:52fdobridge: <zmike.> I just have to update the official documentation
17:53fdobridge: <zmike.> the idea is that as long as you run the commands output by `cts-runner` directly then your submission is valid regardless of how many processes/machines you split it across
17:53fdobridge: <gfxstrand> cool
17:53fdobridge: <zmike.> but sharding those caselists is not currently permitted
17:54fdobridge: <zmike.> ooof radv fails so many of these
17:58fdobridge: <zmike.> testing on nvk now to hopefully get something that can actually pass for verification...
17:59fdobridge: <gfxstrand> The plot thickens! `PRIME_HANDLE_TO_FD` returns `-EBADF` which should only happen if the DRM file has been closed.
17:59fdobridge: <zmike.> https://media.giphy.com/media/CaiVJuZGvR8HK/giphy.gif
18:02fdobridge: <gfxstrand> It's happening in `zink_screen_export_dmabuf_semaphore`
18:03fdobridge: <zmike.> sounds bad?
18:03fdobridge: <zmike.> but also it should be impossible for a dead resource to reach that point
18:04fdobridge: <gfxstrand> There's a lot of load-bearing "should"s going on. 😅
18:04fdobridge: <zmike.> I mean the function would explode elsewhere if that weren't true
18:05fdobridge: <zmike.> argh I made a new build dir and I'm getting rust errors again
18:05fdobridge: <zmike.> I hate build systems
18:05fdobridge: <gfxstrand> It's coming from `zink_resource_image_barrier()`
18:06fdobridge: <zmike.> yes
18:06fdobridge: <gfxstrand> I wish I knew how to attach a debugger to this disaster
18:06fdobridge: <zmike.> file:line always works
18:07fdobridge: <!DodoNVK (she) 🇱🇹> This should help then: https://www.youtube.com/watch?v=7_DExGdUw7w
18:11fdobridge: <zmike.> hm well the runner works but nvk isn't passing here
18:11fdobridge: <zmike.> GOOD ENOUGH
18:11fdobridge: <Sid> 🚢
18:11fdobridge: <Sid> ship it
18:21fdobridge: <airlied> The copr should have debug info bits I think, or do you mean gnome shell?
18:22fdobridge: <airlied> I have a hacky mutter debug, go to rl3. Login to a vt, run screen, run gdb --args mutter --display-server --wayland
18:23fdobridge: <airlied> Then connect to the screen and use it
18:25fdobridge: <gfxstrand> Yeah, we've definitely got a use-after-free going on. I've got GDB broken at the segfault.
18:31fdobridge: <zmike.> WOW
18:31fdobridge: <zmike.> idk if you've tried out that sparse cts split CL recently
18:31fdobridge: <zmike.> but I can do an all-versions GL run in deqp-runner now in under 30s
18:31fdobridge: <zmike.> unreal
18:31fdobridge: <zmike.> this has to be a mistake...
18:33fdobridge: <zmike.> ok yeah it's a mistake
18:33fdobridge: <zmike.> damn
18:39fdobridge: <zmike.> under 2:30 now though, which is a definite improvement
18:46fdobridge: <gfxstrand> Ugh... All the Zink reference counts look sane but my nvk_device_memory is definitely trash
18:48fdobridge: <!DodoNVK (she) 🇱🇹> ~~Winter should double-check that though just in case~~
18:54fdobridge: <zmike.> @gfxstrand what does the backtrace look like
19:21fdobridge: <gfxstrand> https://cdn.discordapp.com/attachments/1034184951790305330/1238209231631683594/bt_full?ex=663e73b5&is=663d2235&hm=b4f770bf102220ccb395b62d02bfce998bdea3858a3334c615abc1046e95c7b5&
19:21fdobridge: <zmike.> huh
19:21fdobridge: <zmike.> normal enough
19:28fdobridge: <gfxstrand> Yeah, there's nothing obvious in there
19:29fdobridge: <gfxstrand> But my BO is definitely trashed
19:29fdobridge: <gfxstrand> I'm gonna memset some stuff to zero on destroy...
19:31fdobridge: <gfxstrand> I guess it's theoretically possible I have a BO refcount bug in nouveau.
19:31fdobridge: <gfxstrand> That'd be a bit crazy
19:31fdobridge: <gfxstrand> But totally possible with import/export
19:32fdobridge: <gfxstrand> Damn! I do...
19:36fdobridge: <gfxstrand> That's my 4th Zink-found NVK bug, I think.
19:36fdobridge: <zmike.> dear diary
19:36fdobridge: <zmike.> today was a good day.
19:36fdobridge: <gfxstrand> But who's counting? 😉
19:43fdobridge: <gfxstrand> https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/28843/diffs?commit_id=b3c133ab4541e4bb47a2c4a8da4e27f06d9fef79 for those following along at home.
19:44fdobridge: <gfxstrand> Yeah, with that Xwayland feels pretty solid. 🎉
19:47fdobridge: <airlied> I will rebuild the copr in a bit
19:50fdobridge: <airlied> I feel like I'd want to ship 24.1 with zink and modifiers enabled if I can in F41 at least, not sure about f40
19:50fdobridge: <airlied> But F41 will have 24.2 anyways
19:52fdobridge: <gfxstrand> Yeah.
19:52fdobridge: <gfxstrand> I'm thinking of back-porting the modifiers branch to 24.1
19:53fdobridge: <gfxstrand> But that means we need to get it reveiwed and the kernel bits merged ASAP
20:08fdobridge: <gfxstrand> I'm going to re-try gles with that patch. I bet I'll pass the EGL tests now. 😅
20:14fdobridge: <gfxstrand> Nope!
20:18fdobridge: <airlied> copr is rebuilding onw
20:19fdobridge: <gfxstrand> Cool
20:20fdobridge: <gfxstrand> Building from my branch? Because I don't think the old one did.
20:21fdobridge: <airlied> not from the branch, from that patch on top of 24.1
20:21fdobridge: <airlied> well the whole MR diff on top of 24.1
20:21fdobridge: <gfxstrand> I'm going to try running them with only one GPU in the machine. Multi-GPU seems to be problematic and that may be why EGL is falling over.
20:22fdobridge: <gfxstrand> @mohamexiety I left a comment on your kernel patch. Please fix and re-send and I'll RB it.
20:28fdobridge: <gfxstrand> @mohamexiety Also, please update the MR link to the original one: https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/24795
20:28fdobridge: <mohamexiety> woops, didn't see that one, sorry. on it
20:28fdobridge: <mohamexiety> got it
20:29fdobridge: <gfxstrand> No particular reason but I needed to close one and figured it was better to use the original now that I've taken it back over.
20:29fdobridge: <gfxstrand> Thanks a bunch for your work rebasing!
20:34fdobridge: <!DodoNVK (she) 🇱🇹> How is VK_EXT_queue_family_foreign related to the modifier work?
20:40fdobridge: <gfxstrand> Yeah, it's basically part of the modifiers extension
20:42fdobridge: <dwlsalmeida> @karolherbst Hey, do you mind if we get back to this? Not sure I get this still, is 1inc only a thing for array methods?
20:42fdobridge: <dwlsalmeida> @marysaka Mary do you know something about this? Since you wrote the dump tool I assume you can help?
20:43fdobridge: <dwlsalmeida> Note that I am running the whole CTS with a breakpoint here:
20:43fdobridge: <dwlsalmeida>
20:43fdobridge: <dwlsalmeida> else if (is_1inc)
20:43fdobridge: <dwlsalmeida> distance = MIN2(1, distance); <---------
20:43fdobridge: <dwlsalmeida>
20:43fdobridge: <dwlsalmeida> Apparently this line is never hit
20:44fdobridge: <dwlsalmeida> I wonder what exactly is being incremented then, if distance==0 always
20:45fdobridge: <mohamexiety> done for both
20:46fdobridge: <mohamexiety> and yeah sorry about that. I basically couldn't do the rebase the "traditional" way so I just branched from `main` and cherry-picked/rewrote commits manually but then didn't know how to push it back to the original branch :blobcatnotlikethis:
20:49fdobridge: <gfxstrand> That's okay. You did fine.
20:49fdobridge: <gfxstrand> Thanks!
20:50fdobridge: <gfxstrand> @airlied, @karolherbst Can I get one or both of you to RB https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/24795 ? Ideally both given how dicy all this is. I need a review for UAPI reasons but I'd also like some sign-off on the plan laid out at the top of the MR so it's not just me who gets blamed with the bugs. 😅
21:01fdobridge: <gfxstrand> @airlied We've basically got the week-end if we want to push this in to rc4. I think we can probably do that.
21:06fdobridge: <gfxstrand> IDK how much I'll have to back-port, though.
21:06fdobridge: <gfxstrand> Probably not much. The first RC was only cut a few weeks ago and I've been traveling.
21:07fdobridge: <dwlsalmeida> @karolherbst ah, I think I get this, so here:
21:07fdobridge: <dwlsalmeida>
21:07fdobridge: <dwlsalmeida> ```
21:07fdobridge: <dwlsalmeida> P_1INC(p, NV9097, CALL_MME_MACRO(NVK_MME_DRAW));
21:07fdobridge: <dwlsalmeida> P_INLINE_DATA(p, begin);
21:07fdobridge: <dwlsalmeida> P_INLINE_DATA(p, 0 /* draw_idx */);
21:07fdobridge: <dwlsalmeida> P_INLINE_DATA(p, vertexCount);
21:07fdobridge: <dwlsalmeida> P_INLINE_DATA(p, instanceCount);
21:07fdobridge: <dwlsalmeida> P_INLINE_DATA(p, firstVertex);
21:07fdobridge: <dwlsalmeida> P_INLINE_DATA(p, firstInstance);
21:07fdobridge: <dwlsalmeida> ```
21:07fdobridge: <dwlsalmeida>
21:07fdobridge: <dwlsalmeida> First one is CALL_MME_MACRO, then all others count against the subsequent one, CALL_MME_DATA, right?
21:09fdobridge: <gfxstrand> Sort-of? There are some methods which take inline data. `CALL_MME_MACRO()` is one example. The data that follows on the command stream isn't so much additional methods as just data.
21:11fdobridge: <gfxstrand> There's a few others such as `LOAD_CONSTANT_BUFFER` and the various inline DMAs that work similarly.
21:11fdobridge: <gfxstrand> That's why you're seeing a bunch of `CALL_MME_DATA(2)`
21:11fdobridge: <gfxstrand> @dwlsalmeida ^^
21:13fdobridge: <airlied> the MR diff applies pretty cleanly to rc3
21:17fdobridge: <dwlsalmeida> @gfxstrand my point being, given what Karol said:
21:17fdobridge: <dwlsalmeida>
21:17fdobridge: <dwlsalmeida> > the inc just means how often the "method" gets increased, like 1inc means that the first value is against the initial mehtod, the second and subsequent against the next (useful for those INLINE_DATA methods, where the first is e.g. the size and the next the data), ninc just increases with each value and 0inc never
21:17fdobridge: <dwlsalmeida> >
21:17fdobridge: <dwlsalmeida>
21:17fdobridge: <dwlsalmeida> Then, this align with the example shown, because the dump first shows CALL_MME_MACRO, then CALL_MME_DATA (which is right below it in the header)
21:20fdobridge: <gfxstrand> Yes
21:21fdobridge: <gfxstrand> So 1inc means `CALL_MME_MACRO` and then as many `CALL_MME_DATA` as needed.
21:21fdobridge: <gfxstrand> 0inc, on the other hand, means the first one repeated as many times as needed.
21:23fdobridge: <gfxstrand> I don't think we're using 0INC anywhere right now
21:24fdobridge: <gfxstrand> I'll be using it all over everywhere soon when I start doing more inline constant data
21:29fdobridge: <gfxstrand> Wow, it's been a while since I ran piglit...
21:38fdobridge: <dwlsalmeida> @gfxstrand I assume this is done by the HW automatically, right? When you set the bits for 1INC, it derives how many times to call the subsequent method from the `size` variable that was passed in?
21:39fdobridge: <dwlsalmeida> seems like it anyways
21:39fdobridge: <dwlsalmeida> ok this is finally making a lot of sense lol
21:43fdobridge: <gfxstrand> yes
22:41fdobridge: <gfxstrand> @zmike. `egl_image_dma_buf*` pass with that hack.
22:47fdobridge: <zmike.> nice
22:47fdobridge: <zmike.> then I guess nvk is one of the chosen few
22:49fdobridge: <redsheep> @gfxstrand Do you want me to test again with the new changes? Are you expecting that to fix the plasma wayland session, since it fixed gnome for you?
22:50fdobridge: <gfxstrand> Please. I think most stuff should be fixed now
22:50fdobridge: <redsheep> Are you planning to try to get 24.1 set to default zink on?
22:50fdobridge: <gfxstrand> I'm not sure if I want to go that far but I at least want GameScope to work and I want NVK+Zink to be an option in 24.1.
22:51fdobridge: <redsheep> No new kernel changes, correct? I don't see anything obviously new with your branch
22:51fdobridge: <samantas5855> How does Zink fare compared to Nouveau
22:52fdobridge: <samantas5855> for running a desktop environment like KDE or Gnome
22:52fdobridge: <redsheep> As of just now it should work and in many cases it is more performant, however there are also some zink specific bugs
22:52fdobridge: <redsheep> It's not like the nouveau gl driver is bug free though
22:53fdobridge: <samantas5855> What kind of bugs
22:53fdobridge: <samantas5855> Freezes?
22:53fdobridge: <samantas5855> Graphical glitches?
22:53fdobridge: <gfxstrand> Correct
22:54fdobridge: <redsheep> No freezes, just trippy stuff here and there. MSAA related flicker, weird UI corruption in discord, that kind of thing
22:58fdobridge: <redsheep> If there's room tomorrow and this weekend it would be cool to see if it's possible to squeeze some last minute fixes in for those to get zink on more equal footing
22:58fdobridge: <redsheep> I would be happy to provide whatever testing I can, and debugging what I know how to.
22:58fdobridge: <redsheep> I can get captures of the msaa issue in heaven at will
23:00fdobridge: <redsheep> It's entirely possible both issues are the same bug, given UI rendering probably involves msaa
23:11fdobridge: <redsheep> Well, my plasma x11 session segfaulted. This was something I did actually see yesterday too.
23:11fdobridge: <redsheep>
23:11fdobridge: <redsheep> ```[ 667.038196] plasmashe:zfq0[31798]: segfault at 0 ip 00007f217d298c03 sp 00007f215fdff1c0 error 4 in libvulkan_nouveau.so[7f217d25c000+578000] likely on CPU 30 (core 14, socket 0)
23:11fdobridge: <redsheep> [ 667.038205] Code: ff 4d 8b 73 18 49 c1 e5 02 4c 89 85 f0 f7 ff ff 44 8b 8d 30 f8 ff ff 4c 8b 95 18 f8 ff ff 66 0f 1f 84 00 00 00 00 00 44 89 c8 <4d> 8b 04 77 31 ff 48 8d 04 40 48 c1 e0 04 4c 01 d0 4d 85 e4 74 04```
23:13fdobridge: <redsheep> It seems to generally happen shortly after logging in, and then it will be fairly stable again for a few hours
23:15fdobridge: <redsheep> Also something notable, the icon corruption is very rare, unless you put the system under load, in which case it is immediate.
23:18fdobridge: <redsheep> I think the flicker in Konsole is gone now, or at least I can't replicate it anymore
23:21fdobridge: <redsheep> Hmm the plasma Wayland session still isn't quite there, instead of repeating a corrupt screen over and over it's just once, and then stuck on a black screen with a cursor. Nothing in dmesg.
23:26fdobridge: <redsheep> I can confirm gamescope works on NVK+zink plasma x11, as well as nvc0 plasma x11
23:27fdobridge: <redsheep> Unfortunately, plasma Wayland on nvc0 is resulting in a frozen game. Again, no dmesg.
23:28fdobridge: <redsheep> Plasma Wayland on nvc0 also results in a currupt cursor after a few moments. Has anyone been running this configuration to know if this was broken before?
23:32fdobridge: <redsheep> @gfxstrand ^ results. Not sure what else to test, if anything.
23:36fdobridge: <redsheep> IIRC corrupt cursor with nvc0 on the plasma wayland session is not new, but I dismissed it months ago as plasma wayland being buggy. In that time plasma wayland has become pretty stable for almost everything else though.
23:37fdobridge: <gfxstrand> Ugh...
23:41fdobridge: <redsheep> How can I help? I am down to do a call to get to the bottom of it more rapidly, or to just leave it and not bother you with it again