Disclaimer

People reading the OpenGL ARB minutes are cautioned that statements made by attendees do not represent official company positions unless explicitly identified as such.

Action Items / Conclusions from the Meeting

• Went over proposed feature list for the next core revision and classified features as probable, possible, ARB extension status only, or dropped.
• Determined deliverables and timeline required for including specific features in the next core revision, as well as other milestones; see below for details.
• High level shading language spec reported out of the working group. WG is still developing extensions to bind it to the OpenGL API, but this will be complete soon.
• Bylaws WG continued the ongoing development of new IP disclosure and licensing policies.
• Khronos OpenGL ES status update. Their spec is nearly complete.
• Super buffers WG is making good progress and unifying the two proposed specs. Still resolving some issues and collecting input.
• A minor spec tweak is needed for the WGL_ARB_render_texture extension spec.
• June meeting will be hosted by Apple in Cupertino, CA.

Summary of Discussion Topics

• Next OpenGL Revision
• Shading Language
• Bylaws Working Group
• Khronos "OpenGL ES" Update
• Super Buffers Working Group
• WGL_ARB_render_texture
• Next Meeting

Tuesday, March 11th

Next OpenGL Revision

Discussed timeline leading up to SIGGRAPH release. Bylaws WG will not complete in time to affect this, so we're looking at the same 30-day comment period after spec approval and prior to public release.

Ran down proposed list of extensions to make first cut at feature set:

• EXT_stencil_two_side (or the similar ATI extension)

  EXT version adds separate front/back stencil mask and stencil ref, and has an enable mode; otherwise similar to ATI extension. Likely contention is over hardware capabilities, not interface. Bill says the extra masks aren't being used today.

  Straw poll: 13 Yes, 0 Don't Care/Abstain, 0 No. Pat and Bill will make a joint proposal by Monday 4/14; if not, this won't go into the next core version.

• EXT_shadow_funcs

  Extends depth comparisons in the shadow unit to general use of depth textures as a depth test (short of writing the depth buffer). Concern about utility of == due to numeric issues. Supported by Mesa and NVIDIA today.

  Straw poll: 3 Yes, 8 Don't Care/Abstain, 0 No. Nick will ask Mark Kilgard to describe utility of this extension on the participants' list. We may want to promote this to ARB status if it doesn't go into the core.

• NV_point_sprite

  Screen-aligned quad (size based on current point size) with texture coordinates generated automatically. Useful for particle systems with non-pointlike geometry. Need to fix a few spec tweaks; for example, if the point is clipped, should all fragments generated for the sprite be clipped - even those within the viewport? ATI has a not-shipped "point cull" extension which could feed into this.

  Straw poll: 10 Yes, 3 Don't Care/Abstain, 0 No. Matt Craighead will work with interested parties (at least Dale and Evan) to address issues and propose changes for the core version by 4/14; if not, this won't go into the next core version.

• Occlusion queries

  NV_occlusion_query extends HP_occlusion_test by allowing more outstanding queries, and returning more information (occluded fragment/multisample count instead of yes/no). HP says there are lots of apps using their extension. There's also a layered HP extension supporting multiple outstanding queries, though we're not sure if it's actually shipped, and there's no specification for it in the registry.

  The NVIDIA extension doesn't return percentage/total fragment count - this is a possible future direction. ATI would like to see some flexibility in accuracy of the pixel count, e.g. monotonically increasing but only "roughly proportional" to the number of passed samples. For example, returning the count with granularity of 8 samples instead of 1.

  Dale noted that many apps misuse the extension by rendering more with the feature enabled than without it. Their drivers actually disable the extension for some apps which are known to misbehave in this fashion.

  Jon noted that the spec in the registry is tagged "Proprietary". Nick will investigate this and report back. Teri asked if HP and NVIDIA can collaborate on making fixes. One company noted that this extension is fundamentally incompatible with their architecture. Some desire to make occlusion tests into an ARB extension rather than a core feature.

  Straw poll: 12 Yes, 0 Don't Care/Abstain, 0 No. Further refinement straw poll: 6 in favor only of promotion to ARB status, 7 want to put it in the core. Matt, Jeremy, and Teri will work on an updated proposal. Nick will report back on possible IP/copyright issues by 4/14. If the proposal is ready and the IP issues cleared up by then, we'll vote on it; otherwise, this won't go into the next core version.

• NV_texture_rectangle

  Supports non-power-of-2 sized textures. Restrictions in NV spec: cannot be mipmapped, cannot be wrapped, no borders, texcoords go [0..width,0..height] instead of [0,1] to allow accessing specific texels. Uses a separate texture target (instead of TEXTURE_2D) because of these restrictions.

  Bimal is interested in the functionality but unsure about extended range texcoords, especially if mipmapping is possible. It's apparent that this isn't ready for core status due to several open issues.

  Jeremy will lead a small working group to fix up the spec. Jon will create the WG mailing list. Noted that Apple is shipping EXT_texture_rectangle, which is similar to the NV version but relaxes some of the restrictions; Jon would like a copy of the EXT spec for the registry.

• NV_half_float

  Pat thinks this doesn't make sense unless considered in conjunction with floating point frame buffers. Extension has two largely independent pieces of functionality:

  • New data type 'half' (16 bit quantity; not a data type supported by general-purposes CPUs today). Matches internal frame buffer formats. ILM OpenEXR file format uses this to represent high dynamic range artwork. Supported through the pixel path.
  • Vertex processing path that also operates on this data type. Less important than the pixel path.

  ATI extensions split these up and do not address external formats, only internal FP.

  Some other relevant buffer/format extensions:

  • NV_float_buffer
  • ATI_texture_float
  • ATI_pixel_format_float

  This is unlikely to make it into the core. However, ATI & NVIDIA are interested in merging FP buffer functionality into an ARB extension. This can also affect the superbuffers effort, although it's secondary to other issues the group should address.

  Jon noted that SGI has IP in this area, although there may be ways to work around this. He'll look into providing more information on the patent.

  Superbuffers WG will pursue this as an ARB extension, as time allows.

• NV_fog_distance

  Gives more app control over computing fog distance, including supporting true "eye radial" Euclidean distance. NVIDIA isn't actually advocating this; old functionality by today's standards. Dropped from consideration for the core, due to lack of interest.

• ATI_draw_buffers

  Extends DrawBuffers to support an array of buffers to direct color output to (e.g. AUX0, AUX1, etc.) Also extends ARB_fragment_program with a program option allowing setting multiple color outputs. Noted that blending happens separately for each buffer being written to. Will revisit this during the ARB_fragment_program discussion.

• ARB_vertex_program / ARB_fragment_program

  Both extensions have proven desirable since their creation. IP issues aside, they are very useful as building blocks for tools like Cg, and helpful for ISVs wanting to see what "assembly language" is being fed to the hardware. Dale is still concerned that this will be deprecated functionality going forward towards HLSLs.

  The low-level instruction set is not complete (e.g. supporting looping/branching constructs). There's still interest in reviving the vertex_program WG and doing this work.

  Straw poll: 8 Yes, 4 Don't care/Abstain, 1 No. Noted that most developers look on ARB extensions as having the legitimacy and pervasiveness of core features, so from that perspective it may be OK to not put them into the new core. The marketing group will discuss IP issues. Everyone should determine their own comfort level with including this in the spec; we'll hold a formal vote in 4-6 weeks.

• ATI_draw_buffers, revisited:

  Kurt would like to see a general capability to write more data out from shaders, but not necessarily this exact mechanism.

  Straw poll broke down into 3 categories: 5 votes (alt.software, ATI, Dell, IBM, SGI) for making it either core or ARB extension functionality at this time; 5 votes (Apple, HP, Imagination, NVIDIA, Sun) for making it an ARB extension first, followed by promotion to the core; and 4 votes (3Dlabs, E&S, Intel, and Matrox) for only making it into an ARB extension.

  We'll form a WG once cycles are available; people are pretty saturated with currently active WGs. Only two open issues: What if anything happens WRT fixed-function programs which aren't output-aware? How do we modify HLSL to write multiple outputs?

• ARB_vertex_buffer_object

  Positive feedback for early-access implementations of this extension. Several games and other apps are making use of this in their code. Seems easy to port from existing vendor extensions. Waiting for big apps to get more feedback.

  Straw poll: 12 Yes, 2 Don't care/Abstain, 0 No. We'll wait until 4/28 to allow time for more feedback from ISVs, then vote on including it in the core.

• Synchronization features - GL2_async / NV_fence / etc.

  ARB_vertex_buffer_object offers an alternative to the original motivation for NV_fence. Some feeling that different categories of apps desire different parts of the synchronization functionality: for example, maximum throughput vs. hard real-time needs. The buffer object class of extensions primarily addresses throughput.

  Fences are used in ways that object-locking APIs cannot be, e.g. waiting for completion of references to some part of a buffer.

  Bimal notes US patent #6025855 may touch on this area.

  This is desirable, but it's not settled funtionality. We'll form a new WG when cycles are available.

Shading Language

HLSL spec was voted out of the working group last month and has been posted for public review. OpenGL extensions binding the HLSL to the API are still under development; major remaining issue is the choice of object model. The WG attempted to vote on this in December, but the new "Borda vote" scheme confused us and the results were unclear.

Bill skimmed over his GDC presentation to update non-WG participants on recent changes in the HLSL.

Still need to get license to use Perlin noise function description/code in the HLSL specification - Jon is pursuing this with his lawyers.

