18:00 anholt_: it would really help me with the regression checking for nouveau codegen if someone could ack https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/16150
18:14 imirkin: sec
18:17 imirkin: anholt_: hrmph. it's slightly awkward ... i wonder if there's a clearer way. gimme a few to think about it.
18:41 karolherbst: imirkin: just do it at fence creation time?
18:42 karolherbst: ehh.. that will assert through the entire code :(
18:43 imirkin: yes.
18:43 imirkin: the thing anholt_ did in the latest update is perfect, i think
18:45 karolherbst: ohh, there was an update
18:45 karolherbst: yeah.. I just wanted to suggest something like that :)
18:45 karolherbst: but wasn't finished thinking
18:46 imirkin: and it all works nicely within the existing framework
18:46 imirkin: which is ideal for hacks like this
18:47 karolherbst: but this is now hitting the part I wasn't finished thinking about, although I think it's fine from a practical point of view
18:48 karolherbst: it could play some weird ping pong between fences, but should be fine
18:48 karolherbst: though it might call nouveau_fence_trigger_work multiple times on the same fence
18:48 imirkin: i don't think so
18:48 imirkin: it's the same as if the hw was infinitely fast at processing the fences
18:49 karolherbst: this would be true if we would have a "screen->fence.sequence_ack >= sequence" check
18:49 imirkin: as it signals the fences, they should be getting removed
18:49 imirkin: by incrementing the head
18:50 imirkin: or whatever
18:50 imirkin: screen->fence.head = next;
18:50 karolherbst: mhhh
18:52 karolherbst: yeah, it's probably fine
18:53 karolherbst: I mean.. it doesn't break things like the last attempt and it's good enough for shader-db regardless
18:53 imirkin: yeah
18:53 imirkin: well i esp prefer not to leak stuff, which this now does not
18:53 imirkin: since it's super-annoying to debug stuff where the debug fixture is what's leaking :)
18:53 imirkin: (i'm looking at you, deqp)
18:57 anholt_: thanks for reviews. helps make sure I can move the GLSL code deduplication along.
18:58 imirkin: anholt_: with your CI hat, if this ends up taking too long, we can probably pare down the list of chipsets
18:58 imirkin: that list was to maximize code coverage
18:59 imirkin: but the reality is that there aren't a _ton_ of differences between some of those
18:59 anholt_: it's still quick
19:00 anholt_: and debian-gallium isn't in the dependency path for anything else, so you just have to be faster than the whole hardware CI farm :)
19:00 imirkin: ok cool