Re: [Mesa-dev] GLUT in 3.4 distro?
[EMAIL PROTECTED] wrote on 26-JAN-2000 18:40:01.60 >Stephen J Baker wrote: >> >> On Wed, 26 Jan 2000, Adam D. Moss wrote: >> >> > Stephen J Baker wrote: >> > > I was wondering about whether we should consider >> > > dropping GLUT from the next major Mesa distribution >> > > (3.4 I guess) and replacing it with 'freeglut' Hmm.. they claim that Mark has dropped glut. But I got a mail from Mark only 3 weeks ago saying that he is working on version 3.8. >> > >> > FWIW I think that this is a good idea, though I >> > can't say whether freeglut is mature enough for the >> > 3.4 timescale. >> >> It *is* rather new code (the first public version is >> only ~3 weeks old) - but like I said - it seems to >> work flawlessly on every test I've tried it with, >> and I'm now using it routinely. If there was more [snip] >> One other issue that I can see is that freeglut >> currently only works under Windoze and X - not >> MacOS, BeOS, etc, etc. I don't know if that's >> a problem or not. This may be a problem --> it means work to to to get working programs working. Another problem maybe that it not 100% compatible with glut. So maybe some application will be broken. >I didn't even know that freeglut existing until this morning. > >What exactly are the terms of Mark's copyright on GLUT? >I couldn't find it after a quick browse of the GLUT distro. > >I don't see an urgency to replace GLUT with freeglut in the >Mesa distro. Agreed. I think it would be best to include both (or pointers only) in the Mesa-distribution so that application builders can choose. Remember that (free)glut is only a tool-kit to make programming with OpenGL easier. Our work is the graphics-core. which does not depend on the tool-kit chosen. Jouk Ceterum censeo tertium millennium post Christum natum anno MMI incepturum esse >--< Jouk Jansen [EMAIL PROTECTED] Technische Universiteit Delfttt uu uu ddd Nationaal centrum voor HREM tt uu uu dddd Rotterdamseweg 137 tt uu uu dd dd 2628 AL Delfttt uu uu dd dd Nederlandtt uu uu dddd tel. 31-15-2781536 tt uuu ddd >--< ___ Mesa-dev maillist - [EMAIL PROTECTED] http://lists.mesa3d.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] Mesa-3.3 CVS link error
Brian Paul wrote: > Found the problem. src/glapi.c wasn't including conf.h. That's > where USE_X86_ASM is defined and that's tested to disable generation > of the C-based entrypoints. > > I didn't realize you were using automake to build. > > I've checked in the fix. > > -Brian That fixed it. Now I can go on with testing Holger's new Athlon 3DNow! prefetch(w) stuff. Thanks, Dieter -- Dieter Nützel Graduate Student, Computer Science University of Hamburg Department of Computer Science Cognitive Systems Group Vogt-Kölln-Straße 30 D-22527 Hamburg, Germany email: [EMAIL PROTECTED] @home: [EMAIL PROTECTED] ___ Mesa-dev maillist - [EMAIL PROTECTED] http://lists.mesa3d.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] OPENGL/MESA
The code that makes windows opengl fast isn't included in the SI released by SGI. Additionally, the driver you run on windows will have large amounts of effort expended by the IHV on tweaking for the particular hardware, in addition to the optimizations not included in the SI. mitch wrote: > I guess my comparision isn't 100% valid but it is a bit. I'm comparing quake3 in > linux with mesa 3.3, and 3.2 with that of quake3 in windows with opengl. There > is the issue that I'm not using SSE in linux but this was still the case when I > was on my P2. The decrease in FPS could not be mesa but it's the most likely > case. I'm not a gaming cowboy either so I don't really care about "My FPS" but > it's good for testing mesa. Games have always pushed the standards. ___ Mesa-dev maillist - [EMAIL PROTECTED] http://lists.mesa3d.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] OPENGL/MESA
I guess my comparision isn't 100% valid but it is a bit. I'm comparing quake3 in linux with mesa 3.3, and 3.2 with that of quake3 in windows with opengl. There is the issue that I'm not using SSE in linux but this was still the case when I was on my P2. The decrease in FPS could not be mesa but it's the most likely case. I'm not a gaming cowboy either so I don't really care about "My FPS" but it's good for testing mesa. Games have always pushed the standards. [EMAIL PROTECTED] wrote: > mitch writes: > >I think that the good parts of Opengl should be merged to the bad parts > >of mesa. Also, is there anyway to squeeze some more speed out of mesa? > >It seems that mesa is a good 8 to 10 FPS slower than Opengl with most > >apps and is much slower for low resolutions. > > Exactly which implementations are you comparing here? Mesa-3.1 vs. MS's > OpenGL that comes with Windows? Or with SGI's sample implementation? > On what platform? > > Dave > - > Email: [EMAIL PROTECTED] David Konerding WWW: http://picasso.ucsf.edu/~dek > - > > ___ > Mesa-dev maillist - [EMAIL PROTECTED] > http://lists.mesa3d.org/mailman/listinfo/mesa-dev -- Mitch Allmond Georgia Institute of Technology, Physics & Computer Science major [EMAIL PROTECTED] lca13.eastnet.gatech.edu "God does not play dice, but I do" ___ Mesa-dev maillist - [EMAIL PROTECTED] http://lists.mesa3d.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] SGI Opensources OpenGL!
On Wed, 26 Jan 2000, JONATHAN DINERSTEIN wrote: > >I don't like the idea of giving Mesa away for SGI to act as gatekeeper. > > > >I think we have to think more in terms of pulling stuff out of SI and > >into Mesa - if the license can be straightened out in *that* direction. > > I can agree with your concern, but my worry is such a fork in development > efforts. It would be like KDE and Gnome ... why spread out development efforts > and end up with two lesser systems when one excellent one could be developed? I agree - but right now, I can't think of a reason to work on the SGI code. *IF* a bunch of IHV's are prompted to release their specific adaptations of this code to their hardware into the public domain, *THEN* it might be interesting to dive into them to fix bugs or optimise them. However, the base code as provided by SGI may well be totally unrecognisable in the releases that (say) nVidia might make. SGI say: "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. ...so apart from this strength in the area of "internal state management", I can't see any particular reason for an OpenSource developer to 'jump ship' and work on the SI instead of Mesa. I don't think the existance of the SI as an independently maintained OpenGL-clone (can't call it OpenGL - remember) is all that rosy. The key to this announcement is that the other IHV's can now OpenSource *their* drivers - and I'll bet that's why SGI released it. > In part, I'm thinking about the benefit that could come to OpenGL in general. > Open source development of OpenGL could be used by any vendor, so work done by > the Mesa team on OpenGL would benefit more than just Linux users. I dunno, my > two cents. Mesa has gained popularity under Linux by being the only free implementation we have. Under Windoze, it had brief popularity for 3Dfx because their was no full OpenGL for those cards and Mesa could do the job. Now 3Dfx have fixed that situation, hardly anyone uses Mesa under Windoze. A similar story applies to Mac's...we were the only game in town - and now there is an officially sanctioned Apple implementation. There are a couple of other 'fringe' markets where Mesa is useful - but I think those were always a very tiny proportion of our users. So, I think Mesa will continue to be the "OpenGL" of choice for Linux - and we should look on this SGI release as a 'code mine' from which we may perhaps extract some nuggets such as the imaging extension. Steve Baker(817)619-2657 (Vox/Vox-Mail) Raytheon Systems Inc. (817)619-2466 (Fax) Work: [EMAIL PROTECTED] http://www.hti.com Home: [EMAIL PROTECTED] http://web2.airmail.net/sjbaker1 ___ Mesa-dev maillist - [EMAIL PROTECTED] http://lists.mesa3d.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] OPENGL/MESA
mitch writes: >I think that the good parts of Opengl should be merged to the bad parts >of mesa. Also, is there anyway to squeeze some more speed out of mesa? >It seems that mesa is a good 8 to 10 FPS slower than Opengl with most >apps and is much slower for low resolutions. Exactly which implementations are you comparing here? Mesa-3.1 vs. MS's OpenGL that comes with Windows? Or with SGI's sample implementation? On what platform? Dave - Email: [EMAIL PROTECTED] David Konerding WWW: http://picasso.ucsf.edu/~dek - ___ Mesa-dev maillist - [EMAIL PROTECTED] http://lists.mesa3d.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] SGI Opensources OpenGL! (fwd)
On Wed, Jan 26, 2000 at 12:09:02PM -0600, C.J. Beyer wrote: (Forwarded from Steve Baker, I think) | | > However, I'd really like to here responces to this comment: | > | > "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." | | Someone at SGI once told me that there had been discussions about dumping | SGI's reference implementation in favor of Mesa ... Precision Insight and SGI have been talking about unifying the OpenGL codebase for some time. Don't know if those are the discussions you had in mind. The reasons for unifying the codebase are obvious; the reasons for *not* doing so just yet are covered pretty well in the new FAQ. (Briefly: Licensing compatibility still needs to be worked out; and Mesa can deliver hardware support and driver optimizations that the SI (Sample Implementation) can't yet because of intellectual property concerns and code development schedules.) | The big favor I'd like to ask of SGI is whether they'd release the | compliance suite for public use ... | | I appreciate that there is already a partial freeware "test" | suite (GLEAN), it's still FAR from being a comprehensive test | harness. I think making the conformance test suite available would be great. However, it wouldn't solve the problem of guaranteeing that OpenGL (or Mesa) implementations are stable, consistent with previous releases, or perform well. Hardware vendors have separate test suites for those purposes, and I imagined that glean would be the open-source equivalent of those private suites. I'm beginning to get contributions for glean now, and certainly would appreciate more. That's what it'll take to have a first-rate quality assurance tool for the open-source world. http://glean.sourceforge.net/ Allen ___ Mesa-dev maillist - [EMAIL PROTECTED] http://lists.mesa3d.org/mailman/listinfo/mesa-dev
[Mesa-dev] OPENGL/MESA
I think that the good parts of Opengl should be merged to the bad parts of mesa. Also, is there anyway to squeeze some more speed out of mesa? It seems that mesa is a good 8 to 10 FPS slower than Opengl with most apps and is much slower for low resolutions. -- Mitch Allmond Georgia Institute of Technology, Physics & Computer Science major [EMAIL PROTECTED] lca13.eastnet.gatech.edu "God does not play dice, but I do" ___ Mesa-dev maillist - [EMAIL PROTECTED] http://lists.mesa3d.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] SGI Opensources OpenGL!
jonathan Dinerstein wrote: > I can agree with your concern, but my worry is such a fork in > development efforts. It would be like KDE and Gnome ... why spread > out development efforts and end up with two lesser systems when one > excellent one could be developed? Which is a worse fork and requires more effort? - Putting Mesa and the hardware drivers in Mesa into the OpenGL sample implementation (then there will be two open source non-OpenGL libraries that support the OpenGL API, or essentially two Mesas) - Taking the good parts of OpenGL SI and working them into Mesa (keeping things the same except making Mesa stronger) > In part, I'm thinking about the benefit that could come to OpenGL in general. > Open source development of OpenGL could be used by any vendor, so work done by > the Mesa team on OpenGL would benefit more than just Linux users. I dunno, my > two cents. You still have to buy the license in order to call it OpenGL, so why not just buy the license, test Mesa, and ship it with the OpenGL logo? I really appreciate the open sourcing of the OpenGL SI, but, like the FAQ says, it's only one piece of a larger puzzle that is hardware accelerated OpenGL. -Brad -- Brad Grantham, [EMAIL PROTECTED], http://alt.net/~grantham ___ Mesa-dev maillist - [EMAIL PROTECTED] http://lists.mesa3d.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] SGI Opensources OpenGL!
>I don't like this clause in the FAQ though: > > Ownership of the original code will remain in SGI. Contributors of > modifications to the original code will own their own modifications > (independent of the original code); however, SGI will ask for > assignment back to SGI of any contributors' modifications offered to > SGI as gatekeeper of the "official" Original Code of the SI. This is > to ensure that the OpenGL SI can continue to play the role of "the gold > standard", freely shared with the development community. > >I don't like the idea of giving Mesa away for SGI to act as gatekeeper. > >I think we have to think more in terms of pulling stuff out of SI and >into Mesa - if the license can be straightened out in *that* direction. I can agree with your concern, but my worry is such a fork in development efforts. It would be like KDE and Gnome ... why spread out development efforts and end up with two lesser systems when one excellent one could be developed? In part, I'm thinking about the benefit that could come to OpenGL in general. Open source development of OpenGL could be used by any vendor, so work done by the Mesa team on OpenGL would benefit more than just Linux users. I dunno, my two cents. Jonathan Dinerstein [EMAIL PROTECTED] ___ Mesa-dev maillist - [EMAIL PROTECTED] http://lists.mesa3d.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] SGI Opensources OpenGL!
On Wed, 26 Jan 2000, JONATHAN DINERSTEIN wrote: > I think that open source OpenGL will eventually replace Mesa for the simple > fact that vendors will trust SGI's OpenGL over Mesa. I'm not saying that Mesa > is a poor library, but that SGI's OpenGL has the SGI name attached. > > For the best benefit for everybody, I think moving Mesa development to OpenGL > is a good idea. I think we've all seen a lot of time/work/effort wasted by > open source developers who can't all stand behind one effort. I don't like this clause in the FAQ though: Ownership of the original code will remain in SGI. Contributors of modifications to the original code will own their own modifications (independent of the original code); however, SGI will ask for assignment back to SGI of any contributors' modifications offered to SGI as gatekeeper of the "official" Original Code of the SI. This is to ensure that the OpenGL SI can continue to play the role of "the gold standard", freely shared with the development community. I don't like the idea of giving Mesa away for SGI to act as gatekeeper. Since SGI are an IHV - and they are snuggling up with nVidia, there would be a conflict of interests that might make the resulting Mesa/SGI hybrid unacceptable to (say) 3Dfx or Matrox. I don't think this is a problem immediately - but who knows how the politics could change in a year or two. I think we have to think more in terms of pulling stuff out of SI and into Mesa - if the license can be straightened out in *that* direction. Steve Baker(817)619-2657 (Vox/Vox-Mail) Raytheon Systems Inc. (817)619-2466 (Fax) Work: [EMAIL PROTECTED] http://www.hti.com Home: [EMAIL PROTECTED] http://web2.airmail.net/sjbaker1 ___ Mesa-dev maillist - [EMAIL PROTECTED] http://lists.mesa3d.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] GLUT in 3.4 distro?
On Wed, 26 Jan 2000, Brian Paul wrote: > I didn't even know that freeglut existing until this morning. Yep. It hasn't been well advertized - and it's very new. > What exactly are the terms of Mark's copyright on GLUT? It's in the file 'NOTICE' in the top of the GLUT distro. It says: "NOTICE: The OpenGL Utility Toolkit (GLUT) distribution contains source code published in a book titled "Programming OpenGL for the X Window System" (ISBN: 0-201-48359-9) published by Addison-Wesley. The programs and associated files contained in the distribution were developed by Mark J. Kilgard and are Copyright 1994, 1995, 1996 by Mark J. Kilgard (unless otherwise noted). The programs are not in the public domain, but they are freely distributable without licensing fees. These programs are provided without guarantee or warrantee expressed or implied." This has historically been taken to mean that you can't MODIFY GLUT and redistribute it. Jon Leech has tried to get Mark to clarify that - he mailed me the word from Mark himself: Mark Kilgard wrote: > Jon Leech wrote: > > One word would suffice: can people modify and redistribute the GLUT > > source code under its current copyright? Yes or no? > > The answer is YES. Just call it something other than GLUT if you > plan to rerelease it. Preserve the copyright notice. Don't slap a GPL > on it and your in business. You can introduce all the bugs, VRML > support, audio, whatever. Just please don't make it sound like I endorse > it or that it is GLUT. So you have to change the name - and not make it sound like it is GLUT - which means you can't have it be 'libglut.a' - because that certainly makes it sound like it is GLUT. If there was no truly, cleanly open substitute, then I might be tempted to go to all the trouble of making changes to GLUT and calling it GLOP or something. But since we have freeglut, and it works well, why not simply dump the weird license restrictions and move on? freeglut uses the Xfree license which is unambiguous and fits better with Mesa and Xfree itself. > I don't see an urgency to replace GLUT with freeglut in the > Mesa distro. Well, I don't think it's *urgent* either - but even non-urgent things have to be done sometime - and Mesa 3.4 seems like the perfect time to me. GLUT really does need some fixes and some minimal enhancements though... eg * Breaking the 'glutMainLoop' thing so you don't have to be strictly event-driven. That is the number one reason why some people won't use GLUT. (freeglut has this) * Allowing a clean way to have code that runs after the last GLUT window is closed. (freeglut has this) * Fix the joystick code so it works under Linux (freeglut already has this). * Change the joystick API so you can have multiple joysticks. * Provide texturemapped fonts for speed. * The 'gameGLUT' fullscreen mode was never properly finished - I don't think it works well/at-all for X. * It needs to be switched from 'imake' to 'autoconf/automake' (freeglut has this) * The GLUT code is cluttered with stuff that *NOBODY* uses like the SGI 'dials-and-buttons' box. That junk could be usefully cleared out. (And of course that stuff isn't in freeglut in the first place). ...none of these are really a very big deal for an OpenSourced package - once freeglut is accepted into the OpenGL community as a permenant replacement for GLUT, I'm sure we'll see a lot of improvements in a short time. We just need to gently push aside the retired Cathederal designer and start moving those Bazaar stalls into place! Having Mesa bundle freeglut would go a long way to providing that acceptance. > I'd like to get 3.2 finished in the next couple weeks > and release 3.3 beta at about the same time. Seems like reasonable timing to me...but it's your call of course. I wouldn't expect it to be in 3.2 - and if we put it into 3.3, and it all screwed up for some reason, we could back it out again in plenty of time for 3.4. (I should point out that I didn't have anything to do with the development of freeglut - except that I donated my collection of portable joystick drivers. I'm a convert to freeglut because it's "The Right Thing") Steve Baker(817)619-2657 (Vox/Vox-Mail) Raytheon Systems Inc. (817)619-2466 (Fax) Work: [EMAIL PROTECTED] http://www.hti.com Home: [EMAIL PROTECTED] http://web2.airmail.net/sjbaker1 ___ Mesa-dev maillist - [EMAIL PROTECTED] http://lists.mesa3d.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] SGI Opensources OpenGL!
I think that open source OpenGL will eventually replace Mesa for the simple fact that vendors will trust SGI's OpenGL over Mesa. I'm not saying that Mesa is a poor library, but that SGI's OpenGL has the SGI name attached. For the best benefit for everybody, I think moving Mesa development to OpenGL is a good idea. I think we've all seen a lot of time/work/effort wasted by open source developers who can't all stand behind one effort. Jonathan Dinerstein [EMAIL PROTECTED] ___ Mesa-dev maillist - [EMAIL PROTECTED] http://lists.mesa3d.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] SGI Opensources OpenGL! (fwd)
-- Forwarded message --
Date: Wed, 26 Jan 2000 10:39:14 -0600 (CST)
From: Stephen J Baker <[EMAIL PROTECTED]>
Subject: Re: [Mesa-dev] SGI Opensources OpenGL!
On Wed, 26 Jan 2000, C.J. Beyer wrote:
> Well, from reading the licence FAQ...
Which is here BTW:
http://oss.sgi.com/projects/ogl-sample/faq.html
> ... it might answer Gareth Hughes question about that extension:
>
> "Some ways we can work together might include implementations of new
>ARB-specified OpenGL extensions..."
Yep. Although I think they are talking more in terms of sharing the
code for those extensions rather than the specification of the
extension which (I guess) is what Gareth is talking about.
> However, I'd really like to here responces to this comment:
>
> "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."
Someone at SGI once told me that there had been discussions about dumping
SGI's reference implementation in favor of Mesa - but that was a LONG time
ago - before OpenGL 1.2 and the optional imaging subset stuff (which Mesa
doesnt implement - but the reference implementation must).
It would be kinda ironic if the one implementation of the OpenGL API that
isn't allowed to be called OpenGL would end up being the reference
implementation!
I have a couple of comments (now I've read the FAQ):
1) They mention that this release does not include the dynamic code
generation rasterizer that's in SGI's OpenGL for Windoze.
That's a shame because that could have benefitted software-only
rendering under Mesa.
2) It *does* include the optional imaging subset of OpenGL 1.2 - which
would be a nice addition to Mesa.
3) To quote the FAQ:
"Do I still need a license for OpenGL? Yes"...
So, if I read this right (and IANAL), if you take this code and do something
to it, you *still* can't call it OpenGL. That's actually pretty reasonable
because you'd still need to pass the conformance test suite and that's *still*
not OpenSourced.
Later on they say:
"...we allow you to use the following exact attribution (no more,
no less) in your software products that are based on this
Sample Implementation:
This software was created using the published OpenGL® version
1.2.1 Sample Implementation, but has not been independently
verified as being compliant with the OpenGL®1 version 1.2.1, GLU
version 1.3, or GLX version 1.3 Specifications."
...well, at least it's made crystal clear what you have to do to
stay legal.
The big favor I'd like to ask of SGI is whether they'd release the
compliance suite for public use (not necessarily as "Open" or as
"Source" - there might be good reasons not to do that).
Whilst that wouldn't change the use of the OpenGL *name*, it would allow
Joe Public to test SquonkGL ("...created using the published OpenGL..")
to see if it is still "an implementation of the OpenGL API".
Given the potential for this newly freed code to create multiple Mesa-like
"implementations of the OpenGL API" (we need a non-copyrighted name for
those things), it would be nice to have a reasonably official way
to test them for yourself against the gold standard.
I appreciate that there is already a partial freeware "test"
suite (GLEAN), it's still FAR from being a comprehensive test
harness.
Steve Baker(817)619-2657 (Vox/Vox-Mail)
Raytheon Systems Inc. (817)619-2466 (Fax)
Work: [EMAIL PROTECTED] http://www.hti.com
Home: [EMAIL PROTECTED] http://web2.airmail.net/sjbaker1
___
Mesa-dev maillist - [EMAIL PROTECTED]
http://lists.mesa3d.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] SGI Opensources OpenGL!
On Wed, 26 Jan 2000, Brad Grantham wrote: > > From [EMAIL PROTECTED] Wed Jan 26 11:24:14 2000 > > So, what does this: > > > > >http://www.quicken.com/investments/news/story/pr/?story=/news/stories/pr/2126/sfw052.htm&symbol=SGI > > > > ...mean for the future of Mesa? > > I imagine (but do not know) that you still need to buy the license in > order to get the conformance tests and use the OpenGL trademark. >From reading the SGI OpenGL SI FAQ, that seems to be true. > Which means that (for now) this is just another OpenGL-compatible open > source library. There's a lot more work *freely available* right now > for hardware accelerating Mesa. I'll be a lot more excited when I see > hardware vendors open sourcing their OpenGL implementations. Which (reading between the lines) may well be why SGI released this. If (say) nVidia wanted to OpenSource their drivers, then before today, they could not legally do so because they are (presumably) based on the SGI reference implementation. The reason for SGI to OpenSource this package could simply be a necessary step to allow one or other of the other IHV's to release their Linux drivers. > In addition, I believe many Windows 98/NT ICD maintainers have an > additional Microsoft license in their source code, so it will probably > require a lot of legal and editing work before they can put out source > for their OpenGL driver. For example, I don't think S3 can > turn around today and open source their Windows driver. Yep. I'm sure that's the case. > This is very exciting, and I think it helps improve the strength of > the OpenGL API on Linux and in general, but this is not nearly as > useful or as interesting as people probably think. Perhaps. If the cross-license mess can be sorted out, then I think that grabbing the imaging subset and Nurbs code (possibly all of GLU actually) from the SGI code and stuffing it into Mesa would be "A Good Thing". I imagine that merging anything else from the SGI implementation would do little to benefit Mesa directly. As an application author, I'll certainly install it somewhere just so I can compare how my program looks on SGI's SI with how it runs under Mesa. This is always a useful way to try to ferret out portability problems. Steve Baker(817)619-2657 (Vox/Vox-Mail) Raytheon Systems Inc. (817)619-2466 (Fax) Work: [EMAIL PROTECTED] http://www.hti.com Home: [EMAIL PROTECTED] http://web2.airmail.net/sjbaker1 ___ Mesa-dev maillist - [EMAIL PROTECTED] http://lists.mesa3d.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] GLUT in 3.4 distro?
Stephen J Baker wrote: > > On Wed, 26 Jan 2000, Adam D. Moss wrote: > > > Stephen J Baker wrote: > > > I was wondering about whether we should consider > > > dropping GLUT from the next major Mesa distribution > > > (3.4 I guess) and replacing it with 'freeglut' > > > > FWIW I think that this is a good idea, though I > > can't say whether freeglut is mature enough for the > > 3.4 timescale. > > It *is* rather new code (the first public version is > only ~3 weeks old) - but like I said - it seems to > work flawlessly on every test I've tried it with, > and I'm now using it routinely. If there was more > time to work on it, I'm not quite sure what you'd > use that time to do...apart from run more tests. > However, since it already runs all the GLUT and Mesa > example code, it's hard to imagine anyone writing > more test code to exercise it further. > > We really need people to test it with more real > applications. > > What is the 3.4 timescale anyway? > > Perhaps it should go into the 3.3 codebase immediately > and we could back it out again for 3.4 if we are > snowed under with complaints. That's what an > unstable odd-numbered release is *for* - right? > > One other issue that I can see is that freeglut > currently only works under Windoze and X - not > MacOS, BeOS, etc, etc. I don't know if that's > a problem or not. I didn't even know that freeglut existing until this morning. What exactly are the terms of Mark's copyright on GLUT? I couldn't find it after a quick browse of the GLUT distro. I don't see an urgency to replace GLUT with freeglut in the Mesa distro. I'd like to get 3.2 finished in the next couple weeks and release 3.3 beta at about the same time. -Brian ___ Mesa-dev maillist - [EMAIL PROTECTED] http://lists.mesa3d.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] GLUT in 3.4 distro?
On Wed, 26 Jan 2000, Adam D. Moss wrote: > Stephen J Baker wrote: > > I was wondering about whether we should consider > > dropping GLUT from the next major Mesa distribution > > (3.4 I guess) and replacing it with 'freeglut' > > FWIW I think that this is a good idea, though I > can't say whether freeglut is mature enough for the > 3.4 timescale. It *is* rather new code (the first public version is only ~3 weeks old) - but like I said - it seems to work flawlessly on every test I've tried it with, and I'm now using it routinely. If there was more time to work on it, I'm not quite sure what you'd use that time to do...apart from run more tests. However, since it already runs all the GLUT and Mesa example code, it's hard to imagine anyone writing more test code to exercise it further. We really need people to test it with more real applications. What is the 3.4 timescale anyway? Perhaps it should go into the 3.3 codebase immediately and we could back it out again for 3.4 if we are snowed under with complaints. That's what an unstable odd-numbered release is *for* - right? One other issue that I can see is that freeglut currently only works under Windoze and X - not MacOS, BeOS, etc, etc. I don't know if that's a problem or not. Steve Baker(817)619-2657 (Vox/Vox-Mail) Raytheon Systems Inc. (817)619-2466 (Fax) Work: [EMAIL PROTECTED] http://www.hti.com Home: [EMAIL PROTECTED] http://web2.airmail.net/sjbaker1 ___ Mesa-dev maillist - [EMAIL PROTECTED] http://lists.mesa3d.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] Re: [utah-glx-dev] Sample implementation of OpenGL released underOpenSource License
Keith Whitwell wrote: > > Sven Heyll wrote: > > > > On Wed, 26 Jan 2000, Hetz Ben Hamo wrote: > > > > Hello, > > > > > Hi, > > > > > > Well, as the title says - SGI has just released a sample implementation of > > > OpenGL to the Open Source Community. > > > > > > URL: > > > >http://www.quicken.com/investments/news/story/pr/?story=/news/stories/pr/2126/sfw052.htm&symbol=SGI > > > > > > Now the biggie question - are we going to modify soon the Matrox and other > > > drivers to the OpenGL? will we leave Mesa out?? (Sorry if it's a stupid > > > question). > > I have this question too. > > > > I dont know if it is a stupid question, but I think that the Mesa > > programmers should compare their implementaion with that from SGI, and > > then take all that is better than Mesa. I dont think that the SGI > > implementation has assembler optimations, and after all, it is just a > > sample maybe it is not that good at all ?( I rather think it is very good) > > > > The stuff that might be interresting in my opinion are several SGI > > extensions and texture stuff. > > > > I think it is first necessary to evaluate the license that they have proposed > and ensure that use of their code doesn't > 'taint' the Mesa codebase. If we take their code, we get the license > restrictions for free, and would need to add them to the Mesa license. > > Here's one - it's not immediately obvious if it is relevent, but it's not in > our license now. > > > 3. No License For Hardware Implementations. The licenses granted in > >Section 2.1 are not applicable to implementation in Hardware of the > >algorithms embodied in the Original Code. > > Here's another one, which is reminiscent of the Java licenses: > > 4.Modifications License and API Compliance. Modifications are only licensed > under Section 2.1(i) to the extent such Modifications are fully compliant with > any API as may be identified in Additional Notice Provisions as appear in the > Original Code. > > The license appears 'viral' in that incorporating SI code into Mesa would > impose these constraints on Mesa. > Please note that I'm not condemning what SGI's done - it's long overdue in my opinion. However there is a dense bit of legalese attached to it which I don't fully understand the implications of, and would be happy to see clarified. Keith ___ Mesa-dev maillist - [EMAIL PROTECTED] http://lists.mesa3d.org/mailman/listinfo/mesa-dev
[Mesa-dev] Re: [utah-glx-dev] Sample implementation of OpenGL released underOpenSource License
Sven Heyll wrote: > > On Wed, 26 Jan 2000, Hetz Ben Hamo wrote: > > Hello, > > > Hi, > > > > Well, as the title says - SGI has just released a sample implementation of > > OpenGL to the Open Source Community. > > > > URL: > > >http://www.quicken.com/investments/news/story/pr/?story=/news/stories/pr/2126/sfw052.htm&symbol=SGI > > > > Now the biggie question - are we going to modify soon the Matrox and other > > drivers to the OpenGL? will we leave Mesa out?? (Sorry if it's a stupid > > question). > I have this question too. > > I dont know if it is a stupid question, but I think that the Mesa > programmers should compare their implementaion with that from SGI, and > then take all that is better than Mesa. I dont think that the SGI > implementation has assembler optimations, and after all, it is just a > sample maybe it is not that good at all ?( I rather think it is very good) > > The stuff that might be interresting in my opinion are several SGI > extensions and texture stuff. > I think it is first necessary to evaluate the license that they have proposed and ensure that use of their code doesn't 'taint' the Mesa codebase. If we take their code, we get the license restrictions for free, and would need to add them to the Mesa license. Here's one - it's not immediately obvious if it is relevent, but it's not in our license now. > 3. No License For Hardware Implementations. The licenses granted in >Section 2.1 are not applicable to implementation in Hardware of the >algorithms embodied in the Original Code. Here's another one, which is reminiscent of the Java licenses: 4.Modifications License and API Compliance. Modifications are only licensed under Section 2.1(i) to the extent such Modifications are fully compliant with any API as may be identified in Additional Notice Provisions as appear in the Original Code. The license appears 'viral' in that incorporating SI code into Mesa would impose these constraints on Mesa. Keith ___ Mesa-dev maillist - [EMAIL PROTECTED] http://lists.mesa3d.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] SGI Opensources OpenGL!
> From [EMAIL PROTECTED] Wed Jan 26 11:24:14 2000 > So, what does this: > > >http://www.quicken.com/investments/news/story/pr/?story=/news/stories/pr/2126/sfw052.htm&symbol=SGI > > ...mean for the future of Mesa? I imagine (but do not know) that you still need to buy the license in order to get the conformance tests and use the OpenGL trademark. Which means that (for now) this is just another OpenGL-compatible open source library. There's a lot more work *freely available* right now for hardware accelerating Mesa. I'll be a lot more excited when I see hardware vendors open sourcing their OpenGL implementations. In addition, I believe many Windows 98/NT ICD maintainers have an additional Microsoft license in their source code, so it will probably require a lot of legal and editing work before they can put out source for their OpenGL driver. For example, I don't think S3 can turn around today and open source their Windows driver. This is very exciting, and I think it helps improve the strength of the OpenGL API on Linux and in general, but this is not nearly as useful or as interesting as people probably think. -Brad -- Brad Grantham, [EMAIL PROTECTED], http://alt.net/~grantham ___ Mesa-dev maillist - [EMAIL PROTECTED] http://lists.mesa3d.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] SGI Opensources OpenGL!
Well, from reading the licence FAQ it might answer Gareth Hughes question about that extension: "Some ways we can work together might include implementations of new ARB-specified OpenGL extensions..." However, I'd really like to here responces to this comment: "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." Have they talk to you about it Brian? Or are you at liberty to discuss it? What kind of "time" are we talking about and how does this relate to getting an "official" OpenGL implementation branding? On Wed, 26 Jan 2000, Stephen J Baker wrote: > So, what does this: > >http://www.quicken.com/investments/news/story/pr/?story=/news/stories/pr/2126/sfw052.htm&symbol=SGI > ...mean for the future of Mesa? C.J. Beyer [EMAIL PROTECTED] http://styx.phy.vanderbilt.edu/~cj/ ___ Mesa-dev maillist - [EMAIL PROTECTED] http://lists.mesa3d.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] GLUT in 3.4 distro?
Stephen J Baker wrote: > I was wondering about whether we should consider > dropping GLUT from the next major Mesa distribution > (3.4 I guess) and replacing it with 'freeglut' FWIW I think that this is a good idea, though I can't say whether freeglut is mature enough for the 3.4 timescale. --Adam ___ Mesa-dev maillist - [EMAIL PROTECTED] http://lists.mesa3d.org/mailman/listinfo/mesa-dev
[Mesa-dev] GLUT in 3.4 distro?
I was wondering about whether we should consider dropping GLUT from the next major Mesa distribution (3.4 I guess) and replacing it with 'freeglut': http://freeglut.sourceforge.net ...which has an Xfree license rather than GLUT's "free for distribution but not public domain" license. Freeglut runs all my applications identically to the real GLUT - and I'm told that it also runs all of the Mesa examples too. GLUT could use some maintenance and enhancements to keep up with the times - and since Mark Kilgard seems to have done nothing to GLUT for at least 18 months, I think it's time to take up the OpenSource version and run with that instead. What do other people think about this? Steve Baker(817)619-2657 (Vox/Vox-Mail) Raytheon Systems Inc. (817)619-2466 (Fax) Work: [EMAIL PROTECTED] http://www.hti.com Home: [EMAIL PROTECTED] http://web2.airmail.net/sjbaker1 ___ Mesa-dev maillist - [EMAIL PROTECTED] http://lists.mesa3d.org/mailman/listinfo/mesa-dev
[Mesa-dev] SGI Opensources OpenGL!
So, what does this: http://www.quicken.com/investments/news/story/pr/?story=/news/stories/pr/2126/sfw052.htm&symbol=SGI ...mean for the future of Mesa? Steve Baker(817)619-2657 (Vox/Vox-Mail) Raytheon Systems Inc. (817)619-2466 (Fax) Work: [EMAIL PROTECTED] http://www.hti.com Home: [EMAIL PROTECTED] http://web2.airmail.net/sjbaker1 ___ Mesa-dev maillist - [EMAIL PROTECTED] http://lists.mesa3d.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] Mesa-3.3 CVS link error
Dieter Nützel wrote: > > What's the problem here? > > rm -fr .libs/libGL.la .libs/libGL.* .libs/libGL.* > gcc -shared accum.lo alpha.lo alphabuf.lo attrib.lo bbox.lo bitmap.lo > blend.lo clip.lo colortab.lo config.lo context.lo copypix.lo cva.lo > debug_xform.lo depth.lo dispatch.lo dlist.lo drawpix.lo enable.lo > enums.lo eval.lo extensions.lo feedback.lo glapi.lo glapinoop.lo > glthread.lo fog.lo get.lo glmisc.lo hash.lo imaging.lo image.lo light.lo > lines.lo logic.lo masking.lo matrix.lo mem.lo mmath.lo pb.lo pipeline.lo > pixel.lo points.lo polygon.lo quads.lo rastpos.lo readpix.lo rect.lo > scissor.lo shade.lo span.lo stages.lo stencil.lo teximage.lo texobj.lo > texstate.lo texture.lo translate.lo triangle.lo varray.lo vb.lo > vbcull.lo vbfill.lo vbindirect.lo vbrender.lo vbxform.lo vector.lo > vertices.lo winpos.lo xform.lo zoom.lo -Wl,--whole-archive > X86/.libs/libMesaX86.al OSmesa/.libs/libMesaOS.al X/.libs/libMesaX11.al > -Wl,--no-whole-archive X86/.libs/libMesaX86.al > OSmesa/.libs/libMesaOS.al X/.libs/libMesaX11.al -lc -Wl,-soname > -Wl,libGL.so.1 -o .libs/libGL.so.1.2.030300 > X86/.libs/libMesaX86.al(glapi_x86.lo): In function `glAccum': > glapi_x86.lo(.text+0x0): multiple definition of `glAccum' > glapi.lo(.text+0xc98): first defined here > X86/.libs/libMesaX86.al(glapi_x86.lo): In function `glAlphaFunc': > glapi_x86.lo(.text+0x10): multiple definition of `glAlphaFunc' > glapi.lo(.text+0x3c8): first defined here > > [snip] > > X86/.libs/libMesaX86.al(glapi_x86.lo): In function > `glMultTransposeMatrixdARB': > glapi_x86.lo(.text+0x3b60): multiple definition of > `glMultTransposeMatrixdARB' > glapi.lo(.text+0x75ac): first defined here > X86/.libs/libMesaX86.al(glapi_x86.lo): In function > `glMultTransposeMatrixfARB': > glapi_x86.lo(.text+0x3b80): multiple definition of > `glMultTransposeMatrixfARB' > glapi.lo(.text+0x75e0): first defined here > collect2: ld returned 1 exit status > make[2]: *** [libGL.la] Error 1 > make[2]: Leaving directory `/usr/local/Mesa/src' > make[1]: *** [check-recursive] Error 1 > make[1]: Leaving directory `/usr/local/Mesa/src' > make: *** [check-recursive] Error 1 > 1.900u 1.250s 0:03.41 92.3% 0+0k 0+0io 28707pf+0w Make sure you do a clean build. The x86-optimized dispatch functions will collide with the ones in glapi.c if you don't recompile everything. -Brian ___ Mesa-dev maillist - [EMAIL PROTECTED] http://lists.mesa3d.org/mailman/listinfo/mesa-dev
