<karolherbst>
it became quite the nice cleanup now
kj2 has quit [Read error: Connection reset by peer]
kj2 has joined #dri-devel
dliviu has quit [Ping timeout: 480 seconds]
tzimmermann has quit [Ping timeout: 480 seconds]
tzimmermann has joined #dri-devel
bmodem has quit [Ping timeout: 480 seconds]
f11f12 has quit [Quit: Leaving]
sgruszka__ has joined #dri-devel
kts has joined #dri-devel
sgruszka has quit [Ping timeout: 480 seconds]
heat_ has joined #dri-devel
sgruszka has joined #dri-devel
sgruszka__ has quit [Ping timeout: 480 seconds]
kts has quit [Quit: Leaving]
kj2 has quit [Ping timeout: 480 seconds]
dliviu has joined #dri-devel
<Hazematman>
Hello all, I've had this MR sitting on the queue for a bit now and recently got all the CI issues with it resolved. I would appreciate if anyone could give it a review. I've highlighted two sections I'm not 100% confident on and would appreciate feedback on https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/27805
kts has joined #dri-devel
amarsh04 has quit []
u-amarsh04 has joined #dri-devel
Leopold has joined #dri-devel
Leopold_ has quit [Ping timeout: 480 seconds]
warpme has quit []
YuGiOhJCJ has quit [Quit: YuGiOhJCJ]
pa has quit [Ping timeout: 480 seconds]
pa has joined #dri-devel
sarnex has quit [Read error: Connection reset by peer]
sarnex has joined #dri-devel
davispuh has joined #dri-devel
warpme has joined #dri-devel
Calandracas has quit [Remote host closed the connection]
<JoshuaAshton>
Slowly going insane over the Wayland explicit sync requirement that release point can be signalled before acquire point if the compositor doesn't want your buffer aaAAaaAAaaaAAaaAAaaAAA
davispuh has joined #dri-devel
<MrCooper>
the compositor having to wait for the acquire point to signal first isn't great either, so let's not rush for that but wait a bit more for a reasonable client-side solution
Daanct12 has quit [Quit: WeeChat 4.2.1]
<MrCooper>
offhand not seeing why threads would be required with eventfds
<JoshuaAshton>
We need two things
simon-perretta-img has quit [Read error: Connection reset by peer]
<JoshuaAshton>
1) The GPU work for the acquire point to actually be done
simon-perretta-img has joined #dri-devel
<JoshuaAshton>
2) The release point to be signalled
<MrCooper>
you can get an eventfd which becomes readable when a fence is available for the acquire point, and can poll for that along with the other fds
<JoshuaAshton>
So essentially we need to merge two drmSyncObj points into one and then use that for our wait list
<JoshuaAshton>
Yeah, but we need to essentially make that wait an `if ((a1 && r1) || (a2 && r2) || ...)`
<pq>
what's the problem with that?
<JoshuaAshton>
drmSyncobjWait is any or all
<MrCooper>
it's just polling for a bunch of fds until the minimum requirements are met for acquiring a VkImage, not really seeing the big issue
tzimmermann has quit [Ping timeout: 480 seconds]
<pq>
use eventfd instead?
<JoshuaAshton>
I guess we could wait on all of them, accept any wakeup and track stuff, then remove from the wait. That still kinda sucks but I guess it works.
<MrCooper>
sounds like a run-of-the-mill event loop to me
<JoshuaAshton>
Sure
<JoshuaAshton>
Oh
<JoshuaAshton>
but we also need to handle that for the GPU side semaphore
<JoshuaAshton>
That was the other part
<JoshuaAshton>
vkAcquireNextImage can signal a VkSemaphore (the temporary part in Mesa) with that
<JoshuaAshton>
which also needs to be r && a
<dj-death>
anybody knows the right meson options to have mesa generate a libGL.so.1 ?
u-amarsh04 has joined #dri-devel
<dj-death>
somehow it only creates a libGLX_mesa.so
<pq>
dj-death, a wild guess: disable glvnd support
<JoshuaAshton>
So yes, we still need to actually merge them into a drmSyncObj if we want to keep non-linear timelines
<MrCooper>
dj-death: -Dglvnd=false
simon-perretta-img has quit [Ping timeout: 480 seconds]
<dj-death>
thanks a lot
<dj-death>
I thought I had it built
<pq>
dj-death, usually it comes from the glvnd project rathen than Mesa.
u-amarsh04 has quit []
<MrCooper>
JoshuaAshton: can't vkAcquireNextImage just wait for the acquire point to signal, then use the release point fence for semaphore?
simon-perretta-img has joined #dri-devel
<JoshuaAshton>
MrCooper: That's really interesting to think about actually
<MrCooper>
I guess waiting for the acquire point to signal isn't ideal, should only need to wait for a fence in principle
<JoshuaAshton>
I think you would end up just getting the same image over and over again
<JoshuaAshton>
If we did that naiively
<JoshuaAshton>
wait
<JoshuaAshton>
no
<MrCooper>
no, also need to wait for a fence for the release point
<JoshuaAshton>
that'd be fine
<JoshuaAshton>
You might not want the same image over and over again though that could be held by the compositor
<JoshuaAshton>
but we could keep pushing forward I guess
<JoshuaAshton>
but you could end up stalling on GPU with an image held by the compositor
<JoshuaAshton>
rather than skipping over it if it did that
<MrCooper>
no, because there's no fence for the release point in that case
<zamundaaa[m]>
You can make that work more nicely if you first check if any images exist where acquire and release points have already been signaled
<zamundaaa[m]>
If so, use that one. If not, use the one that's been committed to the compositor the earliest to maximize the chance of it being signaled soon
apinheiro has quit [Quit: Leaving]
<JoshuaAshton>
MrCooper: You mean wait for the release point to be signalled rather than materialise in Acquire
<JoshuaAshton>
?
Lucretia has quit []
<JoshuaAshton>
Seems to defeat the benefit of explicit sync
<MrCooper>
no, I mean what I wrote :)
<MrCooper>
if the compositor holds a buffer, there's no fence for its release point
<JoshuaAshton>
Then I don't get what you mean :frog:
<JoshuaAshton>
oh
<MrCooper>
since the client must wait for a fence for the release point before re-using the buffer, it won't re-use a held buffer
<JoshuaAshton>
got it
<JoshuaAshton>
I don't think that works though, if there is no fence materialised for it's release point, we have nothing to export on the VkSemaphore
<zamundaaa[m]>
JoshuaAshton: if there's no fence materialized yet, you just have to wait for that to happen
<zamundaaa[m]>
There's no way around that
<JoshuaAshton>
Now we are back to the a && r problem :D
<zamundaaa[m]>
I don't really follow
<MrCooper>
JoshuaAshton: vkAcquireNextImage can't acquire an image before a fence has materialized for the release point