SGI: Computer Graphics

tbcpp wrote: 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.

Sounds great!!

Hate to ask btw, but what is it about successive versions since 2.44 that's mean the render has become slower? (now by quite
a margin)

Ian.

newer release are more slower than the previous....

but , when using AO, the new approx setting can be usefull to speed up some rendering vs raytracing
this is a gain

Laurent

mapesdhs wrote: Hate to ask btw, but what is it about successive versions since 2.44 that's mean the render has become slower? (now by quite a margin)

Ian, Ian, Ian ... you've been around for ages. You should speak developerese by now ! "tons of new awesome features in this version" = "slower than dogshit."

hamei wrote: Ian, Ian, Ian ... you've been around for ages. You should speak developerese by now ! "tons of new awesome features in this version" = "slower than dogshit."

8D

Ah well, I suppose with lots of threads there'll be a point at which the slowdown is countered ok.

Does this version support network rendering using multiple hosts? Would be a laugh if I linked up a few of the systems I have, see
what it could do...

Ian.

I compiled versions 2.46, 2.47, 2.48a, and the svn trunk, and didn't see much of a slowdown. about 1 sec or so on a 3 min render. I did however run some gprof tests on the 2.48a code, and noticed that 90% of the time is being spent in the Octree raytests (at least in my test file it did). The good news is, one of the GSoC projects is to make the ray search algorithm configurable at runtime, and to implement BIH trees and other algorithms.

Personally, my interest lies in paralleling the existing structures a bit more.

On the 2.5 front, I have it all the way down to a linking error. It's the stupid o32 vs n32 thing again, I'm sure I just have something setup wrong in the scons file....so we should have a build this week sometime.

tbcpp wrote: I compiled versions 2.46, 2.47, 2.48a, and the svn trunk, and didn't see much of a slowdown. ...

The biggest drop was after 2.44, some 11% down.

Ian.

Hmm...from the release notes, in 2.43 there was a overhaul of the rendering engine. They added multi-pass rendering, and IIRC they went to a full float based pipeline...but I may be wrong there.

Here's the simple test I did using a dual-300 Octane2, the same scene with different releases:




I've not tried the test with 2.48a yet, but here's a comparison of 2.44 vs. 2.48a using my Fuel/900:



It's... well... kindof a huge difference, more than 30% slower.

Surely it makes sense to get the single CPU efficiency sorted out first before trying to go parallel? At least, that's what
a Cray guy once told me about this sort of thing.

Ian.

mapesdhs wrote: Surely it makes sense to get the single CPU efficiency sorted out first before trying to go parallel? At least, that's what a Cray guy once told me about this sort of thing.

I would think (as a layman ) that it would be better to just throw more processors at the problem than try and hack up the code for better single processor speed, considering today's (and yesterday's) multi-core machines and that the speed losses came as a cost of more features.

sybrfreq writes:
> I would think (as a layman ) that it would be better to just throw more processors at the problem than try and hack up the
> code for better single processor speed, considering today's (and yesterday's) multi-core machines and that the speed losses
> came as a cost of more features.

IMO that idea is a microcosm of why the world's going right down the toilet... :}

So how bad does one allow the basic rendering inefficiency to become? 50% worse? 100% worse? Unless the code does a
decent job of rendering with a single core, having lots of threads is just being lazy IMO. Come on guys, I thought the idea of
all this sort of thing was to write good code, not just any-old-code-will-do...

This is the same slippery slope that gfx cards have dived down - nobody bothers writing efficient engines, just let ever
faster hardware boost the speed.

And hey, aren't we trying to save the planet and all that? (at least yesterday anyway What we're effectively saying here is
that it's ok to knowingly use a significantly greater amount of power to achieve the same render time, when a bit of effort
would cut those times by more than a quarter.

I say get the basic rendering system working well first, then think about threading it out. As it stands, what we have right
now is a build that means a dual-300 Octane is no better than a single-400 Octane. Not good IMO.

By definition (I would have thought) any extra efficiency in the code will automatically be passed on to all threads when running
on multiple cores. That's a major saving in time, energy & hence money.

People often moan about MS apps getting all bloaty. We should be on our guard against freeware sw going the same way.

Ian.

mapesdhs wrote: IMO that idea is a microcosm of why the world's going right down the toilet... :}

OK, yeah, but surely they've figured out the efficiency thing by now? If it was such a big deal eventually the project would split and we would have blender and mixer and scrambler and one would be feature rich, one would be fast, and one would be multithreaded.

as you mentioned previously:

it's not like they are getting slower and slower, I think at 2.44 they just had a big push for speed.

Come on guys, I thought the idea of all this sort of thing was to write good code, not just any-old-code-will-do...

The trend nowadays is to write code in higher and higher and higher level languages, let visual studio do all your heavy lifting, then piss off work early for a couple of rounds of whatever.

I say get the basic rendering system working well first, then think about threading it out. As it stands, what we have right
now is a build that means a dual-300 Octane is no better than a single-400 Octane. Not good IMO.

Wouldn't that mean that the threading aspects of the program need to be worked on?

By definition (I would have thought) any extra efficiency in the code will automatically be passed on to all threads when running on multiple cores. That's a major saving in time, energy & hence money.

Yes but you have to think about where to pull the speed from... it's not like blender is just lumbering down the road at half throttle, it's been coded and tested and whatever else and it's running at full speed as is. To pass a car on the interstate you just step on the gas... but this is a race and everybody is already going full speed.

Then again, it's amazing how such seemingly teeny changes can give huge speed boosts.

People often moan about MS apps getting all bloaty. We should be on our guard against freeware sw going the same way.

Nobody's forcing me to use newer versions of anything. I'm the crotchety old man with regards to new versions of things. I'd go broke if I had to always buy new hardware to keep up with the latest versions of software, and the new versions are always slower and harder to use. When I do buy new hardware, my old software goes wayfast on it.

Well I finally got my hands on MipsPro and SGI was nice enough to donate keys to the Blender Foundation. Last night I got the compilers installed and working, now I can actually compile and debug on my Octane. Should make development a bit faster.

tbcpp wrote: Well I finally got my hands on MipsPro and SGI was nice enough to donate keys to the Blender Foundation . Last night I got the compilers installed and working, now I can actually compile and debug on my Octane. Should make development a bit faster.

wow that's awesome... but how do they keep track of who has compiler tools? or did SGI just give them to you?

I was able to get Blender enrolled in the Dev Plus program. So yes, the keys are tied to the Blender account.

nekonoko wrote: Okay, here's mine:

Thanks for that! Solved it without a hitch. Hi all, by the way, new here, just got my first Octane running as of earlier this evening, Blender's the first thing I installed on it!

transnove wrote:

nekonoko wrote: Okay, here's mine:

Thanks for that! Solved it without a hitch. Hi all, by the way, new here, just got my first Octane running as of earlier this evening, Blender's the first thing I installed on it!

Excellent, glad to help! Welcome to Nekochan - hope you enjoy the Octane

Am I doing something wrong or is there no way I can get my hands on Blender-2.48 for IRIX ....... ?????
Seems like the author and the website are gone .......


Can anyone help me to get to the binary ?

Cheers,
Bob

Certainly. You can find it at:

ftp://ftp.nekochan.net/pub/irix/Graphic ... ender2.48/