SGI: Computer Graphics

Compiling YafRay V0.0.7 On MIPSPRO - Page 3

lhaza
From Milchstrasse, Kakania
Who joined April 20, 2005, 6:35 p.m.
Wrote the following at July 11, 2005, 6:49 p.m...
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: [email protected]/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 [email protected]/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
dexter1
Moderator
From Voorburg, The Netherlands
Who joined Feb. 20, 2003, 6:57 a.m.
Wrote the following at July 12, 2005, 2:56 a.m...
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 :)
makkan77 avatar
makkan77
Who joined Nov. 28, 2003, 11:12 a.m.
and authored 168 notes
Wrote the following at July 12, 2005, 4:01 a.m...
If I recall correctly or IIRC as I've just recently learned there is a open source ansi editor similar to AcidDraw that is called DuhDraw .

I too would also be interested in having duhdraw compiled for irix. I would also like to recommend you Ansi lovers out there to check out this nifty little frontend to various music players.

Camp

// Markus

_________________
Behold my spermlogo, for it is I: Quick, Ambitious, creative and a tad bit sexually oriented.
----------------
[SGI Indigo2 R10K | High Impact | Indigo2 Video for IMPACT with indycam | Irix 6.5.22m]
voidfoo avatar
voidfoo
Who joined May 17, 2003, 1:01 p.m.
and authored 473 notes
Wrote the following at July 12, 2005, 9:13 a.m...
i had the luck to compile a gcc mips-3 duhdraw . mipspro version always segment fault.

http://s92957900.onlinehome.us/packages/duhdraw.tar.gz

Edit. requires neko_ncurses.
nekonoko
Site Admin
From Pleasanton, California
Who joined Jan. 23, 2003, 1:31 a.m.
Wrote the following at July 12, 2005, 10:22 a.m...
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.
miunk avatar
miunk
Who joined Feb. 8, 2004, 4:17 p.m.
and authored 346 notes
Wrote the following at July 12, 2005, 12:34 p.m...
How did you do it? I kept getting:

Code:
rm -f duhdraw
gcc -O2 -s -Wall -L/usr/miunkware/lib -o duhdraw duhdraw.c -lncurses
ld32: Segmentation Fault.  Removing output file...


This is with ncurses 5.4 - which I compiled /w gcc - perhaps my ncurses libs are no good?
nekonoko avatar
nekonoko
Site Admin
Who joined Jan. 23, 2003, 1:31 a.m.
and authored 7947 notes
Wrote the following at July 12, 2005, 12:41 p.m...
miunk wrote:
This is with ncurses 5.4 - which I compiled /w gcc - perhaps my ncurses libs are no good?


I've haven't tried compiling this so my observation is just academic - but is there a reason you have to use ncurses? Most things will let you link against the system curses library instead ( -lcurses ).

_________________
Twitter: @neko_no_ko
IRIX Release 4.0.5 IP12 Version 06151813 System V
Copyright 1987-1992 Silicon Graphics, Inc.
All Rights Reserved.
voidfoo avatar
voidfoo
Who joined May 17, 2003, 1:01 p.m.
and authored 473 notes
Wrote the following at July 12, 2005, 1:22 p.m...
yes, i can confirm it works with -lcurses.

to use ncurses, i made some modifications to the Makefile (added -I and -L for nekoware ncurses) and changed #include <ncurses.h> to #include <ncurses/ncurses.h>. You can check the differences by comparing the source in my tarball with the original source.
miunk avatar
miunk
Who joined Feb. 8, 2004, 4:17 p.m.
and authored 346 notes
Wrote the following at July 12, 2005, 2:14 p.m...
Really how about with -lcurses? What does your makefile look like? I am getting another segfault. How can I debug ld32 segfaults?
incognito avatar
incognito
Who joined Aug. 29, 2004, 6:13 p.m.
and authored 97 notes
Wrote the following at July 12, 2005, 2:31 p.m...
thanks for the bin this should be a fun app to use
voidfoo avatar
voidfoo
Who joined May 17, 2003, 1:01 p.m.
and authored 473 notes
Wrote the following at July 12, 2005, 2:38 p.m...
miunk, maybe you are right. duhdraw segfaults with -lcurses. just the viewer ansi works fine with -lcurses.

