01:28 i509vcb: Wild idea that popped into my mind. If we had a Vulkan implementation that implements all the GPU stuff in compute, it would theoretically be possible to get a "working" Vulkan driver with just working compute and then be able to slowly transition over to using the actual fixed function GPU hardware?
01:28 i509vcb: Of course the devil is in the details and it sounds like a lot of work
01:35 HdkR: Sounds like what the RISC-V GPU people are trying to accomplish
01:39 i509vcb: yeah I have heard of the RISC-V GPU and saw the XDC 22 presentation on the idea
01:40 i509vcb: The idea here being less about compute only and more for speeding up driver development to get to a point where something is usable before doing the fun optimization by using the proper graphics hardware
01:43 HdkR: Writing a compute implementation and also an implementatino that uses the hardware is likely slower than just using the hardware.
01:44 HdkR: Do the work once instead of twice.
01:46 i509vcb: yeah I guess that is a practical issue with the idea, you'll need to do the work to use hardware at some point
14:48 DemiMarie: HdkR i509vcb: Compute-only implementations are necessary if one wants to use Vulkan Compute in the HPC space, since HPC GPUs only have compute and no fixed function at all.
15:43 MrCooper: reading zmike's blog about readback, I was somewhat surprised that Vulkan doesn't allow readback from presented swapchain images (since there's explicit sync for the presentation anyway), but I was very surprised that it doesn't guarantee presented swapchain image contents being preserved, as that precludes any buffer age based optimizations
16:15 Company: MrCooper: Vulkan has a flag on swapchain creation about retaining contents, no?
16:17 Company: it's actually written very wonky
16:17 Company: the clipped property in https://registry.khronos.org/vulkan/specs/1.3-extensions/man/html/VkSwapchainCreateInfoKHR.html
16:17 Company: which talks about readback in the info box
16:23 Company: MrCooper: but Vulkan handles this somewhat differently, in that there's https://registry.khronos.org/vulkan/specs/1.3-extensions/man/html/VkPresentRegionsKHR.html which you pass to vkQueuePresent()
16:24 Company: which requires https://registry.khronos.org/vulkan/specs/1.3-extensions/man/html/VK_KHR_incremental_present.html
16:24 Company: so you can essentially implement buffer age, but without any guarantees about readback
16:27 Company: ie the swapchain implementation could give you an image with undefined contents, you only draw the section that changed, pass the present region and then the swapchain only updates those
16:28 Company: essentially allowing you to implement an X server with everyone drawing to the root window
16:28 Company: and expose events only updating the changed regions
16:39 MrCooper: are you sure that doesn't require the presented swapchain image to have complete valid contents? Because Wayland does, so if this doesn't, it'd be tricky to support efficiently on Wayland
16:40 Company: I think the Wayland implementation can just guarantee that
16:41 Company: but a different implementation doesn't have to
16:44 Company: I read the specification so that I only need to update the changed regions if I use incremental present
16:44 Company: which means a Wayland implementation would need to guarantee that contents in the swapchain buffers stay unmodified
16:46 Company: that's how the GTK Vulkan renderer works fwiw
16:48 Company: ie we only update the change region (or something suitable, might be the bounding box of all changes) and send that region over
16:48 Company: so we assume everything outside of that stays unmodified
16:49 Company: and so far it works
16:50 MrCooper: so you're relying on something which apparently isn't guaranteed by Vulkan
16:52 Company: as I said, that's questionable
16:52 Company: and depends on how you want to read the spec
16:53 Company: "Applications should set this value to VK_TRUE if they do not expect to read back the content of presentable images before presenting them or after reacquiring them"
16:54 Company: which reads to me as "set this to false and you can readback the image"
17:12 Company: MrCooper: btw, that approach in GTK seems to work on Windows (and X), too
17:24 Company: fwiw, the other stuff is correct
17:32 Company: not sure why you need to spam present/acquire though - just acquire all the images there are until you got the one you want?
17:33 Company: hrm okay, maybe that breaks down because the last one only becomes acquirable again after you present a new one
17:34 Company: my assumption was always that the compositor may want to operate on the image, ie do layout transitions, while it uses it
17:35 Company: and such a compositor would make it non-accessible during that time because it's in an unknown state