Summary of Discussion Topics

• Introductions and Status Updates
• OpenGL Programmable Shading
• 3Dlabs "OpenGL 2.0" Presentation
• ARB_texture_mirror_repeat
• Scissor Application to WGL_ARB_buffer_region
• Conformance
• Crossbar Language in the 1.3 Spec
• GLX 1.4 Spec Draft
• New Auxiliary Members
• Next ARB Meeting
• Additional Shading Discussion

September 11, 2001

Introductions and Status Updates

Brian offered to circulate proposed ARB shadow map extensions; there's been limited interest to date, so we won't discuss them at this meeting.

Jon has updated the extension registry and placed Bimal's GLsdk on http://oss.sgi.com/projects/ogl-sample/SDK/. There will also be a pointer posted from www.opengl.org today.

OpenGL Programmable Shading

David Kirk reaffirmed NVIDIA's committment to extending OpenGL for the good of the whole community. They got off on a bad foot with some of the legal positioning on NV_vertex_program, and would now like to offer the extension to the ARB free of any encumbrances or conditions, in contrast to the previous position.

Bimal asked if the previous constraint on adopting the extension only without changes still applied. David says that as we move away from features to programmability, NVIDIA is focusing on the processor instruction set. They'd resist changes which made the extension incapable of running on their platform, but would be more receptive to other changes. Going forward, use will be made less restrictive; IP does underlie the extension, but NVIDIA would like to license it freely and openly, without restrictions.

PeterG: some people like the string-based NV approach, some like the procedural ATI approach. Would NVIDIA be receptive to supporting the other? A: Yes, since this is a layering issue, not branching. NVIDIA will bring the extension back for ARB consideration.

Bimal: ATI has worked well with the ARB. How does ATI see this change affecting them? AllenG: we've promoted our extension to EXT status, working with Matrox. We're pretty far down the current path. NVIDIA's extension is in use; ATI's extension is out there and also appeals to people. Some compromise is needed. The layering approach has possibilities. But this is still a short-term issue, and OpenGL 2.0 needs to be addressed. It's encouraging to hear NVIDIA saying this, though it's too late to find a single solution now.

David: it's like the Pentium instruction set, new ones get defined but the existing ones are immutable. Pat: there's a versioning mechanism already built in to the NV interface.

Allen: maybe we can now start actually comparing the instruction sets; we're not that far away, since we're reflecting the same feature set.

PeterG: Has there been analysis of the intersection of the two extensions? Pat: there are some differences; not extreme.

Bimal: biggest issue is how the program gets specified. Some of the researchers seem to like the ATI approach better, since they're working on higher level toolkits and want fine control over what instructions get generated.

David: it weakens the strength of OpenGL to have incompatible branches, like the DX 8 / 8.1 split. Having a single path is much better. Eric: I'm less worried about the API. The ATI extension seems to abstract the hardware more, NVIDIA's exposes the hardware, and that's my inclination. Peter: there will also be flexible CPU-based implementations, like Apple's Altivec. Having such flexibility (e.g. the number of registers available) might help drive innovation by the researchers.

AllenG: Eric brought up good points. Where do we choose to compete? On the API, or at the hardware level? OpenGL started out leading the hardware; now the hardware is leading the API. Do we want to look behind, or years ahead? ATI made a conscious decision to abstract the API in this case, in order to get something out.

3Dlabs "OpenGL 2.0" Presentation

Neil Trevett brought a detailed presentation of their ideas, starting with marketing aspects.

David: question the assumptions of making OpenGL 2.0 include hardwired functionality from OpenGL 1.x. The elegant-feeling answer is to layer libraries emulating older functionality, while removing the old cruft and hardwired stuff.

Bimal: who does the libraries? ISVs? David: ARB members could contribute to the reference implementation and own it. Dale: we came to similar conclusions. There should be backwards compatibility, but maybe it's a layer on top. This will get some flak from people complaining about layers being slow, though.

Bimal: getting something drawn in OpenGL is simple; concerned about requiring developers to write pipeline programs just to draw a triangle. David/Eric: shouldn't require this, just e.g. #include the right header.

Dale: part of the goal is being able to distinguish between core 2.0 and older layered stuff. Specmanship issue to write this. Randi: sensitivity to ISVs and the length of time it takes for complex apps to migrate. Even in the case of OpenGL 1.0, it took a long time for apps to migrate from IrisGL.

