Summary of Discussion Topics

• ARB_vertex_program
  • IP Issues
  • Technical Discussion
• Next ARB Meeting
• OpenGL 1.4 Plans
• ARB_vertex_program (cont.)
• OpenGL 2.0 Status Update / SIGGRAPH Plans

March 5, 2002

ARB_vertex_program

IP Issues

NVIDIA has signed an ARB Contributor License for the NV_vertex_program extension; copies were distributed to interested parties. For questions, contact Stephen Pettigrew, spettigrew 'at' nvidia.com

Microsoft wanted to alleviate concerns about their statement last week regarding possible claims on vertex program IP. Dave Aronson apologized for the perception that they aren't acting in good faith. They are trying to follow ARB regulations about stating IP as much as possible. When a vote was imminent, they reviewed and felt that they had patents or patents pending covering vertex programming. They do plan on coming up with licensing terms, and have set a hard deadline for themselves of 2 weeks before the June ARB meeting.

Some discussion on the ARB structure and difficulty in dealing with IP issues followed. Suzy wants to start by identifying the scope of the problem and finding out what different companies concerns are.

Technical Discussion

Bob Beretta recapped recent activity in the working group and led the following discussion. He noted that Allen Akin had led discussion to identify common points and points of divergence, and Pat Brown had worked a lot to document all of NVIDIA's open issues.

Several classes of differences were identified:

• Misunderstandings (about 1/3 of issues), which have been dealt with.
• Areas where agreement was reached by Pat, Bob, and Allen, which are assumed to be OK with other working group members.
• Remaining points of contention - areas where Apple agrees with NVIDIA but hasn't run the changes by everyone else (about 5 issues).
• Remaining points of contention - areas where Apple and NVIDIA don't agree (about 5 issues).

The last two classes roughly parallel the document Allen sent out last week. Bob wants to enumerate the remaining issues, allow others to add to them, and try to work through them here.

Bimal asked what the starting point was - NVIDIA's or Apple's spec? Both have been evolving to address open issues. NVIDIA wants to start from the existing spec because NV_vertex_program it's known to work.

Open issues:

1. High Level Language - Are there "compiler sugar" features not essential to functionality, e.g. function macros, aliases (const two = 2), variable scoping blocks, arrays other than parameter arrays (with fixed indices - can't be indexed at runtime)?

   Current status: NVIDIA doesn't want these features; Apple is OK with pulling them out if it doesn't architecturally preclude them in a layered extension.

   Pat: An OPTION mechanism exists in both proposed specs, e.g. NVIDIA's "position invariance" option to guarantee identical coordinates when multipassing with one pass in vertex programs and one pass in the fixed-function pipeline, by preventing vertex programs from writing the output coordinate from the program.

   Consensus: will move HLL features into a separate extension.

2. Three Letter Opcodes (MAD vs. MULTADD) - Should opcodes be limited to three letters or not?

   Current status: Apple is OK with this, doesn't really care - up to Pat to make a case. Opcode space can get packed quickly in the future.

   Pat: Not a hard and fast requirement; compatibility concern for existing programs, and want to keep programs as small as possible. In the future opcodes could get longer.

   Consensus: keep it terse, no 3-letter requirement in the future.

3. Direct Exposure of Vertex Attribute Registers (including Material Properties)

   In contrast to a more abstract mapping. Is there vertex attrib aliasing? Is there a concept of an exact number of attributes, or does OpenGL state map onto the vertex program?

   Current status (also applies to following issues 4 and 5): Apple thinks these are unnecessary exposure of internal implementation. Current Apple proposal allows all these techniques to be done within the implementation. For example, the spec doesn't hardwire GL vertex state to specific vertex registers.

   Pat: ca. 13 GL attributes, 10 materials. Gfx hardware isn't going to build a register file big enough for all of this, so some sort of as-if behavior is needed. NV_vertex_program hardwires GL attributes to specific registers, which allows referring to them by name while also allowing writing very generic vertex programs. Real concern with the Apple model is the overhead of switching the mappings and the undefined behavior that may ensue. Whenever a program binding is changed under the Apple model, the mapping may also change, requiring e.g. some dispatch table switching or second-level dispatch.

   NVIDIA doesn't support ARB_vertex_blend; their current attribute mapping would only allow 4 independent weights. Also doesn't allow material changes inside Begin/End blocks, even for vertex programs. Apps could load generic vertex attributes at the per-vertex level, however.

   Apple and NVIDIA have discussed many implementation options which could allow efficient mappings.

   Consensus: UNRESOLVED.

4. Specifying Parameter Allocation Mechanism

   Should mapping of the {GL state,GL context parameters,private parameters (locals)} -> 96 fixed hardware parameters be left as an implementation detail?

   Current status: see issue 3.

   Discussion: Apple is convinced the mapping can be done under the covers, allowing NVIDIA's current implementation. NVIDIA is concerned that allowing flexibility in mapping will enable implmentation divergences and problems for developers. NVIDIA would like to keep the global state in the register file.

   After much discussion, NVIDIA dropped their objections to the Apple approach.

   Consensus: no specification.

   At this point, Kurt noted that he, Pat, and Nick had been talking offline and were prepared to mostly give in to Apple's design choices, rather than end up at an ugly compromise between the simple, direct NV_vertex_program architecture and the elegant, fullblown Apple architecture.

5. Coherent vs. Non-Coherent State Bindings

   Should GL state changed via the API be visible to vertex programs without an explicit synchronization point?

   Current status: see issue 3.

   Discussion: Apple prefers coherent state binding. NVIDIA doesn't have any binding at all, at present. ATI felt it was easier to introduce vertex programming incrementally with the coherent model.

   Consensus: Coherent bindings.

6. Clipping Planes -

   Should they be supported, and how?

   Current status: NVIDIA has a proposal for the future that no current hardware can do. Current proposal is that clip plane is transformed by the inverse transpose of the projection matrix. If the projection is singular, the result is undefined.

   Much discussion about the implementability of NVIDIA's proposal followed before returning to the core issue of whether user clip planes operate when vertex programs are in use.

   This remains an open issue; too many possiblities, and the usage scenarios in which it's relevant have not been well identified yet. The section of Pat's latest spec enumerates four options in the clip plane section.

   Consensus: UNRESOLVED.

7. Relative Addressing Syntax

   Should there be an explicit ARL-like instruction, or syntax like Array[variable]?

   	    ARL A0.x myTemp.x
   	    MOV myVar myParam[A0.x+offset]
   	    

   vs.

   	    MOV myVar myParam[myTemp.x+offset]
   	    

   Ended up preferring ARL, but with a remaining open question about the maximum range of constant integer offsets allowed to be added to indices.

   Consensus: Use ARL, determine offset limits.

8. Vertex Attribute Data Types

   Should the full OpenGL range of data types be supported, or a narrower set? Vertex attributes have unknown type. Hardware may support a smaller range internally, but this can be hidden.

   Consensus (details TBD): for vertex array forms, support all 14 types with parameterized size. For immediate mode, take some subset of the possible types, while expanding entry points to incorporate the data size rather than passing it as a parameter. No plural forms for immediate mode.

9. Incremental Program Loads

   Should there be a single statement to load entire programs, or should programs be loadable one part at a time and assembled inside the GL? Should the program string be queryable?

   Apple has evolved to wanting a single LoadProgram entry point. Nobody else objected to this.

   Apple also wanted to make the program string unqueryable. Kurt opined that as programs get much larger, it will probably be desirable to incrementally edit them. Opinions were split, various analogies to textures and display lists abounded. Nick strongly desired to have the program queryable.

   Consensus: Single load entry point, queryable program string.

10. Language Version Specification

    How to identify changes for future extensions?

    NV_vertex_program includes a token at the start of the text stream, and the OPTION mechanism, as ways of specifying the version. Apple proposal just uses an option. Apple proposes the second in order to support language types which are so different that they aren't text (encrypted data, binary or tokenized data, bytecodes, etc.)

    Consensus: After discussion, agreed that we need both version/type string (magic number "!!ARBVP1.0" or the like, including a version), the option mechanism, and an extra parameter in the Load call allowing specifying arbitrary data.

11. Compound Instructions

    There are still issues with the base instruction set.

    Consensus: no restriction on using the same register multiple times in one instruction. Working group will vote on specific instructions that may go in or out (ZERO, CLAMP, CROSS, partial vs. full precision exp/log, etc.)

12. Undefined Vertex Program Outputs

    NV_vertex_program defines behavior for outputs not set by the vertex program.

    Apple proposal adds language to EXT_secondary_color specifying vertex program behavior WRT color sum.

13. Temporary Initialization

    Initial values are undefined.

    Consensus: OK.

Issues that have previously been agreed on (from Pat):

• NVIDIA has agreed to allow access to OpenGL state from the vertex program.
• The spec defines a set of limits within which a vertex program is guaranteed to execute in some fashion, rather than hardwired limits corresponding to and guaranteeing hardware execution. EMULATED vs. OPTIMIZED distinction has been dropped; spec does not expose HW vs. SW modes.
• Counting rules for "does a program load or not" should be very straightforward, rather than depending on a compiler or optimizer. If a program oversubscribes available resources, it cannot and should not depend on the GL implementation solving the register allocation problem.
• Limiting ranges for some types of parameters, e.g. exponents. Agreed to add high-precision log2 and exp instructions and ATI's extended swizzle instruction.

March 6, 2002

Next ARB Meeting

Matrox will host the next ARB meeting in Montreal; dates will probably be June 11-12. Exact dates to be settled soon.

OpenGL 1.4 Plans

With likelihood of an ARB vertex program extension being completed soon, OpenGL 1.4 becomes relevant, and can be completed technically shortly after the working group approves the ARB extension. NVIDIA will call another straw poll by email on the extensions Matt Craighead proposed at the December meeting.

Vertex Program Discussion (cont.)

Choice of vertex program spec - Bob comments that many changes will have to made to either spec based on feedback and changes to date. NVIDIA believes they've addressed all the open issues and their spec is closer to the working NV_vertex_program, as well as easier to read for developers.

Apple has open sourced their parser and emulator - it emulates the entire API stack and sits on top of GLUT. Limited by not being able to implement all the state bindings due to the layering on OpenGL instead of being inside the driver. Source distributed to ATI and will be further distributed in the near future. Under the same BSD-like license as Apple's sample code.

Bob notes that having the ARB_pipeline_program extension as part of 1.4 at least lays groundwork for fragment programs, though we can't get fragment programming done in the 1.4 timeframe.

Nick will call a straw poll via email next Monday to choose a spec, asking for votes by Wednesday.

Returning to open issue 3 (Direct Exposure of Vertex Attribute Registers), NVIDIA is worried about the difficulty of supporting both their existing extension and the ARB version, based on knowledge of which version of the spec is being used. Bob noted that the entry point are differently named and thus distinguishable, if need be. General consensus was that material properties should be bound by the user program, not implicitly.

Once the choice of spec is made, the working group will be reconstituted and provide regular status updates to the opengl-participants' mailing list. Bob has volunteered to continue leading the working group, unless Allen Akin wishes to.

OpenGL 2.0 Status Update / SIGGRAPH Plans

Randi Rost presented a status update on 3Dlabs' work. Their proposed schedule has initial GL2 extensions by SIGGRAPH 2002, a full OpenGL 2.0 extension and spec at SIGGRAPH 2003.

Kurt is concerned about introducing a new GL2 namespace with a greater feeling of formality / likelihood of inclusion in OpenGL than EXT extensions, without the formal voting baggage of ARB extensions. Doing the new features as extensions is a good idea, but will require a fair amount of trust and comfort by ARB members.

Kurt asked Jon for historical perspective; Jon noted that the vendor/EXT/ARB distinction was largely informal policy, and that having a GL2 namespace for development could help disambiguation of common names (e.g. LoadShader). Jon was comfortable with 3Dlabs managing this new namespace, so long as ATI/NVIDIA/3Dlabs can work together successfully.

OTOH, developers largely don't care about fine distinctions IHVs try to make, like SGIX vs. SGI, or about the entire extension promotion process short of ARB. From that perspective the namespace may not make a big difference.

Randi's OpenGL 2.0 course at SIGGRAPH will update prospective developers. We also want to talk about this extensively at the OpenGL BOF / 10th birthday party, and to get our marketing people working on a joint, formal ARB direction / announcement.

Thanks to Evans and Sutherland for hosting this meeting!