Summary of Discussion Topics

• Next ARB Meeting
• New Members
• ARB_window_pos
• INTEL_texobj_lod_bias
• ARB_vertex_program and ARB_pipeline_program
• Other ARB Extensions
• OpenGL 1.4 Proposal
• "OpenGL 2.0" Update
• Revisiting EXT_fog_coord and EXT_secondary_color
• OpenGL 1.4 (cont.)
• ARB_render_texture
• Monthly Teleconferences
• "OpenGL 2.0" (cont.)

December 11, 2001

Next Meeting

E&S has offered to host in Salt Lake City in March, between Olympics and Paralympics (March 5-6 are good dates). Compaq has offered to host either in Silicon Valley, or Massachusetts. Tendency towards SLC. Jon asked everyone to say yes or no on SLC by next week.

New Members

ATI was advanced from Auxiliary to Permanent membership status, and Dell was voted in as a new Auxiliary member, by vote of the Permanent ARB members.

ARB_window_pos

Last issue was handling fog coordinates in the current raster position state. Can either set raster distance to 0, or to the fog coordinate. Did not reach consensus. Would like the ARB to consider the two options Brian enumerated in email, and conduct a vote.

OpenGL spec maintained raster z value in eye space, applied when rasterizing pixels. The fog_coord extension didn't really want to support raster position, but dealt with it some. Couldn't overwrite the raster depth - that would break existing code - so introduced a new piece of raster state.

This is substantially different than vertex processing, where the additional state need not be persistent, since it's processed immediately. Bimal feels ISVs will be confused by needing to make some fog calls prior to RasterPos, and some after. Pat says that secondary_color and fog_coord were somewhat botched in their specifications. Every vertex should have associated with it a fog coordinate; RasterPos should be treated as a vertex which is fully processed and captured for later use. Lengthy discussion on fine details of RasterPos followed. This was very hard to capture, and conflated a bunch of discussion of EXT_fog_coord together with ARB_window_pos. There seemed to be general agreement between Pat and Bimal that NVIDIA's suggestion was OK, and that we should vote for option (B). Pat wants to fix fog_coord to apply the decision as to where the fog coord comes from at a per-vertex level - e.g. move the mux up to the RasterPos level. Pat wants to (1) finish ARB_window_pos (2) change EXT_fog_coord => ARB per discussion (3) change EXT_secondary_color => ARB accordingly.

INTEL_texobj_lod_bias

Bimal led. We previously discussed having an LOD bias both per-object and per-environment. Previous attempts at an ARB extension failed because of mixing the two. Per-environment (lookup unit) bias can later be layered on top of the Intel per-object bias.

ATI is interested in doing this as an EXT.

Discussion of per-environment bias and why we didn't standardize on this before. NVIDIA prefers using a new target for TexEnv ala their existing EXT_texture_lod_bias; Intel prefers new entry points.

Bimal will take last year's ARB_texture_lod_bias proposal and modify for a new entry point.

ARB_vertex_program and ARB_pipeline_program

John Stauffer and Bob Beretta led. First decision their working group made: should there be separate management / implementation interfaces? Adding in e.g. fragment programming makes apparent why this is desirable.

As an example, looked at putting ATIX_fragment_shader into this system; 10x fewer entry points / enumerations when layering the functionality on ARB_pipeline_program.

Jon asked about instruction length limits. Some operations are disallowed from expanding to multiple instructions and/or consuming additional intermediate registers; some are allowed.

Pat asked about the generic data matrices in ARB_pipeline_program - these seem more like vertex state. It became clear that matrices are already useful at the fragment level, e.g. the COLOR matrix, so additional matrices should be allowed.

Bimal suggested adding a query for implementation-dependent error string, and changing GetProgram to e.g. GetProgramAttributes, since is seemed to be getting a lot more than the program.

If the minimum stack depth for data matrices is 1, then Push/Pop is useless, so why support it? Pat recommends making the depth at least 2.

Parameters associated with programs are named PROGRAM_PARAMETER; NVIDIA's extension uses this where Apple's uses CONTEXT_PARAMETER. This naming collision should be avoided; it's not the best name NVIDIA could have chosen, but it's out there and widely used. Bob notes there are other conflicts resulting from unifying the ATI and NV extensions.

