 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
This week I updated my kubuntu 22.04LTS to 24.04LTS, and as a result I had to
reconfigure and recompile povray3.8 beta2.
To my amazement I got this error when running the new executable:
Parse Error: Viewing angle has to be smaller than 180 degrees.
After some DuckDuckGoing I found this solution
https://github.com/POV-Ray/povray/issues/460
and after replacing all HUGE_VALs into HUGE_FINITY_VALs my povray was working
again.
Is anybody going to change this in the povray source code, so that there will be
a new version with this patch?
More general, is there anybody, since Christopher Lipka left, still maintaining
povray?
What is the future of povray?
Is there a future for povray, or is 3.8 beta2 the last official version?
Cheers
Ton.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 6/21/24 22:44, Ton wrote:
> This week I updated my kubuntu 22.04LTS to 24.04LTS, and as a result I had to
> reconfigure and recompile povray3.8 beta2.
>
> To my amazement I got this error when running the new executable:
> Parse Error: Viewing angle has to be smaller than 180 degrees.
>
> After some DuckDuckGoing I found this solution
> https://github.com/POV-Ray/povray/issues/460
> and after replacing all HUGE_VALs into HUGE_FINITY_VALs my povray was working
> again.
If the user posting in that issue was correct about g++13 turning on the
-fno-finite-math-only along with -ffast-math by default and it being the
cause of the problem, the safest thing to do is to configure with
-fno-fast-math (*) or use -fno-finite-math-only as suggested. (I cannot
reproduce the problem by turning finite-math-only on with my g++11.4
compiler...)
(*) - Many official linux distribution packages of POV-Ray run without
the fast-math flag, only O2 optimizations and some other stricter
compiler flags too. They play it safer with distributed software packages.
---
The wrong thing to do is use the suggested patch posted to that github
issue! It creates a new macro definition in source/core/configcore.h
called HUGE_FINITE_VAL which replaces the lines:
#ifndef HUGE_VAL
#define HUGE_VAL 1.0e+17
#endif
with
#define HUGE_FINITE_VAL 1.0e+17
But, HUGE_VAL is always defined - for 25 years or more - in math.h /
cmath.h and not by that POV-Ray header file. In other words, we've not
been using that 1e17 value for eons - and the suggested patch brings
back that old value...
A real fix needs to look at and understand the cause and the code
implications in detail, everywhere HUGE_VAL* is used today(**). I know
we use +-inf, which are valid float/double values, to control code flow
in more than the one reported problem case.
(**) - The POV-Ray source uses std::numeric_limits too in places - which
has an inifinity() option. I bet those might be a problem too, if used.
The right fix for the camera code with the hard parse time fail is
likely to use std::numeric_limits<double>::max() over HUGE_VAL.
If finite-math-only is on in g++13 with fast-math by default (or due
whatever), I have to think we have more problems than the one, hard,
parse time camera error fail.
Aside: The linux distribution folks which opened the github issue have
backed up to g++12 for their distribution package.
---
I'm supporting my own playpen yuqk fork - and others too, theirs.
There is no official support as far as I know.
Bill P.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 6/22/24 01:35, William F Pokorny wrote:
> If the user posting in that issue was correct about g++13 turning on the
> -fno-finite-math-only along with -ffast-math by default and it being the
> cause of the problem, the safest thing to do is to configure with -fno-
> fast-math (*) or use -fno-finite-math-only as suggested. (I cannot
> reproduce the problem by turning finite-math-only on with my g++11.4
> compiler...)
Update.
I upgraded from Ubuntu 22.04 to Ubuntu 24.04 over the weekend. The
default g++ compiler is now 13.2.0 and builds do need to use the
-fno-finite-math-only flag when using -ffast-math (*) with g++13 builds.
Rather than the camera issue, with yuqk, I see the 'bounding not working
issue' issue reported in some fora here during the past year.
I expect given the different code bases, what will be seen as problems
with g++13 builds will be varied. This includes introducing problems
which might not be immediately apparent - the camera issues shows up
more or less by chance for example, because of a test not really in play
when it fails...
(I've not gotten around to re-building my collection of official releases.)
Bill P.
(*) - The default linux/unix builds with official releases use
-ffast-math. The yuqk fork as shipped does not assume any compiler
flags, but it does recommend -ffast-math with performance builds
suggested in INSTALL.txt. (**)
(**) - I've only lightly read up on the current g++13 --fast-math
issues. However, it looks like gcc/g++ 13 plans to eventually back out
the library changes creating the POV-Ray g++13 build exposures.
Practically though, I think it best to always use -fno-finite-math-only
when using -ffast-math with g++13 given we might not 'see' all the
possible problems.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"Ton" <ton### [at] gmail com> wrote:
> This week I updated my kubuntu 22.04LTS to 24.04LTS, and as a result I had to
> reconfigure and recompile povray3.8 beta2.
>
> To my amazement I got this error when running the new executable:
> Parse Error: Viewing angle has to be smaller than 180 degrees.
>
> After some DuckDuckGoing I found this solution
> https://github.com/POV-Ray/povray/issues/460
> and after replacing all HUGE_VALs into HUGE_FINITY_VALs my povray was working
> again.
>
> Is anybody going to change this in the povray source code, so that there will be
> a new version with this patch?
> More general, is there anybody, since Christopher Lipka left, still maintaining
> povray?
> What is the future of povray?
> Is there a future for povray, or is 3.8 beta2 the last official version?
>
> Cheers
> Ton.
Hi, I tested the patch too, and it worked for me on every machine I tried it on:
an Intel based Mac OS Big Sur, Windows 10, and Ubuntu 24.04. Did anyone see any
objection to the "Fedore40" patch provided in this post:
https://github.com/POV-Ray/povray/issues/460#issuecomment-2151339517 ?
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
William F Pokorny <ano### [at] anonymousorg> wrote:
> On 6/22/24 01:35, William F Pokorny wrote:
> > If the user posting in that issue was correct about g++13 turning on the
> > -fno-finite-math-only along with -ffast-math by default and it being the
> > cause of the problem, the safest thing to do is to configure with -fno-
> > fast-math (*) or use -fno-finite-math-only as suggested. (I cannot
> > reproduce the problem by turning finite-math-only on with my g++11.4
> > compiler...)
>
> Update.
>
> I upgraded from Ubuntu 22.04 to Ubuntu 24.04 over the weekend. The
> default g++ compiler is now 13.2.0 and builds do need to use the
> -fno-finite-math-only flag when using -ffast-math (*) with g++13 builds.
>
> Rather than the camera issue, with yuqk, I see the 'bounding not working
> issue' issue reported in some fora here during the past year.
>
> I expect given the different code bases, what will be seen as problems
> with g++13 builds will be varied. This includes introducing problems
> which might not be immediately apparent - the camera issues shows up
> more or less by chance for example, because of a test not really in play
> when it fails...
>
> (I've not gotten around to re-building my collection of official releases.)
>
> Bill P.
>
> (*) - The default linux/unix builds with official releases use
> -ffast-math. The yuqk fork as shipped does not assume any compiler
> flags, but it does recommend -ffast-math with performance builds
> suggested in INSTALL.txt. (**)
>
> (**) - I've only lightly read up on the current g++13 --fast-math
> issues. However, it looks like gcc/g++ 13 plans to eventually back out
> the library changes creating the POV-Ray g++13 build exposures.
> Practically though, I think it best to always use -fno-finite-math-only
> when using -ffast-math with g++13 given we might not 'see' all the
> possible problems.
Sorry I reread the thread more carefully and saw there WAS objection, though I
did not understand it! it looks bad, but does your answer suggest another
workaround? something as easy to apply by the profane as such a patch?
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 6/1/25 05:11, Mr wrote:
> Sorry I reread the thread more carefully and saw there WAS objection, though I
> did not understand it! it looks bad, but does your answer suggest another
> workaround? something as easy to apply by the profane as such a patch?
Don't use -ffast-math.
If you do use -ffast-math, you must use -fno-finite-math-only.
---
I've not looked at source code fixes because I don't know how to easily
determine where the exposures in the code are due these g++13 changes!
Only some of which appeared to be backed in later compiler version last
I 'glanced', rather than completely. The partial retrenchment 'might'
explain some (or all) the different fail signatures seen.
Fixing the source code for this likely requires a very deep dive into
what all the g++13 compiler changes were, what's been backed out or not
etc... Then probably some custom source scanning code to highlight
exposures - if new compiler warnings haven't been introduced which do
this work for us.
The work is way down on my todo list because -fno-finite-math-only is
working for me.
Bill P.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
|
|
