14
$\begingroup$

I have a technical question, which maybe someone with a render engine coding background can answer:

Assume we give two PCs with fairly different hardware specs (e.g. one has a dedicated graphics card and the other not) the same blend file. The blend file is then rendered without denoising on both machines. Of course, they will take different times to finish the rendering. But after rendering, we look at the pixel data of both render results: Will it be 100% identical?

To be more precise: If we calculate a hash value (e.g. SHA256), will the result be identical for both images?

Improve this question
$\endgroup$
2
  • $\begingroup$ It's probably worth mentioning that in case of utilized path and ray tracing randomly distributed vectors are used. That's why the noise is usually different for rendering the same scene twice, unless you specify a fixed seed with some Python trickery. $\endgroup$
    – Num Lock
    May 9, 2022 at 8:19
  • $\begingroup$ Yeah, thanks for mentioning this. I was also thinking about the noise. But as I understood it, it works the other way around: It’s usually static but with randomizing the seed, you can change it. 🤔 $\endgroup$
    – reg.cs
    May 9, 2022 at 8:22

2 Answers 2

Reset to default
15
$\begingroup$

In a perfect world, with bug-free software and bug-free hardware, the hashes would be identical. In the real world, both hardware and software have bugs, and you're also coping with floating point differences between hardware implementations.

From the point of view of this retired hardware and software developer, they answer is "I wish, but not necessarily."

That said, the differences are usually very small.

Improve this answer
$\endgroup$
6
  • 2
    $\begingroup$ @reg.cs the IEEE specification has some room for interpretation and floating point hardware implementations are relatively difficult. If you switch CPU models you'll probably get different floating point implementations, so I would still say in theory they should but in practice they might not. $\endgroup$
    – Marty Fouts
    May 9, 2022 at 13:30
  • 1
    $\begingroup$ The problem here isn't bugs, it's that different orders of mathematically equivalent operations will produce different floating point results. This means that changing tile size will fundamentally produce (slightly) different renders. $\endgroup$
    – Oscar Smith
    May 9, 2022 at 19:16
  • 1
    $\begingroup$ @OscarSmith It's both, as well as ambiguity in IEEE 754. Even Intel still manages to introduce a new FP bug from time to time. $\endgroup$
    – Marty Fouts
    May 9, 2022 at 19:35
  • 1
    $\begingroup$ @MartyFouts, OscarSmith Thanks a lot for your insights! So, Think my question is answered and the result is that under most circumstances there will be minimal differences and I cannot expect hash of two renders to be the same due to floating point accuracy. $\endgroup$
    – reg.cs
    May 10, 2022 at 5:45
  • 1
    $\begingroup$ Also, when a job can be executed by multiple threads (the number of which depend on the CPU), the tiling and the stitching of tiles can affect the results at the tile boundaries. $\endgroup$
    – Diomidis Spinellis
    May 10, 2022 at 11:55
4
$\begingroup$

If you are rendering with the GPU, then definitely not, because floating point implementations will likely vary, especially with eevee. On the cpu, the differences should be much smaller, if not entirely nonexistent, as the only spec of floating point used (should) be IEEE.

Improve this answer
$\endgroup$
8
  • 2
    $\begingroup$ x86 trying to be IEEE compliant is slow, most people use "fast" math for compute intensive applications. $\endgroup$
    – Simon Richter
    May 9, 2022 at 13:13
  • 1
    $\begingroup$ @reg.cs Even within a single company's CPU line there will be variance in bugs. I don't think anyone can confirm that either CPUs or GPUs tend to be more bug free in floating point and I can't think of an argument that would justify claiming one or the other. Also, every standard has parts that different implementers will interpret differently. $\endgroup$
    – Marty Fouts
    May 9, 2022 at 13:34
  • 2
    $\begingroup$ Additionally, even GPU manufacturers tend not to directly reuse the floating point design from one generation of hardware to the next. That's because when you reduce feature size in silicon, the design rules change, and different rules lead to different optimization strategies. Of course, what they actually do is strictly kept secret as its seen as a competitive advantage, so it's difficult to tell the trends. $\endgroup$
    – Marty Fouts
    May 9, 2022 at 13:39
  • 1
    $\begingroup$ It may not just be GPU versus CPU. Even on CPU systems, some parallelization techniques can produce results that depend on CPU hardware timing. Parallelization that does exactly the same computations in exactly the same order should be consistent, but paralyzation that is adaptive, with multiple CPUs contributing different parts of objects to the same pixel will be timing dependent. I do not know if or how Blender parallelizes. $\endgroup$
    – Krazy Glew
    May 9, 2022 at 23:34
  • 1
    $\begingroup$ Furthermore, not even necessarily parallel versus non-parallel: instead of “fixed amount of work in whatever time it takes“, even some uniprocessor programs can do “as much quality as I can get in a fixed amount of time“ and similar time dependent computation. Again, I do not know if Glenn does this, but it is rather common in such programs to say “give me the best Rendar I can get overnight, but don’t take a week about it”. $\endgroup$
    – Krazy Glew
    May 9, 2022 at 23:38

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .