Features

Sections

Easy Resource Lifetimes

  1. Most resources are reference counted in Daxa (Instance, Device, Swapchain, Semaphore, ...) for convenience.
  2. For shader resources (Buffer, Image, ImageView, Sampler) however, Daxa does not reference count, because :
    1. Bindless shader resource IDs/addresses can be stored in buffers and other memory, making Daxa unable to consistently track them.
    2. In API calls, they are mentioned with much higher frequency compared to other objects, making their tracking with reference counts much more expensive.
    3. In contrast to other objects, it is very common to build other more specialized lifetime management for shader resources (eg. static, cached, streamed, dynamically created, ...).
  3. The destruction of any resource is deferred until all submits, currently running at the time of the destroy call, are finished. This makes it safe to call destroy on resources in most cases.
  4. Extensive debug checks for any number of cases with sensible error messages detailing what could have gone wrong.
  5. Thread safety can optionally be disabled via a preprocessor macro definition.
    1. Calls to CommandRecorder from multiple threads are NOT threadsafe.
    2. Utils generally are not threadsafe.
    3. All Other objects are generally threadsafe to access from multiple threads simultaneously.

Ergonomic Swapchain

  1. Swapchain contains its semaphores for timing:
    1. acquire semaphores, one for each frame in flight,
    2. present semaphores, one per swapchain image,
    3. a timeline semaphore, used to limit frames in flight.
  2. The correct set of semaphores can be queried with member functions, they are changed after every acquire call.
  3. The swapchain integrates frame in flight limiting, as it is natural for it to handle this.
  4. Easy-to-use interface for recreating the swapchain.

Simple Renderpasses

  1. Daxa does not have the concept of a pre-created renderpass for framebuffers.
  2. To render, you begin and end a renderpass section directly within a command list.
  3. This can be done very efficiently, Daxa does not cache or lazy create anything for this behind the user's back, as Vulkan 1.3 has a feature mapping directly to this interface.
  4. This drastically simplifies rendering and removes a lot of object coupling. Pipelines are completely decoupled of framebuffers or renderpass objects.

Powerful CommandRecorders

  1. The vulkan command pool is abstracted. Daxa maintains a pool pool inside each device.
  2. CommandRecorders make command buffers and command pools easier to use and much safer per design.
  3. Each recorder is a pool + buffer. A command buffer can be completed at any time, a new command buffer is used with the same pool after completing current commands.
  4. PipelineBarrier API is made more ergonomic:
    1. CommandRecorder does not take arrays of memory barriers and image memory barriers, it takes them individually.
    2. As long as only pipeline barrier commands are recorded in sequence, they will be batched into arrays.
    3. As soon as a non-pipeline barrier command is recorded, all memory barriers are recorded to the command buffer.
    4. This effectively is mostly syntax sugar, but can be quite nice to reduce Vulkan API calls if the barrier insertion is segmented into multiple functions.
  5. As mentioned above in the lifetime section, CommandRecorders can record a list of shader resources to destroy after the command list has finished execution on the GPU.
  6. CommandRecorder changes type in render passes to ensure correct command use by static type safety!
  7. CommandRecorders have a convenience function to defer the destruction of a shader resource until after the command list has finished execution on the GPU.
    1. Very helpful to destroy things like staging or scratch buffers.
    2. Necessary as it is not legal to destroy objects that are used in commands that are not yet submitted to the GPU.

Tiny Pipelines

  1. Pipelines are much simpler in Daxa compared to normal Vulkan, they are created with parameter structs that have sensible defaults set for all parameters.
  2. Because of the full bindless interface and full descriptor set and descriptor set layout abstraction, you do not need to specify anything about descriptors at pipeline creation.
  3. Daxa again does this very efficiently with no on-the-fly creation, caching or similar, all cost is fixed and on creation time.
  4. As Renderpasses and framebuffers are abstracted, those also do not need to be mentioned, pipelines are decoupled.
  5. The pipeline manager utility makes pipeline management very simple and convenient.

Effective use of modern Language features

  1. Nearly all functions take in structs. Each of these info structs has defaults. This allows for named parameters and out-of-order defaults!

Safety and Debuggability

  1. IDs and reference-counted handles are fully threadsafe
  2. all Vulkan function return values are checked and propagated
  3. lots of custom checks are performed and propagated
  4. lots of internal validation to ensure correct Vulkan use
  5. preventing wrong use by design
  6. Using type safety for correct command recording
  7. Integrated object naming (used by tooling validation layers and Daxa itself).

Other Features

  1. Automatically managed memory allocations with VMA. Optionally exposed manual management.
  2. Daxa stores and lets you get the info structs used in object creation. Very useful, as you do not need to store the object's metadata yourself.
  3. Abstraction of image aspect. In 99% of cases (Daxa has no sparse image support) Daxa can infer the perfect image aspect for an operation, which is why it's abstracted to reduce boilerplate.
  4. Next to bindless, Daxa also provides simplified uniform buffer bindings, as some hardware can still profit from these greatly.
  5. FSR 2.1 integration
  6. ImGUI backend
  7. Staging memory allocator utility. Provides a fast linear staging memory allocator for small per-frame uploads.