Normalized parameters capture scaling behavior of e.g. Color - this ensures VertexAttribs can do everything existing entry points can do.

Some discussion of maintaining connections between the existing fixed state machine and programmability. From one view, the fixed machine becomes useless baggage; from another, it represents a convenient, well-defined way to specify lots of relevant parameters to programs. NVIDIA has had some difficulty in their work with resolving all the interactions with the complex fixed state machine, and keeping state properly updated; only allows access to matrices because of the utility of e.g. Rotate. Lots of discussion on pros and cons of the two approaches.

Dale is concerned about additional error checking required in Begin, to ensure there's a valid program. Typically this would be handled by dispatch table swizzling.

Should entry points be fully expanded for per-vertex calls by type/size? Would amount to 112 calls. Chose to simplify by making size a call parameter, leaving some flexibility for future use with matrices by increasing size to 16. Also makes it clear you won't have immediate-mode entry points.

There are 6 operations taking a matrix (4 contiguous vectors) as arguments. No apparent benefit on current hardware from knowing that a matrix is a single entity. Therefore it might be more beneficial to apps to simply construct matrix ops from macros, and make the macro ability available to apps. The vertex language is designed to support macros. NVIDIA supported this position from their own experience. Jon and Nick both had some concerns about overwriting intermediate results in the macros (e.g. when one of the sources is also a destination for the M4x4 operation).

This turned into more general discussion about compound vs. simple instructions, and subtle differences in this area between ATI and NVIDIA's current hardware.

Followed asthetic discussion on syntax, case sensitivity in identifiers (particular operation names), etc.

Nick and Bob had a long discussion about the compatibility of the existing NVIDIA extension and the Apple proposal, and the difficulty of supporting Apple's extension on NVIDIA hardware.

A straw poll on going forward with the Apple proposal conducted:

• SGI - Yes. Regrettable that non-technical issues impeded adoption of NV_vertex_program 18 months ago, but that window of opportunity has passed and we need a unified API.
• 3Dlabs - Yes. Dale would like to see fewer HW implementation caveats in the spec, however, and perhaps remove stuff dealing with e.g. evaluators.
• Intel - Unwilling to vote to create an ARB specification with pending issues. Likes the technical direction and the split between the program specification and vertex program.
• Microsoft - Aside from the IP issue, which is a big sticking point, getting stuff that works on multiple hardware platforms is good. Thumbs up.
• ATI - Yes. The dynamics have changed since NVIDIA introduced their extension; most important thing for OpenGL is to decide on one unified extension. Apple, ATI, NVIDIA have worked hard over the last few months. ISVs as a whole know this is coming, and those ATI has spoken to like this direction; there is short-term pain. Some technical details to be resolved.
• Matrox - Yes. Some technical details remain, but it's a good direction.
• Sun - Yes.
• IMG - Very supportive. Layering model is very nice. If IP issues can be resolved, we want to go ahead.
• NVIDIA - Fundamental problems with some technical issues, e.g. doing matrix multiplies as macros. Some other problematic instructions, such as multiple ways of doing EXP. A lot of the work is good. Some concern about MAX_EMULATED vs. MAX_OPTIMIZED. There's a legacy support issue to deal with.
• Compaq - Yes; we believe in standards above almost anything else and will vote in favor. Still some work to be done, and hopefully vendors will come to consensus.
• Brian Paul - Generally in favor. Likes the layering model. Minor concerns about commas, case sensitivity, etc. could be dealt with be external preprocessors.
• A|W - Yes. Generally in favor of anything that becomes standard. We do support NV_vertex_program, but would prefer having just one standard.
• IBM - Yes.
• Apple - Yes.

Apple wants to have only 2-3 more revisions, followed by an email vote in ~1 month. They feel nothing in the bylaws prevents voting on the spec despite NVIDIA's known IP claims.

Nick suggests looking at something more like the MPEG consortium model in the future, rather than an SGI-centric organization.

More ARB Extensions

Brian has been working on updating some vendor extensions to ARB status - ARB_window_pos (covered this morning), ARB_secondary_color, ARB_depth_texture, ARB_shadow, ARB_shadow_ambient. All now need to be updated to refer to the OpenGL 1.3 specification.

Cleanup of SGIX_depth_texture extension, addressing some depth texture behaviors and texture borders. No major open issues. Pat noted a few minor language nits.

Cleanup of SGIX_shadow, increasing flexibility for the future. Works in conjunction with depth textures to enable shadow maps. Pat notes some bizarre interactions with cubemaps and 3D textures - what is the meaning of r with respect to cubemaps, which don't have this coordinate?

ARB_shadow_ambient is based on SGIX functionality.

ARB_window_pos - Pat will specify cleanups WRT rasterpos fog coordinate tonight.

Should all these be ARB extensions? If they're going to be folded into OpenGL 1.4, then probably not; otherwise yes, since there's existing demand.

Pat will tomorrow pass out proposed specs for ARB_fog_coord, ARB_secondary_color, and ARB_window_pos which reflect moving the fog coordinate switch from rasterization to vertex processing.

OpenGL 1.4 Proposal

NVIDIA is proposing a similar process and cycle time as for OpenGL 1.3; they enumerated several criteria in their white paper.

After some discussion, there was a straw poll on people's immediate response to doing OpenGL 1.4 as proposed:

• SGI - supportive.
• Sun - asked some questions as to how this particular list of extensions was arrived at. Particularly interested in multi_draw_arrays, point_parameters, depth_texture, shadow. Not much feedback from ISVs asking for the others.
• IMG - depth_texture and shadow are cool; are they very useful? Do we want to mandate them given precision / accuracy issues?
• Compaq - supportive. Can potentially do interesting global illumination stuff based on shadow / depth_texture.
• Apple - all seem fine.
• 3Dlabs - Dale concerned that ISVs were expecting programmability in OpenGL 1.3, and still won't get it. Vertex shaders really should be part of this for it to be interesting.
• Intel - nothing truly compelling, like vertex programming would have been. Concerned about the rightness of adding secondary_color instead of a "second" color since "secondary_color" does not have an associated alpha. Could support point_parameters. Concerned about utility of depth_texture due to precision issues.
• Microsoft - not a lot to it; wouldn't either support or oppose it. More interested in 2.0 directions.
• ATI - not many problems with proposed features. Agrees with Dale that it would be a big mistake to come out with OpenGL 1.4 without programmability - it sends the wrong message to approve 1.4 without it. If this means slipping 1.4 by a quarter, that's OK. Evan wondered whether shadow maps are well enough understood and high enough quality to codify - there are still SIGGRAPH papers coming out in this area.
• Matrox - likes most of the proposed features. Some reservations about shadow mapping, because some people can't implement it. Vertex programs should be in 1.4; what's proposed is a smaller step than 1.2 -> 1.3.
• Brian - OK with the 1.4 direction; a nice bridge to 2.0.
• IBM - Unified vertex spec is more important at this point. 1.4 looks more like a marketing move otherwise.

NVIDIA notes that many apps die with very large extension strings due to strcpy into fixed-size (256 bytes) buffers. One of the rationales of 1.4 is to reduce the extension string size.

Evan asked about including the blending features in the ARB_imaging subset; Nick says few vendors support these.

"OpenGL 2.0" Update

John Schimpf and Randi presented a status report on 3Dlabs' proposed major revisions to OpenGL.

3Dlabs has concentrated on white papers and reviews of them up until a few weeks ago. Incorporated feedback and otherwise updated white papers last week. Of ARB members, ATI, Apple, SGI, and to a lesser degree Sun have provided feedback. Discreet, Epic, Id, PTC, Rad Game Tools, SideFX, SoftImage, Vital Images among non-members have provided feedback. ISV feedback is overwhelmingly positive.

About 300 responses to an opengl.org survey asking who supported the general direction of the work, with some interesting comments. General flavor of it's about time.

John Stauffer asked about IP issues. Does NVIDIA have any ideas on how to move forward? Nick said they gave John offline feedback that programmability is a good direction to move forward; many of the other proposed features serve some markets, but he's not convinced that all those things belong in OpenGL.

