Summary of Discussion Topics

• Introductions and Status Updates
• OpenGL 1.3 Spec Review
• Closed Members-Only Meeting
• OpenGL 1.3 Schedule
• ARB Extensions
  • WGL_ARB_render_texture
  • ATI_vertex_shader
  • VA_memory_manager
  • ATI_vertex_shader (cont.)
• Next ARB Meeting
• Multisampling discussion (cont.)
• ARB Extensions (cont.)
  • ATI_fragment_shader
  • ATI_pn_triangles
• OpenGL 2.0

June 12, 2001

Introductions and Status Updates

SIGGRAPH OpenGL BOF will be 6-8 PM August 15th, in the Westwood Room at the Wilshire Grand (following the OpenML BOF). Let Jon know if you have agenda items.

SGI will be starting work soon on an OpenGL 1.3 press release for SIGGRAPH - let Jon know PR contacts at your company.

OpenGL 1.3 Spec Review

ARB_window_pos status - Brian has been working on fog_coord and secondary_color interaction. General support for inclusion in OpenGL 1.3. Brian will revise spec over lunch.

Matt Craighead and Dale Kirkland support dropping the ARB affix for ARB extensions going into 1.3. Straw poll shows predominantly in favor of doing this, and we will. Drawbacks: Bimal's SDK gets bigger (twice as many procedures).

Action: Jon needs to bolt together WGL extension specs to form a "WGL 1.1" specification document.

Detailed spec review followed. Numerous minor changes people proposed will be reflected in the next spec draft, but aren't listed here to avoid redundancy.

Open issue: the multisample spec actually precludes a supersampled implementation by being as specific as it is; do we need to revise the language to not require e.g. only one texture sample/fragment? We'll note questionable multisample-specific language as we go through, and judge whether/how to revise it later; Dale and Michael will propose new language.

Open issue: can we fill in functionality of DECAL mode in table 3.21 p. 150? Brian has made a proposal, but e.g. NVIDIA disables texturing in this case, while Intel defines a behavior, so it's difficult to do in a backwards-compatible fashion.

Some of the new tables left-align column entries, some center entries; Jon will make tables consistent, insofar as possible.

As an experiment, we'll remove the grayscale applied to optional (ARB_imaging) body text in the 1.2 spec (but keep the grayed-out imaging state table entries).

There's a problem with the definition of ALL_ATTRIB_BITS in OpenGL 1.2 and before, given the existence of new state groups. Options include:

1. Just add the MULTISAMPLE bit to the mask.
2. Specify that the high bit of the mask is special, meaning all attrib groups supported by the implementation, and add it to the mask.
3. Change mask to 0xFFFFFFFF.
4. Introduce a new enum (ALL_ATTRIB_BITS_REALLY? :-)
5. Add a new entry point taking a list of groups, rather than a mask.

Working assumption after discussion: change to ALL_ATTRIB_BITS = 0xFFFFFFFF; we'll give people some time to think about implications. It affects covgl conformance slightly. We'll fold this change into the formal spec vote next month.

Big discussion about requiring 1+ or 2+ texunits in OpenGL 1.3; some people, particularly Bimal, feel that some hardware may be precluded by this, and we should let the market decide. Others feel this is common capability by now and we should shove the conformance bar up. Issue left open for pushback in the next week or so, but for the moment we'll edit the spec to require 2 or more units.

Discussion of multisampling and conformance; many tests will fail because of assuming e.g. a constant color across a span. Several IHVs have hacked their drivers to avoid exposing multisample PFDs to WHQL conformance, to avoid this.

Closed Members-Only Meeting

Apple applied for Auxiliary Membership and was unanimously approved by the Permanent members present (SGI, Intel, 3Dlabs, E&S, Microsoft, Compaq). Apple's membership will be effective as soon as they've executed the ARB Member Agreement.

June 13, 2001

OpenGL 1.3 Schedule

We'll try to accelerate spec beyond the current schedule. Deadlines:

• June 20 - comments to Jon on open issues.
• June 25 - final spec draft.
• July 9 - teleconference to vote on OpenGL 1.3.

GLX 1.4 spec will lag the core GL spec, although Jon will try to get to this quickly.

ARB Extensions

WGL_ARB_render_texture

Bimal led this discussion and discussed recent changes in the proposed spec. How should we deal with RGB/RGBA textures? E.g. app may have used alpha while rendering, but only want to use the RGB components of the image as a texture. Bimal allowed choice of binding an RGBA image as either an RGB or RGBA texture. Concept is upward extensible; e.g. given a visual, it's possible to bind only the depth buffer to a texture.

Second change: spec had texture type and format. Not consistent with core spec language. Changed texture type to texture target.

Intel has not implemented this, but ATI has, and hasn't come across any big issues.

Change CopyTexImage3D to CopyTexImage1D in Overview.

Dale asked about what happens when modifying a pbuffer after it's bound as a texture. It's undefined; Bimal notes that defining behavior of rendering going on from another thread is difficult.

Change to specify that the "contents of the bound texture", rather than "contents of the pbuffer that's bound", are preserved while bound; this supports copy semantics.

Alan asked about GLX versions; GLX_ARB_render_texture hasn't been kept up to date, but there's no reason it can't be completed.

Alan also asked about issue 17 (supporting depth buffers as textures). Can easily be added as a separate extension. Brian's work on shadow map extensions, when ready, may make this more relevant. Bimal thinks it's a little premature.

VOTE: 8Y / 1A / 0N, PASSED. Bimal will send final version to Jon. Jon will assign WGL token values.

ATI_vertex_shader

Evan led this discussion. ATI has got the spec to a solid state and thinks it's shippable. They want to bring it forward to discuss changes since the last telecon (cosmetic only over the last 5 months) and to call a vote to draw closure and enable ATI to ship it, either as EXT or ARB.

Will defer discussion to later in the day, so Evan can make copies of the spec and ATI's email this morning.

VA_memory_manager

Allen Akin led this discussion. Review: this extension arose for several reasons:

• Gaps in the core GL spec (for example, there's no way to query if two textures can be simultaneously resident, so in a strict sense you can't determine if multitexture with two textures will work).
• Objects of different types can contend for the same memory in modern architectures.
• Modern memory hierarchy is more extensive; original spec just says "resident"/"nonresident". There are apps for which exploiting the more extensive modern hierarchy is valuable.
• Many more types of objects now, e.g. pbuffers, vertex array objects, vertex/fragment programs. Would be nice to have a consistent framework for managing interaction of all these things.
• Scene graph APIs try to estimate overall time to render a frame, to guarantee frame rates. To succeed in this estimate, they need information on how long lower level operations take. Once you make the generalization of handling multiple objects simultaneously, as this extension does, the driver must make time estimates that are close to the types of estimates the scene graphs need. Current proposal exposes these estimates to apps and attempts to make some guarantees as to what they mean.

Allen has done a sample implementation supporting all the functionality described here, establishing that a production-quality implementation is possible. Pushing for implementations set off some controversy; Allen has been talking to IHVs and polling ARB participants. The poll revealed a split between ISVs and IHVs suggesting that resolution in the framework of the current extension is impossible. Allen proposes splitting the extension into three parts:

• Core proposal much like the current one, except: Clarify memory pool semantics (remove explicit "AGP" enum), and split out:
• Time estimation moved into a layered extension. Unlikely to be implemented, given IHV pushback.
• Memory pool selection moved into a layered extension, mapping object+attributes into an enum which is the preferred memory pool; this can be used in the core extension. There will be ~12 attributes, which is about the minimum to give the driver enough information to make a good decision.

  Pete asked about utility of the extension in a high-stress situation: UMA architecture, rendering to 3D textures and rendering using those textures, streaming textures from asynchronous sources, ping-pong buffer swapping, pbuffers used on the side. Allen believe the design will encompass this, although e.g. pbuffers need an extension to obtain an identifier for them that can be handed to the memory manager.

NVIDIA has been following the discussion and considering generalizing part of their vertex program extension which allows making multiple vertex programs resident. If that encompasses what 90% of ISVs want, it's a more comfortable way to move forward. Most apps (leaving aside e.g. Discreet) won't need to exert the degree of control allowed by Allen's extension, and aren't aware of how other parts of the system are using the memory hierarchy. NVIDIA believes they have implemented good heuristics in their drivers.

Allen notes that the proposed new core extension may be less ambitious than Nick is thinking. It supports managing groups of objects, tagging them for copy/swap semantics, and making them resident or not. THe extension doesn't have to expose any further memory hierarchy.

Bimal notes that it's painful to expose this functionality from inside the driver, imposing a testing/support burden, and the benefits of exposing it to the app aren't obvious. Allen built a prototype for some of these reasons. He think's there's some degree of conservatism; this can be thought of as new functionality that only some ISVs will use, just like vertex programs. There are people, like Intrinsic, who need these raw capabilities to make their scene graphs work. Jon suggested targeted embedded (constrained memory) or high-end systems using scene graphs first.

ATI_vertex_shader (cont.)

Spec distributed at the meeting removed a couple of unneeded enums describing storage classes. Discussed several other minor nits and clarifications.

ATI is working with some other vendors on this, but can't reveal who they are yet. There was some degeneration into politico-historical discussion at this point.

ATI asked for a formal vote on the spec. Matrox then noted that they'd put a lot of work into the ATI proposal, and wanted a spec that supported a lot of hardware, including Matrox's. The ATI spec is flexible enough to be supportable and allow other hardware underneath.

Evan said that there are no capabilities in DX8 that are not also exposed in ATI_vertex_shader. In addition, the extension can be implemented on any "DX8 1.1 pixel compliant" hardware. However: any instruction specified by the extension can be implemented in a variable number of micro-operations, using local storage, or otherwise not requiring that each instruction translate to one micro-op.

VOTE: YES 1 (ATI) / ABSTAIN 4 (E&S, 3Dlabs, SGI, Sun) / NO 3 (MS, NVIDIA, Intel), FAILS

ATI asked those abstaining to contact them individually to indicate why. SGI said they voted as they did not because of any technical issues with the spec, but out of fear of setting up an unresolvable conflict within the ARB over vertex programming, rather than the existing, merely very difficult situation. Intel and 3Dlabs concurred.

