17:21fdobridge: <gfxstrand> I've verified this, sort-of. Running the compositor and old GL driver under GDB, I can see that it gets `tile_mode = 0` and `tile_flags = 0` from nouveau.ko so it's seeing a linear buffer. I don't know where those flags are getting thrown away yet.
17:24fdobridge: <gfxstrand> When I run gears from the same GPU, I get the same flags.
17:25fdobridge: <gfxstrand> Just so we're all clear, I'm fine with the multi-GPU case not working correctly with old-school nouveau GL.
18:37fdobridge: <dwlsalmeida> hey, anybody care to educate me on the differences between the method types, i.e.: ninc vs 0inc vs 1inc etc?
18:37fdobridge: <dwlsalmeida> hey, could somebody please educate me on the differences between the method types, i.e.: ninc vs 0inc vs 1inc etc? (edited)
18:39fdobridge: <dwlsalmeida> is this just about how the command is laid out in the push, or are there other implications I should be aware of?
18:42fdobridge: <karolherbst🐧🦀> 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
18:45fdobridge: <dwlsalmeida> I have a simple dump here:
18:45fdobridge: <dwlsalmeida>
18:45fdobridge: <dwlsalmeida> [0x00000000] HDR 20016000 subch 3 NINC
18:45fdobridge: <dwlsalmeida> mthd 0000 NV906F_SET_OBJECT
18:45fdobridge: <dwlsalmeida> .NVCLASS = (0x902d)
18:45fdobridge: <dwlsalmeida> .ENGINE = 0x0
18:45fdobridge: <dwlsalmeida>
18:45fdobridge: <dwlsalmeida> [0x00000002] HDR 20010000 subch 0 NINC
18:45fdobridge: <dwlsalmeida> mthd 0000 NV906F_SET_OBJECT
18:45fdobridge: <dwlsalmeida> .NVCLASS = (0xc797)
18:45fdobridge: <dwlsalmeida> .ENGINE = 0x0
18:46fdobridge: <dwlsalmeida> so NINC here means "0000" remains "0000" for both values?
18:56fdobridge: <gfxstrand> No, we check if it's the same device. drm_prime.c:921
18:56fdobridge: <gfxstrand> Okay, that mystery is solved.
18:56fdobridge: <gfxstrand> Or at least partly solved.
18:58fdobridge: <gfxstrand> And... verified that running the compositor with NVK+Zink fixes the tiling corruption right up until we get that fence timeout
18:58fdobridge: <gfxstrand> Good. So I'm not crazy. That's always a good starting point.
19:00fdobridge: <karolherbst🐧🦀> no, it would increase per pushed value, but both of those only push one value in the first place
19:18fdobridge: <gfxstrand> Hrm... Sometimes it's a timeout and sometimes it's a MMU fault
21:25fdobridge: <gfxstrand> @prop_energy_ball I'm finally looking into this explicit sync issue.
21:25fdobridge: <gfxstrand> It looks like no one is ever signaling the timeline so it's just sitting there in `WAIT_PENDING` forever.
21:25fdobridge: <gfxstrand> I'm digging through Mutter code now
21:31fdobridge: <Misyl with Max-Q Design> Probably worth smoke testing with gamescope as a session too? I at least know that code in and out and it's a lot simpler
21:36fdobridge: <gfxstrand> I think the problem is that it assumes EGL extensions which nouveau GL doesn't support
21:36fdobridge: <gfxstrand> Now I just need to dig through EGL specs to figure out which ones
21:39fdobridge: <gfxstrand> Yeah, it depends on EGL_ANDROID_native_fence_sync and never checks for it.
21:39fdobridge: <gfxstrand> I'll file a Mutter bug
21:41fdobridge: <gfxstrand> Of course the GNOME GitLab instance is going to deadname me... 🤦🏻♀️
21:46fdobridge: <gfxstrand> https://gitlab.gnome.org/GNOME/mutter/-/issues/3475
21:49fdobridge: <gfxstrand> Would someone more adventurous than me like to try out GNOME Shell running on NVK+Zink with the modifiers branch. I think it should be fine on Zink. We should support sync_fd export there.
21:49fdobridge: <gfxstrand> Would someone more adventurous than me like to try out GNOME Shell running on NVK+Zink with the modifiers branch? I think it should be fine on Zink. We should support sync_fd export there. (edited)
22:01fdobridge: <airlied> @gfxstrand do we expose that EGL ext on mesa at all?
22:02fdobridge: <airlied> seems surprising mutter would depend on a non-mesa feature
22:02fdobridge: <gfxstrand> We do
22:02fdobridge: <gfxstrand> Iris exposes it on my laptop
22:03fdobridge: <gfxstrand> Zink+NVK has it
22:03fdobridge: <gfxstrand> Just no old-school nouveau
22:04fdobridge: <gfxstrand> It'd be implementable in old-school nouveau if we really cared but that doesn't fix the issue of users who have an old GL driver installed seeing explicit sync blow up
22:05fdobridge: <airlied> that seems less of a problem since explicit sync is a fairly new mutter feature
22:05fdobridge: <airlied> so it's likely if we could fix nouveau it would just be fine
22:05fdobridge: <airlied> should mutter just not expose explicit sync with that ext?
22:06fdobridge: <gfxstrand> Yeah
22:06fdobridge: <gfxstrand> I could probably type the patch but I'm not set up to actually test it.
22:06fdobridge: <gfxstrand> It's like 3 lines of code
22:07fdobridge: <airlied> I've "escalated" it
22:08fdobridge: <gfxstrand> Thanks!
22:08fdobridge: <gfxstrand> Should take Jonas or similar like 5 minutes
22:09fdobridge: <!DodoNVK (she) 🇱🇹> I don't think Mutter calls that ANDROID function call though
22:09fdobridge: <gfxstrand> It does
22:10fdobridge: <gfxstrand> Just search for `DupNativeFenceFD`
22:16fdobridge: <gfxstrand> @airlied One more question to answer before I think things are in decent shape: Should I use the newly added query? Or should we drop the query from the kernel patch? I'm happy to go either way. I generally like having queries for things. I just didn't know it was there when I typed the patch.
22:20fdobridge: <airlied> I'd go with the query, seems like a good plan to use them
22:20fdobridge: <gfxstrand> Okay. I'll fix that up quick
22:24fdobridge: <gfxstrand> Ugh... We seem to have deleted too much stuff from the uapi header again. 😩
22:26fdobridge: <karolherbst🐧🦀> what do you mean?
22:26fdobridge: <gfxstrand> I tried to sync the header and the build failed
22:26fdobridge: <karolherbst🐧🦀> oh no
22:26fdobridge: <gfxstrand> channel alloc stuff
22:26fdobridge: <karolherbst🐧🦀> I know that I recently added stuff...
22:26fdobridge: <gfxstrand> Maybe I need to rebase?
22:27fdobridge: <karolherbst🐧🦀> yeah.. probably
22:27fdobridge: <karolherbst🐧🦀> maybe I screwed up
22:27fdobridge: <gfxstrand> Okay, I won't sweat it then
22:27fdobridge: <karolherbst🐧🦀> but I've added things on the kenrel side, because I started using them after the libdrm import explicitly
22:27fdobridge: <karolherbst🐧🦀> or rather.. they weren't in the uapi header
22:28fdobridge: <karolherbst🐧🦀> ahh yeah
22:28fdobridge: <karolherbst🐧🦀> it's not in linus' tree yet
22:28fdobridge: <karolherbst🐧🦀> @gfxstrand https://cgit.freedesktop.org/drm/drm-misc/commit/?id=460be1d527a8e296d85301e8b14923299508d4fc
22:28fdobridge: <karolherbst🐧🦀> unless you meant something else
22:29fdobridge: <gfxstrand> Yup! Those are the ones.
22:29fdobridge: <karolherbst🐧🦀> yeah.. still sitting in drm-misc
22:30fdobridge: <gfxstrand> That's fine. I'll scrape the header form drm-misc before merging anyway
22:30fdobridge: <gfxstrand> *from
22:36fdobridge: <gfxstrand> And... as usual, nothing gets sent to dri-devel that I actually care about makes it's way to my e-mail inbox so I can't review the kernel patch. 🤦🏻♀️
22:37fdobridge: <airlied> don't think it's been sent to a list yet
22:38fdobridge: <gfxstrand> https://lore.kernel.org/dri-devel/20240430155453.21132-1-mohamedahmedegypt2001@gmail.com/T/#u
22:38fdobridge: <gfxstrand> @mohamexiety Mind switching the RFC to PATCH and sending again? Also, you might want to line wrap that commit message.
22:39fdobridge: <gfxstrand> I apparently wasn't subscribed to dri-devel
22:39fdobridge: <airlied> probably also add nouveau lsit
22:39fdobridge: <gfxstrand> In theory, that's fixed now.
22:39fdobridge: <mohamexiety> sure! but what do you mean with line wrap?
22:39fdobridge: <airlied> and a pointer to the mesa MR which has been reviewied
22:39fdobridge: <airlied> (or is in the process), and I do wonder if we should add cc: stable
22:40fdobridge: <airlied> oh an sob of course 🙂
22:41fdobridge: <mohamexiety> I made a special mental note for the sob but I still forgot it for v2 lol
22:41fdobridge: <karolherbst🐧🦀> you should use checkpatch because it points those things out
22:41fdobridge: <gfxstrand> The Mesa MR hasn't been reviewed. 😛
22:41fdobridge: <karolherbst🐧🦀> `./scripts/checkpatch.pl`
22:42fdobridge: <mohamexiety> ok so, drop the "RFC", link to the mesa MR, signed off by. what do you mean with stable/nouveau list?
22:42fdobridge: <mohamexiety> TIL this exists, thanks!
22:43fdobridge: <gfxstrand> I've dropped all the WIP and HACK from the NVK MR so it's ready for real review.
22:43fdobridge: <gfxstrand> As of today, I've convinced myself that all the nonsense I've been seeing is either unfixable old GL garbage or extant kernel bugs.
22:44fdobridge: <karolherbst🐧🦀> fair conclusion tbh
22:44fdobridge: <!DodoNVK (she) 🇱🇹> Do I need to wrap it in an unsafe block? :ferris:
22:45fdobridge: <airlied> I think since this fixes the original uapi it should probably add a Fixes: b88baab82871 ("drm/nouveau: implement new VM_BIND uAPI")
22:45fdobridge: <airlied> @mohamexiety just when sending it include nouveau@lists.freedesktop.org on the cc as well as dri-devel
22:45fdobridge: <karolherbst🐧🦀> so I guess the next step after all that's done on the nvk side, is to move GL to VM_BIND and make it my problem to fix it in a way that works?
22:45fdobridge: <airlied> I think next step might be making sync fd work on nvc0
22:46fdobridge: <karolherbst🐧🦀> mhhh
22:46fdobridge: <airlied> so when we merge this do we set nvc0 to recommend zink on everything nvk supports?
22:46fdobridge: <karolherbst🐧🦀> wouldn't that be easier with VM_BIND?
22:46fdobridge: <karolherbst🐧🦀> and syncobjs?
22:46fdobridge: <mohamexiety> alright, got it
22:47fdobridge: <airlied> @karolherbst it might be, but not sure it's necessary to all the way for just sync fd (though I've no idea)
22:47fdobridge: <karolherbst🐧🦀> yeah.....
22:47fdobridge: <karolherbst🐧🦀> I have no idea tbh
22:48fdobridge: <gfxstrand> As long as you fix nvc0 to implement modifiers properly as part of the process, there shouldn't be any issues.
22:48fdobridge: <gfxstrand> What I've done should be forwards-compatible.
22:48fdobridge: <karolherbst🐧🦀> I'm just reluctant moving to zink, because regressions, however I trust zink more than the nvc0 driver
22:48fdobridge: <gfxstrand> There is just a short list of known broken things with nvc0 but most stuff works.
22:48fdobridge: <karolherbst🐧🦀> depends on the what that entails, but a short list sounds fine for now
22:48fdobridge: <airlied> as long as gnome-shell works I think zink is just as valid as nvc0 for most things
22:49fdobridge: <airlied> I don't think anyone is really doing anything serious with nvc0
22:49fdobridge: <karolherbst🐧🦀> the big question is...
22:49fdobridge: <karolherbst🐧🦀> what if the host runs zink and the flatpak runs old nvc0
22:49fdobridge: <karolherbst🐧🦀> (or the other way around)
22:50fdobridge: <karolherbst🐧🦀> yeah.. I'm not all that much caring about breaking random games, because... vulkan is kinda the defacto best option anyway
22:50fdobridge: <gfxstrand> That should work.
22:50fdobridge: <karolherbst🐧🦀> I'm mostly just concerned about random issues, users start to file, especially in flatpak use cases, and then we can't fix them
22:51fdobridge: <leopard1907> I wonder if things like cad apps, blender and similar stuff works ok on zink
22:51fdobridge: <gfxstrand> The modifiers nvc0 advertises are correct AFAIK. It's only when you import an image with modifiers into nvc0 that things start to break down
22:51fdobridge: <karolherbst🐧🦀> ahh
22:51fdobridge: <karolherbst🐧🦀> that's kinda a relief
22:51fdobridge: <gfxstrand> So nvc0 on anything *should* be fine
22:52fdobridge: <karolherbst🐧🦀> right.. but with flatpak it can go either direction depending on things
22:52fdobridge: <karolherbst🐧🦀> new runtime on old host, or old runtime on new host
22:52fdobridge: <gfxstrand> Yeah and as long as we keep the "set the tile mode anyway" hack, the other direction should be fine most of the time.
22:52fdobridge: <karolherbst🐧🦀> in which cases might it not be fine?
22:52fdobridge: <gfxstrand> Where things break down is if you don't do a dedicated allocation
22:52fdobridge: <gfxstrand> Which there's no reason for us to not support because NVK handles that fine
22:53fdobridge: <gfxstrand> We recommend but don't require dedicated allocations.
22:53fdobridge: <karolherbst🐧🦀> mhh, I see
22:53fdobridge: <gfxstrand> The WSI code always uses them and Zink should as well.
22:53fdobridge: <airlied> @leopard1907 why do you think nvc0 has been tested with those?
22:54fdobridge: <karolherbst🐧🦀> we have bugs on blender
22:54fdobridge: <mohamexiety> is there a standard max character length before I wrap?
22:54fdobridge: <airlied> 72 usually
22:55fdobridge: <mohamexiety> alright, thanks!
22:55fdobridge: <karolherbst🐧🦀> but anyway, I think we can assume that people run nvc0 on everything imaginable
22:55fdobridge: <karolherbst🐧🦀> at least according to the bug reports we do kinda have
22:56fdobridge: <gfxstrand> But yeah, I think we're as good to go as we're going to be. We just need to review and land all the things and I need to write the blog post.
22:56fdobridge: <karolherbst🐧🦀> yeah, sounds good
22:56fdobridge: <karolherbst🐧🦀> users are going to complain in a year when it's broken anyway
22:56fdobridge: <gfxstrand> Yup
22:57fdobridge: <gfxstrand> Oh, and we need testing. I don't typically test the full stack but I know some folks here are running the full stack regularly
22:58fdobridge: <gfxstrand> @tiredchiku or @redsheep might be able to help with that. I think they've both run a full Zink+NVK stack.
22:58fdobridge: <gfxstrand> And maybe @asdqueerfromeu
22:58fdobridge: <gfxstrand> We should also make sure GameScope is working properly with the latest branches
23:05fdobridge: <redsheep> Yeah I can do some testing for sure, meant to get to it sooner. Unfortunately I don't think any of us three have gnome, since you mentioned that specifically
23:05fdobridge: <!DodoNVK (she) 🇱🇹> zink isn't as important for me because of my PRIME setup
23:05fdobridge: <gfxstrand> What do you usually run?
23:05fdobridge: <redsheep> Oh yeah you and Sid are on prime
23:06fdobridge: <redsheep> Plasma, and Sid is generally sway afaik
23:06fdobridge: <gfxstrand> Ah
23:06fdobridge: <karolherbst🐧🦀> I could probably do gnome testing, I just hate messing up my system mesa install with random builds 😄
23:07fdobridge: <mohamexiety> @airlied @gfxstrand done, re-sent
23:07fdobridge: <gfxstrand> Same same
23:07fdobridge: <!DodoNVK (she) 🇱🇹> I switched to Plasma
23:07fdobridge: <redsheep> Technically you could point the icd at a test build, but for the zink part that's kinda painful if your zink is old. I learned that the hard way as you know
23:07fdobridge: <karolherbst🐧🦀> yeah...
23:08fdobridge: <karolherbst🐧🦀> I wished I could tell a systemd service to start within a meson devenv tbh
23:08fdobridge: <karolherbst🐧🦀> mhhhhhh
23:08fdobridge: <karolherbst🐧🦀> actually...
23:08fdobridge: <redsheep> That might be possible
23:08fdobridge: <mohamexiety> the endgame is probably 2 systems or something like that. not very convenient space-wise but it feels it'd be a big timesaver in cases like this
23:09fdobridge: <karolherbst🐧🦀> there is this `meson-vscode.env` file
23:09fdobridge: <mohamexiety> but `devenv` is really powerful
23:09fdobridge: <karolherbst🐧🦀> but that relies on the vscode ext
23:09fdobridge: <karolherbst🐧🦀> but...
23:09fdobridge: <karolherbst🐧🦀> there is also `meson devenv $cmd...`
23:09fdobridge: <mohamexiety> also huh
23:10fdobridge: <mohamexiety> ```
23:10fdobridge: <mohamexiety> In file included from ../src/gallium/targets/dri/target.c:3:
23:10fdobridge: <mohamexiety> ../src/gallium/auxiliary/target-helpers/drm_helper.h:220:1: internal compiler error: Segmentation fault
23:10fdobridge: <mohamexiety> 220 | pipe_vmwgfx_create_screen(int fd, const struct pipe_screen_config *config)
23:10fdobridge: <mohamexiety> | ^~~~~~~~~~~~~~~~~~~~~~~~~
23:10fdobridge: <mohamexiety> Please submit a full bug report, with preprocessed source.
23:10fdobridge: <mohamexiety> See <http://bugzilla.redhat.com/bugzilla> for instructions.
23:10fdobridge: <mohamexiety> The bug is not reproducible, so it is likely a hardware or OS problem.
23:10fdobridge: <mohamexiety> ```
23:10fdobridge: <karolherbst🐧🦀> but I'm not sure how well that works with the logind/systemd integration stuff...
23:11fdobridge: <mohamexiety> @gfxstrand quick test of latest branch version: gamescope still works
23:11fdobridge: <mohamexiety> https://cdn.discordapp.com/attachments/1034184951790305330/1237904785093558272/image.png?ex=663d582b&is=663c06ab&hm=790d707d38888a71d526616811f3cc7c5ba4b86a2847f0b76d3418275edad61b&
23:13fdobridge: <airlied> @mohamexiety random ICE like that is often a sign of bad RAM or CPU
23:13fdobridge: <airlied> memtest time
23:14fdobridge: <mohamexiety> uh oh. I did run memtest on this when I got it a month or so ago and it was fine. will rerun and hopefully it's not a sign of something bad
23:14fdobridge: <redsheep> I will get a new kernel and mesa builds to test nvk+zink on the modifiers branch, we're still using the gfxstrand kernel branch from gitlab?
23:15fdobridge: <redsheep> IMO the real acid test will be whether this destroys my display server's performance the way it did before, it always sent about fps to the display regardless of what was happening
23:15fdobridge: <redsheep> sent 5 fps*
23:22fdobridge: <redsheep> I don't see any newer commits than a week ago here: https://gitlab.freedesktop.org/gfxstrand/linux/-/tree/nvk?ref_type=heads
23:22fdobridge: <redsheep>
23:22fdobridge: <redsheep> Is there another place I should be looking for a kernel to build, or have there not been newer kernel patches?
23:22fdobridge: <mohamexiety> no it's the same patch
23:22fdobridge: <mohamexiety> the newer version is just fixed commit description
23:22fdobridge: <mohamexiety> functionally it's literally the same
23:22fdobridge: <redsheep> Ah, okay great
23:27fdobridge: <redsheep> Nice it built this time without any errors
23:31fdobridge: <leopard1907> Good point 🐸
23:31fdobridge: <leopard1907> Yes, people wont be using and testing such a stack when there was no reclocking support on relevant hw for years
23:36fdobridge: <!DodoNVK (she) 🇱🇹> I got one with a massive C file
23:37fdobridge: <gfxstrand> I just pushed again. That version should have been good but the new push has a fix from @airlied
23:40fdobridge: <redsheep> Uhhhhh I was mid clone, if you just pushed I don't know yet what I have got. Is gitlab crazy or does that branch only have old stuff now? https://gitlab.freedesktop.org/gfxstrand/linux/-/commits/nvk
23:46fdobridge: <redsheep> Yeah it
23:46fdobridge: <redsheep> *'s not just the page
23:47fdobridge: <redsheep> My clone only has commits up to January 10th