Alan asked about the relation between the Apple programmability extensions and 3Dlabs' 2.0 proposals. Randi says they are independent proposals, one high level and one low level - but there may be shareable APIs, such as the pipeline_program extension. Apple has tried not to go too far that way, to avoid fragmenting the API.

December 12, 2001

Revisiting EXT_fog_coord and EXT_secondary_color

Pat looked at doing needed revisions; this will be more work than it appeared at first. There are three likely ways of splitting fog computations during vertex processing and rasterization. His inclination is to defer dealing with this until we promote the extensions to ARB status, and to follow Brian's "Option A" in revising ARB_window_pos.

There's some uncertainty left with ARB_shadow, too, regarding behavior with cubemaps. Pat suggests leaving it undefined for now and revising the spec language to be OpenGL 1.3-based. We'll ask Bimal, Pat, Brian, etc. to make all these minor revisions and bring all 5 extensions forward for an email vote within the next week or so.

OpenGL 1.4 (cont.)

Pat would like to proceed at a working group level with specifying the functionality, whether or not it's going into a core spec revision. He'll solicit input from other vendors as to what the exact functionality in 1.4 should be.

Straw poll on whether it's worth doing 1.4 even without vertex programming shows 4 in favor, 6 opposed, and 3 abstaining.

ARB_render_texture

Dale noted a problem with multithreading and Bimal proposed a fix causing contexts to track the pbuffer mipmap target state. There were no objections when emailed out, but several people at the meeting felt that the best way to handle this was to introduce GL state.

However, since the extension was already shipping, it was decided to make minor tweaks. Pat proposed that binding to a pbuffer would cause render texture state to be updated according to that attribute of the pbuffer. Updating the state from one thread would not update other threads; e.g. we would be adding (user-invisible) GL state. Pat will update language and send it out.

Monthly Teleconferences

We'll resume working group teleconferences in January, focusing on "OpenGL 1.4" features. First call with be Thursday, January 10th at 10 AM Pacific.

"OpenGL 2.0" (cont.)

Overall response is positive. Randi will walk through some possible ways to proceed and ask other participants to think about what they may be able to contribute.

Open topics / expertise needed:

• Programmable tesselator.
• Compiler technology - standardized parser, other common tools (debuggers, etc.). Vision: parser/compiler -> intermediate language; vendor-specific IL -> hardware translator.
• Implementing proposed new types of features as 1.3 extensions. 3Dlabs has worked on async features. Some areas of white paper are interesting but problematic, e.g. commands in background stream, switching between foreground and background streams. Implementation would help flush out details.
• Object management framework split out into its own white paper.
• Memory management white paper - policy and priority features need experience.
• OS-specific issues. 3Dlabs is mostly focused on Windows. Some GLX experience, very little MacOS knowledge.

Schedule - lots of work in the proposed timeframe (SIGGRAPH 2002). Probably overagressive from an engineering perspective; but would like to see a fairly complete spec by then, even if still being debugged.

Would like to demonstrate shading compiler at the next ARB meeting, and have some definition of an intermediate language; want demonstrations at SIGGRAPH showing as much of this as is possible. Depends on what individual vendors can commit.

Some discussion of what parts of the proposal are of most interest. Wide agreement that vertex/fragment shaders were most important. Randi conducted a straw poll for what the highest priorities should be, 2 votes/person:

• Pack/unpack engine - 1
• Object framework - 11
• Aux data buffers for multipass - 0
• Memory management - 3 (Bimal concerned about longterm application portability)
• Asynchronous operations - 6

Some discussion on doing away with ability for apps to generate their own names (handles). Generally not seen as a problem.

Bimal objected to the current prioritized texture binding model (e.g. 2D supercedes 1D etc.) and asked if we could get rid of it in OpenGL 2.0. The current object paper simplifies this by binding a specific texture directly to a texture unit.

Bimal also objected to the multitexture ActiveTexture selector model in preference to identifying the target at call time. This hasn't been addressed yet. Similar issue with MatrixMode.

Randi summarized: they'll be in contact with people individually over the next few weeks to determine where they stand and what they might contribute. He asked people to think about the areas that need help and offer any ideas they have. Plan to get interested parties together and make progress.

Thanks (again) to Apple for hosting this meeting!