|
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Am 26.10.2018 um 20:13 schrieb Kenneth:
> clipka <ano### [at] anonymousorg> wrote:
>> Am 26.10.2018 um 05:41 schrieb Anthony D. Baye:
>>> It seems to me that the engine used to throw an error when this happened...
>> ...
>>> Version 3.8.0-alpha.9606898.unofficial
>>
>> That's on Linux, I presume?
>>
>> POV-Ray does produce a warning if the second operand compares /equal to
>> zero/.
>> [etc]
>>
>
> For what it's worth, in POV-Ray for Windows v3.7.1 beta 9, I see the same
> results as Anthony's original image-- the misplaced orange dot and the missing
> hexagons at the top.
Maybe the value isn't even exactly negative zero - I do get a "Division
by zero" warning with all the POV-Ray for Windows binaries I've
currently within close reach whenever I try to divide by exact negative
zero.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"Anthony D. Baye" <Sha### [at] spamnomorehotmailcom> wrote:
> What it should look like.
>
> Regards,
>
> A.D.B.
Anthony,
If you use the x(tVal1) = UI1 + Ud*tVal1 , y(tVal2) = VI1 + Vd*tVal2 formulation
for the lines then (x(tVal1)-y(tVal2)).Ud = 0 and
(x(tVal1)-y(tVal2)).Vd = 0 give 2 equations for tVal1 and tVal2. These would
give the nearest points of the pair of lines in 3D or the intersection point of
lines in 2D.
In the following, the only division is by detM, which will only be zero if the
lines are parallel. This will therefore not tread on the +-0 problem POV Ray
seems to have.
Thanks,
JimT
#macro IPoint(UI1, UI2, VI1, VI2)
#local Ud = vnormalize(UI2 - UI1);
#local Vd = vnormalize(VI2 - VI1);
#local UddotVd = vdot(Ud,Vd);
#if(UddotVd = 1)
#local rX = 0; // Parallel lines so no soln or infinite solns
#local rY = 0;
#else
#local UV1 = UI1 - VI1;
#local b1 = vdot(-UV1,Ud);
#local b2 = vdot( UV1,Vd);
#local detM = 1 - UddotVd*UddotVd;
#local tVal = (b1 + UddotVd*b2)/detM;
#local Upt = UI1 + Ud*tVal;
#local rX = Upt.x;
#local rY = Upt.y;
#end
#local retval = <rX,rY, 0.0>;
retval
#end
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 10/26/18 2:02 AM, clipka wrote:
> - BUT -
>
> ...
>
> POV-Ray for Linux is usually compiled with `-ffast-math`.
> ...
> So if you want to be sure that you're not dividing by negative zero,
> either (a) explicitly test if the divisor is equal to zero in your scene
> code (this is reliable because POV-Ray's equality operator is
> implemented to use an error margin), or (b) re-compile POV-Ray without
> `-ffast-math`.
Most humbly, I would like to point out that the Debian POV-Ray 3.7.0.x
package does not use -ffast-math. So, "usually" might be a bit strong.
From debian/rules:
CXXFLAGS += -O3
# This is rumoured to give wrong results with zero-thickness boxes, so
# disabled
# CXXFLAGS += -ffast-math
and a compile line:
g++ -DHAVE_CONFIG_H -I. -I.. -I.. -I../source/backend -I../source/base
-I../source/frontend -I../unix -I../vfe -I../vfe/unix -I/usr/include/SDL
-D_GNU_SOURCE=1 -D_REENTRANT -I/usr/include/OpenEXR -Wdate-time
-D_FORTIFY_SOURCE=2 -pthread -I/usr/include -I/usr/include -pipe
-Wno-multichar -Wno-write-strings -fno-enforce-eh-specs
-Wno-non-template-friend -g -O2
-fdebug-prefix-map=/home/dick/povray/debian/povray-3.7.0.7=.
-fstack-protector-strong -Wformat -Werror=format-security -O3 -pthread
-c -o lightgrp.o lightgrp.cpp
--
dik
Rendered 1024 of 921600 pixels (0%)
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Am 02.11.2018 um 00:06 schrieb dick balaska:
> On 10/26/18 2:02 AM, clipka wrote:
>> - BUT -
>>
>> ...
>>
>> POV-Ray for Linux is usually compiled with `-ffast-math`.
>> ...
>> So if you want to be sure that you're not dividing by negative zero,
>> either (a) explicitly test if the divisor is equal to zero in your scene
>> code (this is reliable because POV-Ray's equality operator is
>> implemented to use an error margin), or (b) re-compile POV-Ray without
>> `-ffast-math`.
>
> Most humbly, I would like to point out that the Debian POV-Ray 3.7.0.x
> package does not use -ffast-math. So, "usually" might be a bit strong.
Given that "out of the box" from the official repository POV-Ray's Unix
build process defaults to `-ffast-math`, I stick with "usually" and call
Debian's package a - laudable - exception.
(Also, since distro packages are not compiled by each end user but only
by the package manager, technically my statement remains true either way ;))
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 11/1/18 7:06 PM, dick balaska wrote:
> On 10/26/18 2:02 AM, clipka wrote:
>
> Most humbly, I would like to point out that the Debian POV-Ray 3.7.0.x
> package does not use -ffast-math. So, "usually" might be a bit strong.
>
> From debian/rules:
> CXXFLAGS += -O3
>
> # This is rumoured to give wrong results with zero-thickness boxes, so
> # disabled
> # CXXFLAGS += -ffast-math
>
>
> and a compile line:
> g++ -DHAVE_CONFIG_H -I. -I.. -I.. -I../source/backend -I../source/base
> -I../source/frontend -I../unix -I../vfe -I../vfe/unix -I/usr/include/SDL
> -D_GNU_SOURCE=1 -D_REENTRANT -I/usr/include/OpenEXR -Wdate-time
> -D_FORTIFY_SOURCE=2 -pthread -I/usr/include -I/usr/include -pipe
> -Wno-multichar -Wno-write-strings -fno-enforce-eh-specs
> -Wno-non-template-friend -g -O2
> -fdebug-prefix-map=/home/dick/povray/debian/povray-3.7.0.7=.
> -fstack-protector-strong -Wformat -Werror=format-security -O3 -pthread
> -c -o lightgrp.o lightgrp.cpp
>
Interesting. I see too -fstack-protector-strong which off the top of my
head the default compile does not use. Oh, and there is no -march=native
so expect quite a few other optimizations not done. -D_FORTIFY_SOURCE=2
added too.
Suppose compile differences like these something to keep in mind when
someone reports a bug or performance concern where they might be using a
pre-compiled package with different defaults than POV-Ray 'publishes.'
Aside: I've never done comparisons with and without -ffast_math. Wonder
what the performance (result?) difference is...
Aside: Zero thickness boxes I'd think problematic in any case. Not
opaque, differing inside/outside textures etc. Perhaps to the point the
parser should complain on seeing such a box. Maybe something else
meant...
Bill P.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
William F Pokorny <ano### [at] anonymousorg> wrote:
>
> Aside: Zero thickness boxes I'd think problematic in any case. Not
> opaque, differing inside/outside textures etc. Perhaps to the point the
> parser should complain on seeing such a box. Maybe something else
> meant...
>
I use a fair amount of zero-thickness boxes-- for 'billboard' images and such
like-- and haven't encountered any problems so far. But not placed right up
against another object (re: coincident surface problems).
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 11/2/18 10:20 AM, William F Pokorny wrote:
>
> Interesting. I see too -fstack-protector-strong which off the top of my
> head the default compile does not use.
> Oh, and there is no -march=native
> so expect quite a few other optimizations not done. -D_FORTIFY_SOURCE=2
> added too.
-march=native is interesting. "Up to 60% performance increase" [1].
Well that's a hell of a thing if true. But, you have to know which
Intel arch you are compiling for. Skylake/Haswell/Cannonlake/etc are
all different.
If that is true, it's too bad there isn't a switch in packages based on
arch.
(This took me down a rabbit hole lamenting that debian/Ubuntu is stuck
on "Hey, it runs on any x64 hardware, even AMD".
Which made me think of Jr; "If I was still running Slackware, I'd have
built my own Intel Clear Linux kernel with clang" ;) )
[1]
https://www.phoronix.com/scan.php?page=news_item&px=GCC-8-march-native-Skylake
--
dik
Rendered 1024 of 921600 pixels (0%)
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
hi,
dick balaska <dic### [at] buckosoftcom> wrote:
> Which made me think of Jr; "If I was still running Slackware, I'd have
> built my own Intel Clear Linux kernel with clang" ;) )
but.. it /is/ 2018 and there's /no/ gui.. ;-)
regards, jr.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 11/1/18 7:06 PM, dick balaska wrote:
> On 10/26/18 2:02 AM, clipka wrote:
>> - BUT -
>>
>> ...
>>
>> POV-Ray for Linux is usually compiled with `-ffast-math`.
>> ...
>> So if you want to be sure that you're not dividing by negative zero,
>> either (a) explicitly test if the divisor is equal to zero in your scene
>> code (this is reliable because POV-Ray's equality operator is
>> implemented to use an error margin), or (b) re-compile POV-Ray without
>> `-ffast-math`.
>
> Most humbly, I would like to point out that the Debian POV-Ray 3.7.0.x
> package does not use -ffast-math. So, "usually" might be a bit strong.
i've been using various flavors of opensuse for over 10 years now and
have never had to do anything /special/ during build process. just
simply configure and make has always worked just fine for me...
fast-math, march and even boost have /never/ been an issue for me. i've
always thought that rolling your own is way better than using one of the
pre-built distributions... /not/ an expert just personal observations
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 11/3/18 4:36 AM, dick balaska wrote:
> On 11/2/18 10:20 AM, William F Pokorny wrote:
>
...
>
> -march=native is interesting. "Up to 60% performance increase" [1].
> Well that's a hell of a thing if true.
If your talking about not using say AVX2 and AVX512 instructions, the
performance can easily be 2-4x worse than best possible for some code.
> But, you have to know which
> Intel arch you are compiling for. Skylake/Haswell/Cannonlake/etc are
> all different.
>
Christoph earlier this year suggested to me I think about enabling
solver code optimized for different architectures as I work on solver
fixes/updates. I found the gcc/g++ compilers have a cool feature called
Function Multi-Versioning (FMV). The linux kernel has been using the
feature for a long while. In addition to letting you hard code
CPU-specific optimizations, it lets you optimize for a collection of
processors/features with a one line modification to code:
#define MAX 1000000
int a[256], b[256], c[256];
__attribute__((target_clones("avx2","arch=atom","default")))
void foo(){
int i,x;
for (x=0; x<MAX; x++){
for (i=0; i<256; i++){
a[i] = b[i] + c[i];
}
}
}
The compiler creates target versions of the function for each
architecture clone and at run time the best version (by some priority)
of a function gets used. For later gcc versions and 'gnu' dynamically
loaded code the resolution happens once during the load - the pointer to
the function gets fixed to the 'best' compiled version for the CPU's
feature set.
Unfortunately not yet gotten time to play with the feature. The FMV
compiler feature isn't standardized across compilers though others seem
to have something like it.
> If that is true, it's too bad there isn't a switch in packages based on
> arch.
> (This took me down a rabbit hole lamenting that debian/Ubuntu is stuck
> on "Hey, it runs on any x64 hardware, even AMD".
> Which made me think of Jr; "If I was still running Slackware, I'd have
> built my own Intel Clear Linux kernel with clang" ;) )
>
> [1]
> https://www.phoronix.com/scan.php?page=news_item&px=GCC-8-march-native-Skylake
>
Bill P.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |