Slashdot Mirror
SGI Gives Open Source some OpenGL Love
Doctor Bob writes "Just saw this press release from SGI. I think this quote sums it up:
"With today's release, all of the necessary components to implement hardware-accelerated OpenGL drivers will be available to the open source community."
" The implementation from SGI is ready for download from SGI. Have fun.
I don't know how you could consider it not open source; please read the license.
:D My initial (wrong) impression was that the "reference implementation" was just a driver, but it looks like you're giving us the whole enchilada. Good going guys.
...Dynamic assembly code generation for rasterization is not yet included, making software rendering performance slow.
:-) Obviously it's in their interest to throw their stuff into the pot if they want to sell cards to 10,000,000 penguinistas.
I misspoke, and I couldn't be more happy to be corrected
If you have questions about our licensing, please check the FAQ. It goes into a lot more detail.
Jon Leech
OpenGL Group
SGI
So it does:
What's missing from the current Sample Implementation?
That looks like a fun project. I assume this is the time honored hack of assembling code on the stack and branching to it, to cover all the lighting combinations without having 10,000 different inner loops.
The geometry path assembly code optimizations which we ship to our commercial licensees are actually owned by other companies, so we don't have the rights to place them under an open source license. We will work with the companies involved to try and free up these components.
Go get 'em
Thanks a bunch.
Life's a bitch but somebody's gotta do it.
Clustering is a very important technology, that works very well for some applications. But there are some very important, real world applications that will be very difficult (if not impossible) to implement in a clustered environment.
A real world example: A travel reservation company uses a 32 processor Origin 2000 with 16 GBs of memory. They load all of the data (flight schedules, hotel availability, rental car data - about 8 GBs) into a shared memory area, where processes running on all 32 processors can access them directly.
Imagine how difficult that would be to implement in a clustered environment, with the data spread across the system memory of multiple machines. Just finding all the flights from Austin to San Jose would be a nightmare, then you have to worry about locking, etc.
Clustering is great, but it is not the best solution for all problems.
OpenGL is WAY easier to use then D3D.
:)
... because of some "politics" 3D accelerated graphics card vendors are prefering iplementing DirectX acceleration Thats because Microsoft IS so bull-headed after buying Direct3D from Rendermorphics :) Man, do you really believe this is the issue? If you know how d3d drivers are developped, you'd know that a vendor can create a d3d driver for his card with a very small piece of code. So a vendor can easily create D3D drivers for his card, which means there are _always_ d3d drivers for a certain piece of hardware. An OpenGL ICD on the other hand takes a lot more time, because the vendor has to write the complete renderpipeline in the ICD. Ok, they get a basic framework from SGI, but still.. it's a lot more work. In the past, vendors just didn't release any ICD because it would cost too much (S3 comes to mind), but today thankfully any decent cardmaker releases an ICD. It's however a shame not all of those cardmakers include all the new HW features in the ICD via extensions as nVidia does. :(
This is of course very dependant on your skills in the area of the API. If you don't get Binary Objects, if you don't understand OO, you'll NEVER understand D3D. It will be very hard then. OpenGL is a difficult API to master as D3D is too. Everyone can cook up a spinning cube, not everyone can cook up a 10.000 poly world running at decent framespeeds with a lot of different textures.
OpenGL is orthogonal. SGI had tons of experience with IrisGL before they cleaned it up and "re-named" it OpenGL.
Well, there are still some IrisGL leftovers in the OpenGL that should have been removed already. Some things are odd in OpenGL, I wouldn't call it orthogonal
OpenGL has a consistent design (look at Direct3D having 7 versions in 5 year!) OpenGL has gone thru 2 iterations in 10 years. Does that mean OpenGL has been slow to change? No, as vendors are allowed to add any extenstion they wish.
Sorry to interrupt your dreams, but OpenGL seriously is moving forward WAY too slow. I mean by this that the 1.2 specs are great but they are great for a long time already. It's now official and finally we begin to see 1.2 compliant subsystems, but it took way too long, so currently a lot of subsystems don't support any nice features which are provided by the hardware. If the standard would have forced the functionality earlier, Matrox and S3 would have been forced to implement more functionality than they did today. NO Matrox OpenGL driver NOR S3 OpenGL driver supports ANY features which make these cards outstanding: the Matrox bumpmapping in the Gxxx series and the S3 texturecompression. Sure, extensions have an advantage: vendors don't have to wait for the library supplier to release an updated version, but it also doesn't force vendors to add the features.
D3D is a young api. OpenGL is based on IrisGL. Every new technology has it's problems when it's created. IrisGL had these too. D3D is up to par now. It's however IMHO not correct to say: D3D is crap because they had a lot of version in a short time. That's BECAUSE it's new.
OpenGL also has a conformance test, guaranteeing that all OpenGL implementations are feature complete, unlike D3D. Does that guarantee speed? No. Drivers are allowed to "fall-back" into software.
Feature complete is somehow a bit stupid here. 'Feature complete' refers to the 1.1 or 1.2 featureset. 1.2 is too new to be very common, and 1.1 is very old. To be 1.1 compatible doesn't say a thing nowadays. For example ARB_multitexturing, a MUST HAVE feature today, isn't in the 1.1 set. The software fall back is a thing that annoys me the most on OpenGL. When I do a glEnable(GL_POLYGON_SMOOTH); on a GeForce card, it falls COMPLETE to software, because it can't do a part of the pipeline in software, but in D3d only parts of the not by hardware supported features, are done in software. That's IMHO a better approach.
I can only laugh about this.
Take care...
DemoGL main developer. DemoGL is a win32/OpenGL multimedia library.
Never underestimate the relief of true separation of Religion and State.
Indeed. Microsoft bought Softimage, made them port their software to NT, and then sold the company to Avid, which is its currewnt owner.
well see the other repliese we have a very good FreeOpneGl already. If you see the need to do something new - we realy don't need another rendering GL- then go start a project to create a voxel based graphics library which as far as I know does not yet exist in a way comparabel to OpenGL. And by the way what GL are acceleratorboard optimised for? Well the answer is OpenGL and maybe Direct3D and what do you think will happen if we fork OpenGL - I'm sure you dont want that.
--Ulrich
On no accounts allow a Vogon to read poetry at you
From the FAQ
How does the Sample Implementation compare to Mesa?
We believe the Sample Implementation is strong in areas such as internal state management as well as complete feature coverage (such as the optional imaging features of the OpenGL 1.2 Specification, which Mesa does not provide). By comparision to the currently distributed SI, Mesa will probably provide better software rendering performance, and there are existing open-source hardware drivers projects based on Mesa. We think the two codebases can be complementary. Based on discussions with some of the active Mesa developers, there's a reasonable chance of merging the two together into a single reference implementation and driver kit over time.
What does this mean for Mesa-based drivers?
In the long term, it may be possible for the Sample Implementation and Mesa codebases to merge together, drawing on the different strengths of both. Whether or not this happens, elements of the Sample Implementation such as the previously released GLX will continue to be used to support drivers based on either Mesa or the Sample Implementation. We expect both Mesa-based and SI-based drivers will be widespread for some time to come.
What's missing from the current Sample Implementation?
Dynamic assembly code generation for rasterization is not yet included, making software rendering performance slow. The geometry path assembly code optimizations which we ship to our commercial licensees are actually owned by other companies, so we don't have the rights to place them under an open source license. We will work with the companies involved to try and free up these components.
There are also a number of companion libraries, such as the GLS stream codec and the GLC character renderer, which are not being open sourced now because we are uncertain of their value to the community relative to the significant resources we'd have to expend on releasing them. We continue to evaluate what OpenGL-based SGI software technologies would be suitable for open sourcing.
XFree, being an implementation of an X server, has pretty much nothing to do with OpenGL. There are two limited ways they deal with each other:
Mesa is an implementation of the OpenGL API. So is SGI's OpenGL® Sample Implementation. In fact, the reason SGI first started calling it "Open" (instead of simply "GL" for "Graphics Library") was because they cleaned up and published the API, then gave people permission to implement it.
As has been posted elsewhere on this thread, SGI is making vague noises about OpenGL and Mesa merging. This would be a wonderful example of how open source licenses actively discourage forking (as discussed in the context of the GPL in Linuxcare back in November).
If you want to know more about the hoary guts of OpenGL, and not just the API, I'd suggest looking up some of Akeley's articles on the hardware from prior SIGGRAPH proceedings.
Both Inventor and Performer are toolkits developed by SGI to run on top of OpenGL and simplify application development. Inventor is targeted more at interactive applications, like modelers (I wrote one in Inventor before it was released in less than five days, having never seen the library before - see Paul Strauss's and Rikk Carey's SIGGRAPH paper). Performer is targeted more at walkthroughs, flight simulators, and the like.
-----
Klactovedestene!
Funny you should mention Avid. Didn't they stop supporting Apple's QuickTime format and/or MacOS, thus making their video editing systems Windows-specific, for fear of retaliation from MS?
What will happen to Mesa now? Who will assimilate who?
Sorry for the stupid question, but how does the stuff SGI released relate to XFree 4 and Mesa? Also, could somebody please explain how the accelerated 3d graphics will work in Linux? (as in the architecture)
___
___
If you think big enough, you'll never have to do it.
Be sure to take a look at the Project List page at oss.sgi.com, some interesting stuff is listed there.
If you poke around on the A|W site, you'll find information about becoming a beta-tester for the Linux beta of Maya. You'll have to find it yourself because I don't want to cut into my chances of actually making the cut.
Softimage, I don't know, although it would be really nice to see. Avid has owned Softimage for a couple of years now, and Softimage development is actually done by some company in Germany I think, (rather like the way 3DSMax is, or was, owned by Autodesk but developed by Kinetix.) so it's kind of confusing to follow, but IIRC, they do at least offer their Mental Ray rendering engine on Linux and have for a couple of years now.
-=-=-=-=-
-=-=-=-=-
My mom's going to kick you in the face!
IRIX is _that_ cool, I hear. I'd like to run it on my laptop (PowerPC), but I can't think of a way to re-target it there without the source code.
--
Of course, there's a difference between their OpenGL sample implementation and the private SGI OpenGL implementation (and the difference is... speed). Still, this is cool, although SGI could have saved themselves the grief of Microsoft's DirectX crap taking off if they had Open sourced this years ago. ( Amazing how generously giving stuff away just makes people like me whine.)
Now we just need OpenInventor open sourced, and there will be a real chance of DirectX biting the dust. (Novices find it far easier to put together interactive 3D apps with a decent scene graph implementation).
http://rareformnewmedia.com/
-----------
"You can't shake the Devil's hand and say you're only kidding."
There will be future SGI graphics workstations that run* Linux :) This would be (at least from what I've heard) one of the reasons we open-sourced OpenGL.
* - This is in addition to the ones that run Irix, which, of course, will continue to be produced.
I speak for myself, not for SGI.
Go Badgers! -- #include "std/disclaimer.h"
Oops. The last one is $4995 too. My bad.
Glückwünsche, haben Sie Slashdot ermordet, indem Sie zum korporativen Druck beugten und Subskriptionen einlei
This is the reference implementation for OpenGL. This is what a licensee would get prior to this change in licensing when they paid SGI big bucks to license the OpenGL name and produce an OpenGL driver/library set for a given OS. With it, you could produce a clean, 100% compliant driver and library set.
It's a quantum leap towards full Open Source by SGI- it's been one of their crown jewels.
I am not merely a "consumer" or a "taxpayer". I am a Citizen of the State of Texas
-----------
"You can't shake the Devil's hand and say you're only kidding."
It's not obvious that anybody will necessarily assimilate anybody. Let me be perfectly clear that we are not doing this to "kill Mesa" or anything idiotic like that. Mesa has a lot of good stuff in it and, unlike the Sample Implementation, there are some open source Mesa hardware drivers available today. On the other hand, the SI does some things that Mesa does not, and almost all closed source hardware drivers are based off the SI - so companies who choose to open source their own drivers in the future will be able to do so now.
There are a lot of ways we may be able to share code and work together, and we've been in touch with Brian Paul about this for quite a while. None of us know exactly how this is going to work out, but we are talking and we all realize it's important to work this out.
Jon Leech
OpenGL Group
SGI
They _where_ in a bad position, and have taken the _only_ way forward.
As Tim Sweeney (Unreal programmer) pointed on his rant about programming languages, games have a big influence in the course of graphics technology. Last year it looked like ActiveX was winning more and more mindshare in the games industry. If it weren't for John Carmack and the Linux crowd, M$ would have had its way.
Now OpenGL is back again, but it needs the support of the community. The only way to get it is to support open source.
I think OpenGL is in the same position as Netscape. They are cross-platform, and what is clear now from the success of Linux is that bein cross-platform is a huge advantage! OpenGL will be a success and will draw money towards SGI enviroment. If they change their business model and work out how to cash a part of this money, they will be back again.
If you look at Sun, they are making money of Java even though you can get all of the stuff for free (except the EEJB brand). But they make money because people thinks about SUN when they think about Java.
In short. I expect both Mozilla and OpenGL to be big successes in the medium term.
When his defense asked, "Which computer has Jon Johansen trespassed upon?" the answer was: "His own."
I always enjoy posts from the previous SGI-er. Somehow, the world hasn't changed for them, and their knowledge of what is happening in SGI. Every line of code, every building, we even are still using the same coffee grounds .
Mips is _not_ dead. In spite of the fact that MIPS was spun out, SGI retained the high-end design teams within. SGI has announced and shown the roadmap for Mips chips and technology for computers (versus the embedded world) that currently runs through 2006.
Please take a look at the Irix/Mips Roadmap.
Dave McAllister
Open Source Ronin
"Sample Implementation" means that the code serves as a reference to how the OpenGL, GLX, and GLU APIs are supposed to work. It's also used by our current licensees (and hopefully by open source projects in the future) as a starting point for writing hardware drivers.
The release includes what our commercial licensees have been receiving, except for a handful of optional elements that SGI does not own, such as tuned geometry acceleration for different CPUs. Hopefully the other companies involved will choose to open up those pieces too.
Basically, this is one part - albeit a big part - of the set of things that go into an OpenGL driver.
Jon Leech
OpenGL Group
SGI
I don't know how you could consider it not open source; please read the license.
Being "GPL-compatible" is a red herring. Mesa is now under the X license, and the Sample Implementation we just released is under a license designed to be compatible with the X license, in both cases for the same reason: so that the code can be incorporated into XFree86. XFree86 is, if you will, "GPL-incompatible" and that is a conscious decision by the XFree86 project.
If you have questions about our licensing, please check the FAQ. It goes into a lot more detail.
Jon Leech
OpenGL Group
SGI
On win32, there are two OpenGL dlls, as any Windows OpenGL programmer knows. One is made by SGI, and the other by Microsoft. The SGI one is vastly superior in speed for software rendering, because of the dynamic code generation optimisations, I'd assert.
However, after browsing through the source tree for a while, I've found that the version released for Linux does not have these optimisations.
Before I give my speculations, I'd like to point out that I'm pretty new to the OpenGL programming scene, and I'm not completely aware of SGI's motives and resulting tactics in the past.
Here are the reasons I can speculate for this:
1) This is an example OpenGL implementation in order to assist developers in getting the implementation correct, the algorithms are not the focus of this release.
2) SGI has their own motives for not letting others know the dynamic code generation secrets due to political reasons, though I cannot fathom what they'd be.
3) Their original intention for the release of this source tree was to assist Mesa3D, and Mesa3D is a portable implementation of OpenGL, and an x86 code generator would defeat that.
All in all, I cannot settle on a single reason as to why SGI would benefit to not release the highest possible quality OpenGL code.
Any ideas?
So we still need Mesa. A strong Mesa is the only club we have that's big enough to force OpenGL the rest of the way into open source. Don't get me wrong, this is great, and I think SGI is really doing a lot of good for open source in general and Linux in particular, but we'll be sure to make our OpenGL drivers work perfectly under Mesa as well as the official product, won't we? Anything else would be... naive.
Until OpenGL is *fully* GPL-compatible, Mesa must remain the number one 3D platform for Linux.
Life's a bitch but somebody's gotta do it.
That's kind of surprising. I've never used Linux on an SGI, but doesn't it use the framebuffer device for a console driver? I've not had any problems running XF86_FBDev with Linux's framebuffer devices (on my G3 laptop, on a 3Dfx Voodoo 3, and on a Sparc). Maybe the FBDev X server is something to look into.
--
Wow, IRIX sounds really cool. I've only used older versions (on older Crimson and Iris workstations). Where can I grab the source?
--
> i heard that developers of 3D visual apps like
...
... because of some "politics" 3D accelerated graphics card vendors are prefering iplementing DirectX acceleration
> 1. OpenGL much more than DirectX because of easier use,
OpenGL is WAY easier to use then D3D.
OpenGL is orthogonal. SGI had tons of experience with IrisGL before they cleaned it up and "re-named" it OpenGL.
OpenGL has a consistent design (look at Direct3D having 7 versions in 5 year!) OpenGL has gone thru 2 iterations in 10 years. Does that mean OpenGL has been slow to change? No, as vendors are allowed to add any extenstion they wish.
> 2. better performance,
Not true. D3D and OpenGL perform very similiar.
> 3. more/better "API" (functionality)
Today, the 2 API's are very similiar. OpenGL used to have more features then D3D back in the early days.
> and better graphics
Again, very similiar.
OpenGL also has a conformance test, guaranteeing that all OpenGL implementations are feature complete, unlike D3D. Does that guarantee speed? No. Drivers are allowed to "fall-back" into software.
>
Thats because Microsoft IS so bull-headed after buying Direct3D from Rendermorphics.
> so now i wonder (like you) if this "open sourcing" of OpenGL give some advantage to OpenGL
It will definately help Mesa. The video card manufactors ALREADY have the OpenGL reference code. They aren't happy having to support 3 API's either... 1) Their own API, 2) OpenGL, and 3) Direct3D
> also i'm looking for some more info about "OpenGL vs. DirectX" issue.
Sorry, you're late to the party. It was over 2 years ago.
> do someone got some URLs?
All this history can be found here...
http://www.vcnet.com/bms/features/3d.html
Cheers
3D Game Programmer
Is this really a Good Thing? I mean, let's be unbiased here (just for once). I'll hand it to you that OpenGL is a good step in the right direction. This should make it much easier to get some good games and such ported over.
But we're not just interested in "porting" are we? What we really want is portman. This is why I am proposing a new standard called "OpenNP".
OpenNP is what every open source programmer wants. Direct access to Natalie Portman's low level functions is the stuff of dreams around here. But not only will OpenNP provide direct low-level access... it will also provide a very pretty interface.
I have started a web page for the project. Please go there to volunteer or just check out where the project is headed.
thank you.
Has there been any word from SGI on the possibility of open-sourcing Open Inventor?
You can find more information about this here on SGI's OpenGL Sample Implementation. The frequently asked questions are available here.
The page mentions that this OpenGL implementation will be released under a very open license. They will be using the SGI Free Software License B. Another interesting thing mentioned is that in the long term, the sample implementation and Mesa might merge together. It will be very interesting to see how Mesa will continue to develop.
I'm glad to hear that SGI released this, because OpenGL was one of Linux's weaker points, since Mesa isn't fully OpenGL 1.2 compliant. Way to go SGI!
And, besides, the GPL doesn't give freedom. It takes it away.
:)
*sigh* That old thing again?
Very similar to the USA's Bill of Rights, the GPL makes sure certain things (RMS calls them "freedoms", you call them whatever you want) will always be available. And, like the Bill of Rights, it does that by limiting other things.
Now, it is up to the developer to choose the license they like best. Personally, I prefer the GPL, but I don't get all bent out of shape over it.
Seriously, the GPL is far too limiting.
*shrug* See above. There are those who think the GPL's "limitations" are like the "limitations" that prevent citizens from murdering one another.
If we, as a community, are to be taken seriously, we need to break the notion that all software companies, once they open their source, need to be flooded with responses amounting to, "your license is crap, make it GPL so it's truly free!"
I agree. I also think we need to break the notion that shouting "DIE SOUP NAZI" and going off on a rant about the GPL every time someone suggests it accomplishes anything.
Practice what you preach.
dragonhawk@iname.microsoft.com
I do not like Microsoft. Remove them from my email address.
Extract from an SGI news : --- NVIDIA, SGI and VA Linux to Bring Graphics Standard to Desktop Linux Market Three Companies Collaborate to Deliver First Hardware-Accelerated OpenGL (1.2) Conformant Desktop Graphics for Linux --- Hope that helps,
-- Martial MICHEL
I seem to recall that Microsoft spun off Softimage (which it had never really assimilated, and which had remained based in Montreal) some months back.
Basically, the only effect of MS's acquisition of Softimage had been ports of its software to NT, which then started to make inroads into graphics/rendering/animation. Even MS didn't have the clout to abandon SGI support.
A big thank you to SGI for their kernel patches.
You know, I *REALLY* like what IBM and SGI are doing lately. I mean, these companies have their act together. They are taking a higher road that few companies are willing to transverse right now. Despite IBM's shaky history, they really seem to have turned it around (and God bless Blue Labs and everything that has come out of it). SGI is another good example, remember their lawsuit with NVIDIA? Well, rather than carry through with the lawsuit, they decided to work with NVIDIA, and share their technologies instead of bickering over stupid patents and thus ensuring BOTH companies have a bright future not tied up in litigation.
This is the way things should work. Slashdot has been really depressing lately. All the patent infringement and privacy issues that have been wearing down on me, and I've questioned a few times why I continue to read Slashdot (afterall, who wants to spend their day depressed). Every once in a while though, something like this comes along and gives me some hope.
Oh, one last thing while I'm on my podium... I would like to see just a little bit less coverage of these patent infringement/privacy type news posts and get a little more of the science and programming content we used to get. I know this stuff is important, and I don't want to see it go away, but the other content has been a bit barren lately (and what happened to quickies? They come once a month if that now).
Thanks for the hard work and great web site.
Actually, this OpenGL implementation is open-sourced, under a very liberal license. If you didn't read the frequently asked questions, it mentions that this implementation is going to be released under SGI's Free Software License B.
So, the word is "No Comments at this time." =]
I know a lot of people are waiting for my "official" response to the SI release. However, I'm still studying the ramifications of the SI license.
I'm hesitant to endorse any code migration between the SI and Mesa code bases until the implications of the licensing are completely clear. The issues of tainting and copyright ownership have to be well understood first.
-Brian
(Hope this doesn't get me in trouble!)
I will club to death the next person who says "okay, now maybe DirectX will bite the dust" or anything along those lines. DirectX is the Windows multimedia API. Its propriatory to windows just like the UNIX joystick API, and the UNIX Sound API. Thats how they chose to implement these functions in Windows. DirectX is actually a nice, fast API. D3D on the other hand, is what many people consider to be the bastard child of the DirectX family. Its gotten within of OpenGL, but is I think as tricked out as the inane design will allow, and OpenGL is still getting faster. (hopefully.) So to recap. DirectX is analogous to what the Loki game SDK for Linux. I don't see windows user bitching that Loki GSDK is not available on windows. D3D and OpenGL are the two things usually in contention here. So go ahead, club D3D over the head. It deserves it. But leave the rest of DirectX alone.
BTW> Two points. Quake III uses DirectInput, and Linux NEEDS something like directX. Integrated, low-level, and hardware accelerated. Heaven. (sans 3D API of course.)
A deep unwavering belief is a sure sign you're missing something...
SGIs are indeed very nice for image processing, but that has as much to do with their memory model, graphics hardware, bus speed, and other architecture considerations as the CPU itself. Seti doesn't stress the memory nearly as much as real image processing does and obviously doesn't use graphics hardware so it isn't a good benchmark for real use either.
I don't think SGI is going to loose their grip on the high end of image processing any time soon, but the low end keeps getting better with faster memory busses, better graphics boards and of course faster CPUs. For many purposes, SGIs are a luxury that is increasingly hard to justify.
--
"L'IT c'est moi!"
Moderate that question up.. it's pretty key. We already have a really well-written implementation of OpenGL in MESA, lacking only the license fee to get the logo/stamp on it. Can MESA now claim OpenGL compliance? Have they changed the licensing/legaleze of using that mark?
This is interesting none-the-less.
I worked for sgi for a little over 2 yrs. not all that long, but long enough to see the decline of sgi at its during its prime pinnacle.
it was the coolest company I ever worked for. the spirit and atmosphere was unmatched (talking about life on the mtn view campus). I look back at those times with a smile on my face - and a tear in my eye for what it let itself become.
sgi does cool stuff. problem is, they price themselves out of the market and since the market has changed drastically (ie, graphics workstations are now sub-$2k and linux clusters can be built that outperform the o2000 line for a fraction of the price) their business model didn't adapt - so it dies.
I watched the birth and ultimate death of the NT box (called 'wbt', internally; wintel box thing). I saw cray being bought, then attempted to be assimilated, then ultimately thrown away. irix, once a reasonably resilient (albeit somewhat incompatible) version of unix, is essentially dead. the MIPS cpu is essentially dead, with sgi selling its soul to Intel and hoping the merced will save its sorry ass. custom graphics hardware may also be dead at sgi. so what's left? linux??? will sgi attempt to convert from a hardware company that leverages software, to a software-only company?
again, I love sgi and wish them well. but in the last 4 yrs or so, they've demonstrated they know nothing about how to adapt to the New World Order of computing (cost models and such). trying to hang on by rallying behind "the linux thing" is just too little, too late. and there's just not enough profit in it to support the giant that they still are (building- and people-count wise).
--
--
"It is now safe to switch off your computer."