Nekochan Net

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


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

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

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

r12k@300 8mb cache


r10k@250 4mb cache



regards
Joerg

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!


Octane / Dual Head

http://twitter.com/GeekTronixShop

I made some other test...



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

greets

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:

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:

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

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.

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

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.

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... maybe because my torrent machine is an old nasty pc...with linux

Smilies mr Sky, smilies 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:
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:

"But i use the MIPSPro 7.4.x compiler! What gives?"
Well, the library is still there:
... 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...

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


Octane / Dual Head

http://twitter.com/GeekTronixShop

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



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



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