Summary of Discussion Topics

• Introductions and Status Updates
  • Developer Conference
  • Khronos Embedded APIs Working Group
  • Khronos SIG Status
  • Future Meetings
• ARB Extensions
  • WGL Error Handling
  • WGL_ARB_render_texture
  • EXT_gradient_clear_color
  • ATI_vertex_array_store
  • ATI_vertex_transform
  • ATI_fragment_shader
  • Miscellaneous Issues
    • Double- vs. triple-buffering on Windows
    • IBM_texture_mirror_repeat promotion
    • Depth and shadow texture extension promotion
  • Object Manager Extension
• OpenGL Future Directions

March 13, 2001

Introductions and Status Updates

Developer Conference

Bill Mannel (OpenGL product manager at SGI) priced a two day, multiple track event out at $250K. Smaller events would cost less, but it doesn't scale down linearly. SGI can organize, but can't front this amount by itself.

If enough other participants can front money ($25K/each - could be considerably less depending on scope of the final event) we can proceed. Proceeds from the conference would be distributed back to contributors pro-rata.

To move forward, interested companies need to identify their marketing contacts and place those people in touch with Derek Tarvin (dtarvin 'at' sgi.com, 650-933-5809) and Bill Mannel (mannel 'at' sgi.com, 650-933-1867). ATI (Evan Hart) and Dell (Dave Zenz) are both interested in following up.

Khronos Embedded APIs Working Group

Jon relayed an update from Neil Trevett of 3dlabs on the progress of embedded APIs work in the Khronos SIG:

• 10 of 12 companies at ARINC (aerospace standards body) meeting want to sign up.
• Phillips and other appliance companies also interested.
• Pursuing contacts at Liberate, Palm, Sony Research.
• Trying to get new participation agreement in place. Committee of interested companies helping on this. Intel Legal is writing up first draft.
• Lots of marketing activities. Press conference invite for NAB has gone out. Generally under control.
• Draft slides being used in NDA contacts with evangelized bodies.
• Message to ARB: Khronos is pursuing this. Making sure it's done in cooperation with the ARB. Getting lots of people ready to sign up once participation agreement is in place. Hope to have first meeting of embedded working group in early April, before NAB.

Khronos SIG Status

Bill Clifford reports that Khronos is reviewing revision 0.7 of the draft OpenML specification; the final specification should be available for public distribution in June. More details will be presented during NAB (week of April 24th). IDF presentation from 2 weeks ago will go up on khronos.org website soon.

Future Meetings

We need a volunteer to host the June 12-13 ARB meeting, preferably on the west coast of the US.

Teleconferences fell through recently because of the disruption associated with 3dfx going out of business - they were leading or heavily involved in several working groups. However, it's generally considered valuable to have the more frequent forums even if there aren't specific agenda items.

Going forward, we'll plan monthly teleconferences. Bimal will send out reminders one week before. Schedule for Q2:

• Telecon: Thursday, April 12
• Telecon: Thursday, May 17
• ARB mtg: June 12-13, host TBD

ARB Extensions

WGL Error Handling

Bimal passed out a document discussing the WGL error mechanism.

Discussion points:

• Should poll ISVs before doing much work on a WGL error extension. Could use opengl.org polls for this.
• Dale did some work on a WGL replacement / ARB version, but has stopped until other people are willing to help out.
• Discussion on whether a WGL replacement would help or hurt OpenGL. Possible benefits:
  • No need for wrappers/GetProcAddress for 1.2 entry points.
  • Multimonitor support for Win98 would become possible.
  • Standardize pbuffer / extended visual / etc. extensions.
  However, ISVs are already using GetProcAddress. Distribution might raise some issues - centralize on e.g. opengl.org or GLSetup, have ISVs ship it with their apps, etc.?
• There are several separate (although often conflated) issues: exporting 1.2 entry points; providing 1.2 functionality; providing 1.2 headers.

Bimal will follow up with code/header samples for opengl.org.

WGL_ARB_render_texture

Bimal picked this up from Paula after 3dfx went out of business. Changes in the draft specification since last time include removal of LUMINANCE and INTENSITY format support.

Bimal will:

