From owner-ogl-sample@oss.sgi.com Mon Oct 2 02:45:47 2000 Received: by oss.sgi.com id ; Mon, 2 Oct 2000 02:45:37 -0700 Received: from mail1.worldcom.ch ([212.74.176.11]:48324 "EHLO mail.worldcom.ch") by oss.sgi.com with ESMTP id ; Mon, 2 Oct 2000 02:45:07 -0700 Received: from cyberbotics.com ([212.74.183.57]) by mail.worldcom.ch (8.9.3+Sun/8.9.3) with ESMTP id LAA12796; Mon, 2 Oct 2000 11:44:00 +0200 (MET DST) Message-ID: <39D85C55.F644A7E6@cyberbotics.com> Date: Mon, 02 Oct 2000 11:58:45 +0200 From: Olivier Michel Organization: Cyberbotics Ltd. X-Mailer: Mozilla 4.7 [en] (X11; I; Linux 2.2.15-2.9.0 ppc) X-Accept-Language: en MIME-Version: 1.0 To: Craig Dunwoody CC: ogl-sample@oss.sgi.com, brianp@valinux.com Subject: Re: [ogl-sample] GLU SPECS file References: <200009290219.e8T2JVJ03086@dunwoody2.engr.sgi.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ogl-sample@oss.sgi.com Precedence: bulk Reply-To: ogl-sample@oss.sgi.com Return-Path: X-Orcpt: rfc822;ogl-sample-outgoing Craig Dunwoody wrote: > Please do send me the file. Done. > I haven't fully formed an opinion on what > to do here. The OpenGL-SI already has a GLU RPM spec file > (rpmspecs/oss-opengl-glu.spec), but I'm not sure how widely (if at > all) it has been used. I had a look at it, but I could not make any useful thing with it... (many apparently interesting things are actually commented out). Is it broken ? Are there any instructions on how to use it ? > The default Red Hat Linux 7.0 workstation installation includes "Mesa" > and "Mesa-devel" RPMs, which include the Mesa implementation of the > GLU API. The relatively coarse granularity of this packaging is > convenient in some ways, but it does make it more difficult for > developer-types to replace just one component (e.g. GLU), due to RPM > conflicts. Sure. I acknowledge this problem. > I would like to further explore longer-term OpenGL RPM packaging > options with folks who do this for some of the major distributions. > > For now, I think it does make sense to put GLU RPMs (based on your > packaging) up on the Mesa site, for the convenience of developers. I just sent them to Brian. > I'm less certain how much of an impact would result from changing the > GLU RPM packaging provided by the OpenGL-SI, but I'll be happy to take > a look at it. I believe that we have two options: Either (1) merge Mesa GL and SGI GLU into a single set of packages: Mesa and Mesa-devel: core Mesa GL and SGI GLU. Or (2) provide two sets of packages: Mesa and Mesa-devel: core Mesa GL without any GLU. oss-opengl-glu and oss-opengl-glu-devel: SGI GLU. The second option was completed (no major problem). The first option is however more user friendly since it makes no change for the user comparing to the current packaging granularity. Building the packages would in this case require Mesa source and SGI OpenGL source, but it's pretty easy to do with rpm. However, I don't know if there are legal issues about mixing differents packages that have different licenses into a single RPM... I guess that both copyright holders must agree before I can proceed... Anyway, in the future, it would be really nice to officially replace Mesa GLU by SGI OSS GLU in the Mesa source tree. That would make RPM packaging easier, and it would be more clear for the users (and more friendly for the developers using GLU tesselators...). -Olivier From owner-ogl-sample@oss.sgi.com Tue Oct 3 18:08:01 2000 Received: by oss.sgi.com id ; Tue, 3 Oct 2000 18:07:41 -0700 Received: from deliverator.sgi.com ([204.94.214.10]:26134 "EHLO deliverator.sgi.com") by oss.sgi.com with ESMTP id ; Tue, 3 Oct 2000 18:07:15 -0700 Received: from cthulhu.engr.sgi.com (cthulhu.engr.sgi.com [192.26.80.2]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id RAA26827 for ; Tue, 3 Oct 2000 17:58:46 -0700 (PDT) mail_from (dunwoody@dunwoody2.engr.sgi.com) Received: from dunwoody2.engr.sgi.com (dunwoody2.engr.sgi.com [130.62.54.148]) by cthulhu.engr.sgi.com (980427.SGI.8.8.8/970903.SGI.AUTOCF) via ESMTP id SAA90304; Tue, 3 Oct 2000 18:06:11 -0700 (PDT) mail_from (dunwoody@dunwoody2.engr.sgi.com) Received: from dunwoody2.engr.sgi.com (dunwoody@localhost) by dunwoody2.engr.sgi.com (8.11.0/8.11.0) with ESMTP id e9416B818332; Tue, 3 Oct 2000 18:06:11 -0700 Message-Id: <200010040106.e9416B818332@dunwoody2.engr.sgi.com> From: Craig Dunwoody To: Olivier Michel CC: ogl-sample@oss.sgi.com, brianp@valinux.com Subject: Re: [ogl-sample] GLU SPECS file In-Reply-To: Your message of "Mon, 02 Oct 2000 11:58:45 +0200." <39D85C55.F644A7E6@cyberbotics.com> Date: Tue, 03 Oct 2000 18:06:11 -0700 Sender: owner-ogl-sample@oss.sgi.com Precedence: bulk Reply-To: ogl-sample@oss.sgi.com Return-Path: X-Orcpt: rfc822;ogl-sample-outgoing Hi Olivier, Thanks for sending me your GLU RPM spec file. dunwoody writes: > I haven't fully formed an opinion on what > to do here. The OpenGL-SI already has a GLU RPM spec file > (rpmspecs/oss-opengl-glu.spec), but I'm not sure how widely (if at > all) it has been used. olivier writes: > I had a look at it, but I could not make any useful thing with it... > (many apparently interesting things are actually commented out). Is it > broken ? Are there any instructions on how to use it ? There are 3 RPM spec files currently in the SI tree under main/rpmspecs: oss-opengl-glu.spec oss-opengl-glw.spec oss-opengl-glman.spec I don't think they're necessarily broken. I am not aware of any instructions that go with them, and I haven't had a chance to try them myself. I'd like to have a chance to understand the problem a bit better, and participate in a larger discussion of OpenGL RPM packaging issues (as Brian suggested), before putting effort into rearranging the RPM packaging in the SI tree. In the meantime, I think adding your packages to the Mesa site is a good contribution. -c Craig Dunwoody dunwoody@sgi.com From owner-ogl-sample@oss.sgi.com Thu Oct 5 17:16:12 2000 Received: by oss.sgi.com id ; Thu, 5 Oct 2000 17:16:02 -0700 Received: from pneumatic-tube.sgi.com ([204.94.214.22]:38755 "EHLO pneumatic-tube.sgi.com") by oss.sgi.com with ESMTP id ; Thu, 5 Oct 2000 17:15:38 -0700 Received: from cthulhu.engr.sgi.com (cthulhu.engr.sgi.com [192.26.80.2]) by pneumatic-tube.sgi.com (980327.SGI.8.8.8-aspam/980310.SGI-aspam) via ESMTP id RAA09725 for ; Thu, 5 Oct 2000 17:22:41 -0700 (PDT) mail_from (dunwoody@dunwoody2.engr.sgi.com) Received: from dunwoody2.engr.sgi.com (dunwoody2.engr.sgi.com [130.62.54.148]) by cthulhu.engr.sgi.com (980427.SGI.8.8.8/970903.SGI.AUTOCF) via ESMTP id RAA01218 for ; Thu, 5 Oct 2000 17:15:22 -0700 (PDT) mail_from (dunwoody@dunwoody2.engr.sgi.com) Received: from dunwoody2.engr.sgi.com (dunwoody@localhost) by dunwoody2.engr.sgi.com (8.11.0/8.11.0) with ESMTP id e960FMQ03717 for ; Thu, 5 Oct 2000 17:15:22 -0700 Message-Id: <200010060015.e960FMQ03717@dunwoody2.engr.sgi.com> From: Craig Dunwoody To: ogl-sample@oss.sgi.com Subject: Re: [ogl-sample] internalformat param inconsistency In-Reply-To: Your message of "Sat, 09 Sep 2000 17:59:10 MDT." <39BACECE.B94C5360@valinux.com> Date: Thu, 05 Oct 2000 17:15:22 -0700 Sender: owner-ogl-sample@oss.sgi.com Precedence: bulk Reply-To: ogl-sample@oss.sgi.com Return-Path: X-Orcpt: rfc822;ogl-sample-outgoing Hi Brian, brianp@valinux.com writes: > Michael Vance at Loki found this one: > The GL_ARB_texture_compression spec says that the internalformat > parameter to glCompressedTexImage[123]DARB() should be a GLint. > However, the glext.h file (generated from gl.spec) has internalformat > as a GLenum. > ... > Can someone fix this, then generate a new glext.h file? I just asked Jon Leech about this, and it turns out the problem is that the GL_ARB_texture_compression spec document that is currently on the SGI Web site is slightly out of date wrt the final document that the ARB actually approved. We'll fix this problem shortly. Just before the document was approved by the ARB, a change was made to clarify that is indeed a GLenum. So the current glext.h is correct. -c Craig Dunwoody dunwoody@sgi.com From owner-ogl-sample@oss.sgi.com Fri Oct 6 07:45:41 2000 Received: by oss.sgi.com id ; Fri, 6 Oct 2000 07:45:30 -0700 Received: from smtp-fwd.valinux.com ([198.186.202.196]:25613 "EHLO mail.valinux.com") by oss.sgi.com with ESMTP id ; Fri, 6 Oct 2000 07:45:13 -0700 Received: from jens2.cmn.net ([207.174.125.34] helo=valinux.com) by mail.valinux.com with esmtp (Exim 3.16 #1 (Debian)) id 13hYkL-0001uT-00 for ; Fri, 06 Oct 2000 07:45:13 -0700 Message-ID: <39DDE555.E6ACF129@valinux.com> Date: Fri, 06 Oct 2000 08:44:37 -0600 From: Brian Paul Organization: VA Linux Systems, Inc. X-Mailer: Mozilla 4.72 [en] (X11; U; Linux 2.2.14-5.0 i686) X-Accept-Language: en MIME-Version: 1.0 To: ogl-sample@oss.sgi.com Subject: Re: [ogl-sample] internalformat param inconsistency References: <200010060015.e960FMQ03717@dunwoody2.engr.sgi.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ogl-sample@oss.sgi.com Precedence: bulk Reply-To: ogl-sample@oss.sgi.com Return-Path: X-Orcpt: rfc822;ogl-sample-outgoing Craig Dunwoody wrote: > > Hi Brian, > > brianp@valinux.com writes: > > Michael Vance at Loki found this one: > > The GL_ARB_texture_compression spec says that the internalformat > > parameter to glCompressedTexImage[123]DARB() should be a GLint. > > However, the glext.h file (generated from gl.spec) has internalformat > > as a GLenum. > > ... > > Can someone fix this, then generate a new glext.h file? > > I just asked Jon Leech about this, and it turns out the problem is > that the GL_ARB_texture_compression spec document that is currently on > the SGI Web site is slightly out of date wrt the final document that > the ARB actually approved. We'll fix this problem shortly. > > Just before the document was approved by the ARB, a change was made to > clarify that is indeed a GLenum. So the current > glext.h is correct. Thanks, Craig. -Brian From owner-ogl-sample@oss.sgi.com Tue Oct 24 09:38:15 2000 Received: by oss.sgi.com id ; Tue, 24 Oct 2000 09:38:05 -0700 Received: from smtp-fwd.valinux.com ([198.186.202.196]:4616 "EHLO mail.valinux.com") by oss.sgi.com with ESMTP id ; Tue, 24 Oct 2000 09:37:41 -0700 Received: from jens2.cmn.net ([207.174.125.34] helo=valinux.com) by mail.valinux.com with esmtp (Exim 3.16 #1 (Debian)) id 13o752-00072d-00 for ; Tue, 24 Oct 2000 09:37:40 -0700 Message-ID: <39F5BB1A.14F47684@valinux.com> Date: Tue, 24 Oct 2000 10:38:50 -0600 From: Brian Paul Organization: VA Linux Systems, Inc. X-Mailer: Mozilla 4.72 [en] (X11; U; Linux 2.2.14-5.0 i686) X-Accept-Language: en MIME-Version: 1.0 To: "ogl-sample@oss.sgi.com" Subject: [ogl-sample] gl.spec file missing offset values Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ogl-sample@oss.sgi.com Precedence: bulk Reply-To: ogl-sample@oss.sgi.com Return-Path: X-Orcpt: rfc822;ogl-sample-outgoing We want to implement the GL_EXT_secondary_color extension in Mesa. A number of Mesa/DRI's GL API dispatch files are generated from the gl.spec file included in the SI (just like the SI generates some similar files). Unfortunately, gl.spec (the one in OGLsample/projects/ogl-sample/main/doc/registry/specs/gl.spec) does not have 'offset' values assigned to the entrypoints for GL_EXT_secondary_color. A bunch of other extensions don't have offsets assigned either. We can't generate our dispatch files without this information. Can someone fix this, please? -Brian From owner-ogl-sample@oss.sgi.com Tue Oct 24 10:27:04 2000 Received: by oss.sgi.com id ; Tue, 24 Oct 2000 10:26:54 -0700 Received: from smtp-fwd.valinux.com ([198.186.202.196]:27151 "EHLO mail.valinux.com") by oss.sgi.com with ESMTP id ; Tue, 24 Oct 2000 10:26:36 -0700 Received: from jens2.cmn.net ([207.174.125.34] helo=valinux.com) by mail.valinux.com with esmtp (Exim 3.16 #1 (Debian)) id 13o7qN-0001RH-00 for ; Tue, 24 Oct 2000 10:26:36 -0700 Message-ID: <39F5C68E.7B2B5339@valinux.com> Date: Tue, 24 Oct 2000 11:27:42 -0600 From: Brian Paul Organization: VA Linux Systems, Inc. X-Mailer: Mozilla 4.72 [en] (X11; U; Linux 2.2.14-5.0 i686) X-Accept-Language: en MIME-Version: 1.0 To: ogl-sample@oss.sgi.com Subject: Re: [ogl-sample] gl.spec file missing offset values References: <39F5BB1A.14F47684@valinux.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ogl-sample@oss.sgi.com Precedence: bulk Reply-To: ogl-sample@oss.sgi.com Return-Path: X-Orcpt: rfc822;ogl-sample-outgoing Brian Paul wrote: > > We want to implement the GL_EXT_secondary_color extension in Mesa. > A number of Mesa/DRI's GL API dispatch files are generated from the > gl.spec file included in the SI (just like the SI generates some > similar files). > > Unfortunately, gl.spec (the one in > OGLsample/projects/ogl-sample/main/doc/registry/specs/gl.spec) > does not have 'offset' values assigned to the entrypoints for > GL_EXT_secondary_color. A bunch of other extensions don't have > offsets assigned either. We can't generate our dispatch files > without this information. > > Can someone fix this, please? I'd be happy to fix this myself and send in a patch. Would it be accepted? -Brian From owner-ogl-sample@oss.sgi.com Thu Oct 26 12:55:30 2000 Received: by oss.sgi.com id ; Thu, 26 Oct 2000 12:55:20 -0700 Received: from smtp-fwd.valinux.com ([198.186.202.196]:59909 "EHLO mail.valinux.com") by oss.sgi.com with ESMTP id ; Thu, 26 Oct 2000 12:54:58 -0700 Received: from jens2.cmn.net ([207.174.125.34] helo=valinux.com) by mail.valinux.com with esmtp (Exim 3.16 #1 (Debian)) id 13ot73-0008Ke-00 for ; Thu, 26 Oct 2000 12:54:57 -0700 Message-ID: <39F88C43.4A6B3D4C@valinux.com> Date: Thu, 26 Oct 2000 13:55:47 -0600 From: Brian Paul Organization: VA Linux Systems, Inc. X-Mailer: Mozilla 4.72 [en] (X11; U; Linux 2.2.14-5.0 i686) X-Accept-Language: en MIME-Version: 1.0 To: ogl-sample@oss.sgi.com Subject: Re: [ogl-sample] gl.spec file missing offset values References: <39F5BB1A.14F47684@valinux.com> <39F5C68E.7B2B5339@valinux.com> Content-Type: multipart/mixed; boundary="------------24EBAD91A40F3A16828FED72" Sender: owner-ogl-sample@oss.sgi.com Precedence: bulk Reply-To: ogl-sample@oss.sgi.com Return-Path: X-Orcpt: rfc822;ogl-sample-outgoing This is a multi-part message in MIME format. --------------24EBAD91A40F3A16828FED72 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Brian Paul wrote: > > Brian Paul wrote: > > > > We want to implement the GL_EXT_secondary_color extension in Mesa. > > A number of Mesa/DRI's GL API dispatch files are generated from the > > gl.spec file included in the SI (just like the SI generates some > > similar files). > > > > Unfortunately, gl.spec (the one in > > OGLsample/projects/ogl-sample/main/doc/registry/specs/gl.spec) > > does not have 'offset' values assigned to the entrypoints for > > GL_EXT_secondary_color. A bunch of other extensions don't have > > offsets assigned either. We can't generate our dispatch files > > without this information. > > > > Can someone fix this, please? > > I'd be happy to fix this myself and send in a patch. Would it be > accepted? I've filled in the dispatch offsets that we need, starting with 561. Below is a context-diff patch. Will someone at SGI please apply this, or fill in those offsets as you see fit? Thanks. -Brian --------------24EBAD91A40F3A16828FED72 Content-Type: text/plain; charset=us-ascii; name="gl.spec.diff" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="gl.spec.diff" *** gl.spec.orig Thu Oct 26 13:48:33 2000 --- gl.spec Thu Oct 26 13:52:06 2000 *************** *** 69,75 **** # 2048-2082 (SGI extensions) # 4096-4123 (1.2 core and multivendor EXT) # 4124-4142 (EXT extensions) ! # XFree86 dispatch offsets: 0-560 # # New opcodes and offsets must be allocated by SGI in the master registry file; # a copy of this is in doc/registry/extensions/extensions.reserved, but only --- 69,75 ---- # 2048-2082 (SGI extensions) # 4096-4123 (1.2 core and multivendor EXT) # 4124-4142 (EXT extensions) ! # XFree86 dispatch offsets: 0-577 # # New opcodes and offsets must be allocated by SGI in the master registry file; # a copy of this is in doc/registry/extensions/extensions.reserved, but only *************** *** 8022,8028 **** category EXT_secondary_color vectorequiv SecondaryColor3bvEXT version 1.1 ! offset ? SecondaryColor3bvEXT(v) return void --- 8022,8028 ---- category EXT_secondary_color vectorequiv SecondaryColor3bvEXT version 1.1 ! offset 561 SecondaryColor3bvEXT(v) return void *************** *** 8031,8037 **** version 1.1 glxropcode ? glsopcode ? ! offset ? SecondaryColor3dEXT(red, green, blue) return void --- 8031,8037 ---- version 1.1 glxropcode ? glsopcode ? ! offset 562 SecondaryColor3dEXT(red, green, blue) return void *************** *** 8041,8047 **** category EXT_secondary_color vectorequiv SecondaryColor3dvEXT version 1.1 ! offset ? SecondaryColor3dvEXT(v) return void --- 8041,8047 ---- category EXT_secondary_color vectorequiv SecondaryColor3dvEXT version 1.1 ! offset 563 SecondaryColor3dvEXT(v) return void *************** *** 8050,8056 **** version 1.1 glxropcode ? glsopcode ? ! offset ? SecondaryColor3fEXT(red, green, blue) return void --- 8050,8056 ---- version 1.1 glxropcode ? glsopcode ? ! offset 564 SecondaryColor3fEXT(red, green, blue) return void *************** *** 8060,8066 **** category EXT_secondary_color vectorequiv SecondaryColor3fvEXT version 1.1 ! offset ? SecondaryColor3fvEXT(v) return void --- 8060,8066 ---- category EXT_secondary_color vectorequiv SecondaryColor3fvEXT version 1.1 ! offset 565 SecondaryColor3fvEXT(v) return void *************** *** 8069,8075 **** version 1.1 glxropcode ? glsopcode ? ! offset ? SecondaryColor3iEXT(red, green, blue) return void --- 8069,8075 ---- version 1.1 glxropcode ? glsopcode ? ! offset 566 SecondaryColor3iEXT(red, green, blue) return void *************** *** 8079,8085 **** category EXT_secondary_color vectorequiv SecondaryColor3ivEXT version 1.1 ! offset ? SecondaryColor3ivEXT(v) return void --- 8079,8085 ---- category EXT_secondary_color vectorequiv SecondaryColor3ivEXT version 1.1 ! offset 567 SecondaryColor3ivEXT(v) return void *************** *** 8088,8094 **** version 1.1 glxropcode ? glsopcode ? ! offset ? SecondaryColor3sEXT(red, green, blue) return void --- 8088,8094 ---- version 1.1 glxropcode ? glsopcode ? ! offset 568 SecondaryColor3sEXT(red, green, blue) return void *************** *** 8098,8104 **** category EXT_secondary_color vectorequiv SecondaryColor3svEXT version 1.1 ! offset ? SecondaryColor3svEXT(v) return void --- 8098,8104 ---- category EXT_secondary_color vectorequiv SecondaryColor3svEXT version 1.1 ! offset 569 SecondaryColor3svEXT(v) return void *************** *** 8107,8113 **** version 1.1 glxropcode ? glsopcode ? ! offset ? SecondaryColor3ubEXT(red, green, blue) return void --- 8107,8113 ---- version 1.1 glxropcode ? glsopcode ? ! offset 570 SecondaryColor3ubEXT(red, green, blue) return void *************** *** 8117,8123 **** category EXT_secondary_color vectorequiv SecondaryColor3ubvEXT version 1.1 ! offset ? SecondaryColor3ubvEXT(v) return void --- 8117,8123 ---- category EXT_secondary_color vectorequiv SecondaryColor3ubvEXT version 1.1 ! offset 571 SecondaryColor3ubvEXT(v) return void *************** *** 8126,8132 **** version 1.1 glxropcode ? glsopcode ? ! offset ? SecondaryColor3uiEXT(red, green, blue) return void --- 8126,8132 ---- version 1.1 glxropcode ? glsopcode ? ! offset 572 SecondaryColor3uiEXT(red, green, blue) return void *************** *** 8136,8142 **** category EXT_secondary_color vectorequiv SecondaryColor3uivEXT version 1.1 ! offset ? SecondaryColor3uivEXT(v) return void --- 8136,8142 ---- category EXT_secondary_color vectorequiv SecondaryColor3uivEXT version 1.1 ! offset 573 SecondaryColor3uivEXT(v) return void *************** *** 8145,8151 **** version 1.1 glxropcode ? glsopcode ? ! offset ? SecondaryColor3usEXT(red, green, blue) return void --- 8145,8151 ---- version 1.1 glxropcode ? glsopcode ? ! offset 574 SecondaryColor3usEXT(red, green, blue) return void *************** *** 8155,8161 **** category EXT_secondary_color vectorequiv SecondaryColor3usvEXT version 1.1 ! offset ? SecondaryColor3usvEXT(v) return void --- 8155,8161 ---- category EXT_secondary_color vectorequiv SecondaryColor3usvEXT version 1.1 ! offset 575 SecondaryColor3usvEXT(v) return void *************** *** 8164,8170 **** version 1.1 glxropcode ? glsopcode ? ! offset ? # pointer is really 'in' SecondaryColorPointerEXT(size, type, stride, pointer) --- 8164,8170 ---- version 1.1 glxropcode ? glsopcode ? ! offset 576 # pointer is really 'in' SecondaryColorPointerEXT(size, type, stride, pointer) *************** *** 8180,8186 **** extension glsflags client glsopcode ? ! offset ? ############################################################################### # --- 8180,8186 ---- extension glsflags client glsopcode ? ! offset 577 ############################################################################### # --------------24EBAD91A40F3A16828FED72-- From owner-ogl-sample@oss.sgi.com Thu Oct 26 13:14:01 2000 Received: by oss.sgi.com id ; Thu, 26 Oct 2000 13:13:52 -0700 Received: from deliverator.sgi.com ([204.94.214.10]:33863 "EHLO deliverator.sgi.com") by oss.sgi.com with ESMTP id ; Thu, 26 Oct 2000 13:13:40 -0700 Received: from arioch.engr.sgi.com (arioch.engr.sgi.com [130.62.54.161]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id NAA10743 for ; Thu, 26 Oct 2000 13:05:51 -0700 (PDT) mail_from (shreiner@arioch.engr.sgi.com) Received: (from shreiner@localhost) by arioch.engr.sgi.com (SGI-8.9.3/8.9.3) id NAA41739; Thu, 26 Oct 2000 13:12:24 -0700 (PDT) From: Dave Shreiner MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Thu, 26 Oct 2000 13:12:23 -0700 (PDT) To: ogl-sample@oss.sgi.com Subject: Re: [ogl-sample] gl.spec file missing offset values In-Reply-To: <39F88C43.4A6B3D4C@valinux.com> References: <39F5BB1A.14F47684@valinux.com> <39F5C68E.7B2B5339@valinux.com> <39F88C43.4A6B3D4C@valinux.com> X-Mailer: VM 6.43 under 20.4 "Emerald" XEmacs Lucid Message-ID: <14840.36846.524940.701707@arioch.engr.sgi.com> Sender: owner-ogl-sample@oss.sgi.com Precedence: bulk Reply-To: ogl-sample@oss.sgi.com Return-Path: X-Orcpt: rfc822;ogl-sample-outgoing Hey Brian, Please send me the patch, and I'll put it into the tree. Thanks, and sorry for the quietness on the list. -- Thanx, Dave --------------------------------------------------------------------- Dave Shreiner Silicon Graphics, Inc. (650) 933-4899 From owner-ogl-sample@oss.sgi.com Thu Oct 26 13:24:01 2000 Received: by oss.sgi.com id ; Thu, 26 Oct 2000 13:23:52 -0700 Received: from [63.229.11.18] ([63.229.11.18]:63504 "EHLO akira.wiess.net") by oss.sgi.com with ESMTP id ; Thu, 26 Oct 2000 13:23:36 -0700 Received: from w-link.net (IDENT:quark@localhost.localdomain [127.0.0.1]) by akira.wiess.net (8.9.3/8.9.3) with ESMTP id NAA04523 for ; Thu, 26 Oct 2000 13:22:22 -0700 Message-ID: <39F8927E.5CBE46AB@w-link.net> Date: Thu, 26 Oct 2000 13:22:22 -0700 From: Tim Wiess X-Mailer: Mozilla 4.72 [en] (X11; U; Linux 2.2.14-5.0smp i686) X-Accept-Language: en MIME-Version: 1.0 To: ogl-sample@oss.sgi.com Subject: [ogl-sample] DGL? Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ogl-sample@oss.sgi.com Precedence: bulk Reply-To: ogl-sample@oss.sgi.com Return-Path: X-Orcpt: rfc822;ogl-sample-outgoing I apologize if this question was answered already: I was wondering if SGI will be porting their DGL libraries to Linux. Thanks. Tim From owner-ogl-sample@oss.sgi.com Thu Oct 26 13:32:52 2000 Received: by oss.sgi.com id ; Thu, 26 Oct 2000 13:32:41 -0700 Received: from pneumatic-tube.sgi.com ([204.94.214.22]:57683 "EHLO pneumatic-tube.sgi.com") by oss.sgi.com with ESMTP id ; Thu, 26 Oct 2000 13:32:27 -0700 Received: from arioch.engr.sgi.com (arioch.engr.sgi.com [130.62.54.161]) by pneumatic-tube.sgi.com (980327.SGI.8.8.8-aspam/980310.SGI-aspam) via ESMTP id NAA06054 for ; Thu, 26 Oct 2000 13:39:52 -0700 (PDT) mail_from (shreiner@arioch.engr.sgi.com) Received: (from shreiner@localhost) by arioch.engr.sgi.com (SGI-8.9.3/8.9.3) id NAA43327; Thu, 26 Oct 2000 13:31:11 -0700 (PDT) From: Dave Shreiner MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Thu, 26 Oct 2000 13:31:10 -0700 (PDT) To: ogl-sample@oss.sgi.com Subject: Re: [ogl-sample] DGL? In-Reply-To: <39F8927E.5CBE46AB@w-link.net> References: <39F8927E.5CBE46AB@w-link.net> X-Mailer: VM 6.43 under 20.4 "Emerald" XEmacs Lucid Message-ID: <14840.37886.972479.43933@arioch.engr.sgi.com> Sender: owner-ogl-sample@oss.sgi.com Precedence: bulk Reply-To: ogl-sample@oss.sgi.com Return-Path: X-Orcpt: rfc822;ogl-sample-outgoing HI Tim< > I apologize if this question was answered already: > I was wondering if SGI will be porting their DGL libraries to Linux. Do you mean the "Distributed Graphics Library" component that was part of IRIS GL? If so, I'm pretty sure the answer is "definitely not". Hope that isn't too much a problem. -- Thanx, Dave --------------------------------------------------------------------- Dave Shreiner Silicon Graphics, Inc. (650) 933-4899 From owner-ogl-sample@oss.sgi.com Thu Oct 26 14:52:03 2000 Received: by oss.sgi.com id ; Thu, 26 Oct 2000 14:51:53 -0700 Received: from smtp-fwd.valinux.com ([198.186.202.196]:64007 "EHLO mail.valinux.com") by oss.sgi.com with ESMTP id ; Thu, 26 Oct 2000 14:51:36 -0700 Received: from jens2.cmn.net ([207.174.125.34] helo=valinux.com) by mail.valinux.com with esmtp (Exim 3.16 #1 (Debian)) id 13ouvv-0006Py-00 for ; Thu, 26 Oct 2000 14:51:36 -0700 Message-ID: <39F8A79B.9733DE00@valinux.com> Date: Thu, 26 Oct 2000 15:52:27 -0600 From: Brian Paul Organization: VA Linux Systems, Inc. X-Mailer: Mozilla 4.72 [en] (X11; U; Linux 2.2.14-5.0 i686) X-Accept-Language: en MIME-Version: 1.0 To: ogl-sample@oss.sgi.com Subject: Re: [ogl-sample] gl.spec file missing offset values References: <39F5BB1A.14F47684@valinux.com> <39F5C68E.7B2B5339@valinux.com> <39F88C43.4A6B3D4C@valinux.com> <14840.36846.524940.701707@arioch.engr.sgi.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ogl-sample@oss.sgi.com Precedence: bulk Reply-To: ogl-sample@oss.sgi.com Return-Path: X-Orcpt: rfc822;ogl-sample-outgoing Dave Shreiner wrote: > > Hey Brian, > > Please send me the patch, and I'll put it into the tree. You should have seen it by now. Thanks! > Thanks, and sorry for the quietness on the list. I'm sorry if I sounded impatient but when you need something you often _really_ need it. :) -Brian From owner-ogl-sample@oss.sgi.com Thu Oct 26 15:00:03 2000 Received: by oss.sgi.com id ; Thu, 26 Oct 2000 14:59:54 -0700 Received: from [63.229.11.18] ([63.229.11.18]:10002 "EHLO akira.wiess.net") by oss.sgi.com with ESMTP id ; Thu, 26 Oct 2000 14:59:38 -0700 Received: from w-link.net (IDENT:quark@localhost.localdomain [127.0.0.1]) by akira.wiess.net (8.9.3/8.9.3) with ESMTP id OAA04713 for ; Thu, 26 Oct 2000 14:58:25 -0700 Message-ID: <39F8A901.214D2968@w-link.net> Date: Thu, 26 Oct 2000 14:58:25 -0700 From: Tim Wiess X-Mailer: Mozilla 4.72 [en] (X11; U; Linux 2.2.14-5.0smp i686) X-Accept-Language: en MIME-Version: 1.0 To: ogl-sample@oss.sgi.com Subject: [ogl-sample] Re: DGL? Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ogl-sample@oss.sgi.com Precedence: bulk Reply-To: ogl-sample@oss.sgi.com Return-Path: X-Orcpt: rfc822;ogl-sample-outgoing Dave, > Do you mean the "Distributed Graphics Library" That is what I meant, but I thought DGL was also incorporated into Open GL. Nevermind then. Thanks for the info. Tim From owner-ogl-sample@oss.sgi.com Thu Oct 26 15:22:54 2000 Received: by oss.sgi.com id ; Thu, 26 Oct 2000 15:22:34 -0700 Received: from deliverator.sgi.com ([204.94.214.10]:42103 "EHLO deliverator.sgi.com") by oss.sgi.com with ESMTP id ; Thu, 26 Oct 2000 15:22:26 -0700 Received: from oddhack.engr.sgi.com (oddhack.engr.sgi.com [130.62.54.158]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id PAA05095 for ; Thu, 26 Oct 2000 15:14:38 -0700 (PDT) mail_from (ljp@oddhack.engr.sgi.com) Received: (from ljp@localhost) by oddhack.engr.sgi.com (SGI-8.9.3/8.9.3) id PAA94863; Thu, 26 Oct 2000 15:21:12 -0700 (PDT) Message-ID: <20001026152112.A296867@oddhack.engr.sgi.com> Date: Thu, 26 Oct 2000 15:21:12 -0700 From: Jon Leech To: ogl-sample@oss.sgi.com Subject: Re: [ogl-sample] Re: DGL? References: <39F8A901.214D2968@w-link.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.91.1 In-Reply-To: <39F8A901.214D2968@w-link.net>; from Tim Wiess on Thu, Oct 26, 2000 at 02:58:25PM -0700 Sender: owner-ogl-sample@oss.sgi.com Precedence: bulk Reply-To: ogl-sample@oss.sgi.com Return-Path: X-Orcpt: rfc822;ogl-sample-outgoing On Thu, Oct 26, 2000 at 02:58:25PM -0700, Tim Wiess wrote: > Dave, > > > Do you mean the "Distributed Graphics Library" > > That is what I meant, but I thought DGL was also incorporated into > Open GL. DGL is the remote transport layer for IrisGL, SGI's older 3D API. Both DGL and IrisGL greatly predate OpenGL, and neither were designed for crossplatform use. Jon Leech SGI From owner-ogl-sample@oss.sgi.com Fri Oct 27 08:01:11 2000 Received: by oss.sgi.com id ; Fri, 27 Oct 2000 08:00:51 -0700 Received: from sunmgr.hti.com ([130.210.206.69]:8402 "EHLO issun6.hti.com") by oss.sgi.com with ESMTP id ; Fri, 27 Oct 2000 08:00:29 -0700 Received: from issun5.hti.com ([130.210.202.3]) by issun6.hti.com (Netscape Messaging Server 3.6) with ESMTP id AAA10E for ; Fri, 27 Oct 2000 09:48:52 -0500 Received: from sutcliffe.bgm.link.com ([130.210.63.42]) by issun5.hti.com (Netscape Messaging Server 3.6) with SMTP id AAA721E for ; Fri, 27 Oct 2000 10:00:55 -0500 Date: Fri, 27 Oct 2000 10:00:21 -0500 (CDT) From: "Stephen J Baker" X-Sender: steve@sutcliffe.bgm.link.com To: ogl-sample@oss.sgi.com Subject: Re: [ogl-sample] Re: DGL? In-Reply-To: <39F8A901.214D2968@w-link.net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ogl-sample@oss.sgi.com Precedence: bulk Reply-To: ogl-sample@oss.sgi.com Return-Path: X-Orcpt: rfc822;ogl-sample-outgoing On Thu, 26 Oct 2000, Tim Wiess wrote: > Dave, > > > Do you mean the "Distributed Graphics Library" > > That is what I meant, but I thought DGL was also incorporated into > Open GL. I think you are thinking of the GLX protocol - which IS appearing under Linux. That's the thing that lets you run a program on one computer and have the OpenGL be rendered on another (as opposed to simply having the pixels being sent across the net after rendering is complete). ---- Steve Baker (817)619-2657 (Vox/Vox-Mail) L3Com/Link Simulation & Training (817)619-2466 (Fax) Work: sjbaker@link.com http://www.link.com Home: sjbaker1@airmail.net http://web2.airmail.net/sjbaker1 From owner-ogl-sample@oss.sgi.com Fri Oct 27 11:12:53 2000 Received: by oss.sgi.com id ; Fri, 27 Oct 2000 11:12:43 -0700 Received: from smtp-fwd.valinux.com ([198.186.202.196]:63759 "EHLO mail.valinux.com") by oss.sgi.com with ESMTP id ; Fri, 27 Oct 2000 11:12:28 -0700 Received: from jens2.cmn.net ([207.174.125.34] helo=valinux.com) by mail.valinux.com with esmtp (Exim 3.16 #1 (Debian)) id 13pDzQ-0006SP-00 for ; Fri, 27 Oct 2000 11:12:28 -0700 Message-ID: <39F9C5B8.B0390D17@valinux.com> Date: Fri, 27 Oct 2000 12:13:12 -0600 From: Brian Paul Organization: VA Linux Systems, Inc. X-Mailer: Mozilla 4.72 [en] (X11; U; Linux 2.2.14-5.0 i686) X-Accept-Language: en MIME-Version: 1.0 To: ogl-sample@oss.sgi.com Subject: Re: [ogl-sample] gl.spec file missing offset values References: <39F5BB1A.14F47684@valinux.com> <39F5C68E.7B2B5339@valinux.com> <39F88C43.4A6B3D4C@valinux.com> <14840.36846.524940.701707@arioch.engr.sgi.com> <39F8A79B.9733DE00@valinux.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ogl-sample@oss.sgi.com Precedence: bulk Reply-To: ogl-sample@oss.sgi.com Return-Path: X-Orcpt: rfc822;ogl-sample-outgoing There's another problem in gl.spec related to GL_EXT_secondary_color. >From the gl.spec file: # pointer is really 'in' SecondaryColorPointerEXT(size, type, stride, pointer) return void param size Int32 in value param type ColorPointerType in value param stride SizeI in value param pointer Void out array [COMPSIZE(size/type/stride)] retained category EXT_secondary_color dlflags notlistable glxflags client-handcode server-handcode EXT version 1.1 extension glsflags client glsopcode ? offset ? As the comment says, the pointer parameter should be an "in" array, not an "out" array. Can that be fixed as well? -Brian From owner-ogl-sample@oss.sgi.com Fri Oct 27 11:28:24 2000 Received: by oss.sgi.com id ; Fri, 27 Oct 2000 11:28:14 -0700 Received: from smtp-fwd.valinux.com ([198.186.202.196]:55825 "EHLO mail.valinux.com") by oss.sgi.com with ESMTP id ; Fri, 27 Oct 2000 11:27:49 -0700 Received: from jens2.cmn.net ([207.174.125.34] helo=valinux.com) by mail.valinux.com with esmtp (Exim 3.16 #1 (Debian)) id 13pEED-0007Cj-00 for ; Fri, 27 Oct 2000 11:27:45 -0700 Message-ID: <39F9C94E.2169F929@valinux.com> Date: Fri, 27 Oct 2000 12:28:30 -0600 From: Brian Paul Organization: VA Linux Systems, Inc. X-Mailer: Mozilla 4.72 [en] (X11; U; Linux 2.2.14-5.0 i686) X-Accept-Language: en MIME-Version: 1.0 To: ogl-sample@oss.sgi.com Subject: [ogl-sample] problem in gl.spec: DeleteTexturesEXT Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ogl-sample@oss.sgi.com Precedence: bulk Reply-To: ogl-sample@oss.sgi.com Return-Path: X-Orcpt: rfc822;ogl-sample-outgoing I believe the gl.spec entry for glDeleteTexturesEXT is missing an 'alias' line: DeleteTexturesEXT(n, textures) return void param n SizeI in value param textures Texture in array [n] category EXT_texture_object dlflags notlistable version 1.0 glxflags EXT glxvendorpriv 12 extension glsopcode 0x0149 I went back through some old versions of gl.spec and found that in version 1.2 of the file there was an alias: alias DeleteTextures But in version 1.3 of gl.spec it was removed. The check-in log for version 1.3 is: revision 1.3 date: 2000/05/16 23:24:14; author: ljp; state: Exp; lines: +105 -53 Update spec file with new opcodes, fixed function names. Allow generating glext.h with or without prototypes. Minor build and man page tweaks. Perhaps this was an accidental delete. Can this be fixed, please? -Brian From owner-ogl-sample@oss.sgi.com Mon Oct 30 16:11:11 2000 Received: by oss.sgi.com id ; Mon, 30 Oct 2000 16:11:01 -0800 Received: from smtp-fwd.valinux.com ([198.186.202.196]:26374 "EHLO mail.valinux.com") by oss.sgi.com with ESMTP id ; Mon, 30 Oct 2000 16:10:39 -0800 Received: from jens2.cmn.net ([207.174.125.34] helo=valinux.com) by mail.valinux.com with esmtp (Exim 3.16 #1 (Debian)) id 13qP0Z-0007md-00; Mon, 30 Oct 2000 16:10:31 -0800 Message-ID: <39FE0E05.CE10A154@valinux.com> Date: Mon, 30 Oct 2000 17:10:45 -0700 From: Brian Paul Organization: VA Linux Systems, Inc. X-Mailer: Mozilla 4.72 [en] (X11; U; Linux 2.2.14-5.0 i686) X-Accept-Language: en MIME-Version: 1.0 To: Dave Shreiner CC: ogl-sample@oss.sgi.com Subject: Re: [ogl-sample] gl.spec file missing offset values References: <14845.58250.506669.313124@arioch.engr.sgi.com> <39FDE614.B340AEE7@valinux.com> <14846.3002.95992.559934@arioch.engr.sgi.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ogl-sample@oss.sgi.com Precedence: bulk Reply-To: ogl-sample@oss.sgi.com Return-Path: X-Orcpt: rfc822;ogl-sample-outgoing Dave Shreiner wrote: > > Hi Brian, > > I've added all the changes with the exception of the "alias > DeleteTextures" one. Since glDeleteTexturesEXT() and glDeleteTextures() > aren't strictly aliases of each other (there's an issue with their > associated GLX protocol), that alias doesn't fit. Why did you want them > aliased, and is there some other approach that we could reach a > consensus on? It'd be better to know direct from the source, as > compared to trying to second guess what you're thinking. I explained the "alias DeleteTextures" in another email last week. Didn't that go through either??? I can live without that fix but if it's not an alias function then it should have its own dispatch offset. Here's the original message again: ---- I believe the gl.spec entry for glDeleteTexturesEXT is missing an 'alias' line: DeleteTexturesEXT(n, textures) return void param n SizeI in value param textures Texture in array [n] category EXT_texture_object dlflags notlistable version 1.0 glxflags EXT glxvendorpriv 12 extension glsopcode 0x0149 I went back through some old versions of gl.spec and found that in version 1.2 of the file there was an alias: alias DeleteTextures But in version 1.3 of gl.spec it was removed. The check-in log for version 1.3 is: revision 1.3 date: 2000/05/16 23:24:14; author: ljp; state: Exp; lines: +105 -53 Update spec file with new opcodes, fixed function names. Allow generating glext.h with or without prototypes. Minor build and man page tweaks. Perhaps this was an accidental delete. Can this be fixed, please? -Brian From owner-ogl-sample@oss.sgi.com Mon Oct 30 16:17:41 2000 Received: by oss.sgi.com id ; Mon, 30 Oct 2000 16:17:32 -0800 Received: from pneumatic-tube.sgi.com ([204.94.214.22]:61759 "EHLO pneumatic-tube.sgi.com") by oss.sgi.com with ESMTP id ; Mon, 30 Oct 2000 16:17:18 -0800 Received: from arioch.engr.sgi.com (arioch.engr.sgi.com [130.62.54.161]) by pneumatic-tube.sgi.com (980327.SGI.8.8.8-aspam/980310.SGI-aspam) via ESMTP id QAA04017 for ; Mon, 30 Oct 2000 16:15:03 -0800 (PST) mail_from (shreiner@arioch.engr.sgi.com) Received: (from shreiner@localhost) by arioch.engr.sgi.com (SGI-8.9.3/8.9.3) id QAA50790; Mon, 30 Oct 2000 16:05:21 -0800 (PST) From: Dave Shreiner MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Mon, 30 Oct 2000 16:05:21 -0800 (PST) To: Brian Paul Cc: ogl-sample@oss.sgi.com Subject: Re: [ogl-sample] gl.spec file missing offset values In-Reply-To: <39FDE614.B340AEE7@valinux.com> References: <14845.58250.506669.313124@arioch.engr.sgi.com> <39FDE614.B340AEE7@valinux.com> X-Mailer: VM 6.43 under 20.4 "Emerald" XEmacs Lucid Message-ID: <14846.3002.95992.559934@arioch.engr.sgi.com> Sender: owner-ogl-sample@oss.sgi.com Precedence: bulk Reply-To: ogl-sample@oss.sgi.com Return-Path: X-Orcpt: rfc822;ogl-sample-outgoing Hi Brian, I've added all the changes with the exception of the "alias DeleteTextures" one. Since glDeleteTexturesEXT() and glDeleteTextures() aren't strictly aliases of each other (there's an issue with their associated GLX protocol), that alias doesn't fit. Why did you want them aliased, and is there some other approach that we could reach a consensus on? It'd be better to know direct from the source, as compared to trying to second guess what you're thinking. Thanks. -- Thanx, Dave --------------------------------------------------------------------- Dave Shreiner Silicon Graphics, Inc. (650) 933-4899