ARB Meeting
Notes ARB Meeting
NotesHosted by Microsoft in Redmond, WA
Meeting notes taken by Randi Rost, HP
| Dale Kirkland | Intergraph | kirkland@ingr.com |
| Tim Misner | SunSoft | timothy.misner@Eng.Sun.com |
| Randi Rost | HP | rost@tortola.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 |
| Fred Fisher | AccelGraphics | fred@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 |
| Chris Frazier | SGI | frazier@asd.sgi.com |
| Dick Coulter | DEC | coulter@wrksys.enet.dec.com |
| John Dennis | DEC | jdennis@eng.pko.dec.com |
| Andy Bigos | 3DLabs | andy.bigos@3Dlabs.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 |
| Mike Heck | TGS | mmh@tgs.com |
| Kurt Akeley | SGI | kurt@sgi.com |
| Drew Bliss | Microsoft | drewb@microsoft.com |
| Otto Berkes | Microsoft | ottob@microsoft.com |
| R. Todd Frazier | E&S | rfrazier@es.com |
SGI's goal is to release the OpenGL Sample Implementation (SI) for 1.1 in about two weeks. The extensions that were folded into 1.1 (polygon offset, vertex array) have been dropped from the release since they are no longer necessary. The conformance tests will be shipped too, whatever shape they're in. John Dennis asks if SGI can turn off the trapping for floating point exceptions and run it before shipping it. The conformance tests fail with divide by zero errors when run on some platforms other than SGI. Microsoft has made changes to alleviate the divide by zero problems and will help make the necessary changes to the SI.
For extensions that did not change, the enums defined for the extension are the same in 1.1 as they are in the extension definition. For extensions that did change as they were folded into 1.1, the enum values were changed from their values in the extension definition.
A proposal for defining the semantics of an OpenGL 1.1 implementation that also supports the polygon offset extension was written by Craig Dunwoody of SGI and distributed in hard copy form. What is the goal when supporting both the extension and the 1.1 functionality? Generally speaking, we want users to be able to use either the 1.1 capability or the extension, but mixing between the two is not supported. We want people to move to 1.1, so the 1.1 capability should be favored. One suggestion for doing this is to implement the extension on top of the 1.1 capability. SGI and IBM have shipped the polygon offset extension and so are concerned with supporting both the existing extension and the new 1.1 capability. DEC, IBM, SGI, and Microsoft have all shipped the vertex array extension. Pat Brown sent out some pertinent email on this topic following the meeting.
The gl.h include file will be frozen on Mar. 4, so people need to review it and comment quickly.
Chris Frazier passed out hard copy of the proposed changes and typo fixes.
15. Passes 7-0-0, with slight wording changes
16. Passes 6-0-1, with slight changes
17. (New change) Add InterleavedArrays after EdgeFlagPointer to paragraph specified by change #16, passes 7-0-0 (this is really a typo)
18. (New change) Disallow the value of zero to be passed to glPixelMap (from Issue #36), passes 6-0-1
33. Already fixed during transition from 1.0 to 1.1
34. Comments from various vendors, general consensus is not to advertise an extension as present in the glGetString call unless it is substantially complete.
35. Pat suggests adding a box labeled "coverage application" to Figure 3.1 to make it clear where antialiasing occurs. Chris will make a proposal for this next time.
36. Subsumed by change #18.
37. No proposal, investigation needed
38. "Someone" has a machine that supports 240 visuals and takes 8 days to run the conformance tests. People would like to see the tests shortened so that fewer possibilities were examined. Are conformance tests really necessary at this point? It seems as if they are forcing a lot of vendors to do a lot of unnecessary "busy work". But this is how SGI controls use of the OpenGL trademark. Opening up the conformance tests for to figure out how they could be changed to make them run faster could be time consuming, and may not be the best use of time. This topic will be discussed more on the second day.
39. Paula suggests adding a visual caveat "NONCONFORMANT" which would mean that the conformance tests would not be run on that visual. Make the conformance tests stochastic? On an implementation with just a few visuals, test them all. On an implementation with lots of visuals, could specify a few visuals that should be tested and let the conformance test pick a few at random. Paula and Chris will try to write something up to discuss during the second day of the meeting. There was concern expressed over the potential abuse of allowing non-conformant visuals. Would a vendor attempt to ship an OpenGL implementation that had only a small number of conformant visuals and a large collection of non-conformant visuals? This would be accepted by the conformance test, but would not be in the spirit of what the ARB was trying to accomplish. It was felt that a high water mark had already been achieved with current implementations and being concerned over potential abuse now might be inappropriate, that market pressures would self correct the situation. However, it was then pointed out that the current set of OpenGL implementations are mostly from workstation vendors and that when PC board vendors begin shipping in quantity the "abuse issue" might become real.
129. Created during discussion of changes #16 and #17 - change wording of first sentence of change #16 from "when made within a display list" to "when called while compiling a display list". Passes 7-0-0
Discussion of the remainder of the list is deferred till the second day.
Paula passed out a handout regarding extensions, including a registry. Companies are encouraged to submit their extensions in order to make them accessible, get assigned an extension number for new specs, and add their name to the list of extensions they would support.
The remainder of Paula's handout consisted of the specs for four extensions. The texture color table has been split into two extensions, and the shadow extension has also been split into two extensions. The last page of the handout contains some thoughts about additional extensions that SGI has been thinking about.
John Dennis discused the issues with supporting a hidden surface method other than Z-buffering in OpenGL. John D. sent out mail on 2/23 that summarizes his analysis of this issue. John D. talked to Jon Leech of UNC to find out what's happening with the PixelFlow project at UNC. John D. thinks it would be better to add explicit begin/end frame semantics than to add side effects to the existing Clear, Flush, and SwapBuffers calls. Microsoft suggests that it would also be valuable to add begin/end object semantics so that the implementation may also take advantage of any object-level optimizations that are possible. Kurt suggests testing the ideas based on at least a couple of "real" architectures: PixelFlow and scan-line. The ideas could also be tested against the architecture described in the paper written by the folks from Apple. Proving the ideas on a couple of specific architectures would go a long ways towards convincing people that we had a proposal that is generally useful, but not too general. Consensus is that supporting the BSP tree algorithm would require defining static geometry, and this goes beyond what we're attempting here. The biggest issues are around the changes to semantics for stencil test, alpha test, and blending. In answer to John's questions, in its multiprocessor archtiectures, SGI does preserve the order as specified by OpenGL. Intergraph also conforms to the ordering requirements of OpenGL in their multiprocessor architectures because order is preserved for all commands that use a single rendering context. If it is important to preserve ordering across multiple rendering context, applications are responsible for the synchronization. John's next step is to propose an API and the changes to the OpenGL spec that are required to support a hidden surface method other than Z-buffering.
Some additional discussion that John D. captured in his notes:
Hock distributed a handout that describes their paletted texture extension. It was clarified that in this proposal, the palette is part of the texture object. The primary goal of this extension is to reduce the memory required to store textures. Kurt suggested that it might be better to define the paletted textures with an internal format of INDEX rather than introduce a new format (PALETTE_INDEX_EXT). The extension proposed by Microsoft defines a pre-filter lookup table (i.e., the index lookup is done before filtering) and there already exists an SGI proposed extension for post-filter indexed textures (SGI_texture_color_table). SGI indicated that they have also given some thought to a pre-filter indexed texture extension. It was suggested that Microsoft and SGI cooperate on a common pre-filter extension.
Microsoft is also doing a BGRA pixel format extension for performance reasons. They also have a "dirty rectangles" extension to Windows that allows people to specify a list of rectangles that can be used as a hint to optimize Clear and SwapBuffer operations. In a software implementation, only the"dirty rectangles" need to be cleared/swapped. It was pointed out the Microsoft's extensions are missing from the extensions document set maintained by SGI and it was requested that they please add the documents.
Andy Bigos passed out a handout containing brief descriptions of the OpenGL extensions that are of interest to 3DLabs - 2D rendering extents, frustum culling using bounding boxes, 3D clipping control, and chroma testing of textures.
Paula discussed some "thoughts we had at SGI" for extensions in order to see whether anyone else was thinking about these things. The handout containing the extension registry contained some very preliminary thoughts on extensions to support compiled/cached vertex arrays, a sprite rasterization primitive, ramp lighting for component rendering contexts, and a pre-filter texture color table (similar to Microsoft's paletted texture extension).
Igor talked about the extensions Intel would like to see. One of them is to add texturing to color index mode (similar to SGI's thoughts on adding color index lighting and one component colors to RGBA mode). Intel would also like to see a way of using textures that are compressed. Also interested in a simplified lighting model (i.e., one diffuse white light). Others have optimized for this last case without the need for an API change.
Sun was interested in finding out where people stand on imaging in OpenGL. Some people at Sun think that the imaging effort should be larger. Randi described his experience with customers has been that imaging capabilities fall into two categories: image processing and image display. The set of things required for interactive image manipulation and display is actually fairly small and is pretty well addressed by OpenGL and the OpenGL imaging extensions. Image processing operations are often custom and do not necessarily need to be performed at interactive speeds, so can be performed in a higher level toolkit at noninteractive speeds on a general purpose CPU. Kurt adds that we've definitely taken a graphics approach to imaging in OpenGL. The other major benefit is the integration of imaging capabilities with graphics capabilities. Sun is interested in calling a meeting to get together folks interested in using OpenGL for imaging (HP, SGI, Sun, PTC, IBM, indicate interest; GE Medical Systems is another likely participant).
End of Day 1
SGI talked about the status of GLS. A discussion about the GLS REF-0 spec via email a couple of months ago resulted in some incompatible changes. A sample implementation of the new version, REF-1, and documentation covering GLS will be available in the upcoming OpenGL sample release. A synopsis of the changes was distributed as a handout. One of the significant changes that was made was to modify the binary encoding so that it no longer sorts command parameters by size. SGI does not want to make any more incompatible changes to GLS at this point.
Microsoft has taken the REF-0 version of GLS and incorporated the binary encoding capabilities into their metafile support. Since this code will ship in two weeks, there is no possibility of making it compatible with REF-1. It may not be a serious issue anyway, since this would all be internal Microsoft code (it's not there to provide interoperability with platforms from other vendors and it's not exposed as an API) and there aren't any plans to provide documentation on this portion of the metafile format.
There was some displeasure expressed over the way the development of GLS has progressed. Some folks thought that the ARB should have been involved earlier in the design process. Lack of documentation hindered the early review process. SGI felt that GLS was a "contrib" effort and it was appropriate to wait until it was substantially complete before turning it over to the ARB. There is some question as to whether the OpenGL ARB can take ownership of another specification without a change to the bylaws (which lists the other specifications that the ARB controls). There was also a question as to whether changes to the bylaws had to have unanimous approval. John Schimpf will figure out the answers to these questions in time for the next meeting.
A straw vote revealed that people in the room overwhelmingly (20-0-1) thought that it was important for the ARB to define a stream protocol and/or interoperability metafile for OpenGL. Jim Cobb stated that there might be an issue with some vendors who are concerned about their "tricks" being revealed through examination of protocol streams captured with GLS. People were asked to review the REF-1 GLS stuff coming out in the upcoming release of the OpenGL sample implementation and come to the May ARB meeting prepared for a discussion on the plan for standardizing an OpenGL stream protocol. Comments prior to the meeting are strongly encouraged, and should be sent to the opengl-licensees mail list or the OpenGL newsgroup.
John S. reported that 5 book OpenGL-related book projects are underway at Addison-Wesley. The red and blue books are in the process of being updated. The other three book projects consist of a book on OpenGL programming in the X environment, OpenGL programming in the Windows environment, and a textbook that is based on OpenGL programming. SGI folks, including Paula, are working on the updates to the red and blue books.
Returning to Chris Frazier's handout on clarifications, typos, additions, etc...
20. Pat thinks spec is clear and does not need to be modified. Defeated 2-2-3.
21. Passes 7-0-0 after changing the wording from "..., or a CopyContext." to "..., or when copying a context."
22. Passes 7-0-0 after some copy editing. On a side note, an HTML version of the OpenGL spec will be available from SGI soon, they just need to work through the administrivia to get it added to their external web site.
23. Passes 7-0-0.
24. Passes 7-0-0 after minor wordsmithing.
123. Passes 7-0-0.
124. Passes 7-0-0.
125. Tabled.
126. Passes 7-0-0 after minor editing.
127. Passes 7-0-0 after changing reference to table 4.7 to table 3.7.
128. Passes 7-0-0 after changing the phrase "too large" to "out of the range [-1,1]".
The proposed fixes to typos 102-108 are all approved in a single vote, 7-0-0
The first proposed conformance test change would relax the accuracy requirement of fog computation. Currently, the conformance test bases its accuracy requirement on the depth of the buffer, but this is not necessarily related to the accuracy of the fog computation, particularly for deep buffers. It is proposed that the test be modified to require accuracy in the fog computation to the minimum of 7 bits with an error tolerance of 1/2 bit (for an effective precision of 6 bits for the purpose of the test) or the number of bits in the depth buffer. Passes 7-0-0. The second proposed conformance test change was tabled
Andy Vesper suggested a run time check in the conformance tests to see if an OpenGL 1.1 implementation is being tested. There was agreement to modify the test structure to the following:
#if 1.1 (compile-time check)
if (1.1) (run-time check)
run 1.1 tests
else
print "server doesn't support OpenGL 1.1"
#endif
SGI spent some time to try and develop Java bindings for OpenGL. The results of their efforts were discussed with Sun. Nothing is concrete, but SGI wants to contribute the Java bindings to the OpenGL community once it makes sense to do so.
With the Java bindings they developed, SGI was successful in using OpenGL in a Netscape window and as an applet. AWT (Abstract Windows Toolkit) had to be extended to make this work (it doesn't know about Z buffers, among other things). Sun owns AWT and Java, so SGI reported the shortcomings to Sun and hopes to get the necessary changes folded into AWT. Once the changes have been incorporated into AWT, SGI will provide the Java bindings as a "contrib" effort.
The effort to define Ada bindings has kind of been overlooked lately. People should look at the proposed Ada bindings and come to the May meeting prepared to vote on "blessing" the Ada bindings.
Microsoft circulated a proposal to add routines to push and pop client state to OpenGL 1.1. Paula suggested renaming the routines to Push/PopClientAttrib for consistency with the existing Push/PopAttrib calls. She also suggested that it might be nice to have bits to specify the state for AllAttribs and PixelStore in addition to VertexArray. Table 6.2 needs to be modified where it says "client state cannot be pushed/popped". Dale suggests defining these calls in Chapter 6 with the Push/PopAttrib calls. Also need to update several of the tables at the end of chapter 6.
There is some urgency in making this change. Microsoft believes that middleware libraries will not be able to use the vertex array calls without the Push/PopClientAttrib capabilities. They are making a release in two weeks and want to have this capability in the release. Hock said, "If you don't want this in 1.1, we'll do it in WGL, then you'll end up supporting it on your NT workstations." A straw vote (12-2-5) shows there is support for adding this to OpenGL 1.1 even though OpenGL 1.1 was finished.
Paula talked with Kurt about this over the phone, and he was OK with adding it. Do we really want a bitfield for this? We had agreed to stay away from bitfields in other areas of the spec. Consensus is that Push/PopAttrib are the precedents here, and they use bitfields, so these new routines should work the same way. People think that updating the spec will be harder than doing the code to support this. It was agreed (7-0-0) to approve the following API and pursue changing the spec ASAP.
void PushClientAttrib(bitfield mask)
bit definitions for mask: CLIENT_VERTEX_ARRAY_BIT,
CLIENT_PIXEL_STORE_BIT, CLIENT_ALL_ATTRIB_BITS
void PopClientAttrib(void)
Hock offers to donate the changes to GLU that incorporate rendering of spheres, cylinders, etc. with the vertex array capability. SGI and Microsoft will work out the details of the code donation.
Paula and Chris distributed a brief proposal regarding the treatment of nonconformant visuals. Specifically, there exist several examples of visuals that add a lot of OpenGL capability but will not pass the conformance tests (e.g., multisample visuals on SGI platforms). There should be a way to skip over the conformance tests for these visuals. Paula suggests that nonconformant visuals should be listed in the conformance report. Pat is concerned that this capability would introduce some gaping loopholes. There is consensus that there is potential for abuse, but a number of people think this approach has a lot of merit and should be pursued. Andy asked how high we set the bar. If the USE_GL flag is TRUE, what is guaranteed? Paula answers that the intent of USE_GL is to specify whether a visual can be used with OpenGL. John D. adds that if USE_GL is TRUE, there is no guarantee of conformance even today.
Up till now, USE_GL == TRUE implied that the Must Pass test was passed. USE_GL == FALSE implied that you could not create an OpenGL rendering context for that visual. To add this concept of a nonconformant visual, we either have to loosen the definition of USE_GL == TRUE or USE_GL == FALSE. In a straw poll, 8 favor changing USE_GL == TRUE, 2 favor changing USE_GL == FALSE, and 6 abstain. The ARB votes to proceed with firming up Paula's proposal by a vote of 6-1-0.
Chris proposed some rough ideas for streamlining the conformance tests. Rather than make the conformance tests run on every supported visual, visuals would be grouped into buckets of similar visuals. The conformance tests could be run on a small set of visuals plus a randomly selected visual from each set. Andy stated that he is not opposed to stochastic testing, but he would prefer it for primtest rather than for selection of visuals to be tested. A straw vote of 18-1-0 encourages Chris to solidify the proposal. There is some concern about weakening the conformance tests too much, since many people expect an explosion in the number of PC graphics products that support OpenGL.
Who still wants GLX 1.3 to be finished by summer? 2 people. Who would like to form a working group outside the ARB meeting in order to make progress prior to the May ARB meeting? 7 people. What's important to people in GLX 1.3?
Clarification #2 (error semantics for calling a glx function between a Begin/End pair): ARB advisory vote favors the recommended solution, 6-0-1
Clarification #1 (is pixmap support required?): a resolution favoring solutions (b - Don't require pixmap support for all visuals, the FBConfig extension addresses this) and (c - Don't require an implementation to allow a context to be bound to a pixmap and a window) is passed in an ARB advisory vote 5-1-1.
People who want to be involved in a GLX 1.3 design session prior to the next ARB meeting should contact Paula via email so that she can work to set it up.
End of Day 2
![[SGI Surf home]](/Images/Icon/surf.gif){kind=icon}
![[Dev. Program]](/Images/Icon/extreme_icon.gif){kind=icon}
COPYRIGHT © 1994, 1995 Silicon Graphics, Inc. All Rights Reserved. Trademark Information