<fdobridge>
<karolherbst> ohh right, because the gallium interface ain't great either
* fdobridge
<karolherbst> anyway
<fdobridge>
<karolherbst> should we add a `PIPE_HANDLE_USAGE_EXPLICIT_MODIFIER` or something?
<fdobridge>
<karolherbst> though...
<fdobridge>
<karolherbst> not sure if zink actually gives me one
<fdobridge>
<gfxstrand> And if you stomp to linear in the CL implementation, that will very much NOT match Vulkan and it'll be broken.
<fdobridge>
<karolherbst> though maybe I also don't really understood what's the issue there
<fdobridge>
<karolherbst> ....
<fdobridge>
<karolherbst> maybe I avoid that ext for now
<fdobridge>
<karolherbst> I'd rather add a VK_MESA_external_memory_metadata ext holding all the necessary information or something, though zink might also not be able to make much use of it anyway 🙃
<fdobridge>
<karolherbst> I entirely understand why it's all implicit, because getting people to agree on how it all has to look like is a mess, because you have Intel with it's aux buffers and.... mipmaps are a disaster anyway
<fdobridge>
<karolherbst> cl_gl_sharing allows importing mipmapped textures and like....
<fdobridge>
<karolherbst> pain
<fdobridge>
<karolherbst> the fun part is, you can either import one specific level, or up to a specific level starting from 0
<fdobridge>
<gfxstrand> There really are only 4 options:
<fdobridge>
<gfxstrand> 1. Share the pipe_resource (the old interop)
<fdobridge>
<gfxstrand> 2. Make assumptions about the two drivers (VK interop)
<fdobridge>
<gfxstrand> 3. Properly versioned metadata. Basically the only proven solution to this is modifiers.
<fdobridge>
<gfxstrand> 4. Everything is linear
<fdobridge>
<karolherbst> 1. doesn't exist
<fdobridge>
<karolherbst> what we are doing atm is a variant of 3.
<fdobridge>
<gfxstrand> Without proper versioning? 😛
<fdobridge>
<karolherbst> with versioning
<fdobridge>
<karolherbst> bumped it a few times, thing is, it's external API at this point 🙃
<fdobridge>
<karolherbst> ROCm and Intel NEO use the private mesa extension for their gl_sharing impl
<fdobridge>
<gfxstrand> 🤡
<fdobridge>
<karolherbst> but it's versioned
<fdobridge>
<karolherbst> and we added a bunch of stuff to make it suck less
<fdobridge>
<karolherbst> thing is
<fdobridge>
<karolherbst> for native driver it works great, because they can just tell all the metadata, which we then can give to the driver on import and they know what to do.
<fdobridge>
<Owo> watch me submit a change that breaks them, for funsies
<fdobridge>
<karolherbst> oh no
<fdobridge>
<gfxstrand> PSA for those testing Zink: My zink/all-the-fixes now contains the above revert so it should work with KWin
<fdobridge>
<karolherbst> anyway.. we do 3 with modifiers and a bunch of more stuff
<fdobridge>
<karolherbst> the old school way of doing 3 was ROCm using it, but then call gl* APIs on the CL side messing with the current bound gl context and....
<fdobridge>
<karolherbst> so everything they didn't fetch via the private API they fetched via gl API calls
<fdobridge>
<karolherbst> it was a disaster
<fdobridge>
<karolherbst> and broken
<fdobridge>
<karolherbst> maybe I should indeed bump the private ext and just have a field for "gimme the pipe_resource"
<fdobridge>
<karolherbst> but...
<fdobridge>
<karolherbst> well.. maybe it's fine, but I'll kill the first dev to make use of the pipe_resource stuff outside of mes,a lol
<fdobridge>
<karolherbst> .....
<fdobridge>
<karolherbst> @zmike. ... I have a wild idea
<fdobridge>
<gfxstrand> Okay, I think I might have a patch Mike hates less
<fdobridge>
<zmike.> Oh I just assigned
<fdobridge>
<zmike.> :fullheadache:
<fdobridge>
<gfxstrand> That's fine. I think revert for now and try again is a good plan.
<fdobridge>
<karolherbst> there is `pipe_screen::interop_export_object`
<fdobridge>
<karolherbst> though not sure how to use it...
<fdobridge>
<karolherbst> clon12 uses it to simply share the `ID3D12Resource` object through it
<fdobridge>
<karolherbst> could use it to simply share the pipe_resource
<fdobridge>
<karolherbst> or something more stable
<fdobridge>
<karolherbst> like some vulkan handle
<fdobridge>
<karolherbst> and then instead of dma-buf you'd use the vulkan API object
<fdobridge>
<karolherbst> dunno
<fdobridge>
<gfxstrand> That requires both to be running on the same VkDevice
<fdobridge>
<gfxstrand> But if they share a zink_screen, they already are, I think.
<fdobridge>
<karolherbst> they don't share a zink_screen
<fdobridge>
<gfxstrand> Bummer
<fdobridge>
<karolherbst> yeah...
<fdobridge>
<zmike.> Doesn't matter as long as they're both zink using the same physical device
<fdobridge>
<gfxstrand> Yeah.
<fdobridge>
<zmike.> In the same process
<fdobridge>
<gfxstrand> You can do OPAQUE_FD import/export
<fdobridge>
<zmike.> Whatever I don't think this is the biggest perf bottleneck anyway
<fdobridge>
<karolherbst> yeah...
<fdobridge>
<gfxstrand> But if it's Vulkan on both sides, OPAQUE_FD is safe
<fdobridge>
<karolherbst> I'm not checking if the driver_uuid matches yet, but I'm planning to check for it
<fdobridge>
<karolherbst> because if it's different drivers, it's kinda broken in weirdo ways
<fdobridge>
<gfxstrand> Yeah
<fdobridge>
<karolherbst> but yeah, in theory we have a mechanism to share driver private data, just the thing is, that even zink doesn't know of the driver private data 🙃
<fdobridge>
<gfxstrand> Yeah
<fdobridge>
<gfxstrand> But if it's Zink on both sides, you can just trust Vulkan sharing
<fdobridge>
<karolherbst> anyway, I created a great meme after it all worked, and nobody will be able to take away that from me, lol
<fdobridge>
<gfxstrand> The driver private data becomes whatever Zink puts in the `VkImageCreateInfo`.
<fdobridge>
<gfxstrand> Anyway... I need to go cook supper
<fdobridge>
<karolherbst> have fun
<fdobridge>
<karolherbst> but yeah.. could add the driver_uuid and if that one matches, I could make use of the `interop_export_object` hook to share secret data... I kinda like the plan even though I also hate it
<fdobridge>
<zmike.> @gfxstrand sure would be great if we had a piglit test to check this gbm behavior and ensure it doesn't regress
<fdobridge>
<gfxstrand> `create_bo(); get_modifier() == INVALID`. There you go!
<fdobridge>
<zmike.> Dang CI bounced you again
<fdobridge>
<gfxstrand> 😡
<fdobridge>
<Owo> What's that, the fourth time?
<fdobridge>
<Owo> :frog_gears:
karolherbst has quit [Read error: Connection reset by peer]
karolherbst has joined #zink
<fdobridge>
<Sid> :BlobhajShock:
<fdobridge>
<Sid> you guys have been productive while I was asleep for all of 5 hours lol
<fdobridge>
<Sid> but rad
<fdobridge>
<Sid> that the issue was figured out
<fdobridge>
<Owo> yeah, and now I'm writing a gallium frontend :p
<fdobridge>
<Sid> confirmed, using `nouveau.atomic=1` actually fixes kwin wayland on the same commit I tried yesterday
<fdobridge>
<!DodoNVK (she) 🇱🇹> Actually the layer calls `wl_display_dispatch()` (which I guess is translated to the queue function in `wayland-client`)
<fdobridge>
<!DodoNVK (she) 🇱🇹> And that Wayland call calls the `poll()` function (which I guess freezes somehow)
<fdobridge>
<fooishbar> it's a pretty well-known issue: in order to pick the 'best' device, the device-select layer goes to ask the compositor which one it's using as its primary device. so you end up stuck in vkEnumeratePhysicalDevices(), because the device-select layer is waiting for your compositor to answer it, but your compositor is waiting for vkEnumeratePhysicalDevices to complete
<fdobridge>
<zmike.> almost everything landed overnight 🎉
<fdobridge>
<gfxstrand> Yay! Damage landed!
<fdobridge>
<gfxstrand> Now we wait for the iris bug reports to roll in...
<fdobridge>
<gfxstrand> What else should I be looking into RE Zink+NVK?
<fdobridge>
<gfxstrand> IDK if that's the problem. :shrug_anim:
<fdobridge>
<redsheep> You're experiencing two different issues though, right? You aren't have it open at all, but @mhenning gets a black window last I saw
<fdobridge>
<redsheep> You're experiencing two different issues though, right? You aren't having it open at all, but @mhenning gets a black window last I saw (edited)
<fdobridge>
<gfxstrand> :shrug_anim:
<fdobridge>
<gfxstrand> Won't know until we figure out both issues.
<fdobridge>
<gfxstrand> But yeah they look different.
<fdobridge>
<gfxstrand> What I do know about my issue is that steam isn't even loading Zink.
<fdobridge>
<gfxstrand> Wait, what?!? It is loading a driver
<fdobridge>
<redsheep> Do you have the Nvidia drivers installed at all? There's a whole variety of issues that conjures up
<fdobridge>
<gfxstrand> nope
<fdobridge>
<gfxstrand> Yeah, it's definitely getting classic nouveau somehow.
<fdobridge>
<gfxstrand> Installed my 32-bit mesa to the wrong spot
<fdobridge>
<gfxstrand> Steam works great
<fdobridge>
<gfxstrand> But @mhenning said she was using a dgpu+igpu setup?
<fdobridge>
<gfxstrand> let me reboot and turn my igpu back on
<fdobridge>
<gfxstrand> Steam works fine displaying on my AMD gpu and running on my 4060 with `DRI_PRIME=1`
<fdobridge>
<gfxstrand> My desktop is running shockingly well
<fdobridge>
<gfxstrand> I'm not seeing that flicker here. But also, it's a desktop and Steam was the first thing I launched so likely lots of already zeroed VRAM.
<fdobridge>
<gfxstrand> Installing Discord...
<fdobridge>
<gfxstrand> @redsheep How do I tell flatpak to use my system GL/Vulkan?
<fdobridge>
<redsheep> I use the native package on arch so I don't have to mess with that
<fdobridge>
<gfxstrand> Looks like that's all very recent
<fdobridge>
<Sid> `flatpak install --user fedora org.fedoraproject.Platform.GL.host` I think
<fdobridge>
<Sid> and org.fedoraproject.Platform.GL32.host for the 32-bit ones
<fdobridge>
<Sid> might have to replace `fedora` w/ whatever the fedora-flatpaks remote is called
<fdobridge>
<gfxstrand> error: Nothing matches org.fedoraproject.Platform.GL.host in remote fedora
<fdobridge>
<Sid> bah, might be a `Fedora Asahi Remix` only thing for now then
<fdobridge>
<gfxstrand> Yeah. I think I need to either find a native version of the Discord app or I need to figure out how to build org.freedesktop.Platform.GL.
<fdobridge>
<gfxstrand> flatpak was a mistake
pac85 has joined #zink
<fdobridge>
<gfxstrand> Looks like it's in rpmfusion
<fdobridge>
<Sid> they also distribute an official .rpm on their website
<fdobridge>
<gfxstrand> Okay. I'm typing this message from discord on my desktop which I think is running on Zink+NVK but I'm not sure.
<fdobridge>
<gfxstrand> Yeah, looks like it. I got a Vulkan splat when I threw in a `VK_LOADER_DEBUG=all`
<fdobridge>
<gfxstrand> No corruption, though.
<fdobridge>
<redsheep> Hmm. Very strange
<fdobridge>
<gfxstrand> How long does it take you to see corruption?
<fdobridge>
<Owo> Let me know what you need (send me meson build args) and I'll pass you a manifest
<fdobridge>
<Sid> fwiw it works perfectly fine for me on zink
<fdobridge>
<Sid> like, I've been maining Plasma Wayland w/ zink+nvk for a fair few days now with no issues apart from that tiling thing we ran into
<fdobridge>
<Sid> oh and suspend being wonky 50-50
<fdobridge>
<Sid> it *could* be an issue that only manifests on the bigger GPUs since I know redsheep has a 4090
<fdobridge>
<mhenning> Oh, I don't have flicker any more, it just renders a black screen all the time. The menus work fine though
<fdobridge>
<gfxstrand> Huh. Runs great for me once I got it running on the right drivers.
<fdobridge>
<gfxstrand> I do think we might have a problem with nouveau classic running on NVK, though. I need to look at that combo.
<fdobridge>
<gfxstrand> Yeah, I've had faults waking up from suspend. I think those are kernel bugs, though.
<fdobridge>
<Sid> yup
<fdobridge>
<Sid> I don't think I've had dealbreaker issues on wayland on my 3070, ever
<fdobridge>
<gfxstrand> Maybe I should try to test x11?
<fdobridge>
<Sid> certainly
<fdobridge>
<Sid> on x11 I see the same flickers that redsheep does
<fdobridge>
<gfxstrand> Kk
<fdobridge>
<gfxstrand> Plasma or gnome?
<fdobridge>
<redsheep> 5-10 seconds. Far faster than the old bug that's gone now
<fdobridge>
<redsheep> Sid is generally on plasma
<fdobridge>
<Owo> re: performance: no problems now.
<fdobridge>
<Owo> might've just been a one-time thing
<fdobridge>
<gfxstrand> I'm seeing plasma itself corrupt on X11
<fdobridge>
<gfxstrand> But also x11 seems to think I'm running at 1024x768. 😭
<fdobridge>
<gfxstrand> Oh, wait... I'm still plugged into my igpu
<fdobridge>
<gfxstrand> Ugh... Mesa 25.0.1 is missing the damage MR.
<fdobridge>
<gfxstrand> Maybe it's because I'm using startx?
<fdobridge>
<gfxstrand> Okay, I think I'm live from Discord on Plasma+X11
<fdobridge>
<gfxstrand> Not corruption per se but Discord seems to go back a frame or two every so often.
<fdobridge>
<gfxstrand> Like when I'm typing, the cursor will occasionally go backwards. IDK if that's bad damage or bad buffer age.
<fdobridge>
<gfxstrand> I'm not seeing persistent corruptions, though.
<fdobridge>
<gfxstrand> Plasma is no longer corrupting once I installed the right package with all the X11 stuff. I think that was me trying to run Wayland plasma on top of X11 or somesuch nonsense.
<fdobridge>
<gfxstrand> But we definitely have some sort of buffer age problem.
<fdobridge>
<Owo> what about in another electron app, or chomium?
<fdobridge>
<Owo> Firefox? GTK?
<fdobridge>
<Owo> (GTK you'll need to override it to the ngl backend)
<fdobridge>
<gfxstrand> Yeah, definitely seeing some jitter with chromium
<fdobridge>
<gfxstrand> Do I want to know what kind of madness is kopper+x11 wsi?
<fdobridge>
<Owo> ~~close as WONTFIX and tell everyone to just use a rootful xwayland session~~
<fdobridge>
<Owo> and wayland shenanigans (though I think those are a bit easier)
<fdobridge>
<gfxstrand> Wayland is way less rough on your GL driver than X11
<fdobridge>
<Owo> I've heard horror stories about X11
<fdobridge>
<Owo> xf86 drivers, the API itself, scaling, multi monitor....
<fdobridge>
<Owo> *gestures*
<fdobridge>
<gfxstrand> Okay, I've played a bit with one of the Sascha demos and it runs smooth so I don't think the issue is plasma itself. It's probably something with the client app
<fdobridge>
<gfxstrand> Yeah, so something is going wrong with kopper
<fdobridge>
<gfxstrand> It's presenting the wrong frames
<fdobridge>
<gfxstrand> But why that would be different under X11 vs. wayland, I have no idea.
<fdobridge>
<gfxstrand> Especially when "raw" vulkan works fine.
<fdobridge>
<gfxstrand> I'm not seeing any corruption, though.
<fdobridge>
<Owo> explicit sync?
<fdobridge>
<Owo> (or just sync in general)
<fdobridge>
<gfxstrand> Yeah, maybe?
<fdobridge>
<gfxstrand> But everything with X11 should be implicit
<fdobridge>
<Owo> *is* it using explicit sync on the wayland side, and if you turn it off if so, does it go wonky?
<fdobridge>
<gfxstrand> But sync issues are certainly possible. It's just weird that they'd be on the client side.
<fdobridge>
<Owo> I'd want to make sure it's something to do with sync before continuing
<fdobridge>
<Owo> maybe try Xwayland too
<fdobridge>
<gfxstrand> Well this is fun... chromium isn't using Zink. It's using ANGLE
<Sachiel>
that's shocking
<fdobridge>
<Owo> ah.
<fdobridge>
<Owo> not really.
<fdobridge>
<Owo> I forget that Chromium has ANGLE at its disposal
<fdobridge>
<Owo> webkit too, actually...
<fdobridge>
<Owo> I think Firefox is the only one that *doesn't* use ANGLE
<fdobridge>
<gfxstrand> If I disable Vulkan in chromium, it goes back to Zink and everything is smooth as silk.
<fdobridge>
<gfxstrand> If I enable Vulkan and it uses ANGLE, I get massive jitter
<fdobridge>
<zmike.> :lul:
<fdobridge>
<gfxstrand> I have no idea what Discord is using
<fdobridge>
<Owo> Angle on Chromium would be going on top of NVK, right?
<fdobridge>
<gfxstrand> yes
<fdobridge>
<gfxstrand> I mean, everything on my system is on top of NVK at the moment
<fdobridge>
<Owo> does the `chrome://flags/#use-angle` bit still exist, or did it at all, on Linux? I know ANGLE has a GL backend you might be able to try and double check with
<fdobridge>
<gfxstrand> Nah, the bit is gone
<fdobridge>
<Owo> damn
<fdobridge>
<gfxstrand> But I doubt ANGLE would screw that up on top of GL
<fdobridge>
<Owo> yeah, it might be something in how Chromium is doing Vulkan
<fdobridge>
<Owo> :wires:
<fdobridge>
<Owo> or, well, angle, I guess
<fdobridge>
<gfxstrand> Okay, discord is running on Zink and I'm still seeing the glitches.
<fdobridge>
<gfxstrand> I know because I have debug prints in zink
<fdobridge>
<gfxstrand> I guess it's also possible that the frame order being submitted to X11 is fine and that the real problem is a race between Zink and the compositor where the compositor is getting in there and compositing before Zink renders its frame.
<fdobridge>
<gfxstrand> That's sounding very plausible
<fdobridge>
<Owo> would that issue repro under Wayland (without explicit sync) though?
<fdobridge>
<gfxstrand> Possibly.
<fdobridge>
<gfxstrand> Is there an easy way to disable that on plasma?
<fdobridge>
<Owo> not sure about plasma, but I'm looking into mutter's side of things right now
<fdobridge>
<Owo> so, how adverse are you to rebuilding your compositor
<fdobridge>
<gfxstrand> fairly
<fdobridge>
<gfxstrand> I mean, I will if I have to but I don't think I have to so I'm going to avoid it for a bit
<fdobridge>
<Owo> yeahhh, I'm not seeing anything in the way of env vars in kwin and mutter
<fdobridge>
<Owo> `WLR_RENDER_NO_EXPLICIT_SYNC=1` exists for wlroots if you can repro on Sway or smth
<fdobridge>
<gfxstrand> Ugh... chromium without ANGLE is super stable
MTCoster has joined #zink
<fdobridge>
<gfxstrand> Never mind. The fish are stable. The UI isn't
<fdobridge>
<gfxstrand> Yeah, if you go to the chrome://flags and play with a dropdown, it's super all over the place
<fdobridge>
<gfxstrand> And NOUVEAU_USE_ZINK=0 when kwin is running with zink is insta-death
<fdobridge>
<gfxstrand> Good to know.
<fdobridge>
<gfxstrand> Let's fix that one.
<fdobridge>
<redsheep> It's not currently persistent corruption for me, it's like... Sections of UI blinking in and out of existence. The cross monitor/process corruption is always very brief.
<fdobridge>
<redsheep> Also wasn't there something about x11 explicit sync being a thing a while back?
<fdobridge>
<gfxstrand> NVIDIA keeps trying to make it happen