Still some question as to exactly where alpha fade should occur. Bimal advocates not allowing application of alpha fade prior to texture application; either do it right or don't do it at all.

Will add a section on antialiasing application.

Pat notes that the spec says derived point size is clamped to a given range, but does not specify what the range is explicitly. Should rewrite to e.g. "value of POINT_SIZE_MIN_ARB" etc. Also asked if there's any way to know if the implementation actually provides alpha fade behavior.

Michael will rewrite and bring back for a vote later in the meeting.

Pat has two versions. One is a simple rewrite of the SGIS extension, with (s,t,r) coordinate clamping based on the resolution of the texture. An issue was raised with regard to cubic/anisotropic texture filtering; having a spec that behaves properly with regard to such filters is desirable. Alternate spec proposal expresses clamping in terms of where lookup operations are performed. This is a significant rewrite of much of the texture section.

Conformance test proposal is missing from handouts - was sent out with initial opengl-participants proposal. Basically extends texedge.c to check border clamping as well as edge clamping.

Bimal asked whether we want to just approve the functionality written in the old style and upgrade the spec language later, when higher order filtering is actually added by the ARB. Overall feeling this is the better option. Still leaves the question of interaction with higher order filters open - Pat will address in issues. Revised core spec language will be done later.

VOTE: 9Y/0A/0N, PASSES.

Dan notes that Errors section should say TEXTURE_FILTER_CONTROL, not TEXTURE_FILTER_PARAMETER. Change affixes to ARB. Change 'copyright NVIDIA' to 'NVIDIA contact'.

Question as to why minimum value of MAX_TEXTURE_LOD_BIAS is 4. Corresponds to log2 of guaranteed minimum max 3D texture size (16), which is probably why.

Bimal asks whether this should be a texture environment parameter or a texture parameter; the latter is more consistent with existing practice, the former may confuse apps. Straw poll shows 8:5 in favor of making it a TexEnv parameter. Much discussion followed. Michael had the notion of simple image objects with no associated lookup/filtering state. Jon suggested having the bias state in both the texture object and texture environment.

Straw poll showed only one vote in favor of the current form, 2 votes in favor of the texture object form, and many uncertain people. Bill Armstrong thinks there are several reasonable strategies, and we need to work through the issues more; the existing EXT and SGIX extensions can serve in the meantime. Nick wants to speak with Matt Papakipos tonight and get his input.

Brian Paul asked about the need for the MAX_TEXTURE_LOD_BIAS implementation-dependent query, which is not present in the current EXT. Should such a limit exist at all? Should there be separate MIN and MAX values?

Pat points out that GLX protocol encoding spec needs to mention this new enum for TexEnv[fi]{v}.

New spec, apparently more acceptable than ATI spec passed around at last ARB meeting. Parallelizes geometry transform and is then blended to give final vertex.

Some discussion as to whether "vertex unit" is the right name; "unit" is now used to be a piece of hardware, conceptually. Using "modelview" may be preferred.

Discussion on specifying weights individually vs. specifying them in a vector form. NVIDIA likes behavior of automatically summing all weights to 1 when (n-1) weights are specified.

Matrox's indexing behavior (being able to use different matrices on a per-vertex basis) doesn't seem suitable as part of the base ARB extension, though they'll definitely do it separately if needed. Matrox's discussion with ISVs indicates that the indexed behavior is what most people want, however. ATI is willing to ensure the "base" spec accomodates the indexed behavior as a layered extension.

Questions on the usability of the proposed weighted normal computation. ATI observes reasonable behavior except in "degenerate" weighting cases; claims that math is acceptable when differences in matrices are simple rotations. Specifying weights for the normal transform separately (as a future extension) would allow the app more flexibility in how this is handled.

Pat asked whether it's desirable to be able to specify exact zero weights while specifying signed integer weights under the usual OpenGL two's complement conversion rules. Based on feedback from the room, will likely end up allowing both signed and unsigned integer entry points.

Evan summarized differences proposed in discussion so far:

• Change "vertex unit" nomenclature to "modelview".
• Specify "weight environment" with "number of enabled modelview matrices" instead of separate per-matrix enables.
• Change weight specification to a vector call which takes either N or N-1 weights, and auto-sums to 1.0 in the second mode.
• Pull error specification language into a separate Errors section.
• Add changes to GLX specification.
• Allow signed/unsigned integer forms.
• May need some additional Get*s.
• Missing some state from New State section.

Will bring back updated proposal for vote tomorrow.

Very much like the existing EXT_texture_env_combine. Three main changes:

• Addition of SUBTRACT operand.
• Relaxing restriction on the Arg2 operand - previously could just be ALPHA.
• Allowing use of TEXTURE_ARB as an input.

People questioned whether the TEXTURE enumerant was needed when TEXTURE_ARB is supported. Allows backwards compatibility and also allows referencing the current texture easily.

What is desired behavior when using an inconsistent texture / disabled texture unit as input? Undefined or using a white texture, as in the proposed spec? This resulted in a great deal of low-key discussion, along with the topic of whether the number of texture environments and number of texture units should be decoupled.

• Remove texture source capability altogether.
• Allows accesses only to upstream textures.
• Full generality as the extension stands today.

Straw poll showed all voters in favor of full generality (although only about 40% of those present voted).

Second straw poll showed about 40% in favor of decoupling #environments and #units.

Proposed that if a unit references a disabled or inconsistent texture, that unit acts as a passthrough, like ARB_multitexture.

Nick gave a heads-up on an NVIDIA extension proposal. If approved as an ARB extension, NVIDIA would allow everyone to use needed NVIDIA IP to implement the extension. If not approved, they would probably want to keep it proprietary. He handed out a letter satisfying section 7.3 of the Bylaws regarding IP notification. Based on this information, the ARB may or may not wish to consider NVIDIA's extension - continue tomorrow.

Wednesday, June 21

ARB Extensions, cont.

Michael circulated revised spec. Alpha fade multisample behavior is optional.

VOTE: 9Y/0A/0N, PASSES.

Lots of requested changes. Nick tried to think of places where it would make sense to have the state be per-object and couldn't find any; common uses of LOD bias are global at least to a texture unit, if not to the texturing subsystem.

E&S has this parameter with the texture object, and it would burden them to support the TexEnv version. Bill asks that we support biases in both places and add them.

Bimal suggests that making this part of the TexEnv state is confusing, since TexEnv generally deals with texture blending, not texture fetching. Michael states that there should be a different entry point affecting defining fetch state. Considerable discussion ensued. This would be a significant change and will be taken online for further discussion.

Dan wants a min/max bias range query. Nick will add. Will consider online.

Evan revised per yesterday's comments.

Mark Kilgard suggested (offline) that most matrices in multiple units are likely to be simply related, and that a CopyMatrix type of command would be useful. Evan thinks this functionality is more generally useful and should be a separate extension.

Issue with naming conventions. Current spec uses MODELVIEW_ARB enums. MODELVIEW{0,1}_EXT enums already in use by EXT_vertex_weighting, and are not numerically contiguous. General feeling is that reducing ambiguity by using the existing EXT enum values and the MODELVIEW / MODELVIEW0 aliasing is preferable to creating a new contiguous block of enums.

Dan asks whether ActiveMatrixARB indirection would be a reasonable alternative. Not much interest in this.

Mark Kilgard also pointed out that automatic sum-to-1 weight mode gets inefficient as the number of weights climbs. Also that RESCALE_NORMAL should be applied separately prior to weighting, NORMALIZE after. Much discussion as to desired / "right" behavior. Nick volunteers NVIDIA to work through the math and send it out by mail. Pat's competing proposal is that normalization behavior only occurs after the weighted sum. We will conduct an email discussion and vote, hopefully quickly.

Several minor semantic nits pointed out; Evan will revise. Summary of discussion:

• Examine normalization math.
• Error for weights more than MAX_UNITS should be dropped, just first N assigned.
• Will use existing MODELVIEW{0,1}_EXT enum values and add 30 more.

