00:46
eukara_ has joined #zink
00:53
eukara has quit [Ping timeout: 480 seconds]
02:36
eukara__ has joined #zink
02:36
eukara_ has quit [Read error: Connection reset by peer]
03:56
anholt has joined #zink
15:25
<
zmike >
kusma: did you ever look at e.g., dEQP-GLES2.functional.clipping.point.wide_point_clip failures?
15:25
<
kusma >
I don't think so, but I know the GLES2 line/point clipping stuff...
15:26
<
kusma >
There's different rules in GLES2 vs desktop GL
15:26
<
kusma >
I thought we had those right for llvmpipe, though...
15:26
<
zmike >
those two that I posted are the only line fails
15:27
<
zmike >
the point ones pass on llvmpipe and fail on lavapipe
15:32
<
ajax >
zmike: was on pto last week. acked the revert and will look into re-fixing it today.
15:33
<
zmike >
can you do some kopper reviews
15:33
<
zmike >
would like to get fixes in before next stable on weds
15:34
<
kusma >
zmike: So are you saying that we fail the test above on zink + lavapipe, and the line test on llvmpipe?
15:34
<
zmike >
the full list of fails I posted on that ticket is what fails on zink+lavapipe
15:34
<
zmike >
the two in the OP are on both
15:35
<
ajax >
i think i can do that
15:35
<
kusma >
zmike: The ticket calls out llvmpipe, not zink + lavapipe...
15:35
<
zmike >
> At least some of these pass on llvmpipe, but they all fail on lavapipe.
15:36
<
zmike >
I guess I could be a little more specific, but it seemed obvious as I was writing it
15:46
<
zmike >
looks familiar
15:47
<
kusma >
There's nothing like point_tri_clip in Vulkan, we'd have to clip the primitive in a GS, I think...
15:47
<
kusma >
(clip/discard, same same)
15:48
<
kusma >
Oh, wait. We have problems emulating the GLES2 behavior, not the desktop GL behavior? That seems... wrong.
15:49
<
kusma >
I guess lavapipe should set point_tri_clip to true
15:52
<
kusma >
(it doesn't so, I'm fairly sure that's a bug, and a hole in the CTS... maybe even intentional :P)
15:53
<
zmike >
dunno, this isn't an area I have expertise in
15:53
<
zmike >
just gearing up for conformance submissions and filing tickets as I find issues
15:53
<
kusma >
Yeah, great stuff, BTW.
15:54
<
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.
16:07
<
zmike >
what sorts of features are you targeting?
16:52
<
zmike >
hm that's weird
16:54
<
anholt >
no dmesg complaints about gpu hangs
16:54
<
zmike >
I assume it works fine locally?
16:56
<
anholt >
haven't tried to see if zink+tu is flaky locally
16:56
<
anholt >
it's flakes -- sometimes a trace passes, sometimes throws that.
17:13
<
ajax >
zmike: that seems... elaborate. what's the bug being fixed there?
17:13
<
zmike >
ajax: theoretical haiku stuff where swapchain could be read from the present thread while it's being modified in the driver thread
17:24
<
ajax >
i mean. i can come up with that for x11 too i think but it's kind of a reach
17:24
<
zmike >
yeah it's extremely unlikely
17:24
<
zmike >
but theoretically it's possible
17:24
<
zmike >
and the changes are pretty trivial so I figured why not
17:41
<
anholt >
==602634== Uninitialised value was created by a stack allocation
17:41
<
anholt >
==602634== at 0x6282AC0: zink_begin_render_pass (zink_render_pass.c:612)
17:42
<
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
17:43
<
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
17:43
<
zmike >
yeah that's what I was 🤔
17:44
<
zmike >
but I'm not sure what it could be since the hash key is zeroed
17:44
<
zmike >
anholt: try doing struct zink_render_pass_pipeline_state *ppstate = {0};
17:44
<
zmike >
around L428
17:45
<
zmike >
be weird if it was that but maybe
17:45
<
anholt >
do you mean to rzalloc there instead?
17:46
<
zmike >
no, because in theory it should be writing the entire size of it
17:46
<
zmike >
unless I broke the packing?
17:46
<
anholt >
I don't know what *ppstate = {0} is supposed to be doing. the pointer gets immediately set to something.
17:46
<
zmike >
yeah I'm kinda doing a drive-by on this
17:47
<
zmike >
I meant the one at L421
17:53
<
anholt >
that does clear it up
17:53
<
anholt >
doesn't clear up the "zink_kopper_acquire_readback: Assertion `res->obj->dt' failed." fails
17:53
<
anholt >
(not that I actually expected that)
17:54
<
zmike >
ooh I've been looking for a repro case for that since people have been reporting it
17:55
<
anholt >
running eglretraces seems to do it for me
17:56
<
zmike >
okay, I've got a local patch that should fix the uninit
17:56
<
zmike >
will get that up soonish
17:56
<
zmike >
and I guess try to check out eglretrace
17:57
<
zmike >
have to finish up some homework for khronos first
18:02
<
zmike >
hmmm strange but also not that strange
18:02
<
zmike >
it's a dead swapchain
18:02
<
zmike >
so I think I need to....
18:02
<
zmike >
ajax: see? you wanted to remove KILL
18:02
<
zmike >
but here it is solving a bug
18:03
<
zmike >
anholt: at zink_kopper.c:524 try adding `res->swapchain = false;`
18:03
<
zmike >
should fix the assert
18:03
<
ajax >
i don't mind if a message sneaks out through like KHR_debug_utils or whatever
18:04
<
ajax >
i just dislike anything touching standard fds if they don't have to
18:04
<
zmike >
I was being facetious, it was supposed to be a log error
18:04
<
zmike >
and a better one probably
18:04
<
zmike >
I'll take care of that in the next round of kopper stuff
18:05
<
anholt >
tentatively, looks like that fixes it.
18:22
* anholt
has been in the tiling mines recently, so it looked like a possible tu failure
20:13
<
zmike >
anholt: that's got your assert fix too^