7 ms·

Cycles does the same work regardless of whether it's running on the CPU or GPU. You can even run mixed where both the CPU and GPU do rendering. The amount of no

Cycles does the same work regardless of whether it's running on the CPU or GPU. You can even run mixed where both the CPU and GPU do rendering. The amount of noise has nothing to do with it running on the GPU or not, that's simply how path-tracing works...

wtracy 6y ago
I think the implication is that GPU rendering ends up using lower-precision floating point numbers than are available on modern CPUs, which leads to more rounding errors.
- gmueckl 6y ago
  No, CPU renderers also use IEEE single precision floats for performance. Unless you do something really absurd[0], single precision has more than enough range and resolution to not lead to any noticable inaccuracies in the result. [0] like trying to render an insect eye to scale while having everything shifted 1000km from the origin.
  - fxtentacle 6y ago
    While that is in general correct, most GPUs do not fully adhere to IEEE or they do not calculate at full resolution. It's a well-documented fact that the same floating point operations on a GPU will have less precision than on CPU, despite both using the same IEEE storage format. https://developer.nvidia.com/sites/default/files/akamai/cuda/files/NVIDIA-CUDA-Floating-Point.pdf https://developer.nvidia.com/sites/default/files/akamai/cuda...
    - dahart 6y ago
      That paper does not say what you claim it does, it is not showing that GPUs are computing at lower resolution, nor that CUDA is failing to adhere to the IEEE 754 standard. In at least two cases, it says the opposite of what you just claimed: FMA on the GPU was a way to achieve higher float precision than you could with CPU math, in 2011 when the paper was written. That is changing now with CPU adoption of fma, but that doesn't change the claims of the paper. The GPU's strict adherence to IEEE 754 is mentioned multiple times. "The same inputs will give the same results for individual IEEE 754 operations to a given precision on the CPU and GPU. As we have explained, there are many reasons why the same sequence of operations may not be performed on the CPU and GPU. The GPU has fused multiply-add while the CPU does not. Parallelizing algorithms may rearrange operations, yielding different numeric results. The CPU may be computing results in a precision higher than expected. Finally, many common mathematical functions are not required by the IEEE 754 standard to be correctly rounded so should not be expected to yield identical results between implementations."
virtualritz 6y ago
Maybe you misunderstood me. I didn't peg the amount of noise to CPU vs. GPU rendering. I said that these renderers produce too much noise. All of them. And the solution is not denoising. The solutions are novel algorithms that produce faster convergence. There are other issues of course. Noise is just one. What I implied was that the developers would better spend their time fixing these than trying make stuff fit into a GPU. This[1] is a comparison of light sampling in 3Delight, Autodesk's Arnold and Pixar's RenderMan (RMan). TLDR; The bottom of the page has a 'Conclusion' section which is worth reading. The page is from around 2017 if my memory serves me right and was a private page requiring a password at the time. Pixar asked 3Delight to not make it public until RMan 21 was out. After which 3Delight re-ran the tests and RMan came out worse even. They never published the results because they do not care about publicity. Mind you, these were all pure CPU renderers at the time. Few people know about this. What everyone is exposed to is just the marketing mumbo jumbo on the vendors websites. As one can guess even skimming over this comparisons there are many things one must get right. E.g. speed of convergence. I.e.: what is the threshold of samples I can get away with? Some renderers converge linearly. An image with twice as much samples will have half the noise. But others manage to converge non-linear in a good or a bad way (twice the samples give you more than twice the quality or less than twice the quality). Another is bias: does the image look the same when it has fewer samples and you squint or is it darker/brighter than a reference that has 'infinite' samples? Very important for artists doing look development: time to first pixel. The graphs on the website have not changed much with recent versions of Arnold & RMan, unfortunately. Note that shaders wise 3Delight already used OSL (byte-code, run-time interpreted) whereas Arnold & RMan used C++ (at the time). Basically, what I tried to say was: if I was Pixar or Autodesk (insert any other renderer vendor here that came from CPU land) and saw this page (which Autodesk & Pixar did then) ... considering that the competition is running on the same metal, a CPU – maybe I'd try to get to the same level of speed/quality before putting a bunch of new problems on my plate that come when you strive for making this all work on a GPU. [1] https://www.3delight.com/documentation/display/3DSP/Geo+Light+Sampling+Algorithms+Comparison https://www.3delight.com/documentation/display/3DSP/Geo+Ligh...
- dahart 6y ago
  > And the solution is not denoising. The solutions are novel algorithms that produce faster convergence. IMO, there are a few things you seem to be confused about. 1- There are no perfect sampling algorithms, the need for denoising will never go away. 3Delight's geo light sampling does not remove the need for denoising. 2- Denoising and better sampling are independent. You can do both, and everyone already is doing both. 3- 3Delight's geo light sampling is a pretty narrow use-case way to compare renderers. Games don't generally use geo lights at all, and films only rarely. What 3delight doesn't show you in that web page is how their sphere, quad & point light sampling algorithms compare to Pixar's & Arnold's, which is what everyone uses in practice. Spoiler alert: it's not better. > Very important for artists doing look development: time to first pixel. Your 3delight page doesn't say whether they're using binary or ascii .rib files. (How do I know it's being fair?) It doesn't compare realistic production scenes. It doesn't compare texturing quality, or how well the renderers perform under extreme memory usage. You are being sucked into some marketing, and missing the bigger picture.