Discussion by Rob Glidden - BGL launched by (mostly) hardware companies interested in the interactive settop space. Very different than PC market space. Buyers are network operators (e.g. cable companies) who spec the boxes they want. Some standards exist; more proprietary than PCs. Leader (OpenTV) has ~8M units. Marketing is growing rapidly, but doesn't evolve in the same fashion as the PC market since it's a closed market.

Several chipmakers (ATI, Broadcom) are bringing PC-type functionality (3D, video, etc.). OpenGL seems to be a suitable foundation. BGL group identified requirements: surfacing, compositing, marking engines (OpenGL, UGL, etc.) Surfacing and compositing APIs also must be crossplatform.

Good progress made on GLX-like surfacing/compositing layer. Defined core marking API and interfaces between multiple marking APIs and surfaces.

Settop platforms are resource constrained. Chipmakers and network operators find OpenGL "too big" - 1M driver on 4-8M devices. BGL group working on 3D "profile".

Not many developers compared to PC market. Network operators kept demanding games / interactive content; ATI and Sony decided to go ahead and implement.

BGL group is about done with 1.0 specification. Going through 2 implementations of surfacing / compositing APIs, one on ATI Rage Pro class box, one on Playstation2. Two other non-public projects in varying states of support.

BGL working group plans to go public soonish (July-September) with press release, 1.0 specification, availability of developer boxes, etc.

Sun's involvement is that they sell servers to network operators. Gets requests for how networks will be used. Several activities: JavaTV, DVD consortium in Europe, ATSC group in US, other business interests. Not building settop boxes; probably wants to provide a Java binding for it and provide applications to drive use of servers. No strong opinion on profiling issue, but wants resolution so industry can move forward in this area.

BGL profiling discussion as a whole has not reached consensus. SGI advocates doing all of OpenGL. BGL IHVs mostly advocate profiles aimed at their hardware constraints. No clear methodology for constructing a profile, which has complicated the process.

Rob asked for feedback from the ARB on their profiling discussion. Jon asked if ARB participants are interested in discussing OpenGL and embedded systems. Someone else (Bimal?) suggested that the BGL APIs might be a good thing to standardize on as a cross-platform replacement for WGL etc.