• Fix error messages (don't create new WGL errors just for this).
• Remove WGL_TEXTURE_FORMAT_ARB (issue #23).
• Update implementation notes per discussion today.

ATI likes this, will withdraw ATI_render_texture (which was just the old version of the ARB proposal w/o 3D textures). They have an implementation running inhouse, so we should be able to call an email vote soon.

EXT_gradient_clear_color

Dale Kirkland discussed 3dlabs' proposed gradient clear color extension. Motivation is to decrease depth complexity and application complexity (saving and restoring irrelevant state), and increase performance for apps such as Pro/E and CATIA. IBM provided the only feedback. 3dlabs is shipping (although not publicizing) this. Some confusion over the spec - handout is not quite current; gradient color should not be clamped; params value to ClearParameter should be a pointer, not a scalar.

Nick, Jon Paul, and some others feel this is a problem apps should solve, perhaps with developer relations help. Some issues with the interface - might be better to specify top and bottom color parameters, and have some way to enable "ClearGradient" behavior, e.g. a ClearMode. Can remove integer parameter specification entry point. There's also concern about feeping creaturism with additional background types in the future.

After the ARB meeting, Dale circulated a new gradient clear color extension specification with the following changes:

• ClearColorMode and ClearParameterfv entry points, instead of overloading ClearColor.
• ClearColorMode determines how clearing of the color buffer occurs.
• ClearParameterfv specifies additional parameters. This extension uses y base and y gradient parameters.
• Name changed to allow for a future x gradient clear.

We'll discuss this at the April 12 teleconference, if not before.

ATI_vertex_array_store

Preliminary spec; ATI is looking for feedback. Concept is to be able to place vertex data in AGP memory and pull out vertex pointers for GL calls.

Issues include conversion to internal representation, necessity for keeping a driver copy of the application data (for updating), whether updating is desirable, whether compressed data should even be allowed (currently not discussed - affects e.g. linear offsets into the array), difficulty of synchronizing with client state (what happens if some of the arrays are in stored memory, and some in normal client memory), etc.

Shares some of the vertex_array_object proposal's difficulty with multipass rendering - configuring for the correct data formats in each pass. agenda item for April 12 teleconference

ATI_vertex_transform

New spec is mostly identical to the one handed out at the last ARB meeting. Several comments and error fixes, mostly in response to 3dfx's comments, have been added. ATI has been coding, and has a functional implementation now. Will pass out an alternative, more implementable spec relatively soon. Changes since the last version:

• Using GL enumerants in the transform ops argument allows direct access to GL state that can be used elsewhere with fixed pipeline operations, but is restrictive. An alternative would be to bind light / material / texcoord set enums to generated IDs, to avoid enumerant explosion.
• Ability to query a concatenated modelview matrix is useful to apps.
• Typed operations were proposed. In practice dealing with typeless operations isn't too difficult, but types do improve some things, and make usage easier (e.g. could drop ability to compute log2 of a vector).
• Clarified behavior of queries on programs. Reports are consistently in terms of "micro-ops", whether on the CPU or GPU. These queries are intended mostly as a development aid, not as a performance metric.

ATI has a user-level implementation of this extension which they may be willing to distribute to other driver writers.

New spec would have 3 new entry points. Open issue as to whether opcodes are typed or untyped. Evan should be able to update spec in 1-2 weeks.

Some more notional IP discussion. Bottom line is that individual companies, particularly ATI, need to work with NVIDIA to understand what IP they're claiming. Nick will talk to NVIDIA Legal to try and get a read on whether they're claiming IP on the API, or on particular implementations thereof.

ATI_fragment_shader

New proposal; no spec today. ATI thinks the ARB needs to look at this because pixel pipelines are becoming more flexible. They've been working on a framework - not necessarily the right one for everyone. Hopefully will distribute it soon; have written up man pages, but not an extension specification.

Issues: handling extended range/precision issues in the pixel pipeline ([-1,1], "superbright"), per-component texture issues, etc. Hope to have a spec prior to the June meeting. ATI will have no interface IP issues.

Trying to be more general than just current-generation ATI parts; would have had a spec much sooner if that were the goal.

Question came up about working group, ATI will start one.

Question came up about how to deal with out-of-range values, ATI is only focusing on how to deal with this within the section of fragment shading.

Bill Clifford mentioned that SGI has an extension (SGIS_color_range) that allows higher precision (float?) out to the frame buffer.

ATI suggests perhaps to include queryable precision/range values for various parts of the pipe, Videologic thinks it's a bad idea, just define a range and use scaling if needed.

Videologic would be happy with float or [-1,+1] range with scaling.

Videologic and VA Linux think that specifying queries for precision aren't useful, since it's unclear how an app could deal with insufficient precision

Videologic asks about src/dst blending as part of fragment shading, ATI's current thought is to not include this. Videologic agrees.

March 14, 2001

Miscellaneous Issues

Bimal discussed double vs. triple buffering on PCs. Much PC hardware does triple buffering and apps don't mandate PFD_SWAP_COPY behavior. Is there a need for a "never do triple buffering" control? E.g. Intel doesn't support PFD_SWAP_COPY, but some apps mandate it.

Dan: several people are shipping IBM_texture_mirror_repeat. Is it worth promoting to ARB? Several people are interested. ATI has ATI_texture_mirror_once, which may interact in odd fashions. We'll setup working group. NVIDIA asks "no cylindrical wrap".

Brian recently implemented SGIX_shadow in Mesa and found some problems in the spec. Some agreement that depth_texture, shadow, and shadow_ambient specs need cleaning up and promotion to ARB.

Bimal asked if SGIX_shadow_ambient could be added to the registry, and also that SGI determine if it has any issues with this promotion. Pixar is believed to have IP in this area.

Short discussion on render to texture semantics if app only wants to render depth textures. Would need layering on the upcoming ARB_render_texture extension, or possibly it can be added before we approve ARB_render_texture. Bimal will check.

Object Manager Extension

Allen Akin led this discussion by telephone.

Allen sees object manager and ATI_vertex_array_store as complementary.

Summary of the extension:

Multiple mechanisms for creating and using objects. No mechanisms for more complex requests - "can object be created"; managing more complex objects like vertex/pixel shaders; offscreen rendering surfaces.

Want interfaces for managing multiple pools of memory and (potentially) automatically moving objects around between them.

Interface identifies objects with an (enum type, uint id) tuple. Operations are to move objects between pools, copy into pools, pack a pool, and free an object from a pool. There's also a "trial run" interface to determine if some arbitrary set of objects will fit, and estimate how long those operations will take.

Prototype implementation is mostly done and currently being tested. Assumes linear memory layout of pools; this is a useful for much current PC hardware and the code may be generalizable to future hardware. Bimal notes that Intel uses tiled memory layouts for textures. Unlikely that all hardware will use linear layouts going forward. So, API will tell whether or not a set of objects will fit, but won't assume linear packing or give "free space" metrics.

Dale asked about how the APIs work with multiple applications interacting. Allen has thought some about this; one thing you can't do is invoke the test API and rely on its results holding true when actually invoking the operations, since resources are shared. Two ways around this: lock memory pools, or virtualize them.

Dale notes that apps don't always know the best place to put stuff. Would it be better for apps to specify use of objects, instead of where they should live? Allen agrees, but thinks that's a separate issue. Need a function that maps those criteria into a preferred pool.

Dale is concerned about changes in CPU/gfx. requiring apps to update frequently to use the correct explicit maps. Allen notes that multiple pools may be mapped onto a single physical pool, which provides some coping ability. Intent is to preserve upwards compatibility, while allowing people who really think they know what they're doing to have control (or shoot themselves in the foot).

Nick thinks that apps can't track evolution of hardware and drivers, and drivers really should have control. In hindsight, he would have preferred that NV_vertex_array_range not specify read/write frequencies in the allocate call, but separately as parameters. Allen has tried to do this. He asks that people who know what upcoming attributes will be important work with him to get those into the API.

Bimal says that Intel places textures in different types of memory to increase memory bandwidth when multitexturing. Videologic has this issue as well. Allen had tried to address this in the past; may need to restore that ability if this technique is widely used.

Bob Beretta says that Apple defers texture loads until just before use, which allows placing textures optimally. Also, heavy use of OpenGL in the OSX window system precludes prescriptive applications - hints are welcome, but no more. WRT the first point, Allen notes that this is classic OpenGL behavior, and the object manager doesn't preclude this. On the second point, the OS isn't constrained about use of the pools. Allen says that the Apple model can't guarantee real-time or even interactive response rates; by allowing applications to schedule transfers, pipeline stalls are avoided. Bob says some apps have encountered this; one technique is to draw e.g. a single textured point to force loading. Bob would prefer that the extension just provide information to the app on what it can do, rather than allowing apps to specify exactly how it's done.

Scene graphs are headed towards wanting sophisticated management, e.g. preloading textures in previous frames. Providing this ability is part of what the object manager is designed for. A lot of the criticism received on OpenGL memory management is that it's at too high an abstraction level. Allen is trying to push it down to where apps don't behave unpredictably, without exposing driver internals.

Intel and NVIDIA think the new line is drawn too low. Allen says the line can be moved so that apps don't specify where objects live, but does specify when they are transferred. But it's not clear what this means with the existing attributes.

Example: for textures, we'd want to know if it's used for drawing; if and how it will be updated; which texture stage it applies to; perhaps whether it is a target of render to texture; perhaps others.

Further discussion about relative uselessness of the current texture priority mechanism - in part because some drivers just ignore priorities - and some people's desire for an intermediate complexity mechanism.

Allen will finish up his implementation in the next week or so and distribute it. Functionality case of most concern is whether pools are specified by a pool name, or implied by some combination of attributes.

Allen would like to talk more with Apple, since their system seems the most different in terms of usage patterns.

OpenGL Future Directions

Jon started by laying out options for OpenGL evolution:

• Just keep approving ARB extensions.
• OpenGL 1.3 - standardize on existing ARB extensions without creating new functionality. Set a new capability bar and drive implementations in that direction.
• OpenGL 2.0 - significant API revision for programmability and other new concepts; also address longstanding nits (texture borders). Not backwards compatible, and would be a major time investment by the ARB and IHVs.

Everyone was first asked to comment without discussion, to get a sense of the ARB.

Bimal thinks the versioning mechanism with mandated behavior no longer works, but the ARB extension mechanism works fine.

Nick says NVIDIA could contribute resources towards a 2.0 spec, but doing 1.3 would be more immediately useful.

Several people think 1.3 (1.4, ...) and 2.0 could be done in parallel. 2.0 is much more than getting rid of things we don't like; new issues like programmability, object management, etc. are part of this.

Jack says that backwards compatibility when removing features is important - the first extension on top of 2.0 could be a "1.2 compatibility" extension.

Chris Fraser would like us to consider for 2.0 some of the extensions that fell by the wayside in the past - e.g. state objects. He thinks embedded markets want smaller versions of 1.2, rather than 2.0.

Brian agrees with dual 1.3 / 2.0 approach. First big decision is whether backwards compatibility is desired.

Jon Paul asks about the window interface - do we keep using WGL on Windows?

Jon would like to do 2.0, but is concerned about manpower requirements and resolving IP issues holding up programmable pipeline extensions. 1.3 can be done quickly.

Allen notes that requiring software implementations of features not in hardware can hold things up. He's also concerned about IP. Thinks that for the embedded space, a different type of modularization is appropriate - perhaps a stronger emphasis on multivendor extensions.

Kevin wants to make sure there are conformance tests for 1.3 features. Should set aside time to brainstorm on OpenGL 2.0.

Dan thinks 1.3 needs to have mandatory functionality; otherwise it's pointless. Bill Clifford agrees - can be a good marketing vehicle, but only if there's differentiation from just listing a bunch of extensions. 2.0 needs to address where we want to be 5 years from now. It will be hard to sell a non upward-compatible API; what can't we do with 1.x that would require 2.0?

Dale believes backwards compatibility is a big selling point; people trying to build on DirectX complain about constant changes. Leery of taking out features, but maybe there's a way of doing it that establishes a common subset of functionality. 1.3 would be interesting to do, and establishing a Khronos-related subset might be valuable too.

Next, we took a first cut at new OpenGL 1.3 features by a straw poll on all existing ARB extensions. Results were:

• ARB_multitexture - Yes
• ARB_get_proc_address - Yes
• ARB_transpose_matrix - Yes
• ARB_buffer_region - Maybe
• ARB_multisample - Maybe. Depends on on whether multisample capable visuals/PFSs are required or not.
• ARB_texture_env_add - Yes
• ARB_texture_cube_map - Yes
• WGL_ARB_extensions_string - Yes
• WGL_ARB_pixel_format - Yes (group of 3)
• WGL_ARB_make_current_read - Yes
• WGL_ARB_pbuffer - Yes
• ARB_texture_compression - Yes
• ARB_texture_border_clamp - Yes
• ARB_point_parameters - No (probably)
• ARB_vertex_blend - No
• ARB_matrix_palette - No
• ARB_texture_env_combine - Yes
• ARB_texture_env_crossbar - No (probably)
• ARB_texture_env_dot3 - Yes

There was some desire to synchronize GLX and OpenGL version numbers (WGL thus far has no version number). This might fail for the same reason that they drifted initially - a minor revision to correct a core problem.

Summary of the versioning discussion:

• The ARB will proceed with OpenGL 1.3, to be completed at SIGGRAPH.
• NVIDIA and ATI both said they would have working implementations at that time.
• SGI (Bill Mannel) will lead PR effort with marketing folks from other participants.
• OpenGL 2.0 will be an ongoing effort with time set aside at all future meetings.
• If the Khronos SIG's OpenGL extensions for OpenML are available quickly enough (they're targeting a June spec release), they may be added to OpenGL 1.3 as a set of optional functionality ala ARB_imaging.
• NVIDIA volunteers to do some amount of 1.3 conformance tests.
• Intel also has some conformance tests - would like to get PR mention in return for contributing them.

Thanks to HP for hosting this meeting!