wtracy 6y ago

I think the implication is that GPU rendering ends up using lower-precision floating point numbers than are available on modern CPUs, which leads to more rounding errors.

gmueckl 6y ago
No, CPU renderers also use IEEE single precision floats for performance. Unless you do something really absurd[0], single precision has more than enough range and resolution to not lead to any noticable inaccuracies in the result. [0] like trying to render an insect eye to scale while having everything shifted 1000km from the origin.
- fxtentacle 6y ago
  While that is in general correct, most GPUs do not fully adhere to IEEE or they do not calculate at full resolution. It's a well-documented fact that the same floating point operations on a GPU will have less precision than on CPU, despite both using the same IEEE storage format. https://developer.nvidia.com/sites/default/files/akamai/cuda/files/NVIDIA-CUDA-Floating-Point.pdf https://developer.nvidia.com/sites/default/files/akamai/cuda...
  - dahart 6y ago
    That paper does not say what you claim it does, it is not showing that GPUs are computing at lower resolution, nor that CUDA is failing to adhere to the IEEE 754 standard. In at least two cases, it says the opposite of what you just claimed: FMA on the GPU was a way to achieve higher float precision than you could with CPU math, in 2011 when the paper was written. That is changing now with CPU adoption of fma, but that doesn't change the claims of the paper. The GPU's strict adherence to IEEE 754 is mentioned multiple times. "The same inputs will give the same results for individual IEEE 754 operations to a given precision on the CPU and GPU. As we have explained, there are many reasons why the same sequence of operations may not be performed on the CPU and GPU. The GPU has fused multiply-add while the CPU does not. Parallelizing algorithms may rearrange operations, yielding different numeric results. The CPU may be computing results in a precision higher than expected. Finally, many common mathematical functions are not required by the IEEE 754 standard to be correctly rounded so should not be expected to yield identical results between implementations."

virtualritz 6y ago

Maybe you misunderstood me. I didn't peg the amount of noise to CPU vs. GPU rendering. I said that these renderers produce too much noise. All of them. And the solution is not denoising. The solutions are novel algorithms that produce faster convergence. There are other issues of course. Noise is just one. What I implied was that the developers would better spend their time fixing these than trying make stuff fit into a GPU. This[1] is a comparison of light sampling in 3Delight, Autodesk's Arnold and Pixar's RenderMan (RMan). TLDR; The bottom of the page has a 'Conclusion' section which is worth reading. The page is from around 2017 if my memory serves me right and was a private page requiring a password at the time. Pixar asked 3Delight to not make it public until RMan 21 was out. After which 3Delight re-ran the tests and RMan came out worse even. They never published the results because they do not care about publicity. Mind you, these were all pure CPU renderers at the time. Few people know about this. What everyone is exposed to is just the marketing mumbo jumbo on the vendors websites. As one can guess even skimming over this comparisons there are many things one must get right. E.g. speed of convergence. I.e.: what is the threshold of samples I can get away with? Some renderers converge linearly. An image with twice as much samples will have half the noise. But others manage to converge non-linear in a good or a bad way (twice the samples give you more than twice the quality or less than twice the quality). Another is bias: does the image look the same when it has fewer samples and you squint or is it darker/brighter than a reference that has 'infinite' samples? Very important for artists doing look development: time to first pixel. The graphs on the website have not changed much with recent versions of Arnold & RMan, unfortunately. Note that shaders wise 3Delight already used OSL (byte-code, run-time interpreted) whereas Arnold & RMan used C++ (at the time). Basically, what I tried to say was: if I was Pixar or Autodesk (insert any other renderer vendor here that came from CPU land) and saw this page (which Autodesk & Pixar did then) ... considering that the competition is running on the same metal, a CPU – maybe I'd try to get to the same level of speed/quality before putting a bunch of new problems on my plate that come when you strive for making this all work on a GPU. [1] https://www.3delight.com/documentation/display/3DSP/Geo+Light+Sampling+Algorithms+Comparison https://www.3delight.com/documentation/display/3DSP/Geo+Ligh...

dahart 6y ago
> And the solution is not denoising. The solutions are novel algorithms that produce faster convergence. IMO, there are a few things you seem to be confused about. 1- There are no perfect sampling algorithms, the need for denoising will never go away. 3Delight's geo light sampling does not remove the need for denoising. 2- Denoising and better sampling are independent. You can do both, and everyone already is doing both. 3- 3Delight's geo light sampling is a pretty narrow use-case way to compare renderers. Games don't generally use geo lights at all, and films only rarely. What 3delight doesn't show you in that web page is how their sphere, quad & point light sampling algorithms compare to Pixar's & Arnold's, which is what everyone uses in practice. Spoiler alert: it's not better. > Very important for artists doing look development: time to first pixel. Your 3delight page doesn't say whether they're using binary or ascii .rib files. (How do I know it's being fair?) It doesn't compare realistic production scenes. It doesn't compare texturing quality, or how well the renderers perform under extreme memory usage. You are being sucked into some marketing, and missing the bigger picture.