DodoGTA has quit [Quit: DodoGTA]
DodoGTA has joined #zink
DodoGTA has left #zink [#zink]
DodoGTA has joined #zink
DodoGTA has left #zink [#zink]
DodoGTA has joined #zink
DodoGTA has quit [Quit: DodoGTA]
DodoGTA has joined #zink
Mary has quit [Quit: .]
Mary has joined #zink
<
fdobridge>
<gfxstrand> Ugh... I don't understand `zink_tc_fence` at all
<
fdobridge>
<gfxstrand> It looks like it's mostly a one-shot but sometimes it needs to not be
<
fdobridge>
<zmike.> tc is complex
<
fdobridge>
<zmike.> what's your issue
<
fdobridge>
<zmike.> @gfxstrand generally if you're investigating that, the odds are you fucked up
<
fdobridge>
<gfxstrand> Oh, I'm 100% sure it's broken.
<
fdobridge>
<gfxstrand> I'm just not sure how it's supposed to work so I don't know how to fix it
<
fdobridge>
<zmike.> what seems broken
<
fdobridge>
<gfxstrand> With Vulkan interop semaphores, it's supposed to be persistent
<
fdobridge>
<zmike.> what is "it"
<
fdobridge>
<gfxstrand> But all of the deferred_ctx stuff and a few other places seem to think it's a one-shot
<
fdobridge>
<gfxstrand> `zink_tc_fence`
<
fdobridge>
<zmike.> no that's impossible
<
fdobridge>
<zmike.> what is "it"
<
fdobridge>
<gfxstrand> If `zink_create_fence_fd()` is created with `PIPE_FD_TYPE_SYNCOBJ`, it's persistent.
<
fdobridge>
<zmike.> by persistent you mean reusable?
<
fdobridge>
<gfxstrand> Yes
<
fdobridge>
<gfxstrand> Without doing any sort of re-import
<
fdobridge>
<gfxstrand> each `server_signal` should signal it and each `server_sync` should wait on it exactly once.
<
fdobridge>
<zmike.> ok so just do like I said on the MR ?
<
fdobridge>
<gfxstrand> That's not enough.
<
fdobridge>
<zmike.> what makes it not enough?
<
fdobridge>
<gfxstrand> Because all the `deferred_ctx` stuff is causing us to not wait again
<
fdobridge>
<gfxstrand> Because all that logic seems to assume that once `deferred_ctx` is set, the fence will be thrown away
<
fdobridge>
<gfxstrand> Nothing resets it
<
fdobridge>
<gfxstrand> And IDK how it's supposed to work well enough to know where to unset it safely.
<
fdobridge>
<zmike.> hold on trying to consult and stir fry simultaneously
<
fdobridge>
<gfxstrand> Don't code and work with hot oil at the same time! Very not recommended.
<
fdobridge>
<zmike.> alright alright
<
fdobridge>
<zmike.> damn this stir fry is good
<
fdobridge>
<zmike.> the problem here is that all the fence stuff is massively overloaded at the gallium level
<
fdobridge>
<zmike.> which makes things like this tricky
<
fdobridge>
<zmike.> @gfxstrand so is the signal side fine? or is there an issue there too
<
fdobridge>
<zmike.> I think you just need this
<
fdobridge>
<gfxstrand> Yeah, that doesn't work either
<
fdobridge>
<zmike.> it doesn't?
<
fdobridge>
<zmike.> but how
<
fdobridge>
<zmike.> unless...
<
fdobridge>
<zmike.> what's the usage pattern here?
<
fdobridge>
<zmike.> uhhhh
<
fdobridge>
<zmike.> so hold up, you're doing wait -> flush -> wait -> flush in a loop?
<
fdobridge>
<zmike.> without actually waiting?
<
fdobridge>
<gfxstrand> It's ping-ponging between GL and Vulkan
<
fdobridge>
<zmike.> yeah
<
fdobridge>
<zmike.> but like
<
fdobridge>
<zmike.> ok
<
fdobridge>
<zmike.> that's annoying
<
fdobridge>
<zmike.> and not what I expected
<
fdobridge>
<gfxstrand> If it makes you feel better, I'm pretty sure all of Mesa is broken for that case. 🤡
<
fdobridge>
<zmike.> I doubt any drivers handle it correctly including nvidia
<
fdobridge>
<gfxstrand> I think Zink is a little more broken than iris but don't quote me on that. 😂
<
fdobridge>
<zmike.> ok try that version
<
fdobridge>
<zmike.> I'm amazed something is actually doing this in the wild
<
fdobridge>
<gfxstrand> Now I think something is double-waiting
<
fdobridge>
<gfxstrand> But let me try and figure out why
<
fdobridge>
<gfxstrand> Okay, I think I got it maybe
<
fdobridge>
<gfxstrand> I wonder if Chrome agrees.
<
fdobridge>
<zmike.> 🤔
<
fdobridge>
<gfxstrand> Look at all those beautiful fish!
<
fdobridge>
<zmike.> you remind me of a younger me in the year 2020