The same engine, different native responsibilities#
QubicEngine’s secondary backend consumes the same RenderWorld and logical RenderGraph. Scene simulation, mesh import, material parameters, and animation poses do not need to be recreated just because command submission changes. Native resource allocation, descriptor binding, barriers, pipeline creation, and presentation do. This track describes a Vulkan 1.3 reference profile with dynamic rendering, Synchronization2, and timeline semaphores. The backend checks the actual API version, features, limits, queues, formats, and surface support. A device advertising an API version still needs the relevant features enabled at device creation.
Follow the secondary path#
| Chapter | Scope |
|---|---|
| Setup | SDK, validation, instance, platform surface, feature queries, shader compilation |
| Backend | Queue families, swap chain, command recording, descriptors, pipelines, presentation |
| Resources and synchronization | Memory selection, buffer/image copies, layouts, barriers, semaphores, fences, retirement |
The Vulkan chapters are architectural implementation guidance and labeled excerpts. The delivered complete native teaching executables are DX12. No Vulkan native executable was compiled or run in this environment, and the website’s backend comparisons are illustrations.
Set up a Vulkan backend
Choose a feature profile, inspect the loader and device, create an instance and surface, and compile an explicit SPIR-V shader variant.
Explore chapter Vulkan / CHAPTERCommands, bindings & presentation
Map the shared renderer to queue families, command pools, descriptor sets, dynamic rendering, pipelines, and swap-chain images.
Explore chapter Vulkan / CHAPTERResources, layouts & synchronization
Allocate memory deliberately, transfer pixels, express stage/access dependencies, and retire work with the right host and queue completion facts.
Explore chapterA fallback needs a working implementation#
On a selected machine, Vulkan must have a suitable loader, driver implementation, and compatible physical device. The windowing surface extension must be available. Required formats and rendering features must pass queries. The engine then creates a Vulkan device and rebuilds GPU assets for that backend. A DX12 ID3D12Resource cannot become a VkImage by changing a file path. CPU source assets can be reused, but native allocations and compiled shader targets belong to their backend. If neither supported backend initializes, report the missing capability rather than implying universal compatibility.
Shared shader intent, explicit bindings#
The handbook uses HLSL for the primary path. DXC can compile a Vulkan variant to SPIR-V with deliberate descriptor-set bindings and stage interfaces. Native DX12 bytecode is DXIL, not SPIR-V. Some features, layouts, or intrinsic behavior need backend-specific variants even when most shader source is shared. Compare the API mappings and the Khronos HLSL guide. The introductory sample’s root constants are not automatically a descriptor set; the backend chooses push constants or a buffer layout appropriate to its contract.