Summary of Discussion Topics

• ICD / SI Status
• OpenGL 1.2.1 Specification Approval
• GLU 1.3 Specification Approval
• New ARB Members / Next Meeting
• OpenGL Extensions
  • EXT stability
  • Fragment Lighting and IP
  • ARB_texenv
  • Texture Compression
  • Intergraph Extensions
  • Other Extensions
• Java Bindings
  • JSparrow Presentation
  • Summary
  • Recommendations to the ARB
• Conformance

Tuesday, September 15

ICD / SI Status

Steve Wright described the status of the Windows OpenGL 1.1 Installable Client Driver. Testing of the final bits from SGI was preempted by NT5 testing, but is about to begin and should finish in ~2 weeks. The ICD runs on NT 4, NT 5 beta, Win95, and Win98. It includes a software rasterizer and a sample S3 Virge driver.

Current OpenGL 1.2 ICD plans do not include software rendering. The DDK dispatch table changes needed for 1.2 entry points will go into NT 5, but it's possible that NT 5 might not support metafiles and printing. NT4/Win95 support for the 1.2 ICD is not planned.

Jon Leech and David Yu described the status of the OpenGL 1.2 Sample Implementation. In order to get 1.2 features out quickly, they are first being put into the existing SI codebase; this should be ready in 6-8 weeks. Merging the old SI with the Intel-optimized codebase will follow, around January. The Windows ICD should follow the SI release by about 3 months.

OpenGL 1.2.1 Specification Approval

The draft specification was not changed in a functional sense. However, a terminology change to the ARB_multitexture specification in appendix E was made: references to "active textures" were generally replaced with "texture units". The "active texture" now refers to the specific texture unit selected by glActiveTextureARB(). The MAX_ACTIVE_TEXTURES_ARB enumerant was changed to MAX_TEXTURE_UNITS_ARB.

After making these changes and prior to voting, Microsoft expressed concerns about adopting multitexture too quickly, without enough flexibility to meet the needs of CAD customers.

The vote on the final OpenGL 1.2.1 Specification was unanimous in favor; OpenGL 1.2.1 is approved (subject to the changes agreed on at the meeting). The final specification document will be posted by Jon shortly after the meeting.

GLU 1.3 Specification Approval

The draft specification underwent several changes after discussion:

• The proposed "GLU_SUPPORTED_VERSION" target for gluGetString was dropped. Applications will be responsible for checking the underlying OpenGL server version to see which GLU calls and parameters are supported.
• The "GLU_VERSION" query was changed to return the GLU client version, which is the behavior implemented by the Sample Implementation. The GLU 1.2 Specification incorrectly documented this to return the maximum version of GLU compatible with an OpenGL 1.0 implementation.
• Added a parameter specifying the mipmap level of the input to gluBuildxDMipmapLevels.
• A note was added stating that the GLU_EXT_nurbs_tessellator and GLU_EXT_object_space_tess extensions and the corresponding GLU 1.3 core features are equivalent to each other and may be called interchangably.
• We noted that gluErrorString needs to understand the new OpenGL 1.2 GL_TABLE_TOO_LARGE error.

Steve Wright noted that an updated GLU can't be released on NT except as part of a service pack, since it's considered a system component.

We'll vote on the final version of the GLU spec by email after these changes are integrated.

Wednesday, September 16

New ARB Members / Next Meeting

The permanent ARB members met following the GLU discussion on Monday to discuss additions to the ARB. HP was voted in as a permanent member. To increase representation from the PC IHV space, 3Dlabs and Nvidia were voted in as auxiliary members for one-year terms. Congratulations to the new members!

Metrolink will host the next ARB meeting, December 3-4, 1998 in Fort Lauderdale, Florida.

OpenGL Extensions

EXT stability

Nate Tuck brought up the desire of several IHVs for increased stability of multivendor EXT extensions, and better codification of the process of promoting an extension from vendor-specific through EXT and ARB status and finally into the OpenGL core. While EXTs are not controlled by the ARB per se, it's still a good forum to discuss this issue.

Nate proposed adding to the guidelines in Paula Womack's extension rules document. Suggestions contributed by attendees included:

• Add a field to the extension template, and to future extension specifications, showing incompatibilities with previous extensions.
• Clarify IP issues with EXTs.
• Identify who can make what sort of changes to existing EXTs.
• Collect prototype/enumerant information from licensees for a <GL/glextension.h> header. This is particularly important on Windows, where multiple vendors ship drivers with different extensions to be built with the headers supplied with the SDK. These headers only describe features in Microsoft's distribution.
• Add a field to the template for an owner/contact, and another field describing which version of the Specification the extension is written against. Note that the version number is already listed in the individual section headings showing changes to the Specification. There is some contact information in SGI's database which might be added to existing extension specs.
• Maintain a list of vendors supporting each extension. This would be difficult to keep accurate or current, but SGI is willing to host such a database.
• Get vendors to agree on an EXT initially, rather than multiple vendor extensions implementing comparable functionality. This is difficult since some extensions are considered proprietary during development.

