Summary of Discussion Topics

• Intro / SIGGRAPH BOF / Next ARB Meeting
• ARB_vertex_program
• OpenGL 1.4 spec review
• "OpenGL 2.0" Status Update
• ARB_fragment_program
• ARB_vertex_program (cont.)
• New and Continuing ARB Members
• Khronos Update
• Shader Metaprogramming
• "Cg" Q&A
• New Working Groups

June 18, 2002

Introductions

Jon reminded everyone that the OpenGL BOF / 10th Anniversary Celebration at SIGGRAPH will be Wednesday, 4-6 PM in the Mariott, and noted that there were still slots available for short, focused technical presentations - talk to him if interested.

Next ARB Meeting

We accepted Dell's offer to host in Austin in September. Tentative dates are September 17-18th, subject to discussion on the participants' list. Normally we'd hold the meeting a week earlier, but some companies don't wish to have people travelling on the anniversary of 9/11.

ARB_vertex_program

Microsoft believes they have patent rights relating to the ARB_vertex_program extension. They did not contribute to the extension, but are trying to be upfront about it. They're offering to license their IP under reasonable and nondiscriminatory terms; will license rights to the extent necessary, provided a reciprocal license is granted to MS. Granted on 1:1 basis for OpenGL 1.3, 1.4, and earlier versions. Contact Dave Aronson for more specifics. Suzy asked Dave to circulate his statement to the participants' list.

Pat led technical discussion. Bob has two proposed changes:

• Introducing "light product bindings". Would like "scene ambient and emissive" bindings. Would be for front/back materials of emissive and ambient colors, to reduce lighting calculations. Should not be controversial.
• Adding 3-component cross product (XPD) instruction. What happens to 4th component? Working group resolution that 4th component is disabled for writes, which can be expensive. Could produce 0 instead, but there are some difficulties in order-of-operations, rounding, etc. that might make the result non-zero. Could make it undefined (Bob's suggestions).

Bimal notes allowing undefined behavior is short-term gain for long-term pain. But there are other undefined behaviors in the spec already.

Bimal brought up the aliasing solution. Ugly either way, but what's in the spec now is probably the best choice.

GLX protocol needs definition, but this shouldn't bar voting on the core spec.

IBM thinks it's premature to vote on this without seeing the MS license terms. NVIDIA wants to vote it in at this meeting. SGI thinks if we can't deal with IP claims, we might as well all go home. Microsoft suggests that other bodies have licensing terms that are more effective in a corporate sense, and we should look at adopting some of those terms. Dell doesn't think this is relevant to the current ARB_vertex_program discussion. Kurt asked Dave Aronson for a ranked list of "preferred" standards bodies. Intel is relatively comfortable with a 1:1 crosslicense with Microsoft, but not with competitors in the HW space for future extensions. Dave could not discuss whether or not their claims would read on e.g. a pure SW, CPU-only implementation, because they involve pending patents.

We'll wait until Apple joins us, then vote.

ARB_vertex_program integration into 1.4

Technical issue - 3Dlabs doesn't find 1.4 all that compelling without vertex programming, but finds the vec4 architecture underlying ARB_vertex_program too hardware-specific to include into 1.4 except as an optional subset. Seems short-sighted to incorporate into the standard when this assembler-level functionality is likely to be quickly superseded by new silicon generations; but it serves a tactical purpose, to take advantage of current market conditions. It's not the right assembly language for 3Dlabs' hardware, but they would implement and support it.

Could approve it as an optional subset of 1.4, like ARB_imaging was an optional subset of 1.2.

Legal issues (unknown licensing terms, 1:1 licensing) may make it more difficult to approve as part of the core 1.4 spec than as an extension. NVIDIA disagrees, thinks many IHVs must support equivalent functionality anyway for DX.

Kurt thinks developers don't really like extensions, so we need to get programmability into the core spec for wide ISV adoption. Randi thinks high-level languages are more important.

Bill Licea-Kane notes that ATI's reading of the bylaws does allow the ARB to approve an ARB extension with known IP claims against it, but that if the IP is offered with alternative licensing, it may not become part of core OpenGL.

OpenGL 1.4 spec review

Bimal noted some additional secondary_color corrections:

• p. 43: add "used in color, secondary color"
• p. 47: replace "eye coordinate" with "raster distance" and remove period after "current color index".
• p. 48: add "to have the same colors".
• p. 73: add secondary color to last paragraph.
• p. 107: change "taken from ... raster depth" to "raster distance" in sentence prior to 3.6.5.

Major issue: Intel would like to see shadow mapping deferred to 1.5, unless there's a SW/HW performance query. Dell doesn't feel strongly, but thinks a robust query mechanism ("isfast") would be useful - discussion to take place seperate from 1.4.

Second issue: Intel noted that we incorporated EXT_texture_lod_bias rather than ARB_texture_lod_bias, and wants the latter. Nick will forward the latter spec.

Third issue: restoration of Matt's proposed secondary_color change. Also, we should indeed specify secondary color A produced by lighting as 1 (on p. 52).

Straw polls on 1.4 with and without various features:

• As currently proposed (all features): 3 Yes, 8 No
• With ARB_shadow, without ARB_vertex_program: 10 Yes, 1 No.
• Without ARB_shadow, with ARB_vertex_program: 5 Yes, 1 Abstain, 5 No.
• Without ARB_shadow, without ARB_vertex_program: 10 Yes, 1 No.

Numerous suggestions on revising bylaws to better deal with IP issues. We'll setup a bylaws working group. Would like to clarify status of (1) ARB extensions (2) optional subsets of a core spec revision WRT IP issues.

Jon will make proposed revisions to the 1.4 spec and call an email vote w/o vertex programming.

Future directions discussion / statement of purpose - Dell would like to see a joint statement regarding commitment to OpenGL 2.0. Should be as detailed as can be done in a timely manner, indicating our direction to the industry. Most attendees supportive of this.

"OpenGL 2.0" Status Update

Randi provided an update on the 3Dlabs work, including a live demo of brick and noise procedural fragment shaders, and an animated noise texture using offsets.

Randi asked about setting up a weekly working group to proceed with GL2 extensions and resolve open issues. Interested people: Jon Leech, Bill Licea-Kane, Brandon Fliflet, Jack Middleton, Evan Hart, Rich Johnson, Dave Zenz. Bill is willing to chair the group.

NVIDIA is very interested in extending OpenGL to support programmability; they see it as a continuation of the ARB_vertex_program work.

Non-shading-language stuff is less controversial and potentially could be worked on separately. 3Dlabs encourages interested people to proceed with that, but sees the shading effort as highest priority. Little interest in working on the async spec, but Bimal pointed out that 3Dlabs had not walked through the various non-shading areas to give people a basis for deciding.

Low- vs. high-level direction should be discussed/clarified soon.

Evan asked if the working group should be focused on long or short-term goals. Randi's initial suggestion was directed more at long-term consensus leading in part to short-term deliverables; nice to have both! And important to communicate what consensus exists.

Kurt suggests concentrating on process: revving OpenGL much more frequently, and making that known to developers. 2.0 stuff suggests a different, slower process.

Randi notes that "2.0" has generated some excitement in the market. Should we stop saying it? Kurt: 2.0 would be when a sufficiently big "bucket of stuff" has gone into OpenGL.

Jon noted that "2.0" could also mean breaking the ABI, e.g. by relying on programmability to replace current fixed functionality. That's less of a 3Dlabs direction now - still on the table, but compatibility is very important.

Dale's sense was that "2.0" implied that the fixed functionality would still always be there, but no longer necessarily the fast path.

Randi notes proposed "GL2" affix to indicate "more important than EXT, but not ARB-blessed yet". May enable moving faster than the ARB voting process.

NVIDIA wants to participate in a group that evaulates the existing extension set for suitability, as well as new proposals.

ARB_fragment_program

Benj Lipchak led this discussion. Quite a few companies interested. Benj will setup a working group.

Microsoft does believe they have IP claims against fragment shaders, too.

Pat asked if this was intended to be implementable on current devices. No - ATI, at least, doesn't plan to support ARB_fragment_program on old hardware (although current implementation-dependent limits in the ARB spec are drawn from their current hardware).

Evan pointed out the difficulty of supporting different types of architectures with a single assembly language. Still want a spec with legs.

Benj thinks it's doable within a few months; looks a lot like ARB_vertex_program and hardware is probably broadly similar in capabilities.

Pat recapped vertex program framework:

• 4-component vector-based language.
• Apps can define a program string including local parameters.
• Program parameters (like "uniform" parameters).
• Most take 1-3 vectors and/or scalars and produce a vector result which can be write-masked.
• Swizzle operations.
• Basic math operations.
• Comparisons producing true/false masks.
• Data passed through a vertex program is conceptually different from the standard GL pipeline. No real distinction between GL parameters, e.g. can use them for nonstandard purposes.
• Ultimately outputs a coordinate and associated data.
• One vertex in, one vertex out.
• Almost entirely replaces standard GL vertex processing model, aside from vertex specification and primitive assembly.

Original NVIDIA notion was that all parameters were completely generic. GL attributes would map in a well-defined fashion. Other architectures may have a fixed register file + generic registers. Final resolution was that this mapping could occur, but was not required (e.g. setting a generic attribute might leave the corresponding conventional attribute undefined). Allowed exposing more registers.

Parameters include program environment parameters (global - only kind in NV_vertex_program); constant in the program text; local parameters to the program object; state bindings from GL state; temporary registers; address registry for array accesses; transformed vertex position and associated data from the app.

The fragment program extension is just like this, except it replaces the texture environment, texture application, and color sum stages. Program inputs are interpolated colors and texture coordinates (screen space coordinates not available in current spec) and local, global, and GL state parameters, including lighting parameters. Can add more if needed. Aliasing (reusing variables) as in ARB_vertex_program. Output is primary color and (possibly) depth.

Texture lookups are a new kind of instruction (texture fetch).

Fragment operations are local, e.g. can't do convolutions in the obvious way.

Blending and framebuffer access not available, unlike GL2.

ARB_vertex_program (cont.)

Kurt asked what we could do to make developers confident that ARB_vertex_program is a stable, widely available part of OpenGL?

• Could just vote on the ARB extension spec as discussed earlier.
• Had planned for vertex programming to be part of the 1.4 core. Ran into an IP issue. Spectrum of possibilities:
  • ARB_vertex_program distinct from 1.4
  • ...
  • Optional extension to 1.4
  • ...
  • Everything in 1.4

Let's examine possibilities before voting.

What's less satisfying about a separate extension?

• Has ARB affix, makes it look like there will be one more rev before it's "final".
• Have made a certain amount of PR about packaging programmability in 1.4; would cause a marketing issue.

Ideas:

• Make ARB_vertex_program optional functionality, like ARB_imaging. People may still be reluctant to vote because of IP concerns.
• Pull out program management infrastructure and put just that in 1.4, somewhat like splitting the generic texture compression framework from S3TC and other specific compressed formats. Kurt was against this but would support it under these circumstances.
• Invent a new category of extension that's "related to a release" rather than an "ARB extension". By that sleight of hand, can claim 1.4 includes programmability.
• Just approve the extension and leave off the affixes :-)

