Fast And Straightforward GPU Random Numbers In D3D11 - Nathan Reed’s Coding Weblog

Word: please see the 2021 update to this publish, here. In games and graphics one often needs to generate pseudorandom numbers. For sure, PRNGs are a particularly properly-researched matter; however, the majority of the literature focuses on purposes with very exacting quality necessities: cryptography, excessive-dimensional Monte Carlo simulations, and suchlike. These PRNGs are likely to have lots of of bytes of state and take a whole bunch of instructions to replace.

That’s manner overkill for many extra modest purposes-when you just need to do a little random sampling in a game context, you can in all probability get away with much less. To drive home just how much lower my random number standards can be for this text, I’m not going to run a single statistical test on the numbers I generate-I’m simply going to look at them! The human visual system is fairly good at picking out patterns in what we see, so if we generate a bitmap with one random bit per pixel, black or white, it’s straightforward to see if we’re producing "pretty random" numbers-or if something’s going mistaken.

The one on the left is a linear congruential generator (LCG), and on the precise is Xorshift.

We’re at all times advised that LCGs are unhealthy information, and now you possibly can see simply how dangerous! Xorshift, alternatively, is significantly better. It’ll really pass some medium-energy statistical tests, and it certainly seems to be random enough to the eye. Moreover, it’s fairly quick in comparison with other PRNGs of comparable quality. Since D3D11 GPUs help integer operations natively, it’s straightforward to port these PRNGs to shader code. GPUs do issues in parallel, so we’ll create an unbiased occasion of the PRNG for each work merchandise-vertex, pixel, or compute-shader thread.

Then we simply have to seed them with totally different values, e.g. using the vertex index, pixel display coordinates, or thread index, and we’ll get different sequences. LCGs are actually fast-updating the state takes only one imad instruction (in HLSL meeting, which is simply an intermediate language, however nonetheless an affordable proxy for machine code speed).

Xorshift is a bit slower, requiring six directions, however that’s not bad contemplating the quality of random numbers it provides you.

Determine two or three more directions to get the quantity into the vary you want, and convert it to a float if needed. On a high-end GPU, you can generate tens of billions of random numbers per second with these PRNGs, simple. Again, on the left is the LCG and on the right is Xorshift. The LCG doesn’t look too different from earlier than, but Xorshift looks absolutely terrible! PRNGs are designed to be effectively-distributed while you "go deep"-draw many values from the same occasion.

Since this includes sequentially updating the state after each value, it doesn’t map properly to the GPU. On the GPU we have to "go wide"-arrange a number of impartial PRNG situations with totally different seeds so we will draw from each of them in parallel. But PRNGs aren’t designed to provide good statistics throughout seeds. I tried a number of small PRNGs I discovered on the net, and they all produced apparent artifacts when going large, even in the event that they were completely high quality going deep.