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.
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.
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!
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.
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/
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
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
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.
--
> 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.
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!
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.
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!)
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?
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."