Held straw poll, then WG vote on the object model issue. Results of the vote were 5 for handles, 3 for old-style names, and 1 Don't Care. We'll proceed with current handle-based API.

Discussed extension proposals in the WG, concentrating on GL2_shader_objects. Concern about UseProgramObject requiring compilation work be done at that point, instead of at use (glBegin) time, and possibility of having to do unneeded work for e.g. hetereogeneous graphics heads where some heads will not be used by that shader. Concern about info logs being persistent per-object; Barthold will propose a per-context per-object-class alternative. We reconvened as the entire ARB at this point.

The HLSL WG has reported out the HLSL spec and would like it to be formally approved, even though the GL2 specs remain to be completed. Some objection to this staged approach since interactions between the extensions and the language might still emerge. Compromise straw poll held; HLSL spec signed-off on 12 Yes, 0 Abstain, 0 No. We'll move forward expecting minimal changes to the HLSL spec. Formal vote to be held after WG completes work on the extensions.

3Dlabs was asked to alter the "IP Status" comment on the GL2 extensions to account for their having submitted the original version of those specs under an explicit Contributor License.

Nick revisited half precision floating point and their strong desire to see it in the HLSL.

Wednesday, March 12th

Bylaws Working Group

No telecon tomorrow since people have been travelling. Will resume on Monday.

Helene reviewed recent progress on currently open issues list, followed by lengthy discussion of IP disclosure and licensing policies. Dave Zenz tracked comments.

Khronos "OpenGL ES" Update

Neil and David Blythe summarized progress on the embedded subset being developed within Khronos. OpenGL ES is nearly complete; final spec will be brought back to the ARB for signoff.

Super Buffers Working Group

Good progress is being made. Kurt proposed an alternative "image buffers" spec. Rob and Kurt have worked to converge and refine the proposed specifications. Added notion of a frame buffer object to which memories are attached. This methodology clarified distinctions between window-system owned and application-allocated (through the GL) buffers.

Some issues still need more input to be resolved; the next step will be defining and specifying micro-behaviors and writing a final spec.

Biggest remaining difference is in creating textures. Über buffers creates the texture memory object at one time, and has a sub-memory object interface to ask for e.g. specific mipmap levels or cubemap faces. While these sub-memories are buffers from most of the API's viewpoint, they are really just views into a single object.

In contrast, image buffers are fundamentally 1D, 2D, or 3D, and are aggregated together to form a mipmap pyramid, cubemap, etc. However, both APIs use aggregation to construct framebuffers.

Considerable discussion on this difference and its consequence. Much closer on other topics.

Next difference is 'bind' vs 'attach'. Mostly notational; straw poll showed strong preference for 'attach'.

Discussion on how to standardize this - can it be put in the next core release? Straw poll had all 12 responses in agreement: ARB extension first, promote to the core later. Additional comments: SGI thinks there's not enough time to get this finished and tested for a SIGGRAPH core release. Apple and Intel are both concerned about implementation difficulty. HP wants to address the buffer object problem. 3Dlabs thinks it's a bit premature.

Options for mapping: never, required, optional, required only for certain classes of objects. Discussion followed by straw poll: 6 responses (SGI, Apple, NVIDIA, Intel, Sun, HP) in favor of "never mappable". 2 (IBM, E&S) in favor of supporting mapping as an extension. 1 (alt.software) in favor of either never mappable, or only allowing some classes of objects to be mapped. 1 (ATI) in favor of only allowing some classes to be mapped, but they can live with never mappable.

Über buffers has content access APIs - MemImage, MemSubImage, etc. for writing into a buffer; GetMemImage for reading; MemCopy for copying. Mapping has the usual potential problems in multithreaded situations.

Straw poll: 7 (alt.software, ATI, E&S, HP, Intel, SGI, Sun) think they're useful. Additional "useful" comments: ATI could live without them. E&S and Sun are both concerned about implementation difficulty. SGI is concerned about data representation and transformation in the future, when these can be used as sources and sinks for HLSL programs using arbitrary structured data.

3 (Apple, IBM, NVIDIA) are not convinced they're useful. Apple is concerned about expressing/defining the structure of the underlying data as it's moved between memory objects. IBM wants to wait and add this in later if it turns out to be needed. NVIDIA wants to see if there's a simpler way to express this capability.

WGL_ARB_render_texture

Evan and Bimal discovered an ambiguity - bind semantics do not support an error indicating that binding to multiple texture objects is not allowed. But release semantics indicate that the buffer is released (e.g. all references are destroyed), rather than that it's detached from the bound texture object. They will propose the tiny spec change required on the participants' list.

Next Meeting

Following the meeting, Apple volunteered to host the June 10-11 ARB meeting in Cupertino; further details TBD.