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

• Jon will complete 1.5 spec updates with agreed on resolution of secondary alpha value setting and push to opengl.org.
• Bill will complete shading language and extension updates with the help of the gl2 working group, and push new specs to Jon for the registry.
• Jon will setup the shader language metafile working group. Nick to identify WG leader from his team.
• All members and participants wishing to sign up at the Promoter level under the new Bylaws should explore the proposed $12-15K/year dues figure within their companies.
• OpenGL 2.0 will be released at SIGGRAPH 2004. Basic feature list is now established but numerous action items specific to different proposed features must be closed by March 31st (see the minutes for details), at which point we will conduct formal ARB votes on new extensions and on the final 2.0 feature set. Failure to close those items will result in the corresponding features being dropped from OpenGL 2.0.
• Superbuffers WG should find a volunteer to maintain an issues list independently of Rob's specifications.
• Vertex array object WG to clarify existing specification and to determine required behavior when popping an array binding to a no longer existing array.
• Jon will propose a question for opengl.org to get developer feedback on extension query backwards compatibility issues.
• Technical WG will pick one specific task to stat with, and find members who will commit time to coding / writing for that task.
• Jon will setup GLX protocol WG. Ian and Pat will agree on the WG leader (Ian or Joe).
• The June 8-9 meeting will be hosted by Intel in Sacramento, CA.

Summary of Discussion Topics

• Specification Edits/Changes
• Marketing Working Group Review
• OpenGL 2.0 Feature Selection
• Bylaws Working Group Session
• Review of OpenGL 2.0 Feature Set
• Superbuffers Working Group
• Secondary Color Alpha
• VBO Binding Issues
• Floating Point Working Group
• ARB_extension_query
• General Technical Working Group
• GLX Protocol Working Group
• Next Meeting Plans

Tuesday, March 2

Specification Edits/Changes

1.5 specification edits reviewed. Dale thinks the GetHistogram pixel processing language - which is a bit tricky - is finally correct. Still need to resolve secondary color alpha default value (done on the next day). Changes are adopted by unanimous consent.

Shading Language and related extension specification edits reviewed. There are some functional changes. The glslang array function parameters now have to be sized and can be overloaded on array size. Updated fragment shader spec with mostly trivial changes, but reserved some new sampler type enumerants in addition to int/float/matrix types. This is backwards compatible.

Versioning - original was 1.052. Changed to major.minor (100.054) so major matches the extension name string. Currently compiler provides a VERSION token matching the name string (100), but not capturing the minor version. We clearly need some way to query the minor version. Exposing many more ARB_shading_language_### name strings is probably wrong. Also need some way to indicate support of new sample type enums in the shader object extension.

NVIDIA wants to setup a shader language metafile working group; general agreement, and Bill is OK with this being separate from the arb-gl2 WG. We will setup a new mailing list and NVIDIA will identify a WG leader.

Marketing Working Group Review

First WG telecon held last week. Shawn wants to float a dues figure of $12K-$15K for each Promoter, under the new membership structure. This is aimed to be enough to provide seed money for a developer conference, hire a half-time ARB engineering resource, or other such tasks of large and useful scope. People should take this figure back and check inside your company. Some pushback from people who have been assuming the earlier $5K figure floated

Proposed shared documentation project - would begin with pointers to existing documentation on IHV developer websites, expand to new material. Another possible use of member dues.

Major topic: next OpenGL version - are we ready to promote the HLSL into the OpenGL core?

A couple of years ago, Bill would have been surprised if a CAD ISV was one of the first to support the shading language because of their conservative reputations. But today a CAD ISV (SolidWorks) is one of the first to ship support for the shading language. They are using the shading language for material shading libraries (cast iron, anodized aluminum, stamped steel, etc). Also, RenderMonkey (joint ATI/3Dlabs project) is about to be shipped with shading language support. DCC ISVs (anonymous for now) will also be shipping shading language support.

