 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Straight from the news item on povray.co.uk
'I was amazed! Those povray guys write really portable code. Unfortunately,
its not very fast :(. The Dreamcast uses an SH4 processor. The NetBSD dc
port is using an SH3 compiler. The SH4 is backwards compatible w/ the SH3,
so it works, but I would imagine the SH4 can do a lot more than the SH3. I
am pretty sure the SuperH SH4 processor in the DC is supposed to have some
fancy floating point stuff. Once we get a compiler for the SH4 we'll
probably get better results. Plus, gcc probably optimises code much better
for x86s, PowerPCs, etc, than the SH3.'
While we are awaiting the actual benchmark figures, I think it will be safe
to assume that its around the 3 hours mark for the standard skyvase.pov at
640x480.
--
Rick
Kitty5 WebDesign - http://Kitty5.com
Hi-Impact database driven web site design & e-commerce
TEL : +44 (01625) 266358 - FAX : +44 (01625) 611913 - ICQ : 15776037
POV-Ray News & Resources - http://Povray.co.uk
PGP Public Key
http://pgpkeys.mit.edu:11371/pks/lookup?op=get&search=0x231E1CEA
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"Rick [Kitty5]" wrote:
> While we are awaiting the actual benchmark figures, I think it will be safe
> to assume that its around the 3 hours mark for the standard skyvase.pov at
> 640x480.
3 HOURS !?! My old XT could do it in 3 hours!
--
Ken Tyler
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
> > While we are awaiting the actual benchmark figures, I think it will be safe
> > to assume that its around the 3 hours mark for the standard skyvase.pov at
> > 640x480.
>
> 3 HOURS !?! My old XT could do it in 3 hours!
Yep, but IIRC the SH4 is a RISC chip, and I've never seen POV running at
any great speed on a RISC chip (Caveat: My experience of POV on RISC
machines is limited to Acorn Archimedes systems which compared *Very*
poorly, even to my old 486DX2/66, and so may not apply to the SH4)
Bye for now,
Jamie.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
In article <MPG.1539782b51913029898ad@news.povray.org>,
jam### [at] ntlworld com (Jamie Davison) wrote:
> Yep, but IIRC the SH4 is a RISC chip, and I've never seen POV running at
> any great speed on a RISC chip (Caveat: My experience of POV on RISC
> machines is limited to Acorn Archimedes systems which compared *Very*
> poorly, even to my old 486DX2/66, and so may not apply to the SH4)
The PowerPC processors are RISC, and while they aren't the top
performers, they are far better than you implied. My 350MHz G3 rendered
skyvase.pov at 640*480, using adaptive antialiasing with a threshold of
0.3, in 1 minute 33 seconds.
The Dreamcast's processor runs at 200MHz, it should render skyvase.pov
in far less than 3 hours, even with an unoptimized compiler.
--
Christopher James Huff
Personal: chr### [at] maccom, http://homepage.mac.com/chrishuff/
TAG: chr### [at] tagpovrayorg, http://tag.povray.org/
<><
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
In article <chrishuff-88B0A4.17280307042001@news.povray.org> , Chris
Huff <chr### [at] maccom> wrote:
> The Dreamcast's processor runs at 200MHz, it should render skyvase.pov
> in far less than 3 hours, even with an unoptimized compiler.
Maybe (I do not know about the SH) the FPU only supports
single-precision floating point numbers in hardware? If the compiler is
then forced to generate code for it you would get such a slowdown...
Thorsten
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
In article <MPG.1539782b51913029898ad@news.povray.org> ,
jam### [at] ntlworldcom (Jamie Davison) wrote:
> Yep, but IIRC the SH4 is a RISC chip, and I've never seen POV running at
> any great speed on a RISC chip
Even if you have not seen it, this is simply an incorrect
generalisation!
> (Caveat: My experience of POV on RISC
> machines is limited to Acorn Archimedes systems which compared *Very*
Because it didn't have an FPU?
Thorsten
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
In article <3acf994e$1@news.povray.org>, "Thorsten Froehlich"
<tho### [at] trfde> wrote:
> Maybe (I do not know about the SH) the FPU only supports
> single-precision floating point numbers in hardware? If the compiler is
> then forced to generate code for it you would get such a slowdown...
I looked for specifications on it, and couldn't find any in-depth
information, but I did see a reference to a 64-bit floating point
unit...I interpreted that as a unit that handles 64-bit floats, though
it could be a vector unit handling 2 32-bit floats, or something similar.
If it does double-precision through software, that would slow it
down a lot...nothing to do with it being a RISC processor, though.
--
Christopher James Huff
Personal: chr### [at] maccom, http://homepage.mac.com/chrishuff/
TAG: chr### [at] tagpovrayorg, http://tag.povray.org/
<><
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
> Maybe (I do not know about the SH) the FPU only supports
> single-precision floating point numbers in hardware? If the compiler is
> then forced to generate code for it you would get such a slowdown...
don't forget that while a DC maybe able to handle very complex 3d geometry,
this is almost certainly handled by the gfx chipset to a certain degree, the
main cpu doesn't have to be (and probably isn't) up to much in terms of
actual computing power.
now if pov could figure out a way to use the geometry engines on 3d hardware
to do some floating point crunching :P
--
Rick
Kitty5 WebDesign - http://Kitty5.com
Hi-Impact database driven web site design & e-commerce
TEL : +44 (01625) 266358 - FAX : +44 (01625) 611913 - ICQ : 15776037
POV-Ray News & Resources - http://Povray.co.uk
PGP Public Key
http://pgpkeys.mit.edu:11371/pks/lookup?op=get&search=0x231E1CEA
--
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
In article <3acfbe85@news.povray.org>, "Rick [Kitty5]"
<ric### [at] kitty5com> wrote:
> now if pov could figure out a way to use the geometry engines on 3d
> hardware to do some floating point crunching :P
I doubt the geometry engines are any more capable at double-precision
calculations...and sending the information back and forth would probably
be even slower.
--
Christopher James Huff
Personal: chr### [at] maccom, http://homepage.mac.com/chrishuff/
TAG: chr### [at] tagpovrayorg, http://tag.povray.org/
<><
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
> 3 HOURS !?! My old XT could do it in 3 hours!
From what I can tell, the guy left it running at minimum priority because
that machine isn't just for rendering, but is also a webserver, and he
didn't want any slowdowns. So that benchmark is not accurate at all.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
