14:09 fdobridge: <k​arolherbst🐧🦀> sooo.. I think the instability is caused by having multiple channels per application and nouveau not locking that stuff properly and just ends up doing data races on the GPU object tree stuff
14:10 fdobridge: <k​arolherbst🐧🦀> I can see that happening when allocating subchannels e.g.
17:46 fdobridge: <b​inhani> I was trying to compile the repository to test something when I got this error
17:46 fdobridge: <b​inhani> https://cdn.discordapp.com/attachments/1034184951790305330/1146501140905742386/image.png
17:47 fdobridge: <b​inhani> from what I understand, `nvk_entrypoints.h` is auto-generated from `vk_entrypoints_gen.py` which means it should already be there
17:47 fdobridge: <b​inhani> what am I missing?
18:02 fdobridge: <!​[NVK Whacker] Echo (she) 🇱🇹> I think so
18:13 anholt: binhani: generally, that's that caused by that library's meson.build forgetting to use the generated header's idep, so you tried to build that code before the auto-generation completed.
18:21 dakr: airlied: btw. while moving over to DRM_SCHED_POLICY_SINGLE_ENTITY I noticed a race between nouveau_channel_idle() and dma-fence callbacks from jobs on this channel.
18:22 dakr: This seems to be due to nouveau_fence_wait() called with lazy == false, which is polling while the dma-fence path is waiting for the interrupt.
18:24 dakr: So, it can happen that a job's dma-fence with a smaller seqno appears to be signaled after nouveau_channel_idle() already returned.
18:26 dakr: Not a huge problem, but probably worth to keep that in mind.
23:46 fdobridge: <g​fxstrand> We're getting there... `Pass: 401948, Fail: 928, Crash: 445, Skip: 1728657, Timeout: 2, Flake: 390, Duration: 1:39:59`
23:46 fdobridge: <g​fxstrand> NAK CS-only run with my new spiller ^^