cppgfx

CPU-based graphics library for C++

– "Look mom, no GPU!"

Instead, this is a software renderer running, written in C++ 20 and compiled to LLVM IR ➜ WebAssembly using Emscripten. Therefore, expect this to run significantly slower than hardware-accelerated WebGL (this demo is running in a single thread!).

Project on GitHub

Scene made with Blender

Features

Draw directly into a surface pointer
Write vertex and pixel shaders directly in C++ as functors, including state
- Instant access to uniform data
- Arbitrary vertex inputs and outputs
Stateless drawing functions
Alpha blending (blend states)
Depth buffering
Image sampling (samplers) including optional linear filtering
Multiple render targets
Standalone, no dependencies beside the C++ STL
- Plug & play
Multithreaded rasterization using OpenMP if available
Pretty fast!

For a draw call, almost the entire pipeline state is specified. Where possible, the library infers some information for you. This allows the library to decide which code paths to take at compile time. You therefore only pay for what you use.

Usage

Either

add_subdirectory(cppgfx), then
target_link_libraries(MyApp PRIVATE cppgfx)
#include <cppgfx.hpp>

copy cppgfx.hpp to your project and #include from there.

Example

See the Demo folder for an example application. It uses CMake and downloads all dependencies automatically. Configure & build as usual:

> cd cppgfx
> cmake -S . -B build
> cmake --build build --parallel

Have fun!

Why software rasterization?

Well, sometimes, especially in the medical field (e.g. hospitals or radiology practices), you have workstations without any sort of GPU. Even if there's a GPU, you cannot fully trust the driver to be bug-free or have deterministic behavior. If you're for example required to use OpenGL and can't trust the target drivers, you could circumvent this by using Mesa/llvmpipe as a drop-in replacement. Same goes for Direct3D with WARP.

This works fine for most cases. However, there are also cases where you need a minimal renderer that is platform-independent, does not require upfront work such as setting up a context, and is just happy to take some geometry and render target pointer; no state management necessary.

Another case would be for cheap rendering tasks where CPU ⇄ GPU synchronization would be too expensive or when the CPU has some spare idle time. See DICE's Occlusion Culling Method in Battlefield 3 for example, where they determined occluded geometry CPU-side before sending it to the GPU. A similar method has also been used in Crytek's CryENGINE 3.

TL;DR: Software renderers to this day have their use, especially in cases where no GPU is available. Even though GPUs are feature-rich, software renderers provide hassle-free and highly-flexible drawing operations, down to the pixel. Additionally, they may be used to support and relieve the GPU, instead of replacing it.

dervis.de