Hi all,

I'm trying to compile from the source tarball POV 3.5 on my UltraSparc 
Box under Solaris 8.
But I'm facing several problems I've shown here like "-mcpu=i586" craps 
in Makefile.
Can I find somewhere patches to make my compilation successfull ?

Thanks

Laurent

Post a reply to this message

destroyedlolo wrote:
> Hi all,
> 
> I'm trying to compile from the source tarball POV 3.5 on my UltraSparc 
> Box under Solaris 8.
> But I'm facing several problems I've shown here like "-mcpu=i586" craps 
> in Makefile.
> Can I find somewhere patches to make my compilation successfull ?


Arg, unfortunaly, I got the same problem on my SunServer 5 under NetBSD 
1.6 :-(

Lolo (no, I realy don't want to use Intel machine ;-D)

Post a reply to this message

Simply remove the offending compiler parameters from the makefiles
for now. (The next release will fix all these problems and will include
much smarter automatic configuration capabilities.)

-- 
#macro N(D)#if(D>99)cylinder{M()#local D=div(D,104);M().5,2pigment{rgb M()}}
N(D)#end#end#macro M()<mod(D,13)-6mod(div(D,13)8)-3,10>#end blob{
N(11117333955)N(4254934330)N(3900569407)N(7382340)N(3358)N(970)}//  - Warp -

Post a reply to this message

Warp wrote:
>   Simply remove the offending compiler parameters from the makefiles
> for now. (The next release will fix all these problems and will include
> much smarter automatic configuration capabilities.)

Ok, thanks for you help.
When do you espect the next release ?

Can someone give me the best setting for an UltraSparc machine and for 
my SparcServer 5 ?

Post a reply to this message

destroyedlolo <l_f### [at] yahoocom> wrote:
> When do you espect the next release ?

  When it's ready.

> Can someone give me the best setting for an UltraSparc machine and for 
> my SparcServer 5 ?

  If you are using Sun's CC compiler, just use "-fast". If you are using
gcc, use "-O3 -ffast-math" (according to my experiments, no other
optimization flags have any effect whatsoever; apparently they haven't
developed the Sparc version of gcc too much).
  CC gives about 5% faster binaries than gcc (but also larger).

-- 
plane{-x+y,-1pigment{bozo color_map{[0rgb x][1rgb x+y]}turbulence 1}}
sphere{0,2pigment{rgbt 1}interior{media{emission 1density{spherical
density_map{[0rgb 0][.5rgb<1,.5>][1rgb 1]}turbulence.9}}}scale
<1,1,3>hollow}text{ttf"timrom""Warp".1,0translate<-1,-.1,2>}//  - Warp -

Post a reply to this message

On Fri, 14 Nov 2003, Warp wrote:
>
>  If you are using Sun's CC compiler, just use "-fast". If you are using
>gcc, use "-O3 -ffast-math" (according to my experiments, no other
>optimization flags have any effect whatsoever; apparently they haven't
>developed the Sparc version of gcc too much).

If you are using the Sun One Studio 8 Compiler Collection then I assure you
that a simple -fast will not get you what you want.

>  CC gives about 5% faster binaries than gcc (but also larger).

Actually, depending on the scene file and the size of the output image you
will find that the binary produced by gcc will not work very well past a size
of about 10240x7680 pixels.  The 64-bit build of povray for the UltraSparc
works just fine at these sizes provided that you have the gigs of RAM needed.
I expect that the 64-bit build for Solaris 10 on the Opteron will be quite
fast.  Testing has begun on the Solaris 10 build 46 with dual Opteron servers
and I expect to be using a quad Opteron with Solaris this month.  I still use
PovRay for a lot of my benchmarking and number crunching and all I can tell
you is that they are really really fast.  The Linux kernel, on Red Hat 9 and
the same hardware, run well in 32-bit mode but can not address RAM past about
4Gb unless you tweak the kernel.  The 2.4.22 kernel ( see kernel.org ) will
allow the RAM addressing with a custom build but one needs to build a
monolithic kernel to get real speed.  Still, the Solaris 10 servers are faster
in head to head comparison.  Probably due to the mature kernel in Solaris.

[dclarke@appro dclarke]$ uname -a
Linux appro 2.4.22 #2 Sun Oct 19 00:58:28 EDT 2003 i686 i686 i386 GNU/Linux
[dclarke@appro dclarke]$ lsmod --version
lsmod version 2.4.25
[dclarke@appro dclarke]$ lsmod
Module                  Size  Used by    Not tainted


In any case, you can find well tuned builds of PovRay at www.blastwave.org

Dennis

Post a reply to this message

Dennis Clarke <dcl### [at] blastwaveorg> wrote:
> If you are using the Sun One Studio 8 Compiler Collection then I assure you
> that a simple -fast will not get you what you want.

  The "-fast" should be a flag which automatically turns on all the best
optimization flags for the current platform.
  It may be, of course, that it does not turn on certain optimization flags
which result in slightly non-standard code.

> Actually, depending on the scene file and the size of the output image you
> will find that the binary produced by gcc will not work very well past a size
> of about 10240x7680 pixels.

  What's this based on?
  I have no knowledge of POV-Ray taking more memory with larger images
(given that you are not using X preview) and I don't understand why it
wouldn't work with output images of any size.

>  The 64-bit build of povray for the UltraSparc
> works just fine at these sizes provided that you have the gigs of RAM needed.

  I don't see why the 32-bit build would have any problem with large images.
It's not like the image was stored in memory.

  The 64-bit binary can handle larger scenes and larger *input* images, but
with regular scenes I can't imagine why it would make any difference (except
that the 64-bit binary will be slightly slower than the equivalent 32-bit
binary).

  If you are using X preview, that's a different story, but that doesn't
really make sense for a final 10240x7680 render anyways. The preview window
is intended for fast test renders, not for ultra-large final renders.

  *If* POV-Ray takes more memory depending on the size of the output image,
that's more a symptom of a bug than a normal behaviour.

-- 
#macro N(D)#if(D>99)cylinder{M()#local D=div(D,104);M().5,2pigment{rgb M()}}
N(D)#end#end#macro M()<mod(D,13)-6mod(div(D,13)8)-3,10>#end blob{
N(11117333955)N(4254934330)N(3900569407)N(7382340)N(3358)N(970)}//  - Warp -

Post a reply to this message

Warp wrote:
> 
>>Actually, depending on the scene file and the size of the output image you
>>will find that the binary produced by gcc will not work very well past a size
>>of about 10240x7680 pixels.
> 
> 
>   What's this based on?
>   I have no knowledge of POV-Ray taking more memory with larger images
> (given that you are not using X preview) and I don't understand why it
> wouldn't work with output images of any size.

Actually it will take more memory for the line buffers but that is not 
significant in comparison to the rest.

Christoph

-- 
POV-Ray tutorials, include files, Sim-POV,
HCR-Edit and more: http://www.tu-bs.de/~y0013390/
Last updated 25 Oct. 2003 _____./\/^>_*_<^\/\.______

Post a reply to this message