Summary of Discussion Topics

• Status Reports
• 1.2 Conformance Test Vote
• ARB Extensions
• Michael Duncheon - IP Issues
• ARB Extensions (continued)
• ARB Extensions (Wednesday session)
• New and Continuing ARB Extensions
• Extended X/Unix OpenGL Interface Standards
• Next Meeting

Tuesday, December 7

Status Reports

Steve McGuigan recapped the Register article and resulting FUD: SGI and Microsoft both made public responses on opengl.org and other forums, and Microsoft is working with the Register on a correction.

Steve Wright did a Microsoft update. The Register article made it to Japan as well, and Microsoft Japan people translated and are distributing the official response response there. Microsoft is trying to staff up on OpenGL - interviewing, but haven't found good candidates yet. Need strong development lead + 1-2 development/test people. They're exercising OpenGL in new ways for e.g. scene graphs, and need to work on systems integration issues. If interested, contact Steve. Lots of customers are using OpenGL, not only on Quake but professional applications - more than Phil Taylor (DX Evangelist) thinks.

Microsoft has never shipped ICDs in the box. Had hoped to do this for Win2K, but video testing people were concerned about the "black box" aspect of an ICD. The Register panicked and didn't know what was going on. They're looking at getting ICDs into the "Windows Update" mechanism. People buying cards and systems are getting drivers that way - the concern is people upgrading from NT4 to Win2K. If people have data on such upgrade cases, please contact Steve - marketing people at Microsoft have disagreed on how much exposure this represents and how many people will be affected.

Ken Nicholson did the SGI update. Comment on Register issue - like a wildfire in the press. Contacted by JPA, Tom's Hardware, etc. When they did the research, they found out that it's a rumor, but still wanted a story. General comment - press would like to write about OpenGL!

SI status - final beta in test. Make sure you've signed the 1.2 license agreement. Soliciting feedback. Remaining work is integration of pbuffers & other GLX 1.3 entry points.

ICD status - continued integration of Intel optimized geometry code underway. Final beta to Microsoft imminent, they will test and distribute in a wider beta. Work on opengl32.dll scheduled for January, as is accelerated multihead support for Win2K SP2.

Steve Wright - DDK having slipped helps on Microsoft side, since they've had trouble getting test resources. Getting it in late December helps. There's also contention with people working on scene graphs - should free up in early January. Steve has also found a group inside Microsoft who runs the mechanics of beta programs, and wants to use them for ICD beta. They're also looking ahead to 64 bit support, coordinated with Intel, and to a full 1.2 driver example demonstrating that the DDK does everything it needs to.

Otto's team is working with some third parties on an OpenGL layered-on-DX driver for people not wanting the highest performance drivers. Steve expects ICDs to be model of choice for highend CAD, but it's hard to test since it doesn't support the type of internal hooks that DX drivers have. If people have ideas on improving testing, please contact Steve.

Ken - lots of Linux going on work at SGI. Monitoring DRI work and seeing if that's the right basis for Linux drivers going forward. Continuing to work on Java binding issues with Magician. Looking at wider testing and qualification programs and at 64-bit support.

Steve Wright - chime in on testing issue. Feedback from CAD ISVs is that testing on midrange and lowend cards focuses on Quake and fails for their apps. It's hard to boil their problems down to simple test cases. Compaq and Microsoft think a higher level of certification would be suitable. Even conformance tests are much longer than other WHQL test suites.

Michael proposes that WHQL testing not include Microsoft-specific pixel formats (e.g. anything that doesn't touch the display driver, like offscreen renderers).

Tests might be contributed to Microsoft or to Allen Akin for glean (glean.sourceforge.net).

Paula Womack - 3Dfx has open-sourced Glide and announced that they will be concentrating their work on standard 3D APIs in the future.

1.2 Conformance Test Vote

Jon - 2 remaining issues. First, there's a missing DepthRange test in mustpass.c; this is present in Microsoft DDK, but was removed from the 1.1.1 SI in 2/97 by Paul Ho for currently unknown reasons. Second, the GLX protocol problem with ReadPixels and REDUCE-mode convolution. Removed the ReadPixels test until this is resolved - we'll have a proposal for fixing this by the next meeting, but won't hold up the vote yet again.

VOTE held on 1.2 conformance: passes 10:0:0 (at last!)

ARB Extensions

Kurt reminded people that we have a chance to make OpenGL continue to be relevant and evolve rapidly. He's looking forward to seeing how the first try at the ARB extension process works.

GLX_ARB_get_proc_address

Michael made the case for context-dependent pointers again - context-independence is error-prone and places a burden on drivers. Brian Paul described his dispatch mechanism prototyping experiments, which look fairly straightforward.

Clarification on spec - query can be called whether a context current or not. Need to add extra parenthesis after function declaration.

VOTE: 3Y, FAILS.

Paula proposed an alternate: screen dependent pointers. Jon will bring back both versions tomorrow: context dependent and screen dependent.

GL_ARB_transpose_matrix

GLX issues: no new protocol is created. Gets are not layered; server must recognize new query enums and return transposed data.

VOTE: 10Y/0A/0N, PASSES.

WGL_ARB_buffer_region

Must change spec to read ARB instead of EXT (Intergraph is shipping the EXT version now).

Hard to test - this is a WGL extension, and conformance structure doesn't support it. No test specified yet.

Interaction with ARB_multisample - will behave as though a ReadPixels/DrawPixels was done, supersample information is lost.

Intergraph has layered KTX_buffer_region on top of this extension. Kinetix is willing to migrate to using the ARB version over time, though they're on a long release cycle.

VOTE: 9Y/1A/0N (E&S abstains), PASSES.

GL_ARB_multisample

Open issues:

1. Will move multiple passes to a separate layered extension.
2. Some feeling that more than two objects should be supported. Problem in that dividing N samples into M objects where N/M is non-integral produces nonintuitive results. SampleCoverageARB(min,max) may suffer floating point precision problems in specifying the range.

   Decided to stay with old (value,invert) interface and layer the range interface later.

3. Will restrict {GLX,GL}_SAMPLE_BUFFER_ARB to zero or one, and document that they're equal.
4. Retain point sampling.
5. State will remain in spec.

Missing GLX protocol; Dale will generate some with Jon's help.

Want more specific spec language in the future (e.g. what changes apply to what specific parts of the GL and GLX specs).

Coverage testing is hard; many existing tests might break when run on a multisample buffer.

Will choose to allow one-sample multisample buffers, despite the "distinguishing characteristics of ARB extensions", because it invokes different rasterization rules.

discussion suspended for presentation from Michael Duncheon

Michael Duncheon - IP Issues

30 day review period was proposed because it was felt to be beneficial to have a short, but not too short period for patent reviews. Some people felt this was too short a period. From the perspective of creating a timeframe that encouraged more review, 60 days seems better. People implementing prior to that are somewhat at their own risk - the ARB would have to decide what to do if an interference was raised.

Dale asked why ARB members are held to a shorter review period (e.g. must state objections when vote is held) than signers of the Participation agreement. Michael hasn't specifically reviewed this and suggests the Bylaws be revised to be consistent with the Agreement.

Bimal asked why current ARB members should sign the Agreement, when they've already put work into getting the Bylaws signed. Michael will report back on this.

Jon asked about rights assignment for changes to the Specification and conformance tests. The Specification is covered by the Agreement, but the tests appear not to be. The consequence is that SGI should probably write the actual tests, rather than accepting them from others, unless (maybe) there's a rights assignment doable quickly.

Michael Gold asked what to do when someone raises an objection on IP grounds prior to the meeting. Michael Duncheon says we should note that and explore exactly what the infringement might be, so we can figure out how to work around it or reduce the risk. Ultimately the ARB must make a decision to work around it or to standardize it and let implementors take on the risk for themselves. The mere fact that someone asserts they have a patent doesn't mean we shouldn't approve an extension.

ARB Extensions

GL_ARB_multisample (cont.)

Dale will write up changes tonight and final vote will be tomorrow. Straw poll shows it will be approved.

GL_ARB_texture_filter_anisotropic

Bill Armstrong: the pertinent E&S patent is #5,651,104, filed April 25, 1995 (predates DirectX 6), granted July 22, 1997: "Computer Graphics System & Process for Adaptive Supersampling". Haven't resolved anything about licensing at this time; they believe the patent conflicts with the spec. E&S is not willing to sign an ARB document granting worldwide use at this time. Bill's personal opinion is that the patent covers all implementations of the extension.

Steve Wright: Believes some Talisman technologies also applies (anisotropic texturing is in DX6). Have turned over to their lawyers for comment.

Tabled pending resolution of E&S issue - Michael will propagate a few proposed language fixes back into the EXT spec.

Kurt proposes that we go off and think creatively about ways to rewrite the spec to encompass e.g. summed-area tables or other old approaches to anisotropic filtering, rather than specifying a possibly encumbered approach.

GL_ARB_compiled_vertex_array

This is currently in wide use as an EXT. Concerns were raised about what state was allowed to change while locked. Dan Brokenshire said IBM had trouble getting substantial performance improvements and has pulled support in their newer hardware. He wants to add hints as to what state may be changed during the lock; if any state can be changed, assumptions made in compiling are limited. Example: changing TexGen mode invalidates computed coordinates.

Pat Brown said that, having implemented this, it left performance on the table and was speced vaguely, allowing implementations great latitude. Finally, the arrays that are locked are the ones enabled at the time they're locked - e.g. Quake will disable texcoord array, lock, enable texcoord array, render, change texcoord array and render another pass. Michael Gold's assumption is that any array enabled while the lock is on, is itself locked.

Dan proposed just clarifying the existing spec. Need feedback on what needs to be fixed. Straw poll suggests that ARB would approve a clarified spec.

Some notion of specifying which individual arrays are locked via a bitmask; Dan is interested in a more precise hint as to which state might change, but this is very open-ended.

Bimal revisited different uses for vertex arrays:

1. Reuse of data (quad mesh)
2. Multipass with some state changes, e.g. transforms
3. T&L (hint as to what data is static)

He contends that current version works well for (1) and (2).

One clarification needed: is an array implicitly unlocked when it's disabled?

We'll convene a separate working group for vertex array objects and also clean up the EXT language and re-propose it as an ARB extension.

GL_ARB_texture_env_add

Pat wants the overview to include at least one justification for this function. The spec as written is against GL 1.1 (or maybe 1.0) and needs to be updated. It also needs to insert GL_ADD in the list of possible texture functions, and make change in texture function type in state table (Z4->Z5).

Conformance test proposal: must include ALPHA and INTENSITY tests. Draw a polygon in some color with an added texture color, and test result. Punt on alpha test w/no destination alpha.

VOTE: 10Y/0A/0N, PASSES. Michael will clean up and bring back tomorrow.

GL_ARB_point_parameters

Point of order: this is affected by ARB_multisample (not SGIS_multisample); will need to discuss this.

Dan: what happens if min point size > max point size? Answer: implementation defined.

Bill: suggests changing DISTANCE_ATTENUATION to specify it applies only to POINTs.

Dan: when does threshold size apply? Answer: to derived size, not specified size.

Dan: should resolve an issue - does specifying negative values generate an error?

Blythe: derived point size should behave like core PointSize regarding errors and use within Begin/End. Need to add to the list in section 2.6.3.

Bimal: there are two maximum point sizes (smooth and aliased).

Kurt: initially wrote SGIS spec so limits applied to derived point sizes, not specified sizes.

Dale: alpha fade behavior seems backwards - should fade alpha on size < 1 for non-multisampled points. Blythe will check our code and with person who wrote the spec as to whether it might have been specified backwards.

Jon: needs GLX protocol for PointParameters.

Bill passed on some typos for Michael.

Michael will clean up and bring back a more readable form tomorrow.

Issue: AA points with size [0,1) will behave differently if ALPHA_FADE behavior is changed.

Blythe will explore SGI implementation and report back.

Wednesday, December 8

ARB Extensions (cont.)

GL_ARB_texture_compression

After a format-independent way of specifying compressed textures. Provides generic compressed formats and a way to return compressed textures in an opaque format.

Two issues unresolved:

1. How or if to provide compression level control - currently just NICEST or FASTEST
2. GLX protocol for images of unknown size.

Should the extension encompass external opaque compressed formats, or just compression on download? Two scenarios: precompressed textures provided with the app which should be downloaded compressed, and generic uncompressed->internal compressed textures.

Lots of discussion of ways of using compression; straw poll on 4 options:

1. Forget the extension
2. Only allow downloading uncompressed images that are compressed on download
3. Fix spec up to allow readback and download of opaque compressed formats
4. Allow download only of specified external compressed formats, e.g. FXT1, S3TC - Pat considers this as a separate extension

Straw poll suggests most interest in (2) and (4). Propose to table the extension and figure out how to encompass streaming protocols.

Intel will try to create a generic version of the extension by January, on which 3Dfx could layer FXT1 as an example.

Discussion of GLX protocol problems; Steve Wright noted in passing that X servers on Windows with indirect GLX support is of growing importance to them.

Straw poll on how to define GLX/GLS protocol for compressed data - overwhelming preference for option (3), define new APIs and protocols for compressed data including an explicit out of band data size. These APIs will bypass pixel transfer operations.

Open issues: what pixel transfer operations are allowed on compressed downloads? How is byteswapping handled on the protocol stream for these formats? Are existing formats byte-order independent?

Pat will continue the working group - send him or Bimal email (address is on the current extensions page). There will be two specs: current ARB_texture_compression (uncompressed app -> compressed server), and a framework for compressed app -> compressed server. Second spec would be layered example using FXT1.

GLX_ARB_get_proc_address (cont.)

Allen Akin came in to discuss implementation and utility in more detail. Two types of issues: First, actually using extensions is hard. Context independence eases some of these problems. Example: renderer code assumes functionality is available, then app invokes a renderer appropriate to the hardware. Context dependent pointers make it more difficult to modularize, since renderer needs to know current context each time it's called. Possible but complex, also a performance loss that can't be made up on the core dispatch side.

Second, system implications. By creating a distinction between those things dispatched through the core and through a context-dependent pointer, creates possibility of a new class of error: invoking a driver function when that driver doesn't own the current context. Probably need to start inserting tests into the driver to validate the context.

Lots of discussion about context dependence and implementation details, much of which was repeating topics covered repeatedly on the working group list. People changed their opinions after hearing Allen's discussion, and it was brought up again:

VOTE: 8Y/1A(NVIDIA)/1N(Microsoft), PASSES

Steve Wright requested that practical experience on implementation be forwarded to him, and that the difference in behavior with wglGetProcAddress() be very well documented so ISVs aren't confused.

GL_ARB_multisample (cont.)

Revised version distributed by Dale. Steve W. will update the WGL enumerant registry per spec. Jon asked that Steve distribute a copy of the WGL registry for inclusion in the broader GL registry.

VOTE: 10Y/0A/0N, PASSES

GL_ARB_point_parameters (cont.)

David Blythe looked at SGI implementation. Reason for FADE_THRESHOLD was that when multisampling, it allows reasonable behavior for small smooth points - when very small, there are motion artifacts because they cover significantly different number of multisamples as they move. For aliased points, nobody cared because the motion artifacts were unfixable. App is probably already manipulating alpha explicitly for aliased small points, so recommendation is to leave behavior unchanged in that case.

Michael will correct clamping so user-specified range clamp is followed by implementation-defined range clamp. Can't restrict user-specified range to implementation range since there are two impl. ranges (smooth or aliased).

Will make max user-specified size the same as the max aliased point size, for ease of default state test.

Conformance test - draw points and test sizes, Michael will propose details. Very much like the existing pntrast.c test, which has been pulled from the TESTLIST.

Nits: need to correct 'd' to 'dist' in the distance attenuation equation. Rewrite 'alpha *= { conditionals' expression on bottom of page 4 to valid mathematics. Strike following 'points do not affect the current color' comment.

Does derived alpha get used before or after texturing? Ideally after at coverage application, realistic fallback will allow before for current hardware too. Need a new block in the state machine diagram to express this.

E&S is concerned about how multisample behavior works, and suggests pulling out the alpha fade behavior into a separate extension. Michael counterproposed that Bill check the behavior on his systems and report back, and that the vote be deferred to email in 2 weeks.

GL_ARB_texture_cube_map

Jon missed the (short) discussion

VOTE: 9Y/0A/1N (Intergraph), PASSES

Pat Brown notes that cube mapping is one of the first compelling uses of texture borders :-)