Dave Zenz informally polled about a dozen of their workstation ISVs. Very responsive to the shading language. Out of 6-7 responses, 5 were actively developing or had already released apps using the HLSL. Responses typically indicated strong interest. Asked about extension vs. core - 5 respondents had a preference for a core implementation, 4 had a very strong preference. Asked about quality of implementation - 3 liked it, rest were mostly lacking experience.

Nick has also generally found good, positive response from ISVs. Some minor issues that have been brought up, but can probably be added to future revisions of the language. Pretty wide variety - content creation, graphics authoring, CAD - with roughly the same sentiments.

Neil has had similar experiences with their ISVs, and very strongly supports putting the HLSL into the core.

Randi's "OpenGL Shading Language" book was published by Addison-Wesley last week - joins the stable as the "Orange Book".

Dave thinks the real push is from the workstation side, where they want stable drivers over the longterm, and don't want to jump versions until there's compelling reason to do so. Bill notes that game publishers would like to be able to say e.g. "OpenGL 2.0 required" on the box.

Eskil thinks game developers are not so concerned with the latest and greatest API version, given their 3-4 year development timescale, but they would be more confident planning to use "OpenGL 2.0" than a bunch of extensions.

Kent suggests bundling the HLSL with the FP buffer extensions. The extensions Dale is proposing are fairly far along, with the exception of the one handling enables, which has some yucky issues to resolve.

John R. thinks debugging needs to be addressed.

Straw poll shows everyone in favor of folding HLSL into the core! Continued discussion to identify other features.

OpenGL 2.0 Feature Selection

Each proposed feature was discussed followed by a straw poll of support. We have roughly 5 months to SIGGRAPH. Agreed plan of action is that the feature set can only get smaller from here on in. Features will be dropped if identified dependencies (spec changes, clarifications, etc.) are not done by March 31st. At that time we will hold formal votes on new ARB extensions, changes to existing extensions, and approval of the 2.0 feature set, then enter the spec editing and review cycle. Jon will break down the timeline in more detail soon.

Mark Kilgard wrote up a summary following the meeting, giving more detail on NVIDIA's preferences for non-programmable 2.0 features.

• OpenGL Shading Language (ARB_shading_language_100) + related API features (ARB_shader_objects, ARB_vertex_shader, ARB_fragment_shader).

  Straw poll: YES, unanimously.

  Dependency: Minor spec changes previously discussed by Bill are required by March 31st.

• Superbuffers - Rob described how the group has broken this into 4 extensions:
  • Base ARB_uber_buffers extension is for creating memory & framebuffer objects, and attaching buffers to texture objects.
  • ARB_uber_mem_image adds functions to set/query contents of memory objects.
  • ARB_uber_vertex_array creates vertex array containers.
  • ARB_swap_buffers adds glSwapBuffers and framebuffer parameters to control it (swap interval, preserve source buffer), allows swapping between framebuffers in core GL APIs.

  Straw poll: NO (deferred until Wednesday's WG meeting, at which this was discussed in depth).

• Floating point buffer extensions - these are intended to allow 32- and 16-bit floats to be used in several places: internal format for textures, pixel format for non-displayed framebuffers, input format for DrawPixels / ReadPixels. The WG brought up some issues as to where clamping occurs in the pipeline, so Pat created another extension to control this. The four extensions are:
  • WGL_ARB_pixel_format_float - new WGL pixel formats to specify float components + ability to readback unclamped clear value so it can be cleared to an unclamped value.
  • ARB_texture_float - based on ATI extension, provides 16/32 bit floating point internal texture formats.
  • ARB_half_float_pixel - allows specifying float16 as an input format for pixel operations; split off from NV_half_float, which also allowed float16 as input to geometry path.
  • ARB_color_clamp_control - gives direct control of clamping to [0,1] for float formats. Several levels of control in vertex, fragment, and pixel pipelines.

  Together, these allow float16/32 to be used for pixel buffers, textures, and (undisplayable?) framebuffers. They do not allow float16s for vertex processing.

  Straw poll: YES, near-unanimously. These extensions were discussed in more detail on Wednesday.

  Dependency: The arb-float WG must complete final extension specs by March 31st, and the ARB must then formally vote to approve the extensions.

• Pixel buffer objects - these are an expected followon to vertex buffer objects. Many ISVs, particularly those with "pro" apps, want a better way to stream in pixel data in the same way they do vertex data today. NVIDIA has a spec they can forward around today.

  Superbuffers does overlap in functionality, and Rob thinks it's better for operations like render-to-vertex array (fewer copies required). There's been discussion on making uber buffers mappable; if there was a clean way to do that, it has the potential to be a better way to stream in data than PBOs.

  General sense is that the functionality is desirable, but it could be provided either through PBO or through layering on superbuffers. Open to further discussion.

  Nick & Rob will discuss whether to augment superbuffers, or finalize PBO. Nick will circulate PBO spec to the ARB. We will probably hold a straw poll by email at that point.

  Dependency: Agreement to use PBOs layered on VBOs. If so, the final extension spec must be delivered by March 31st, and the ARB must then formally vote to approve the extensions. If we decide to use PBOs layered on superbuffers, they will not be included in OpenGL 2.0.

• ARB_point_sprite - good for compressing data going over the bus to the gfx. card; games use it for replicating objects on the screen many times. Drawback: t coordinate is backwards from the usual OpenGL conventions.

  Straw poll: YES. Kent would like to address the t-direction issue.

  Dependency: Kent and other interested parties must develop changes to control the t coordinate direction by March 31st, and the ARB must then formally vote to approve any changes. Otherwise, the existing extension specification will be used as is.

• ARB_texture_non_power_of_two - no API, just relaxes restrictions requiring power-of-two textures. As a result, requires full NPOT textures for all texture targets. A problem is that this isn't fully implementable without software fallback paths on much current hardware. However, we are trying to set a high bar with the HLSL, which also isn't fully implementable everywhere.

  Pat says they've found strong correlation between FP buffers and NPOT textures. There are other ways of getting this functionality, like EXT_texture_rectangle (a subset of NPOT supported in more hardware).

  Straw poll: predominantly in favor - but given implementation difficulties, its inclusion may be questionable for now. People are more comfortable with committing to doing only the 2D part.

  Dependency: Nick will drive a discussion in the arb-texrect WG to determine if support is required for the other texture targets, and if not, deliver proposed changes to the ARB by March 31st. The ARB must then formally vote to approve any changes.

• EXT_texture_rectangle - texcoords for this special texture target change to [0,width]x[0,height] instead of [0,1]^2. This is especially helpful for non-graphics uses, e.g. Stanford's Brook language. Rob notes that we might also capture this in shader operations.

  Straw poll: YES on functionality, with agreement to provide lookup by texel index functionality in the shading language, instead of through the extension API. Kent says this is very painful on their hardware, and may be a showstopper for them.

  Dependency: Bill and the arb-gl2 WG must develop changes to the shading language to support indexed texture access by March 31st, and the ARB must then formally vote to approve the changes.

• EXT_blend_equation_separate - provides additional framebuffer functionality, not available through shaders since this stage of the pipeline isn't currently programmable (although it could be done multipass with writemask or source framebuffer data from a rendered-to texture).

  Straw poll: YES. A few companies want to sanity-check the extension, and make sure it uses the same enum values as the equivalent ATI vendor extension.

  Dependency: Companies needing to do sanity checking have until March 31st to push back on the extension, or offer changes for compatibility. The ARB must formally vote to approve any changes.

• NV_texture_mirror_clamp - fully orthogonalizes mapping texcoords to texels. Texel lookup is still fixed-function so this completes the set of functionality. But there isn't significant ISV feedback for utility of this.

  Straw poll: probably NO. Pat and Ian are strongly in favor; 4-5 others are opposed because there's no obvious use for this. Jeff wants to look up whether ISVs are using the ATI extension this was based on (his later response indicates it's used in their SDK demos, but they're not aware of ISV usage). Mirror clamp mode will not be included unless there's significant feedback and change of heart by March 31st.

• SUN_slice_accum - adds a dstAlpha-based LERP between the framebuffer RGB and the accumulation buffer RGB. Useful for composited volume rendering. Sun has been shipping this for a while; not sure how many ISVs are using it. Possibly the shortest extension specification on record!

  Straw poll: probably YES. However, Teri & Jon were both opposed for lack of demonstrated use. They will ask their volume rendering people for feedback.

  Dependency: Members who are concerned about utility must provide developer and/or internal feedback by March 31st. Only significant pushback will prevent inclusion in OpenGL 2.0.

• ARB_vertex_program / ARB_fragment_program / ARB_fragment_program_shadow - the low level shading extensions are definitely being used today. Nick agrees that a large number of apps will migrate to the HLSL when they can, but there are still going to be apps which want to optimize and hand-tune code, and debugging is arguably easier with the low-level API. Some developers have been asking for further ARB low-level extensions to match later hardware.

  Straw poll: NO (8 people in favor, 11 opposed). This is an increase in support from when we considered inclusion in OpenGL 1.5, but still not enough. The shadow extension is logically dropped as well, without the base fragment program extension it builds on.

• ATI_draw_buffers - tets you pick a subset of the color buffers for writing, and write multiple colors into multiple color buffers. Need to resolve interaction with GLSL. Implementations can support only one draw buffer, so it wouldn't force software fallback on less capable hardware.

  Straw poll: YES, unanimously.

  Dependency: Bill, Rob, and the arb-gl2 WG must make changes to define interactions with the Shading Language by March 31st, and the ARB must then formally vote to approve the changes.

• ARB_extension_query - we still need to resolve the backwards compatibility model (do new extensions continue to be added to the static EXTENSIONS string or are they queried just through IsExtensionSupported?) & runtime detection (does the query functionality show up in the static EXTENSIONS string?).

  Straw poll: YES, unanimously. Ian however wants this only as an OpenGL 2.0 function, not an extension, due to GLX implementation difficulties.

  Dependency: Open issues must be resolved by March 31st, and the ARB must then formally vote to approve the extension.

• Two-sided stencil (EXT_stencil_two_side / ATI_seperate_stencil) - this is used in Doom, eliminating multiple passes. Nick has noted some claims of IP against this on web forums.

  Straw poll: YES, unanimously.

  Dependency: We must explore and understand the potential IP issue by March 31st, in order not to accidentally push encumbered technology into the OpenGL core.

Bylaws Working Group Session

Reviewed a number of specific glossary and legal language issues and achieved a compromise on handling joint development agreements (existing agreements to be grandfathered).

In general, people are happy with the direction of the developing agreements, and we will probably be able to stay on Dave's timeline for completing the process. We need to be careful that the quiet period suggested around approving the new bylaws doesn't interfere with approval of OpenGL 2.0 by SIGGRAPH. Refer to Dave's WG notes for further details.

Wednesday, March 3

Review of OpenGL 2.0 Feature Set

Assuming the dependencies discussed on Tuesday are all satisfied, the OpenGL 2.0 feature set will include:

• OpenGL Shading Language, ARB_shader_objects, ARB_vertex_shader, and ARB_fragment_shader.
• Floating point buffer extensions from the arb-float WG.
• Pixel buffer objects, if based on vertex buffer objects.
• ARB_point_sprite
• ARB_texture_non_power_of_two (possibly only the 2D target).
• Indexed texture access via new fragment shader operations (instead of the EXT_texture_rectangle API).
• EXT_blend_equation_separate
• SUN_slice_accum (unless negative ISV feedback develops).
• ATI_draw_buffers
• ARB_extension_query
• Two-sided stencil (assuming favorable resolution of the potential IP issue).

Superbuffers Working Group

John S. is concerned about complexity and extent of design change with superbuffers; thinks we can solve customer problems with a different approach. An area of particular concern is how OSes are interacting more directly with GPUs for UIs, raising resource allocation/control issues.

Lots of discussion about implementation strategies, programming model, marketing, etc. It doesn't appear feasible to wrap up the current superbuffers proposal, get the ARB to sign off on it, and promote it to the core in the SIGGRAPH 2004 timeframe, so we won't plan on that. Instead, the WG will continue evolving its proposals and getting ISV feedback, allowing a chance for fully thought out alternate proposals to be brought forward. However this sorts out, the functionality could likely be at the heart of "OpenGL 3.0", as it represents another large advance and usage model change beyond the HLSL.

To reduce contention over closing issues that there may not be agreement on closing, Jon suggested the group consider maintaining the issues list separately from the uber buffers specification. This could reduce the workload on Rob, too.

Eskil Steenberg gave us a related presentation on algorithmic use of more flexible memory models, from his ISV perspective. Quick summary of the slides:

• Current shader model is still 1:1 vertex processing - transform, lighting, fragment shader setup, simple animation.
• Would prefer more general model of many:1 vertex processing, e.g. looping over indexed array of vertices and combining them to generate an output vertex. Curved surfaces, billboards, advanced blend animation, skeletal animation, deformers.
• Animation is done completely in the CPU in current packages like Maya, which kills performance. Similarly game developers want curved surfaces but can't easily do them with existing APIs.
• Would like to be able to put varying output data from vertex shader into a vertex buffer, rather than passing on to a fragment shader.
• Textures are poor random access memory paths - floating point indexing, mipmap filtering, etc. are hard to deal with.
• Legacy data types ("vertex", "color") and APIs (provoking vertex program with glVertex()) will be confusing to new developers.

Jon thinks the short code sample in Eskil's talk was quite useful in exposing memory access patterns and required changes in the GPU programming model, and that additional examples of what developers would like to accomplish with the HLSL would be helpful to drive discussion of this area in the arb-gl2 WG.

Secondary Color Alpha

SecondaryColor3 sets A=0. However, the default value is 1, so there's no way to restore the initial state. We've been discussing this for a long time; it's not entirely clear how we arrived at this point, but by consensus, Jon will change the 1.5 spec to mandate that SecondaryColor3 set A=1. This is in theory an incompatible change and could affect some application, but nobody considers it to be a problem in practice.

VBO Binding Issues

Kent has several issues. First, specifying directly that individual array bindings are established at array specification (e.g., VertexPointer) time. This is just a spec clarification.

Second, specifying when buffer deletions actually happen. The present language says that bindings are released at delete time, and Nick's proposed change (delayed deletion) doesn't match this. We will not change the current language.

Third, we should add discussion in section 6.1.14 (and in the extension issues list) to note behavior when popping the array binding to a binding to a no-longer-existent array. Need to resolve whether or not a new object is created in this case - by analogy with texture objects, it would be created. Resolution is TBD on the participant's list per Pat's proposal.

Floating Point Working Group

Dale reviewed ARB_half_float_pixel, ARB_texture_float, and WGL_ARB_pixel_format_float proposals. Need to determine whether to use half or float16 to refer to the 16-bit precision float data type. Need GLX equivalent to the WGL extension.

Pat reviewed ARB_color_clamp_control. Allows disabling clamping at several stages of the pipeline. Lots of open issues around specific operations which currently clamp, and around AA and multisampling math which may not make sense with non-[0,1] values.

ARB_extension_query

We need to enumerate compatibility drawbacks of not continuing to expand the EXTENSIONS string and only using this query, then poll developers. Rob suggests an alternate approach for enumerating extensions in addition to this.

Jon will construct a prototype question and post it to the participants list.

General Technical Working Group

We have a good list of proposed tasks but difficulty in engaging on them. Need to get people together, see who can pony up resources (Pat may have someone). To drive this, the WG will identify a specific task as our first goal, then collect parties interested in that particular task.

GLX Protocol Working Group

GLX protocol needs to be established for a number of ARB extensions (and corresponding 1.4/1.5 core features) to bring GLX up to date. May also want to define GLX equivalents of some WGL extensions such as WGL_ARB_render_texture.

General agreement to establish the WG. Ian may be interested in leading, and Pat also offered Joe Kain from his group as a possibility. Jon will setup the mailing list and we'll go from there.

Next Meeting

Intel will host in Sacramento on June 8-9. Kent Lin will provide more detailed information soon.

Volunteers are needed to host September, December, and beyond meetings. Please email or phone Jon if you may be willing to host.

Thanks to Apple for hosting this meeting!