Jon: we could use this opportunity to finesse the OPENGL32.DLL issue - continue providing the old library for older apps, a new vendor-neutral, open source DLL for new apps.

Randi's technical discussion continued from slide 13 of the 3Dlabs presentation.

Discussion

John Schimpf - two categories of discussion. Should we do this? Is this the right thing to do?

Bimal - by the time we get this done, it's next year, and even more momentum is lost. Does the embedded space need a solution without the advanced 2.0 features? Can OpenGL 2.0 get critical mass of ISVs?

JSch - ISVs want two competing APIs. They question the viability of OpenGL due to perception of lack of forward progress; don't see a real direction from the ARB. There are both technical and market reasons to take a decisive step in this direction, but the window of opportunity is getting smaller. There are still multiple platforms that matter, and compatibility matters.

Bimal - making progress on vertex shaders, in light of NVIDIA's new position, would help as a stopgap. It's hard to get standards bodies to write specs; really needs to be driven by a single group. Can 3Dlabs take the leadership role?

JSch - 3Dlabs is committed to proceed with this; but we can't do it without support from the other ARB participants. Reasons for introducing it in a half-baked for, now, are to unify thinking early, before committing to specific details. Comments from ISVs are uniform: they want OpenGL to continue to succeed and innovate; they want programmability (even though it may make their lives more difficult). Many care primarily about Windows, but they care about other platforms too. ISVs are pragmatic; if they can't count on OpenGL, they'll find other alternatives, but they'd prefer to stay with OpenGL.

Jon suggested conducting development in a more open process, perhaps outside the ARB context, partly for the benefits of OSS development and partly to address perceptual issues about the ARB. However, SGI supports the general direction being proposed. JSch says his feedback from ISVs indicates they're confident the ARB members are smart people who can come up with a reasonable language.

Randi would probably lead the 3Dlabs efforts; they're already implementing parts of it, particularly stuff deriving from OpenML discussions.

JSch notes that many people need to be involved. There are specific companies (3Dlabs, ATI, NVIDIA) that are most important in terms of needing these features near-term for their hardware, though.

AllenG believes we need to be careful, and aware of the lessons learned from OpenGL 1.0. But that we can do this, and it's important.

Michael notes we'll have to overcome the SDK issue - distributing new libraries and getting developers to use them will be hard. Not sure a "2.0" is preferable to a "1.4".

Wide agreement that the current assembler-level vertex/pixel shader lockup can and probably should be solved first. Neal says that 2.0 is analogous to the upcoming DX 9, with higher level features. Graham wants to go straight to the higher level programmability, rather than keep a legacy interim solution around forever. AllenG says it may be easier to implement programmability in the context of cleaned up, stripped down OpenGL 2.0.

JSch: what are the goals and priorities? Michael: biggest problem is the fragmentation of the API. Marketing advantage of "2.0" takes a back seat to solving today's problem. Bimal: embedded subsets are an important, unrelated "2.0" area. JSch: agreement that there are important short-term tasks as a first step, but we need to step back a bit further and determine if we're ready to move beyond OpenGL 1.4. If there's agreement, then we can start the conversation.

Neil: difficult to find embedded apps that need programmability today; don't see this space being a driver. Graham: first few years of the embedded market will be e.g. porting PlayStation 1 games, needing only a subset of today's OpenGL. Neil: ISVs have figured out programmability just enough to know that it's important, while not knowing what to do with it. They're making platform decisions this year, and can be influenced by a clear roadmap.

JSch: is there a sense to move forward? Separated between short and long-term tasks? Jon: is there logical segmentation in the 3Dlabs proposal? E.g. can we separate out memory management, timing, and programmability? David: embedded stuff is not important compared to having a unified programming model in the 3-6 month timeframe; ISVs are being lost now.

