SGI: Computer Graphics

Diego wrote: ...mmmhhh
Anyone has completed succesfully the build of YafRay V0.0.7 on IRIX? ...I got the package already compiled, but on the 'make install' phase I get:

Ok everybody please start laughing at Yafray makefile "specialists", 'cause this one is a real screamer:


g++ ??? what the hell does that do in a mipspro build? Looks like somebody made a sick joke upon us. I tried this myself and even with env settings like 'setenv CXX CC' it still came up with g++.


Sure enough, i found the bug in src/yafraycore/Makefile.in:
Hardcoded g++ compiler in the makefile. It doesn't get any worse than this. Stupid crack kiddies...

So add this patch:

And this environment:

There are more Makefile.in which also have this harcode. Please fix them accordingly...

The " _ZN6yafray9context_tC1Ev" i recognised as c++ name mangling errors, which would be perfectly logical if one would mix g++ libs with mipspro code.

It could be that the libraries need to be rearchived with CC -ar -WR,-suv -o
I'm rechecking this ATM...

dexter1 wrote: Ok everybody please start laughing at Yafray makefile "specialists", 'cause this one is a real screamer:

Code: Select all

.
g++ -shared -nostdlib /usr/freeware/lib/gcc-lib/mips-sgi-irix6.5/3.3/crtbegin.o  .libs/pathlight.o .libs/pathtools.o  -Wl,-rpath -Wl,/usr/local/lib -L/usr/local/lib -lyafraycore -L/usr/freeware/lib/gcc-lib/mips-sgi-irix6.5/3.3 -L/usr/bin -L/usr/freeware/lib/gcc-lib/mips-sgi-irix6.5/3.3/../../.. -lstdc++ -lm -L/usr/lib32/mips3 -L/usr/lib32 -lgcc /usr/freeware/lib/gcc-lib/mips-sgi-irix6.5/3.3/crtend.o  -Wl,-soname -Wl,libpathlight `test -n "" && echo -Wl,-set_version -Wl,` -Wl,-update_registry -Wl,.libs/so_locations -o .libs/libpathlight
ld32: FATAL   9  : I/O error (-lyafraycore): No such file or directory
collect2: ld returned 32 exit status
libtool: install: error: relink `libpathlight.la' with the above command before installing it
*** Error code 1 (bu21)
*** Error code 1 (bu21)
*** Error code 1 (bu21)
*** Error code 1 (bu21)


g++ ??? what the hell does that do in a mipspro build? Looks like somebody made a sick joke upon us. I tried this myself and even with env settings like 'setenv CXX CC' it still came up with g++.

Nice catch, Dexter!
...but I've also tried using g++ (GCC Version 3.3), and I can't get a clean install here... Hence my words:

Diego wrote: it compiles fine, even with MIPSPRO

As far as I can see, it is not a very clean "multiplatform" sourcecode, but I could be wrong!

Diego wrote: Nice catch, Dexter!
...but I've also tried using g++ (GCC Version 3.3), and I can't get a clean install here... Hence my words:

Diego wrote: it compiles fine, even with MIPSPRO

As far as I can see, it is not a very clean "multiplatform" sourcecode, but I could be wrong!

No Diego, you're missing the entire point.

With the Makefile.in template you ALWAYS compile with g++ even when the ./configure script says it has found CC and you have set environment variables the right way.
The g++ is HARDCODED in all Makefile.in templates...

If you really managed to get it compiled with MIPSPro 7.4.x you should have had complaints with in 2 files because that is an old, unsupported style header file. See my patch, it's in there...

That's why you need to change all g++ occurences with @CXX@ in all Makefile.in files. Then do a ./configure again and it should start compiling with MIPSPro CC.

The make install problem is an entirely different one. Looks like the supplied libtool severely screws up. The solution is to get the latest libtool from gnu.org ( 1.5.18 ), ./configure;make that one and copy libtool and ltmain.sh to the yafray top source dir. Then do
The next thing that you get is that every cout/cerr stream ending with '<<endl' will segfault and dump core. Looks like the coders got overzealous and decided to overload every << instance in their own ostream class. Handy...
Replacing all '<<endl' with '<<"\n"' seems to fix this. Better get a script to do that for you.

I have this almost done. Good testing still needs to be done before we can go to '-Ofast -IPA'

hi,

tried it, too.
it's a real pain. seems like the guys over there are some sort of 'made with and for linux'
hardcoding g++ in some makefiles is crap anyway. no matter which os.

dexter1 wrote: No Diego, you're missing the entire point.

With the Makefile.in template you ALWAYS compile with g++ even when the ./configure script says it has found CC and you have set environment variables the right way.
The g++ is HARDCODED in all Makefile.in templates...

Ouch! Now I really feel stupid!
That's it, seems that I'm too much hurried by this days, and I've not taked well care of your post...
Now all has a lot of sense.

dexter1 wrote: If you really managed to get it compiled with MIPSPro 7.4.x you should have had complaints with

Code: Select all

#include <cmath>

in 2 files because that is an old, unsupported style header file. See my patch, it's in there...

That's why you need to change all g++ occurences with @CXX@ in all Makefile.in files. Then do a ./configure again and it should start compiling with MIPSPro CC.

Nah... then, I've never really compiled with MIPSPRO; now I can see the g++ sentences hardcoded in my Makefile.in! :shock:
Sorry, I'm felt in the fact too late. You can see it even in my previous post! Augh! :(

dexter1 wrote: The make install problem is an entirely different one. Looks like the supplied libtool severely screws up. The solution is to get the latest libtool from gnu.org ( 1.5.18 ), ./configure;make that one and copy libtool and ltmain.sh to the yafray top source dir. Then do

Code: Select all

./configure --enable-static --disable-fast-install ; gmake ; gmake install

The next thing that you get is that every cout/cerr stream ending with '<<endl' will segfault and dump core. Looks like the coders got overzealous and decided to overload every << instance in their own ostream class. Handy...
Replacing all '<<endl' with '<<"\n"' seems to fix this. Better get a script to do that for you.

I have this almost done. Good testing still needs to be done before we can go to '-Ofast -IPA'

Well; seems a lot of work for a nice piece of software that I'll only use a few minutes by month in my spare time... But stills interesting...
I already have done a tardist install for Blender 2.37a, and I could like to add this one to the list of customizations modules for my SlimDesktop, since both makes a good douple!
SlimDesktop has currently included a tardist for YafRay V0.0.6, but if the new version is "NekoWared" I'll be happy pulling out the 0.0.6 to replace it with another "IRIX-Orphan" software...
The prerequisites for a program, to be added to my SlimDesktop are:

1) Not other tardist versions visible on the net for such program.
2) An IRIX friendly roadmap of the program, without too many gcc/g++ 'isms or platform dependant vicious.
3) That the program by itself can be interesting from a graphic/visual work point of view for the end user.
4) That the program can enhance the already available features on IRIX/IMD/4Dwm.
5) The author agreement about the inclusion of his software on my big tardist install! ...Even when sometimes I'm too lazy to ask to the authors, and I only wait for a claim to pull-out the whole thing!

But as a rule of my philosophy, I'll not double efforts already present on the IRIX community, beeing this SGI FreeWare, NekoWare, or whatever else. So, every tardist version already present on SlimDesktop for a given program, yet covered by the SGI/IRIX community, there'll be replaced for a new one acomplishing strictly the above five rules to keep my software rich from the point of view of their originality and usefulness.

This also works as a good way to manage better my time at front my SGI boxes!

After some bloody confrontation scenarious with yafray source, i think i have the magic patch file pinned down. Problem only is that i cannot find a mundane test.xml file so i can test the yafray binary. I already tried the test007.zip package and i can't get a sensible xml out of blender. Or the xml code will come out fine, but i get things like this:

... and YBtest.tga is completely black. BTW this is the same in Linux as it is in IRIX. Seems the Yafray coders have their heads firmly in mr Gates' butt...

Can anyone provide me with a small working XML file so i can do some speed testing?

now this thread is starting to make sense :)

This is a normal output from Yafray V0.06, for comparation purposes... oh, and yup, complaining about the Python environment variables, that I must fix at some point in my system



The generated XML file :



These will give you a cube with the upper face hardly enlightened...

Oh Mr Diego, i think you might want to read this:

viewtopic.php?t=1826&start=112

dexter1 wrote: Oh Mr Diego, i think you might want to read this:

viewtopic.php?t=1826&start=112

Very cool Dexter!
...Now we can play again with raytraycing on Blender using the latest version of YafRay! I'll download now to give it a try. Thanks by the mention of the NekoWare thread...

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.

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

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

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!