|
 |
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.
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.
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
(platform/x86/avx2fma3/avx2fma3noise.cpp). All three generators end up
with gaussian like distributions centered near 0.5 and in a 0-1 range as
expected.
The Perlin-Skinner distributions are a little asymmetric, but smoother
than the implemented Perlin version. All three have still visible
artifacts, though the current generator 2 default is the best in this
respect.
Aside: In the granite call I coded up a version which alternates between
Perlin and Perlin-Skinner(2) as it sums up the scaled, fractional noise
and to me looks really good artefact wise. Have others tried this?
Thinking I might keep it as a noise option in my cut down povr code.
We'll see.
Bill P.
(1) - Partial lie as images to this group show up in the 100 most recent
images group until no longer in the most recent 100. I started to use
the group so as not to present noise to most web interface users while
still storing what I see where other hackers / developers (and I) can
find stuff by news group search...
(2) - Granite introduces clamping as part of the pattern. (Something
never really optimized for Perlin(3) it looks. Perhaps the Skinner(2)
clamping good enough with Perlin too?)
Post a reply to this message
|
|
|
|
William F Pokorny <ano### [at] anonymous org> 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
code...)
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
code.
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
|
|
