GPU-Accelerated Painting

·

Screenshot pending — the Interface tab of Settings with the GPU painting checkbox visible

Painting in Vertexix runs on the graphics card by default. You should not have to think about it — the result is the same either way, and the only thing that changes is how quickly a stroke keeps up with the cursor on a heavy mesh or a large texture. This page is here for when you do need to think about it.

What runs there

A brush dab is a rasterization problem, which is the thing a graphics card is for. With GPU painting on, the work moves across almost whole:

  • The dab itself, for every channel — colour and greyscale alike.
  • The paint mask, any layer mask, the stencil and the brush image, applied as multipliers inside the shader rather than as separate passes over the pixels.
  • The Brush Mode — the blend the dab performs.
  • The layer composite, so a deep stack does not cost a full re-blend on the processor after every stroke.
  • The Clone Brush.

Only the triangles actually under the brush are submitted, and only the tiles that changed are sent back to be displayed. That is what keeps the cost of a stroke roughly proportional to the size of the brush rather than to the size of the model.

Turning it off

The switch is GPU painting on the Interface tab of Settings. There is also a --no-gpu-paint command-line switch if you need to start without it — useful when you are reporting a problem and want to know whether the GPU path is involved.

The Blur Brush is the exception

The Blur Brush runs on the processor by default even with GPU painting on, because that turned out to be the faster of the two for the way its kernel gathers samples across the surface. --gpu-blur opts into the GPU version.

What it needs, and what happens without it

The path needs a graphics context that can compile GLSL 4.00, along with 16-bit single-channel textures and maximum-blending — everything else it uses is much older than that. Most cards from the last decade qualify.

If yours does not, nothing silently degrades into a wrong result: initialization fails loudly, the setting turns itself off, and painting continues on the processor. The startup log names the reason.

Same pixels either way

The two paths are held to producing bit-identical output, and there is a verification harness that compares them dab for dab. If you ever see a difference between painting with this on and with it off, that is a bug worth reporting rather than a setting worth living with.