Random numbers every GPU agrees on

In the noise article, a hash was a shader’s dice, a little arithmetic that turns a cell’s number into a random looking number from 0 to 1. There’s one famous hash you’ll find in shaders everywhere:

frac(sin(dot(p, float2(12.9898, 78.233))) * 43758.5453)

It hides a nasty secret, though. On two different GPUs it can roll different numbers. Let’s find out why, then build a hash that rolls the very same numbers on every GPU.

The same demo rendered in Unity. Twinkling sparkles in a dark sky, one per grid cell, with a split line down the middle. — Fig. 1
Left of the line the sine hash places one sparkle per cell, right of it the integer hash we’ll build. Slide **Distance** to 5, a hundred thousand cells from the origin, then to 6. On my PC the left sparkles bunch into rows, then vanish. Your GPU may break in its own way. Set **Show** to Numbers to see each cell’s raw number.

What sin really is on a GPU

A GPU doesn’t work out sine exactly. It runs a fast approximation in hardware, and the rules for how good it must be are loose:

GLSL ES 3.00, the language behind WebGL 2, leaves the precision of sine undefined.
Vulkan allows an error of $2^{-11}$ , about 0.0005, but only between $-\pi$ and $\pi$ .
Direct3D allows 0.0008 between $-100\pi$ and $100\pi$ .

Outside those ranges, nothing is promised at all. On my PC, sin is off by up to 0.0003 for inputs below three thousand, and by more further out. Mobile GPUs, like the ones in Quest headsets and Android phones, can run math written with half at 16 bit precision, where Vulkan allows sine an error of $2^{-7}$ , almost 0.008.

The 43758 magnifier

Now let’s see what the hash does with that slightly wobbly sine:

\begin{aligned} a &= 12.9898\,x + 78.233\,y \\ h &= \operatorname{frac}(43758.5453 \sin a) \end{aligned}

$x$ and $y$ are the cell’s numbers, $a$ the angle they make, and $h$ the hash. Frac keeps only the part after the decimal point. Multiplying by 43758 turns every tiny wobble into a big one. If two GPUs disagree about $\sin a$ by 0.00002, the products differ by almost 0.9, and after frac the two hashes have nothing in common.

What 43758 does to a wobble

Turn on JavaScript to run this demo.

Code for the plot above

f1(x):frac((sin(1.0) + x * 0.000001) * 43758.5453)
f2(x):sin(1.0) + x * 0.000001

#define PLOT_X_RANGE float2(0.0, 60.0)
#define PLOT_Y_RANGE float2(-0.05, 1.05)
#define PLOT_TICK float2(10.0, 0.2)
#include "plot"
float curve0(float x) { return frac((sin(1.0) + x * 0.000001) * 43758.5453); }
float curve1(float x) { return sin(1.0) + x * 0.000001; }
float4 shade(float2 uv)
{
    float2 p = plotCoord(uv);
    float3 col = plotBackground(p);
    float h = plotPixel().x;
    col = plotCurveStyled(col, p, curve0(p.x), plotSlope(curve0(p.x - h), curve0(p.x), curve0(p.x + h), h), series1(), 0);
    col = plotCurveStyled(col, p, curve1(p.x), plotSlope(curve1(p.x - h), curve1(p.x), curve1(p.x + h), h), series2(), 1);
    return float4(col, 1.0);
}
#define PLOT_X_RANGE vec2(0.0, 60.0)
#define PLOT_Y_RANGE vec2(-0.05, 1.05)
#define PLOT_TICK vec2(10.0, 0.2)
#include "plot"
float curve0(float x) { return fract((sin(1.0) + x * 0.000001) * 43758.5453); }
float curve1(float x) { return sin(1.0) + x * 0.000001; }
vec4 shade(vec2 uv)
{
    vec2 p = plotCoord(uv);
    vec3 col = plotBackground(p);
    float h = plotPixel().x;
    col = plotCurveStyled(col, p, curve0(p.x), plotSlope(curve0(p.x - h), curve0(p.x), curve0(p.x + h), h), series1(), 0);
    col = plotCurveStyled(col, p, curve1(p.x), plotSlope(curve1(p.x - h), curve1(p.x), curve1(p.x + h), h), series2(), 1);
    return vec4(col, 1.0);
}
Names in this code (19)colDeclared on line 10: float3 col = plotBackground(p);
curve0float curve0(float x)
curve1float curve1(float x)
fracThe part after the decimal point, in HLSL. GLSL calls it fract.
hDeclared on line 11: float h = plotPixel().x;
includePulls another file into this one, for example UnityCG.cginc.
pDeclared on line 9: float2 p = plotCoord(uv);
plotBackgroundfloat3 plotBackground(float2 p) (plot library)
plotCoordfloat2 plotCoord(float2 uv) (plot library)
plotCurveStyledfloat3 plotCurveStyled(float3 col, float2 p, float y, float slope, float3 ink, int style). The same line, solid (style 0), dashed (1) or dotted (2), so curves differ by more than color. (plot library)
plotPixelfloat2 plotPixel(). Size of one pixel in data units. (plot library)
plotSlopefloat plotSlope(float before, float here, float after, float h). f'(x) from f one pixel before, at and after x. Where f jumps (a step, a saw tooth), one side changes by many pixels and the other hardly at all: then the gentler side wins, so the line ends on each side of the jump instead of smearing up and down through it. (plot library)
series1float3 series1() (common library)
series2float3 series2() (common library)
shadefloat4 shade(float2 uv)
uvA parameter of shade(), line 7: float2 uv.
xA parameter of curve0(), line 5: float x.
defineWith #define NAME value, every NAME in the code is replaced by value before compiling.
sinsin(a) is the sine of the angle a, in radians.

Fig. 2

The bottom axis shows how far a GPU’s sine of 1 is off, in millionths. The dashed pink sine looks flat, while the solid mint hash climbs from 0 to 1 every 23 millionths.

I can’t put a second GPU in your computer, so the next demo fakes one. It works out each cell’s hash twice, once with your GPU’s sin and once with a stand-in sine of mine built from a short polynomial.

The same demo rendered in Unity. A grid of cells, nearly all pink, with a few scattered mint cells. — Fig. 3
The stand-in sine plays another GPU. On my PC the two sines differ by less than 0.0002 here, yet nearly every cell is pink, meaning its two hashes disagree. Mint cells agree. Switch **Show** to see each hash alone. Both look like fine noise.

Large inputs make it worse even on one GPU. A float keeps about seven significant digits, so around a million, neighbouring floats are 0.0625 apart. Far from the origin $a$ runs into the millions, and its fine digits are gone before sin even starts. On my PC, sin’s answer out there can be off by more than 1. That’s the rows in the first demo. A hash fed _Time.y gets coarser the same way as a world runs on.

Why VRChat makes it matter

Every player in VRChat renders your avatar on their own GPU. With a sine hash, the glitter on your outfit can sparkle in different places for each viewer, and a pattern placed by world position far from the origin can turn streaky. On Quest and Android, avatars may only use VRChat’s mobile shaders, but world shaders run there, on mobile GPUs.

Hash without Sine gives steadier floats

Dave Hoskins’ Hash without Sine, the one from the noise article, skips sine. It only multiplies, adds and takes frac, and GLSL ES asks for every multiply and add to be rounded correctly. Pick it under Left half in the first demo. On my PC it holds up even ten million cells out.

A little wiggle room is left. A GPU may fuse a multiply and an add into one step that rounds once, and Direct3D lets hardware cut off the last bit instead of rounding it. Either can change a last digit, and a hash turns last digits into new numbers. Rare, but possible.

Whole numbers wrap the same everywhere

Integers never round. A uint holds exactly 32 bits, and when a sum or a product overflows, it wraps around and keeps the lowest 32 bits. GLSL ES 3.00 demands this, and Direct3D’s integer math works the same way. Same input, same bits, on every GPU.

PCG is a hash made of exactly that. Mark Jarzynski and Marc Olano tested over a hundred GPU hash variants for quality and speed, and PCG came out a good default. Nathan Reed puts it plainly. “It should probably be your default GPU hash function.”

uint pcg(uint v)
{
    uint state = v * 747796405u + 2891336453u;
    uint word = ((state >> ((state >> 28u) + 4u)) ^ state) * 277803737u;
    return (word >> 22u) ^ word;
}

Line one multiplies, adds and wraps. Line two shifts the bits by an amount they pick themselves and mixes them back in with xor (^). Line three folds the high bits into the low ones. For a cell’s two numbers, nest it: pcg(x + pcg(y)). The paper found that nesting keeps the quality, while adding weighted numbers first makes repeating patterns.

From bits to a number from 0 to 1

u = \lfloor n / 2^8 \rfloor \cdot 2^{-24}

$n$ is the 32 bit hash. Dividing by $2^8$ and rounding down keeps its top 24 bits (n >> 8u), and $u$ runs from 0 up to a hair under 1. Why 24? A float holds every whole number up to $2^{24}$ exactly, and multiplying by a power of two only changes its exponent. Nothing rounds, so every GPU gets the exact same float. That’s toUnit in the code under the first demo.

From a position to a whole number

A shader’s positions are floats. Round down with floor, turn that into an int, and only then into a uint: uint2(int2(floor(p))).

Skipping the int is a trap. GLSL ES 3.00 leaves a negative float turned into a uint undefined, and Direct3D clamps it to 0. From int to uint, GLSL ES and HLSL both keep the bits, so -1 becomes 4294967295 and every cell keeps a number of its own.

The same demo rendered in Unity. Mint, pink and butter tiles in random shades on a dark grid, with the two axes crossing in the middle. — Fig. 4
Switch **Convert** to Straight to uint. On my PC every negative number becomes 0, so rows and columns left of and below the middle repeat, and the bottom left is one block. Through int, every tile gets its own color.

In practice

A sparkle per UV cell, with pcg2 and toUnit from the code under the first demo:

uint2 cell = uint2(int2(floor(i.uv * _Cells)));
uint n = pcg2(cell);
float bright = toUnit(n);       // 0 to 1, the same on every GPU
float size = toUnit(pcg(n));    // a second, fresh number

Integers in Unity. Whole number math needs #pragma target 3.5 or higher.
Full precision. GLSL ES lets a mediump integer be as small as 16 bits. Keep hashes in plain uint, never min16uint.
Steady input. A world position far from the origin has lost its fine digits before any hash sees it. Hash UVs or object positions when you can.

Credits

PCG is Melissa O’Neill’s random number family. The GPU hash and its tests are from Mark Jarzynski and Marc Olano’s Hash Functions for GPU Rendering (JCGT, 2020); my pcg follows Nathan Reed’s summary.
Hash without Sine is by Dave Hoskins (MIT License). Inigo Quilez’s integer hashes are another family the paper tests.

Takeaways

A GPU’s sine is an approximation with loose rules, and the sine hash blows its tiny errors up into different numbers.
Hash without Sine is much steadier, and integer hashes such as PCG give the very same bits on every GPU.
Turn positions into whole numbers through int, and hashes into 0 to 1 with their top 24 bits.