ChanServ changed the topic of #zink to: official development channel for the mesa3d zink driver || https://docs.mesa3d.org/drivers/zink.html
chiku has joined #zink
Sid127- has quit [Ping timeout: 480 seconds]
Sid127 has quit [Read error: Connection reset by peer]
Sid127 has joined #zink
_whitelogger has joined #zink
<fdobridge> <g​fxstrand> Trying to detangle Kopper... I don't see a reason why Kopper can't work on both the DRM and SWRast paths
<fdobridge> <z​mike.> is the solution to finding a bug really to always rewrite everything?
<fdobridge> <g​fxstrand> In this case, I'm not sure there's another way.
<fdobridge> <g​fxstrand> Something is going to have to be refactored. The question is what and how
<fdobridge> <g​fxstrand> The real problem, TBH, is that we have two paths at all
<fdobridge> <g​fxstrand> Trust me. If there were a quick fix that would let me touch *less* EGL code, I would take that path in a heartbeat.
<fdobridge> <g​fxstrand> I hate EGL...
<fdobridge> <g​fxstrand> There are so many layers of broken...
<fdobridge> <m​ango> so *is* [this](https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/35940) a good mr to upgrade to? or should i wait because it may've broken things
<fdobridge> <g​fxstrand> :shrug_anim:
<fdobridge> <m​ango> okay
<fdobridge> <m​ango> was wondering if all the egl jank was in general, or from the recent mr
<fdobridge> <m​ango> i'll probably upgrade rn because i'm desperate for sync 😭
<fdobridge> <g​fxstrand> general
<fdobridge> <m​ango> fair
<fdobridge> <m​ango> ~~i've noticed~~
<fdobridge> <m​ango> egl is jank though
<fdobridge> <m​ango> and yet every desktop uses it :/
<fdobridge> <m​ango> new commit feels *substantially* better already
<fdobridge> <m​ango> cursor feels way less stutter prone
<fdobridge> <m​ango> before, any remote spike in gpu usage would cause the cursor plane to stutter
<fdobridge> <m​ango> i've barely noticed any cursor lag so far, hoping for the best
<fdobridge> <m​ango> not perfect, but as the mr name implied, it's a good bit of improvement
karolherbst has quit [Read error: Connection reset by peer]
<fdobridge> <g​fxstrand> What the hell is Kopper DRI2. There is no such thing as DRI2 with Vulkan WSI so there can't possibly be DRI2 with Kopper.
karolherbst has joined #zink
<fdobridge> <g​fxstrand> What the hell is Kopper DRI2?!? There is no such thing as DRI2 with Vulkan WSI so there can't possibly be DRI2 with Kopper. (edited)
<fdobridge> <g​fxstrand> Okay, the world is starting to make sense again... In the worst possible way.
<fdobridge> <k​arolherbst> and here I thought that's impossible with wsi
<fdobridge> <g​fxstrand> The world making sense? Oh, it can happen but only after you've gone batshit crazy.
<fdobridge> <k​arolherbst> well.. at least you don't have to debug LLVM/SPIR-V stuff, because I just hit the most annoying and the most frustrating bug caused by LLVM of all time
<fdobridge> <g​fxstrand> I'm not sure that's worse...
<fdobridge> <k​arolherbst> it is
ced117 has quit [Remote host closed the connection]
ced117 has joined #zink
<fdobridge> <k​arolherbst> I want to implement global vars, and.... llvm-20 decided that sometimes to add padding to the var, so now one spir-v accesses the var without padding, and the other one is. And now I have to figure out how to link it all together, because the deref chains are all like.. broken if I pick one over the other type :)... okay maybe it's not as bad as your issue, but I'm going crazy over this one already
<fdobridge> <k​arolherbst> "adding padding" as in.. in one version it's implicit, in the other it's explicit
<fdobridge> <k​arolherbst> magically
<fdobridge> <g​fxstrand> I'm sure untyped pointers will fix this. 🤡
<fdobridge> <k​arolherbst> yeah..... so the reason this happens is that in one module the global var has an initializer and the padding is set to 0 🙂
<fdobridge> <k​arolherbst> maybe there is a magic clang flag I can set...
<fdobridge> <z​mike.> it's just misnamed