Slashdot is powered by your submissions, so send in your scoop

 


Forgot your password?
Close
typodupeerror
×
Silicon Graphics

SGI and Mesa on Linux/OpenGL Base 62

Posted by CmdrTaco from the aint-that-spiffy dept.
An anonymous reader sent us an interesting linke over to SGI on their new Linux/OpenGL Base. Its a project to standardize OpenGL on Linux, but Mesa Compatibility is actually part of the plan. Nice strong Linux push for one of SGIs most important technologies. Very cool. Also, but not linux related, is their new Reality Center. Dibs on one of those "Walls".
This discussion has been archived. No new comments can be posted.

SGI and Mesa on Linux/OpenGL Base More

SGI and Mesa on Linux/OpenGL Base

Comments Filter:
  • XiG and MetroX may not be interested in doing their stuff for anything other than Linux- but I know that the GLX acceleration project has at least one FreeBSD person working on the Matrox G200 support for *BSD.

    No worry about FreeBSD. The Mesa/Glide combination has been in the ports collection for some time now, and we have the glx from openprojects.net working too, yielding accelerated 3d for Matrox G200/G400 and nvidia RIVA128/128ZX/TNT/TNT2 etc.
    Grab it here:

    http://www.freebsd.org/~3d/distfiles/glx [freebsd.org]

    The Direct Rendering Infrastructure for the upcoming XFree86 4 release will get ported to FreeBSD too.

    And theres is more. Please subscribe to

    freebsd-multimedia@freebsd.org [freebsd.org]

    to participate in the discussion of this exciting subject or send me an e-mail to 3d@freebsd.org [mailto] if you have any questions left.

    Add to that support for the Matrox G400, NVidia TNT2, ,,

    See my comment above, on how to get it. Please use it and help testing!

    .. and several others I'm not quite yet at liberty to mention (Work on these chips have just begun, and I don't want to get false hopes up!)- all with open source code and no black magic that would keep someone from implementing it under *BSD, etc. under any chipset that will work with an adapter.

    Bet on it. If the information get freed it is just a matter of time that it will be implemented.

  • Re:Standards help everybody ... (Score:3)

    by LL ( 20038 ) on Wednesday September 08, 1999 @08:05AM (#1695210)
    Lupulack [slashdot.org] wrote


    This is EXACTLY what most GNU / Open source advocates are looking for. Here's a software standard that makes software easier to write. Who cares what OS / Hardware you're writing for? It's all a standard, just re-compile for the other platform.

    Yes but who gets to define the standards?


    My general observation of the computer industry suggests there are several variants of what are commonly called "standards" (oh and toss in the word open somewhere to really confuse matters).

    - evolved standards, resulting from a bunch of people trying to solve a specific problem and iterating towards a solution (e.g. Gl->OpenGL->Web3D?)

    - committee standards, a technical specification agreed ahead of time (e.g. Fortran, IETF, W3C sorta)

    - defacto standard, an implementation that so completely fills a role/niche that it is universally adopted (e.g. NFS)

    - imposed specifications, a base implementation released and through fortunate timing or market dominance, is defined as a standard for conformance

    The problem is that it is extremely hard to create universal standards that work well the FIRST time. Usually at least two or more implementations hitting real-world bottlenecks are necessary to define a flexible standard that covers enough variances of the problem space for it to be widely adopted. Plus major issues in allowing it to evolve over time without any preconception of future technologies (witness Fortran 66, 77, 8x, 90, 95, etc). This learning curve puts a serious crimp on progress, especially as the hardware tech evolves faster than software development.

    Anything that gives CHOICES is OK in my book ...
    I would qualify this by observing that it takes bloody-mindedness and sheer Machiavellian talent to get any largeish group with a multitude of self-interests to adopt a common code of practice (see legal conformance or tussels with metric/imperial measurements). Choice of standards that have no external force or non-biased referee insisting on interoperability leads to fragmentation and slower adoption. Combined with the pressures of commercialisation and the prospect of dominating a profitable market, good technical standards can often be distorted, subsumed or replaced by plurity of suboptimal choices.


    As they say, standards are good, lets have lots of them.


    LL

  • i'm gonna withhold my happy dance until SGI agrees to port Alias and their other tools to linux instead of just using linux boxen for rendering

    For my part I would be already glad, if they would open up their electropaint screen saver sources. :)

    Fun aside, please remember that SGI is undergoing a big change. Having a Silicon Graphics workstation has been a bit like having a Mercedes-Benz car. This was very capable (not always the fastest, but always with stunning graphics and that special flair) and expensive hardware, and the software was not what a PC user would call cheap either.

    So they need to make the transition from relativly low volume/high priced to high volume/low priced.

    Once the demand is there, the software will follow. In some months from now we have really powerful 3d on the free operating systems, people will take it seriously and consider using these platforms for serious work, asking for serious tools. It will happen.

  • Quake 2 is a pretty good example ;).

    CC
  • (..) evolved standards, resulting from a bunch of people trying to solve a specific problem and iterating towards a solution (e.g. Gl->OpenGL->Web3D?) (..)

    Web3D? You should have a look here:

    http://gel.urstudios.com/ [urstudios.com]

    The problem is that it is extremely hard to create universal standards that work well the FIRST time. Usually at least two or more implementations hitting real-world bottlenecks are necessary to define a flexible standard that covers enough variances of the problem space for it to be widely adopted. Plus major issues in allowing it to evolve over time without any preconception of future technologies (witness Fortran 66, 77, 8x, 90, 95, etc). This learning curve puts a serious crimp on progress, especially as the hardware tech evolves faster than software development.

    Well spoken. It might interest you folks that one of the main developers behind Direct3d has another 3d API out of the door that is a nice C++ library for Win32 and Unix:

    QDraw [calcaphon.com]

    It will be used for the above mentioned Web3D format. Works very nice under FreeBSD. Alas I recommend hardware 3d acceleration (I use a TNT) for some of the samples. Backends are OpenGL and our special friend aalib!

  • I see this as a good thing for Linux. Means that hopefully they will moake ports of the rest of there stuf that uses OpenGL to Linux too. I hope that this is not just a promise and they follow thru.

    We owe much to id Software, without them OpenGL would have not been established widely on Win32. Now they have OpenGL, we have OpenGL and game publishers and other software companies will have it easier than ever to create powerful applications for both platforms.

    Further it is a joy to have John Carmack working on the open glx Matrox driver. This guy is dedicated to the subject and certainly not only money driven.

    Linux is uniting *NIXes. Solaris and FreeBSD already have the means to run some Linux programs, this makes Linux binaries "almost" a default format.

    Well, as a former OS/2 user I have very mixed feeling on this subject, as OS/2 emulation for Win16 was so good that nearly no native app was created, in the end the death for that operating system.

    FreeBSD's Linux emulation is very good. So you can run Netscape, RealAudio Player,Myth2 demo, Quake3 under that emulation layer. Like in the case of OS/2, Linux apps might actually run better under FreeBSD in some regards. You even get the same Linux headaches (like clib/glib madness) under the emulation. :-)

    However it is just an option and not the native ABI and we will strive to keep porting and developing for FreeBSD. So we have native hardware acclerated XFree86 (2d) and Mesa (3d) versions and apps.

    Drop me a mail at 3d@freebsd.org [mailto] if you need more information.

  • The hairy issues where Linux and FreeBSD differ are hidden somewhere in XFree86. Porting Mesa is relativley easy. Next tougher job will be providing FreeBSD kernel support for DRI and here a member from the FreeBSD core team has already indicated interest so that I have no doubt that it will get ported timely.

    Of course the basic idea of the effort mentioned in this Slashdot article, interchangeability of OpenGL libs is important for FreeBSD as well, and we will try to find an appropriate solution and join discussion. Maybe it will differ in some aspects (our shared lib versioning scheme is different than the one from Linux, so we might not be able to use a solution one to one) but I believe it will not be too far from it away.

  • is there any pc hardware that takes advantage
    of opengls 2d accelleration (glDrawPixels etc)
    i know sgi boxen are good this way...
  • It's all a matter of getting the hardware supported. I've talked to a number of developers from a variety of companies. They are all interested in Linux. They see the value.

    It just does their customers no good for them to port to Linux today. Their customers won't buy it today. Customers need a stable environment that works. Although we're starting to see implementations that work, stable is not a word I'd use to describe them.

    Have patience. I'm convinced it'll happen. It is moving along at a fairly rapid pace. If vendors don't have products out by next SIGGRAPH then I suspect you'd have a real reason to complain.

    - |Daryll

  • I forgot to mention in my other post. If you are having problems like that with the shutter glasses it may be because they are not set up correctly. I dont know what kind you are using but when we switched to the IR emitters from http://www.nuvision3d.com our whole setup worked better. These use a tiny fraction of the power that the StereoGraphics crystalEyes glasses we had before used. If you are using the IR emitters make sure you have more than one. Buy enough to make sure the glasses always recieve a signal no matter where the user is facing.

  • Re:don't start cheering yet (Score:2)

    by Anonymous Coward

    Well during AWGUA 99, they said (Mark Sylvester) that depending on the user response, they may port their apps to Linux. So if you Alias Wavefront licenses are current, bug them about it. There was a loud cheer just when they announced the availability of the Maya and Composer batch renderers. Though, I think realistically there won't be any serious consideration until Xfree 4.0 and DRI are included in the distros. These apps need some serious hardware OpenGL accelaration.

    Still the apps are coming. Houdini 4.0 will run on Linux (using the Xi OpenGL I believe). There is Blender which could me called a mid-level package, and there is the roto and ras_track from Hammerhead. So it might just be a matter of time. Hopefully by next SIGGRAPH will get some real good news. Here is a link to the OpenGL BOF for reference:


    Openl BOF minutes [mesa3d.org]

  • LSB library naming conventions?! (Score:1)

    by Anonymous Coward
    the LSB uses the convention libfoo.lsb.N where the
    lsb.N reflects the version of LSB in use. However, it's not clear we should be tied to a particular version of
    LSB.

    WTF is this? Why does LSB screw up library names like this? Where does the version of the library go? What about library bugfixes? (like the .6 in libc.so.2.0.6)
  • This may present some issues in having both X and non-X OpenGL implementations resident on the same platform.
    What non-X implementations of OpenGL exist? I've never heard of any.

    slightly offtopic: Has there been any progress on a Java OpenGL API standard? I recall news about perhaps magician [arcana.co.uk] becoming the standard, but no word since then.

    My Java Quake-wannabe development is suffering :)

  • The Real Magic is in the software - the CAVE Library automagically manages all the walls and headtracking for you. When you write a CAVE program, basically you just give the library a callback that draws the world, and the library will call it each time it needs to draw a wall, setting up the correct projection magic so it's drawn properly to your head position. It's really
    pretty slick.

    I've been playing with the idea of designing my own CAVE type setup using a group of 4 to 6 cheap networked PC's, each with a 3D card and an LCD projector. It doesn't seem like it would be that difficult to do; has anyone tried this? If not, are there any "gotchas" that would keep it from working? The only ones I can think of are possible network delay desynchronizing the walls, or perhaps the view-positioning math is harder than I think it is...

  • Re:don't start cheering yet (Score:1)

    by Anonymous Coward
    Well, A|W can't port and release their products on Linux until there's a decent OpenGL implementation there. (No, I'm afraid mesa doesn't count -- a software only GL is *way* too slow for the stuff Alias does)
  • does anyone actaually use C++ to implement low level libraries like this?

    Yes. SGI's GLU implementation is written in C++.

  • I would like to see linux-like portability and ease of use with SGI's outstanding cases...

  • This is NOT an announcement of any kind of SGI product launch - or any new OpenSource package or anything exciting like that. Apart from the fact that SGI are hosting the mailing list and web site on one of their computers, it isn't even a particularly SGI-releated thing at all!

    Right. This is the same idea as the LSB, but targeted specifically at OpenGL and trying to work on a faster timescale, since 3D acceleration is starting to happen in a big way on Linux.

  • What you've described is a CAVE [pyramidsystems.com]. They're not $50 million, more like $250k-$500k, depending on how decked out your SGI is.

    They're actually pretty simple - you get a couple of real good projectors, some big pieces of plastic film to use as a screen, and just project onto them. Then you get a magnetic tracker (they're not that much) and maybe a little joystick-like thing, and you've built a CAVE.

    The Real Magic is in the software - the CAVE Library automagically manages all the walls and headtracking for you. When you write a CAVE program, basically you just give the library a callback that draws the world, and the library will call it each time it needs to draw a wall, setting up the correct projection magic so it's drawn properly to your head position. It's really
    pretty slick.

    The big bummer with the CAVE library is that it's pretty expensive - about $30,000 (educational and with-hardware discounts are availble, though that drop that to about 15,000) It's availble from VRCO [vrco.com]. There isn't any free software that does anything quite like it out there...

    -Erik
  • What do you mean pseudoparanoid? Why is a reality wall any worse than a TV?


  • For my part I would be already glad, if they would open up their electropaint screen saver sources. :)

    Sounds like a great topic for a Slashdot poll. That would be a yea vote for me ...

    I'd love to check out the innards of that program. Also, it was written for the old IrisGL libraries so it's past due for a port to OpenGL.

    BTW, electropaint was written by David Tristram [tristram.com]

    Have you ever run ep with the -c option? Try it, you'll like it.

  • GLboolean represents a yes/no value. It has to be an addressable quantity since you can pass pointers to arrays of them to some GL calls. The smallest addressable quantity is a byte, so that's a reasonable choice.
  • Anyone else noticed that nVidia is the only graphics card manufacturer to cooperate on the project ?
    nVidia is going to be the way ahead for Linux graphics acceltating (well that is apart from SGI of course).

  • now, our community is splintering with announcements like this

    Please calm down and have another look. There's almost nothing here that other free unix OS's can't use. Your charges are laughable. There was no implication in this that any code will be non-portable.

    No part of this says it will not work on FreeBSD/OpenBSD/AcmeBSD. What's Windows got to do with anything?

    Do we really want people like this harming our comminity?

    The word 'harming' is ridiculous. In fact, it shows no respect for the many well known developers who are (and have been) writing this software FREE. What is your agenda?

  • You haven't lived till you have played DOOM in one of those things. We have one here at school that they use for among otherer things showing off how nifty our schools computer resources are. And one of the things they like to show off is a doom port... Its really killer. I loved it, and I had no problem with the 3d glasses, even though they were the old RF kind. The RF joystick was a bit strange to get used to, but once you get the hang of it, it kicks ass.
  • Its not enough to say that things can be used for other OSes if you want.

    The intent up front should be to provided an OpenGL on multiple OSes. Why is it that all the Non RedHat people get all excited about releasing products "for RedHat Linux"? Becuase if there is no intention of helping other platforms then it is more lilely that they will fall to the side in the future.

    I just do not want to see people start to develop for specific platforms. I think that it helps all of us if we develop for Free Software.

    -jason
  • Perhaps an Apple G4 cluster running Black lab Linux?

    Why not?

    TML
  • Chill. This has no effect on portability of code to BSD. No code will result from this (other than maybe a simple test suite to verify that the libraries and headers are in the right place and export the right symbols). It's just a way to organize libraries and header files on a specific OS. Mesa, for example, is not going to be any less portable to FreeBSD because it puts the libraries in one place as opposed to another when built on Linux.
  • I have freeBSD running in a Vmware session under Linux, I have thought about switching, but will wait to see how Linux 2.2 continues to progress, and will learn about FreeBSD too, not counting it out..
  • I suspect that commercial interests will skip supporting things other than Linux (which is why I'm against binary only stuff!) and the open source people will work at making sure (or will have someone come along that will) that it works on anything anyone is interested in.

    XiG and MetroX may not be interested in doing their stuff for anything other than Linux- but I know that the GLX acceleration project has at least one FreeBSD person working on the Matrox G200 support for *BSD.

    Add to that support for the Matrox G400, NVidia TNT2, and several others I'm not quite yet at liberty to mention (Work on these chips have just begun, and I don't want to get false hopes up!)- all with open source code and no black magic that would keep someone from implementing it under *BSD, etc. under any chipset that will work with an adapter.
  • What non-X implementations of OpenGL exist? I've never heard of any.

    GGIMesa is one. I bridged it to GLX well enough to run Quake3 in XGGI/GGIMesa, but with a GL-enabled X server you do have the potential for LD_LIBRARY_PATH related conflicts. Jon

  • Ok you have mesa trying to be OpenGL compatible and you've got OpenGL trying to be Mesa compatible now. Why don't the SGI guys just beef up OpenGL support in Mesa?

    ~GoRK
  • Not knowing otherwise, I'm wondering if one has to pay $$$ to license OpenGL from SGI to implement on Linux? Or are they releasing it as free/open source software?

    Without knowing that status, while it seems cool that the "Official" OpenGL is making it's way to Linux, it'd be a shame that it couldn't be included in all the distros.
  • After using both linux and SGI in an academic setting for many years, I can envision linux-like portability and ease of use with SGI's outstanding graphics in a single system. One can only hope.
    -- Moondog
  • hmmmm... i would think that those walls, with a little bit of creative flooring would make the beginnings of a HoloDeck...

    wouldn't THAT be a hoot? i think i would go mad, though; surrounded by my dream(s), but not being able to directly interact with them....

  • Standards help everybody ... (Score:3)

    by Lupulack ( 3988 ) on Wednesday September 08, 1999 @04:07AM (#1695247)
    This is EXACTLY what most GNU / Open source advocates are looking for.

    Here's a software standard that makes software easier to write. Who cares what OS / Hardware you're writing for? It's all a standard, just re-compile for the other platform.

    This will help both developers and companies like SGI ... after all, if you're selling hardware whose claim to fame is best-of-breed OpenGL performance, wouldn't you want software to be available for it?

    A lot of software is made for x86 ( Windows) because it's a popular platform, and thus a large market ... but if the platform doesn't matter, then the best software will be more affordable, since it will sell better ( being the best ).

    Anything that gives CHOICES is OK in my book ...
  • The picture of the Reality Center wall is how I've always invisioned the "Geek compound" or whatever Rob calls his dwelling. I can picture CmdrTaco and Hemos standing in front of their wall, viewing a graphical represenation of current Slashdot traffic, using voice commands to config httpd, ban trolls, and stories, etc.
    Somehow, though, I suspect reality is much less sexy than my imagination. ; )
  • when you can have a whole room?!

    THAT seems just like the Holodeck to me, except it's too small (1-5 people?)

    Now if only I had $50 million dollars...

  • Re:Licensing? (Score:2)

    by Anonymous Coward
    SGI currently doesn't protect the API. However, they do protect the trademark. To call what you sell "OpenGL", you have to license it from them. To call it "an API very similar to OpenGL" or something like that is free.
  • I was in one of these immersive environments about a year and a half ago, and they are extremely cool. It is hosted at Virginia Tech (Balcksburg, Va.) and they have public open houses if you are nearby. My program (Architecture) was experimenting with Virtual Environments, and I am sorry to say I graduated before I got to see the facility come completly online. It is a shared facility, so multiple programs can schedule to use it. If you ever get a chance, check them out. Too bad they are way out of budget for most buisnesses that could use them. Here is a URL if you feel like checking out a real world application of these systems at Tech,VELab [vt.edu] and one for the CAVE [vt.edu].

  • I was reading the standards, and noted that GLboolean was 8 bits. OK, so this is C, not C++, and 8bits is probably the smallest efficient size, but this adds a new demension to "fuzzy logic."
  • I was kidding, really.

    Actually, the C++ standard provides the bitset container for this. Certain classes (such as iostreams) do require a large number of booleans. Looking at my compiler (Metrowerks) it appears can use less than one byte per bit, although other implementations may vary. Of course, OpenGL is not written in C++.

  • Re:reality centres SUCK. (Score:1)

    by Anonymous Coward
    I worked at the UIC EVL lab for awhile doing some programming. Never looked at the ImmersaDesk (which was also developed there) but the CAVE was simply the most amazing 3D I've ever seen. Having 3 huge walls plus the floor getting projections along with the LCD glasses was totally amazing. I know exactly why people get excited....cuz it kicks ass.
  • Actually most C++ compilers that I know of implement the bool type in hardware at least an 8 bit integer, they just check that its value is only ever assigned a 1 or a zero. While it is possible in most architectures to test a single bit, it usually less efficient because memory these days tends to be byte addressable, not bit addressable, so the entire byte will be loaded into a register (or at least the cache), anyway. Also due to the byte addressing, no space is saved by using a single bit, since it has to be addressed (unless you want to write a compiler that keeps allocates 8 bools at the same time and keeps track of their bit positions to access them(which wouldn't even be that much more efficient since there are rarely (that I have seen) 8 bools all with the same scope and lifetime , so you would only have maybe two bools stored in 8 bits, despite having a more much more complex compiler structure)). Wow that was a long parenthesis.

    Note that is is useful to consider a bool as if it were a single bit, but that is not how it is really implemented.
    >~~~~~~~~~~~~~~~~

  • reality centres SUCK. (Score:2)

    by Anonymous Coward
    We have 2 of them over here with immarsadesk/glove/3dshutter (think reverse projected TV set type things with a 12 foot screen and wireless control for a room full of 3D shuttered battery powered glasses)..i *dislike* them intensely. They give people a headache from the 3D effects, very uncomfortable to work with due to limited RF range (if the glasses dont sync correctly you see dual fuzzy images which give splitting headaches). I fail to see what the fuss is about..probably by people who never use one daily. just cause a technology looks cool doesnt mean its useful...or worth using on a daily basis. im more productive with old fashioned SGI 20 inch monitors at 1600 x 1200 32bpp than with a reality centre/immarsadesk screen.
  • Yes, they do have drivers for each card that is different.

    But OpenGL is NOT a driver. It's an API that is used to write 3D rendering applications with. It doesn't concern itself with drivers. Under Windows, there's only two different OpenGL layers to muck with- the Win95 one and the WinNT one. With Linux, you've got at least twice to three times as many. What they're asking for here is to make the OpenGL implementations identical as far as calls, behavior, etc. and to provide as common as is possible driver layer API.
  • I've worked with immersaDesks /CAVE's for while. Here goes my current view on them.

    1) It is almost impossible to get the stereo parameters correct if what you are looking at is very dynamic. -- In order to make imersive display work you know exactly where someone is and exactly what they are looking at. With this info you can make the scene look pretty good. The problem is that a small error here gives people headaches, nausea, motion-sickness and the general impression that it 'SUCKS'. The problem with the cave is that you have 5 people looking in different places and there is no way to get it right.

    2) The RF emitter/receiver system used for headtracking can way to difficult to keep running and acurate. Even the newest stuff they sell to do this seems like it's 20 yrs old and I haven't seen it done really well yet.

    3) When it works you really knock peoples socks off. I think it's worth all of that effort because this system really does let you convey much more info and understanding than 2D or non-immersive 3D. Despite all the difficulties with it I think you'll start seeing it everywhere when we can fix the two problems above. I've seen too many customers come in and oh and ahh for hours to think otherwise.

  • No,no! You have it wrong! (Score:3)

    by Anonymous Coward on Wednesday September 08, 1999 @07:23AM (#1695261)
    This is NOT an announcement of any kind of SGI product launch - or any new OpenSource package or anything exciting like that. Apart from the fact that SGI are hosting the mailing list and web site on one of their computers, it isn't even a particularly SGI-releated thing at all!

    It's a document written by a bunch of concerned OpenGL developers/users that attempts to standardize such mundane (yet important) issues as:

    • "What is the OpenGL/Mesa library *called*?",
    • "Where do the header files live?",
    • "How does a BINARY program figure out what OpenGL extensions there are?"
    Don't read into this more than there is!

  • I see this as a good thing for Linux. Means that hopefully they will moake ports of the rest of there stuf that uses OpenGL to Linux too. I hope that this is not just a promise and they follow thru.

    SGI technology in Linux can be good, it will hopefully get more people to embrace Linux, and improve Linux as an OS.

    Linux is uniting *NIXes. Solaris and FreeBSD already have the means to run some Linux programs, this makes Linux binaries "almost" a default format.

    I am looking forward to next year and the things to come for Linux, and hopefully more features added in in the 2.4 kernel. I wonder what 3.0 will be like and if it will make it that far?

  • this is in section 2.2 regarding assembly.

    does anyone
    actaually use C++ to implement low level libraries
    like this? (id call it device driver, but the
    example refers to GLU which does not
    interact with hardware)

    seems like this leads to many problems.

  • Re:Interesting........ (Score:3)

    by Caballero ( 11938 ) <daryll@@@daryll...net> on Wednesday September 08, 1999 @05:01AM (#1695264) Homepage
    Linux is in a rather unique position. It has multiple different implementations of OpenGL provided by different companies. We've got Mesa stand-alone, Mesa in X, Xi Graphics, Metro Link, and others. Most other operating systems have one implementation.

    The idea of the Linux/OpenGL base is to make sure that applications written to any of these implementations will all work together. Mesa is important to that list of products as it is probably the most established implementation of the OpenGL API around.

    We want vendors to treat OpenGL under Linux as a given. They can pick any implementation they like for their development system. When they release their product they'll know it'll work with whatever OpenGL compatible implementation the user is running.

    This isn't really OpenGL becoming compatible with Mesa or even Mesa becoming compatible with OpenGL. It is really an effort to make sure we have a common standard and that changes are made wherever they are needed to implement the standard.

    - |Daryll

  • I'll take the bait and respond to this troll.

    How is this any better than the Microsoft "Will only work on MS Windows" philosophy?

    Umm, this is an open standard which anyone can use. If I wrote an API for Linux made the it an open standard would I get flamed for not writing the BeOS and BSD versions of the API? It's a public API and how it works is well known. If you want it for BSD or BeOS do it yourself....

    SGI has only made it easier for people or companies to make openGL API's on other OS's.

  • Reality Walls? Say it ain't so (Score:3)

    by Laxitive ( 10360 ) on Wednesday September 08, 1999 @05:06AM (#1695267) Journal
    Does this make the world look more and more like the world of Fahrenheight 451? I posted this once before when sony announced it's robotic dog, and there were stories of robotic fish that were indistinguishable from real ones (except for the eyes). I state it once again. If (and when) this comes to the mass market, what next? Western populations are apathetic as it is. People dont read as much as they used to, relying more and more on the boob tube to provide sensory deprivational entertainment. Even the books that people DO read are hopelessly bland, PC, and uncontroversial ones like "Chicken soup for the soul). What is happening to this world????? Just some thoughts from a pseudo paranoid. -Laxative
  • Cooperation between all the Free Software camps is an important part of our world. All the major Free projects strive to work on all FreeUnixen: Netscape, Gnome, Mesa, etc...

    But now, our community is splintering with announcements like this:

    Operating systems other than Linux. BSD etc. are welcome to use whatever comes out of this project, but we are explicitly not trying to solve this problem for every free OS in the world.
    To all of you who have said how easy it is to write portable code and to make it run on all platforms, they are basically saying that you are wrong. Do we really want people like this harming our comminity? How is this any better than the Microsoft "Will only work on MS Windows" philosophy?

    Linux is part of something much larger.

    -jason
  • Ok you have mesa trying to be OpenGL compatible

    True.

    and you've got OpenGL trying to be Mesa compatible now.

    That is not the case. What those folks try to achieve is making OpenGL backends interchangable.

    So that you get the latest hot 3d app and am able to use it with Mesa3d, or some OpenGL licensed lib from Xi or maybe even SGI without recompiling.

    Why don't the SGI guys just beef up OpenGL support in Mesa?

    In my opinion the SGI folks are already very generous. For example Brian Paul got access to the OpenGL conformance tests. So far we got an amazing Mesa 3d library. It might become one of the best OpenGL implementations in the future, but this will require our sweat in the first place and not SGIs. Fair game.

    BTW calling Mesa OpenGL conformance is not just a matter of putting Mesa through those mentioned tests, the system to be tested is a bit larger and consists also of the card drivers and maybe even cards and screens - I don't know the details, but it is more than just Mesa.

Slashdot Top Deals

No man is an island if he's on at least one mailing list.

Close