ChanServ changed the topic of #zink to: official development channel for the mesa3d zink driver || https://docs.mesa3d.org/drivers/zink.html
Akari has quit [Read error: Connection reset by peer]
Akari has joined #zink
Akari has quit [Ping timeout: 480 seconds]
Akari has joined #zink
<anholt> looking at zink+tu's dEQP-GLES31.functional.copy_image.non_compressed.viewclass_16_bits.* flakes, I see some validation failures in the group, though not necessarily on the flaking tests.
<zmike> hm will check it out tomorrow
hch12907 has quit [Quit: Reconnecting]
hch12907 has joined #zink
hch12907__ has joined #zink
hch12907__ has quit []
fahien has joined #zink
fahien has quit [Ping timeout: 480 seconds]
fahien has joined #zink
fahien has quit [Ping timeout: 480 seconds]
anholt_ has joined #zink
anholt has quit [Ping timeout: 480 seconds]
fahien has joined #zink
fahien has quit [Ping timeout: 480 seconds]
fahien has joined #zink
fahien1 has joined #zink
fahien has quit [Ping timeout: 480 seconds]
fahien1 is now known as fahien
fahien1 has joined #zink
fahien is now known as Guest1086
fahien1 is now known as fahien
Guest1086 has quit [Ping timeout: 480 seconds]
fahien has quit [Ping timeout: 480 seconds]
fahien has joined #zink
fahien1 has joined #zink
fahien has quit [Ping timeout: 480 seconds]
fahien1 is now known as fahien
<zmike> and also hopefully the flakes
<zmike> ajax: could use some zink reviews if you have time for it
pendingchaos has quit [Ping timeout: 480 seconds]
fahien has quit [Quit: fahien]
pendingchaos has joined #zink
<anholt_> glmark2-es2 with zink is doing stores to the z buffer? rude.
<anholt_> (I thought we had invalidate_resource hoooked up to not store things)
<zmike> 🤔
<zmike> for framebuffer discards you mean?
<anholt_> yeah
<zmike> hm I think right now that's only hooked up to change the loadop
<zmike> is it supposed to do more?
<zmike> my read of the code there was that it was called after draws or whatever in order to indicate that the existing contents should be discarded
<anholt_> the invalidate just before the flush should make you not store it. notably, on EGL, that means you don't need to store Z.
<zmike> hmmm
<anholt_> though, maybe this is missing from kopper or something? Doesn't seem to be happening.
<zmike> is that actually the way invalidate_resource is supposed to work?
<zmike> I'm not sure where invalidate_resource would come through
<zmike> for that behavior
<zmike> but if it's just before flush then it's too late anyway
<zmike> since that would need to be known on rp begin
<anholt_> __DRI2_FLUSH_INVALIDATE_ANCILLARY looks like the grep to do
<zmike> hmmm
<zmike> that should still be happening?
<zmike> it's triggered from notify_before_flush_cb() which kopper uses
<zmike> any piglit tests which would trigger this?
<anholt_> anything with depth and eglswapbuffers?
<zmike> I guess it's too much to hope that es2gears_x11 uses a depth buffer
<zmike> well, I can probably check with that anyway
<zmike> yep not called from kopper at all
<anholt_> looks like kopper has a swapBuffers() method in dri2_x11_swap_buffers(), so you don't get the dri2_flush_drawable_for_swapbuffers(disp, draw) call that would otherwise happen
<zmike> hm I think it's slightly more complex
<zmike> drisw in general doesn't seem to get that call
<zmike> oh no I'm blind
<zmike> or am I
<zmike> ahh it takes the same path
<zmike> I think throwing __DRI2_FLUSH_INVALIDATE_ANCILLARY into the kopper swapbuffers impl might be enough to trigger it?
<anholt_> watch out that you're not allowed to do that for glx, though.
<zmike> ah hm
<zmike> time to sift through dri interfaces again to see if there's a way to tell the api
<zmike> api_mask looks promising
<anholt_> I don't think so. you can have an ES2 context on GLX, which should preserve, or a GL context on EGL which shouldn't.
<zmike> ah
<zmike> hm
<zmike> has to be a flag for this somewhere....
<anholt_> I don't think there is, which is why this is done in such an ugly way through egl/platform_*.c
<anholt_> if we could just have the pipe context accessible from egl/, this seems like it would be way easier.
<zmike> I think that's asking for too much haha
<zmike> well it should be trivial enough to add a flag for "this is egl" to dri_screen or something
<anholt_> Filed #7321 to track this
<zmike> ah found it
<zmike> oh ffs
<zmike> obviously the type would have to be opaque
<zmike> hm
<anholt_> oh dear. it seems angle serializes vk drawing/state commands, and replays them into the primary cmd buffer later. presumably for things like optmizing the render pass.
<zmike> huh
<anholt_> I was hoping that SecondaryCommandBuffer was going to be a, you know, vulkan secondary command buffer.
<zmike> too easy
<zmike> this seems insane to me but I think I need to bump the dri swrast interface to get this through
<zmike> alright, this takes care of the flush thing
<zmike> but I think it's still not actually what we want
<zmike> because what we really want is to create a zs buffer that never loads and never stores
<anholt_> it's hard, because if someone does a glFlush() in the middle of rendering, you should save zs contents across that. it's just at swap that it's invalidated.
<zmike> oh
<zmike> I don't see how it's possible to ever avoid stores then
<anholt_> could you move all the inside-the-renderpass stuff to a secondary? I'm not great at what the rules are for them.
<anholt_> then you get to begin the pass after you've recorded the insides.
<zmike> I think that would create serious issues with other stuff like queries
<zmike> or
<zmike> there's something I remember knowing that I needed to never use secondaries or everything would explode
<zmike> but I don't remember what it is
<zmike> I could maybe do something like copy the zs buffer on non-swapbuffers flush and then load it back in after?
<zmike> though I'd need to end the renderpass for that too
<zmike> hmmmmm
<anholt_> angle does seem to play its "secondary" into primary, so maybe there's a good reason.
<zmike> VK_EXT_really_dynamic_rendering
<anholt_> we just need VK_EXT_store_op_just_kidding
<anholt_> (ha ha only serious)
<zmike> hahaha
<zmike> is it possible at a technical level to do that?
<zmike> because...
<zmike> would really rather do anything but use secondaries
<anholt_> it would be pretty easy inside turnip to have the stores get skipped if you emitted an appropriate command just before the end of the pass.
<zmike> hm
<zmike> feels like I could push this through pretty easily
<zmike> and then avoid considerable complexity
<zmike> can you do per-attachment? like if I passed idx=1?
<anholt_> yeah, we could skip for individual attachments
<anholt_> would presumably want to specify things as basically switching to dont_care.
<zmike> yea
<zmike> have to wonder why google didn't do this already