Vulkan Backend

The Vulkan backend is a multi-platform backend implemented using the Vulkan API. Vulkan is supported on Windows, Linux, and Android. Vulkan's API is very close to Veldrid's and as such this is a fairly simple, straightforward backend.

Vulkan GraphicsDevices are created from a VkSurfaceSource, which is a platform-specific object used to create a Vulkan surface (VkSurfaceKHR). The following helper functions are available:

  • CreateWin32: Creates a VkSurfaceSource for the given Win32 instance and window handle.
  • CreateXlib: Creates a VkSurfaceSource for the given Xlib display and window.

API Concept Map

Veldrid Concept Vulkan Concept Notes
GraphicsDevice VkDevice, VkPhysicalDevice, VkCommandPool, VkDescriptorPool, VkQueue
CommandList VkCommandBuffer
DeviceBuffer VkBuffer
BufferUsage VkBufferUsageFlagBits
Texture VkImage
TextureUsage VkImageUsageFlagBits
TextureView VkImageView
Sampler VkSampler
Pipeline VkPipeline
Blend State VkPipelineColorBlendStateCreateInfo
Depth Stencil State VkPipelineDepthStencilStateCreateInfo
Rasterizer State VkPipelineRasterizationStateCreateInfo
PrimitiveTopology VkPrimitiveTopology, VkPipelineInputAssemblyStateCreateInfo
Vertex Layouts VkPipelineVertexInputStateCreateInfo
Shader VkShaderModule
ShaderSetDescription None
Framebuffer VkFramebuffer
ResourceLayout VkDescriptorSetLayout
ResourceSet VkDescriptorSet
Swapchain VkSwapchainKHR

Notes

Veldrid's API is modeled after modern graphics API's like Vulkan. As a result, this backend is simple, straightforward, and has very good performance. Driver support for Vulkan remains somewhat less common than other graphics API's, but new GPUs from all major vendors support Vulkan. In time, Vulkan will likely be supported by all major systems.

Memory Management

Memory management must be custom-handled in Vulkan. The VkDeviceMemoryManager class allocates and reclaims all memory needed in the Vulkan backend. In general, the allocation handling is as follows:

  • The manager tracks several "chunk allocators", one for each type of memory (the memoryTypeBits and VkMemoryPropertyFlags identify a "type" of memory).
  • Each chunk allocator tracks a set of contiguous allocations of real physical device memory.
  • When requested, an individual chunk allocator identifies a free chunk of memory (or allocates one), and subdivides it into an appropriate block for usage by the caller.
  • Chunk allocators also reclaim memory when a resource is disposed.

Staging Textures

Staging Textures are actually implemented using VkBuffers, rather than VkImages. This has no observable effect on the implementation, and is actually the recommended approach.

Linear VkImages would be another option, but they are extremely limited in most Vulkan implementations, and cannot support all of the possible permutations of a staging Texture (dimensions, mips, array layers, etc.). For example, almost all Vulkan implementations require that Linear images be 2D (not even 1D), have one mip level, have one array layer, and are a small subset of pixel formats. Since staging Textures are conceptually just a contiguous, tightly-packed block of memory, a VkBuffer works perfectly and has none of the above limitations. Simple arithmetic can convert between the buffer' linear address space into a Texture's 1D, 2D, or 3D address space. Vulkan has a variety of commands that perform copies between VkBuffers and VkImages.