SGI: Computer Graphics

render optimization comes and goes, depending on the whims of (usually) Ton somethings may get tweaked at the expense of others, depending on real world work rather than the test.blend.

fwiw - although the renderer is multithreaded, not all parts, or indeed the most computationally expensive parts are parallelized.

skywriter writes:
> render optimization comes and goes, depending on the whims of (usually) Ton somethings may get tweaked at the expense of
> others, depending on real world work rather than the test.blend.

Yeah but still, 30%?? Kinda huge drop IMO. Makes a nonsense of inter-version comparisons, which is why I'm sticking to 2.44 for
benchmarking. And remember this is just for a very simple scene; quite possible the speed loss would be much worse for a complex scene.


> fwiw - although the renderer is multithreaded, not all parts, or indeed the most computationally expensive parts are parallelized.

I noticed. Personally I don't like the way the threaded stuff works at all. Sometimes it doesn't start using more than one thread
until after the first block has been completed, there's a major stutter when each thread completes which can be nasty if a whole bunch
finish at more or less the same time, and once the no. of remaining blocks is less than the no. of threads then the parallelism drops
off completely (very poor if the last coupla blocks happen to be complex). Ah well, better than nothing.

I know it's just a very simple test program by comparison, but I like the way C-ray does it. Parallelism is always maxed as much as it
can be since it's done by scanline.

Ian.

I tried getting the 2.48 blender to run (Tezro with 6.5.26).

I set the PYTHONHOME=/usr/nekoware/bin

The ldd shows:
root@MICHELANGELO:/root/irix6# ldd ./blender
libaudio.so => /usr/lib32/libaudio.so
libGL.so => /usr/lib32/libGL.so
libGLU.so => /usr/lib32/libGLU.so
libX11.so.1 => /usr/lib32/libX11.so.1
libXi.so => /usr/lib32/libXi.so
libXext.so => /usr/lib32/libXext.so
libc.so.1 => /usr/lib32/libc.so.1
libm.so => /usr/lib32/libm.so
libdl.so => /usr/lib32/libdl.so
libpthread.so => /usr/lib32/libpthread.so
libdmedia.so => /usr/lib32/libdmedia.so
libmovie.so => /usr/lib32/libmovie.so
libCsup.so => /usr/lib32/libCsup.so
libC.so.2 => /usr/lib32/libC.so.2
libCio.so.1 => /usr/lib32/libCio.so.1
libGLcore.so => /usr/lib32/libGLcore.so
libXsgivc.so => /usr/lib32/libXsgivc.so
libmutex.so => /usr/lib32/libmutex.so
libmovieplay.so => /usr/lib32/libmovieplay.so
libmoviefile.so => /usr/lib32/libmoviefile.so
libcl.so => /usr/lib32/libcl.so
libawareaudio.so => /usr/lib32/libawareaudio.so delay-load
root@MICHELANGELO:/root/irix6#

When I try and run it, I get:

root@MICHELANGELO:/root/irix6# ./blender
guessing './blender' == '/root/irix6/./blender'
Compiled with Python version 2.5.2.
'import site' failed; use -v for traceback
Checking for installed Python... No installed Python found.
Only built-in modules are available. Some scripts may not run.
Continuing happily.
Bus error (core dumped)


Any ideas?

Thanks,

Jackson

mapesdhs wrote: skywriter writes:
> render optimization comes and goes, depending on the whims of (usually) Ton somethings may get tweaked at the expense of
> others, depending on real world work rather than the test.blend.

Yeah but still, 30%?? Kinda huge drop IMO. Makes a nonsense of inter-version comparisons, which is why I'm sticking to 2.44 for
benchmarking. And remember this is just for a very simple scene; quite possible the speed loss would be much worse for a complex scene.

it's possible that there could have been an increase on an intel/pc architecture. it's been a long time since anyone cared about sgi/irix performance in the vast majority of the blender community.

> fwiw - although the renderer is multithreaded, not all parts, or indeed the most computationally expensive parts are parallelized.

I noticed. Personally I don't like the way the threaded stuff works at all. Sometimes it doesn't start using more than one thread
until after the first block has been completed, there's a major stutter when each thread completes which can be nasty if a whole bunch
finish at more or less the same time, and once the no. of remaining blocks is less than the no. of threads then the parallelism drops
off completely (very poor if the last coupla blocks happen to be complex). Ah well, better than nothing.

I know it's just a very simple test program by comparison, but I like the way C-ray does it. Parallelism is always maxed as much as it
can be since it's done by scanline.

Ian.

if you bashed your head against the blender development community you would find they haven't been interested so much as doing it right, but getting something at all done. the threading and distributed rendering is really, really, really, primitive.

skywriter writes:
> it's possible that there could have been an increase on an intel/pc architecture. it's been a long time since anyone cared about sgi/irix
> performance in the vast majority of the blender community.

Hmm, I don't see how that could occur though, afterall the build is compiled for MIPS. How could a general 'method' of rendering a scene
within the application be magically faster after a revision on an x86 platform? ie. the algorithm is surely unrelated to the final compiled
code for whatever platform.


> if you bashed your head against the blender development community you would find they haven't been interested so much as doing it
> right, but getting something at all done. the threading and distributed rendering is really, really, really, primitive.

So I see. Oh well.

Ian.

What are the correct environment variables to set for Python btw? What would they be for a normal
installation with Python 2.5.2? Anyone care to post their .cshrc entries for V2.5.2?

Ian.

PYTHONHOME=/usr/nekoware
PYTHONPATH=/usr/nekoware/lib/python2.5

hope this help you

Laurent

No such luck...



Ian.

mapesdhs wrote: No such luck...

You guys are not reading this thread in its entirety:

sgefant wrote: That crash probably is not related to python. Do you have a .B.blend file in your home directory? if not, try creating one by running a older version of blender and pressing ctrl+u. If blender 2.48 works then, you've hit the same bug as I did.

Perform that step and it should work.

nekonoko wrote:

sgefant wrote: That crash probably is not related to python. Do you have a .B.blend file in your home directory? if not, try creating one by running a older version of blender and pressing ctrl+u. If blender 2.48 works then, you've hit the same bug as I did.

Perform that step and it should work.

I never went farther with this since I don't use Blender and it wasn't worth the effort to install then de-install two versions just to see if it worked ... but if someone had a .B blend file I'd probably test again (hint hint).

Okay, here's mine:

nekonoko wrote: Okay, here's mine:

Solves the problem instantly. Don't know how well it works because I am a Blender I.D-ten-T but putting that file in the home directory solved the problem on a 6.5.30 Fool .

It certainly opens fast, I can say that.

Gracias, Senor Neko.

nekonoko writes:
> You guys are not reading this thread in its entirety:

Whoops! I had read that a while back, but forgot.


> Perform that step and it should work.

Yep, works ok! But as before, it's a lot slower than V2.44 (1 min 17s on quad-1gig Tezro with V2.48, vs. 1 min exactly with V2.44).

Ian.

Thank you, works right out of the gzipped tar!

Funny thing is that when trying to play-back a render of 300 frames the play-back stops at 65 frames and loops right back to frame 1 .....

Can anyone confirm this ?

Is there a playback limit introduced in this version ( previous version 2.44 plays just fine ... )

that's weird. is the end frame set to 300? is the 66th frame corrupted? are the frames on a file share?

humm

an option is missing with our release, the FSA antialiasing method is missing..... only hav the OSA

Laurent

Hi,

The game engine seems to be missing, and also the standalone blenderplayer.
I'm using these in the official IRIX 2.45 release for interactive walkthrough's of architectural
designs using stereo glasses, but would like to take advantage of some of the improvements
made to the game engine in 2.48a.

Thanks,
dlw

Sorry for being gone for so long, I got busy with a job change, and didn't have much time to work on this.

Anyway, 2.5 is at the point that I'm going to start on getting it to compile. Don't expect any news for the next week or so, but I am still alive and plan on keeping 2.5 compilable on MIPSPro. Here's hoping the new code base is easier to compile...we'll see.

Seems like I've heard the 2.5 should come out in July 09, but I may be wrong there. Anyway, tons of new awesome features in this version.

hip hip hurray !!!!

i personaly wait this release
i spend all my time on blender since four month

i have a request: please let us to have a lot of threads to feed our (my) origin....

somes examples of my works....







Laurent