Abstract:

This video documents a live-streamed coding session detailing a major architectural rewrite of the Hazel game engine's resource management system. The primary goal is to abstract the renderer's resource binding logic from a hard-coded Vulkan implementation to an API-agnostic approach using NVIDIA's NVRHI (Rendering Hardware Interface).

The developer walks through the design principles, such as categorizing resources by their update frequency (per-draw, per-pass, static) and using shader reflection as the source of truth for a render pass's input requirements. The core of the session involves refactoring the "Descriptor Set Manager" by replacing Vulkan-specific data structures and logic with their NVRHI equivalents, such as moving from VkDescriptorSet to nvrhi::BindingSet. The process includes updating the shader reflection system to generate NVRHI-compatible input declarations and cleaning up the class hierarchy to remove backend-specific code. The stream concludes with an initial build and debugging session, which reveals that the new validation and binding set creation logic is partially working, but also uncovers new challenges related to correctly identifying texture dimensions and handling differences between Vulkan's combined image-samplers and HLSL's separated model.

Rewriting Hazel's Resource Manager for an API-Agnostic Backend

• 0:00 Opening & Context: The stream begins by outlining the current state of the Hazel engine's new renderer. While basic clear passes are functional, the main 2D and 3D rendering is broken due to the old, Vulkan-specific resource management system. The initial goal is to get 2D rendering working as a first step.
• 6:00 Resource Management Deep Dive: The developer explains the core design of the resource manager. It is built around the concept of "resource frequency"—how often a resource (like a texture or buffer) changes. This leads to a strategy where different descriptor sets are used for different frequencies: per-draw resources (e.g., materials), per-render-pass resources (e.g., camera data), and static resources (e.g., BRDF lookup tables).
• 30:00 Descriptor Set Manager Rewrite: This section covers the main refactoring effort to convert the Vulkan-specific DescriptorSetManager to use the NVRHI abstraction layer. Key changes include replacing Vulkan write descriptors with NVRHI binding set descriptions, using static arrays for better memory layout, and moving from manual descriptor pool management to direct NVRHI binding set creation.
• 1:11:45 Handling Dynamic Resources: A key challenge discussed is managing "dynamic" resources, such as frame buffers that can be resized. The system must be able to detect when a resource's underlying handle has changed and invalidate its old binding, triggering a "rebake" of the binding set to ensure the renderer uses the updated resource.
• 1:20:00 Shader Reflection System: The system relies on shader reflection to automatically determine the required inputs for any given render pass. The developer updates this reflection pipeline to generate RenderInputDeclaration objects that are compatible with the new NVRHI-based system, mapping shader types to the appropriate NVRHI binding types.
• 1:50:00 Architecture Cleanup: To make the engine truly API-agnostic, Vulkan-specific classes like VulkanRenderPass and VulkanComputePass are removed. They are replaced by single, abstract RenderPass and ComputePass classes that contain the shared logic, while platform-specific code is moved to the appropriate backend.
• 2:20:00 Debugging Session: The first attempt to compile and run the new system is made. The initial validation logic for the camera's uniform buffer works correctly. However, the process quickly runs into several issues, including incorrect detection of texture dimensions (e.g., misidentifying a 2D texture as 1D) and complications arising from how NVRHI handles the separation of textures and samplers, which differs from the engine's previous combined-sampler approach in GLSL/Vulkan.