Hacker News new | past | comments | ask | show | jobs | submit login
Hash Functions for GPU Rendering (reedbeta.com)
41 points by ingve on May 23, 2021 | hide | past | favorite | 8 comments



The empirical pseudorandomness testing situation seems kind of sad. The suite used in the paper discussed here is unmantained for many years, while its "competitor" PracRand/PractRand is not maintained for the last couple of years. It seems like the author of PractRand is the only one who tried to keep their pseudorandomness testing suite relevant, but just the compiler warnings that one gets while trying to compile it are quite scary, so it seems that there's really no project in this space that's in a remotely healthy condition :(

Here's a link to a Git mirror of PractRand, in case somebody wants to contribute or fork it: https://github.com/tylov-fork/PractRand

More broadly, it feels like the situation with non-cryptographic pseudorandom generators and/or hashes isn't in a good place. I have a hunch that making progress on that front requires effort from expert scientists, but presumably the work isn't considered grant-worthy, so there's not a lot of it?

On another note, a quite possibly stupid question; but why were the Xoshiro PRNG variants not considered in the paper?


I'm looking for code that will execute the same on all CPU/GPUs, I found this one so far:

  float rand_from_seed(inout uint seed) {
    int k;
    int s = int(seed);
    if (s == 0)
    s = 305420679;
    k = s / 127773;
    s = 16807 \* (s - k \* 127773) - 2836 \* k;
    if (s < 0)
        s += 2147483647;
    seed = uint(s);
    return float(seed % uint(65536)) / 65535.0;
  }
Any one know if the methods in this article will work too?


Why wouldn't they? CPUs and GPUs should obey IEEE-754 floating point rules, assuming you turn -ffast-math off...


Ok, we'll see. Thx!


Ok, that was way over my head. All of it but e.g.

> measured by time to render a quad evaluating the hash at each pixel

What do hash functions have to do with pixels?


Nothing, they are just drawing and shading quads as a practical GPU benchmark. Each pixel could be shaded with a pseudorandom color generated as the hash of its screen coordinates.


I see, thanks. But there is a link between graphics and hash functions, e.g. (First sentence of abstract of linked paper[1])

> In many graphics applications, a deterministic random hash provides the best source of random numbers.

So, why do people need cheap random numbers in graphics? Is that to create some sort of fuzz/texture/visual effect? Or is it to implement stochastic animations? (I know nothing about graphics)

[1] http://jcgt.org/published/0009/03/02/


Graphics uses a lot of Monte-Carlo integration, for which you need (pseudo) random numbers. You want your random numbers to be fast to generate, and have completely uniform so as not to introduce bias in the result.




Consider applying for YC's Spring batch! Applications are open till Feb 11.

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: