00:08 pgrwe: hihi - to whom it may concern, the link in the wiki on the nouveau / IntroductoryCourse page to "The State of Linux Graphics" appears to be dead. Re-sending cus i had to register...
03:54 fdobridge_: <g​fxstrand> Do you have easy to install images? I've got a V1 switch that I'd like to test stuff out on one of these days.
03:54 fdobridge_: <a​zkali> Have you ever flashed Linux on your v1 ?
03:54 fdobridge_: <g​fxstrand> Nope
03:54 fdobridge_: <a​zkali> The process is the same as we document for the others, hold on
03:55 fdobridge_: <g​fxstrand> But I've checked serial numbers and it's hackable
03:55 fdobridge_: <a​zkali> V2 can be hacked too with a chip
03:55 fdobridge_: <a​zkali> As well as patched v1 as well
03:55 fdobridge_: <a​zkali> But that's beside the topic of interest
03:56 fdobridge_: <a​zkali> https://wiki.switchroot.org/wiki/linux/l4t-fedora-installation-guide
03:56 fdobridge_: <a​zkali> I should update the version
03:56 fdobridge_: <g​fxstrand> Cool. Thanks! I may flash it later this week.
03:57 fdobridge_: <a​zkali> I'll send a link cause I just triggered a fresh build
03:57 fdobridge_: <a​zkali> https://gitlab.azka.li/l4t-community/gnu-linux/jet-factory/-/jobs/10000
03:57 fdobridge_: <a​zkali> When it'll be done
03:57 fdobridge_: <a​zkali> Username and password are the same in case you wonder
03:58 fdobridge_: <g​fxstrand> We've got some known kernel problems with synchronization on Tegra that @marysaka found but otherwise NVK should work in theory. I've yet to play with it personally, though. The only Tegra I own is a couple switches.
03:59 fdobridge_: <a​zkali> I own a Nano, and have access to a Xavier NX easily. I plan to get an Orin NX soon but finance are not great (gonna be fixed soon)
04:00 fdobridge_: <a​zkali> The downside in my case is that I am using Mary's patchsets to get mesa work on Switch
04:00 fdobridge_: <a​zkali> https://build.opensuse.org/package/show/home:Azkali:Tegra:Icosa_testing/mesa-nvk
04:02 fdobridge_: <g​fxstrand> Ah, yeah, modifiers may be a bit busted depending on `$stuff`. The good news is that that's probably going to get fixed in the next month or two. It's next on @mohamexiety's list after he's done with sparse.
04:03 fdobridge_: <g​fxstrand> It's one of the few big "yeah, we really need to fix this" issues left.
04:04 fdobridge_: <g​fxstrand> Until then, carrying Mary's patches to disable them on the GL side should work. IDK why that's needed on Tegra and not desktop cards but I can believe it is.
04:06 fdobridge_: <g​fxstrand> Hrm... Or maybe it's the Tegra display path on the kernel that busted? That's plausible, too. I'll have a far better idea of the state of things once I get it up and going.
04:07 fdobridge_: <a​zkali> Didn't got enough time to get too far into investigating the issue
04:08 fdobridge_: <a​zkali> Got some serious health issues earlier this year so this kinda throw my year schedule all over the place tbh
04:08 fdobridge_: <a​zkali> I am fine before you ask
04:08 fdobridge_: <g​fxstrand> Yeah, I know how that goes...
04:08 fdobridge_: <a​zkali> I am fine now before you ask (edited)
04:09 fdobridge_: <g​fxstrand> I've had a lot of stuff the last couple years so I get it.
04:10 fdobridge_: <a​zkali> Thanks for understanding. And I hope life's gonna get easier on you as well, if that's a possibility
04:11 fdobridge_: <g​fxstrand> It will eventually. This year is gonna be crazy as well but it should start to level off in '25.
04:13 fdobridge_: <a​zkali> But yeah back on the main subject
04:15 fdobridge_: <a​zkali> The initial idea of running NVK and mainline is getting close to completion, at least on my end I did the groundwork that was needed for the most part.
04:15 fdobridge_: <a​zkali> I should really start to document my whole plan/roadmap for this device cause it's hard to get all the ideas together. But yeah the switch is going to have a nice treatment the next couple months from me (and our team)
04:16 fdobridge_: <a​zkali> I'd like to see if we could get CUDA to work with nouveau
04:16 fdobridge_: <g​fxstrand> That's gonna be harder
04:17 fdobridge_: <g​fxstrand> I've not really looked into what that would take yet. I'd like to get there one day but I'm really not sure what it would look like.
04:19 fdobridge_: <g​fxstrand> For NVK, Maxwell support is continuing, if slowly. I'm intentionally trying to leave Maxwell as a sandbox for newer devs. Whenever I'm head-down on something, there doesn't tend to be a lot of room for other people to work in the same area. It helps to carve out stuff and leave it alone. I'll pick it up and finish it off eventually, though.
04:20 fdobridge_: <g​fxstrand> Then there's Tegra in general. IDK what all is needed there. @marysaka looked into it and it looks like there are either synchronization or caching issues somewhere. Fences are showing up before the data they supposedly guard. It's still unknown exactly what's going on or what/where we need to fix.
04:21 fdobridge_: <g​fxstrand> The good news is that most of it seems to work without much modification.
04:21 fdobridge_: <g​fxstrand> I really want NVK on switch to work well.
04:22 fdobridge_: <a​zkali> Well I could see myself work on it but I need to finish a few project before that
04:22 fdobridge_: <g​fxstrand> That's okay
04:22 fdobridge_: <a​zkali> We're on the same boat there
05:41 fdobridge_: <!​DodoNVK (she) 🇱🇹> I'm not sure you can fix kernel issues though (because you don't want to be a kernel maintainer)
06:13 fdobridge_: <S​id> not me happily diving into kernel code because I wanna do some damn nvk gaming
09:59 fdobridge_: <m​arysaka> so on that side, I'm pretty sure nouveau needs to integrate host1x syncpoints to handle job fences.
09:59 fdobridge_: <m​arysaka> host1x driver being upstream those days it should hopefully not be that hard but yeah all my attempt at trying to integrate it failed
10:00 fdobridge_: <m​arysaka> I can't remember if I opened an issue for that yet, I will add that to my list of things to do when I get back
10:26 fdobridge_: <p​homes_> @gfxstrand with your planned work on the pipeline code does it still make sense for me to rebase my shader cache MR?
10:26 fdobridge_: <!​DodoNVK (she) 🇱🇹> https://tenor.com/view/nike-just-do-it-gif-26636514
10:39 fdobridge_: <p​homes_> heh 🙂 maybe I will spend a bit of time on it but I could easily see Faith reimplement all of it if she is moving the implementation to common code
15:19 fdobridge_: <g​fxstrand> Probably not. My plan is to build it all in common code. If you wanted to give it a rebase, I'd be happy to merge it but it'll all go away in a month or so when we get the new pipeline code.
15:20 fdobridge_: <g​fxstrand> I'm happy to have it in-tree for a month, though.
15:21 fdobridge_: <g​fxstrand> And now that I'm done reworking nvk_shader to use NAK, merging it won't make development harder in any way.
15:22 fdobridge_: <g​fxstrand> That's why I didn't want to merge it before. I was afraid it would make the "make everything use NAK" refactor harder if I had to think about caching, too.
15:24 fdobridge_: <g​fxstrand> Hehe, fair. If the kernel devs ever get the idea that I can fix my own kernel bugs, it's all over for my cunning plan to not be a kernel maintainer. 😂
15:25 fdobridge_: <g​fxstrand> I don't see a problem with this. How do you think most of us got roped in? 😅
15:39 fdobridge_: <g​fxstrand> Also, I say a month but I honestly don't know how long the common code will be stuck in review. I want to land it and move on but I also want ANV and RADV to use it so it may take a bit before they're all happy with it.
16:26 fdobridge_: <t​riang3l> Wouldn't RADV theoretically benefit from the opposite, by the way? Though maybe the current code wouldn't
16:26 fdobridge_: <t​riang3l> if the common pipeline code implements pipelines on top of dynamic state
16:28 fdobridge_: <t​riang3l> But yeah, the current code probably doesn't, something like `PA_SU_SC_MODE_CNTL` is regenerated whenever any involved dynamic state (cull mode, front face, depth bias enabled, polygon mode, provoking vertex, line mode) is changed
16:30 fdobridge_: <g​fxstrand> Yes and no. The goal would be to make something that gracefully transitions between all the benefits of pipelines and full ESO. I think I've got a decent plan for how to do it but the proof will be in the pudding, as they say.
16:36 fdobridge_: <a​zkali> Starting to look at how L4T handles host1x syncpoints and fences
21:26 fdobridge_: <g​fxstrand> What's "host1x"?
21:39 fdobridge_: <m​arysaka> https://github.com/torvalds/linux/tree/master/drivers/gpu/host1x
21:39 fdobridge_: <m​arysaka> very old doc about it https://http.download.nvidia.com/tegra-public-appnotes/host1x.html
21:40 fdobridge_: <m​arysaka> there is also ton of infos on the TX1 TRM but that's basically what you have to interact with for syncpoints and nvdec/nvenc
21:49 fdobridge_: <!​DodoNVK (she) 🇱🇹> DXVK/vkd3d-proton only supports GPL
21:54 HdkR: Fancy bus that has some random features glued to it :P
21:58 HdkR: Which I guess AXI/AMBA isn't too far off for fancy bus with random features
22:04 fdobridge_: <m​arysaka> well the only thing we do care about is syncpoints here and possibly interaction with nvdec
22:12 HdkR: You'll probably care about the coherency of the bus clients changing over time for the different SoCs
22:17 HdkR: Wonder if the tertiary features changed over time as well