ARB Meeting Notes ARB Meeting NotesHosted by Digital Equipment Corp. in Boston, MA
Meeting notes taken by Randi Rost, HP
Thanks to these people for constructive comments on the meeting notes: Bimal Poddar, Pat Brown, Jim Cobb, Bill Sweeney, Bill Armstrong, and Andy Vesper.
| Dale Kirkland | Intergraph | kirkland@ingr.com |
| Chris Kokkinos | Parametric Technologies | chris@ptc.com |
| Randi Rost | HP | rost@fc.hp.com |
| Kevin Lefebvre | HP | kevinl@fc.hp.com |
| Bill Sweeney | SunSoft | william.sweeney@Eng.sun.com |
| Andy Vesper | Digital | andy.vesper@eng.pko.dec.com |
| Henri Warren | Megatek | warren@megatek.com |
| Mike Cripps | AccelGraphics | mikec@ag3d.com |
| Igor Sinyak | Intel | Igor_Sinyak@ccm.sc.intel.com |
| Pat Brown | IBM | pbrown@austin.ibm.com |
| John Schimpf | SGI | jsch@asd.sgi.com |
| Phil Huxley | 3Dlabs | phil.Huxley@3Dlabs.com |
| Tim Hall | Parametric Technology | thall@ptc.com |
| John Dennis | DEC | jdennis@eng.pko.dec.com |
| Steve Cochran | Real 3D | steven_h_cochran@ccmail.orl.mmc.com |
| Paula Womack | SGI | womack@sgi.com |
| Jim Cobb | Parametric Technology | jcobb@ptc.com |
| Hock San Lee | Microsoft | hockl@microsoft.com |
| Ken Garnett | NCD | keg@ncd.com |
| Steve Wright | Microsoft | swright@microsoft.com |
| Kurt Akeley | SGI | kurt@sgi.com |
| Drew Bliss | Microsoft | drewb@microsoft.com |
| Bimal Poddar | IBM | poddar@austin.ib.com |
| Bill Armstrong | E & S | armstron@es.com |
| Craig Dunwoody | SGI | dunwoody@sgi.com |
Andy V. asks if their should be a forward reference on p. 50 of the spec to the discussion of how evaluators affect the current color on p. 130. We agree that the discussion on p. 130 is accurate. There is a history of trying to minimize the number of forward references in the spec, so the consensus is to leave this unchanged.
Jim C. asks for a clarification of the max texture size constant. In the spec, this value is defined only in the table in Ch. 6, and there it only defines the name of the constant, its type, etc. It doesn't really define it. The man page in the blue book goes a little farther in defining this constant, but the discussion is still unclear. Jim would like to see the ARB make a clear statement about this value and how it should be used. Kurt thinks it will be messy to try to change the table in Ch. 6 to include a definition of the max texture size (right now, the table only defines the minimum value that is allowed for this implementation-dependent constant). Kurt will try to develop a proposal to resolve this over lunch.
SGI has started to develop an implementation of OpenGL for Intel platforms. This started out as an experiment in order to prove to people that an efficient implementation of OpenGL could be written for low-end platforms. SGI also wants to be able to provide this implementation to licensees so that they need not start from scratch on an implementation for Windows. SGI has also been thinking about how to modify the current licensing agreement to allow more widespread usage on PC's. SGI is likely to make available a binary at no cost in order to promote widespread usage of OpenGL. The implementation is not product quality yet, but if/when SGI gets it to product quality status, their intent is to make it available to OpenGL source code licensees. This work has also given SGI some ideas about extensions that might be needed to make OpenGL more useful on the PC platform. John S. thinks that by the next ARB meeting, SGI can give a more definitive statement about this effort. This implementation will be different than the SI in that it will be highly tuned for the Intel platform, and it will include lots of assembly code.
Steve W. reiterates that Microsoft supports the OpenGL effort. OpenGL is going into beta for Windows '95, and will be available in an OEM release in the second half of this year. There is growing buy-in from management at Microsoft that OpenGL is a critical API. Significant performance improvements were made in the 1.1 release.
John S. says that SGI's overall objective is to determine whether OpenGL is viable in an environment without hardware acceleration. His inclination is to make SGI's work available to other licensees, but the project is still underway and there are still issues to overcome. Will the implementation be conformant? Yes, but SGI promises to use good judgment in trading off performance and conformance. The goal is to provide a product quality implementation, not a portable sample implementation.They expect to be at beta with this implementation by about the end of June.
SGI is working on HTML versions of the man pages. They will be made available as soon as they are finished.They are also planning to release both PostScript and HTML versions of the spec.
The release number of GLU for the SI is "1.2.2". The revision number (the value after the second period) is optional. The release string is followed by a space, and vendor-specific information may follow the space. GLU code is generally shared between vendors and since a good number of changes (bug fixes and such) have been made without changing the minor revision number, a sub-minor release number has been added to indicate which version of code is being used.
There is not yet a version of the spec that includes push/pop client state. This will be done for the next SI release.
Paula summarized the results of the recent meeting to discuss the schedule and functionality for GLX 1.3. Since it was agreed to try and make fbconfig and pbuffer EXT extensions as the first step of the process to get to GLX 1.3, Paula led a discussion of this topic by talking through the mail she sent out on 5/9/96.
Randi asks whether something similar to fbconfig should be done in the Windows environment. If not, fbconfig promotes even more incompatibility between the UNIX/X/OpenGL environment and the Windows/OpenGL environment.
Should fbconfig remove the current similarity requirement (e.g., allow a 4/4 double-buffered drawable and an 8-bit single-buffered drawable to use the same rendering context)? There is agreement that this would be a good for application developers, but would this be a big burden for OpenGL implementors? John D. suggests that we make the attempt to remove the similarity requirement, and see if any of the implementors scream.
Should fbconfig allow contexts to support both RGBA and color index rendering? Consensus is that this would be a big burden on implementors and not really worth the cost.
Should fbconfig attempt to address the problem of visual explosion? The visual explosion problem burdens both server implementors and X applicaion writers. People felt like it would be a good idea to try and use the fbconfig extension to reduce or eliminate the visual explosion problem.
Should fbconfig try to reduce the problem of fbconfig explosion? Consensus is that making fbconfigs explicit is a good thing, so let's not worry about the explosion problem here.
Should fbconfig try to do more to support colormap sharing? Seems like this problem is reduced if we reduce the problem of visual explosion. Sun is considering modifying X with an extension that would relax the similarity requirements between colormaps and drawables. They were encouraged to distribute their X extension spec to the other OpenGL licensees.
Should fbconfig support a way to specify whether a context can be bound first to one type of GLXDrawable (drawable, pixmap, pbuffer) and then to another? It seems like pixmaps are usually the problematical ones in this set. Consensus is that we should try to resolve this problem.
John D. asks whether there have been any requests for multiple depth buffers in a single GLXDrawable and whether this plays into the fbconfig extension. Yes, people have heard requests for multiple depth buffers: simultaneous stereo rendering, multipass algorithms that require two or more depth buffers, scanning out the depth buffer while the next frame is being rendered. Would be a good exercise for someone to write up a multi-depth-buffer extension spec.
Does anyone have any issues with the coverage tests (covgl) for 1.1? Bimal would like to see an archive of proposals for spec and conformance changes. The goal of this request is to ensure that spec and test changes have been approved by the ARB. Chris F. keeps a log of these things and records the resolution for each, and he sometimes makes this publicly available. Paula will check to see if this can be done more consistently.
Bimal proposes a change in the treatment of errors in covgl for the 1.1 conformance tests (leaving the conformance tests for 1.0 unaltered). The vote is 6-0-1 to change the detection of errors. Instead of only checking for an invalid enum error, the code will check to see if any error has occurred.
A proposal was made to add a test for the texture priority parameter in glTexParameter. (Passes 7-0-0)
Testing of the major and minor version numbers is incorrect in covglx for the 1.2 conformance tests. It is proposed to fix this bug, to make sure glXGetCurrentDisplay is tested and properly bracketed with compile time and run time checks for the version number, and to verify that glXGetCurrentDrawable is properly tested. (Passes 6-0-1)
There was a discussion of conformance tests results and how they are made available to customers. Each vendor must submit conformance test results to SGI as part of their licensing agreement, and they must agree to supply conformance test results to anyone who asks.
The proposal sent to the ARB mailing list regarding the handling of non-conformant visuals was discussed. The proposal was approved with the addition that vendors are required to include with their conformance test results a written statement descrbing why the visual is non-conformant. (Passes 7-0-0)
There was a vote to approve covgl as modified. (Passes 7-0-0)
There was a vote to approve covglx as modified. (Passes 6-0-1)
Any issues with mustpass? The texture object test changes the texture environment and does not change it back. Need to reset the state. There was a vote to fix this. (Passes 7-0-0)
Hock reports that there is a bug in the SI such that vertex arrays cannot be stored in display lists. Hock would like to see more tests so that basic stuff like this is guaranteed to work. Is there really a reason for adding these kind of things to the conformance tests rather than a Q/A test suite? The conformance tests are not meant to be exhaustive Q/A tests.
There was a vote to approve mustpass as modified. (Passes 7-0-0)
Should we add more tests to the conformance test suite? Hock suggests adding more tests to vertex array in display lists. Pat suggests adding vertex array tests that cover more vertex formats. Randi asks if there is a container in the SI contrib area where people can contribute Q/A tests. Is it worth the development effort to do additional tests? If it is, will the majority of ARB members approve the addition of new tests? (Straw vote: 5 in favor, 2 abstain) Paula asks that people send ideas about what new tests should be written.
Bimal reported a problem in covgl. The call to glPixelStoref should have its first parameter changed from GL_UNPACK_ALIGNMENT to "...pixelstore[i].value". Vote to fix this bug passes 7-0-0.
Not everyone has reviewed the 1.1 man pages. People should review these ASAP so that they can be approved.
To resolve the issue about the definition of the MAX_TEXTURE_SIZE constant, Kurt proposes the following wording be added to Sec. 3.8: "It must be at least 2k-lod + 2bt for image arrays of level-of-detail 0 through k, where k is the log base 2 of MAX_TEXTURE_SIZE, lod is the level-of-detail of the image array, and bt is the maximum border width. It may be 0 for image arrays of any level-of-detail greater than k." Furthermore, the phrase "See discussion in Section 3.8" would be added to Table 6.14. (Passes 7-0-0)
Who is supporting this besides Microsoft? 3DLabs. The two ways to make something an EXT extension are: 1) two or more OpenGL licensees agree to support an extension, or 2) the OpenGL ARB agrees to define an extension as an EXT extension. Paula states that all EXT extensions should be registered and made available to all OpenGL licensees. John D. thinks it should be made public. Paula agrees, but doesn't think it must be made public right away.
A question about shared textured was raised, and it was clarified that default textures are not shared.
Bimal wonders whether polygon antialiasing is worthwhile, since polygons have to be sorted in order for it to work properly. Could the spec be relaxed to reduce the burden on OpenGL implementors? Kurt states that the spec is already loose with regard to this attribute. Also, the conformance tests do not check for "proper" behavior of polygon antialiasing. Megatek and SGI support polygon antialiasing on some platforms. SGI supports it on their high end platforms. In the Megatek environment, applications must enable a Megatek-specific attribute to get proper antialiasing behavior.
The OpenGL specification is written loosely enough that there is some ambiguity regarding the precise behavior of polygon antialiasing. The additional requirements on the application developer to render a 3D scene (sorting polygons) make this feature difficult to exploit, even if present. During the discussion, Kurt stated that the additional demands on an application made polygon antialiasing under OpenGL to some extent a "2D operation". In a poll of the hardware vendors in the room, it appears that many (if not most) vendors either do not support polygon antialiasing at all or do not support it correctly. This raises the issue that the OpenGL specification effectively advertises a feature (polygon antialiasing) that is not present in a large number of OpenGL renderers. After carefully reading the spec, it may be possible to conclude that polygon antialiasing is not strictly required. Bimal requested that this be stated explicitly in the spec. He first proposed modifying the Polygon Rasterization section and later proposed adding a corollary in the appendix. There wasn't much enthusiasm for modifying the Polygon Rasterization section, and the attempt to draft a corollary was abandoned after a careful reading of the relevant sections of the spec. The issue was dropped and remains unresolved.
A proposal was made to change table 6.2 to replace "client", the last entry in the Dec. 21 version of the spec, with two entries: "feedback" and "selection", neither of which can be pushed or popped. Note that a previously approved change which does not show up in the Dec. 21 version is to add a third column specifying client/server.
ICD - Installable Client Driver: Defines support for lighting, transformation,and rasterization. Developing this is a lot of work for some smaller companies. A lot of companies are just developing hardware to support rasterization. MCD - Mini Client Driver: defines support for rasterization, Microsoft supplies software for the remainder. This architecture will be released with NT 4.0.
The Q3 ARB meeting was tentatively scheduled for the week of Aug. 19th to be hosted by HP in the Denver area. The Q4 ARB meeting will be hosted by Megatek in San Diego. In the past, the Q4 meeting has occurred early in December.
End of Day 1.
John S. wants to put together an OpenGL "information kit". He's talked to Addison-Wesley about special pricing for their books. He'd like to see a station in each vendor's booth clearly marked as an OpenGL station, and have web pages on each that reference this information kit. The kit would also include a CD-ROM with demos and HTML versions of man pages. People will register on-line to receive the kit, and John will coordinate mailing it to them. John needs help acquiring demos and would like to have each company plug into their SIGGRAPH planning the request for booth space and a machine for OpenGL.
John will also be updating the OpenGL WWW Center web pages, with more of a focus on applications. Pointers to new and exciting OpenGL applications are appreciated. He'll also be putting together a letterhead and a format for making "ARB-related" press releases. John D. thinks we should not have the ARB member companies listed on the letterhead in order that we don't appear exclusive.
Paula handed out a copy of some mail with proposed changes to the stencil conformance tests. Two proposed changes were made for visuals with stencil but without Z, one to spop.c and one to drawpix.c. Pat proposed that the change to drawpix.c was not needed and should not be made (the StencilOp was the same whether the Z test passed or failed). The other change looked acceptable, but Pat wanted to hold the vote by email so that he could go back and review the conformance test code to be sure. This issue was tabled and an email vote will be taken ASAP.
Microsoft handed out a writeup of an issue with the stencil conformance test. Approved 7-0-0.
Thick or thin? That is the question... The currently proposed Ada binding from SGI is considered "thin" in that it looks like the C binding and does not take advantage of the stronger type checking available in Ada. Should the ARB approve the existing thin binding or come up with a thick one? Nice to follow the C binding more closely (A) so that you don't have to change the documentation for each binding, (B) so that the binding can be generated automatically from the C source, and (C) to minimize the source code support cost, and (D) we have the precedent of the C++ binding being the same as the C binding. It was suggested that we post the OpenGL Ada binding to the Ada newsgroup for comment. Paula had hoped that ARB members would have talked to their Ada experts. It was resolved to have SGI post the current thin Ada binding to the Ada newsgroups in order to obtain feedback as to whether this approach is fatally flawed.
IBM handed out a spec for the IBM_rasterpos_clip extension. They received complaints from several customers that their geometry-aligned pixel primitive is entirely clipped when the raster pos was barely outside of the clip volume. SGI has also received complaints about this behavior. Contact Pat Brown as soon as possible if you have any comments or if you're interested in supporting this extension.
Bimal proposes that in the discussion of polygon antialiasing on p. 66, we add the sentence "This feature may not be supported on some OpenGL implementations." He is concerned that applications count on this feature and then are disappointed when they encounter an implementation that doesn't support it. It's also costly for vendors to support this feature. The wording in the spec is fairly loose, and the conformance tests do not check to see whether polygon antialiasing is implemented. After a lengthy discussion, there was not much support for changing the spec.
Has Microsoft considered adding the ability to render using RGBA semantics to a single channel window? No. Hock says if we want this to work, we should contact him and he will design something that works for us. Paula said that we'll defer discussion of the pbuffer extension. She is not aware of any serious issues. People should read the handout and post comments to the mail list (opengl-licensees@sgi.com).
Craig Dunwoody of SGI presented an overview of GLS. He passed out a version of the GLS spec dated 4/10/96. Highlights of GLS: stream encodings + API, platform independent,client side, zero-cost passthrough (integrate into OpenGL dispatch table), captures gl only (not glX or glu). Reference implementation captures extension calls that the SI implements. Expected that each vendor will capture extension calls that it wants to, and do "something reasonable" when it gets extension commands that it doesn't know about. Release 1 of GLS supports OpenGL 1.1.
John D. expresses disappointment that there was not more ARB involvement in defining this to be a multivendor standard. There was no spec for this until very recently. SGI is now shipping GLS as a product, and Microsoft used an earlier version as the basis for their metafile support. Craig states that SGI is willing to fix things that are broken, even if that means that SGI will have a problem with their customers. Please make comments to the OpenGL licensees mailing list (opengl-licensees@sgi.com).
The slides presented by Craig are included more or less verbatim below.
SGI, DEC, HP indicated they would support GLS. Microsoft indicated they would not. Should GLS be under ARB control? Some people think that any spec that the ARB approves must be mentioned in the bylaws, because there is already a list of documents mentioned there. Other people think that the ARB only needs an unambiguous list of approved ARB "standards" and this list need not be in the bylaws.
Kevin mentioned some of HP's interests and activities in the area of OpenGL printing. If you're interested in discussing this area, send kevin some email ( kevinl@fc.hp.com).
John D. said that printing has not been as big an issue for DEC as interchange and replay of standard metafiles.
A tentative schedule for GLS was established:
Comments should be sent to the mailing list (opengl-licensees@sgi.com).