Nekochan Net

Official Chat Channel: #nekochan // irc.nekochan.net
It is currently Fri Apr 18, 2014 3:16 pm

All times are UTC - 8 hours


Forum rules


Any posts concerning pirated software or offering to buy/sell/trade commercial software are subject to removal.



Post new topic Reply to topic  [ 45 posts ]  Go to page Previous  1, 2, 3  Next
Author Message
Unread postPosted: Sun Jul 03, 2005 10:32 pm 
Offline
User avatar

Joined: Wed Apr 20, 2005 5:35 pm
Posts: 186
Location: Milchstrasse, Kakania
I timed big.xml on an Octane2/R12k@400/2gig and on a Notebook(P IV, 3 GHZ, 512 meg)

The notebook runs yafray from debian stable, while the irixbox runs neko-yafray:

octane:
real 3m30.63s
user 2m56.788s
sys 0m0.221s

linuxbook:
real 4m35.402s
user 4m17.550s
sys 0m0.080s

:D
maybe the built on debian is not very optimized, but most user won't optimize their apps...still this is surprising...


Top
 Profile  
 
 Post subject:
Unread postPosted: Sun Jul 03, 2005 10:54 pm 
Offline
User avatar

Joined: Fri Jan 16, 2004 6:08 pm
Posts: 541
Location: Golden Valley/Kingman, Arizona
Whoa, I wonder if the extra memory of the Octane was part of that... It looks like the octane did those renders in about half of the time of the Linux 'Book.

_________________
I [heart] the Performer Town Demo


Top
 Profile  
 
 Post subject:
Unread postPosted: Mon Jul 04, 2005 3:01 am 
Offline
Moderator
Moderator
User avatar

Joined: Fri May 09, 2003 5:10 am
Posts: 2931
Location: Maryland, USA
Where can I get big.xml, I'd like to run it on the Onyx350?


Top
 Profile  
 
 Post subject:
Unread postPosted: Mon Jul 04, 2005 5:49 am 
Offline
Moderator
Moderator
User avatar

Joined: Thu Feb 20, 2003 6:57 am
Posts: 2062
Location: Voorburg, The Netherlands
squeen wrote:
Where can I get big.xml, I'd like to run it on the Onyx350?

It's mentioned in thread: viewtopic.php?t=1826&start=112

big.xml


Top
 Profile  
 
 Post subject:
Unread postPosted: Mon Jul 04, 2005 7:24 am 
Offline
User avatar

Joined: Thu Jan 08, 2004 6:57 am
Posts: 2223
Location: In an origin rack - Germany
r12k@300 8mb cache
Code:
real    3m43.328s
user    3m42.527s
sys     0m0.169s


r10k@250 4mb cache
Code:
real    4m53.950s
user    4m17.997s
sys     0m33.644s



regards
Joerg


Top
 Profile  
 
 Post subject: Crunchers!
Unread postPosted: Tue Jul 05, 2005 9:33 am 
Offline
User avatar

Joined: Tue Oct 21, 2003 1:07 am
Posts: 4226
Location: Rosario / Santa Fe / República Argentina
Wow!; nice benchamarking figures... I guess I must run the test on my O2/602MHz to have the whole picture about what different processors/platforms can do with Dexter's build of YafRay!

...Great to see that our monsters can crunch ray traces really fast! ;)

_________________
Oh!, let me write that!

https://www.facebook.com/GeekTronix
https://geekli.st/GeekTronixShop
https://www.rebelmouse.com/GeekTronixShop/
http://twitter.com/GeekTronixShop
http://www.youtube.com/GeekTronixStream


Top
 Profile  
 
 Post subject: added numbers
Unread postPosted: Mon Jul 11, 2005 5:49 pm 
Offline
User avatar

Joined: Wed Apr 20, 2005 5:35 pm
Posts: 186
Location: Milchstrasse, Kakania
I made some other test...

Code:
Octane2/R12k@400/2 MB Cache/2gig
real 3m30.63s
user 2m56.788s
sys 0m0.221s

r12k@300 8mb cache
real    3m43.328s
user    3m42.527s
sys     0m0.169s

linuxbook: PIV@3.02GHZ/512kb cache/512 Meg
real 4m35.402s
user 4m17.550s
sys 0m0.080s

r10k@250 4mb cache
real    4m53.950s
user    4m17.997s
sys     0m33.644s

O2/R10K@250/1 Mb Cache/448 Meg
real    7m27.680s
user   6m16.307
sys    0m39.668s

