![](/i/fill.gif) |
![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
John VanSickle <evi### [at] hotmail com> 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
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
In article <4083cb0b@news.povray.org> , Warp <war### [at] tag povray org> 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] trf de
Visit POV-Ray on the web: http://mac.povray.org
Post a reply to this message
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
ABX <abx### [at] abx art pl> 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
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
Warp wrote:
>
> John VanSickle <evi### [at] hotmail com> 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
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
John VanSickle <evi### [at] hotmail com> 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
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
"Warp" <war### [at] tag povray org> wrote in message news:4084717c@news.povray.org...
> John VanSickle <evi### [at] hotmail com> 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
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
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] matwei de
http://www.matwei.de
Post a reply to this message
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
> [...]
>
> 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
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
> > 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
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
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] matwei de
http://www.matwei.de
Post a reply to this message
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |