ChanServ changed the topic of #zink to: official development channel for the mesa3d zink driver || https://docs.mesa3d.org/drivers/zink.html
eukara_ has joined #zink
eukara has quit [Ping timeout: 480 seconds]
eukara__ has joined #zink
eukara_ has quit [Read error: Connection reset by peer]
anholt has joined #zink
<zmike> kusma: did you ever look at e.g., dEQP-GLES2.functional.clipping.point.wide_point_clip failures?
<kusma> I don't think so, but I know the GLES2 line/point clipping stuff...
<kusma> There's different rules in GLES2 vs desktop GL
<kusma> I thought we had those right for llvmpipe, though...
<zmike> those two that I posted are the only line fails
<zmike> the point ones pass on llvmpipe and fail on lavapipe
<ajax> zmike: was on pto last week. acked the revert and will look into re-fixing it today.
<zmike> ajax: cool
<zmike> can you do some kopper reviews
<zmike> would like to get fixes in before next stable on weds
<kusma> zmike: So are you saying that we fail the test above on zink + lavapipe, and the line test on llvmpipe?
<zmike> the full list of fails I posted on that ticket is what fails on zink+lavapipe
<zmike> the two in the OP are on both
<ajax> i think i can do that
<kusma> zmike: The ticket calls out llvmpipe, not zink + lavapipe...
<zmike> > At least some of these pass on llvmpipe, but they all fail on lavapipe.
<zmike> I guess I could be a little more specific, but it seemed obvious as I was writing it
<kusma> zmike: Here's last time I touched this stuff, I think: https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/12350
<zmike> looks familiar
<kusma> There's nothing like point_tri_clip in Vulkan, we'd have to clip the primitive in a GS, I think...
<kusma> (clip/discard, same same)
<kusma> Oh, wait. We have problems emulating the GLES2 behavior, not the desktop GL behavior? That seems... wrong.
<kusma> I guess lavapipe should set point_tri_clip to true
<kusma> (it doesn't so, I'm fairly sure that's a bug, and a hole in the CTS... maybe even intentional :P)
<zmike> dunno, this isn't an area I have expertise in
<zmike> just gearing up for conformance submissions and filing tickets as I find issues
<kusma> Yeah, great stuff, BTW.
<kusma> I'll be working on some Zink stuff in the near-ish future, BTW. Basically doing emulation of some features for GPUs that lack them. Mostly stuff we've already done for the D3D12 driver, so there's some prior art and all.
<zmike> cool
<zmike> what sorts of features are you targeting?
<zmike> ajax: specifically https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/16932 and then I've got a followup to fix implicit sync
<anholt> looks like tu zink traces aren't stable, getting this "image height is zero" failure. with or without the VK_SUBOPTIMAL_KHR complaint. https://anholt.pages.freedesktop.org/-/mesa/-/jobs/23949251/artifacts/results/summary/results/trace@zink-a630@gputest@pixmark-volplosion.trace.html
<zmike> hm that's weird
<anholt> no dmesg complaints about gpu hangs
<zmike> I assume it works fine locally?
<anholt> haven't tried to see if zink+tu is flaky locally
<anholt> it's flakes -- sometimes a trace passes, sometimes throws that.
<ajax> zmike: that seems... elaborate. what's the bug being fixed there?
<zmike> ajax: theoretical haiku stuff where swapchain could be read from the present thread while it's being modified in the driver thread
<ajax> hmph
<zmike> yup
<ajax> i mean. i can come up with that for x11 too i think but it's kind of a reach
<zmike> yeah it's extremely unlikely
<zmike> but theoretically it's possible
<zmike> and the changes are pretty trivial so I figured why not
<ajax> yeah okay
<zmike> 🤔
<anholt> ==602634== Uninitialised value was created by a stack allocation
<anholt> ==602634== at 0x6282AC0: zink_begin_render_pass (zink_render_pass.c:612)
<zmike> now that's a puzzler since there's no stack allocations in that function unless you're hitting the multisample-to-single-sample path
<anholt> I don't think you can actually trust the line numbers from valgrind, and things like inlined functions can have their stack accounted to the same place
<zmike> yeah that's what I was 🤔
<zmike> but I'm not sure what it could be since the hash key is zeroed
<zmike> unless
<zmike> anholt: try doing struct zink_render_pass_pipeline_state *ppstate = {0};
<zmike> around L428
<zmike> be weird if it was that but maybe
<anholt> do you mean to rzalloc there instead?
<zmike> no, because in theory it should be writing the entire size of it
<zmike> unless I broke the packing?
<anholt> I don't know what *ppstate = {0} is supposed to be doing. the pointer gets immediately set to something.
<zmike> yeah I'm kinda doing a drive-by on this
<zmike> I meant the one at L421
<anholt> that does clear it up
<zmike> bizarre
<anholt> doesn't clear up the "zink_kopper_acquire_readback: Assertion `res->obj->dt' failed." fails
<anholt> (not that I actually expected that)
<zmike> ooh I've been looking for a repro case for that since people have been reporting it
<anholt> running eglretraces seems to do it for me
<zmike> okay, I've got a local patch that should fix the uninit
<zmike> I think
<zmike> will get that up soonish
<zmike> and I guess try to check out eglretrace
<zmike> have to finish up some homework for khronos first
<anholt> https://paste.centos.org/view/a07886cf <-- the assert. no luck getting it under valgrind.
<zmike> hmmm strange but also not that strange
<zmike> it's a dead swapchain
<zmike> so I think I need to....
<zmike> ajax: see? you wanted to remove KILL
<zmike> but here it is solving a bug
<zmike> anholt: at zink_kopper.c:524 try adding `res->swapchain = false;`
<zmike> should fix the assert
<ajax> i don't mind if a message sneaks out through like KHR_debug_utils or whatever
<ajax> i just dislike anything touching standard fds if they don't have to
<zmike> I was being facetious, it was supposed to be a log error
<zmike> and a better one probably
<zmike> I'll take care of that in the next round of kopper stuff
<anholt> tentatively, looks like that fixes it.
<zmike> booya
* anholt has been in the tiling mines recently, so it looked like a possible tu failure
<zmike> 🤔
<ajax> zmike: bonk
<zmike> 👍
<zmike> anholt: that's got your assert fix too^