3 ms·

Can you expand on this? I’d like to read more. Do you mean you’d like 40GB/core/second, or something else?

deleted 6y ago
[deleted]
magicalhippo 6y ago
Well I mean you might need quite a number of random numbers per second, in this case 32bit floats was what we used. Even fairly trivial scenes can require over 20 random floats per sample and more complex scenes over 100. And you want to actually use those random numbers for calculating reflections, intersections etc. In the renderer I worked on the PRNG typically took at most 10% of total CPU time. So assuming the above those 4GB/s would translate into less than 5k samples/sec, which would be considered quite slow. Just to refresh my memory I just ran a quick test with a fairly simple scene. There's 6 samples for the camera, at least 3 per path vertex up (depth 32) and another 2 per light (8 in this scene). There might be some more I'm forgetting but lets use that a lower bound. For this scene then that means 6 + 3 * 32 + 2 * 8 = 118 random numbers per sample. On a single core I got 14.04kS/s, so that works out to at least 1.6M random numbers per second. And this renderer was focusing more on physics and fidelity rather than speed. For animations and similar you'd need a renderer that's at least an order of magnitude faster than the one I worked on. For reading further you could try PBRT[1]. It's a great book but not free. Luckily enough though the free chapter is about sampling and reconstruction so you can get a feel from that what is needed. [1]: https://pbrt.org/ https://pbrt.org/
- fractionalhare 6y ago
  This is a great answer and very helpful, thank you.
- nightcracker 6y ago
  It is you that is off by several orders of magnitude. 4GB/sec is 10^9 random floats per sec, and using your 118 random numbers per sample that'd be 8.5 million samples/sec. In other words, it's not the RNG that's your bottleneck at all.
  - magicalhippo 6y ago
    Well that was certainly embarrassing. On the other hand I overlooked that in my test scene it samples the lights at every vertex, and I forgot it had textures which needs at least 2 coordinates per vertex. So it needs at least 10 * 32 * 2 = 960 random values for that. I also recall that we tried MT but found a quite noticeable impact on speed compared to what we had, and on the PGC performance page MT is listed in the tens of GB/s. Perhaps our implementation was considerably worse though, I can't recall us testing it alone like that. As I mentioned though, that renderer was more about physics and fidelity. Typical render times for even a preview would be a minute, for final single-frame stills tens of hours to several days on a single computer was common. For animations you don't have that kind of time, so you need a orders of magnitude more samples/sec.

deleted 6y ago

[deleted]

Well I mean you might need quite a number of random numbers per second, in this case 32bit floats was what we used. Even fairly trivial scenes can require over 20 random floats per sample and more complex scenes over 100. And you want to actually use those random numbers for calculating reflections, intersections etc. In the renderer I worked on the PRNG typically took at most 10% of total CPU time. So assuming the above those 4GB/s would translate into less than 5k samples/sec, which would be considered quite slow. Just to refresh my memory I just ran a quick test with a fairly simple scene. There's 6 samples for the camera, at least 3 per path vertex up (depth 32) and another 2 per light (8 in this scene). There might be some more I'm forgetting but lets use that a lower bound. For this scene then that means 6 + 3 * 32 + 2 * 8 = 118 random numbers per sample. On a single core I got 14.04kS/s, so that works out to at least 1.6M random numbers per second. And this renderer was focusing more on physics and fidelity rather than speed. For animations and similar you'd need a renderer that's at least an order of magnitude faster than the one I worked on. For reading further you could try PBRT[1]. It's a great book but not free. Luckily enough though the free chapter is about sampling and reconstruction so you can get a feel from that what is needed. [1]: https://pbrt.org/ https://pbrt.org/

fractionalhare 6y ago
This is a great answer and very helpful, thank you.
nightcracker 6y ago
It is you that is off by several orders of magnitude. 4GB/sec is 10^9 random floats per sec, and using your 118 random numbers per sample that'd be 8.5 million samples/sec. In other words, it's not the RNG that's your bottleneck at all.
- magicalhippo 6y ago
  Well that was certainly embarrassing. On the other hand I overlooked that in my test scene it samples the lights at every vertex, and I forgot it had textures which needs at least 2 coordinates per vertex. So it needs at least 10 * 32 * 2 = 960 random values for that. I also recall that we tried MT but found a quite noticeable impact on speed compared to what we had, and on the PGC performance page MT is listed in the tens of GB/s. Perhaps our implementation was considerably worse though, I can't recall us testing it alone like that. As I mentioned though, that renderer was more about physics and fidelity. Typical render times for even a preview would be a minute, for final single-frame stills tens of hours to several days on a single computer was common. For animations you don't have that kind of time, so you need a orders of magnitude more samples/sec.