(Considerable discussion about doing short-term assembler-level extensions vs. long-term high-level language extensions followed, and wasn't captured in detail in these minutes).

Bimal: Devil's Advocacy question: why do we want OpenGL to survive? If IHVs can't articulate this and drive progress, it won't survive.

Action: John Stauffer volunteered Apple to lead the short-term unification work. 3Dlabs volunteered to lead the long-term 2.0 work.

The first short-term question is ATI and NVIDIA agreeing on procedural vs. string interfaces. John notes that having a vertex object interface for high-bandwidth data transmission to the GPU is important; would the ATI_vertex_object extension work? Finally, a high-bandwidth path for pixel data is important; Apple will be introducting this feature soon, but would like it more widely standardized.

We don't know yet if there are roadblocks (either legal or technical) to unification of fragment shaders. Vertex programming functionality is well understood, fragment programming less so, and a low-level model is harder to arrive at.

John Stauffer will also lead an effort to understand fragment shader unification; this is more challenging than vertex shaders.

ARB_texture_mirror_repeat

Bimal wants to upgrade the extension spec to be written against OpenGL 1.3. This is a minor language change, just rearranging some text. We'll call an email vote ASAP.

Scissor Application to WGL_ARB_buffer_region

Dale got ISV mail (forwarded by Mark Kilgard) from Travis Heppe at TechSoft America, regarding implementation differences as to whether scissor is applied to the restore operation. He cited a variety of cases and different behaviors. The original spec doesn't seem to have any reason for scissoring to apply; Dale proposed changing the spec to state this. NVIDIA is OK with this. He'll circulate a modified spec proposal for voting.

Conformance

1.3 conformance problem - the current shell.c doesn't run 1.1/1.2 tests on a "1.3" GL_VERSION string. Action: Jon will circulate a patch to shell.c. Brian has written proposed 1.3 tests for everything except WGL extensions, multisampling, and texture compression.

Crossbar Language in the 1.3 Spec

On page 152, and also in the ARB_texture_env_combine spec, there's some language referring to the ARB_texture_env_crossbar extension (referencing TEXTUREn, textures from other texture units) which should be removed, since the crossbar extension didn't make it into 1.3. Bimal will circulate a proposed patch to the participants' list.

GLX 1.4 Spec Draft

The proposed GLX 1.4 specification was reviewed; changes are small and just a couple of typos were observed. Action: Jon will update the spec and recirculate; vote will be called soon.

September 12, 2001

New Auxiliary Members

Renewal proposals were received from all of the current Auxiliary members (ATI, NVIDIA, Sun). The attending Permanent members (3Dlabs, SGI, E&S, Intel, HP, and IBM) voted unanimously in favor of each application (6 Yes, 0 abstain, 0 No). ATI, NVIDIA, and Sun are all renewed as Auxiliary members for another year.

The Auxiliary members are also all interested in Permanent membership. This requires a unanimous vote of all Permanent members, and will be conducted by email.

Next ARB Meeting

The next meeting date is set for Tue-Wed, December 11-12, 2001. Apple is tentatively willing to host again, if needed - the food budget was a bit of a problem for them this time. ATI will also look into hosting. Matrox is more interested in hosting Q1/2 2002 meetings.

Additional Shading Discussion

Some miscellaneous discussion followed the nominal end of meeting:

Vertex shader - what should the flavor of interface be? Procedural, string, or HLL? Apple is inclined towards the procedural low-level approach. 3Dlabs looked at a "series of strings" approach for the HLL interface, to allow combining different elements. An external loader accepting the NVIDIA string format, and perhaps DX file formats as well, would help developers.

Abstraction of registers is important to support a single extension across multiple hardware instruction sets. A minimum level of functionality is needed; e.g. 3Dlabs' implicit multipass support may be too much for the near term.

Should there be required minimum supported complexities, to establish a baseline of useful functionality? ATI extension has a required minimum of 32 instructions, though their current hardware supports more. How should we expose and abstract registers?

The historical OpenGL model is for a base extension reflecting shared capabilities with vendor extensions layered on top for additional features. This may be the wrong model for programmable shading; a validation model for the input language could be more suitable, and reduce the number of vendor extensions required.

The Stanford shading language is an example of a competing technology to the 3Dlabs proposal, layered above OpenGL. What Stanford couldn't do was change the underlying OpenGL structure to support their language. 3Dlabs feels that if hardware independence is needed, changing the underlying structure is appropriate.

They also feel that fragment shaders will soon evolve to truly programmable capabilities, just as vertex shaders have. So they want to tie them together and support both types of functionality.

Pixel path shaders are a potentially attractive new capability for Graham, but 3Dlabs is more inclined to only program pack/unpack operations and do traditional pixel path operations in the fragment shader.

Thanks to Apple for hosting this meeting!