Follow Slashdot blog updates by subscribing to our blog RSS feed

 



Forgot your password?
typodupeerror
Check out the new SourceForge HTML5 internet speed test! No Flash necessary and runs on all devices. ×
Silicon Graphics

SGI Gives Open Source some OpenGL Love 211

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.
This discussion has been archived. No new comments can be posted.

SGI Gives Open Source some OpenGL Love

Comments Filter:
  • If SGI wish to open-source their stuff, I'm happy. I think that's a good think, and I can heartily say "more power to 'em". Why do we scream for companies to open-source their stuff, then we have people like you who proceed to bitch about it when they do.

    Also, it'd be a lot easier to understand your opinion on this if you wrote in better English. (I'm not gonna say anything about your intelligence - I have a professor who is quite intelligent from what I can tell, but most of the time people can't understand him for love or money...)
  • The availability of Open Inventor [sgi.com] on Linux would make it much easier to build compelling 3D applications on that platform. Releasing it under an Open Source license would be killer! Please make it happen SGI. While you're at it, please do the same with the ImageVision Library [sgi.com].

  • 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.

    That seems to have been SGI's attitude all along, and I must say that it's far and away the best corporate attitude I've seen in any big player.

    IBM is doing good, yes, but in a relatively cold-blooded way. In essence, SGI can't see the bottom of this chasm they've come to, but are willing to try jumping it anyway. That's real courage! IBM thinks that they can see the bottom, and are in for a surprise (-: IBM-shaped hole at bottom? :-). Sun are preparing to trek around it. So long, Sun, enjoy the trip, follow the footprints when you get back.

    For SGI's multiple commitments to the public good (hey, that's me!), I'll be recommending SGI gear over comparable equipment from elsewhere for every high-end job that I spec from now on. It won't take a great percentage of the computing public doing likewise to double SGI's turnover.

    Are you listening, Sun?
  • The funny thing is, SGI is smart. They know that if they help drive the Linux application market, they will reap the benefits: "Hey applications maker, let us help you port your Linux application to Irix."

    This is actually a very insightful take on SGI's current strategy. By promoting Linux as "Irix Jr.", they keep some of the mindshare away from NT, and towards the traditional Unix vendors (which SGI knows how to compete with).

    The question is: are people really moving towards NT because of hardware costs? Or is because NT is seen to integrate easier into a "regular" corporate network with "regular" support personnel? (I know that is one main reason Macs are on the out on most corporate networks.) Sure, the smart strategy is to be "developer-centric", but in the real world there are many pennywise-poundfoolish situations.
    --
  • My comment was on the sad fact that, in the last few cases of companies attempting to open up source of a particular piece of software, that this is in fact A Very Bad Thing when the software is not released under the GPL. This, in fact, has been encouraged in the past by Richard Stallman (although his position seems to have softened a bit; he actually seemed pretty positive about Qt.)

    On the same token, I started using Linux around '96, and at the time, several of us realized that if we wanted corporate America, or our future bosses if you will, to take Linux seriously and consider it as something more than a hacker's toy, that we would have to persuade companies to release/port Linux versions of their software. Well, several of us have worked to do just that; and, with embarrassing regularity, these companies are flooded with emails berating the comanies for not opening the source of the program. This is an area where we should take small steps. We've been able to convince a *few* comanies to port what would be considered desktop-oriented products to what would ordinarily be considered a hacker-oriented/server-oriented operating system. To have them take on, at the same time, an entirely new development strategy would be considered by most to be a foolish business decision. I wish I could remember what company it was, or even what product it was, but I recall an interview with a developer working for a company that had just released a Linux version of their product. The developer made the point of saying, "Don't crucify us for not releasing the source," or something to that effect, stating that it was tough enough to get the pointy-haired management types to do a Linux port. There's a reason he said that.

    And yes, I feel very strongly about the GPL, which is why I bristle every time someone suggests that every piece of software written *has* to be released under the GPL, and that any other license is crap. I personally like the GPL, but I certainly don't advocate GPLing everything. Hey, let's get Visa to GPL their CCN generator code :^)
  • Yeah we really see consumers just flocking for machines that cost more than $5,000 US at the cheapest.

    Are you implying that Sun is doing the wrong thing for not being a consumer oriented business? Why would Sun even *want* consumers to use their products? That's not their business plan.

    -Brent
  • by SurfsUp ( 11523 ) on Wednesday January 26, 2000 @09:43AM (#1334266)
    I don't know how you could consider it not open source; please read the license.

    I misspoke, and I couldn't be more happy to be corrected :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.

    If you have questions about our licensing, please check the FAQ [sgi.com]. It goes into a lot more detail.

    Jon Leech
    OpenGL Group
    SGI


    So it does:

    What's missing from the current Sample Implementation?
    ...Dynamic assembly code generation for rasterization is not yet included, making software rendering performance slow.


    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 :-) Obviously it's in their interest to throw their stuff into the pot if they want to sell cards to 10,000,000 penguinistas.

    Thanks a bunch.

  • >Linux will run on low cost, high powered >hardware. IRIX will (currently) only run on >expensive proprietary SGI boxes.

    I can easily put together a set of requirements that would force a Linux-based system to cost more than the "equivalent" SGI box. Real-time image processing on a video stream is one example: an R5000 O2 can do a lot in that regime (for tiny money); I don't know how you'd build the Linux box to do the same thing (assuming PC components).


    I appologize, I was speaking strictly from the view of someone who uses computers to create 2D and 3D art assets for both realtime and prerendered animations. For the work I do I can easily grab a bunch of off the shelf components (motherboard, 2 PIIIs or Athlons, GeForce Quadro, SCSI card, SCSI drive, etc...) and build a box that would have a lot of bang/buck under either Linux or NT. It will be a heck of a lot cheaper than an Oxygen and it will do the job just as well.


  • Did you figure in the cost of gigabit ethernet and the switches to go with it? I wouldn't even consider doing a large render on 100bt.
    For more money you have one single box. Ask pixar why they used 14 sun boxes and not a fleet of cheap PC's.


    Pixar used many more than 14 Sun boxes. And you know why they chose Sun boxes with slower processors? It wasn't $/cycle or anything as traditional as that. They used a measurement of cycles/square foot. Since those Sun boxes are flat they could get many many more of them in the space they had for their renderfarm. Mac, SGIs, Alpha, and Intel boxes were out because they couldn't get enough of them in the room.

    But what Pixar does is -orders- of magnitude more complex than the work a team of 5 artists does for a computer game. So, no, I didn't figure in the cost of a bunch of networking equipment that wouldn't benefit us greatly.


  • Seti doesn't even come close to using the FPU to the extent that a 3D rendering program will. Using Seti as some sort of contrived benchmark for -anything- is ridiculous in the extreme.

    Sure one MIPS processor of a given mHz might outperform the same PIII at the same speed, but for the same money I can get a room full of PIIIs and have a very fast renderfarm. So what if an SGI can do 1 frame faster than my PIII. With the distributed renderfarm at the same $ I can have the entire animation done much much faster.

    Plus I don't have to have yearly maintenance contracts for hardware and overpriced software that make the TCO of the machine much larger than it should be.
  • I'm not going to go into the issue of the rating system here at slashdot. I don't really care what they rated my post. in fact, I didn't post to get a rating - I simply posted just to share my views of how I saw things from the inside.

    ok - you have more years at sgi than I do. great. have you not read the .ba postings while you were there? or, were we reading different .ba groups?? the one that _I_ read had lots of disgust/mistrust toward management. when they effectively cut MIPS loose there was sore feelings all around. but they DID cut it loose, for all practical purposes. in fact, when I was on the first floor and they were on the 2nd, you needed a special keycard to get into their space and vice versa. that is a SURE sign that the two had parted company. they had their own network, mostly separate from ours, etc, etc.

    for the record, I have nothing bad to say about the MIPS technology, let me make that very clear. I loved their chips and designs. but business-wise, sgi and mips were just not meant to be with each other for the long run. "IA64 this and IA64 that, and microsoft for the other" was all I heard. "dump IRIX from the desktop and replace the whole shooting match with NT". we were staffing up to train our ops guys in NT and were de-emphasizing IRIX on the desktop big-time. I saw this first-hand - this wasn't just a rumor.

    if you've been at sgi as long as you have, surely you know that their business direction (in the last few years) changes like the wind. so there's no basis in betting the farm on what they are currently preaching.

    as to your comment 2 years at SGI doesn't give everyone insight into it's future, my reply is: how long does it take to see that staying there was a losing proposition? about 3/4 of the folks I knew when I was there had all left. perhaps even the top 3/4 of the company, talen-wise, if I may be so bold...

    --

  • If you don't like the patent infringment-stories.
    Turn them off :)
    After all, you decide what is shown on your
    personal Slashdot-page.
    This is what dynamic websites are all about
  • Actually what we really need is a command-line Lightwave *renderer* ported to Linux. Currently we have a several-hundred machine renderfarm and are forced to run NT on this just so it can render Lightwave. All other software of interest would work on Linux (mostly RenderMan and in-house stuff). Linux occupies about 1/10th the memory (because it is not running X) and the NFS performance is far better, and the filenames can be the same on all machines, thus making a huge win for us if we could use Linux. But NewTek definately has said they will not do this.

    It does seem odd that NewTek, once huge proponents of the Amiga, now refuse to consider alternative systems...

  • Most 'professional' places have sys admins. A free OS makes 'turnkey' a unique proposition as well, no? As for 'professional' support, you've been able to get that for a long time (even before SGI, IBM, VA, or Redhat came along). Your arguments are nonsense.


    They are prefectly valid arguments. In my experience there's not been a professional unix admin in most small scale digital design houses. As far as a free os making turnkey a unique proposition, well that's ludicrous. It's impossible to pair up your average linux dist with any particular machine and have it "just work" with the full feature set. Support is more than paying some consultant to come and do backups and installs and kluge some scripts together. Support at this level is when someone guarantees that their product will work and when there are problems they are willing to put a man in your shop in less than 24 hours to make it work again.

    Have you seen the amount of work SGI and IBM have been putting into Linux lately? You completely miss the point ...


    No I don't miss the point. I'm seeing one large company that is putting capital into research. I see another company looking for a way off the sinking ship. When the big names are putting as much into Linux as they are into their flagship products, then we'll re-assess the support situation.

    Different opinions I guess.
  • [...] and linux clusters can be built that outperform the o2000 line for a fraction of the price

    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.

  • 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).

    An open-source alternative to Inventor is Quesa [quesa.org]. Quesa implements the Quickdraw 3D API, which includes a nice hierarchical scene system.

  • by Otis_INF ( 130595 ) on Wednesday January 26, 2000 @10:26AM (#1334280) Homepage
    OpenGL is WAY easier to use then D3D.
    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.

    ... 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
    I can only laugh about this. :) 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. :(

    Take care...
    DemoGL [www.sd.nl] main developer. DemoGL is a win32/OpenGL multimedia library.
  • Indeed. Microsoft bought Softimage, made them port their software to NT, and then sold the company to Avid, which is its currewnt owner.

  • Nvidia stuff sucks under linux. It sucks pretty badly.
  • I heartily agree. My brother-in-law is running Lightwave 5.6 and Maya 2.5 on his NT box because the SGI/IRIX boxes were too expensive. Both packages are great (credit to the software not NT). He used to be a diehard MAC fan but now uses whatever works best for the money. The SGI boxes they used to demo Maya are great but I don't that kind of cash at this moment. SGI is a great company and I believe they are/will be a great asset to the Linux community.
  • 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.
  • Glide 2/3 != OpenGL (in the case of 3Dfx)

    I'm not sure about nVidia. Glide was a proprietary driver from 3Dfx (it's OS now too). But OpenGL was initially drafted as a standard 3D lib. Not quite sure on much of the other details, but simply put, it's a matter of one standard across the board irregardless of whether you've got a TNT or a VooDoo (or whatever).

  • by Anonymous Coward
    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.

  • by nellardo ( 68657 ) on Wednesday January 26, 2000 @06:12AM (#1334288) Homepage Journal

    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:

    • They both draw stuff to the framebuffer, and...
    • GL can cooperate with an X server by using the GLX extension to X. GLX basically moderates contention for the graphics hardware between X and GL.

    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 [linuxcare.com] 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 [siggraph.org] 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.

  • 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?
  • Yes, OpenGL is not a program. It is an API. Forking an API is just as bad as forking the linux kernel(or any OS); It leads to bad things. Mesa and certified OpenGL implementations are in essence two forks of the same API. You may say that the function calls are the same, or the visual effects are the same. But that doesn't matter, there are features Mesa doesn't support. Forking OpenGL would fragment the UNIX graphics community and create havoc for those of us who have real work to do.

    One thing I really like about OpenGL is that there have only been 3 versions. v1.0, v1.1, and v1.2. That makes it pretty easy to pick your applications and your implementations. SGI has done the (TM)"Right Thing" and I believe will lead to a much better, much more compatible Mesa and accelereted OpenGL implementations created by many people.

    Look at the results:
    Companies can now release the source to their Windoze GL implementations, leading to integration of accelerated hardware support possibly being implemented in Mesa. I doubt this will change the OpenGL trademarking or certification procedures, hence Mesa will still not be certified. However, Mesa can finally be really compliant while supporting in a single code tree all hardware whose respective companies choose to release source! A very good thing.
  • You might not agree with me that software rendering is already dead today but what about 1 year from now?
  • Pixar used many more than 14 Sun boxes. And you know why they chose Sun boxes with slower processors? It wasn't $/cycle or anything as traditional as that. They used a measurement of cycles/square foot.

    If that's the case, then wouldn't 1U (unit) rackmounted linux/freeBSD boxes be the trick?

    Most of the SGI stuff can be Rackmounted. The Octanes were great too! (the only thing it was missing was a cdrom drive)

  • Take a newbie and get him started on D3D. Take another newbie and have him use OpenGL. Who will have working code sooner?
    the OpenGL newbie will definitely have a rotating polygon sooner. But that's not the point I was refering to :) You see: perhaps the learning curve of d3d is steeper than OpenGL's, but in the end if you want to program a full application and you need all the API's power to achieve good quality, it takes the same amount of time and effort to get there.

    Once you need to start worrying about Visible Surface Determination, the API isn't the bottleneck: Your culling / occlusion algorithms are, along with state minimization, and texture management. Wouldn't you agree?
    I agree. It's however funny to see people first don't understand statechanges are expensive and visual face determination IS important :). I think that the understanding these things are important is part of the learning process of both api's. The api's both provide different solutions to achieve the same goal, but the goal first has to be determined by the programmer. newbies never get that :)

    For the most part it is. I'm curious, what part of OpenGL isn't orthogonal? For me: display lists: it's a whole bunch of hoopla but no speed increase nowadays, and the global orientation of the code: it's nice to have everything global, but it can also work against you, especially in a OOP environment IMHO.

    MS shoved D3D down our game developer throats whether we wanted it or not. OpenGL works for games, as Carmack has shown us. They already had OpenGL on NT, why did they have to go and FIX ANOTHER API?
    There were numerous api's. Not one was 'major', perhaps Glide was. MS created DX (not only D3D) to provide a uniform layer of abstract code using COM, which was always the same, independant of the underlying hardware. It solved a problem for gameprogrammers: which api would we take? Glide? MeTal? OpenGL? Not one of these was supported by ALL cards. D3D is. For gameprogrammers this was a blessing because they could now focus on 1 API.

    The D3D drivers are very small, because the HW vendor just has to implement the very basic stuff to communicate with the hardware. The rest is already implemented in the HAL. That's why it's easy to provide a good d3d driver, the opengl icd has to contain that HAL AND the HEL and the driver.

    Question: How does a vendor provide extensions in D3D ? Oh wait, they CAN'T, unless they pesister MS to provide it in a future D3D version.
    Afaik, Dx7 also contains an extension mechanism.

    Nice job on DemoGL.
    Thanks!
  • God, I love SGI. I'm glad to see another big company actually put their source code where their mouth is. Sun are you listening?
  • i like sgi, but i don't think they are doing enough to support linux on their machines, no x server for indys, etc.

    they need to make a concerted effort to get more tools ported, too -- maybe even that cvd debugger.

    man i love their hardware, it is always so funny to see the monkeys post about their "750 mhz athlon" -- they have absolutely no clue how wonderful it is to develop under SGI/Irix -- it really makes me cringe to write under linux/pc crapware.

    hope SGI continues to embrace os community.

  • I have heard it said, and I will say it myself, Irix is perhaps the BEST operating system in existence right now.

    Well, I'm definitely in agreement with a qualifier similar to your other comment:

    It is a joy to be a developer on IRIX.

    That's really the key isn't it: development. What people forget that the most expensive resource isn't the computer; it's the developer. Chances are very slim (in today's economy) that, if you're a working developer, you cost your employer less than the computer that you work at. Even better, your fully loaded rate (with overhead, etc.) is likely several times higher than an amortized billing / lease rate for your machine.

    In short, it makes economic sense to pick the tools that make your (expensive!) workers most effective. In my case, I've been working with UNIX (and other OSes) for about 20 years; I find IRIX to be the best all-around package. Then there's the real-time capabilities: nanosecond-level real-time clocks, anyone?

    On the other hand, for those running render farms (batch processing of animations), they need cheap cycles, so they don't really care about "development." To my mind, they shouldn't be buying computers at all, they should be renting the cycles. That sort of drives down your "total cost of ownership...". ;-)

    My favorite comments, though, are when person P says something along the lines of "application X isn't supported on IRIX, so it sucks and is dying off" (e.g., Multigen Creator).

    Well, if application X is a requirement right now, it's a requirement; choose a supported a platform and get to work. Note, however, that a lot of those types of applications are also not supported on Linux. Well, P, by the transitive property, you're saying that Linux sucks and is dying off, too. Are you sure you want to say that? Here? Go on, I dare you.... ;-)
  • by Faw ( 33935 ) on Wednesday January 26, 2000 @05:37AM (#1334299)
    What will happen to Mesa now? Who will assimilate who?
  • You can bet that once people improve it, SGI will take those improvments and roll them back into their own products.

    Something tells me that is the whole point of Open Source. To benefit from open source development. Or did I miss something?

    -Brent
  • by Anonymous Coward
    This is probably good news, but why should the community mess around trying to make SGI's outdated proprietary software work for them? Forget OpenGL, we need to develop a fully open set of drivers, so that the community can continue to develop good applications and games without the intrinsic restrictions of the form. I say we need to start a FreeOpenGL project -- I'd volunteer to lead it, but have neither the time nor (probably) the ability. Will someone else pick up the baton?
  • The Sun boxes are -flat-, like pizza box dimension flat. Can you get rack mount chassis that hold PIIIs or Athlons (with their annoying propensity to want to sit perpendicular to the motherboard) that are that thin? I honestly don't know, but I don't think it's possible due to the Slot1 layout.

    The newer flat PIIIs might work better, but those weren't available when Pixar was working on TS2.


  • ...cheaper than an Oxygen...


    I meant Octane. (must not type late at night...)

  • by RelliK ( 4466 ) on Wednesday January 26, 2000 @05:39AM (#1334306)
    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)
    ___
  • Check news.com. Apparently, they released the code today.

    I know that. However I was replying to a post that seemed to imply that Sun was solving the wrong problem because consumers didn't want > $5000 computers.

    I am asking why do you think that Sun would even want consumers to use their computers. That's not what their computers are being made for. Sun has no problems with the fact that little old ladies aren't using Solaris to read their e-mail. That has nothing to do with source, or cost, or anything, really. Just that Sun exists to solve a different problem.

    -Brent
  • Are you implying that SGI currently sells hardware aimed at little old e-mail checking ladies? I know they DO plan on lightening their systems a little, but the average HOME is still not their target market.

    No, not Sun, not SGI either are in the business of consumer devices.

    -Brent
  • Of course they will. That's how Open Source works, does it not? The catch is, however, that they cannot close the source once it's open. So, even if they do sell it, we can still get ahold of the code for free :)

    Besides, they will likely be giving as good as they get. IRIX is a very high end system, and it would be cool to have some of those features released for Linux (such as xfs, for beginners. In fact, they already have a sample code release for it). SGI has to move towards the low-end because that's where most people are going. Movie studios, for instance, are beginning to favor farms of Linux boxen to render films as opposed to just one big-ass server.

  • >> OpenGL is WAY easier to use then D3D.
    >This is of course very dependant on your skills in the area of the API.
    Take a newbie and get him started on D3D.
    Take another newbie and have him use OpenGL.
    Who will have working code sooner?

    Granted, once you understand the 3d pipeline, moving to another API is not too difficult.


    > If you don't get Binary Objects, if you don't understand OO, you'll NEVER understand D3D. Everyone can cook up a spinning cube,
    Seems like OpenGL is easier to learn then? ;-)

    > not everyone can cook up a 10,000 poly world running at decent framespeeds with a lot of different textures.
    Once you need to start worrying about Visible Surface Determination, the API isn't the bottleneck: Your culling / occlusion algorithms are, along with state minimization, and texture management. Wouldn't you agree?


    > Some things are odd in OpenGL, I wouldn't call it orthogonal :)
    For the most part it is. I'm curious, what part of OpenGL isn't orthogonal?
    Last time I read the spec, I didn't see any discretions. Maybe Jon Leech can point out a few?


    > Feature complete is somehow a bit stupid here.
    Compared to cap-bits?! Capability bits break when you have 2 mutual exclusive features. No thanks. Of the 2 methods, I'll take (slow) feature complete, over missing features. Its the best of worst worlds.

    Let's not forgot "feature complete" and cap-bits, do not tell you how FAST something is implemented. Remember, some people prefer quality, others prefer framerate. Feature complete or cap-bits doesn't answer those 2 scenarios. At least your game will visually look the same on different hardware (assuming the drivers aren't broken.)


    > It's however IMHO not correct to say: D3D is crap because they had a lot of versions in a short time. That's BECAUSE it's new.
    So you're telling me that you still want to use executive buffers from DX3 ? I don't see them in DX7 ! D3D is already 5 years old, thats not new.


    >> Thats because Microsoft IS so bull-headed after buying Direct3D from Rendermorphics
    > I can only laugh about this. :) Man, do you really believe this is the issue?

    MS shoved D3D down our game developer throats whether we wanted it or not. OpenGL works for games, as Carmack has shown us. They already had OpenGL on NT, why did they have to go and FIX ANOTHER API?


    > 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.

    I can't comment on this having never seen any d3d driver code. I'm not a driver writer, just a game developer. Have you seen any d3d driver code?


    Ok, I'll buy the bit where OpenGL drivers are harder to develop then D3D drivers.


    > It's however a shame not all of those cardmakers include all the new HW features in the ICD via extensions as nVidia does

    That's for sure.

    Question: How does a vendor provide extensions in D3D ? Oh wait, they CAN'T, unless they pesister MS to provide it in a future D3D version.


    Nice job on DemoGL.

    Cheers
  • Are you implying that SGI currently sells hardware aimed at little old e-mail checking ladies? I know they DO plan on lightening their systems a little, but the average HOME is still not their target market.
  • This is how I think it works...now this is just a buddy and me asking ourselves how would we do this. But here goes....As I read it, this is a software rendered OpenGL implementation without some of the software optimizers. However you take this piece combine it with the specs of what your particular card can do in hardware...and doing alot of coding...and you end up with a hardware-accelerated OpenGL driver for whatever card you were working with.

    Am I even close?
  • by cpytel ( 89261 ) on Wednesday January 26, 2000 @05:43AM (#1334314) Homepage
    Be sure to take a look at the Project List page at oss.sgi.com, some interesting stuff is listed there.
  • No, there hasn't been any word as far as I know. However, it has been discussed and so far everyone seems to think it's a reasonable idea. Who knows maybe it will even happen someday. Personally, I'd like to see all our scene graphs go to open source.
  • What was this Simple Implementation before it was open source? Was this something they sold to the commercial apps before? Has anyone gone to look at the code to see what this actually is?

    I agree it's a step towards full open source, but I wonder if it's not just a baby step.

    J.
  • What are the "intrinsic restrictions" of OpenGL? I seem to have missed something.
    --
  • Oh man, I almost crapped myself when I read that. I was like "Portman? What does he mean by that?" Then the light dawned on me and I laughed myself silly. Even though you're a troll, thanks.

    -----------

    "You can't shake the Devil's hand and say you're only kidding."

  • DirectX/Direct3D isn't portable.

    OpenGL is available on almost all major/minor platforms. For starters: Win, Mac, Linux, Be, etc.


    First glQuake, now OpenGL source. Its a good year to be a 3d programmer.
  • Does this mean we'll FINALLY see an OpenGL driver for 3Dfx cards?

    No flames, but the OpenGL driver has been in beta now, for what, a year?

    Cheers
  • First, I'm not familiar with the differences between Mesa and OpenGL.
    Now I'm wondering, if they are thinking about merging both sources, is there any chance that what's different in Mesa could influence OpenGL's specification?
  • OpenInventor is no longer sgi's. I believe it now belongs to them [tgs.com].
  • You'll never see Lightwave ported to Linux. The company (not the developers) seem to be vehemently opposed to it for some reason. (Alan and Stuart on the other hand have repeatedly said that supporting new architectures/OS's is a matter of a day or two's work porting over the interface/framework code and then running make.) Since NewTek currently has SGI, Mac and Sun ports of Lightwave, one would assume that if you could convince them that the Linux market was larger than the SGI/Sun combined, they might think about it, but don't hold your breath. (Especially since they've outsourced the SGI, Mac and Sun ports to other companies who actually do the porting and support, which is why the non-NT versions are usually a couple of revs behind the NT version.) I've actually spoken with NewTek management about sponsoring a Linux port and gotten nowhere, despite they're having said publically that "if someone can present us with a viable business plan for producing a port of the program, we'll give them the code."

    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.

    -=-=-=-=-

  • > Not one of these was supported by ALL cards. D3D is.

    I don't see D3D drivers for our $10,000 video cards. I see OpenGL drivers, but no D3D.


    > For gameprogrammers this was a blessing because they could now focus on 1 API.

    You've never done any ports, have you? ;-)

    D3D is not available on consoles. That's a BIG chuck on the games industry right there !

    Use D3D and you're LOCKED into Windows. That's a curse, not a blessing. I'd rather use an API that lets our games be developed on several platforms.

    OpenGL is portable among Win, Linux, Mac, even to a degree on N64.

    What did Carmack say, how many lines of code was different for Quake3? 18K ?


    > For me: display lists: it's a whole bunch of hoopla but no speed increase nowadays

    I can see you've also never used the high-end SGI's. Display lists were faster, since the geometry had to be static.

    But you're right, today on PC's display lists show no gain, due to bandwidth bottlenecks.

    Cheers
  • This is actually a very insightful take on SGI's current strategy.

    Thanks, I like pretending I know what I'm talking about.... ;-)

    The "NT mindshare" question is an interesting one, as is the "move." As far as I can tell, smart folks are thinking "we want to move away from HP (or VAX or whatever) hardware to something that's more commercial / consumer grade." The smart ones are not saying, "NT is better than UNIX." They just haven't had a viable choice up until now (remember, all decisions must be defensible).

    I am literally watching government project managers changing their minds and saying, "No, we've decided to go with Linux rather than NT on our PC-based-replacement for legacy hardware. Why? Because it's X-Windows, Unix-ish, etc., and thus has lower risk than MFC-ing, NutCrackering or Java-ing our code." We're seeing the NT "pull" evaporate; as far as I can tell, the only "push" left is inertia (of which the government has a lot).

    Two somewhat related items:

    1. I'd seen several remarks implying that SGI hardware rules SETI but might have limited utility elsewhere. I think we've agreed that if something is in use (and has strong advocates), it's gotta have measurable utility.

    However, I'd never tried the SETI work units on my R12000 at work. Given that some benchmarks indicate that Pentium III-based machines are right on top of SGI performance (e.g., CPU95 at www.spec.org), I thought it'd be interesting to try a "real" cross-platform application (remember, your mileage may vary; chances are slim that your full-time employment is as a SETI scientist...):

    3 h 27 m: PIII 500 Mhz Wintendo98 = 4%
    16 h 22 m: PMMX 233 Mhz WinNT = 58%
    3 h 27 m: R12K 300 Mhz Irix 6.5 = 100%

    Swell, the R12000 does great FFTs, what's the point? The thing is, that's the kind of thing I do: lots of real-time floating point. More importantly, we're not talking about a few percent; this is a different order of magnitude! For completeness, compare the price on a Dell workstation (as tested for SPEC) to a single R12K SGI Octane. The SGI will likely be more but not by an order of magnitude....

    2. In terms of "pennywise", I've started pushing for the idea that if we developers are willing to have less people (at hiring time, not layoffs!), the management should reinvest that "savings" into our infrastructure. Salary + benefits + overhead comes to quite a lot in today's economy. Split between a group of 3-4 developers, it can buy lots and lots of toys ... I mean "tools"! ;-) Seriously, though, that's also an annual savings; keep that infrastructure up to date.

    I've actually started using it as a metric for employment; if your PHBs just pocket the money, you know it's time to look for another job.
  • My favorite comments, though, are when person P says something along the lines of "application X isn't supported on IRIX, so it sucks and is dying off" (e.g., Multigen Creator).

    Well, if application X is a requirement right now, it's a requirement; choose a supported a platform and get to work.


    Which was my point in the other part of this discussion (which I think you are refering to). The question I was answering was not about MIPS, but about the previous poster's (in that branch of this discussion) query as to why anyone would consider art asset creation on NT boxes.

    We had SGIs. They were expensive to buy, expensive to own, and had very expensive software with expensive yearly support contracts. Then those application developers started making their software for NT (many times devoting their resources to the NT version before the IRIX version). Suddenly being on IRIX wasn't very useful. Moving to NT got us the better software, at better prices, and with lower $/machine. We went where the tools we needed were.

    Now, IRIX might not be "dying", but a lack of applications on any given platform is usually not a good portent for the continuing viability of that platform.

    Note, however, that a lot of those types of applications are also not supported on Linux. Well, P, by the transitive property, you're saying that Linux sucks and is dying off, too. Are you sure you want to say that? Here? Go on, I dare you.... ;-)


    I never infered that Linux sucks. It most definately doesn't. I've already asked numerous people at MultiGen if they are considering a Linux port of Creator and if so, when. We moved from IRIX to NT because that was where the tools we needed were and the hardware was much less expensive. We'll move again if there is sufficient reason (i.e. needed applications exist there and the hardware won't bankrupt us) to do so.

    Comparing Linux to IRIX (or saying that I'm infering that Linux sucks because of a lack of certain applications) in the context of this discussion isn't really valid. Linux will run on low cost, high powered hardware. IRIX will (currently) only run on expensive proprietary SGI boxes. If the choice came down to Linux on Intel or IRIX on MIPs, all other things being equal, we'd take the Linux route because it would be a better use of our $.


  • Halting the 320 & 540 was the best decision SGI made in relation to the whole NT thing.

    Sad to say, I have to agree with you. I loved the 320; I came close to buying one for my home (and cash flow is tight with another kidling on the way). At the same time, I need SGI to stay in business; they're still making the best tools for my work. If SGI can manage to make something much like the 320/540 but is commercially viable over the long haul and runs all my favorite applications (!), I'm there.

    Re: MIPS = dead: somebody's confused. MIPS makes the most popular embedded processor in the world. Period. Maybe User X (who may or may not have worked for SGI in the past) doesn't do floating point calcs anymore, but 3.5 hours for a SETI work unit is a serious motivator in my business. Signal processing and visualization at the same time?! ;-)

    BTW, when I heard about the "SGI is a UNIX company = Linux + IRIX" press release, my first response was, "Now there's a ballsy decision." I still feel it was the right move (and I wish I had had serious money to buy SGI when it was at $6 per share).

    PS: Let me know if SGI could use any east coast industry-advocates. I accept payment in cool t-shirts.... ;-)

    [An early 1990s beta-tester for Crimson, Irix 5.0a, Delta C++, etc.]
  • This is definitely an interesting development and quite unexpected. Once again, I applaud SGI for grabbing the bull by the horns and making a difference.

    Now what I'd like to know is what's going on as far as SGI/Linux graphics machines go - you see, I have this old PC I'd love to upgrade soon :-)

    From what I gather, it appears that SGI might be asking VA Linux to build the systems using Nvidia graphics hardware and, probably, an SGI openGL subsystem.

    May I also make a suggestion that SGI consider what to do about the other multimedia API's they own - video and audio in particular. Although I cannot expect PC hardware to easily support an API like SGI's libvl, SGI should perhaps look to support this on hardware they build (or have built). What's the chance of ever seeing something like OpenVL and/or OpenAL?

    After all, once XFS (and hopefully XLV) is ported, we'll need something substantial to thrash those disks - what's better than D1 video?

    Keep up the great work!

    Alastair

  • 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.

    --
  • Check this out

    Coin [coin3d.org]
  • It'll take a while. Renderers maybe, but before we see the complete apps being ported over we'll to see more graphic software companies stating plans to port their goods, as well. Take Photoshop & Illustrator for two. Premiere, for three. Those all go hand in hand with Lightwave or any other 3D package, and they'ed be not useless, but not extremely useful, without the side programs.
  • Does Microsoft invent ANYTHING>?? Or at least develop it themselves??
    At this list [vcnet.com] there is a list of all the products and companies that MS has purchased rather than just imitating, and practically every single thing they own is on that list. Such 'innovation'!

    Also, the sheer amount of things listed in the '99 secion there is truly disturbing.
  • 90% of people who use SGI workstations are potentially interested in Lightwave.

    Probably about the same of Sun's workstations.

    Their more competition in the low-end space on Macs, so probably only 10% of G3 and G4 (not iMac) owners would be interested in lightwave. They make that up with volume.

    How many Linux users use 3D software in Linux everyday? Probably about zero. How many will spend $1500 for a 3D package? probably not many, either. If New-Tek starts getting letters from people who are already customers requesting Linux ports, they'll probably do it. But if they get 10,000 letters from slashdot readers, that's still not 1 firm commitment to buy. It's just lots of linux advocates. If they needed or wanted Lightwave, they'ed have swallowed their Linux pride and purchased an ample machine running Solaris, Irix, NT, Mac OS, or an old Amiga for that matter.

    Yes, there's lots of linux machines out there. But lots are completely incapable of running lightwave. And all the capable ones are acting as servers or developers workstations.

    If you said that the market for Lightwave was larger for Linux than SGI/Sun combined, they could easily turn and call you a liar. No offense.

    About the best you could do is go buy a real copy of lightwave and then maybe return it as a symbolic gesture that you actually do have the money to spend if they bring the product over. But don't count on it.
  • by joss ( 1346 ) on Wednesday January 26, 2000 @06:44AM (#1334341) Homepage
    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).
  • I bought an Indy hoping to run Linux on it. Linux on MIPS hardware doesn't even run X-Windows. I'd be really happy if this support for hardware OpenGL is extended to the Indy. Then maybe I'll have X-Windows on it! Of course I doubt I'll ever see that. The last status update for the project on SGI's web site is almost a year old.
  • Nvidia, yes. Glide isn't really OpenGL. And as for the "other 3d cards", well keep dreaming. Unless something new has happened recently there are only 3 companies that have cards capable of doing OpenGL under Linux.

    -----------

    "You can't shake the Devil's hand and say you're only kidding."

  • > Move over SGI graphics workstations, Linux is here.

    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.

  • Oops. The last one is $4995 too. My bad.
  • 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 think you're reading way too much into this release. All those graphics cards out there that didn't have support under Linux for OpenGL *still* don't have support under Linux for OpenGL. So, as far as your screensaver goes, you can still do it of course, but it's not going to run much faster than if you did it with Mesa.

    -----------

    "You can't shake the Devil's hand and say you're only kidding."

  • by Oddhack ( 18073 ) on Wednesday January 26, 2000 @07:50AM (#1334363) Homepage
    What will happen to Mesa now? Who will assimilate who?

    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.
  • by davemc ( 16393 ) on Wednesday January 26, 2000 @07:54AM (#1334370) Homepage

    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. [sgi.com]

    Dave McAllister

  • by Oddhack ( 18073 ) on Wednesday January 26, 2000 @08:02AM (#1334371) Homepage
    However, I notice that the terms of the release are defined as "Sample Implementation." What does this mean? Is this a less-than-full release? Do we have all of the source, or just part of it?

    "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

  • by Oddhack ( 18073 ) on Wednesday January 26, 2000 @08:09AM (#1334373) Homepage

    I don't know how you could consider it not open source; please read the license [sgi.com].

    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 [sgi.com]. 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?
  • by SurfsUp ( 11523 ) on Wednesday January 26, 2000 @07:03AM (#1334386)
    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.
  • by sterwill ( 972 ) on Wednesday January 26, 2000 @08:37AM (#1334396) Homepage
    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?

    --
  • by UnknownSoldier ( 67820 ) on Wednesday January 26, 2000 @08:45AM (#1334400)
    > i heard that developers of 3D visual apps like

    > 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.


    > ... 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.


    > 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 [vcnet.com]

    Cheers

    3D Game Programmer
  • by Anonymous Coward on Wednesday January 26, 2000 @05:47AM (#1334404)
    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 [nportman.com] 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?
  • They have an answer for your speculations in their FAQ [sgi.com]. For example: 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.

    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.
  • by worth ( 132011 ) on Wednesday January 26, 2000 @05:51AM (#1334414)
    You can find more information about this here [sgi.com] on SGI's OpenGL Sample Implementation. The frequently asked questions are available here [sgi.com].

    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. :)
  • Extract from an SGI news [sgi.com] : --- 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,
  • 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.
  • by Col. Panic ( 90528 ) on Wednesday January 26, 2000 @05:54AM (#1334440) Homepage Journal
    A big thank you to SGI for their kernel patches [sgi.com].
  • by Dalroth ( 85450 ) on Wednesday January 26, 2000 @05:54AM (#1334442) Homepage Journal
    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 [sgi.com], it mentions that this implementation is going to be released under SGI's Free Software License B.
  • by Thrakkerzog ( 7580 ) on Wednesday January 26, 2000 @09:05AM (#1334449)
    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.)
  • rc5 uses very little if any FPU. In fact x86 and PowerPC cpus are better for rc5 than MIPS. From The distributed.net RC5-64 FAQ [distributed.net]


    Why are Intel and PowerPC computers so much faster than other platforms?

    Integral to the mathematics of the RC5 algorithm are 32-bit rotate operations. For whatever reason, the designers of the x86 and the PowerPC architectures decided to implement the rotate function as a hardware instruction. Many other CPUs do not have built-in hardware rotate instructions and must emulate the operation by (at the very least) two shifts and a logical OR. This handicap is why many non-Intel and non-PowerPC computers run RC5 slower than one might expect based on real-world benchmarks. It is also the main reason why the RC5 clients are a poor benchmark to use in determining the speed or performance of a particular CPU.


    Why isn't my computer with an FPU faster than mycomputer without one?

    RC5 involves a large number of integer additions, rotates and XORs. It doesn't require floating point calculations and won't, in general, benefit from them. There has been quite a lot of recent discussion on whether or not it might be possible to boost keyrates (on x86 architectures at least) by taking advantage of the fact that there are separate pipelines for integer and floating point instructions. (We leave it to the reader to figure out how to do floating-point XORs and rotates!)

    Currently none of the Bovine clients attempt to make use of FPUs and we believe any use of the FPU will result in slower clients rather than faster ones. At least one bright person has suggested this is notnecessarily the case and indeed he may be right. If anyone can develop an RC5-64 core that takes advantage of the x86 FPU for an overall client speed boost we would be very interested in hearing from them! If you are interested in looking into it the x86 core code is available and can be downloaded from http://www.distributed.net/source/.


    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.
    --
  • by dlc ( 41988 )

    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 agree--perhaps the patent infringement stuff could be its own section? there's definitely enough of it.

  • DIE SOUP NAZI!!!!!!!!!!!!!

    *stops giggling...wipes eyes..takes breath*

    Seriously, the GPL is far too limiting. 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!"

    Quite frankly, the developers and proponents of open-sourcing commercial software, many of which probably worked hard to get a restrictive license put on the software, will just become alienated and never push again.

    And, besides, the GPL doesn't give freedom. It takes it away.
  • by Hoonis ( 20223 ) on Wednesday January 26, 2000 @05:57AM (#1334464) Homepage
    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?
  • by Anonymous Coward
    This isn't a first for SGI - look at libtiff (IIRC). Look at the STL bundled with gcc.

    This is interesting none-the-less.

  • by TheGratefulNet ( 143330 ) on Wednesday January 26, 2000 @05:58AM (#1334467)

    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).

    --

  • by worth ( 132011 ) on Wednesday January 26, 2000 @06:02AM (#1334468)
    Well, Mesa is not really 100% OpenGL 1.2 compliant. If you read the frequently asked questions [sgi.com] you will notice that they are talking about the possibility of merging Mesa with their Sample Implementation. I think this would be a very good thing--It would make a fully compliant implementation, while maintaing the good parts from Mesa.

Keep your boss's boss off your boss's back.

Working...