More suggestions should be sent to Nate or to Chris Frazier; they'll develop a proposal.

Fragment Lighting and IP

SGI distributed copies of the fragment_lighting, light_texture, coordinate_frame, and texture_perturb_normal extensions with an attached statement clarifying their IP interests. The purpose of this family of extensions is to provide high-quality lighting and bump mapping. Questions about the IP statement should be directed to Ken Niven in SGI's legal department: kwn@corp.sgi.com, 650-933-3020.

Some concern was expressed about slowing down the EXT process by drawing in lawyers.

ARB_texenv

This in-development extension is intended to support additional texture blending modes beyond those in OpenGL 1.2. Mahesh Dandipani will lead discussion and development of this extension on the opengl-arb-interest mailing list. We hope to turn this into the next ARB extension. Points raised included:

• Nvidia can't layer their texture combiner spec on top of this, but is still willing to support the ARB version.
• Why have a new texture environment parameter? A: this allows specifying alpha and RGB blend modes separately.
• Nate noted that it's still clumsy to treat the old environment separately. Can we turn the current TEXTURE_ENV target into an alias for two separate targets, TEXTURE_ENV_COLOR and TEXTURE_ENV_ALPHA? We'd have to define a rule for which target is returned by the current query, if they differ. Someone (not sure who) suggested instead having an Enable controlling the RGBA / separate RGB and A behavior.
• With more than one environment, do we have a precedence rule identifying which one is used?
• Do we want shift and bias when clamping is done immediately afterwards? Probably not.

Texture Compression

Mahesh started this discussion. Should compression operate as a hint, or new internal formats? Mahesh preferred hints; others preferred internal formats. Note that hints mess up texture proxy calls, which assume that all relevant state is passed in the call.

Digression to discuss S3's block compression algorithm. Nate Cheung from S3 said that decoding is freely licensed; encoding status is unclear. He'll talk to S3 developer relations and report back to the ARB.

We might want e.g. RGBA_COMPRESSED (generic) and RGBA_COMPRESSED_JPEG (vendor- or method- specific). Some schemes demand additional quality parameters; might we need new TexImage calls to support this? Do we want to support just internal formats, or compressed host formats as well?

Mahesh will also lead this discussion.

Intergraph Extensions

Dale Kirkland led this discussion and handed out copies of their extension proposals. The first proposal, wglSwapInterval, raised general questions about WGL:

• WGL has no extension mechanism, and Microsoft has not been willing to add one up to this point. IHVs can support WGL extensions by advertising them via the core GL_EXTENSIONS string and returning their addresses with wglGetProcAddress, just as for a GL extension, but this is not an ideal approach.
• Michael Gold asked where the state for WGL extensions should exist - in the current device context? current drawable?
• Bimal Poddar suggested that if Microsoft was unwilling to do WGL extensions, IHVs might get together on a common source base. Michael is willing to work on a multivendor "bootstrapping" mechanism to help accomplish this.
• Professional applications are increasingly interested in WGL extensions; this may push Microsoft to do some support work.
• Steve will take all this discussion back to Otto Berkes at Microsoft and see if they can help.

Returning to wglSwapInterval proper (initially created for Id software), Intergraph's motivation is flight simulators, which need to provide different swap rates for different windows. Dale will lead discussion of this extension on the mailing list and come up with a final specification for the registry.

The remaining Intergraph extensions are all incomplete; talk to Dale if you want to work together with Intergraph on finishing these.

INGR_blend_func_separate was created for imaging houses needing separate RGB and A fragment blending. The only ugly part is querying for the old BLEND_SRC / BLEND_DST state. People like this approach to splitting RGB and A state better the the current ARB_texenv approach.

INGR_color_clamp is useful when doing color space conversions where some output channels are not in the [0,1] range. This is based on the OpenGL 1.2 imaging subset, replacing the 1.2 "final conversion" operation.

INGR_depth_float is to make the depth range more accurate near 0. This really should be in WGL, but PFDs currently don't allow specifying vendor-specific bits (Steve Wright will also look into this issue). The semantics of changing from float <->fixed depth buffers are not yet defined by the extension.

INGR_stencil_wrap defines a new mode for wrapping (instead of clamping) stencil values; this is useful for in/out testing and other operations where the stencil might over- or underflow, but the low bit(s) are still well defined and meaningful. The extension as defined is controlled with a glEnable; it could also use INCR_WRAP and DECR_WRAP parameters to glStencilOp.

INGR_ycrcb_pixels supports YCrCb host memory formats but, unlike SGIX_ycrcb, just expands 422 -> 444 format prior to the imaging pipeline. It relies on pixel pipeline operations to do the actual YCrCb -> RGB color space conversion.

