John VanSickle <evi### [at] hotmailcom> wrote:
> Now a processor that does 3d arithmetic directly would be very nice...

  Don't 3D accelerator cards do tons of that already?

-- 
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

In article <4083cb0b@news.povray.org> , Warp <war### [at] tagpovrayorg>  wrote:

>> Now a processor that does 3d arithmetic directly would be very nice...
>
>   Don't 3D accelerator cards do tons of that already?

But what use is single-precision floating-point math for ray-tracing ;-)

    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

ABX <abx### [at] abxartpl> wrote in news:qp27805463p54p28qbpsanb9v7jcjbmi6s@
4ax.com:

> http://www.winprog.org/tutorial/msvc.html

Thanks, I'll check it out.

Rich

Post a reply to this message

Warp wrote:
> 
> John VanSickle <evi### [at] hotmailcom> wrote:
> > Now a processor that does 3d arithmetic directly would be very
> > nice...
> 
>   Don't 3D accelerator cards do tons of that already?

Their job is to puke triangles onto the screen.  I want something a
ray-tracer can use.

Regards,
John

Post a reply to this message

John VanSickle <evi### [at] hotmailcom> wrote:
> Their job is to puke triangles onto the screen.  I want something a
> ray-tracer can use.

  They do much more than that. They have even their own mini-assembler
you can use to write shaders.

-- 
#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" <war### [at] tagpovrayorg> wrote in message news:4084717c@news.povray.org...
> John VanSickle <evi### [at] hotmailcom> wrote:
> > Their job is to puke triangles onto the screen.  I want something a
> > ray-tracer can use.
>
>   They do much more than that. They have even their own mini-assembler
> you can use to write shaders.

While it's not really relevent to this conversation the following may be of
interest:

  http://film.nvidia.com/page/gelato.html

-- Chris

Post a reply to this message

Christoph Hormann schrieb:
> Rich wrote:
> 
>> Has anyone tried to compile 3.5 with 64bit optimizations?  I have a 
>> new PC with an AMD64 3200+ cpu (running Windows XP64) and I'm dying to 
>> see what this thing can do in native 64bit mode.

> In general POV-Ray compiles on 64bit systems but it won't be faster (in 
> most cases even slower).  The main advantage would be to be able to 
> address more than 4GB of memory.

I couldn't believe this and did some testing with my own compilations of 
POVRay.

I compile POVRay on my new AMD64 Box running Suse 9.0 for AMD64. One 
time with -m32 (using 32Bit mode of the processor) and one with -m64 
(using 64Bit mode of the processor)

I have tested the different binarys with this

povray -d -q9 +w800 +h600 +b1000 +r3 +a0.300 +ft 
-i[povray-dir]/scenes/advanced/chess2.pov -L[povray-dir]/include

commandline. I used always the -msse2 option to enable the sse2 Unit in 
the processor. So here are the results:

GCC 3.3.1 with -m32 -mcpu=k8 -msse2
   3:26
GCC 3.3.1 with -m64 -mcpu=k8 -msse2
   2:59

GCC 3.4.0 with -m32 -mcpu=k8 -msse2
   3:08
GCC 3.4.0 with -m64 -mcpu=k8 -msse2
   2:47

I will also try to compile POVRay with the ICC 8.0 under Linux if I can 
bring the compiler to work.

-- 

mat### [at] matweide
http://www.matwei.de

Post a reply to this message

> [...]
> 
> GCC 3.3.1 with -m32 -mcpu=k8 -msse2
>   3:26
> GCC 3.3.1 with -m64 -mcpu=k8 -msse2
>   2:59
> 
> GCC 3.4.0 with -m32 -mcpu=k8 -msse2
>   3:08
> GCC 3.4.0 with -m64 -mcpu=k8 -msse2
>   2:47

That either confirms what Warp said, that the processor is less 
efficient for 32bit code by design, or - if these times are indeed 
accurate enough - that gcc AMD64 specific optimizations were subject to 
significant changes recently.  Also note that you should use -march=k8 

and not only -mcpu (which should be replaced by -mtune with gcc 3.4 anywa
y).

And you should better use the benchmark scene to test, it will give more 

accurate time comparisons.  Also it would be important to test with a 
somewhat larger scene (benchmark.pov is not very large either) how the 
effect of the higher memory requirements for 64bit pointers etc. 
influences performance.

Christoph

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

Post a reply to this message

> > In general POV-Ray compiles on 64bit systems but it won't be faster (in 
> > most cases even slower).  The main advantage would be to be able to 
> > address more than 4GB of memory.

> I couldn't believe this and did some testing with my own compilations of 
> POVRay.

  As noted in other articles of this thread, there's a slight confusion
of concepts here.

  64-bitness in itself does not bring any speed benefit to POV-Ray.
There's nothing special in having 64-bit pointers (and long integers,
which are not used almost anywhere in POV-Ray) which would bring
extra speed.
  However, making an AMD64-optimized binary can and most probably will
give speed benefits. However, this is not because AMD64 is a 64-bit
processor. It's because it has new features which the compiler can use
to make faster code and which the 32-bit processors don't have.

  In a 64-bit processor which has no extra speeding features compared
to its 32-bit equivalent (the UltraSparc being a good example of this)
you won't get any speed benefits from making a 64-bit binary.

-- 
#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 schrieb:


>> > In general POV-Ray compiles on 64bit systems but it won't be faster (in 
>> > most cases even slower).  The main advantage would be to be able to 
>> > address more than 4GB of memory.
> 
>> I couldn't believe this and did some testing with my own compilations of 
>> POVRay.
> 
>   As noted in other articles of this thread, there's a slight confusion
> of concepts here.
> 
>   64-bitness in itself does not bring any speed benefit to POV-Ray.
> There's nothing special in having 64-bit pointers (and long integers,
> which are not used almost anywhere in POV-Ray) which would bring
> extra speed.
>   However, making an AMD64-optimized binary can and most probably will
> give speed benefits. However, this is not because AMD64 is a 64-bit
> processor. It's because it has new features which the compiler can use
> to make faster code and which the 32-bit processors don't have.

And thats the point. A 64Bit-compile on an AMD64 box will increase the 
performance of POVRay. If this increase of performance is caused by the 
64-bitness or the increased number of (SSE) registers is meaningless. It 
_will_ be faster. Thats the point. And so a version of POVRay for 
WindowsXP 64Bit edition will bring advantages against a 32 Bit Version.

Tonight I am going to make some tests with different versions of POVRay 
and the official POVRay benchmark file and also with a file with a lots 
of spheres to test the influence of the memory interface.

-- 

mat### [at] matweide
http://www.matwei.de

Post a reply to this message