Program Management framework is potentially usable by GL2 as well. Some policy differenes like:

• Whether app or driver manages the program namespace.
• Aliasing.
• How user-defined vertex array attributes are passed.

But there is still a high degree of overlap.

Bill asked about Microsoft's IP position on just the program management framework; Dave was unable to comment at this point.

Kurt thinks correct process is to vote now on ARB_vertex_program as it stands, then work out the methodology in the run up to 1.4.

More straw polls (Dave Zenz had to leave; Jon voted Dell's proxy by prior arrangement)

• ARB_vertex_program extension, with known IP claim: 10 Yes, 1 No
• ARB_vertex_program as an optional subset of 1.4: 6 Yes, 2 Probably Yes, 3 No.

Suzy asked Microsoft to figure out their IP claims, if any, against just the program management stuff. Most of this can be seen in version 21 of the working group spec, or section 2.14 of the version 28 spec, possibly excluding the Program*Parameter calls.

VOTE on ARB_vertex_program; PASSES, 10 Yes / 0 Abstain / 1 No.

People should take a harder look at their legal position on concepts like "optional subset" and decide what level of comfort we have moving parts of ARB_vertex_program into 1.4. ARB_vertex_program would probably pass as an optional part of 1.4, based on another straw poll

New and Continuing ARB Members

Meeting in closed session, the Permanent ARB members voted Matrox in as an auxiliary ARB Member, and renewed Apple's Auxiliary membership for another year.

June 19, 2002

Khronos Update

Neil Trevett provided a Khronos "Embedded" OpenGL update.

Kurt reiterated his concern about positioning "OpenGL 2.0" as something different and incompatible with OpenGL 1.x. Programmability and fixed-function both need to work in the same app, though not at the same moment in time. Considerable discussion about the importance of backwards compatibility and ways to evolve the spec.

"Shader Metaprogramming"

Michael McCool from U. Waterloo joined the meeting. Randi recapped his "2.0" status update from yesterday. Michael brought some copies of his "Shader Metaprogramming" paper from the upcoming HW workshop conference, and presented this research.

NVIDIA wanted to discuss their goals with Cg (although they are not offering Cg to the ARB)

Principal goals are to enable apps to use all the features of NVIDIA hardware, do rapid prototyping, and make efficient use of the underlying architecture. "Profiles" allow compiler to control what it accepts as valid programs.

Want to allow developing apps start to finish with one toolset, rather than being DX- or OpenGL-specific. Format can be read in by authoring tools, manipulated, written out to an "fx" or "cgfx" file (shader + "render state" + multiple representations of how to implement that effect, e.g. Cg, card-specific techniques, etc.)

Cg browser supports multiple shaders.

Cg is a dataflow language - defined inputs and outputs, program executes on a stream of those inputs and produces a stream of those outputs. Introduces "connectors", data structures representing inputs and outputs. Targets DX8 vertex/pixel shaders, NV_vertex_program, ARB_vertex_program. Currently doesn't support pixel/fragment abilities in OpenGL, but will support ARB_fragment_program as well as NVIDIA extensions (register_combiners, texture_shader) ASAP.

They've been working on Cg for about a year; this is why they've been pushing for the right building blocks in OpenGL to support higher level languages.

Cgfx format can annotate parameters - e.g. let tools know that "hair color" is indeed a color, "hair thickness" a scalar parameter, etc. Content creation apps can tweak these files. NVIDIA is working with NewTek, Alias|Wavefront, Discreet, SoftImage, etc. on this.

Cg is single-pass only, unlike e.g. the Stanford shading language. Apps mostly prefer having their own scene graphs, data management, etc. and not having to multipass data. Hope is that hardware will become capable enough that incompatibilities largely disappear due to much larger limits on each platform.

Goal is that there not need to be multiple, very similar shading languages for different underlying APIs and platforms. Thus Cg is syntactially and semantically compatible with HLSL in DX9; may not be true forever, but it is today. This is a constraint on evolving the language, had to get feedback from developers and work with Microsoft.

However, not trying to solve the same problem as batch-mode shading languages like Renderman, which are complete rendering systems. Cg doesn't work behind developers' backs, they can understand just what's happening under the covers.

NVIDIA will provide frontend as open source under a BSD-like license; backend will remain proprietary, but other vendors can provide their own backends. Other IHVs should talk to NVIDIA about how best to support this. Not making any IP or patent claims on Cg. Standard library is implemented differently on different backends.

Dave asked that, since developers have mostly chosen their low-level API, what's the advantage of having a single shading language across DX and OpenGL? Makes it easier for crossplatform developers - Cg allows portability of the "artwork", as well as the rendering engine. Shaders are a separate asset from the app itself. Workflow will create shaders with one set of apps and use them in another.

Compatibility with hardware deployed today was also a key design goal - demos are running on a GeForce4 MX laptop.

Bimal asked about NVIDIA's interest in incorporating a high-level language directly into OpenGL, ala 3Dlabs' design. Nick says what's important is solving developers' problems, and they want a single shading language. If the market wants an integrated language, NVIDIA will support that too - but they don't think that's what developers want, and they're less excited about it. What's critical to making Cg work is having the right low-level interfaces to the underlying API, and that's where they want to concentrate their efforts.

Discussion followed on the relative effort the ARB should put into low and high level language working groups. ARB_vertex_program now represents nearly 2 year old technology; low level interfaces need to look at branching, looping, etc. constructs.

Cg backend receives a partially optimized DAG representation of the shader. Must figure out how to map onto what the backend supports.

Compatibility with DX is very important, but they're willing to weigh advantages of changes vs. cost. Cg and the proposed "OpenGL 2.0" language are similar but not identical; both look like C, and both target multiple underlying execution units. Interfaces, communication between nodes, and accessing state across nodes are different. It's very late, but not too late to contemplate merging the two languages.

The Cg language itself is very general and shouldn't need to be updated in the future. Code can be conditionally included depending on the target profile.

Working Groups

Currently expected groups include:

• ARB_fragment_program - based on the ATI spec, targeted for a vote by the next meeting/.
• Vertex program group continues - targeted at flow of control issues.
• High level shading language ("2.0") - what stands in the way of proposed GL2/ARB extensions? How can the Cg and 3Dlabs proposals be put together?
• Bylaws working group - how might we modify the bylaws to ease dealing with IP issues like those around vertex programming?

3Dlabs will be talking about their "2.0" proposals in a SIGGRAPH course and various presentations. They've received some updates on messaging here and will send presentations out for more comments ~1 week before SIGGRAPH.

Merci à Matrox d'avoir accueilli cette réunion!