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