Linuxbook PIII@1.2GHZ/256Kb Cache/512 Meg
real    7m55.234s
user    7m52.440s
sys     0m0.060s



Numbers from R7k would be very interesting..and , of course, from the old king of floatingpoint, I2/r8k :D
And joerg, are the numbers from ... modded O2s? :roll:

greets


Top
 Profile  
 
 Post subject:
Unread postPosted: Tue Jul 12, 2005 1:56 am 
Offline
Moderator
Moderator
User avatar

Joined: Thu Feb 20, 2003 6:57 am
Posts: 2062
Location: Voorburg, The Netherlands
Don't get your hopes up too high :) The IRIX yafray binary has a shortcoming with Caustics, noticable by the missing red spot on the ground of big.xml, of which much of the render time depends on it.
Yesterday evening i found the bug in 0.0.7CVS and 0.0.8 (just out). Stupid me and my ideas of code cleanup.

In vector3d.h:
Code:
-       const int m = (1<<31)-1;
+       const int m = 0x7fff;

Somewhere between toilet visits and getting coffee my mind has dropped 4 nibbles. MIPSPro was barking on this (1<<31)-1 line like mad so i wrote it down as 0x7fff. D'OH! Ofcourse it should have been:
Code:
-       const int m = (1<<31)-1;
+       const int m = 0x7fffffff;

Running the code with 0x7fff, causes the random function to spew large numbers, not normalised between 0 and 1. This triggers overflowed vectors in the Caustics code, causing it to reject all rays for Caustics.

Needless to say, the binary runs a lot slower now, with the added caustic rays, but the image is now in par with the Linux one. The red spot is there.

I'll build a 0.0.8 yafray today and a new package should be in somewhere this week. I hope to compensate a little for the slower rendertime by attempting to profile the binary. Wish me luck :)


Top
 Profile  
 
 Post subject:
Unread postPosted: Tue Jul 12, 2005 9:22 am 
Offline
Site Admin
Site Admin
User avatar

Joined: Thu Jan 23, 2003 1:31 am
Posts: 7956
Location: Pleasanton, California
dexter1 wrote:
I'll build a 0.0.8 yafray today and a new package should be in somewhere this week. I hope to compensate a little for the slower rendertime by attempting to profile the binary. Wish me luck :)


Cool! Great work as always :) When you upload I'll announce it on the blog - it makes a very good companion to Blender.

_________________
Twitter: @neko_no_ko
IRIX Release 4.0.5 IP12 Version 06151813 System V
Copyright 1987-1992 Silicon Graphics, Inc.
All Rights Reserved.


Top
 Profile  
 
 Post subject: red lights
Unread postPosted: Wed Jul 13, 2005 8:06 am 
Offline
User avatar

Joined: Wed Apr 20, 2005 5:35 pm
Posts: 186
Location: Milchstrasse, Kakania
hm, actually I do not like the red spots in the rendering...maybe one should add a switch for adjusting this parameter, since it looks it tremendously stretches rendertime for an effect e.g I would not like in this rendering...a red spot in blue glass, c'mon it looks like an error :lol:


Top
 Profile  
 
 Post subject:
Unread postPosted: Wed Jul 13, 2005 8:40 am 
Offline
User avatar

Joined: Fri Mar 14, 2003 5:22 am
Posts: 3097
Location: living in a linux-blunderland
don't worry it'll be something completely different broken in the next release. upgrade!

alos bittorent is annoying. when you're done; please package up with something useful.


Top
 Profile  
 
 Post subject:
Unread postPosted: Wed Jul 13, 2005 10:30 am 
Offline
User avatar

Joined: Wed Apr 20, 2005 5:35 pm
Posts: 186
Location: Milchstrasse, Kakania
have you ever tried azureus on irix? since it is in java it should run easily, though I never tried...it runs even on 1.4, but slower... :roll: maybe because my torrent machine is an old nasty pc...with linux


Top
 Profile  
 
 Post subject:
Unread postPosted: Wed Jul 13, 2005 4:27 pm 
Offline
Moderator
Moderator
User avatar

Joined: Thu Feb 20, 2003 6:57 am
Posts: 2062
Location: Voorburg, The Netherlands
skywriter wrote:
don't worry it'll be something completely different broken in the next release. upgrade!

alos bittorent is annoying. when you're done; please package up with something useful.
Smilies mr Sky, smilies :o :) :D :shock: :? 8) :lol: Ah that Blender stuff can't be good for one's heart..

