03:09airlied[d]: marysaka[d]: https://lore.kernel.org/nouveau/20260129030710.1574879-1-airlied@gmail.com/T/#u rinse repeat 🙂
03:09airlied[d]: found a missing one line, not sure it's it, but appreciate giving that one a spin
08:46marysaka[d]: same as last time
08:46marysaka[d]: even the address match :aki_thonk:
09:49airlied[d]: Running out of good ideas, have to start thinking of bad ones
10:21marysaka[d]: same here tbh... the only thing I'm still a bit suspicious about is `nvkm_vmm_ref_hwpt` not unsetting `NVKM_VMM_PTE_VALID` in case of `LPT` non-sparse
10:21marysaka[d]: but even then it shouldn't really be possible actually so I'm not sure
10:23marysaka[d]: (I'm talking about the else block in case pgt->refs[1] == 0)
10:48airlied[d]: Yeah I went into that path a bit today, but it might be possible if we unref lpt and ref if again that something goes wrong in recreating it
10:49airlied[d]: I was tempted to try just always creating both hwpt and letting them live for the lifetime of the pt
12:08marysaka[d]: that would simplify stuffs quite a bit yeah....
17:23marysaka[d]: https://cdn.discordapp.com/attachments/1034184951790305330/1466483977002029316/test_comp_kern.log?ex=697ce922&is=697b97a2&hm=077059ca85c185f34fd815ce4922fad4cb6c4fa315cd7aadee65945f41623fd1&
17:23marysaka[d]: I don't know if that could help but I refined my runner script to only keep the last run of dmesg logs and reduced the testcase group (only running `dEQP-VK.renderpasses.renderpass1.dedicated_allocation.formats.r8_unorm.*`)
21:08snowycoder[d]: karolherbst[d]: It was more than 8 bits in sm30?
21:08snowycoder[d]: Sorry I originally made it for sm32, I didn't have any sm30 card
21:09snowycoder[d]: Also, hi everybody, miss you :3
21:09snowycoder[d]: I'm still alive, just very tired
21:13mhenning[d]: snowycoder[d]: I hope you have a chance to rest! ❤️
21:15snowycoder[d]: mhenning[d]: I still have some patches to send so I better do!
21:26karolherbst[d]: snowycoder[d]: sm20 encodes it as 16 it seems: `e.set_field(26..42, self.off);`
21:56emufan4568[d]: Hi, I have a vk app that creates a large sparse resident buffer (1 << 36) whose creation succeeds on prop but fails on nvk, I suspect its due to this check https://gitlab.freedesktop.org/mesa/mesa/-/blob/main/src/nouveau/vulkan/nvk_buffer.c#L111 should this maybe check against something like NVK_SPARSE_ADDR_SPACE_SIZE when residency flag is present?
22:28mhenning[d]: emufan4568[d]: We have a number of places where we use 32-bit arithmetic for buffers internally. so there's a decent chance that this would require more effort than that to support correctly
22:29mhenning[d]: The limit is advertised as VkPhysicalDeviceMaintenance4Properties::maxBufferSize and you need to stay within it or you violate VUID-VkBufferCreateInfo-size-06409
22:30mhenning[d]: There's a bug for exposing a larger address space: https://gitlab.freedesktop.org/mesa/mesa/-/issues/14497
22:32emufan4568[d]: I see thanks for explanation!
22:33emufan4568[d]: How is that issue in terms of difficulty? I might experiment with trying it locally if that isn't in the roadmap in near future ig
22:36mhenning[d]: If you want to be able to bind a single ssbo that's over 4 GB it will be a decent amount of work - there are a bunch of core compiler pieces that assume the ssbo size is 32 bits
22:36mhenning[d]: There might be a way to let you create buffers that are larger but still have a limit on the size of a single ssbo that will be less work
22:36emufan4568[d]: In my case I don't want any buffer thats > 4GB but the offset of that buffer inside that sparse can be large
22:37mhenning[d]: Yeah, I'm not really sure how hard that will be
22:37emufan4568[d]: I built NVK locally with that check removed and it seemed to work, though something might be broken from what you mentioned
22:37mhenning[d]: The ssbo base addresses are typically 64-bit already, so some of that may work
22:38mhenning[d]: You'll probably want to run cts to test if anything is broken though