Two points were brought up yesterday: drawing a distinction between texture fetch/blend units (we don't want to deal with this now), and what happens when a texunit references a texture from another unit that is disabled or inconsistent. Initial resolution: disable texturing on the affected unit (e.g. disabling propagates forward). NVIDIA has a concern with this as their current behavior is to treat the input as white, rather than turning the affected unit into a passthrough.

Pat wants a crisp definition of "references" for this purpose, in terms of inputs to the texture unit.

After much discussion, straw poll indicates most people prefer undefined behavior. However, the fetch/blend issue became more pressing during discussion. Michael undertakes to write an extension exposing this; Rick will rewrite ARB_texture_env_combine WRT Michael's extension. Try for next meeting or before.

Some level of discomfort WRT Nick's presentation; he will write up a note stating that nothing discussed today is proprietary and send out post-meeting.

Intended to handle more flexible geometry processing. Multiple vertex buffers, new lighting models, etc. "Instruction set" controlling how the pipeline functions. Many implementations already microcode such behavior in their GEs, others do it on general-purpose host CPUs.

Proposes mechanisms for loading and managing these, and the instruction set itself, which is where NVIDIA feels they have IP.

Bimal notes that lookups in cubemaps can generate artifacts across cube face boundaries. Would like some way to have lookups respect cube geometry. Options: (1) no change (2) allowable alternate behavior (3) cubemap texture edge mode extension.

Intel will bring back a proposal.

Bimal gets questions as to life expectancy of OpenGL. ARB extensions are mostly standardizing existing work; IP issues impede progress. Also, OpenGL doesn't have a conference.

Jon wants to figure out how to get more ISV input to the ARB. Also, ARB working groups aren't coming in as well prepared as they ought to be.

Nick points out that DX has lots of marketing money associated with it. Also, it has a file loader.

Dale thinks Microsoft's unwillingness to ship OpenGL 1.2 DLL, and general lack of engagement, contributes to perception of staleness.

Bimal, Dale, and Michael are in favor of placing control of the OpenGL DLL with IHVs, rather than in Microsoft.

Jon thinks SGI may be able to coordinate some promotional/marketing activity, but doesn't have much money to spend. Will consult with Kurt and Bill Mannel.

Bimal thinks teleconferences are useful. More frequent face to face meetings would also be useful, as might more ARB meetings (6x/year). Many people indicate willingness/ability to come.

Red Book is in fifth printing within one year. Would an OpenGL developer's journal be useful? More frequent technical articles on opengl.org? Need to review OpenGL Specification more frequently. Jon will undertake to update Specification by next meeting with current ARB specs.

Man pages need to be updated too. Dave is willing to be responsible for this. Dale asked if WGL man pages could go on opengl.org too. If Dave can get base WGL pages from Microsoft up, Dale will do them for WGL extensions.

Some discussion of GLSetup and driver support issues. Integrators like Dell don't like users replacing drivers since it creates a support issue. Michael in particular - also Dale and Bimal - are interested in a vendor-controlled OPENGL.DLL, since Microsoft is having difficulty keeping OPENGL32.DLL up to date. NVIDIA and Intel seem interested in doing such work.

New working groups identified for next quarter:

• Separating texture fetch and texture blend units (Michael).
• Matrox would potentially like to lead a working group on indexed_blend functionality, based off vertex_blend working group. Evan and Jon Paul will sort out leadership.

Continuing or unfinished working groups:

• Video source - pursue in Khronos.
• State objects (James Bowman was going to lead, left 3Dfx for a dot-com) Jon will pursue with Blythe, maybe do himself.
• Render to texture - mostly capturable in terms of pbuffers + automatic mipmap generation.
• Vertex array objects - Blythe was leading. Brian Paul will pick up. Jon will ping John Carmack re participant undertaking.

Nobody has picked up copies of the NVIDIA proposal. Nick is wondering why - are people frightened of contamination? They're trying to do the right thing and are willing to adapt the proposal in a semantic sense, although the functionality is fairly fixed.

Michael is concerned that OpenGL is no longer driving hardware features. This makes it difficult to achieve common interfaces.

People struggled with the difficulty of discussing this stuff. A cooling off period was suggested by Jon. Also, we'll consult with Michael Duncheon regarding correct behavior - is there some way to transfer the information within the specs without contaminating people.

OpenGL Progress / Marketing:

• Jon will talk with Kurt and Bill Mannel re joint marketing efforts.
• OpenGL Technical Conference?
• File loader?
• OpenGL DLL by IHVs?
• Developer's journal / technical articles.

Other stuff:

• Jon will update GL Spec w/ARB extensions.
• Dave will update SI man pages.
• Dave will try to get WGL man pages from MS for publishing.
• Dale will create WGL extension man pages.
• Michael will lead group on separating texture fetch/blend units.
• Evan/Jon Paul will sort out leadership of group for indexed_blend.
• Jon/Blythe will sort out leadership of state object group.
• Brian Paul will pick up vertex array object group. Jon will ping Carmack re participation.
• Texture LOD bias group continues.
• Vertex blend group continues.
• Texture combiner group continues (quickly).
• Paula will poll group for next meeting date.
• Pat will propose cubemap changes online.
• Pat will propose texture compression changes online.
• Nick will send out a letter stating that nothing thus far discussed re the NVIDIA proposal is proprietary.
• Jon will bring up ChrisF's proposed secondary color/rasterpos changes online.
• Jon will put ARB minutes on participants website.

The next meeting will be hosted by 3Dfx in Silicon Valley in September. Exact dates TBD by discussion on the opengl-participants list.

ATI had previously volunteered to host the December meeting in Orlando.

Thanks to NVIDIA for hosting this meeting!