12:49 karolherbst: deqp MT tests: Failed: 1/1278 (0.1%) :)
16:25 Lyude: RSpliet: I forget, did I get an answer from you whether or not you'd tried reverting the cursor changes I made upstream on nouveau to see if they fix your issues?
16:29 RSpliet: Lyude: no, I run Fedora mainline kernels at the moment.
16:30 RSpliet: But also: the issue doesn't always appear, just... sometimes
16:30 RSpliet: Like, I haven't seen it in the past few days
21:06 karolherbst: okay... at least according to valgrind I am also race free...
21:06 karolherbst: I still suspect some weirdo mem corruption somewhere though
21:17 karolherbst: so yeah I guess we can't upload shaders from multiple contexts without syncing :D
21:18 karolherbst: also this kernel race condition is annoying
22:40 karolherbst: imirkin: eww... screen->text_heap is annoying.. so what can happen is that one context resizes the entire heap, because out of space, but we still have nvc0_program objects having mem allocations from the old and destroyed heap :/
22:42 karolherbst: I am not even sure how that all worked single threaded besides out of luck
23:23 imirkin: karolherbst: well, that should cause the program objects to no longer think they're attached to the heap
23:23 imirkin: which should ause them to revalidate
23:23 imirkin: cause*
23:28 imirkin: karolherbst: basically it's in the heap linked list
23:28 imirkin: when text gets reallocated, that should get cleared out
23:28 imirkin: at least that's my recollection
23:29 imirkin: this is definitely meant to work.
23:29 imirkin: there's an extra-subtle point that you have to ensure that both the new text and old text are added to the submit
23:29 imirkin: otherwise it won't work. that was a fun debugging session :)
23:29 imirkin: aka "why does bindless not work in dirt rally"
23:50 karolherbst: imirkin: I am not talking about the GPU side though, but the CPU one
23:51 karolherbst: mainly about the screen->text_heap bit
23:52 karolherbst: so inside nvc0_screen_resize_text_area we destroy screen->text_heap and init a new nouveau_heap thing
23:52 karolherbst: but the old nvc0_program objects still reference the old one
23:52 karolherbst: or I missed something and this gets cleaned up
23:54 karolherbst: could be that only the case is broken where a nvc0_program thing isn't used again, but simply destroyed
23:54 karolherbst: so nvc0_screen_resize_text_area -> nouveau_heap_destroy and then nvc0_program_destroy -> nouveau_heap_free based on the destroyed nouveau_heap thing
23:56 karolherbst: this is what libasan is hitting: https://gist.githubusercontent.com/karolherbst/9e4a7e2c8027f07ef4d1709203651147/raw/66a8f80aad671111939f35a2076e5c87f7fd078b/gistfile1.txt
23:56 karolherbst: I was wondering if it's already broken on main
23:56 karolherbst: and if that can be hit in a single context application