Compiling YafRay V0.0.7 On MIPSPRO

3D/2D CGI and the tools used in their creation (Maya, Photoshop, Blender, GIMP, etc.).
Forum rules
Any posts concerning pirated software or offering to buy/sell/trade commercial software are subject to removal.
User avatar
lhaza
Posts: 186
Joined: Wed Apr 20, 2005 6:35 pm
Location: Milchstrasse, Kakania
Contact:

representative benchmark?

Unread postby lhaza » Sun Jul 03, 2005 11:32 pm

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

User avatar
Cory5412
Posts: 567
Joined: Fri Jan 16, 2004 6:08 pm
Location: Arizona
Contact:

Unread postby Cory5412 » Sun Jul 03, 2005 11:54 pm

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

User avatar
squeen
Moderator
Moderator
Posts: 2932
Joined: Fri May 09, 2003 6:10 am
Location: Maryland, USA

Unread postby squeen » Mon Jul 04, 2005 4:01 am

Where can I get big.xml, I'd like to run it on the Onyx350?

User avatar
dexter1
Moderator
Moderator
Posts: 2062
Joined: Thu Feb 20, 2003 6:57 am
Location: Voorburg, The Netherlands
Contact:

Unread postby dexter1 » Mon Jul 04, 2005 6:49 am

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

User avatar
joerg
Posts: 2223
Joined: Thu Jan 08, 2004 6:57 am
Location: In an origin rack - Germany
Contact:

Unread postby joerg » Mon Jul 04, 2005 8:24 am

r12k@300 8mb cache

Code: Select all

real    3m43.328s
user    3m42.527s
sys     0m0.169s


r10k@250 4mb cache

Code: Select all

real    4m53.950s
user    4m17.997s
sys     0m33.644s



regards
Joerg

User avatar
GeneratriX
Posts: 4238
Joined: Tue Oct 21, 2003 2:07 am
Location: Rosario / Santa Fe / República Argentina

Crunchers!

Unread postby GeneratriX » Tue Jul 05, 2005 10:33 am

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! ;)

User avatar
lhaza
Posts: 186
Joined: Wed Apr 20, 2005 6:35 pm
Location: Milchstrasse, Kakania
Contact:

added numbers

Unread postby lhaza » Mon Jul 11, 2005 6:49 pm

I made some other test...

Code: Select all

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

User avatar
dexter1
Moderator
Moderator
Posts: 2062
Joined: Thu Feb 20, 2003 6:57 am
Location: Voorburg, The Netherlands
Contact:

Unread postby dexter1 » Tue Jul 12, 2005 2:56 am

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: Select all

-       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: Select all

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

User avatar
nekonoko
Site Admin
Site Admin
Posts: 8041
Joined: Thu Jan 23, 2003 1:31 am
Location: Pleasanton, California
Contact:

Unread postby nekonoko » Tue Jul 12, 2005 10:22 am

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.

User avatar
lhaza
Posts: 186
Joined: Wed Apr 20, 2005 6:35 pm
Location: Milchstrasse, Kakania
Contact:

red lights

Unread postby lhaza » Wed Jul 13, 2005 9:06 am

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:

User avatar
skywriter
Posts: 3104
Joined: Fri Mar 14, 2003 5:22 am
Location: living in a linux-blunderland
Contact:

Unread postby skywriter » Wed Jul 13, 2005 9:40 am

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.

User avatar
lhaza
Posts: 186
Joined: Wed Apr 20, 2005 6:35 pm
Location: Milchstrasse, Kakania
Contact:

Unread postby lhaza » Wed Jul 13, 2005 11:30 am

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

User avatar
dexter1
Moderator
Moderator
Posts: 2062
Joined: Thu Feb 20, 2003 6:57 am
Location: Voorburg, The Netherlands
Contact:

Unread postby dexter1 » Wed Jul 13, 2005 5:27 pm

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: Select all

#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:
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: Select all

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

User avatar
GeneratriX
Posts: 4238
Joined: Tue Oct 21, 2003 2:07 am
Location: Rosario / Santa Fe / República Argentina

YafRay

Unread postby GeneratriX » Wed Jul 13, 2005 6:48 pm

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

User avatar
squeen
Moderator
Moderator
Posts: 2932
Joined: Fri May 09, 2003 6:10 am
Location: Maryland, USA

Unread postby squeen » Thu Jul 14, 2005 4:35 am

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. :(


Return to “SGI: Computer Graphics”

Who is online

Users browsing this forum: No registered users and 1 guest