08:30 notthatclippy[d]: skeggsb9778[d]: For the cleanup stuff, it seems desirable regardless, though likely in a separate patch series. For GSP versioning.. I don't really see a reason to support _every_ version upstream. Great as a POC, but it bloats the code and even introduces some inefficiencies - IIRC I saw a place where a thing had to be HAL'd for an intermediate release because some change came and went, so if you
08:30 notthatclippy[d]: just do 535+565 it'd be simpler.
08:30 notthatclippy[d]: We can review and test on 565 but then probably best to actually merge just 570 support.
08:52 tiredchiku[d]: yeah, best to bump up the GSP that'll run blackwell
09:24 fabcal: Hi Karol, quick question in relation to the software bug "Neuveau/Wayland" for a desktop installation (fbcon: 1st GPU: nVIDIA; 2nd GPU: intel T1000)
09:46 karolherbst: notthatclippy[d]: yeah.. I think it would have been cool if the GSP API wouldn't be such a mess to quickly figure out if a new version fixes a random bug users are hitting, but distributions will hate us more for every version we are supporting
09:50 notthatclippy[d]: Sure, but that is going forward. I can't really see much reason that anyone would bisect between 535 and 565 for a GSP bug, and anyone who does that could just build their own nouveau for it. After 570, it might make sense to support future major releases too. They'll be more stable anyway.
09:52 notthatclippy[d]: This reminds me to follow up on some avenues of cutting down the gsp.bin size. We ship a lot of crap that no one outside of NVIDIA will ever use. Maybe we can reorganize it such that you can then objcopy the bits nouveau will never use out before putting it in linux-firmware.
10:07 airlied[d]: As long as you keep nvdec and enc fw 😦
10:07 airlied[d]: 🙂
10:22 karolherbst[d]: notthatclippy[d]: yeah.. maybe something like that could work. It's kinda the question how much of a difference it makes though and if it's worth the effort, because gsp as it's now also kinda requires distribution to finally fix their approach to firmware which they'll have to fix sooner or later anyway
10:25 notthatclippy[d]: Well, there's two ideas that together would cut the gsp.bin size by at least half. One of them might not work out due to HW security design.
10:26 magic_rb[d]: I was just thinking that if you chop up the binary, you break the signature
10:26 notthatclippy[d]: Yes, that's a thing that would need to be solved.
10:27 notthatclippy[d]: For context, the gsp.bin contains both the GSP firmware, but it also has about a thousand other ucodes embedded in it (`uint8_t nvdec_tu104[] = {...}` style). We're talking about trimming that thousand to something a lot smaller.
10:28 notthatclippy[d]: Each of those ucodes also have their own signature (or are encrypted), so security is not impacted by them not being a factor in the overall gsp.bin signature.
10:32 kwizart: the main trend for distro (having fedora in mind) is to avoid DRM drivers in initramfs (unless simpledrm). Then firmware size is too that much an issue
10:33 kwizart: (even when compressed firmware)
10:33 notthatclippy[d]: We can always just plumb `request_firmware()` to GSP and dump a thousand small files into linux-firmware 👿
12:10 karolherbst[d]: the latter
12:11 karolherbst[d]: because it's maintained
12:11 karolherbst[d]: and `xf86-video-nouveau` is kinda a dead project
12:12 karolherbst[d]: modesetting doesn't use any hardware specific APIs
12:16 karolherbst[d]: pavlo_kozlenko[d]: yep, and it uses OpenGL for acceleration
12:26 tiredchiku[d]: for 2D acceleration, yes
12:26 tiredchiku[d]: afaik they don't do any 3D accel
12:42 karolherbst[d]: for most drivers/hardware this distinction doesn't exist anymore
12:42 karolherbst[d]: I don't even know if it actually does for nvidia either, though they do have 2D functionality, I just don't know if it's simply emulated on top of 3D
20:26 gfxstrand[d]: It might be interesting to do a Vulkan glamour and try to use vkCmdCopyImage for stuff when possible. That might be a little faster on Nvidia. On Intel it all goes through 3D anyway until maybe DG2 where they added a copy engine that doesn't totally suck.
20:27 gfxstrand[d]: But also none of that matters if you have a compositor. It's all just font rendering and the odd blit to the front buffer and two triangles is good enough for that.
20:28 HdkR: One triangle is also good enough for that :D
20:30 gfxstrand[d]: If we can ever agree on how to draw what triangle, yes. 😂
20:30 gfxstrand[d]: Or you can just set a scissor
20:31 gfxstrand[d]: We've had rectlist proposals floating around for how long now?
20:36 airlied[d]: we really should have just implemented all 3 rectlist APIs already 😛
20:37 airlied[d]: https://gitlab.freedesktop.org/airlied/xserver/-/tree/wip-vaccum-sketch?ref_type=heads I did start once sketching out vulkan glamor
22:50 gfxstrand[d]: Yeah, it wouldn't be that hard to make glamour support 3 extensions