Summary of Discussion Topics

• Status
• Java Bindings
• OpenGL Evolution
• Standards Bodies / IP
• Linux ABI
• ARB Extensions
• ARB Members-Only Meeting
• More ARB Extensions
• ARB Extension Process
• Specification Edits
• Conformance tests
• Next Meeting

Tuesday, September 14

Status

Introduction of the new OpenGL Product Manager and ARB Secretary, Steve McGuigan. In the future, please direct all non-engineering ARB issues to Steve instead of Jon Leech.

The 1.2 ICD kit is in limited beta; all Microsoft testers are working on the W2K beta, and will be free in about a month to help. Beta is in smoke testing by another ARB member.

The 1.2 Sample Implementation beta is available to paid-up licensees. A final beta, including remaining parts of the imaging subset, will be available in 1-2 weeks.

Intel optimization work is well underway and should be part of the ICD. AMD optimizations may not make it into ICD kit immediately.

Java Bindings

SGI feels that insufficient progress has been made and wants to standardize on Magician bindings. The ARB seemed generally agreeable; a complete spec will be needed. Ideally the result will be a set of freely downloadable bindings like the FORTRAN 90 bindings. SGI will continue talking with Arcane to define a proposal for the ARB,

OpenGL Evolution

Many of us feel that OpenGL needs to evolve more rapidly; initially it was ahead of most hardware, now it's falling behind. Not evolving means becoming irrelevant. In the ARB's interest and the community's interest to evolve OpenGL more rapidly. Kurt wants to come to group agreement about evolving more quickly.

Two big issues:

• Technical group interaction process to come to agreement
• IP ownership, protecting ourselves as a group and protecting the process. Fear reduces willingness to work together and evolve the standard. More on this from Michael Duncheon at lunch. SGI did pass out a draft participant agreement for comment; not much feedback was received. Concerns over multitexture make clear that IP is a critical issue.

Technical process - 3 tuneup suggestions. Moving faster means more risk of doing things incorrectly. We've erred on the side of caution historically. Have made some mistakes, but overall done a good job.

Possible ways to move forward include an accelerated ARB extension process, OpenGL 1.n, and OpenGL 2.0.

ARB extensions strongly suggest a direction that the standard itself is going and should achieve wider adoption. Kurt suggests that a purpose of ARB meetings is to take votes on ARB extension proposals. To accomplish this, we must first change the mindset such that the group belief is that it's in our collective interest to approve extensions unless there's something clearly wrong. Suggested process/timeline proposal:

• Process needs to follow the existing extension template and development guidelines in the extension registry (updated version will move to opengl.org). Includes GL, GLX, GLU, WGL extensions. Reference code implementation admired but not required.
• Small groups announce their intentions (e.g. at the previous ARB meeting) and put together a proposal (spec and conformance test) offline.
• Complete (not rough sketch) proposal sent to the ARB list and opengl.org at least 4 weeks prior to the meeting. Feedback requested.
• Feedback must be received no later than 10 working days before the meeting.
• Final spec sent out no later than 5 working days before the meeting.
• Want to vote on at least 3 extensions at each ARB meeting, and propose at least 3 to bring to the next meeting.

Expectation is that ARB will have reviewed and commented on the spec. If these deadlines aren't met, the vote probably won't be held. Set aside time to discuss remaining issues and take a vote at the same meeting. texenv_combine was developed at an ARB meeting - good evidence that face-to-face discussion works. Not much has been happening between ARB meetings.

Kurt: everyone needs to take the process seriously. If not actively involved, then should at least review and comment rapidly. Bias towards getting things done.

Some concern was expressed about locking into mistakes, or supporting an extension that doesn't work on your hardware. Segues to:

OpenGL 2.0 - Kurt's concern is that we get into a huge design by committee problem trying to remove/fix things. SGI's suggestion is that a 1.n revision identify features which becomes optional, and that we adopt the attitude that the ARB can deprecate capabilities in this fashion. 1.n could become an annual revision.

Question for the next meeting: of the companies which survey use of extensions by apps on their platforms, how many would share that information?

Can we get more ISV representation to the ARB? What are their needs and how can the ARB satisfy them? Traditionally they work directly with IHVs, but not much of that information necessarily makes it to the ARB. Is there a time advantage to talking to a single ARB representative, rather than each IHV individually? Steve says that DirectX program manager works in this fashion, under NDA to ISVs (who have their own IP concerns).

Ken asked how many people are interested in participating in an OpenGL Developer's Conference; almost everyone is.

Matt observed that game developers are more open about their needs than e.g. CAD ISVs. Is this just a perceptual issue for those two communities, or is there an underlying reason for the difference in attitude?

Chris wants a process for removing an extension. Hard to do this, but an extension can evolve (e.g SGIX -> SGI -> EXT -> ARB) and change features in the process.

Dale polled who's shipping 1.2: Sun and IBM. Part of the problem is that MS isn't updating OPENGL32.DLL and IHVs can't overlay it. Steve says that the DLL is becoming ever more a part of the OS and not evolvable. NVIDIA says they need to make other changes in the DLL, such as multimon support, since it never even calls the ICD in the multimon case.

Dale comments that wglGetProcAddress is burdensome for e.g. WGL_extension_string since app needs to create a context just to get the extension string for the ICD.

Steve thinks that degree of corporate involvement depends on management approval, so we should all go back and get our managers to let us spend more time on OpenGL Evolution. (MS has an open req for OpenGL engineering work now - contact Steve if interested.) Perhaps attendees should plan on dedicating N hours/week to ARB/OpenGL stuff.

Process issues: making the 4 week advance notice and the deadline on responses a hard requirement is important. Identifying a specific person at each company responsible for responding should be helpful. SGI is getting back on track with getting agendas out and otherwise moving things forward, which will help - they once again have both an Engineering and Product manager.

Kurt will write up a document summarizing the process for developing and approving ARB extensions. Blythe proposes someone take on responsibility for tracking progress of extensions and documenting it on a public website. Ken suggests that we define a roadmap: at December meeting define a "2.0" feature set - all contributions people want to make by that timeframe - and approve it by March 2000 for announcement at GDC and other ISV conferences.

ARB as a whole is just too large to get extension work done; might split into smaller groups at the meeting. We can also propose extensions to finish by the next meeting.

No extension versioning mechanism exists today, although changes can be made when moving from e.g. SGI to EXT to ARB. Dave Kirk proposes that we could make periodic changes at the "OpenGL 2000" level. Blythe suggests including revision number in the extension name string.

Standards Bodies / IP

Michael Duncheon is a lawyer who represents standards organizations in antitrust and IP areas, as well as organizational. NGIO Forum, new System I/O, I2O SIG, Storage Network Industry Assn., etc. He discussed IP issues relating to the ARB.

IP issues arise due to questions of whether individual companies or the organization as a whole are at risk of patent/copyright infringement. Also want to make standards as open as possible, and fear of infringement or high royalties damages the standard. Also don't want anyone to unfairly take advantage of the process by submitting or proposing a standard which they can extract unexpected royalties from, or impose high licensing terms upon.

Every standards organization encounters these issues and needs to work out rules of engagement up front. Michael has looked briefly at our bylaws, but notes that some companies participate without having signed the ARB member agreement. His advice is that this should be focused on and cleaned up, or we're at risk of litigation, interference in the OpenGL business objective, etc.

The agreement must cover everyone who makes a contribution, shapes the development, or knows what's happening. It covers patents, copyrights, and patents applied for. Addresses risk of silent parties to the ARB raising objections after something is approved.

Kurt: SGI is moving ahead, acting as the ARB Secretary, on the Participant Agreement circulated for ARB comment in June. It will be the current form of the agreement unless feedback is received quickly. Agreement will be posted on www.opengl.org ASAP and URL circulated (posted at http://reality.sgi.com/opengl/arb/ after the meeting).

Michael Duncheon: participants should get their legal departments in the loop ASAP. Some companies may have real issues about 30-day patent filters, royalty-free contribution agreements, etc. Proposed agreement is very similar to the I2O agreement. Differs in contemplating a fully paid-up royalty-free license; most organizations are willing to commit to a license, but not neccessarily a royalty-free one. Concept of disclosure is important.

Kurt: expect to entertain discussion until October 1st. From then on, non-ARB members wanting to participate in the meetings or the mailing lists, or any other discussions about OpenGL with SGI, must sign the agreement. While changes in the agreement may happen in the long term, we don't contemplate one-off agreements.

Michael Duncheon: individual negotiations take forever; also, everyone ought to be playing by the same rules, so no private favorable deals are cut.

Some concern expressed about adequate time for input. Kurt extended to feedback deadline to Friday, October 15. Feedback should go to opengl-secretary. Michael is also available for consultation: email mduncheon 'at' hansonbridgett.com . This will also cover the arb-interest mailing list, exact fashion TBD.

Michael Duncheon: most important issue WRT antitrust and subgroups is to have a documentary record of what the group discussed and did.

Small groups in other standards bodies are formed out of the group itself, and the relative publicity thereof helps the sense that their goal is reasonable.

Question about the asymmetry between the participant agreement and the ARB member agreement; Michael says this is not a problem from a legal perspective. There's an existing asymmetry in that ARB members have given up certain rights and others have given up nothing. SGI will also post the bylaws and member agreement, so non-member legal departments have a basis for comparison.

The ARB Secretary must determine that everyone attending future meetings has signed the agreement.

Public release of specs can happen when it's finalized and no longer subject to suggestion and modification. The exact point of public release is to be determined as part of the approval process.

Linux ABI

Jon summarized progress made by the Linux/OpenGL Base working group; the group's agenda and progress to date are summarized at http://reality.sgi.com/opengl/linux/linuxbase.html. PTC would like to see this adopted across all platforms.

Extensions (possibly for next ARB meeting)

From David Blythe:

1. State object extension - something like dlists, something like state macros in DX7. As amount of state increases, new state objects get automatic default state. State objects of particular types have particular fixed sets of OpenGL commands associated with them. Dlists are too open-ended; implementors were failing at recognizing optimizable state bundles in general display lists (e.g. that a list represents exactly and only texture object state).
2. Extension to allow transposed matrices to be passed in. Currently the spec uses column vectors, unlike the C code. Would like C notation to match the spec. Introduces new LoadMatrix and MultMatrix commands, and several new gets. Primarily for app compatibility with C++ math libraries etc. Also matches up with Java 3D and other scene graph libraries. Uses new routines instead of a mode switch to avoid confusing app code.

David will send these out - he believes there's not much IP involved in either. He expects that vertex array objects will be next up. We're seeing more bandwidth limitations and desire to cache vertices in e.g. AGP memory.

From Matt Papakipos:

1. EXT_compiled_vertex_array - locks vertex arrays for possible pretransform/caching in hardware. In use. This came up with regard to OpenGL 1.2 but didn't make it in then. Shipped in SGI OpenGL for Windows and in use by Quake3. This is a hint; biggest contention in developing it was how state changes between Lock/Unlock affect the cached data. Things to clean up: which arrays are affected, can up enable/disable arrays in the locked region. Apple wants to be in the loop on developing ARB version of this.
2. EXT_point_parameters - in use for Quake as an el-cheapo particle system. Some state only useful for multisample extension; this needs to be addressed in the ARB revision since that probably won't cover multisample.
3. EXT_texenv_add (not compatible with SGI_texture_env_add). Addresses a deficiency in the core spec.
4. EXT_texture_lod_bias (not compatible with SGI_texture_lod_bias). Generally used for blurring of too-sharp textures. Differences need to be resolved (isotropic vs. anisotropic bias, rho vs. lambda application of bias). Might be some concern about how this affects computation accuracy. Currently doesn't talk about internal precision of the bias.
5. EXT_filter_anisotropic - new NVIDIA extension. Quality meter for anisotropy. Still uses mipmaps, but modifies lambda computation. Not very restrictive on implementations - doesn't specify math for filtering. Should require support of at least some anisotropy so implementations can't advertise it while only doing traditional filtering.
6. EXT_texture_cubemap - new NVIDIA extension. Cube environment maps. Reduces artifacts compared to sphere maps. Needs to address where state goes (environment or object). Allows loading each cube face as an independent texture.
7. EXT_vertex_weighting - new NVIDIA extension. Interpolation between two transformed versions of a vertex. Used for skinning. Now have two MODELVIEW matrices and a new piece of vertex state: weight.

Remainder are primarily for backward compatibility or likely to be contentious to approve: EXT_fog_coord, EXT_paletted_texture, EXT_shared_texture_palette, EXT_clip_volume_hint, EXT_secondary_color, EXT_texenv_combine.

From Richard Pimentel (PTC):

PTC works with huge virtual prototypes needing 64-bit machines to host. Would like some sort of hooks - geometry LOD, etc. - to help render these efficiently. Occlusion culling, pipeline instrumentation are interesting going forward.

From James Bowman (3Dfx):

3Dfx has released FXT1 texture compression in "open source" format: free license on all platforms on any API. See their website for press release details. Interested in promoting to EXT or ARB status; no copies of spec available at this meeting, though.

3DFX_tbuffer relates to earlier press release. Also has 3DFX_multisample. This appears to be a subset of EXT_multisample (aka SGIS_multisample) from Intergraph/SGI. Doesn't cover images and bitmaps; images are important to professional ISVs. Also has different ways of specifying the multisample mask.

Need to decide ASAP if we want EXT_multisample as SGIS-only or EXT, or if we can identify a common subset of SGIS and 3DFX functionality and make that an EXT or ARB, plus additional extensions for 3DFX/SGI specific behavior. Discussion will be held among David Blythe, James Bowman, Bill Armstrong, Dale Kirkland.

From Jon Leech:

ISVs are asking for render-into-texture semantics. Not clear this is really needed with pbuffer + accelerated CopyTexImage, but we need to put it on the table for the future.

ARB Members-Only Meeting

The general meeting was closed and a meeting of the Permanent ARB members held to elect Auxiliary ARB members. NVIDIA and ATI were elected as new Auxiliary members for one-year terms, results announced the following morning.

Wednesday, September 15

More Extensions

From Chris Frazier (Raycer) and Dale Kirkland (Intergraph):

RAYCER_cross_product_face captures Autodesk's need as previously expressed through 3Dlabs_facet_normal extension (which was not developed through the regular EXT process, and is highly irregular). The new extension is still in development and is a candidate for EXT/ARB status.

Chris, Simon Myszko, and Jeremy Morris should get in contact to figure out what the original extension is actually called in practice (Autodesk uses AUTODESK affix; 3Dlabs claimed something different).

Concern expressed about not repeating the experience of defining the extension spec after implementations are shipping, and about not following the extension development guidelines. Updated guidelines are in the registry, but is this enough notice to driver developers / extension authors, or should we make broader publicity efforts? Include as appendix to OpenGL Specification? Delegate Steve McGuigan to contact Autodesk and establish relationship w/ARB?

Several requests for spec language cleanup which Chris will address. Kurt is concerned about architectural precedent of collapsing / mixing primitive and vertex level processing, which appears to occur in this extension.

From Dale Kirkland:

EXT_buffer_region attempts to capture functionality of the existing Kinetix extension (which again didn't go through the usual EXT process) in a clean and regular fashion. Unclear if, as a WGL extension, this should use GDI or GL coordinate systems. Establish convention going forward to use GL coordinate system (leaving swap_hint as odd man out). Add language requiring DC to remain valid for duration of use of the buffer region. Intergraph wants to ship by the end of the month, so if there are more issues, contact Dale ASAP. He will send out updated spec to the mailing list.

ARB Extension Process

Kurt, Steve, and Jon wrote up a summary of yesterday's discussion as a process proposal.

Should adding ARB extensions cause changing minor spec version number (1.3 -> 1.4 -> ... -> 1.37) or just the minor revision number (1.2.1 -> 1.2.2)? This is mostly a marketing question; since ARB extensions are optional, a version 1.37 implementation might offer exactly the same functionality as a version 1.2 implementation.

Chose to go with the "1.X.Y" notation, incrementing Y every time new ARB extensions are added (e.g. every ARB meeting).

Some concern was expressed about fairness of having small working groups, which might prove exclusionary.

Specification Edits

Proposed changes from Jon were circulated; these changes were already verbally approved in prior ARB discussion. ARB chose to vote seperately on core spec edits (texture application table, Map1, etc.) and on changing the multitexture extension to require at least 2 texture Units. Comments: table 3.19 needs to change _t to _s subscript, and include '1' and '2' internal format aliases for LUMINANCE and LUMINANCE_ALPHA.

Dale also had proposed edits, most of which had already happened in the 1.2.1 Specification. Remainder include:

• GetTexImage does not apply pixel transfer modes.
• Texture residency should not be push/poppable in table 6.13.

Typo in last sentence on page 104: "decribed" -> "described".

Core vote held: passes 9Y:0A:0N (Microsoft left early).

Multitexture vote held: passes 7Y:1A:1N.

Conformance tests

Action items for Jon, to finally finish 1.2 conformane:

• Put current tests up for FTP on licensee FTP site by Thursday 9/16.
• Update specular test with Bill's changes from July 20.
• Look in RCS logs for tests which were pulled to see why they were pulled.
• Rewrite convolution border test.
• Distribute new tests by 9/21.
• Feedback required by Tuesday 10/5.
• Final version by Tuesday 10/12.
• ARB vote due by Tuesday 10/19.

Michael Gold will update multitexture test based on Dan Brokenshire's feedback; will be incorporated into FTP drop.

ARB extension dispatch will be pulled into ctk (ctkw in this case). Michael will write reference implementation for Windows; other OSes will follow later.

Michael asks if there's interest in fixing the old tests that were pulled (e.g. aapoint). Chris and Michael expressed interest in fixing such tests.

Next Meeting

Meeting will be December 7-8, 1999. Host and location are being finalized and will be announced on the arb-interest list soon.

Thanks to NVIDIA for hosting the Tuesday dinner!