Bézier surfaces are a standard representation for smooth geometry in computer graphics. Car bodies, organic character shapes, and many other smooth objects can all be conveniently expressed as collections of bicubic Bézier patches, where each patch consists of 16 control points. To render them efficiently, those patches can be broken down into triangles. This post gives a brief look at the ideas behind our paper presented at the Eurographics Symposium on Rendering (2026) on doing exactly that, fast and crack-free, using GPU work graphs.
Hardware tessellation handles the conversion to triangles directly. It works by assigning tessellation factors to each patch: two inner factors controlling the interior grid density in u and v, and four outer factors that must match the neighboring patches to prevent cracks along shared edges. The factors can be made view-adaptive based on projected screen size or patch curvature. The problem is that the two inner factors dictate the entire patch uniformly. A patch that curves sharply in one corner and is nearly flat everywhere else still gets a uniform grid of triangles across its whole surface, producing more triangles than the image requires.
To avoid this, the conversion can be expressed as a recursive problem. You ask: is this patch flat enough to approximate as two triangles? If yes, draw it. If not, split it into four sub-patches and ask again. The result adapts naturally to curvature and distance from the camera, concentrating triangles only where they matter. Drag the slider above to compare the two wireframes side by side.
Recursive subdivision is difficult to implement efficiently on a GPU. Conventional compute-based approaches spread the recursion across multiple dispatches with explicit synchronization barriers between levels. Worse, they require large worst-case buffers, since the GPU must pre-allocate memory for the maximum possible number of sub-patches, even if most patches terminate early. Memory quickly becomes the bottleneck.
Our paper introduces several techniques that work together to address this. Rather than storing all 16 Bézier control points for every sub-patch (192 bytes each), we represent a sub-patch as just 8 bytes encoding its position in a subdivision quad tree. The actual control points are reconstructed on demand from the base patch using a numerically stable evaluation based on tensor product blossoms. This evaluation is designed so that neighboring patches compute bitwise-identical positions on shared boundaries, which is the key to producing a crack-free result without any communication between patches.
When adjacent patches reach different subdivision depths, cracks would normally appear along their shared edges. We close them with small wedge triangles that each patch generates independently.
The following figure shows our Work Graph:
The Entry node starts the process, dispatching one thread per base-patch. If a patch needs subdivision, Entry emits four child records to the Quad node, one per sub-patch. Quad performs the same job recursively: it reconstructs the sub-patch control points on demand, tests the flatness criterion, and either splits further by enqueuing itself again via work graphs’ trivial recursion, or passes the finished patch to BundleQuads. BundleQuads collects up to 512 patches at a time and forwards the batch as a single record to the Draw mesh node, which outputs the triangles and wedges directly to the rasterizer. A single CPU dispatch drives all of this. There are no explicit barriers between levels and no worst-case buffer allocations: the work graphs runtime allocates only what is actually needed.
GPU view-adaptive crack-free subdivision of Bézier surfaces demo video.
At equivalent image quality, our method renders on par with hardware tessellation while producing significantly fewer triangles across the scene. The work graphs implementation also turned out to be considerably simpler to write than the execute-indirect equivalent: one dispatch on the CPU side, no manual synchronization, and no buffer management between levels. We see this as a broader signal that GPU work graphs are a natural fit for any recursive splitting problem where the amount of work per level is not known in advance. You can see the results in the demo video above.
For more on the subdivision criterion, the watertightness guarantees, and the full performance numbers, read the paper below.
Links to third party sites are provided for convenience and unless explicitly stated, AMD is not responsible for the contents of such linked sites and no endorsement is implied. GD-97.