And the Yafray code is good, it's just my buttarsed brain that twisted and turned. Rest assured, i am working on bringing back full SGI+pthread support into Yafray. I found the offending bug in the SGI STL-library and i think i have a fix for it. For anybody who cares to know this, and have an cast-iron belly, read up:

Problem description
Consider this small program:
Code:
#include <iostream>
int main() { std::cout << 1 << std::endl;}
Unsurprisingly, it prints a '1' on stdout.
Compiled via 'CC -o pth pth.cpp -mips4 -n32 -LANG:std' this indeed gives the desired output.

However, if you need to have pthread support in your C++ STL-Library, you need the -D_PTHREADS flag. And now it gets ugly. Compile with 'CC -D_PTHREADS -o pth pth.cpp -mips4 -n32 -LANG:std' and run, and the program segfaults.

Solution
This is a long outstanding bug, since 2001, but the fix is much more obscure and few people know. This is the fix:
Quote:
Solution: C++ application compiled using STL, -D_PTHREADS generates segmentation fault or bus error
This bug has been fixed in the 7.3.1.3m compiler. To use the fix compile with the following options :

CC -LANG:std -D_PTHREADS filename.cpp -o filename -lCio_pthreads

"But i use the MIPSPro 7.4.x compiler! What gives?"
Well, the library is still there:
Code:
mech044 /usr3/everdij> versions long | grep Cio_pthreads
f 47975  7566 c++_dev.sw.lib          usr/lib32/libCio_pthreads.a
... as an archive.
So you need to link all code with that small static archive and presto! 'CC -D_PTHREADS -o pth pth.cpp -mips4 -n32 -LANG:std -lCio_pthreads' will give the correct output.

Phew, messy stuff. Anyway am rebuilding yafray with this feature, and hopefully it will behave much better when using two or more processors...


Top
 Profile  
 
 Post subject: YafRay
Unread postPosted: Wed Jul 13, 2005 5:48 pm 
Offline
User avatar

Joined: Tue Oct 21, 2003 1:07 am
Posts: 4226
Location: Rosario / Santa Fe / República Argentina
...nice work Mr. Dexter! ;)
I think the YafRay sourcecode is really good to be free, and worths the pain a lot, to have it working properly on IRIX. Specially for people having multi-processor boxes. Also, I've noticed on previous versions that the illumination behavior is a lot different than the Blender's render engine...

_________________
Oh!, let me write that!

https://www.facebook.com/GeekTronix
https://geekli.st/GeekTronixShop
https://www.rebelmouse.com/GeekTronixShop/
http://twitter.com/GeekTronixShop
http://www.youtube.com/GeekTronixStream


Top
 Profile  
 
 Post subject:
Unread postPosted: Thu Jul 14, 2005 3:35 am 
Offline
Moderator
Moderator
User avatar

Joined: Fri May 09, 2003 5:10 am
Posts: 2931
Location: Maryland, USA
Dex,

Are you saying the problem was suppoesed to be fixed in 7.4.x but was not? Or is it some sort of unintentional linking particular to the YafRay make? Just curious. And thanks for the hard work.

BTW, I really would like to run YafRay on the Onxy, but I need to learn it's basic commands. And (as usually) I'm behind on my projects. I'm porting some C++ code over to C for another little IRIX based effort (a user space driver for a National Instruments multifunction DAQ board). What a convoluted, intentionally obscured language! It's not just unframilarity on my part, I really can't stand the C++ design philosophy---my engineering mottos are more in line with

Antoine de Saint-Exupery wrote:
A designer knows he has achieved perfection not when there is nothing left to add, but when there is nothing left to take away.


C++ seems to have the opposite goal (intellectual masturbation and "black-box" product!). My C code version is much shorter and "at-a-glance" understandable as to what is really taking place. Here one last quote

Paul Graham wrote:
Historically, languages designed for other people to use have been bad: Cobol, PL/I, Pascal, Ada, C++. The good languages have been those that were designed for their own creators: C, Perl, Smalltalk, Lisp.


Sorry, didn't mean to rant. As you can guess, this has been on my mind a bit. Good gravy, I'm a dinosaur. :(


Top
 Profile  
 
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 45 posts ]  Go to page Previous  1, 2, 3  Next

All times are UTC - 8 hours


Who is online

Users browsing this forum: No registered users and 1 guest


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Search for:
Jump to:  
Powered by phpBB® Forum Software © phpBB Group