POV-Ray : Newsgroups : povray.beta-test : v3.8 Clean up TODOs. kNoiseGen_Default switch use. : Re: v3.8 Clean up TODOs. kNoiseGen_Default switch use. Server Time
8 Dec 2021 07:56:17 EST (-0500)
  Re: v3.8 Clean up TODOs. kNoiseGen_Default switch use.  
From: clipka
Date: 29 May 2021 17:15:00
Message: <web.60b2ae15c40d1d79860b50e9afff112@news.povray.org>
William F Pokorny <ano### [at] anonymousorg> wrote:
> Documenting some cleanup which I think should happen on any resumption
> of v3.8 work. It's work I am doing in my cut down povr.
> In working on pattern / function handling changes (documented mostly in
> the non-web presented newsgroup povray.beta-test.binaries(1)) the
> following code caught my eye in the granite pattern:
>          switch (noise_generator)
>          {
>              case kNoiseGen_Default:  // <---- ????
>              case kNoiseGen_Original:
>                  temp = 0.5 - Noise (tv2, noise_generator);
>                  temp = fabs(temp);
>                  break;
>              default:
>                  temp = 1.0 - 2.0 * Noise (tv2, noise_generator);
>                  temp = fabs(temp);
>                  if (temp>0.5) temp=0.5;
>                  break;
>          }
> kNoiseGen_Default "Indicates that the scene's global settings noise
> generator should be used." It's not the local pattern noise default
> and should not be used as such. The coding is harmless to result, but
> not completely to performance - the case statement should be removed and
> also in wrinkles. Perhaps there are other such uses - turbulence??? Not
> looked.

I should note that the documentation of `kNoiseGen_Default` is probably not
authoritative. Judging by the comment style, it was probably added by me, and
I'm sure I did so to document my understanding of things at the time I added
them, which may have be flawed. (Of course, today I understand every jot of the

It is entirely possible that `kNoiseGen_Default` is used for multiple
independent things that use noise generators, and used in the documented sense
in some places, and in other senses elsewhere.

> The above issue got me looking more at the noise code and CPU specific
> optimizations. The AMD optimization file:
>        platform/x86/avxfma4/avxfma4noise.cpp
> is missing the #if CHECK_FUNCTIONAL test blocks comparing results to the
> non-optimized portable Noise and DNoise code which exists in the other
> optimization files. Looks like the check existed when Noise / DNoise was
> in texture.cpp - so this I think missed when the file above was created
> in the v3.8 / master branch.

To the best of my knowledge, the `CHECK_FUNCTIONAL` stuff is an artifact of the
approach Intel used on their end back in the days to make sure the optimized
code variants they provided for the AVX instruction sets were faithful to the
original unoptimized code, apparently testing the function "on the job" in a
living POV-Ray build, rather than in a dedicated testbed. when they later
adapted the code to optimize it for the AVX2/FMA3 instruction set, they seem to
have simply left it in there, or re-used it for the very same purpose. This is
also the reason why I never bothered to throw it out: Don't fuss with code that
some 3rd party provided for us, in case we ever want them to re-visit their

Their counterparts at AMD, who provided the AVX/FMA4 optimizations, presumably
started from the original non-optimized noise, and did not use the same approach
for testing, so they had no reason to leave the same kind of artifacts in there.

> Lastly, I'll ramble a little about what look to me to be less than clear
> statements in comments about mean, media and ranges which led me to take
> detailed looks at the distributions on my machine

Welcome to my world: POV-Ray is full of old code that has not been documented at
all, documented vaguely, imprecisely, sometimes wrong or no longer in sync with
the code, and where it is highly precise it tends to also be utterly
incomprehensible for anyone but an expert in the field. And more often than not
the corresponding code is written for maximum performance on antiquated
compilers that provided little in the way of automated optimizations, so the
code itself also tends to be highly unintelligible.

The earliest pieces of the POV-Ray source code are 30 years old now.

Post a reply to this message

Copyright 2003-2021 Persistence of Vision Raytracer Pty. Ltd.