 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Has anyone tried to compile a version of pov which works as a Win32 console
application? I am trying to do so at the moment with the Unix source code,
but am running into problems with unix.c.
Also: Has anyone yet made PVMPov work with Windows? I know there is a
version of PVM for windows and suggestions that it is easy to do, but have
not seen any results yet. That is why I am trying to make the console app, I
figure the slaves dont need a GUI.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On Wed, 3 Nov 1999 01:50:10 -0800, Chris Jeppesen wrote:
>Has anyone tried to compile a version of pov which works as a Win32 console
>application? I am trying to do so at the moment with the Unix source code,
>but am running into problems with unix.c.
You can probably safely leave unix.c out of the mix. The other thing you'll
have to do is edit config.h to not have any Unix-specific stuff in it - it's
best to start with the "unix" target rather than the "svga" or "xwin" targets
in this pursuit, as it should already be fairly generic.
--
These are my opinions. I do NOT speak for the POV-Team.
The superpatch: http://www2.fwi.com/~parkerr/superpatch/
My other stuff: http://www2.fwi.com/~parkerr/traces.html
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Chris Jeppesen wrote:
>
> Has anyone tried to compile a version of pov which works as a Win32 console
> application? I am trying to do so at the moment with the Unix source code,
> but am running into problems with unix.c.
>
> Also: Has anyone yet made PVMPov work with Windows? I know there is a
> version of PVM for windows and suggestions that it is easy to do, but have
> not seen any results yet. That is why I am trying to make the console app, I
> figure the slaves dont need a GUI.
I do not want to burst your bubble, but: within the last 8 months I got
about 4 mails from different people, which told that they would do the
win32-port of PVMPOV. After all there wasn't anybody, successfully
porting PVMPOV to win32.
I'd look forward to your PVMPOV port to win32, Chris
- Jakob Flierl
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Yay! I got it to work! Except...
It doesnt read povray.ini
it doesnt use a "precision timer" (whatever that is)
it doesnt read environment vars
but at least it compiles and traces!
And I got rid of 607 warnings with a simple #define float double
Still trying with pvm.
Chris Jeppesen <chr### [at] digiquill com> wrote in message
news:3820055d@news.povray.org...
> Has anyone tried to compile a version of pov which works as a Win32
console
> application? I am trying to do so at the moment with the Unix source code,
> but am running into problems with unix.c.
>
> Also: Has anyone yet made PVMPov work with Windows? I know there is a
> version of PVM for windows and suggestions that it is easy to do, but have
> not seen any results yet. That is why I am trying to make the console app,
I
> figure the slaves dont need a GUI.
>
>
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
In article <3820f651@news.povray.org> , "Chris Jeppesen"
<chr### [at] digiquillcom> wrote:
> And I got rid of 607 warnings with a simple #define float double
I presume you are using Visual C? Just tell it to ignore the possible loss
of "data" warning. Basically the warning is nonsense (it is a _wanted_
lowering of _precision_) and by forcing float to be double you just make
rendering slower. If you dig in the online help you will find where the
option to manually deactivate single warnings is (I don't remember the
option right now, sorry).
Thorsten
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On Wed, 03 Nov 1999 22:09:22 -0600, Thorsten Froehlich wrote:
>In article <3820f651@news.povray.org> , "Chris Jeppesen"
><chr### [at] digiquillcom> wrote:
>
>> And I got rid of 607 warnings with a simple #define float double
>
>I presume you are using Visual C? Just tell it to ignore the possible loss
>of "data" warning.
To do this, add one or more of the lines below to the appropriate place
in config.h.
/* disable truncation warning */
#pragma warning(disable: 4305)
/* disable precision warning */
#pragma warning(disable: 4244)
/* disable signed/unsigned warning */
#pragma warning(disable: 4018)
--
These are my opinions. I do NOT speak for the POV-Team.
The superpatch: http://www2.fwi.com/~parkerr/superpatch/
My other stuff: http://www2.fwi.com/~parkerr/traces.html
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Ron Parker wrote:
> On Wed, 03 Nov 1999 22:09:22 -0600, Thorsten Froehlich wrote:
> >In article <3820f651@news.povray.org> , "Chris Jeppesen"
> ><chr### [at] digiquillcom> wrote:
> >
> >> And I got rid of 607 warnings with a simple #define float double
> >
> >I presume you are using Visual C? Just tell it to ignore the possible loss
> >of "data" warning.
>
> To do this, add one or more of the lines below to the appropriate place
> in config.h.
>
> /* disable truncation warning */
> #pragma warning(disable: 4305)
>
> /* disable precision warning */
> #pragma warning(disable: 4244)
>
> /* disable signed/unsigned warning */
> #pragma warning(disable: 4018)
>
Just note that this will hide the problem, but is not a really good solution
engineering-wise. Especially 4018.
But, there's not a simple fix, since most of those come up due to the use of
macros. It might take a lot of engineering effort to correct all those in a
manner that is cross-platform and also "correct". In POV_Ray, most of the
precision and truncation warnings are due to known conversions that are
desired, thus the warnings are less important (just remember that I said "most"
and not "all possible"). Of course, any new code writen will be nice and clean
and not have any of this, right? :-)
Go ahead and put on the band-aid, but remember that it is such.
--
"My new computer's got the clocks, it rocks
But it was obsolete before I opened the box" - W.A.Y.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On Thu, 04 Nov 1999 06:33:49 -0800, Jon A. Cruz wrote:
>Just note that this will hide the problem, but is not a really good solution
>engineering-wise. Especially 4018.
Oh, absolutely. And I don't actually disable any of them in my own
code, either, but fixing them is fairly impractical.
--
These are my opinions. I do NOT speak for the POV-Team.
The superpatch: http://www2.fwi.com/~parkerr/superpatch/
My other stuff: http://www2.fwi.com/~parkerr/traces.html
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Thorsten Froehlich wrote:
>
> In article <3820f651@news.povray.org> , "Chris Jeppesen"
> <chr### [at] digiquillcom> wrote:
>
> > And I got rid of 607 warnings with a simple #define float double
>
> and by forcing float to be double you just make rendering slower.
That's not true. By amazing coincidence, the FPU (at least for intel arch)
is the same size as a Visual C++ double. So if your code is using floats,
they have to be converted to doubles before stuffing in the FPU (and
converted back to float on the way out of the FPU). So you lose precision
and take a performance hit by using floats.
No comment on the #define float double solution though. ;)
It's also interesting that since the '486, FPU mul/div is faster than
integer mul/div.
--
_,--"
dik `-._ ________-_______ "----
_----'--'--------------------------------'--'----_
//_| | \ dic### [at] buckosoftcom / | |_\\
(_____|_|__= Guilford CT +1.203.458.0389 =__|_|_____)
_\_____=___ http://www.buckosoft.com ___=_____/_
\/-(o)-~~-(o)-~~-(o)-`------'-(o)-~~-(o)-~~-(o)-\/
Early Net Poetry:
Wustl, Wustl, ERR RIP MIT BOOT, BIND Wustl
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On Tue, 23 Nov 1999 13:34:36 -0500, Dick Balaska wrote:
>Thorsten Froehlich wrote:
>>
>> In article <3820f651@news.povray.org> , "Chris Jeppesen"
>> <chr### [at] digiquillcom> wrote:
>>
>> > And I got rid of 607 warnings with a simple #define float double
>>
>> and by forcing float to be double you just make rendering slower.
>
>That's not true. By amazing coincidence, the FPU (at least for intel arch)
>is the same size as a Visual C++ double. So if your code is using floats,
>they have to be converted to doubles before stuffing in the FPU (and
>converted back to float on the way out of the FPU).
Not really. FLD with a 32-bit real operand is 20 clocks, as opposed to the
64-bit version at 25 clocks. FST is 44 vs. 45 clocks. FMUL is 27-35 clocks
for a float, or 32-57 for a double. FDIV is 89 or 94. So floats are faster,
under ideal conditions, but not by any significant amount. (This data is for
the 386. Other processors vary, of course. Intel no longer seems to publish
this data, for the obvious reason that pipelining and other optimizations
make it useless.)
--
These are my opinions. I do NOT speak for the POV-Team.
The superpatch: http://www2.fwi.com/~parkerr/superpatch/
My other stuff: http://www2.fwi.com/~parkerr/traces.html
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
In article <383ADE3C.61F2BC9E@buckosoft.com> , Dick Balaska
<dic### [at] buckosoftcom> wrote:
> So if your code is using floats,
> they have to be converted to doubles before stuffing in the FPU (and
> converted back to float on the way out of the FPU). So you lose precision
> and take a performance hit by using floats.
That is wrong! There is no time for conversion required, as it is a trivial
to "cut off" the exponent (reduce it from 11 to 8 bit) and the significant
(reducing it from 52 to 23 bit) when loading/storing them.
As a matter of fact, internally all current processors store floating-point
numbers as if they were doubles (or whatever other most precise internal
format they support). When performing the calculation as single-precision,
the other bits are just not taken into account.
Thorsten
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Ron Parker wrote:
Comments a little bit from back top front:
>(This data is for
> the 386. Other processors vary, of course.
And as such it is of no value. Who has a 386?
I know something like FMUL taking (if the pipelines are full) arount
1/3 clock. Double floating points are indeed a lot faster than integers.
Markus
--
Der deutsche Schlager ist aus dem Klofenster gesprungen....
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Thorsten Froehlich wrote:
>
> In article <383ADE3C.61F2BC9E@buckosoft.com> , Dick Balaska
> <dic### [at] buckosoftcom> wrote:
>
> > So if your code is using floats,
> ...
>
> That is wrong! There is no time for conversion required, as it is a trivial
> to "cut off" the exponent (reduce it from 11 to 8 bit) and the significant
> (reducing it from 52 to 23 bit) when loading/storing them.
> As a matter of fact, internally all current processors store floating-point
> numbers as if they were doubles (or whatever other most precise internal
> format they support). When performing the calculation as single-precision,
> the other bits are just not taken into account.
It is a little more curious still. You can force an Intel FPU to work
in several precision modes (32, 64, 80). There are differences in the
total # of clocks from beginning to end based on how much data needs to
be pushed onto the FPU stack and the precision you run the FPU.
A secondary consideration is that with the tiny on chip cache of the
Intel chips, using larger data sizes (8 byte doubles) will cause misses
more often than using 4 byte singles. When this happens you get a huge
performance hit.
Understanding and programming around these types of things is very
important to games programmers and real time sim packages. It is also
quite platform dependent.
Xander
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On Wed, 24 Nov 1999 10:20:47 +0100, Markus Becker wrote:
>Ron Parker wrote:
>
>Comments a little bit from back top front:
>>(This data is for
>> the 386. Other processors vary, of course.
>
>And as such it is of no value. Who has a 386?
>
>I know something like FMUL taking (if the pipelines are full) arount
>1/3 clock. Double floating points are indeed a lot faster than integers.
But try getting any information on instruction timings from Intel these
days. I checked both the PII and PIII reference manuals and they've dropped
that sort of information.
--
These are my opinions. I do NOT speak for the POV-Team.
The superpatch: http://www2.fwi.com/~parkerr/superpatch/
My other stuff: http://www2.fwi.com/~parkerr/traces.html
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Markus Becker wrote:
>
.
.
.
> Markus
> --
> Der deutsche Schlager ist aus dem Klofenster gesprungen....
I just wonder when some nongerman will ask you about your sig
<bg>
Marc
--
Marc Schimmler
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
> Not really. FLD with a 32-bit real operand is 20 clocks, as opposed to
the
> 64-bit version at 25 clocks. FST is 44 vs. 45 clocks. FMUL is 27-35
clocks
> for a float, or 32-57 for a double. FDIV is 89 or 94. So floats are
faster,
> under ideal conditions, but not by any significant amount. (This data is
for
> the 386. Other processors vary, of course. Intel no longer seems to
publish
> this data, for the obvious reason that pipelining and other optimizations
> make it useless.)
But if you want to look anyway, I think Ralf Brown's Interrupt List
(http://www.pobox.com/~ralf) has the data.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Marc Schimmler wrote:
>
> I just wonder when some nongerman will ask you about your sig
I'm hoping for it. We had some good laughs already in our institute....
> <bg>
<veg>
BTW, this is not my courtesy, I found it on the last page of the
"SPIEGEL"
(Hohlspiegel), originally it was a headline in the "Zeit".
Markus
--
Der deutsche Schlager ist aus dem Klofenster gesprungen....
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Ron Parker wrote:
>
> But try getting any information on instruction timings from Intel these
> days. I checked both the PII and PIII reference manuals and they've dropped
> that sort of information.
You can download the developer pack from Intel (is it still free?) and
especially VTune, which will clear show you how much cycles your machine
instructions take and how the pipelines will be filled.
And you can alway try to time it for yourself.
Markus
--
Der deutsche Schlager ist aus dem Klofenster gesprungen....
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Markus Becker wrote:
>
> I'm hoping for it. We had some good laughs already in our institute....
>
> > <bg>
> <veg>
>
> BTW, this is not my courtesy, I found it on the last page of the
> "SPIEGEL"
> (Hohlspiegel), originally it was a headline in the "Zeit".
>
As subscribed reader of the SPIEGEL I certainly know that one! :-)
Now cm'on people ask! <vbg>
Marc
--
Marc Schimmler
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Marc Schimmler wrote:
> As subscribed reader of the SPIEGEL I certainly know that one! :-)
>
> Now cm'on people ask! <vbg>
Well ?
--
Ken Tyler - 1200+ Povray, Graphics, 3D Rendering, and Raytracing Links:
http://home.pacbell.net/tylereng/index.html http://www.povray.org/links/
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Ron Parker <ron### [at] povrayorg> wrote:
: Not really. FLD with a 32-bit real operand is 20 clocks, as opposed to the
: 64-bit version at 25 clocks. FST is 44 vs. 45 clocks. FMUL is 27-35 clocks
: for a float, or 32-57 for a double. FDIV is 89 or 94. So floats are faster,
: under ideal conditions, but not by any significant amount. (This data is for
: the 386. Other processors vary, of course. Intel no longer seems to publish
: this data, for the obvious reason that pipelining and other optimizations
: make it useless.)
As someone already said, this is not true anymore for pentium-class
processors.
In a plain pentium (if I remember right) the fld takes about 6 clocks
and fst about 3 (for both float and double) and fmul takes 1 clock (amazingly)
in most cases.
In a P-II it's even faster.
On the other hand, all values are internally converted to 80 bits floating
numbers by the FPU (this is usually the long double type in C compilers for
PC). However, it's not faster to use the long double type. Double is faster.
--
main(i,_){for(_?--i,main(i+2,"FhhQHFIJD|FQTITFN]zRFHhhTBFHhhTBFysdB"[i]
):5;i&&_>1;printf("%s",_-70?_&1?"[]":" ":(_=0,"\n")),_/=2);} /*- Warp -*/
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 24 Nov 1999 13:11:01 -0500, Nieminen Juha wrote:
>Ron Parker <ron### [at] povrayorg> wrote:
>: Not really. FLD with a 32-bit real operand is 20 clocks, as opposed to the
>: 64-bit version at 25 clocks. FST is 44 vs. 45 clocks. FMUL is 27-35 clocks
>: for a float, or 32-57 for a double. FDIV is 89 or 94. So floats are faster,
>: under ideal conditions, but not by any significant amount. (This data is for
>: the 386. Other processors vary, of course. Intel no longer seems to publish
>: this data, for the obvious reason that pipelining and other optimizations
>: make it useless.)
>
> As someone already said, this is not true anymore for pentium-class
>processors.
> In a plain pentium (if I remember right) the fld takes about 6 clocks
>and fst about 3 (for both float and double) and fmul takes 1 clock (amazingly)
>in most cases.
> In a P-II it's even faster.
Y'all seem to be missing the point. My point was that it is not true that
there is a conversion penalty for using 32-bit floats on Intel x86 processors,
and that that has been true since at least the 387. Whether later processors
made the difference smaller or nonexistent is irrelevant: even when there was a
penalty, it favored using floats over doubles rather than the other way around
as stated, and even then it was really small (5 clocks on a 33-MHz 387 is 150ns.
It takes millions of FLDs - even on a 387 - before that even comes close to
taking measurably more or less time.)
--
These are my opinions. I do NOT speak for the POV-Team.
The superpatch: http://www2.fwi.com/~parkerr/superpatch/
My other stuff: http://www2.fwi.com/~parkerr/traces.html
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
In article <383BD96F.47668841@mitre.org> , Alexander Enzmann
<xan### [at] mitreorg> wrote:
> It is a little more curious still. You can force an Intel FPU to work
> in several precision modes (32, 64, 80). There are differences in the
> total # of clocks from beginning to end based on how much data needs to
> be pushed onto the FPU stack and the precision you run the FPU.
Well, that is true up to the 486 (and maybe Pentium). As all current x86
processors translate instructions internally, there is bottleneck between
the FPU and its registers.
> A secondary consideration is that with the tiny on chip cache of the
> Intel chips, using larger data sizes (8 byte doubles) will cause misses
> more often than using 4 byte singles. When this happens you get a huge
> performance hit.
Yes, this will happen when using old code or compilers that don't support
proper alignment. Usually cache row sizes are 16 or 32 bytes and a processor
will always fetch a complete row anyway.
Of course you will see a performance hit if your data really takes up large
parts of the caches.
However, I have tried to define DBL as float on a Mac (PowerPC) and could
not find any significant speed increase for large scenes, for example Anton
Raves' Lego scene heli_3.pov takes 79 s with DBL as double and 76 s with DBL
as float (using radiosity and anti-aliasing). That makes only four percent
speed increase, other scenes I tried didn't even show that much at all.
So I guess POV-Ray does not suffer that much from "DBL size". Its memory
access bottlenecks are probably somewhere else.
> Understanding and programming around these types of things is very
> important to games programmers and real time sim packages. It is also
> quite platform dependent.
Yes, and then those four percent would matter!
Thorsten
____________________________________________________
Thorsten Froehlich, Duisburg, Germany
e-mail: tho### [at] trfde
Visit POV-Ray on the web: http://mac.povray.org
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Ken wrote:
>
> Marc Schimmler wrote:
>
> > As subscribed reader of the SPIEGEL I certainly know that one! :-)
> >
> > Now cm'on people ask! <vbg>
>
> Well ?
Hmm, well, not easy to translate, but I'll try. A little bit of
background.
German songs that go well in germany are called "Schlager", you could
translate it as "hit". One of our most beloved "Schlager"-singers,
called
Rex Gildo, commited suicide one of the last weeks. He jumped out of the
toilet window while some reporters where waiting in another room.
Literally it would mean: "The german hit has jumped out of the toilet
window".
You didn't laugh? I knew it!
Markus
--
Der deutsche Schlager ist aus dem Klofenster gesprungen....
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Markus Becker wrote:
> You didn't laugh? I knew it!
I guess I would have had to be there :)
--
Ken Tyler - 1200+ Povray, Graphics, 3D Rendering, and Raytracing Links:
http://home.pacbell.net/tylereng/index.html http://www.povray.org/links/
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
