yesbird wrote:
> ...
> Thanks, jr, for the fast reply, I will try it, but this solution looks
> like, a hack.

well, it is for WFP's "yuqk" fork :-).


> I'd prefer 'official' method to control usage of advanced
> CPU instructions, via config parameters.
> Don't you know, if it's possible ?

unsure even what you mean.  there are some bits of the source which are
"hand-optimised" for specific CPU types, but the detection & inclusion is
automatic.

either way, I've attached another "hack"[*] </grin>, a beta.2 build script.

[*] anyway, works.  </shrug>


regards, jr.

Post a reply to this message

Attachments:
Download 'povray.slackbuild.txt' (1 KB)

On 08/11/2025 12:32, jr wrote:
> unsure even what you mean.  there are some bits of the source which are
> "hand-optimised" for specific CPU types, but the detection & inclusion is
> automatic.
> 
> either way, I've attached another "hack"[*] </grin>, a beta.2 build script.
> 
> [*] anyway, works.  </shrug>


Unfortunately results is the same: "no result".
---------------------------------------------------------------------
./unix/povray +i./scenes/advanced/biscuit.pov -f +d +p +v +w320 +h240 
+a0.3 +L./include
make: *** [Makefile:1089: check] Illegal instruction (core dumped)
---------------------------------------------------------------------
YB

Post a reply to this message

On 11/8/25 02:55, yesbird wrote:
> On 08/11/2025 12:32, jr wrote:
>> unsure even what you mean.  there are some bits of the source which are
>> "hand-optimised" for specific CPU types, but the detection & inclusion is
>> automatic.
>>
>> either way, I've attached another "hack"[*] </grin>, a beta.2 build 
>> script.
>>
>> [*] anyway, works.  </shrug>
> 
> 
> Unfortunately results is the same: "no result".
> ---------------------------------------------------------------------
> ./unix/povray +i./scenes/advanced/biscuit.pov -f +d +p +v +w320 +h240 
> +a0.3 +L./include
> make: *** [Makefile:1089: check] Illegal instruction (core dumped)
> ---------------------------------------------------------------------
> YB
> 

There can be many causes for what you are seeing. Things you might try:

1) Download the latest yuqk tarball at:

https://news.povray.org/povray.binaries.programming/thread/%3C67eba626%40news.povray.org%3E/

Unpack it and run:

./configure -q COMPILED_BY="YB_yuqk" CXXFLAGS="-std=c++17"
make -j4
make check

The yuqk fork ships without any compiler optimizations during 
./configure - aside from the cpu specific noise code where it has fixed 
some 'gnu compiler broken' cpu detection code.

2) Both the default unix build and the build script jr provided use 
-ffast-math. There are a number of flaky fails due recent compiler 
changes to what -ffast-math does. Change that flag to: -fno-fast-math or 
add the flag -fno-finite-math-only to your CXXFLAGS and try another build.

3) You can try a configure with the defines:

-DDISABLE_OPTIMIZED_NOISE_AVXFMA4 -DDISABLE_OPTIMIZED_NOISE_AVX2FMA3 
-DISABLE_OPTIMIZED_NOISE_AVX

Which 'should' turn off any use of the cpu target specific hand 
optimized code - but they might not turn off the dynamic cpu detection 
code which runs ahead of the hand optimized code (I don't remember).

There is too a -DDISABLE_OPTIMIZED_NOISE_AVX_PORTABLE, but my memory is 
fuzzy as to what that means - probably harmless to add it to those above.

4) At a terminal after a illegal instruction problem build, are you able 
to run:

./unix/povray --help

If so, try each of:

touch bogus.pov; ./unix/povray bogus.pov -d +p

touch bogus.pov; ./unix/povray bogus.pov -d -p

touch bogus.pov; ./unix/povray bogus.pov -d +p -fn

Bill P.

Post a reply to this message

On 08/11/2025 14:59, William F Pokorny wrote:
> There can be many causes for what you are seeing. Things you might try:
> ... 

Many thanks for such a detailed response, I will put these tips to my
'internal storage' ).

The .configure option that helps was '-disable-optimiz'.
Probably I was too lazy to run:
./configure --help

and examine output, instead of disturbing the community, sorry for
inconvenience.
-- 
YB

Post a reply to this message

hi,

William F Pokorny <ano### [at] anonymousorg> wrote:
> ...
> 2) Both the default unix build and the build script jr provided use
> -ffast-math. There are a number of flaky fails due recent compiler
> changes to what -ffast-math does. Change that flag to: -fno-fast-math or
> add the flag -fno-finite-math-only to your CXXFLAGS and try another build.

thanks !


@yesbird
> The .configure option that helps was '-disable-optimiz'.

good that you found a work-around.


regards, jr.

Post a reply to this message

On 08/11/2025 16:58, jr wrote:
> good that you found a work-around.

Yes, I did with the help of the community, but don't you think that
it would be better to turn off this optimization by default to
preserve other users from similar issues in future ?
--
YB

Post a reply to this message

hi,

William F Pokorny <ano### [at] anonymousorg> wrote:
> ...
> 2) Both the default unix build and the build script jr provided use
> -ffast-math. There are a number of flaky fails due recent compiler
> changes to what -ffast-math does. Change that flag to: -fno-fast-math or
> add the flag -fno-finite-math-only to your CXXFLAGS and try another build.

in light of yesbird asking whether optimisation should be turned off perhaps, I
think it would be beneficial if (at least) the build flags for default *NIX were
appended / updated to include the '-fno-finite-math-only'.  can do ?


regards, jr.

Post a reply to this message

On 11/10/25 04:52, jr wrote:
> hi,
> 
> William F Pokorny <ano### [at] anonymousorg> wrote:
>> ...
>> 2) Both the default unix build and the build script jr provided use
>> -ffast-math. There are a number of flaky fails due recent compiler
>> changes to what -ffast-math does. Change that flag to: -fno-fast-math or
>> add the flag -fno-finite-math-only to your CXXFLAGS and try another build.
> 
> in light of yesbird asking whether optimisation should be turned off perhaps, I
> think it would be beneficial if (at least) the build flags for default *NIX were
> appended / updated to include the '-fno-finite-math-only'.  can do ?
> 

No(*), not easily.

---

It's true I did some github things a year or so ago to get bumped to a 
developer with the idea I might do a few quick commits like this, but my 
github upgrade from contributor to developer didn't go well. Best I 
could tell, I ended up with developer permission to one hidden / 
developer only fork / branch about which I know nothing.

None of the automated, github, build, check and release stuff is 
currently working. I never understood that set up beyond checking 
results of the auto-build-check fails. I have now not used github 
itself, except for occasionally commenting on issues posted there, for 
more than 5 years.

I cannot help with or support any windows specific development.

The suggested change should be made in at least 3 github branches. The 
github support infrastructure is really nice when it's all working - but 
even then, the simplest change takes non-trivial 'git / github' time.

---

My Unix/Linux only yuqk fork is different. The Unix build system itself 
is substantially different. I don't even have the --disable-optimiz 
configure option YB used(**) to build on his machine, for example.

---

Lastly, of late, real life is leaving me with much less time for my 
POV-Ray hobby :-(.

Bill P.


(*) - You're likely guessing correctly that YB's core issue comes down 
to the -ffast-math changes. The --disable-optimize option almost 
certainly turns off fast math.

(**) - Completely non-optimized POV-Ray builds are slow. (Though, it is 
a workaround for the gnu compiler optimizations breaking the dynamic cpu 
detection code issue (fixed in yuqk no matter the compiler optimization 
level))

Post a reply to this message

On 11/10/25 06:44, William F Pokorny wrote:
> It's true I did some github things a year or so ago to get bumped to a 
> developer with the idea I might do a few quick commits like this, but my 
> github upgrade from contributor to developer didn't go well. Best I 
> could tell, I ended up with developer permission to one hidden / 
> developer only fork / branch about which I know nothing.

I recently got an email from a friend on this subject. I want to make 
clear I am the one who has not pursued fixing the situation above.

It might be something I could fix myself with some time and focus. If 
not, others - like Chris - would certainly try and help me, but I don't 
want others burning time for something I'm currently unlikely to much 
use(*).

Aside:

Thinking about the patch, it's safer to remove the -ffast-math flag, I 
think. I'm unsure how pervasive the -fno-finite-math-only flag is... 
(clang ?)

Bill P.

(*) - Eventually, I plan to move 'yuqk' to github as I am already using 
git for it locally. At that change I'll be coming up to speed with 
github for yuqk - and sorting base POV-Ray github issues then, should be 
easier.

Post a reply to this message

On 14/11/2025 20:32, William F Pokorny wrote:

> (*) - Eventually, I plan to move 'yuqk' to github as I am already using 
> git for it locally. At that change I'll be coming up to speed with 
> github for yuqk - and sorting base POV-Ray github issues then, should be 
> easier.

Good luck with it - Github is a _very_ useful and now "must have"
service. I can suggest desktop version with excellent GUI:
https://desktop.github.com/download/

There is also a Linux fork, which I am using too, but you will need some
googling to find it.
--
YB

Post a reply to this message