ChanServ changed the topic of #zink to: official development channel for the mesa3d zink driver || https://docs.mesa3d.org/drivers/zink.html
Dark-Show has joined #zink
gfxstrand is now known as Guest10819
gfxstrand has joined #zink
Guest10819 has quit [Ping timeout: 480 seconds]
<fdobridge> <h​untercz122> Oh
<fdobridge> <g​fxstrand> Okay, I've confirmed that Zink isn't barriering images properly. Now the question is why
<fdobridge> <g​fxstrand> @zmike. I'm pretty sure the problem with X11 sync is that we're not doing QUEUE_FAMILY_FOREIGN transfers on the BOs that get imported via `glXBindTexImageEXT()`
<fdobridge> <g​fxstrand> I see the code that should be triggering but I'm having trouble tracking down why it isn't
<fdobridge> <f​ooishbar> you can't really do QFOT and handoff
<fdobridge> <g​fxstrand> You can. You have to do it every submit
<fdobridge> <f​ooishbar> yep on the compositor, which is easy enough since it came from BindTexImage, but harder from the xserver since it's just an arbitrary GBM BO
<fdobridge> <g​fxstrand> The sync issue I'm seeing is in the compositor, I think.
<fdobridge> <g​fxstrand> But it's the same story for both. QFOT both ways on every `vkQueueSubmit()`.
<fdobridge> <g​fxstrand> As long as we only submit in `glFlush()`, that's fine
<fdobridge> <g​fxstrand> For actual winsys things, we have more information
<fdobridge> <g​fxstrand> And we have code which looks like it does this... except it doesn't.
<fdobridge> <f​ooishbar> I think you'd want something like a new gbm_bo_create flag in glamor_make_pixmap_exportable to indicate that it's ... well it's basically the shared_present layout tbh
<fdobridge> <g​fxstrand> I *think* Zink is already trying to do that with anything that's a dmabuf
<fdobridge> <g​fxstrand> We're adding things to a hash set while iterating it...
<fdobridge> <g​fxstrand> I need to look at a dma-buf piglit test, I think.
<fdobridge> <g​fxstrand> I'm very sure Zink's `dmabuf_exports` thing is broken. I just don't know why
f_ is now known as funderscore
funderscore is now known as f_
f_ is now known as funderscore
<fdobridge> <g​fxstrand> Found it!
<fdobridge> <g​fxstrand> Well, found one of the bugs anyway. :frog_upside_down:
<fdobridge> <g​fxstrand> But not THE bug, sadly.
<fdobridge> <z​mike.> ?
<fdobridge> <z​mike.> hm
<fdobridge> <z​mike.> for reusing across batches?
<fdobridge> <z​mike.> annoying
<fdobridge> <g​fxstrand> It's fine for Wayland because it always re-imports the dma-buf every frame so it's always fresh and never bound.
<fdobridge> <z​mike.> yeah, that was the assumption
<fdobridge> <g​fxstrand> X doesn't re-import
<fdobridge> <z​mike.> makes sense
<fdobridge> <g​fxstrand> But also I expect X compositors are binding a lot of different textures so they *should* hit the image barrier path anyway
<fdobridge> <g​fxstrand> Something is still missing
<fdobridge> <g​fxstrand> Okay, sync is fixed. Now to figure out why cursor images are wrong.
<fdobridge> <g​fxstrand> I'll make an MR once GitLab stops being a pig and believes that the branch I just pushed actually exists
<fdobridge> <g​fxstrand> Happy birthday!
<fdobridge> <g​fxstrand> I have no idea what's wrong with cursors. Honestly, I'm starting to suspect the kernel.
<fdobridge> <z​mike.> good work
<fdobridge> <z​mike.> what was the scenario for the second case?
<fdobridge> <z​mike.> @gfxstrand ^
<fdobridge> <g​fxstrand> The first case is
<fdobridge> <g​fxstrand> ```
<fdobridge> <g​fxstrand> glXBindTexImageEXT();
<fdobridge> <g​fxstrand> glBindTexture();
<fdobridge> <g​fxstrand> glDraw();
<fdobridge> <g​fxstrand> glFlush();
<fdobridge> <g​fxstrand> // something
<fdobridge> <g​fxstrand> glDraw();
<fdobridge> <g​fxstrand> ```
<fdobridge> <z​mike.> right
<fdobridge> <g​fxstrand> The second case is
<fdobridge> <g​fxstrand> ```
<fdobridge> <g​fxstrand> glXBindTexImageEXT(tex);
<fdobridge> <g​fxstrand> glBindTexture(tex);
<fdobridge> <g​fxstrand> glDraw();
<fdobridge> <g​fxstrand> glFlush();
<fdobridge> <g​fxstrand> // something
<fdobridge> <g​fxstrand> glBindTexture(other_tex);
<fdobridge> <g​fxstrand> // Oops! The bind pulled it out of the needs_barrier set
<fdobridge> <g​fxstrand> glDraw();
<fdobridge> <g​fxstrand> // And this one won't put it back in because we don't check queues here
<fdobridge> <g​fxstrand> glBindTexture(tex);
<fdobridge> <g​fxstrand> glDraw();
<fdobridge> <g​fxstrand> ```
<fdobridge> <z​mike.> hm
<fdobridge> <z​mike.> the last BindTexture should trigger a barrier on bind though?
<fdobridge> <g​fxstrand> That's what my 2nd patch fixes
<fdobridge> <g​fxstrand> It will trigger a barrier if a layout has changed or something. But the "or something" didn't include a queue check.
<fdobridge> <z​mike.> where is it being called from?
<fdobridge> <g​fxstrand> That's being called from all the tex/image validate code
<fdobridge> <g​fxstrand> or tex/image bind, rather
<fdobridge> <z​mike.> ah, okay, I misremembered how I wired that up
* fdobridge <z​mike.> adds a mental note
<fdobridge> <z​mike.> good find
<fdobridge> <g​fxstrand> And we figured out the cursor problem.
<fdobridge> <g​fxstrand> Zink is all fixed now. There are no more bugs. Time to write the blog post.
<fdobridge> <z​mike.> way too late in the day/week for that
<fdobridge> <z​mike.> maybe monday
<fdobridge> <g​fxstrand> Yeah, that's my Monday project
<fdobridge> <g​fxstrand> Gotta justify my paycheck!
xroumegue has quit [Ping timeout: 480 seconds]
<fdobridge> <z​mike.> well if all the bugs are fixed then that frees me up even more to take the chainsaw to other parts of mesa
<fdobridge> <g​fxstrand> Oh, no!
<fdobridge> <m​henning> bugs fixed? gotta make new bugs
<fdobridge> <g​fxstrand> `rm -r src/gallium/drivers/radeonsi`?
<fdobridge> <z​mike.> nah I gotta have a reference
<fdobridge> <z​mike.> the next phase is closing the cpu perf gap
<fdobridge> <g​fxstrand> `rm -r src/gallium/drivers/iris`, then?
<fdobridge> <z​mike.> ideally, though probably need to get uhhh
* fdobridge <z​mike.> searches
<fdobridge> <z​mike.> then I'll know how much pushconst space I have left for doing the intel ubo->pc optimization, though I think it'll need all of the spec min
<fdobridge> <z​mike.> then again who knows if anyone would even care?
xroumegue has joined #zink
<fdobridge> <g​fxstrand> The next question is: Do I care enough to block `NOUVEAU_USE_ZINK` on fixing the crazy Flatpak corner case?
<fdobridge> <g​fxstrand> Or do Flatpak users get the issues they've been asking for?
<fdobridge> <z​mike.> which corner case was that again
<fdobridge> <g​fxstrand> non-modifier magic-tiled dma-buf import
<fdobridge> <z​mike.> ah
<fdobridge> <g​fxstrand> Which we can mostly avoid with a glamor patch but can't ever totally avoid.
<fdobridge> <g​fxstrand> And for which I wrote the extension @fooishbar hates
<fdobridge> <g​fxstrand> Which does solve it completely at the cost of a Vulkan extension and a fairly small bit of driver code.
<fdobridge> <z​mike.> maybe just push that through and only enable for zink
<fdobridge> <g​fxstrand> We could also do a mesa-private thing that we just declare stable for all of time until Zink doesn't need it.
<fdobridge> <z​mike.> works for me, though VVL will scream until the end of time
<fdobridge> <g​fxstrand> lol
<fdobridge> <g​fxstrand> I don't actually hate the way the Vulkan extension turned out. As new solutions to ancient problems go, it's pretty surgical.
<fdobridge> <z​mike.> seems fine to me if the problem needs a Production-Ready Fix