13:29marysaka[d]: Does anyone have issues replaying renderdoc captures of some games running on DXVK on NVK?
13:29marysaka[d]: Getting `Replaying '/home/mary/bad_capture.rdc' locally..
13:29marysaka[d]: MESA: warning: ../../../dev/mesa/src/nouveau/vulkan/nvk_descriptor_table.c:185: Descriptor 14198 is already in use (VK_ERROR_INVALID_DEVICE_ADDRESS_EXT)` with renderdoc nightly and stable
13:30marysaka[d]: (trying to capture Lego Builder's Journey under renderdoc to make sense of the constant color regression)
14:22phomes_[d]: it is working fine here with a capture I had from a few months ago.
14:22phomes_[d]: oh wait that is with vkd3d not dxvk
14:28marysaka[d]: phomes_[d]: I just noticed it's vkd3d yeah... also interesting to note the bug doesn't appear when it runs in dx11 mode
16:02mhenning[d]: Does it also happen with only the second commit applied? ("nvk: Conditionally disable MRT bit in SPH ")
16:05marysaka[d]: mhenning[d]: It happens if you revert top commit ("nvk: Add support for constant color rendering")
16:05marysaka[d]: I wasn't able to do a capture but the validation layers are spamming this:
16:05marysaka[d]: 0344:warn:vkd3d_debug_messenger_callback: vkCmdDraw(): Inside the fragment shader, it writes to output Location 0 but there is no VkRenderingInfo::pColorAttachments[0] and this write is unused.
16:05marysaka[d]: Spec information at https://docs.vulkan.org/spec/latest/chapters/interfaces.html#interfaces-fragmentoutput
16:18marysaka[d]: With the previous approach for MRT, the specific shader that write only 0,0,0,0 to color0 would enable MRT as color_attachment_count would report 3
16:19marysaka[d]: ... while what I see in the push_dump is a draw with no RTs enabled, just D/S being bound 🤔
16:21mhenning[d]: Oh, here's something interesting. From the SPH docs: "[MrtEnable] is always AND’d with SetCtMrtEnable.V(eff) to allow the driver to dynamically override the MRT (Multiple Render Target) behavior of the pixel shader."
16:22mhenning[d]: and we have NV9097_SET_CT_MRT_ENABLE
16:22mhenning[d]: so we could potentially toggle NV9097_SET_CT_MRT_ENABLE in the command stream along with constant color, no shader keys needed
16:23mhenning[d]: although I am curious about what's going on with lego builders journey
16:24marysaka[d]: mhenning[d]: so that's the funny thing, when I was typing constant color this would not disable MRT
16:24mhenning[d]: or I guess the mrt bit in sph could be toggled by nak_fs_const_color
16:24marysaka[d]: (aka the constant color wasn't used and the shader was running)
16:24mhenning[d]: oh, huh
16:25marysaka[d]: I should maybe pull Maxwell and try to use that method, maybe it's a no-op those days?
16:25marysaka[d]: or maybe something else control if that is used or not I'm not too sure...
16:27mhenning[d]: Or maybe NV9097_SET_CT_MRT_ENABLE is just ignored for the purposes of constant color?
16:27mhenning[d]: blackwell still has a SET_CT_MRT_ENABLE in the headers. It would be a little odd of them to break it but leave the definition there
16:29marysaka[d]: hmm that's possible...
16:31mhenning[d]: maybe disabling mrt in sph also disables depth/stencil writes?
16:46marysaka[d]: https://cdn.discordapp.com/attachments/1034184951790305330/1451616637147938857/snapshot.png?ex=6946d2d8&is=69458158&hm=dc8bc1fd42d3be78c00669a6521c8f4af3f3599313d0cdb31403d563f4d5603d&
16:46marysaka[d]: mhenning[d]: that seems to be that yeah, just tested forcing MRT=1 and SET_CT_MRT_ENABLE = V_FALSE (of course render is wrong now but the lego piece is not black anymore)
16:47marysaka[d]: or at least it does interact a bit with it.. because if MRT was truly disabled then it would be black :blobcatnotlikethis:
17:15chikuwad[d]: does anyone here have experience with cross compiling mesa for arm64 devices on x86-64?
17:16karolherbst[d]: marysaka[d]: looks like a heat camera thing
17:17karolherbst[d]: but what is that game doing 🙃 it sounds like it does proper light physic simulation and stuff
17:17karolherbst[d]: it's impressively compute heavy
17:59esdrastarsis[d]: marysaka[d]: Do you have issues with mouse cursor on cosmic on zink+nvk?
18:23esdrastarsis[d]: https://cdn.discordapp.com/attachments/1034184951790305330/1451641224178958437/IMG_20251219_152215961.jpg?ex=6946e9be&is=6945983e&hm=03b8023e2169f72a77768e02096a0f83b925524c809f1e3b4e1fd318fa1d4e20&
18:23esdrastarsis[d]: Like this one
18:25esdrastarsis[d]: I think its not a zink bug, because it happens on nvc0 too
18:48_lyude[d]: esdrastarsis[d]: You said that you were hitting the same `CMDre Xid:56` exception I posted about the other day, and that it seemed like a kernel regression to you - right?
18:48_lyude[d]: I'm wondering if you remember what kernel version it was working on
18:49_lyude[d]: I've made some progress on it at the very least: I'm convinced now it's actually a race condition with our pushbuffer code
18:51_lyude[d]: It seems like somehow we're actually skipping entries in the pushbuffer (like, I'm seeing the pushbuffer index in one of the logs I have go 254, 258, 25c, 260, 260, 268)
18:51chikuwad[d]: chikuwad[d]: running into this error `meson.build:1604:11: ERROR: Dependency 'zlib' is required but not found.` when trying to cross compile for aarch64 on x86-64
18:59esdrastarsis[d]: _lyude[d]: 6.18.0, but it's probably just luck since it's a race condition and there's nothing related to nouveau between 6.18 and 6.18.1 :blobcatnotlikethis:
19:00_lyude[d]: ahhh. so - I do know some things that trigger it now btw
19:00_lyude[d]: If your cursor surface is updating repeatedly, like a spinning busy icon, moving it between monitors can break things
19:01_lyude[d]: but yeah - once I figure out how we're racing I think fixing this should be easy 🙂
19:05esdrastarsis[d]: _lyude[d]: I noticed the spinning busy icon in Gnome, I didn't know it was related 🤔
19:06_lyude[d]: Yeah it took me a while to notice that too until I realized "seems kinda weird that's my cursor every single time this happens". You really notice it if you have a continously updating cursor that's between two displays, one of the displays will show the cursor stuttering and glitching
19:06_lyude[d]: It's entirely possible that in particular is a separate bug but it's hard to say until we figure out how we're managing to race and corrupt our display pushbuffer
20:11_lyude[d]: got it. We're not setting lock_core in some atomic updates 🙂
20:13_lyude[d]: esdrastarsis[d]: I will probably have a fix ready today
20:18x512[m]: Is it related to GSP that physical VRAM allocation is very slow?
21:54_lyude[d]: btw airlied[d] still waiting for a review on "Don't call drm_atomic_get_crtc_state() in prepare_fb"
21:55_lyude[d]: https://patchwork.freedesktop.org/series/159325/ esdrastarsis[d] btw, let me know if the fix works for you 🙂
22:32airlied[d]: _lyude[d]: r-b for v2, please just add it in and push