00:00redsheep[d]: I was going to use the blurbusters tests and my phone set to high speed video mode, but as soon as I pull up blurbusters in chrome it runs at 60 fps only...
00:01orowith2os[d]: does your monitor not have a HUD or something to display FPS?
00:01orowith2os[d]: if it does, pair that with mangohud and compare the two
00:02orowith2os[d]: triple check with an in-compositor HUD
00:02orowith2os[d]: erhm, I'm assuming kwin?
00:02redsheep[d]: orowith2os[d]: It does, but nouveau doesn't do variable refresh rate. It says 120 there but it would never not say 120, so long as the mode actually took, which it did
00:03redsheep[d]: orowith2os[d]: Yes, kwin. Is there some kwin debug overlay I don't know about?
00:03orowith2os[d]: not sure
00:03orowith2os[d]: I want to say there was, but I don't remember if it was a setting somewhere or just me injecting mangohud into kwin itself
00:05redsheep[d]: Ok so doing the blurbusters testing prompted me to try firefox again, and it's good that it did because this has got some artifacting. Maybe I can finally open a useful issue.
00:06redsheep[d]: It does run at 120 and makes it painfully clear that frame delivery on this session is not working properly at all
00:07orowith2os[d]: I think Firefox artifacting is a known problem with zink?
00:07orowith2os[d]: assuming you're using it on this session
00:08orowith2os[d]: let me find my issue
00:09redsheep[d]: orowith2os[d]: I am, that's been my testing goal for the last few days. That's good to know it may not be nvk specific. Still, anything where zink has issues with normal ui apps is a potential reason to hold back on switching the default
00:09orowith2os[d]: https://gitlab.freedesktop.org/mesa/mesa/-/issues/12194
00:09orowith2os[d]: I had it on my AMD laptop
00:10orowith2os[d]: something to do with multi-context GL
00:11orowith2os[d]: does Firefox crash later down the line, specifically if you cover the window fully, and show it again?
00:11orowith2os[d]: I got a syncobj error, I know someone else here got an issue on a different protocol object
00:13redsheep[d]: It hasn't yet. The artifacting is more of ui elements seeming to not render sometimes, similar to what discord was doing for me on wayland. Just parts of the ui flicking in and out of existence. Not showing the background behind the window, but whatever that ui element would have covered up in the same window
00:13redsheep[d]: It's unfortunately a little hard to describe, I guess I should try to get video of both if I can manage to replicate
00:14redsheep[d]: The discord issue is specific to wayland but this firefox issue is happening right now even without wayland
00:17redsheep[d]: Oh you already found it happening with x11 as well. Hmm. Maybe it is the same issue and I am just misinterpreting your description of what it looks like
00:19orowith2os[d]: I can't remember if I tried to get a picture of it happening
00:19orowith2os[d]: it probably exists on the Discord side somewhere
00:25redsheep[d]: I am seeing webrender under about:support. The more I read the more I think this is my issue. It does look like this is nouveau specific though? If it's happening on nouveau gl as well maybe there's a kernel issue
00:26redsheep[d]: I still haven't managed to crash FF so it's hard to say. If it can consistently be made to crash maybe we could at least get a backtrace that's useful
00:32orowith2os[d]: it might all be different incarnations of the same bug
00:32orowith2os[d]: dunno
04:24tiredchiku[d]: rinlovesyou[d]: I do
04:25tiredchiku[d]: redsheep[d]: there is
04:28redsheep[d]: tiredchiku[d]: More words are more good
04:29tiredchiku[d]: yeah wait I just woke up 4 minutes ago
04:33tiredchiku[d]: redsheep[d]: system settings > window management > desktop effects
04:33tiredchiku[d]: scroll down to tools
04:34tiredchiku[d]: https://cdn.discordapp.com/attachments/1034184951790305330/1345252790833909832/P1dXfRA.png?ex=67c3dfca&is=67c28e4a&hm=8db2da9994d6853f0fc58405c7f074e49b264fc589e8d3f3a69f81d468f5ccda&
04:35orowith2os[d]: gfxstrand[d]: thank you *so much* for taking a look at the firefox issue :catgirl_heart:
04:36orowith2os[d]: if you have a demo app that abuses zink to an extent you think is enough, I can try it over here on RADV
04:39gfxstrand[d]: Trying to reproduce in RADV+Zink might be helpful.
04:39orowith2os[d]: it *is* where *I* encountered this error, and I think someone else had it on ANV
04:39gfxstrand[d]: But we need to be sure what the reproducer case is. Right now there's a lot of different stuff on that bug report.
04:40gfxstrand[d]: I'm pretty sure it's a Zink/EGL sync issue which, honestly, could explain a lot...
04:40gfxstrand[d]: That could be the discord issue redsheep[d] keeps seeing. (No guarantees but they smell similar.)
04:41orowith2os[d]: here's a link to the sway instance, when I had this issue: https://discordapp.com/channels/1033216351990456371/1209954375766908948/1345254360875012127
04:41orowith2os[d]: fwiw I didn't have any issues with chromium or webkit
04:41orowith2os[d]: can try again later though
04:41gfxstrand[d]: Does it need a wlroots based compositor to reproduce?
04:42redsheep[d]: kwin isn't wlroots and it happens on x11 there too
04:42orowith2os[d]: I had it on GNOME Wayland
04:42gfxstrand[d]: redsheep[d]: The Firefox thing?
04:42redsheep[d]: Yep. Replicated today on that config.
04:42gfxstrand[d]: orowith2os[d]: Firefox on gnome Wayland?
04:42orowith2os[d]: yup
04:42redsheep[d]: Or, at least what I think matches the description.
04:42gfxstrand[d]: Okay, cool. I can repro then.
04:43gfxstrand[d]: Well, I can theoretically repro anything but that's the easiest for me
04:44gfxstrand[d]: This really smells like an EGL sync bug. Which honestly isn't surprising given how Vulkan and EGL mismatch.
04:44gfxstrand[d]: I'll look into it next week. I already fixed one Zink synchronization issue a week ago so I have that code pretty well paged in.
04:45orowith2os[d]: we love sync shenanigans :marioWow:
04:46redsheep[d]: I haven't bothered to go back to look but I would assume that other fix was what fixed the corruption. Hard to say though and not worth looking back
04:47redsheep[d]: I really hope that this ends up being the same sync issue that is making just everything flicker, just a little.
04:47orowith2os[d]: give me a Mesa commit and I'll have you some results ASAP
04:48gfxstrand[d]: My fix from a two weeks ago just fixed GL<->Vulkan interop. Not much uses that. But I'm suspicious that other bugs are lurking around a corner.
04:48tiredchiku[d]: :Stitch_lurk:
04:49tiredchiku[d]: 👆 real footage of other bugs
04:49gfxstrand[d]: I would love to get the Zink sync bugs fixed because I think that's most of what's causing us grief right now. I would love it if people could just stop using nouveau GL.
04:49gfxstrand[d]: I also don't want to write a gallium driver. 🙃
04:50gfxstrand[d]: Fixing Zink seems like less work
04:50redsheep[d]: Once the zink session is solid the kernel will be the bigger holdup for a comfortable session for me, not nvk at all.
04:51tiredchiku[d]: the kernel is definitely a major holdup for a lot of things as it stands
04:52gfxstrand[d]: Yeah. Especially on laptops.
04:52orowith2os[d]: gfxstrand[d]: I would love it over here on RADV to see if I can hit some corner cases with zink and get some more real world testing for it.
04:52orowith2os[d]: What's the point in being an advanced user if I don't put my resources to use? :)
04:53orowith2os[d]: I'm sure any issues I hit over here would help NVK as well
04:53gfxstrand[d]: Desktop seems stable enough if you aren't seeing the display problems. But my laptop is a constant source of trouble.
04:53gfxstrand[d]: orowith2os[d]: Trying to run RADV+Zink as your daily driver would definitely fish out some issues.
04:54orowith2os[d]: I remember hitting some issues with session initialization when I first tried, then graphical problems with GTK - and now it almost completely works :))
04:54orowith2os[d]: all over the span of the last year, and change
04:54orowith2os[d]: it's amazing to see Zink make progress
04:55tiredchiku[d]: I should continue working on the thing I was working on <a:ahh:1022261668148940810>
04:55orowith2os[d]: orowith2os[d]: ~~now we just need zmike to have a bunch of testing clients to run and let him go ham on the performance aspect, after being fully working~~
04:56orowith2os[d]: "this testing client doesn't spit out 4000 goobleflorps every single second? impossible!"
04:56redsheep[d]: The zink session does seem like 10x closer to usable than it was like a year ago, yeah
04:57orowith2os[d]: maybe I'll be able to do some light hacking in Mesa after I'm done over here in GNOME :wires:
04:58orowith2os[d]: doubting myself when it comes to writing C is really handy, I either agonize over safety issues, which are found, or every path leads to it being fine and I take a shot for being an idiot
04:59tiredchiku[d]: tiredchiku[d]: I have a fair bit of code ready I just need to figure out some nvrm ioctls to make nvk "work" on nvidia's own kernel module
05:00tiredchiku[d]: if I can even just have vulkaninfo and/or vkcube run to start with, I'll be more than happy
05:00redsheep[d]: tiredchiku[d]: I'm impressed you've gotten anywhere at all. That project turned out to be a lot harder than I thought it would be and I didn't think it would be easy.
05:01tiredchiku[d]: well, I just have boilerplate code for pdev/dev/context creation and va allocation
05:01tiredchiku[d]: some of it is wired up to the kernel module, but most of it isn't
05:01orowith2os[d]: I don't think I've asked here yet - how does Nova play with NVK? Is it as active as I've seen NVK?
05:01tiredchiku[d]: Nova doesn't exist yet
05:01orowith2os[d]: I remember taking a look at a branch for it but it was a bit out of date
05:01tiredchiku[d]: only behind redhat walls
05:01orowith2os[d]: oh noes
05:02orowith2os[d]: I guess that answers my question then
05:02redsheep[d]: I think there's probably a recent version somewhere public. Last I checked though it's still mostly a shell. Getting the rust for linux stuff progressed enough that nova has what it needs to get into the meat of things has been the primary area of progress
05:03tiredchiku[d]: but for the end users/testers, there's nothing to see
05:03orowith2os[d]: it would be fun to mess with writing a rust amdgpu driver, even if only for my specific GPU
05:04tiredchiku[d]: tiredchiku[d]: one thing I should change about my approach is to ask more questions instead of trying to find everything myself
05:04tiredchiku[d]: e-e
05:04redsheep[d]: Getting a solid foundation is really important and I respect taking the time to do that right, forging a path for all future rust gpu drivers. It does kind of suck though that a growing list of stuff has ended up on the waiting for nova list though since implementing some stuff in nouveau is just really hard.
05:05orowith2os[d]: does R4L have all the stuff in their tree?
05:05orowith2os[d]: or, well, most of it?
05:06orowith2os[d]: if so, I'm REALLY going to abuse my nixos generations this time >:3
05:07redsheep[d]: I don't really know. I haven't watched too closely since there's not much for me to do until something minimally testable exists
05:08orowith2os[d]: oooh, they use zulip. Okay.
05:08orowith2os[d]: I'll ask there
10:02airlied[d]: There is no RH walls
10:03airlied[d]: We don't as policy develop behind closed doors, it does happen from time to time but the default is to develop on public servers even if not advertised
10:04airlied[d]: But there is no nova yet, there are some hacks that replace the core pieces of nouveau with a rust driver , but still keeps the nouveau DRM code and uapi
10:42asdqueerfromeu[d]: Does the multi-GSP version support actually work in the R570 GSP kernel? I see load entries for both R570 and R535 GSP blobs
10:42tiredchiku[d]: asdqueerfromeu[d]: no idea, since dmesg doesn't mention which version it loads :froge:
13:52gfxstrand[d]: asdqueerfromeu[d]: Ben's 570 branch does for me. I've got a patch with a printk with the GSP version in my version of his branch.
13:52gfxstrand[d]: I really should rsync that over to my other desktop and see if it makes my GSP death problems go away... 🤔
14:04gfxstrand[d]: orowith2os[d]: Just go for it and trust that reviewers.
14:08gfxstrand[d]: orowith2os[d]: NVK will support Nova when it's ready and NVK will be the primary userspace for Nova. However, it's mostly a prototype at the moment. I don't think the pure Rust driver can do much more than load the GSP.
14:10gfxstrand[d]: I expect Nova to take a similar path to NVK and NAK. (I walked this park twice.) It'll be cool but useless/unusable for a long time and then, suddenly, in the space of about 6 months to a year, it'll suddenly become actually pretty good.
14:12gfxstrand[d]: As for things waiting on Nova, I'm hoping to do most of your things with nouveau.ko first. That way we can do them badly once and then when we build the Nova UAPI, we can do them the right way.
14:16gfxstrand[d]: The big problem with that plan is that the people who really know the parts of nouveau.ko we need to hack on are all busy with Nova so we're having to spin people up.
14:17mohamexiety[d]: :nervous:
14:38gfxstrand[d]: https://tenor.com/view/chuckles-im-in-danger-ralph-wiggum-the-simpsons-gif-14149962
14:39gfxstrand[d]: We'll get there. I want to get Zink fixed and land mhenning[d]'s scheduler stuff and then I think I'm gonna start working on it for realz.
14:41mohamexiety[d]: yeah. I did discover a few things about removing `nvbo->page` that makes it look like not exactly the best path forwards but will look further into things to see if there's an alternative we could do
14:45gfxstrand[d]: mohamexiety[d]: I think that's a good thread to pull. We need to break that dependency somehow. But I fear the final solution is going to end up being pretty invasive.
14:47tiredchiku[d]: am gonna bump this again :Sweat:
14:47tiredchiku[d]: https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/31518
14:47tiredchiku[d]: wanna know if that's plenty or if I'm missing something really
14:54gfxstrand[d]: I'll take a look. Next week
14:55tiredchiku[d]: okie
15:23gfxstrand[d]: I've mostly been ignoring it because we don't have device fault information yet and that's where that extension really gets useful. It may be useful for other things like RMV, though. I'm not sure. Once 570 lands, we can look into wiring up the device fault extension, too.
15:25tiredchiku[d]: ahh, yeah, that's fair
15:34gfxstrand[d]: Someone really should look into RMV and what it takes to get that working. asdqueerfromeu[d] filled an issue but IDK if she is actually looking into it or not.
15:39tiredchiku[d]: I could try to figure out out all the extensions it requires
15:44gfxstrand[d]: That would be good. Then we can treat that issue as a checklist.
16:02tiredchiku[d]: now to find a pre-made trace that the app will open
16:03tiredchiku[d]: (app itself launches just fine on nvk)
19:10redsheep[d]: gfxstrand[d]: Wait, like you're gonna start improving the nouveau kernel?
19:15redsheep[d]: That sounds very exciting. I have the hardware to test most of the more major issues or missing features wrt displays, if you ever get around to that corner of things. I assume you'd start with the page size stuff which is great.
19:29redsheep[d]: I really wish that I could have a bpc and chroma subsampling option explicitly somewhere instead of just having the kernel choose for me. Probably a dsc toggle as well when that's added. Then just have it only show modes that comply with what I've explicitly set. I dunno if that's possible though, and afaik not even amdgpu has that
20:09djdeath3483[d]: tiredchiku[d]: none afaik
20:09tiredchiku[d]: :doomthink:
20:35gfxstrand[d]: redsheep[d]: Yeah, I'm not planning on touching display. I know even less about display hardware than the rest of the kernel.
20:42redsheep[d]: gfxstrand[d]: Alright. Who knows, maybe I will try to fix it. It feels like it shouldn't be that hard to fix the bpc stuff, but it kind of makes no sense. I've spent too much time trying to read both openrm and nouveau and understand what they are doing different and it doesn't feel lkike nouveau even has any code that would even be capable of messing things up
20:46redsheep[d]: Same goes for missing modes
20:48gfxstrand[d]: <a:bim_shrug2:1102331343695790160>
20:51gfxstrand[d]: gfxstrand[d]: But I also said I wasn't planning on hacking on the kernel, so...
21:03redsheep[d]: I feel like for me the limitation has been less of understanding displays, and more that I am not a programmer and can't read C and automatically understand what it's doing. You won't have that problem.
21:03redsheep[d]: As far as I can tell almost all of that low level stuff that has to do with how displays work has been stuffed into the gsp and isn't even visible to us.