ChanServ changed the topic of #zink to: official development channel for the mesa3d zink driver || https://docs.mesa3d.org/drivers/zink.html
fahien has joined #zink
fahien1 has joined #zink
fahien has quit [Ping timeout: 480 seconds]
fahien1 is now known as fahien
neobrain has joined #zink
<neobrain> Hi! Are there up-to-date instructions on how to setup and use zink for development? I only found that Collabora blog post from years ago, but it seems that nowadays Kopper is required (or at least glxinfo complains about "mesa: Kopper interface not found")
<zmike> you have to use the same libGLX that comes with your zink .so
<neobrain> I built zink from source. Is libGLX part of mesa or is that in a different repo?
<zmike> part of mesa
<zmike> usually you would do something like LD_LIBRARY_PATH=$libdir
<neobrain> Looks like there's no libGLX.so in my build folder, despite glx being set to "auto"
<ajax> if you have a live meson build tree, you can do 'meson devenv -C ~/git/mesa/zink-build glxinfo' and it'll get all the library path stuff right
<ajax> it's only named libGLX.so if you built with glvnd=true, otherwise it's just libGL.so
<ajax> (and it'd be libGLX_mesa.so technically)(
<zmike> ajax: here's a weird one I'm investigating - piglit/bin/glx-swap-copy
<zmike> maybe I'm not understanding the test but I don't see how this could ever pass?
<neobrain> ajax: with that devenv command I'm getting "glx: failed to create drisw screen" :D
<ajax> neobrain: what kind of xserver config?
<zmike> it does a clear -> swapbuffers swapbuffers swapbuffers -> read backbuffer -> read frontbuffer, and it expects front and back to both have the same color from the clear?
<neobrain> uhm, default one in Ubuntu, running in a VM without hw acceleration
<neobrain> (well, actually virgl)
<zmike> did you build llvmpipe/lavapipe?
<neobrain> yes, those are enabled and functional
* neobrain tries building with glvnd
<neobrain> ok well, with glvnd I'm getting the same output as with the `meson devenv` command :)
<ajax> neobrain: can you try devenving 'strace -o /tmp/glxinfo.t glxinfo' instead, and pastebin the trace file?
<ajax> zmike: if they were exchange swaps, then after the third swap you'd have the initial (undefined) front buffer contents in your back buffer
<zmike> so then how are the front and the back supposed to have the same contents?
<ajax> but if they're blit swaps, you'd expect the back to be unmodified by swapping, but the first swap would make it match the back
<zmike> huh
<ajax> swap method is a property of the fbconfig (in GLX_OML_swap_method, which i kind of detest)
<zmike> right, and that's what this test is testing
<zmike> I think this may be a kopper bug
<zmike> because the swaps occur with no context current
<zmike> and kopper does if (!ctx) return
<ajax> uggggh.
<ajax> fuck you glx
<zmike> amen
<ajax> stupid fucking feature, that
<zmike> so with that diagnosis I'm gonna push https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/17590 through and mark that test as a fail since it's probably passing erroneously now
<ajax> ack
<ajax> or, better, we could just not expose that extension
<zmike> probably we want to expose the same extensions real drivers have?
<zmike> though I guess until it's functional not exposing it is viable
<ajax> it ties the implementation's hands in really unpleasant ways, and nobody can seriously depend on it because nvidia doesn't implement it
<ajax> personally i'd prefer to remove it from all the backends, kopper or dri
<ajax> word. i'll rant there.
<ajax> i really wish xcb wasn't so malloc-happy
<ajax> really prefer vulkan's caller-allocates callee-fills style
<ajax> (bad adam, stop designing x11 protocol bindings)
<zmike> hm
<zmike> I'm trying out the EGL buffer age tests in cts and they're still failing
<ajax> fun
<ajax> do i even have that built anywhere
<zmike> dunno
<zmike> do you have cts built with egl config?
<ajax> ... from like 2019?
<zmike> I think that year was a good vintage
<ajax> got a cheat sheet for building it handy or shall i google myself
<zmike> yea
<zmike> uhh
<zmike> cmake .. -DDEQP_TARGET=x11_egl_glx -GNinja
<zmike> assuming you have first done python external/fetch_sources.py
<neobrain> Woo, got it working. zink_internal_create_screen fails unless LIBGL_ALWAYS_SOFTWARE=1 is set. I'm guessing that's intentional, though in my case it broke things since sw is the only available renderer :)
<neobrain> actually, no wait, I guess that just disables zink and uses gl sw rendering, doesn't it?
<zmike> you would need both that and the usual mesa loader env var
<neobrain> oh ok. So it is using zink indeed then? (glxinfo indicates so, anyway)
<zmike> yep
<neobrain> neato
<ajax> woo, got it built and definitely seeing the buffer age fails
<zmike> \o/
<zmike> ajax: got a couple small zink MRs up
<ajax> !17634 is the gift that keeps on giving
<zmike> is it?
<ajax> i keep finding subtly broken things about it
<ajax> i mean this more in the sense of "tar pit you can't escape" than "source of joy"
<zmike> I assumed
<zmike> ty
<ajax> gaaaaah
<ajax> i hate that i'm seriously considering whether to move the xcb_put_image to a thread and do real async swapbuffers for sw
<ajax> pro: makes it look a lot like how present works. con: kind of insane.
<ajax> also: would it be insane to require Present even for software
<ajax> airlied: ^^^
<ajax> zmike: for !16730, dri3_wait_for_event_locked is used in like three places, i assume the path we reall care about is from dri3_find_back though
<ajax> actually. why are you caring about the loader dri3 code?
fahien has quit [Quit: fahien]
<zmike> ajax: I've gotten reports that this is deadlocking in Very Inauspicious Places and so it would be good to get it fixed
<ajax> i mean
<airlied> ajax: I'd accept using present for the non-mit-shm paths, with a horrible non-present fallback?
<ajax> maybe
<airlied> when does Xwayland support mit-shm? :-)