A new technique lets GPUs evaluate Bezier curves using the same hardware that samples textures, instead of running the usual shader math. The paper behind it, A Texture Lookup Approach to Bezier Curve Evaluation on the GPU by Muhammad Anas and Alan Wolfe, published in the Journal of Computer Graphics Techniques, shows how to pack a curve into a tiny texture and read points off it with a single hardware accelerated lookup.
This article walks through how the technique works, why it can be faster, where it falls short, and what it costs in numerical precision.
The problem with evaluating curves on a GPU
A Bezier curve is a smooth curve defined by a small number of points called control points. Games and design tools use Bezier curves everywhere, for font outlines, camera paths, motion trails, and particle movement.
To find a point on the curve at some position, usually written as a value called t between 0 and 1, a GPU normally runs the de Casteljau algorithm. This method repeatedly blends pairs of control points together, a process called interpolation, until only one point is left. For a cubic Bezier curve, the most common type, this takes several rounds of blending done directly in shader code.
A shader core is the part of the GPU that runs small programs to compute colors, positions, and other per pixel or per vertex values. Running de Casteljau there means every curve evaluation competes with all the other math the shader is already doing, lighting, shading, physics, and anything else in the frame.
The core idea, use the texture unit instead of the shader
GPUs contain a second, mostly unrelated piece of hardware built for a completely different job, sampling textures. A texture is an image mapped onto a surface, and the texture sampling unit is dedicated circuitry that reads pixels from that image and blends nearby ones together, a process called bilinear interpolation, extremely fast and almost for free from the shader's point of view.
Anas and Wolfe's insight is that bilinear interpolation is, mathematically, doing the same kind of blending the de Casteljau algorithm needs. So instead of asking the shader to compute the blending steps directly, they encode a curve's control points into a small texture. A single texture lookup, sent to hardware that is normally busy with unrelated image sampling, then returns a point on the curve.
Traditional approach. Control points feed into shader arithmetic. Several interpolation steps run one after another inside the shader. The output is a point on the curve.
Texture lookup approach. Control points get encoded into a small texture ahead of time. The GPU's texture sampling hardware performs the interpolation during a normal texture read. The output is a point on the curve.
Packing a cubic Bezier curve into a 2 by 2 texture
The paper shows that a cubic Bezier curve, defined by four control points, can be encoded using a method called Seiler interpolation into a texture as small as two pixels by two pixels. Seiler interpolation is a way of arranging values in a small grid so that standard bilinear texture sampling reproduces the intended blend when the texture is read at the right coordinates.
With the control points packed into that tiny 2 by 2 texture, a single bilinear texture lookup at the appropriate texture coordinate returns the correct point on the curve. No loop, no repeated shader side blending, just one hardware texture read.
This is a genuinely different way of framing the problem. Instead of treating curve evaluation as a math operation, it treats curve evaluation as an image sampling operation, and lets the GPU's existing image sampling hardware do the work it was built to do.
Why this works, shader cores and texture units are separate hardware
The reason this can be a real performance win, and not just a curiosity, comes down to GPU architecture. Shader cores and texture sampling units are physically separate resources inside a GPU. They can, to a meaningful degree, do work in parallel.
If an application already keeps its shader cores fully busy, and the texture units are sitting comparatively idle, moving curve evaluation from the shader to the texture unit does not compete for the same resource. It shifts work to hardware that has spare capacity, rather than adding more work to hardware that is already the bottleneck.
This also means the technique's benefit depends entirely on the balance of a given workload. A scene that is already texture heavy, with texture units doing most of the work, will not see the same gains as a scene that is shader heavy with texture units mostly idle. The benchmarks later in this article show exactly that pattern.
Beyond one curve, surfaces, volumes, and splines
The paper does not stop at a single cubic Bezier curve. The same texture lookup idea extends to several related shapes used in graphics and computer aided design.
Bezier surfaces, two dimensional grids of control points that define curved surfaces, and Bezier volumes, the three dimensional equivalent, can both be encoded into larger textures and read with the same kind of hardware accelerated lookup. Piecewise curves, made of several Bezier segments joined together, rational polynomials, and general polynomial evaluation are also covered.
The authors also address B-splines and NURBS, two curve and surface types widely used in industrial design, animation, and CAD software. A B-spline is a flexible curve built from multiple smaller curve segments joined smoothly together, and NURBS extends that same idea with additional weighting for complex three dimensional shapes.
Turning a B-spline into pieces a texture can hold
B-splines and NURBS are not natively in the same simple form as a single Bezier curve, so the paper describes converting them first. It uses a known method called Boehm's algorithm to break a B-spline into a series of ordinary Bezier segments.
Once the B-spline exists as a sequence of Bezier pieces, each piece can be encoded into its own small texture and evaluated with the same texture lookup approach used for a single cubic curve. This means the technique is not limited to simple curves used for camera paths or motion. It can, in principle, extend into more demanding surface modeling work as well, though the paper's own performance testing focuses mainly on simpler curve cases.
Benchmark one, a compute heavy path tracer
To measure real performance, the authors tested a compute heavy path tracer, a rendering method that simulates the path of individual light rays through a scene, at a resolution of 1920 by 1080 pixels with 16 rays traced per pixel.
On an RTX 4090 graphics card, the standard shader based method took 1.952 milliseconds per frame, and the texture lookup method took 1.938 milliseconds. On an RTX 3070, the shader method took 12.662 milliseconds, and the texture method took 12.496 milliseconds.
Both results favor the texture lookup method, but only slightly, around 0.7 percent faster on the RTX 4090 and around 1.3 percent faster on the RTX 3070. In a workload like this path tracer, where a huge amount of other compute work is already happening per pixel, the curve evaluation itself is a small enough slice of total work that shifting it to texture hardware barely moves the needle.
Benchmark two, a large particle simulation
The second benchmark tells a much clearer story. The authors simulated large numbers of particles moving along cubic Bezier curves on an RTX 4050, varying the particle count.
| Particle count | Shader based method | Texture lookup method |
|---|---|---|
| 1 million | 6.9 milliseconds | 6.9 milliseconds |
| 5 million | 13.9 milliseconds | 10.3 milliseconds |
| 10 million | 23.2 milliseconds | 18.6 milliseconds |
At 5 million particles, the texture lookup method cut frame time by roughly 26 percent. At 10 million particles, it cut frame time by roughly 20 percent. In this workload, curve evaluation is a much larger share of the total work per frame, since the entire simulation is essentially millions of repeated curve lookups. That is exactly the kind of workload where freeing up the shader cores by moving work to the texture unit pays off.
Why the method does not always win
The paper is careful not to present the texture lookup method as a universal speedup. The authors report cases where it actually made performance worse, because the additional memory access needed to read the encoding texture could not overlap well with the rest of the computation already happening on the GPU.
This matters for anyone considering the technique for a real project. It is not a drop in replacement that helps everywhere. It helps specifically when shader cores are the bottleneck and texture units have spare capacity, and it can hurt when memory bandwidth or texture unit load is already the limiting factor. The right move is to profile a specific workload before assuming the technique will help.
The precision cost and the hybrid fix
Texture sampling hardware does not always operate at the same numerical precision as shader math. Texture coordinates, the values that specify where in the texture to read, can be stored and processed using a more compressed, fixed point format inside the GPU rather than full floating point precision.
Fixed point storage uses a fixed number of digits after the decimal point, rather than the flexible, wider range that floating point numbers allow. The paper measures this directly and shows that relying entirely on texture hardware interpolation can introduce small but visible errors in the shape of the resulting curve, particularly for cases needing high precision.
Their solution is a hybrid approach. Part of the interpolation happens through the texture hardware, and the remaining stage is finished in the shader using full 32 bit floating point precision, the standard high precision number format used throughout graphics programming. This limits the exposure to fixed point error while still capturing most of the performance benefit from offloading part of the calculation to the texture unit.
In short, the real design choice is between full shader based computation with full precision, and partially texture based computation with a small, correctable precision cost. Which one makes sense depends on how much precision a given application actually needs and how much shader headroom it has to spare.
What this means for real graphics engines
The technique is most useful in shader bound scenarios with high curve evaluation volume, such as large particle systems, procedural animation, or any pipeline generating many curve samples per frame. It is less useful, and can even hurt performance, in workloads that are already memory bound or texture unit heavy.
The paper includes supporting implementations covering both DirectX 12 and WebGPU, two of the graphics APIs used to program modern GPUs directly, along with the path tracer and particle simulation used for testing. That gives engineers a concrete starting point for trying the technique against their own workloads rather than working from the math alone.
The broader lesson generalizes past Bezier curves specifically. GPUs contain several kinds of fixed function hardware built for narrow purposes, texture sampling among them, and workloads that are bottlenecked on general purpose shader cores can sometimes find real headroom by reframing part of their math as an operation that fixed function hardware already does well.
