Re: [Mesa-dev] beta 3 release
Stephen J Baker wrote: On Tue, 7 Sep 1999, Brian Paul wrote: Here's another issue. There's an effort underway to standardize the OpenGL environment on Linux. One aspect of that is version numbering for the libGL.so file (used to be libMesaGL.so). I propose this lib name for the 3.1 release: libGL.so.1.2.310 The 1.2 designates an implementation of the 1.2 API specification. The 310 designates the Mesa version number (3.1.0). The main idea is to allow Linux OpenGL apps to relink with other OpenGL implementations at load/runtime. Comments? I think that the Mesa numbering scheme should simply be the OpenGL version number and a consecutively incrementing third number. It's usual for the last number in a three part version number to represent bug fixes and optimisations, and the first two part to indicate changes that affect the API or user interface significantly. Since Mesa is just following the OpenGL API, the only time one of the higher up numbers should change is when OpenGL changes - and that's covered by picking the same version number as the OpenGL spec. So, I would simply renumber Mesa versions to continue from: 1.2.1 ...starting with the next release. I think that would be less confusing than running two sets of version numbers in parallel (1.2.310 *and* 3.1) - although there would of course be a small one-time confusion at the point of switch. (Does anyone even remember Mesa 1.x ?) Every once in a while someone asks me about problems with version 1.2.8 (circa 1995)! I've checked in changes so that libGL.so.1.2.310 is built using the old Makefile scheme. Steve's been the only one to comment on my new numbering idea. I respect his opinion but I think I'll release 3.1 beta 3 with the 1.2.310 number and see what the response is. I'm hesitant to restart Mesa's version numbering at 1.2.0. I think there would be quite a bit of confusion. -Brian ___ Mesa-dev maillist - [EMAIL PROTECTED] http://lists.mesa3d.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] beta 3 release
Brian Paul [EMAIL PROTECTED] writes: I've checked in changes so that libGL.so.1.2.310 is built using the old Makefile scheme. Steve's been the only one to comment on my new numbering idea. I respect his opinion but I think I'll release 3.1 beta 3 with the 1.2.310 number and see what the response is. I was going to reply, but Steve's response was exactly what I would have said. There is a technical problem with using 310 for the patchlevel too - in this scheme, version 3.1.10 (3110) would appear to be a more recent version than 3.2.0 (320), when it is actually older. If you decide to encode the mesa version in the patchlevel number, you should give yourself at least two digits per number so the patchlevel will always increase (e.g. 3.1.0 = 030100). I'm hesitant to restart Mesa's version numbering at 1.2.0. I think there would be quite a bit of confusion. I think you would want to call Mesa "Mesa-3.1" and name the library "libGL.so.1.2.0". Josh ___ Mesa-dev maillist - [EMAIL PROTECTED] http://lists.mesa3d.org/mailman/listinfo/mesa-dev
RE: [Mesa-dev] beta 3 release
On 07-Sep-99 Brian Paul wrote: Here's another issue. There's an effort underway to standardize the OpenGL environment on Linux. One aspect of that is version numbering for the libGL.so file (used to be libMesaGL.so). I propose this lib name for the 3.1 release: libGL.so.1.2.310 The 1.2 designates an implementation of the 1.2 API specification. The 310 designates the Mesa version number (3.1.0). The main idea is to allow Linux OpenGL apps to relink with other OpenGL implementations at load/runtime. Comments? Two questions about this: 1) what group will be maintaining the GLU implementation? Will that stay with core Mesa? If I recall, the glx-dev group (working on the g200/g400/nvidia/ati drivers) does not build a glx library when you compile that setup, though you have to have already downloaded Mesa so I guess it's not too much of an issue. On the other hand, I think nvidia's reference implementation for linux *did* include its own glu library -- are these the same? Should people continue to look to Mesa for the de facto standard glu implementation? 2) What's the best way to handle multiple drivers for different chipsets? It almost seems like it would make sense to have each of the Mesa versions be named something to do with it's chipset -- ie libGx00GL.so.1.0, libVoodooGL.so.1.0, libRivaGL.so.1.0, etc, and then automagically symlink that file to libGL.so[.1[.0]] at compile/install time. I don't know a lot about the way ld works on systems aside from linux -- but doesn't the linux ld internally assign the root name of the library component? Could you set the internal library name to libGL.so.1.0 and then the name-on-the-hard-drive to the descriptive name, and then symlink around to make things work? Or is there a better way to handle this? On the one hand, I think this might become less and less of an issue as the Voodoo/Voodoo2 cards age and are replaced with 2D/3D combo cards, but the problem will probably pop up again -- isn't XF86 4 supposed to have multi-head support? How do you determine which libGL is the right one for each display in that case? Joe -Brian ___ Mesa-dev maillist - [EMAIL PROTECTED] http://lists.mesa3d.org/mailman/listinfo/mesa-dev -- Joe Waters ([EMAIL PROTECTED]) Aegis Simulation Technologies Shoot stuff. Break things. Impress your friends. We can help. Play BFRIS. http://www.aegistech.com ___ Mesa-dev maillist - [EMAIL PROTECTED] http://lists.mesa3d.org/mailman/listinfo/mesa-dev
RE: [Mesa-dev] beta 3 release
On 07-Sep-99 Brian Paul wrote: I propose this lib name for the 3.1 release: libGL.so.1.2.310 The 1.2 designates an implementation of the 1.2 API specification. The 310 designates the Mesa version number (3.1.0). The main idea is to allow Linux OpenGL apps to relink with other OpenGL implementations at load/runtime. Comments? I think that's the right thing to do... (GLX project libGL already uses libGL.so.1 so the current libGL.so.3 did not help much for binary compatibility) Andree ___ Mesa-dev maillist - [EMAIL PROTECTED] http://lists.mesa3d.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] beta 3 release
On Tue, 7 Sep 1999, Brian Paul wrote: Here's another issue. There's an effort underway to standardize the OpenGL environment on Linux. One aspect of that is version numbering for the libGL.so file (used to be libMesaGL.so). I propose this lib name for the 3.1 release: libGL.so.1.2.310 The 1.2 designates an implementation of the 1.2 API specification. The 310 designates the Mesa version number (3.1.0). The main idea is to allow Linux OpenGL apps to relink with other OpenGL implementations at load/runtime. Comments? I think that the Mesa numbering scheme should simply be the OpenGL version number and a consecutively incrementing third number. It's usual for the last number in a three part version number to represent bug fixes and optimisations, and the first two part to indicate changes that affect the API or user interface significantly. Since Mesa is just following the OpenGL API, the only time one of the higher up numbers should change is when OpenGL changes - and that's covered by picking the same version number as the OpenGL spec. So, I would simply renumber Mesa versions to continue from: 1.2.1 ...starting with the next release. I think that would be less confusing than running two sets of version numbers in parallel (1.2.310 *and* 3.1) - although there would of course be a small one-time confusion at the point of switch. (Does anyone even remember Mesa 1.x ?) 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] beta 3 release
On Tue, 7 Sep 1999, Brian Paul wrote: I'd like to make a 3.1 beta 3 release by the end of next week. Fellow developers, any concerns? Is anyone going to put in the glGetFuncAddressEXT stuff before then so we are essentially compliant with the new Linux OpenGL Base spec? 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] beta 3 release
Stephen J Baker wrote: On Tue, 7 Sep 1999, Brian Paul wrote: I'd like to make a 3.1 beta 3 release by the end of next week. Fellow developers, any concerns? Is anyone going to put in the glGetFuncAddressEXT stuff before then so we are essentially compliant with the new Linux OpenGL Base spec? I'll do it tonight. Should be easy. -Brian ___ Mesa-dev maillist - [EMAIL PROTECTED] http://lists.mesa3d.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] beta 3 release
Brian Paul wrote: I'd like to make a 3.1 beta 3 release by the end of next week. There have been quite a few bug fixes since beta 2 but I'm not quite confident enough that a final release is appropriate yet. I'd like to do more conformance testing and get more end user feedback. Sound great to me. I have a reasonable stable GGIMesa in CVS right now, and it would be nice to get a beta release out there which reflects this. Here's another issue. There's an effort underway to standardize the OpenGL environment on Linux. ...Which explicitly states that this "standardization effort" is predicated on the existence and use of X/GLX, and hence is not relevant for me. I just hope that non-X-based Mesa stuff does not get screwed over in the process Jon ___ Mesa-dev maillist - [EMAIL PROTECTED] http://lists.mesa3d.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] beta 3 release
2) What's the best way to handle multiple drivers for different chipsets? Well, the best way that I have found to handle it is to use GGIMesa, which lets you keep the exact same libGL.so core and dynamically load driver modules on a per-hardware or per-rendering-system basis. Jon ___ Mesa-dev maillist - [EMAIL PROTECTED] http://lists.mesa3d.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] beta 3 release
On Wed, 8 Sep 1999, Jon Taylor wrote: Here's another issue. There's an effort underway to standardize the OpenGL environment on Linux. ...Which explicitly states that this "standardization effort" is predicated on the existence and use of X/GLX, and hence is not relevant for me. I just hope that non-X-based Mesa stuff does not get screwed over in the process Well, all of the hardware OpenGL implementations for Linux look like being GLX-based - the only holdouts being the Voodoo-1/2's that *can't* be integrated into X. I think you may be out of luck as far as hardware-based rendering is concerned. 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] beta 3 release
Stephen J Baker wrote: On Wed, 8 Sep 1999, Jon Taylor wrote: Here's another issue. There's an effort underway to standardize the OpenGL environment on Linux. ...Which explicitly states that this "standardization effort" is predicated on the existence and use of X/GLX, and hence is not relevant for me. I just hope that non-X-based Mesa stuff does not get screwed over in the process Well, all of the hardware OpenGL implementations for Linux look like being GLX-based - the only holdouts being the Voodoo-1/2's that *can't* be integrated into X. Not all. I am writing a Savage4 KGI driver which is a kernel module. nVidia's HAL is also available as a kernel module, and others are writing Permidia KGI drivers. A G200/G400 KGI driver will probably also soon be forthcoming, since the GLX group got WARP engine specs. Jon ___ Mesa-dev maillist - [EMAIL PROTECTED] http://lists.mesa3d.org/mailman/listinfo/mesa-dev
RE: [Mesa-dev] beta 3 release
I'd like to make a 3.1 beta 3 release by the end of next week. There have been quite a few bug fixes since beta 2 but I'm not quite confident enough that a final release is appropriate yet. I'd like to do more conformance testing and get more end user feedback. Fellow developers, any concerns? I'll upload the 1.3 tessellation code so it can be go out with this release. Are there good conformance tests for the GLU tessellation? I'd be interested to see the output of those. I guess it will be several late nights to fix the winding rule bug before Friday week :-) -- Gareth ___ Mesa-dev maillist - [EMAIL PROTECTED] http://lists.mesa3d.org/mailman/listinfo/mesa-dev
