00:02 pavlo_kozlenko[d]: redsheep[d]: Should I roll back to the fermi?
17:10 mhenning[d]: gfxstrand[d]: Do you happen to know what's causing this? https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/33897#note_2817293
17:41 gfxstrand[d]: mhenning[d]: Backtrace?
17:41 gfxstrand[d]: I was sure I CTS'd on NVK...
17:50 mhenning[d]: gfxstrand[d]: Do you cts with assertions enabled?
17:50 mhenning[d]: Possible fix: https://gitlab.freedesktop.org/mhenning/mesa/-/commit/74078c187eda639bd22b3690eec444a947b0719e
17:50 mhenning[d]: I'm not sure if that's right though
17:50 mhenning[d]: Added a backtrace to the gitlab thread
17:51 gfxstrand[d]: What's `buffer->vk.size`?
17:51 mhenning[d]: nonzero
17:52 mhenning[d]: I can get the actual size if that's important
17:54 gfxstrand[d]: That's gotta be a CTS bug then
17:55 gfxstrand[d]: Because we always use sparse when `VK_BUFFER_CREATE_DEVICE_ADDRESS_CAPTURE_REPLAY_BIT` is set.
17:56 mhenning[d]: I don't think it's a replay
17:56 gfxstrand[d]: But it's a capture
17:57 karolherbst[d]: `Unimplemented SPIR-V capability: SpvCapabilityUniformDecoration (71)` :blobcatnotlikethis: maybe I need to remove 1.6 spirv support
17:57 mhenning[d]: Why do we special case zero in our replay paths then?
17:57 karolherbst[d]: ohh wait
17:57 karolherbst[d]: it's just a shader feature
17:57 karolherbst[d]: maybe I can just turn it on, don't mind me
17:58 gfxstrand[d]: mhenning[d]: That's the "you don't have a replay address"
17:59 gfxstrand[d]: So I think we have a bug because we shouldn't assert if `size == 0` but I'm pretty sure it's invalid to call `GetOpaqueCaptureAddress()` if you haven't set `VK_BUFFER_CREATE_DEVICE_ADDRESS_CAPTURE_REPLAY_BIT`
17:59 gfxstrand[d]: I'm also a little surprised because I've done full CTS runs on that branch.
18:00 gfxstrand[d]: Are these new tests or something?
18:01 mhenning[d]: What cts version are you on? I've used vulkan-cts-1.4.1.2 and vulkan-cts-1.4.1.0
18:02 mhenning[d]: Also vkGetBufferOpaqueCaptureAddress doesn't directly say you need VK_BUFFER_CREATE_DEVICE_ADDRESS_CAPTURE_REPLAY_BIT https://registry.khronos.org/vulkan/specs/latest/man/html/vkGetBufferOpaqueCaptureAddressKHR.html
18:05 gfxstrand[d]: I'm on fairly recent mainline
18:05 mhenning[d]: Some text says "The expected usage for this is that a trace capture/replay tool will add the VK_BUFFER_CREATE_DEVICE_ADDRESS_CAPTURE_REPLAY_BIT flag to all buffers that use VK_BUFFER_USAGE_SHADER_DEVICE_ADDRESS_BIT," but that says expected, not required https://registry.khronos.org/vulkan/specs/latest/man/html/VkBufferOpaqueCaptureAddressCreateInfo.html
18:05 gfxstrand[d]: https://registry.khronos.org/vulkan/specs/latest/man/html/VkBufferDeviceAddressInfo.html
18:06 gfxstrand[d]: Sometimes things are in the struct, not the function. *sigh*
18:06 mhenning[d]: gfxstrand[d]: can you give me a commit hash?
18:06 gfxstrand[d]: Wait, that doesn't say either
18:07 gfxstrand[d]: ba86fb95004331f2cf571dd9adefe2458290ee11
18:08 mhenning[d]: gfxstrand[d]: It looks like it does: `If buffer is non-sparse and was not created with the VK_BUFFER_CREATE_DEVICE_ADDRESS_CAPTURE_REPLAY_BIT flag, then it must be bound completely and contiguously to a single VkDeviceMemory object`
18:08 mhenning[d]: The case we're hitting is where the buffer hasn't been bound yet
18:10 gfxstrand[d]: I think we really should have a stronger condition in `GetOpaqueCaptureAddress()`. IMO, that looks like a spec bug.
18:10 gfxstrand[d]: But also, the above text should be exactly the case we're hitting
18:11 mhenning[d]: Yeah, makes sense
18:13 gfxstrand[d]: We should add an `if (buffer->vk.size == 0) return 0;`, though.
18:13 gfxstrand[d]: And similarly in `GetDeviceAddress`
18:15 mhenning[d]: gfxstrand[d]: Probably just for nvk, not for common?
18:16 mhenning[d]: I can make the MR for that
18:16 gfxstrand[d]: Yeah, just for NVK for now. The common `GetBufferDeviceAddress` just returns with no assert.
18:17 gfxstrand[d]: Actually... `vk_buffer_address()` should probably have its assert updated to `assert(buffer->size == 0 || buffer->device_address != 0)`
18:18 mhenning[d]: Right, that's what I was asking - should we do this in nvk_GetBufferOpaqueCaptureAddress or vk_buffer_address
18:19 mhenning[d]: I'm happy to just change the assert
18:20 gfxstrand[d]: Let's just change that assert then
18:20 gfxstrand[d]: The fact that Vulkan allows zero-size buffers is kinda bogus
18:22 zmike[d]: you mean the fact that it gives you the **freedom** to have zero-sized buffers is awesome
18:23 mhenning[d]: do you find zero-size buffers useful, zmike?
18:23 mhenning[d]: have a lot of zero-length information to store on your gpus?
18:26 zmike[d]: I have an unlimited amount of zero-sized information
18:28 mhenning[d]: gfxstrand[d]: Okay, yeah the test in question passes for me on that cts commit
18:29 zmike[d]: also though I think if you go back far enough in vulkan telecon minutes you'll find a line of me saying "but aren't zero-sized buffers stupid? who would want this?" and then getting shot down on The Wrong Side Of History
18:39 mhenning[d]: gfxstrand[d]: https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/33988
18:40 mhenning[d]: And yeah, the rest of it was already fixed in cts
18:41 tiredchiku[d]: quick question for ya, gfxstrand[d]
18:41 tiredchiku[d]: on x11 with that glamor patch, you said the kernel fails to handle 32x32 hardware cursors? why is it not an issue on wayland then :doomthink:
18:48 gfxstrand[d]: tiredchiku[d]: Because Wayland compositors seem to look at the DRM caps that suggest a cursor size whereas the modesetting driver tries to get smart and find the minimal size by probing the driver.
18:48 gfxstrand[d]: And Nouveau suggests a cursor size of 64x64, even though some hardware can theoretically do 32x32
19:14 tiredchiku[d]: interesting
19:14 tiredchiku[d]: thanks :saigeheart:
21:26 _lyude[d]: gfxstrand[d]: btw - setting up a machine to take a look at the cursor now
21:36 gfxstrand[d]: Thanks!
22:34 gfxstrand[d]: mhenning[d]: Any other issues with my NIL patches?
22:36 mhenning[d]: Looking at it now, got interrupted in the middle of my review earlier
22:36 gfxstrand[d]: That's okay
22:36 gfxstrand[d]: That's the last bit to land before we can flip the switch.
22:41 _lyude[d]: aaaaand she doesn't boot now???
22:41 _lyude[d]: this may take longer than anticipated
22:43 mhenning[d]: gfxstrand[d]: added my r-b
22:43 gfxstrand[d]: Thanks!
22:45 gfxstrand[d]: _lyude[d]: Nooooooo
22:47 _lyude[d]: worst case I might have to reinstall, not sure what happened. it just finished upgrading to fedora 41 and now it seems to be having trouble finding the SSD even on older kernels
22:57 gfxstrand[d]: 😭