Post AirQiMUzbTZdpsMDDM by gfxstrand@mastodon.gamedev.place
 (DIR) More posts by gfxstrand@mastodon.gamedev.place
 (DIR) Post #AirQiHOmZ8dS1APgLA by gfxstrand@mastodon.gamedev.place
       2024-06-12T17:24:07Z
       
       1 likes, 1 repeats
       
       Want to read some spooky driver code?https://gitlab.freedesktop.org/mesa/mesa/-/blob/main/src/intel/vulkan_hasvk/anv_batch_chain.c?ref_type=heads#L1463That function is mission-critical for performance for Vulkan on Intel hardware with older kernels/hardware.
       
 (DIR) Post #AirQiK3GhaD0FJN2iu by gfxstrand@mastodon.gamedev.place
       2024-06-12T17:24:17Z
       
       0 likes, 0 repeats
       
       In the early days of the Intel Vulkan driver, we had to deal with kernel patching of command buffers. This is because older Intel hardware only had 32-bit addresses and the kernel API didn't allow userspace to know addresses up-front. (No buffer device address for you!) Instead, the kernel would assign addresses on-demand and patch them into userspace BOs before executing. There was also a presumed address mechanism to avoid redundant relocations.
       
 (DIR) Post #AirQiMUzbTZdpsMDDM by gfxstrand@mastodon.gamedev.place
       2024-06-12T17:24:26Z
       
       0 likes, 0 repeats
       
       Unfortunately, thanks to Vulkan's execution model, the userspace driver is the only component in the system that has any idea which bits of memory actually have the right address. Also, because Vulkan heavily re-uses objects across command buffers, things like the descriptor pool would end up having relocations applied frequently and, since the descriptor pool is always in use, doing so would mean a stall on nearly every batch.
       
 (DIR) Post #AirQiOqgrm7P7kWZJQ by gfxstrand@mastodon.gamedev.place
       2024-06-12T17:24:38Z
       
       0 likes, 0 repeats
       
       The solution was to relocate in userspace and tell the kernel not to bother unless it actually moved something (which is rare). However, this means userspace is potentially racing with both the kernel and the hardware.But it's provably safe...And shipped in production for years and I never got a single bug report that ended up being that code.