Jon observed that the SGI extension uses a different component ordering; should reversed (or permuted?) component order formats be provided for compatibility? This needs to be followed up after the meeting.

Intergraph is also working on pbuffers - this is hard on Windows. They're interested in SGI video input extensions - interlace, 422, maybe a few more. Raycer may also be interested.

Other Extensions

Jon suggested that EXT_point_parameters would be a good candidate for the next ARB extension. Although the extension is currently supported by multiple vendors, there are some outstanding issues regarding multisampled and antialiased points which should be resolved.

Java Bindings

Jack Middleton led this discussion. Three proposals were received in response to the ARB RFP: Magician, Java4GL, and JSparrow. Arcane previously presented Magician to the ARB at the June ARB meeting.

JSparrow Presentation

Naruki Aruga of PFU presented JSparrow. PFU is a subsidiary of Fujitsu and Panasonic. They are developing a range of Java products and want to be able to do 3D on a handheld "Java Terminal" (a prototype was shown). JSparrow is their approach to bridging the OpenGL and Java worlds, and addresses the following points:

• Thin layer.
• Supports the entire original OpenGL specification.
• Easy to port C OpenGL applications to Java JSparrow - most lines of code are unchanged.
• GL, GLU, and GLUT are integrated in one class.
• There's a simple type mapping - in general the C type GLtype maps to the Java type type (there are a few exceptions).

The remainder of the presentation was a combination of slides and a live demo, which can't be reproduced in the minutes. PFU's slides are available at http://www.will.or.jp/~jsparrow/ for the present.

Summary

Jack summarized several aspects of the 3 proposals:

	Magician	Java4GL	JSparrow
Support	Windows, Linux, Solaris, Irix Multiple JVM Mesa / SGI OpenGL / Sun OpenGL	Multiple OS Sun JDK Not sure which OpenGL versions	Windows Sun JDK Microsoft OpenGL
Packaging (class/interface structure) What should go in an interface or class? This affects extensions.	Separate GL and GLU classes	?	Single interface
Naming (e.g. vertex vs. glVertex3f) Overloading or not? This adds test and documentation complexity. Arrays instead of pointers? This adds ambiguity if the array length isn't encoded in the call name
Type Mapping No unsigned types in Java - this affects images. Untyped pointers (e.g. glCallLists) are a problem. Expand to type-specific calls?
Window System How should we specify non-default visuals? It's hard to get this right. The Magician abstraction makes it harder to support extensions - must modify to accept abstract types.	Classes for visuals, events, contexts, windows	Methods for window creation and context management	Methods for window creation and context management
Version Compatibility We probably want undefined behavior. Java bindings themselves will need versioning of some sort.	No-op if GL doesn't support the feature	?	?
GL Extensions	Build a new class subclassing the GL class	All methods are in one class	Haven't addressed this yet
Exceptions	Methods throw (return?) OGLException - only used in the error pipeline glError	glError	glError
Callbacks (GLU)	Create a derived class and override methods	?	Java reflection mechanism

Magician's composable pipelines (tracing, error detection, profiling) are "nice", but Sun doesn't believe these belong in the core bindings.

Other issues Sun doesn't think we should address now:

• Security (class signing)
• Serialization
• Java Beans
• ActiveX / DirectX
• COM

Recommendations to the ARB

• JDK 1.2 is (still) not available, so people used other methods to get non-default visuals. This needs to be addressed properly.
• Think through how to support extensions and a versioning mechanism.

Who writes the specification?

• Working group comes up with an outline
• Discussion/consensus
• ARB vote

Resources

• More are needed. Sun is planning to commit some new resources for this work.
• SGI may be asked to maintain conformance source.
• We don't know how best to maintain a sample implementation. Some companies may want to implement proprietary implementations.
• Just define Java interfaces and class skeletons? David Yu will look at this.

We're not yet to the point where a specification can be constructed - probably soon. Jack will maintain the issues/solutions list, forward issues to the ARB list as they emerge, and come up with a plan/schedule for the bindings.

To help this along, we need a lot more feedback from licensees to Jack, particularly on core bindings and window integration.

Conformance

Multitexture proposal - Nvidia will remove the last bits referring to "texcoord set 0". Conformance source will be released to licensees as a separate source module.

General issues on conformance:

• SGI needs to release the conformance document (this will happen soon)
• Licensees need to get covgl source, not just conform
• Sort out how to integrate ARB conformance tests into the existing suite - run the test if the extension string is present.
• SGI should probably also distribute a conformance binary for Windows - they'll look into possible legal issues.

Convolution border modes - this is conform only, no mustpass portion.

Remaining conformance proposals still need to be refined; Jon fell behind on this.

Thanks to Nvidia for hosting this meeting!