 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 5/6/24 11:56, jr wrote:
> yes, no object with value '100'. run with the scene as posted finds a max of
> '29882873856'.
Hi jr, The scene, as posted, was the original without the suggested
min() wrapper - which we expect to have a very large max gradient.
Would you be kind enough to run the following version of the function on
your machine to verify you too see a much, much lower gradient?
min(
(sq(sqrt(x*x + y*y) - 3) + z*z - 0.4 ) ,
(sq(sqrt((x - 4.5)*(x - 4.5) + z*z) - 3) + y*y - 0.4) ,
(sq(sqrt((x + 4.5)*(x + 4.5) + z*z) - 3) + y*y - 0.4) ,
(sq(sqrt((y + 4.5)*(y + 4.5) + z*z) - 3) + x*x - 0.4) ,
(sq(sqrt((y - 4.5)*(y - 4.5) + z*z) - 3) + x*x - 0.4) ,
(sq(sqrt(x*x + y*y) - 5) + z*z - 0.4 )
)
// Rather than the posted:
// (sq(sqrt(x*x + y*y) - 3) + z*z - 0.4 ) *
// (sq(sqrt((x - 4.5)*(x - 4.5) + z*z) - 3) + y*y - 0.4) *
// (sq(sqrt((x + 4.5)*(x + 4.5) + z*z) - 3) + y*y - 0.4) *
// (sq(sqrt((y + 4.5)*(y + 4.5) + z*z) - 3) + x*x - 0.4) *
// (sq(sqrt((y - 4.5)*(y - 4.5) + z*z) - 3) + x*x - 0.4) *
// (sq(sqrt(x*x + y*y) - 5) + z*z - 0.4 )
With the bounding sphere of radius 9 I'm seeing less than 10 on all
recent versions of official POV-Ray and yuqk I have in hand. I'd like to
know you too see the really low gradient too and not just a lower, but
still quite large max gradient with the min() wrap.
I've not tried a clang compile yet. Off to do that - in part because
I've not done a clang compile of yuqk in long while...
Bill P.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
hi,
William F Pokorny <ano### [at] anonymous org> wrote:
> ...
> Would you be kind enough to run the following version of the function on
> your machine to verify you too see a much, much lower gradient?
>
> min(
> (sq(sqrt(x*x + y*y) - 3) + z*z - 0.4 ) ,
> (sq(sqrt((x - 4.5)*(x - 4.5) + z*z) - 3) + y*y - 0.4) ,
> (sq(sqrt((x + 4.5)*(x + 4.5) + z*z) - 3) + y*y - 0.4) ,
> (sq(sqrt((y + 4.5)*(y + 4.5) + z*z) - 3) + x*x - 0.4) ,
> (sq(sqrt((y - 4.5)*(y - 4.5) + z*z) - 3) + x*x - 0.4) ,
> (sq(sqrt(x*x + y*y) - 5) + z*z - 0.4 )
> )
much faster render, much lower gradient. gave (again) value '100', the beta.2
now reports "maximum gradient found was 12.207, ...". nice.
cheers.
regards, jr.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"jr" <cre### [at] gmailcom> wrote:
> ...
> much faster render, much lower gradient. gave (again) value '100', the beta.2
> now reports "maximum gradient found was 12.207, ...". nice.
fwiw, ran same with alpha.9945627 (over breakfast :-)), and got same gradient /
result.
regards, jr.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 5/6/24 15:35, William F Pokorny wrote:
> I've not tried a clang compile yet. Off to do that - in part because
> I've not done a clang compile of yuqk in long while...
The clang results for max gradients with min() are also all <<20.
---
That said, I found the clang++ compile broken! :-( While coding up a few
of of the vm inbuilt functions I used code like:
constexpr double Cn = 4.0*std::exp(-0.5)/std::sqrt(2.0); // **
which works with gnu compilers c+11 and later, but does not in today's
mainstream c++ versions for clang++. I knew there were differences in
what basic functions could be used in constant expressions, but I
somehow fooled myself into thinking clang++ was OK with those two (they
are officially available in later c++ standards).
The fix is to hard code the resultant values from exp() and sqrt() and
the fixes will be in the next yuqk release (R15).
(**) - The why of this approach is, in part, related to the fact POV-Ray
today defines many macro constants with MORE than double precision
digits as well as others at double precision. What I suspect is that
this mixed precision constant habit is sometimes not numerically
optimal, but I've never found the time to prove / disprove the thought.
---
Once the clang compile issue was fixed, I happened to notice that so
long as the clang++ configuration was run with the flag
'-fgnuc-version=5' to set internally to clang++ __GNUC__, I got Intel's
hand coded noise optimization for my i3. I didn't expect this to happen,
though maybe it is the right result.
The (perhaps bogus) story I've been carrying around in my head is that
the gnu g++ compile used to do the same dynamic optimization, but for at
least a couple years now, it has not... It's one of the issues on my
infinite to-do list.
So, the dynamic optimization situation on my i3 is today confusing /
worrying? The clang++ compile has the dynamic optimization:
Dynamic optimizations:
CPU detected: Intel,SSE2,AVX,AVX2,FMA3
Noise generator: avx2fma3-intel (hand-optimized by Intel)
While the g++ compile has the dynamic optimization:
Dynamic optimizations:
CPU detected: Intel,FMA3,FMA4
Noise generator: generic (portable)
The latter is safe, but likely not optimal. The clang++ compile is
finding the correct features for my i3.
Add to this, that in my testing back when clipka first ported the AMD
and Intel hand optimizations to the Linux / Unix builds, the optimized
code was only sometimes (the benchmark scene being one) faster on my i3.
It sometimes tested slower than the generic (using -march=native) too.
Quickly on the biscuit.pov scene today, clang's dynamic optimization is
2.3% faster than a -march=native compile.
Aside: clang native is currently 4.2% faster the g++ native with
relatively basic optimization flags, but knowing learning why is always
a time consuming trick and which is faster tends to change over time.
Lastly, since I rendered different versions of output png files while
looking at performance, I did image comparisons. The clang++ native vs
avx2fma3-intel results matches exactly - as should be. The interesting
bit is the g++ native vs clang++ native mismatched by 1/255 on two
pixels. :-)
Anyhow...
Bill P.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 5/7/24 02:03, jr wrote:
> much faster render, much lower gradient. gave (again) value '100', the beta.2
> now reports "maximum gradient found was 12.207, ...". nice.
Thank you!
I got a clang++ compile going too (with issues...), but it's also
reporting the much lower gradient with the min() wrapper.
So, my best guess at the moment - given, kurtz le pirate, reported a
lower max gradient, but one still quite large, is that perhaps what
ended up coded on trying min() in his case was something like:
min(
(SQ(sqrt(x*x + y*y) - 3) + z*z - 0.4 ),
(SQ(sqrt((x - 4.5)*(x - 4.5) + z*z) - 3) + y*y - 0.4),
(SQ(sqrt((x + 4.5)*(x + 4.5) + z*z) - 3) + y*y - 0.4),
(SQ(sqrt((y + 4.5)*(y + 4.5) + z*z) - 3) + x*x - 0.4),
(SQ(sqrt((y - 4.5)*(y - 4.5) + z*z) - 3) + x*x - 0.4) *
(SQ(sqrt(x*x + y*y) - 5) + z*z - 0.4 )
)
It's just a guess but, I'm otherwise out of ideas as to other causes.
Bill P.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 5/7/24 07:18, William F Pokorny wrote:
> So, the dynamic optimization situation on my i3 is today confusing /
> worrying? The clang++ compile has the dynamic optimization:
>
> Dynamic optimizations:
> CPU detected: Intel,SSE2,AVX,AVX2,FMA3
> Noise generator: avx2fma3-intel (hand-optimized by Intel)
>
> While the g++ compile has the dynamic optimization:
>
> Dynamic optimizations:
> CPU detected: Intel,FMA3,FMA4
> Noise generator: generic (portable)
>
> The latter is safe, but likely not optimal. The clang++ compile is
> finding the correct features for my i3.
For the record.
Yesterday, I found LLVM Project code with comments and code for handling
gcc not accounting for 'cpuid' clobbering of one of the registers.
Though they don't protect the register in the same way, it explains
'some 'of the assembly code in our code base protecting the same
register. Still unsure if this issue really why my g++ compiles don't
use the same optimization as clang++'s.
Looking at what we have, I see all this code is now a bit dated and the
set up is limited in comparison. I'm unsure I want to invest my time in
it - thinking now about removing it all from yuqk as another general
simplification.
Bill P.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 06/05/2024 20:27, William F Pokorny wrote:
> On 5/6/24 10:27, kurtz le pirate wrote:
>> Lower (normal) value for max_gradient don't render object
>>
>> Last thing, my version :
>> Persistence of Vision(tm) Ray Tracer Version
>> 3.8.0-alpha.9945627.unofficial (
>> Compiler: 4.2.1 Compatible Apple LLVM 10.0.0 (clang-1000.11.45.5))
>>
>>
>> Might be buggy ?
>
> Thank you for the information and scene SDL. I'll let you know what I find.
Hello Bill,
Looking at the various answers, I don't think it's a compiler problem
any more. Your code and mine are identical and give the same results for
several people.
I don't think there's any point in you wasting any more time on this
problem unless you really care... For me, it was just a test to adapt
isosurfaces found in "MathMod" to POVRay
<https://sourceforge.net/projects/mathmod/>.
Thank you all for your participation.
--
Kurtz le pirate
Compagnie de la Banquise
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
kurtz le pirate <kur### [at] gmailcom> wrote:
> . . . to adapt
> isosurfaces found in "MathMod" to POVRay
> <https://sourceforge.net/projects/mathmod/>.
Nice - I've played with that before.
I emailed the guy who runs that to find out how he managed:
https://www.deviantart.com/mathmod/art/Straw-Torus-579426225
But I never did get an answer.
Do you understand how all the syntax works?
- BW
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 09/05/2024 12:39, Bald Eagle wrote:
> Nice - I've played with that before.
>
LOL
> I emailed the guy who runs that to find out how he managed:
> https://www.deviantart.com/mathmod/art/Straw-Torus-579426225
>
> But I never did get an answer.
>
Same...
It seems that a FaceBook group exists. I don't have an account, so I
don't know if it's still active : <https://www.facebook.com/parisolab/>
> Do you understand how all the syntax works?
Ho no, far from it.
Some syntaxes are really strange and without doc..
--
Kurtz le pirate
Compagnie de la Banquise
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 5/9/24 04:23, kurtz le pirate wrote:
> For me, it was just a test to adapt
> isosurfaces found in "MathMod" to POVRay
> <https://sourceforge.net/projects/mathmod/>
I've not run the application, but I too have spent time trying shapes
others have worked up for it. The f_toupie() inbuilt in my yuqk fork,
both in name and core code, comes from such play! :-)
---
As for chasing the original, "min() max gradient still too high" issue,
I've stopped.
In hindsight, the overall chase was worthwhile for yuqk fork issues of
my own doing. Plus, clang correctly implementing the dynamic CPU
optimization, gave me the means to dig into a longstanding, general
POV-Ray build issue too.
As "code bug hunts" go, this one yielded much. :-)
Bill P.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
|
|
