Graphics Hardware and Real-Time APIs
Domain scope
Graphics Hardware and Real-Time APIs tests the GPU pipeline, command submission, memory and synchronization, and the performance model behind draw calls, bandwidth, and occupancy.
Core rules
- Modern APIs such as Vulkan, D3D12, and Metal expose explicit command buffers, pipelines, and barriers; OpenGL hides much of this in a state machine.
- A pipeline state object bundles shaders, blend, depth, and raster states so the driver can validate once.
- GPU memory is tiered: device-local for render targets, host-visible for staging; transfer queues copy between them.
- Synchronization is explicit: barriers order resource access, semaphores order queue submissions, and fences let the CPU wait.
Worked example
A 1920×1080 RGBA8 color target has 1920×1080×4=8,294,400 bytes, about 7.91 MiB. Adding a 32-bit depth buffer adds 1920×1080×4=8,294,400 bytes, doubling the per-pass storage. At 60 fps, writing only the color target once per frame moves about 475 MB/s (8.29 MB×60), before overdraw, blending, or texture reads. That is why overdraw and pass count matter more than shader instruction count on bandwidth-limited mobile GPUs.
Traps that cost marks
- Omitting a barrier between a render pass write and a shader read, causing hazards.
- Recreating pipelines or descriptor sets every frame and stalling the CPU.
- Assuming a swapchain image is available immediately; acquire and present must be synchronized.
- Writing linear values into an sRGB framebuffer without the correct format conversion.