00:10gfxstrand[d]: airlied[d]: `glXBindTexImageEXT()` is the hole
00:14gfxstrand[d]: The plan assumed that we would get modifiers from nouveau GL and wouldn't have to deal with importing non-modifier dma-bufs
00:18gfxstrand[d]: The good news is that flatpak is wayland-only, I think.
00:18gfxstrand[d]: Right?
00:20ermine1716[d]: ^ said with Padme's face
00:20orowith2os[d]: gfxstrand[d]: Ha.
00:20orowith2os[d]: Haha.
00:20orowith2os[d]: Nice joke
00:20gfxstrand[d]: https://cdn.discordapp.com/attachments/1034184951790305330/1347000869316464720/9melfq.png?ex=67ca3bd1&is=67c8ea51&hm=44c2e5a5376305dc8bc9c921dc109c9afdbef2a73d5e3008075c00fedf2da900&
00:20gfxstrand[d]: ermine1716[d]: I was already working on the meme
00:21ermine1716[d]: gfxstrand[d]: great minds think alike
00:22orowith2os[d]: Every time I see messed up stuff that's only broken on X11, my first thought is always "thank god I don't use X11"
00:22ermine1716[d]: X11 doesn't understand modifiers?
00:22gfxstrand[d]: nope
00:22gfxstrand[d]: XWayland does but not plane ol' x11
00:22ermine1716[d]: geez
00:23gfxstrand[d]: Maybe I can not care about people using bare X11 and Flatpak?
00:23orowith2os[d]: That's what I'm saying :wires:
00:23gfxstrand[d]: Or at least tell them to sub in a Mesa 25.1 framework?
00:24mhenning[d]: yeah maybe we delete nouveau gl modifiers and hope things upgrade eventually
00:25gfxstrand[d]: No, we want nouveau GL modifiers
00:25gfxstrand[d]: What we don't want are the non-modifier buffers
00:25gfxstrand[d]: Those are the evil ones
00:27orowith2os[d]: Give me a patch and I can ask fd-sdk to ship it, if that's what you need
00:27mhenning[d]: ~~maybe we delete nouveau gl~~
00:27orowith2os[d]: orowith2os[d]: You'll probably be able to get 25 on 24.08, but not on 23.08, since it needs stuff that's too new.
00:28gfxstrand[d]: mhenning[d]: I'm working on it!
00:28redsheep[d]: You know, this is probably the worst idea imaginable but I bet there's some math you can do that recognizes the most likely formatting of the buffer and then you can correct how the driver uses it lol
00:28mhenning[d]: orowith2os[d]: It's possible a patch would backport cleanly
00:28gfxstrand[d]: redsheep[d]: Oh, we have the information to correct how the driver uses it. We just don't know when we would need to kick in that plan.
00:28redsheep[d]: If anything is drawn to it you can look for whatever is the least scrambled
00:28gfxstrand[d]: Like, the information is attached to the BO.
00:29gfxstrand[d]: In theory, we can fetch it out of there.
00:29redsheep[d]: Oh?
00:29gfxstrand[d]: But that's not the way Vulkan dma-buf import is supposed to work.
00:29gfxstrand[d]: That said...
00:30gfxstrand[d]: If we really really want this to work, I can look for the case where I'm handed a linear image and a tiled BO and re-jigger the image at bind time.
00:30gfxstrand[d]: I don't really *want* to do that but I could
00:31redsheep[d]: That sounds terrible, I like it
00:31gfxstrand[d]: Terrible is bad. 😛
00:31gfxstrand[d]: I could also come up with a terrible MESA extension to query a VkDeviceMemory object for its modifier.
00:32gfxstrand[d]: Or query a BO directly
00:32orowith2os[d]: The annoying decision to either buy a Nvidia laptop to help with more NVK dev, or an idle 650cc motorcycle with no key, no title, and no idea on if it runs for $700
00:33orowith2os[d]: ~~its a trick question, I ended up deciding on the motorcycle, if/when the guy texts me~~
00:33orowith2os[d]: :hammy:
00:33redsheep[d]: One of the two is safer
00:34orowith2os[d]: NVK might get rid of my sanity, motorcycle, uh, at least keeps a little
00:34orowith2os[d]: :thumbsup:
00:35redsheep[d]: Fair, nvk testing does have a tendency to make me feel like I'm losing my marbles after a few hours, and I really need those marbles not to get lost.
00:38gfxstrand[d]: gfxstrand[d]: I hate this idea but I also kinda love it.
00:38gfxstrand[d]: We already have
00:39gfxstrand[d]: `vkGetMemoryFdPropertiesKHR()`.
00:39gfxstrand[d]: What if we added a mesa-private but guaranteed stable chain-in which gives you a modifier back.
00:40gfxstrand[d]: This is a terrible, horrible, no good very bad idea.
00:40gfxstrand[d]: But it might solve the same problem with Intel if/when they ever flip to Zink
00:41redsheep[d]: Would that still mean the mesa inside the flatpak needs to be updated to work?
00:41gfxstrand[d]: nope
00:41mhenning[d]: VK_MESA_TERRIBLE_LEGACY_HACK
00:42redsheep[d]: Modifiers are very confusing. I feel like I have no mental model at all for this. Guess I don't really need one though as long as y'all understand it
00:46gfxstrand[d]: VK_MESA_legacy_dma_buf_modifier_query
00:46gfxstrand[d]: I'm going to draft it tomorrow
00:46gfxstrand[d]: Or at least prototype it
00:48gfxstrand[d]: I'm gonna go make supper before I get any more bad ideas.
00:51orowith2os[d]: gfxstrand[d]: Would Mesa 23 work?
00:51orowith2os[d]: I think that's what 23.08 ships, but I'll have to double check
00:52orowith2os[d]: I don't want you to bring up a solution that works for newer mesa, but ends up falling apart when you have someone running Firefox, which still hasn't updated to 24.08
00:53redsheep[d]: I don't think this part of nouveau gl has changed a whole lot, I doubt if any old version works at all that a couple years further back will make a difference
00:54redsheep[d]: In previous discussions it sounded like the issues that led to modifier hell have been there pretty well unchanged for many years
00:57redsheep[d]: Though if a distro isn't shipping a new enough kernel for the nvk modifier stuff to work I believe that creates a snag regardless. Actually that's an interesting question, would this mesa extension be able to help work around that limitation? I don't remember exactly what the issue with older kernels was
00:59redsheep[d]: Though probably irrelevant since nobody should ship a kernel that old and really new mesa together
01:22orowith2os[d]: redsheep[d]: Except for flatpak
01:22orowith2os[d]: Linux 5 with mesa 25 :blobcatnotlikethis:
01:24redsheep[d]: orowith2os[d]: If there's an issue at all it's with system mesa being really new but the kernel really old, I think really new flatpak mesa with old kernel and system mesa is probably fine?
01:25orowith2os[d]: I guess if someone's using flatpak on an old distro, they're probably using nouveau-gl, not nvk
01:25orowith2os[d]: So irrelevant?
01:26redsheep[d]: Yeah it won't be zink on the system so all of this is fine, u less like... I guess if nouveau gl got deleted eventually and the flatpak had to use zink inside. Idk that isn't really the same thing as what we're talking about
01:27orowith2os[d]: All paths lead to null ig
01:27redsheep[d]: And would maybe even be okay. Like I said modifiers are confusing so I'm not completely sure
03:01gfxstrand[d]: gfxstrand[d]: I'm hating this less and less the more I think about it. It sucks and I hate it but it's the only way to make Zink have the legacy behavior.
06:59jannau: orowith2os[d]: the asahi fdo flatpak extensions builds with sdk 23.08.28 and llvm18 / rust-stable a mesa snapshot from mid february, i.e. after 25.0 branching
09:01tiredchiku[d]: we are now on-par with nv prop perf
09:01tiredchiku[d]: in Killing Floor 1
09:06huntercz122[d]: tiredchiku[d]: cpu bound ig?
09:07tiredchiku[d]: https://cdn.discordapp.com/attachments/1034184951790305330/1347133393619521557/t2ExYia.png?ex=67cab73d&is=67c965bd&hm=ee7fd6df2794f6dc3897dccdec14c16151fb448bc0eda01dfd1ea52637ee126e&
09:07tiredchiku[d]: doesn't look like it
09:21huntercz122[d]: Killing Floor 1 also supports OpenGL iirc
09:25tiredchiku[d]: it does
09:26huntercz122[d]: does it perform well under Zink? :xenia_plead:
09:28tiredchiku[d]: will check in some time
12:27orowith2os[d]: Jannau: hm. I'll have to take a look then. I know I was hitting some 23.08 limitations (like Wayland-protocols) when I tried earlier.
12:34jannau: 23.08.28 (~4 weeks old) updated wayland-protocols to 1.40 https://gitlab.com/freedesktop-sdk/freedesktop-sdk/-/commit/ee9ab7ddc0d5e678f72d29ced8d8c50f8f8a2eeb so it might have been a timing issue if you tried with mesa 25.0 betas or rc
12:42orowith2os[d]: I tried just the other day with 25
12:42orowith2os[d]: I think it was wayland-protocols 1.41 I needed
12:45jannau: mesa 25.0 only needs 1.38. current mesa/main needs 1.41
12:49orowith2os[d]: 25-git :slowpoke:
12:49orowith2os[d]: Bleh
12:49orowith2os[d]: I think I still have my manifest lying around, unless I threw it out in favor of just forcing Firefox onto 24.08
15:19gfxstrand[d]: redsheep[d]: NVK without modifiers is fine. It just falls back to linear.
16:26asdqueerfromeu[d]: gfxstrand[d]: Do any applications actually use that?
16:40gfxstrand[d]: compositors do
16:46asdqueerfromeu[d]: gfxstrand[d]: So do they still use pbuffer-like operations?
19:35gfxstrand[d]: https://cdn.discordapp.com/attachments/1034184951790305330/1347291514119786579/snapshot.png?ex=67cb4a80&is=67c9f900&hm=ec0add2b80a2a1d319a0e195e3b0717716a651df976acc4268f63b99862d859e&
19:35gfxstrand[d]: There we go!
20:03karolherbst[d]: nice
20:35gfxstrand[d]: Now we all get to fight over whether or not the sins I had to commit are worth it.
23:55orowith2os[d]: gfxstrand[d]: Show us
23:55orowith2os[d]: :wires:
23:56orowith2os[d]: We shall be the judges of that
23:56orowith2os[d]: Well, actually, is this for Wayland or X@1?
23:56orowith2os[d]: *X11
23:57mhenning[d]: orowith2os[d]: the sins are here https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/33932
23:57mhenning[d]: and x11 was the motivator