Evaluating ARB Extension Process

Kurt summarized his thoughts about the extension process:

1. I enjoyed this meeting. We are off to a good start at driving OpenGL more quickly. The participant and contributor agreements are in place. But we definitely have the opportunity to continue to tune the process.
2. An implementation is a very good thing. Witness the quality of discussion about the getprocaddress extension, vs. the bug that was discovered for transpose matrix. Perhaps prototype implementation should be required for these extensions?
3. We need to target the important extensions, not just get success with the easy ones. Priority should be given to capabilities that do or will soon exist in IHV accelerators, and that may soon exist in competing APIs.
4. There is not enough agreement being created prior to the meeting. The working group that is proposing the extension should have worked out its differences prior to the meeting, so that they present a combined front. Ideally they should address concerns of non-group-members that have not been adequately addressed during the the pre-meeting work, and then call for a vote. The issues list should be complete (a history of all issues addressed by the group) and resolved (a decision for each issue, that is implemented in the specification). If the entire working group cannot come to agreement, then a subset of the group should do so. The members who are in agreement and who support the proposed specification AS WRITTEN should clearly identify themselves at the start of the discussion at the ARB meeting.

   At the ARB meeting the idea isn't to get agreement from everyone that a given approach is the "right" one, but rather to create in advance agreement among a subset of the ARB that a given approach is the one to champion, and to then use the meeting to get agreement in the form of a vote that the approach is acceptable. We should avoid design-by-committee in the interest of getting on with extending OpenGL.

5. We need to take holidays into account when setting the initial schedule. The idea is to leave some number of working days for each step. (Action for ARB secretary to check the schedule for the March 2000 meeting.)
6. Proposers should be careful to not take on too much for a single meeting. It's important to give adequate attention to each extension that is being seriously proposed.
7. Issues came up regarding:
   • Motivation for the extension. Be clear about what problems are and are not addressed.
   • Priority of the extension. Is it urgent? Why?
   • Error semantics should be carefully considered and documented.
   • Organization of the GLX section (should be separated into pieces that correspond to the GLX specification subsections).
   • Need to be clear about exact location of operations in the OpenGL pipeline
   • Missing testing info
8. Be sure that the print-outs are correctly formatted. Line wrapping makes it very difficult to follow along.

Group discussion:

• Need more feedback from group members before the meeting. Set aside time to do this if you are a member of a group.
• ARB secretary should send email reminders based on the known groups.
• ARB secretary will collect phone numbers of ARB attendies and make them available to that same group.
• Jon Leech will set up the OpenGL participants email list very soon.
• The group organizer should set the focus, intent, priority, etc. of the extension before the group is organized. Ideally an extension proposal would already exist, but if not, at least be clear about the target.

New and Continuing ARB Extensions

After recapping the first round, we discussed ARB extension candidates for the next meeting. The following proposals are continuing:

• GL_ARB_texture_filter_anisotropic
• GL_ARB_compiled_vertex_array
• GL_ARB_texture_compression (revision expected in January)
• GL_ARB_point_parameters (revision expected in 2 weeks)

Dale suggested the following new ARB extension candidates:

• WGL_ARB_extension_string (Paula will lead; promote from EXT)
• WGL_ARB_pixel_descriptor (Paula will lead; promote from EXT)
• WGL_ARB_pbuffer (Dale will lead; promote from EXT)
• WGL_ARB_make_current_read (Dale will lead; promote from EXT)
• Texture border clamp (based on the SGIS extension, which didn't make Open1.2; no group leader yet)
• Texture LOD bias (based on SGI or NV extensions; SGI form didn't make OpenGL 1.2. Matt Papakipos will lead)

Jon brought up these candidates:

• Vertex array objects (David Blythe will lead)
• State objects (David will lead)
• Video -> texture (Jon will lead, and distribute the SGIX_video_source specification as a starting point)
• Render into texture or BGL-like "surfacing" APIs. This introduces lots of strange semantic issues, and people aren't ready to take it on yet - but we'll track developments.

Extended X/Unix OpenGL Interface Standards

Craig Dunwoody presented an overview of the different interface layers: API, ABI, loadable driver interface (LDI), etc. This was followed up with general discussion of the current Linux OpenGL ABI proposal and how we might want to lift that into a non-Linux-specific standard. The discussion was lengthy and mostly speculative, and I haven't tried to capture it here.

Next Meeting

The next ARB meeting will be the week of March 14-15, in Sacramento. Intel will host. Exact date TBD - this is the week after GDC.

The following meeting is tentatively set for June 6-7, location & host TBD - 3Dfx and NVIDIA are both willing, NVIDIA might host in North Carolina.