the beginning of my Makefile to use ncurses looks like this
Code:
CC=gcc -O2 -I/usr/nekoware/include
STRIP=strip
LIBS= -L/usr/nekoware/lib -lncurses

I also changed #include <ncurses.h> to <ncurses/ncurses.h>, as mentioned above.
miunk avatar
miunk
Who joined Feb. 8, 2004, 4:17 p.m.
and authored 346 notes
Wrote the following at July 12, 2005, 9:49 p.m...
Thanks - adding the ncurses/ncurses.h was the key. I can run the program but the "splash screen" displays all jumbled - do I need to configure my winterm?
lhaza
From Milchstrasse, Kakania
Who joined April 20, 2005, 6:35 p.m.
Wrote the following at July 13, 2005, 9:06 a.m...
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:
skywriter
From living in a linux-blunderland
Who joined March 14, 2003, 5:22 a.m.
Wrote the following at July 13, 2005, 9:40 a.m...
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.
lhaza
From Milchstrasse, Kakania
Who joined April 20, 2005, 6:35 p.m.
Wrote the following at July 13, 2005, 11:30 a.m...
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
voidfoo avatar
voidfoo
Who joined May 17, 2003, 1:01 p.m.
and authored 473 notes
Wrote the following at July 13, 2005, 4:32 p.m...
winterm (xwsh) wont work. you also need a capable font. i am using rxvt as term program, and vga font, set term=vt100 or vt220. i remember i got the font here. search the forums to see if you can find anything.
dexter1
Moderator
From Voorburg, The Netherlands
Who joined Feb. 20, 2003, 6:57 a.m.
Wrote the following at July 13, 2005, 5:27 p.m...
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...
GeneratriX
From Rosario / Santa Fe / República Argentina
Who joined Oct. 21, 2003, 2:07 a.m.
Wrote the following at July 13, 2005, 6:48 p.m...
...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...
squeen
Moderator
From Maryland, USA
Who joined May 9, 2003, 6:10 a.m.
Wrote the following at July 14, 2005, 4:35 a.m...
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. :(
skywriter
From living in a linux-blunderland
Who joined March 14, 2003, 5:22 a.m.
Wrote the following at July 14, 2005, 9:19 a.m...
Most of my posts start as a looooong rants. However, i generally get though 1/2 of it, get disgusted, and replace the whole thing with a short one-liner as i realize i've probably gone way beyond anyones particular interest in reading the post (i know i rarely read anything over 3-4 lines...). usually it doesn't matter, sometimes it does (yes i've already deleted this post 3 times already... but must.... go... on..). therefore i wish to clarify previous statements.


skywriter wrote: don't worry it'll be something completely different broken in the next release. upgrade!


what i intended here was that my own frustration with open source projects where somethings were so broken on IRIX, that by the time I fixed i it someone had either already replaced it entirely (or deprecated it), or it was fixed by accident, or something else turned out to be even more broken that was more important. Point being the work that dexter has put into yafray should be applied to the CVS and maintained by yafray.org (nobody should break it by virtue of being commited to the codebase) so we can continue to use a MIPSPRO binary without having to reowork it everytime a new release comes out.

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


the point here was that regardless of the absolute value of bittorrent (which is not being argued, it's a neat concept no argument) it's a fact that it's use by entertainment trading users has relegated it to the 'bad/evil software' category by large business. my companies webfilter at work not only does not allow use of bittorent, i can't even visit the site to download it. which means yafray is inaccessible to me at work. when i'm at home i use IRIX and don't want to deal with downloading software (bittorrent) only because one other peice of software needs it - therefore, since i want to use yafray at home, and i use IRIX i want to yafray to be packaged in something that is directly usable by irix, zip or .Z is prefered.

ok, enough talk; on with the party!!!!