Getting Started with KDGpu¶
What is KDGpu?¶
KDGpu is a modern, type-safe C++ wrapper for the Vulkan graphics API. It provides a clean, high-level interface that reduces boilerplate code while maintaining full control over GPU operations and excellent performance.
Key benefits:
- Simplified API: Less verbose than raw Vulkan while keeping the same power and flexibility
- Type Safety: Strong typing prevents common errors at compile time
- Automatic Resource Management: RAII-based objects to manage GPU resource lifetimes, handles to reference objects safely
- Zero Overhead: Thin wrapper with no runtime performance cost
- Familiar Concepts: API structure closely mirrors Vulkan for easy learning
Who Should Use KDGpu?¶
KDGpu is ideal for:
- Graphics Developers who want Vulkan power without the verbosity
- Game Engine Developers building modern rendering systems
- Technical Artists creating compute-based tools and effects
- Researchers implementing GPU-accelerated algorithms
- Educators teaching modern graphics programming concepts
If you need direct GPU access with modern C++ ergonomics, KDGpu is for you.
Quick Start Example¶
A KDGpu application typically follows these steps:
- create a VulkanGraphicsApi
- use it to create an Instance
- select an Adapter (physical GPU)
- create a Device and obtain a Queue
- upload geometry data to a Buffer
- compile SPIR-V shaders into ShaderModule objects
- build a GraphicsPipeline with a PipelineLayout
- record commands with a CommandRecorder (begin render pass → set pipeline → bind buffers → draw → end)
- submit the resulting CommandBuffer to the queue
For a complete, runnable example see Hello Triangle.
Core Concepts¶
Before diving into KDGpu development, familiarize yourself with these fundamental concepts:
Handles and Resource Management¶
KDGpu uses a handle-based system for GPU resources.
When you create a GPU resource through a KDGpu frontend object e.g:
1 | |
KDGpu allocates an underlying Vulkan wrapper object (VulkanBuffer) in an internal pool and returns a lightweight Handle that references it.
The frontend buffer object owns the pool entry and manages its lifetime, while the Handle is a small, cheaply copyable token you pass around the rest of your code to safely reference that Vulkan wrapper.
When the owning frontend object is destroyed, the pool entry is released and all existing Handles to it become invalid — preventing use-after-free bugs without requiring manual reference counting.
Handles provide:
- Safe references: Prevent use-after-free bugs
- Lightweight copying: Handles are small and efficient to pass around
Learn more: KDGpu Handle-Based Ownership Model
Device as Factory¶
The Device is your factory for all GPU resources. Everything you create comes from the device — buffers, textures, pipelines, samplers, bind groups, and command recorders all originate from Device method calls.
Pipelines Define GPU Work¶
Pipelines encapsulate the complete GPU rendering or compute state:
- Graphics Pipelines: Define how geometry is rendered (shaders, blending, rasterization)
- Compute Pipelines: Define GPU compute operations (shaders, workgroup size)
- Ray Tracing Pipelines: Define ray tracing behavior (ray generation, hit shaders)
Command Recording¶
GPU work is recorded into command buffers and submitted to queues. A CommandRecorder records render passes, compute passes, and resource copy operations. The finished CommandBuffer is submitted to a Queue for execution.
Learning Path¶
Follow this recommended path to master KDGpu:
Step 1: Understand the API Architecture¶
Start with the API overview to understand how KDGpu is organized and how it maps to Vulkan concepts.
Read:KDGpu API Overview
This page covers:
- Overall API architecture and class organization
- The rendering pipeline from instance to presentation
- How different components work together
Step 2: Learn Resource Management¶
Understanding how KDGpu manages resources is crucial for writing correct, leak-free code.
Read:KDGpu Handle-Based Ownership Model
This page covers:
- How handles work internally
- Resource lifetime management
- Pool-based allocation strategies
- RAII patterns in KDGpu
Step 3: Master Vulkan Mapping¶
If you're familiar with Vulkan or need to reference Vulkan documentation, understand how KDGpu maps to Vulkan.
Read:KDGpu to Vulkan API Mapping
This page provides:
- Complete KDGpu to Vulkan type mappings
- Function call equivalents
- Links to Vulkan specification
Step 4: Explore the Class Documentation¶
Browse the detailed class documentation to learn about specific features and usage patterns.
Key classes to explore:
- Instance - Application-wide Vulkan instance
- Adapter - Physical GPU device selection
- Device - Logical device and resource factory
- Buffer - GPU memory buffers
- Texture - Image and texture resources
- GraphicsPipeline - Graphics rendering pipeline
- CommandRecorder - Command buffer recording
- Queue - Command submission and execution
Step 5: Study the Examples¶
Practical examples demonstrate real-world usage patterns and best practices.
Check out the KDGpu examples repository for complete, runnable applications showing:
- Basic triangle rendering
- Texture mapping
- Compute shaders
- Multi-pass rendering
- Ray tracing
- And more...
Next Steps¶
You now have the foundational knowledge to start developing with KDGpu. Here's what to do next:
- Read the core documentation: Work through the KDGpu API Overview, KDGpu Handle-Based Ownership Model, and KDGpu to Vulkan API Mapping pages
- Study the KDGpu Examples: Look at complete applications in the examples repository
- Build something small: Start with a simple triangle or quad renderer
- Explore advanced features: Experiment with compute shaders, ray tracing, or multi-pass rendering
- Join the community: Connect with other KDGpu developers and share your work
Welcome to KDGpu development!
KDGpu Handle-Based Ownership Model
Updated on 2026-03-14 at 00:03:56 +0000