Summary of Discussion Topics

• WGL / opengl32.dll Status
• Histogram/Minmax Conformance Changes - Dale
• Developer Conference
• GLSetup Status and Developer Poll Results
• Working Group Meetings
• OpenGL Roadmap Discussion
• ARB Extensions
  • GL_ARB_vertex_blend
  • Render to texture
• New ARB Members
• WGL reimplementation (Dale)
• ARB Extensions, cont.
  • ATI programmable geometry extension
  • Render to texture (cont.)
  • GL_EXT_state_object
  • GL_ARB_texture_lod_bias
  • Vertex array objects
  • GL_ARB_texture_env_combine
  • Object Management
• Working groups for next quarter
• Next Meeting

September 19, 2000

Introductions

New ARB Participants have signed up - Apple + numerous ISVs (see the ARB page on opengl.org for a relatively current list).

3Dlabs is now a permanent ARB member - inherited Intergraph's membership.

WGL / opengl32.dll Status

Dave Aronson, MS - working internally and externally to push OpenGL forward; no major announcements since SIGGRAPH timeframe.

Dale - Microsoft's future doesn't seem to be OpenGL. IHVs have been having informal discussions about taking over, promoting, and adding OpenGL features on Windows (NT), integrating OpenML features, etc. Is there interest in specifying and developing an open implementation of this? ICD-centric; possibly NT-centric.

3Dlabs would like to see this, and is willing to do some of the work.

Bimal - Intel is interested in participating in a working group. Some WGL features leave a lot to be desired, e.g. error handling mechanism.

Jon - SGI is willing to open source opengl32.dll infrastructure, if Microsoft allows it. IP issues involved.

ChrisH - Different levels of IP. Probably no patents involved.

Dale - Mainly interested in what the application sees, and a specification of how that works. Easier on Win2K - Win98 does lots of this work inside opengl32.dll rather than the ICD.

George - Will Microsoft say just what IP they're concerned about?

DaveA - Will research it and report back.

Dale - Thinks NT has actually hurt OpenGL by not evolving its support.

ChrisH - advocates taking control of the entire mechanism, to not rely on Redmond. Concerned about how much systems work is involved.

Michael - Ideally, ICD loader would come from Microsoft, if they can keep it up to date. Code effort required isn't significant.

Jon - SGI has already done this work; the issue seems to be Microsoft finding engineering resources to test / package / ship it.

DaveA - Trying to find resources to get this done.

Kurt - it's clear Microsoft won't do this. If people want it, they need to just go do it.

ChrisH - volunteers to drive the spec, with Bimal, Michael, and Dale. Will create a working group through the regular ARB process.

Jon - concerned about compatibility issues with existing build/runtime environment.

Dale - don't want to get into namespace wars with Microsoft. Will write up a proposal for ARB vote.

ChrisH - wants to make sure this includes Win9x too.

Dale - impromptu meeting at 5 PM.

Histogram/Minmax Conformance Changes - Dale

Dale proposed some bugfixes. The histogram fixes disable histogram operation on readback. The minmax fix changes the error bounds to a fixed epsilon, since it shouldn't be dependent on the frame buffer precision. An email vote will be called on these after the ARB meeting.

The second issue is probably a specification error introduced when incorporating the histogram extension into the OpenGL 1.2 spec;

The final issue produced general agreement that reading histograms in packed pixel formats should also be dropped from the spec; the SI doesn't support this.

Jon will propose new language on the second and third issues.

Developer Conference

Talked with Michael Duncheon regarding ability to NDA ISVs at e.g. a developer conference. This is doable, if the ARB members are comfortable with it.

Silicon Studio is currently running a DevCon in Japan - may get ideas from the format from this.

Brian Sharp - several suggestions on working with ISVs. EULA, NDA. NDA wouldn't address perceptual issues, since most ISVs won't sign anytime soon.

Michael - we didn't get much feedback from ISVs even when the arb-interest list was active.

Paula, PeteD - other conferences (e.g. WinHEC) have such NDAs, and many people do sign them. Jon will get a proposed proposed NDA from Michael Duncheon and circulate to Participants.

GLSetup Status and Developer Poll Results

Chris Hecker gave a presentation on GLSetup and the results of their recently conducted survey of game developers (will link to this later).

Working Group Meetings

SGI will host monthly face-to-face meetings with teleconference capability, to encourage progress by the working groups. Proposed dates are October 19 and November 16, 9-3 PST. Blocks of time for each working group will be scheduled prior to the meetings.

OpenGL Roadmap Discussion

ChrisH - having a hard time getting incremental changes in. What's up with OpenGL 2.0? Where are we going? People have run out of SGI machines to copy.

Michael - we can make major new additions without breaking existing API.

Brian Sharp - could have some mechanism for deprecating old features.

Bimal - having a discontinuity in the API could kill OpenGL on the adoption rate.

Allen - example: multiple state machines (or operations respecting different subsets of state - Jon).

Bimal - a discontinuity might work if a complete, high performance open source infrastructure was defined.

ChrisH - feature explosion (e.g. formats) makes testability hard.

Brian - would like to merge all the (relevant) extension specifications into the base document.

Michael, Jon - disagree that developers care about the spec. Better documentation and examples are needed.

Bimal, ChrisH - it's still hard to figure out what the spec is.

Jon - would make sense to merge into the base iff we define e.g. OpenGL 1.3.

Brian - we should define a deprecation process in advance of deprecating any specific feature, so there's a clear path to do it.

Michael - there's substantial risk in OpenGL 2.0. If we get to a point where the extension process is moving smoothly, this may be more viable. Until that point, why put any effort into deprecating features that aren't getting in the way of stability, performance, and testability.

Yanjun - Agrees with Michael. Sun's ISVs use all OpenGL features, and many of them still are based on OpenGL 1.1.

Ken Dyke (?) - people will upgrade when there's a compelling reason to (e.g., there should be one).

Bruce - Chris' data suggest robustness is a bigger concern than features. If deprecation would help, maybe that's the way to go.

Michael - Deprecation won't help. Adding generalized functionality is easy, then specialized code paths for e.g. different data formats.

Bimal - the problem is the explosion of code paths (different ways of doing the same thing).

Kurt - motivation for IrisGL -> OpenGL transition was writing and having a spec; inconsistency between IrisGL implementations was frustrating.

Lots of discussion around the value and lifetime of the OpenGL SI, conformance tests, ogtst and other vendor testing frameworks, etc. Desirable to have more open source bases people can contribute to, but nobody seems to be able to contribute engineering effort (alt.software would do it if paid :-)

Also, if a common codebase existed, it's unclear whether it would be applicable to vendor drivers, which have forked a long way from the ICD/SI codebase.

ChrisH - will setup a discussion list (outside ARB context) on OpenGL 2.0. Start with Kurt's feature list from earlier ARB meeting.

ARB Extensions

GL_ARB_vertex_blend

The proposal contains primarily cosmetic changes since the last meeting. Substantive change on transforming blended normals - allows an ideal (aka "more correct") implementation for cases with a based matrix and derived matrices differing by pure rotations and nonuniform scales, and an alternate which is correct only in the case of rotations.

Will add an issue about why there are two formulations of the normal calculation and under what conditions they're equivalent.

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

Render to texture

This extension is in process - latest version circulated on 9/15/2000. Paula will bring in current copies tomorrow. Plan is to discuss now, develop and vote at December meeting. Still needs the WGL (and maybe AGL) equivalents to the GLX component of the extension.

Basic goal is to use the same piece of memory for rendering and as a texture. Can do this now with pbuffers and CopyTexImage, which can do a lazy copy, but this has some format limitations. Also may want to know when you're e.g. creating a cubemap or mipmap texture, and when you start and end using it for texturing and rendering purposes. The proposed spec allows this and defines semantics for these changes.

ChrisH and John Stauffer note that Apple is looking at implementing pbuffer-like concepts, and want to think about this sort of thing (there's no AGL equivalent to pbuffers today). John says it looks like the right general direction, but they need to think about it some more. Will join the working group.

The spec currently doesn't allow using a non-pbuffer FRONT buffer as a texture. This may not be a desirable restriction (D3D just doesn't say what happens in this case). It's also not an expressable constraint in the core GL spec - this restriction would need to move to the WGL / GLX / AGL layer.

George raised concerns about the compatibility of this with SGIX_video_source - like behavior. Khronos is aware of the extension and will also consider this.

Dale thinks that simply knowing that the buffer is *not* being used as a texture does not give information as to when the buffer *will* start to be rendered into again.

Concern about copy-on-write semantics (writing to a buffer being used as a texture creates a new buffer). Paula agrees this isn't the right language.

Kurt suggests defining "move" semantics rather than allowing drawables and textures to actually be the *same*. This would presumably leave the buffer contents undefined, allowing pointer-swap semantics for the "move". He's not worried about the duplicate memory required, but Paula is.

Michael suggests disallowing making the draw or read drawable be a buffer bound to a texture, addressing some multithreading issues. Considerable discussion about this.

Bill Clifford says that Khronos will probably consider "volatile" textures desirable for e.g. streaming video applications.

Paula notes that GLX supports volatile pbuffers; WGL does not, with the caveat of mode changes. May want some changes to release/COW semantics, e.g. generating an error rather than duplicating the buffer.

September 20, 2000

New ARB Members

3Dfx, ATI, Nvidia, SUN were elected as auxiliary members in the closed meeting yesterday. Membership is effective after this meeting and once the Member Agreement is signed.

WGL reimplementation (Dale)

Goal: Create a DLL under ARB control that provides an alternative to WGL for apps to link with instead of opengl32.dll.

Characteristics:

• Support for Windows 2000 / ME
• Support OpenGL 1.2 and beyond
• Support current ICDs through calls to opengl32.dll
• New interface between DLL and ICD, to avoid IP issues
• No changes to ICD interaction with OS
• Fixes problems with
  • Extensions
  • WGL Errors
  • Jump table overloading (and copying)

ARB-controlled items:

• Specification
• Source code for DLL and SDK
• Man pages
• Enum allocation
• Conformance tests

Issues:

• How to deliver DLL and SDK
• Who owns source code
• Timeframe (1 year or less)
• Is there enough interest?
• Issues added by ChrisH:
• Compatibility across all Windows OSes.
• As much compatibility as possible across other OSes, for vendors keeping a single crossplatform source base.
• Most WGL stuff is currently in GDI32 - need to handle driver interactions, e.g. clipregions. Bimal disagrees, saying that the ICD already handles this.

Jon will setup the working group mailing list. Dale and/or Bimal will lead. Dave Zenz says that Dell's ISV group can provide data and perhaps help evangelize the new interface.

ARB Extensions, cont.

ATI programmable geometry extension

ATI handed out a spec describing their extension (will copy to the opengl-participants list). No IP is involved. In the flavor of D3D, but tries to fit with the OpenGL programming model. Not shipping this today; haven't even implemented yet. Just asking for feedback and brainstorming. Doesn't include curved surface stuff, but replaces the OpenGL pipeline between vertex specification and clipping.

Would like to hold off on working group for a little while, so ATI can get input from ISVs. Jon suggests that ATI should consult with Michael Duncheon regarding the risk scenarios with what they're trying to accomplish here.

Render to texture (cont.)

Paula brought copies of the current spec. Outstanding issues:

• Should there be backing store on rendered textures, or should they be volatile?
• What happens when you try rendering to a color buffer that's bound to a texture? Currently the spec says that a new buffer is created. Could generate an error. Could discard rendering, like rendering into the null clip. Could block until the buffer is unbound - not a good idea, can easily introduce deadlock.
• Should attributes be per-color-buffer or per-drawable?
• Usage scenario:
  • Call GetFBConfig to get a visual supporting rendering to texture.
  • Create a Pbuffer WRT this config, including texture and perhaps mipmap/cubemap attributes.
  • Use e.g. SetDrawableAttrib to change the mipmap level or cubemap face the buffer is to be bound to.
  • Call RenderTexture to bind the buffer to the texture.
• What happens to ancillary buffers when binding occurs? Probably should have undefined contents.
• Problems with allowing Windows to be bound as textures (resizing, invalidation, etc.). Michael suggests allowing only pbuffers to be so bound.
• Allen mentions shadow maps and asks if the extension can address binding e.g. depth buffers as well.
• Considerable unhappiness from ChrisH about volatility of these textures across mode switches. This is properly a WGL issue but isn't currently addressed (nor are any other such issues, since there isn't a WGL spec). Possibly an issue for Dale's working group.
• What happens when CopyTexImage(NULL) or DeleteTextures happens WRT a bound buffer? A: should release the memory back to the pbuffer. The pbuffer, not the texture, owns the memory involved.
• Bimal counters that the bind operation should make the memory owned by the texture, not the pbuffer.
• George encourages Kurt's suggested "move hint" as an alternative approach. Also suggests that there could be "texture buffers" in addition to draw buffers.
• Bimal is uncomfortable using MakeCurrent to associate a texture with a read buffer, and asks if there should be a MakeCurrentTexture call.

GL_EXT_state_object

Brian Sharp picked this up from David Blythe. Brian's motivation: driver writers seem to hate Push/PopAttrib, but as an ISV he loves it. Wants to pick up that functionality while fixing some problems with PushAttrib. Main objection: why is this dramatically different from display lists?

Nick Triantos apparently objected that all of this could already be done with display lists. Gary Tarolli objected that there could be some efficiency losses by the coarse granularity of the state interface, compared to specifying exactly and only the state needed in a dlist.

Michael initially favored this when texture_env_combine was created, although his need has diminished in importance given experience that the cost of a few additional state-setting calls is lost in the noise compared to the expense of actually changing the texture state. He's also concerned about bloating the API for convenience.

George doesn't like replicating the state bits as state enums. Jon doesn't share Brian's concern about running out of state bits (could at worst define a GLlonglongbitfield type).

ChrisH thinks saving state for e.g. complex rasterization path configuration is more important than replacing Push/PopAttrib.

Michael notes that there's no reason to think this will improve performance, and if not, then dlists should be adequate for the programmer convenience angle. Rich and Evan agree. Bill Armstrong notes that apps caring about performance are already sorting for state; this is more of an OpenGL 2.0 feature.

We'll table this for now, and put it in the registry in the obsolete / abandoned section. ChrisH / Brian will write up an Issues section describing why we are doing so.

GL_ARB_texture_lod_bias

Nick was going to resolve this after the last meeting, but this hasn't happened yet. Michael will ask him to send out an update, try to decide on the environment vs. texture state issue at the October face to face meeting, and vote on it thereafter.

Bill Armstrong pointed out that the purpose of the SGIX and proposed ARB extensions is different, so they can coexist.

Vertex array objects

Brian Paul picked this up from David Blythe. Goal is to have a more efficient way of storing and processing vertex data. SGIX proposal treats vertex objects ala texture objects. Carmack suggested an alternate dlist-based approach in January 2000; Brian turned this into an alternate proposal.

Neither one of these has been prototyped / implemented yet, and they aren't ready for making decisions without such data.

Lots of discussion about the differences between the two extensions and how it might map onto hardware.

Brian Sharp would like to determine if there are any usage cases where Brian Paul's EXT proposal is slower than Blythe's SGIX proposal. George likes the symmetry of the SGIX proposal with texture objects, as contrasted to the bind-free behavior of the EXT proposal.

Brian Paul will try to bring back a sample implementation by next meeting.

GL_ARB_texture_env_combine

No progress since last meeting. Michael thinks this is a deadend approach; at the time the EXT version was written it was a reasonable direction, but now we're moving towards more general programmability.

ChrisH says that many ISVs use the EXT form today, since it works on multiple generations of current hardware. Having vendor-specific features exposing the exact capabilities of their hardware, perhaps layering on a common subset, is not a bad thing.

We should think hard about how to capture more general purpose programmability. Some people think it's it's too early to try and standardize, and we should let a thousand flowers bloom.

The ARB proposal offers additional functionality over the EXT version, which is not supported by relatively recent hardware like G400 and Rage128.

After much discussion, Bimal will revise the language on behavior with undefined textures and bring back the ARB proposal for a vote. The fetch/blend distinction is more of an OpenGL 2.0 feature. Working group will be tabled.

ChrisH inquired about an extension versioning mechanism. After considerable discussion on the extension process, this issue was dropped for the moment - hasn't come up often enough to be a big concern.

Object Management

Allen Akin recently sent around a white paper proposing a general OpenGL object management scheme.

Allen's challenge for Participants: figure out how to characterize the different sets of memory you might use.

John Stauffer noted that Allen's proposal is in opposition to the basic MacOS X design, which strives to virtualize all resources. He'd like to see an approach that could encompass both usage patterns.

A great deal of discussion followed, which I haven't attempted to capture in detail here. People asked for clarifications, objected to some design decisions, etc., but were generally supportive of proceeding. Allen will lead a working group.

Working groups for next quarter

Tabled:

• state_object - tabled
• texture_env_combine - tabled (will call ARB vote on current spec)

Continuing:

• vertex_array_object
• render_texture
• texture_lod_bias (Michael will follow up with Nick Triantos)
• vertex_blend - continues as a forum for Matrox matrix_palette proposal

New:

• Object management (Allen)
• WGL replacement (Dale, Bimal)
• Developer conference (Jon)
• Dependent texturing - Brian Sharp may lead this working group.
• swaptmesh - ChrisH will determine ISV interest and may lead this working group.

Next Meeting