<fdobridge>
<gfxstrand> Okay, I just pushed the legacy tiling MR again. Two major changes:
<fdobridge>
<gfxstrand> 1. The NVK implementation is now meaner and returns `DRM_FORMAT_MOD_INVALID` if it's not a tiled BO because in that case we don't know if the BO came from nouveau or another driver and we don't know if it's one of NVK's linear BOs with a tiled image or if it's actually linear.
<fdobridge>
<gfxstrand> 2. NVK now only advertises the extension of `engine_name` is "mesa zink".
<fdobridge>
<zmike.> sgtm
<fdobridge>
<gfxstrand> Hopefully 1 will make the reference implementation of the extension sufficiently mean that people won't make too many assumptions in their zink wannabe apps
<fdobridge>
<zmike.> I guess maybe the only other driver that might implement would be radv
<fdobridge>
<gfxstrand> anv
<fdobridge>
<zmike.> they can't get modifier info from the kernel though?
<fdobridge>
<gfxstrand> They can on i915 but not Xe
<fdobridge>
<gfxstrand> And only Gfx12 and earlier
<fdobridge>
<zmike.> ah
<fdobridge>
<zmike.> well then
<fdobridge>
<gfxstrand> But there's still a hell of a lot of skylake out there
<fdobridge>
<zmike.> :frog_whip:
<fdobridge>
<gfxstrand> But the ANV implementation is like 3 lines of code
<fdobridge>
<gfxstrand> Because they already have those 3 lines in iris
<fdobridge>
<gfxstrand> Freedreno is like 1 line of code. They use the AMD blob API but their blob is a modifier
<fdobridge>
<gfxstrand> But IDK how much they care about Zink
<fdobridge>
<zmike.> I think 1 line of code is manageable
Dark-Show has quit [Quit: Leaving]
<fdobridge>
<Sid> MRs to test :BlobhajReach:
<fdobridge>
<Sid> MRs to test? :BlobhajReach: (edited)
<fdobridge>
<gfxstrand> Same branch. Just pull again.
<fdobridge>
<gfxstrand> The cursor thing is still busted but it's been verified to be a kernel bug. @_lyude is gonna take a crack at it on Monday.
<fdobridge>
<Sid> :salute:
<fdobridge>
<gfxstrand> There's a few NVK commits in that branch that aren't in their final state yet. I'm gonna figure out a better plan for those on Monday.
<fdobridge>
<gfxstrand> All the Zink fixes are upstream now, though.
<fdobridge>
<Sid> all good-
<fdobridge>
<Sid> I take it the synchronization issues need the xserver patch as well?
<fdobridge>
<Sid> yeah, seems like it
<fdobridge>
<Sid> though, my browser (librewolf) still has a sync issue
<fdobridge>
<Sid> `../mesa/src/vulkan/wsi/wsi_common_x11.c:1924: Swapchain status changed to VK_SUBOPTIMAL_KHR`
<fdobridge>
<Sid> browser ^
<fdobridge>
<!DodoNVK (she) 🇱🇹> Don't forget to do `rm -r src/vulkan/device-select-layer` first
<fdobridge>
<fooishbar> I still don’t know where the meme that Flatpak drivers are frozen in amber and will literally never be updated is coming from … ?
<fdobridge>
<fooishbar> I’m doing us all a favour tbf
<fdobridge>
<fooishbar> just go for it and if you end up with a totally unsolvable problem, then do the horrible thing
<fdobridge>
<karolherbst> probably because applications decide which runtime to target and some people are annoyed by the fact it's the applications decision, not somebody elses
<fdobridge>
<karolherbst> there are enough people out there in positions of power who distrust all application developers
<fdobridge>
<fooishbar> sure, but those aren’t stuck there for years, e.g. OBS could choose to update their base with an older Qt if they wanted, or try to get Qt fixed - it’s not like OBS will have a 10-year old Mesa forever - or if they do, that’s a bizarre and terrible choice
<fdobridge>
<karolherbst> ohh it's not anything logical, there are just people who hate it and are vocal about it
<fdobridge>
<fooishbar> at the very least, anyone wanting to run on new hardware needs that to be updated, not just people wanting to run Zink on NVK on nouveau
<fdobridge>
<fooishbar> ah yes, the internet
<fdobridge>
<karolherbst> yeah...
<fdobridge>
<karolherbst> but yeah, people will have to update eventually, and some people would just prefer if GL drivers are always shipped by the OS or something, which is even possible if the libstdc++ situation wouldn't be there
<fdobridge>
<fooishbar> anyway, it seems like a normal market pressure problem: if enough people want it to be solved, then it’ll be solved in the thing, or people stop using the thing
<fdobridge>
<fooishbar> also LLVM
<fdobridge>
<karolherbst> yeah... I wished we'd have proper library namespaces, so one could ship multiple libstdc++ within the same process (so mesa would get its own)
<fdobridge>
<karolherbst> llvm has the same issue
<fdobridge>
<karolherbst> and then we could in theory use system GPU drivers inside flatpak without running into those issues
<fdobridge>
<karolherbst> to a lesser extent libc has the same issue
<fdobridge>
<ermine1716> Feels like that would increase RAM usage substantially
<fdobridge>
<karolherbst> things using GL/VK already use a lot of RAM
<fdobridge>
<karolherbst> another 2 or 3 won't matter
<fdobridge>
<karolherbst> but it would solve a looot of headaches for a lot of people
<fdobridge>
<karolherbst> like vavle/steam run into similar issues where games ship their own libstdc++ and then things just break, because mesa needs a newer one
<fdobridge>
<Owo> You can also force it to a specific runtime
<fdobridge>
<Owo> See the --runtime=name/arch/branch flag, as well as --runtime-version
<fdobridge>
<Owo> I used it with Firefox earlier in this channel to test with Mesa 25
<fdobridge>
<Owo> So long as there's no backwards-incompatible ABI breaks, it's fine
<fdobridge>
<fooishbar> and there’s nothing stopping OBS from taking the Qt 6.6 runtime then rebuilding with a newer Mesa - other than I’m not sure if anyone’s asked them to
<fdobridge>
<gfxstrand> That's probably because someone (either X or your compositor) switching to a SW cursor for the screenshot. The cursor problem is the nouveau kernel driver not handling 32x32 hardware cursors correctly.
<fdobridge>
<Owo> Is the runtime OBS is on right now 23.08 or 24.08-based?
<fdobridge>
<Owo> If it's 23.08, you'll have problems with Wayland-protocols, but 24.08 is up to date
<fdobridge>
<gfxstrand> Asahi has a Platform.GL.Host flatpak that they ship to let them inject newer drivers. All distros should ship that as an option, IMO.
<fdobridge>
<Owo> That only works because they target one, or a few, specific runtime versions
<fdobridge>
<Owo> You'd need distros to keep up every year to ship a new driver, and that also means more storage used that flatpak can't deduplicate on its own
<fdobridge>
<gfxstrand> Also, we were very close at one point to not needing libstdc++ in some drivers.
<fdobridge>
<Owo> It looks like they have different packages for each runtime
<fdobridge>
<Owo> If you want to integrate building in each major supported runtime with your package, go for it
<fdobridge>
<Owo> Just be aware of the issues you'll have when trying to do so
<fdobridge>
<Sid> :ablobnote:
<fdobridge>
<gfxstrand> It shows up in my screenshots because I don't screenshot from the compositor. I screenshot from HDMI capture on my PiKVM.
<fdobridge>
<Sid> fancy! :P
<fdobridge>
<gfxstrand> PiKVMs are really nice...
<fdobridge>
<gfxstrand> And they let me work with confidence from anywhere in the world because I can remote power cycle the machine. Hell, I've done an install over it before.
<fdobridge>
<gfxstrand> As long as my home Internet doesn't go down and I don't need to swap GPUs, I'm in good shape.
<fdobridge>
<Sid> that's rad tbh
<fdobridge>
<gfxstrand> Yeah, it's really nice
<fdobridge>
<gfxstrand> Okay, looks like the X release is delayed until after the GitLab migration. If anyone else wants to do some testing of that X branch which switches glamour to use modifiers on Zink, that'd be cool. Especially if it could be tested on other Vulkan drivers.
<fdobridge>
<gfxstrand> If we don't see anything going wrong, I'm going to try and get it into the 25.1 release.
<fdobridge>
<gfxstrand> And I might try to con @fooishbar or @eanholt into reviewing it.
<fdobridge>
<fooishbar> Ab
<fdobridge>
<fooishbar> and don’t worry about the release, just ping distros to ship it
<fdobridge>
<fooishbar> I can’t imagine too many would take 25.1
<fdobridge>
<gfxstrand> Yeah, I'm happy to backport it to whatever stable thing.
<fdobridge>
<gfxstrand> If we need to do another 21 release, then so be it.
<fdobridge>
<gfxstrand> I don't think glamour has substantially changed so it'll probably work there, too. Though someone should probably test that...