Next ARB Meeting

The next meeting is tentatively scheduled for Tue/Wed, September 11-12. Apple is willing to host in Cupertino; Matrox may be willing to host in Montreal. Matrox will make a call on this within the next couple of weeks and we'll decide at that time.

Multisampling discussion (cont.)

Dale noted there are 6 places where multisampling refers to a single texture coordinate. As written, the spec precludes a true supersampling implementation. Does it need to be corrected, pulled from the spec for 1.3, or otherwise?

Bimal's biggest concern is basing the coverage mask on alpha; supersampling implementations just don't do this.

Pages 64, 75, 80, 116, 163, and 176 contain suspect language. The parts towards the back, discussing a single color, are the worst.

Evan's biggest concern is that single color, fragment center sampling precludes supersampling. Sampling at the fragment center may be arbitrarily far outside a primitive being sampled. In the past, an SGI white paper discussed using the fragment center only if within the primitive, the closest subsample otherwise. This can force e.g. sampling the border color rather than the texture color. Dale noted the opposite case: two triangles sharing an edge at the pixel center generating an unreasonable color.

Dale would rather pull it from 1.3, rather than force a second extension to support supersampling. Bill agrees.

Bimal notes that supersampling can be supported on most hardware today, if there's some way to reduce the samples after image generation.

Nick says that NVIDIA supports supersampling on some architectures, multisampling on other architectures. Sees it as a reasonable thing to drop from 1.3 iff making the fix would hold up 1.3; but would like to see it get in.

Michael suggested dropping the SampleCoverage APIs. Equivalent functionality will be needed in supersample implementations, however. Currently, the rasterized destination alpha is the same as the coverage in NVIDIA's drivers.

Does anyone have a solution for generating coverage based on alpha for supersample implementations? Page 163 is really the difficult part. The remainder (allowing more flexibility in sampling locations) seems tractable. But the coverage mask stuff is of a lot of interest to e.g. 3Dlabs' customers.

Evan suggests generating an additional alpha value per subsample, modulating the alpha coming down the pipe. By setting the sample pattern in a dither pattern, the resultant alpha can be changed for each sample, causing writing the correct number of samples for each pixel.

Easy to change draw/clear behavior (p. 176) such that ColorMask and DrawBuffers only affects color samples, not depth/stencil.

Bill suggests we fix as much as we can now, and plan to weaken/vagueify the coverage behavior when true supersample implementations come along. Some of the language on the bottom of p. 162 is already vague along these lines.

Dale will propose new language and circulate it.

ARB Extensions (cont.)

ATI_fragment_shader

Evan circulated a snapshot of ATI's work in progress, and is describing their programming model to stimulate comments / thoughts as early as possible and hopefully head off multiple competing extensions again. ATI is confident that there's too much divergence in supported operations and operation counts at this point, to standardize yet. The number of instructions and temporaries supported needs to increase to make it truly general functionality.

The proposal essentially replaces the texture application stage, and interacts with texture coordinate generation.

There was a suggestion of using the DX pixel shader file format instead, to leverage work already being done for shader tools etc. Nick noted that Microsoft probably considers that format proprietary, and that there are OpenGL concepts that have no analog in DX which need to be expressible. The NV_vertex_program format is not compatible with the DX8 format.

Nick proposed that a procedural interface for defining the program was not easily extensible, compared to a string-based interface like NV_vertex_program. Evan said there are plenty of ISVs in both groups, e.g. ISVs who already have their own shader language and are burdened by having to convert to a different format, and said that in the long run, both formats should probably be supported.

NVIDIA couldn't take on the risk of using Microsoft's IP in OpenGL, nor could others. Allen notes that other people have shader languages that we could make use of.

Some discussion on string vs. procedural interfaces. ATI has taken apart DX textual shaders into procedural form, and probably the other translation is easy as well. There seems to be some receptiveness by attendees to providing both types of interfaces.

Nick says that NVIDIA has shader work in progress which they'll be willing to share "soon". ATI wanted to kickstart the discussion and try to project where we'll be a year out, instead of what's being done on today's hardware, which is restricted enough that agreement is probably impossible.

ATI vertex program SDK will probably go under their royalty-free SDK license, so it might provide some context for people to experiment and discuss.

ATI_pn_triangles

ATI distributed a spec, but there was little discussion. This extension exposes ATI's TruForm technology for dynamically tesselating triangles based on vertex normals. It shares some characteristics with subdivision surfaces, but does not use nonlocality of reference for tesselation. It appears the distributed spec may be missing some of the mathematics; Evan will look into this.

OpenGL 2.0

We've accumulated lists of possible changes, additions, and deletions in the past, but need to compare / synthesize them. Should invite presentations from / discussion with from folks like Michael McCool, Stanford shader group, etc. (if people know of other relevant academic work, please let Jon know). Might try to invite presentations at the SIGGRAPH BOF.

Many thanks to Vicki Shreiner and Dave Shreiner for food, drinks, and handling setup, and to Nick Triantos for bringing donuts and bagels!