04:55 airlied[d]: okay, got gsp to start booting on spark, but gsp never finished boot, it tries to use the graphics engine for something, but hits a page fault on NULL, I wonder what I'm not configuring
05:29 redsheep[d]: airlied[d]: Do you have hardware to test with? If that bubbles back up the priority list I would love to help if possible
05:52 airlied[d]: I was using a capture card to test, and it kind off worked on hotplug, but would hang on boot
06:36 airlied[d]: okay got to instmem, which is where the fun of having no vram starts
10:38 mohamexiety[d]: hm i figured that it would just treat the system ram as vram in that scenario
10:44 airlied[d]: No there is no bar 1 or bar 2
10:44 airlied[d]: I copied some of the Tegra instmem code but need to handle the lack of bars
14:35 karolherbst[d]: okay.. with https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/40848 we probably have to move lower_int64 into the opt loop 🥲
15:23 calim: why does it matter what nir does?
15:24 calim: and why doesn't it have options to ask you what you want
15:29 calim: aren't there any arch-specific optimizations anymore?
17:08 karolherbst[d]: there are, but things are complicated (tm)
17:09 mhenning[d]: gfxstrand[d]: why do secondary command buffers with RENDER_PASS_CONTINUE need to re-initialize attachments? shouldn't the primary have already set that up?
17:10 karolherbst[d]: mhh we might want to move `nir_lower_load_const_to_scalar` into an opt loop. Was testing that MR and were seeing us doing weird things 🙃
17:10 karolherbst[d]: https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/40848#note_3416062
17:11 gfxstrand[d]: mhenning[d]: Uh... Possibly? Probably?
17:13 mhenning[d]: okay, I'll go back to reading the spec then
17:16 mhenning[d]: zcull needs us to insert a LOAD_ZCULL in begin_rendering and a STORE_ZCULL in end_rendering so a begin_rendering call in an existing rendering pass like we currently do for secondaries breaks things
17:19 karolherbst[d]: couldn't this be tied to switching the framebuffer or whatever object we need to zcull there?
17:20 mhenning[d]: Yes, that's exactly what I'm talking about
17:21 karolherbst[d]: ahh I see
17:42 calim: meh, I just see that cse doesn't cull those 3 duplicate bcsel for some reason, not what it has to do with int64
17:45 calim: ah, unless you rely on all int64 being lowered already, right
18:12 Lyude: airlied[d] btw - neal gompa brought up that apparently we are seeing some issues with gnome-initial-setup on the fedora installer with nouveau that look pretty similar to the crashes I've seen from nouveau on neovim-gtk: https://bugzilla.redhat.com/show_bug.cgi?id=2359799
18:13 Lyude: it might end up being a blocker so this is probably something we want to try to figure out a solution for soon
19:03 calim: vulkan is so explicit about everything to the point of annoyance, just dealing with gallium seems nice in comparison now
19:10 airlied[d]: _lyude: I was waiting to see if it was still reproducing on f44, does neovim still crash on main. Is there an issue filed?
19:11 _lyude[d]: yeah there's a gitlab issue filed, also crash probably isn't the right word
19:11 _lyude[d]: https://gitlab.freedesktop.org/mesa/mesa/-/issues/14662
19:12 _lyude[d]: we typically get the same warnings about a vulkan device being lost when that happens
19:12 _lyude[d]: I wonder if this might be related to the other vmm race I discovered the other dahy
19:15 _lyude[d]: https://paste.centos.org/view/594fb0da ← I did end up writing a patch for it that seems to work but honestly I'm pretty sure there are still other parts of nouveau_vmm.c that are missing locks
19:27 mohamexiety[d]: man why is vmm so messed up
19:40 airlied[d]: Ah corrupted surfaces is probably not the same as the installer which was GR crashes
20:14 airlied[d]: _lyude[d]: does that patch fix something, just wondering where we would create a vma when a bo has been exposed to users already
20:34 _lyude[d]: airlied[d]: Im still trying to figure out if it does, unfortunately I haven't been back at my desk since writing last week - but since writing it I haven't had any flickering, I still need to test more though.
20:34 _lyude[d]: The thing is though I can't find anything besides the ttm lock that would provide any actual protection against concurrent updates on vmm->refs
20:50 airlied[d]: changing refs to an atomic might be enough, but I'm also unsure where refs can be raced on that matters
20:55 airlied[d]: I do wonder how a bo ever gets the same vmm, I suppose gem open/close a lot could do it
21:13 airlied[d]: _lyude[d]: I suspect the zink fixes I backported for chrome might have helped initial setup, but not 100% sure
21:14 airlied[d]: though maybe not it seems it's using vulkan directly
23:55 _lyude[d]: airlied[d]: Yeah - I still need to do a bit of digging. And remember how on earth I actually noticed this in the driver in the first place