Summary of Discussion Topics

• Status Reports
• ARB Extensions
• Outstanding Extension Status
• ARB Extensions (continued)
• New and Continuing ARB Extensions
• Conformance issues
• Spec issues
• Next Meeting

Wednesday, March 15

Status Reports

The Linux/OpenGL ABI working group has finished its public comment period and will shortly release version 1.0 of the ABI. XFree86 4.0 is now shipping, including Precision Insight's DRI work which is intended to follow the final ABI.

After the open source release of the OpenGL 1.2.1 SI in January, some licensees asked whether they could retroactively apply the SGI Free Software B License to the 1.1 SI. SGI has a statement regarding the conditions under which this is allowed; if you are seriously interested in doing this, contact Jon Leech for a copy. Note that this retroactive license application carries no rights whatsoever to the OpenGL trademark, nor can it be applied to the conformance tests.

Steve Wright reported on the 1.2 ICD status. Microsoft is still waiting for final code drop; SGI has been having some trouble integrating Intel tuning work, and Quake is not running. Steve talking with his management about just putting out the headers/dispatch tables and putting out a quick DDK update including 1.2 entry points. Looking at a service pack for Win2K; not planning support for Win95/98 or NT 4, but that's subject to ISV demand - mostly gated by testing demand. MS needs to refresh the kit soon anyway, for 64-bit support. Let Steve know if that's of interest. Some discussion about WGL ensued:

Kurt: Is there a WGL spec?
Steve: Not now. Suggested to management that they should create one. Management would like MS to own that space, but is having trouble hiring people - there are 4 OpenGL reqs open that haven't been filled yet.
Michael: It would be interesting for the ARB to draft spec and submit to Microsoft.
Dale: If MS isn't interested in extending WGL, maybe the ARB should take it over.
Steve: MS is interested in doing WGL work. Took a work list to Otto Berkes. Otto is interested in building a reference driver that talks to the D3D DDI.
Paula: Of the WGL extensions up for approval, at least two really should be core features - otherwise it's necessary to open a window just to query pixel formats!
Dale: Cumbersome; even more so with multimon (which monitor goes with which driver?) Is the ARB willing to maintain a spec?

Jon has not yet updated the core GL/GLX specifications to include ARB extensions approved last time. Will update ASAP. In the meantime, extension specs approved by the ARB will go in the extension registry.

BroadcastGL (www.broadcastgl.org) is being revived by Rob Glidden (now working at Sun) under Web3D auspices. ATI is implementing BGL.

ARB Extensions

We didn't follow the agreed upon comment periods this quarter due to SGI's OpenGL Product Manager (acting as the ARB Secretary) leaving the company. Bimal volunteered to manage the ARB extension schedule process for next quarter, until there's a new SGI ARB Secretary/Product Manager hired.

ARB_point_parameters

Last meeting, E&S had an issue with alpha fade behavior for tiny points. It turns out that their hardware rejects tiny points anyway, so it doesn't directly affect them.

Neither E&S nor NVIDIA like the multisample POINT_FADE_THRESHOLD behavior; NVIDIA wants to strip it out. Matt suggests adding an implementation-defined constant MAX_POINT_FADE_THRESHOLD which would clamp POINT_FADE_THRESHOLD, enabling implementation to finesse the issue.

Another possibility is to make the behavior optional in the spec; if so, it should be optional for both regular and multisampled points. Straw poll suggests this is the preferred approach.

Alpha fade behavior should be specified as happening after texturing and before antialiasing coverage. Some implementations might do it before texturing.

Michael will revise and bring back with these changes. Will use existing SGIS_point_parameters GLX protocol.

WGL_ARB_extensions_string

Paula led working group. Added HDC parameter (relative to EXT version). This can distinguish in e.g. multimon case. Discussion of how to promote this to core WGL, if and when MS revises/specifies WGL. Difficult to distinguish between generic and device-specific extensions.

HDC parameter is useless until this goes into core WGL, but should be kept in so there won't be 3 versions (EXT, ARB, and core WGL) with different calling conventions.

Paula will revise to specify error behavior for invalid HDC.

Pat objected to having a "Name" field which is potentially ambiguous.

VOTE: 10Y/0A/0N, PASSES

WGL_ARB_pixel_format

Paula led working group. This is an important extension; ICDs need a way to expose new pixel formats. This is a new way of getting pixel format attributes, superseding Describe{PixelFormat,LayerPlane} etc., which do not return extended attribute information.

Important that accelerated pixel formats come first because of how ChoosePixelFormat behaves.

Differences from EXT_pixel_format: clarifications of semantics of TRANSPARENT attributes. No API changes.

Proposed spec changes:

• Name change -> WGL_ARB_pixel_format
• SWAP_LAYER_BUFFERS query should return FALSE for a single-buffered pixel format, and SWAP_METHOD will be undefined.
• TRANSPARENT_VALUE query can't represent e.g. 12 bits/component RGBA. Change to TRANSPARENT_{RED,GREEN,BLUE,ALPHA,INDEX}_VALUE queries.
• Change GetPixelFormatAttrib[fi]vARB piAttribute parameter type to const int *; list is no longer NULL terminated.
• iPixelFormat parameter may take <= 0 values, which are also invalid. Error checking will take this into account.
• Sloppy language re "hardware" vs. "pixel format" capabilities in attribute descriptions will be cleaned up.
• Get/Choose queries mandate that if FALSE is returned, memory pointed to by piValues/piFormats will not have been modified. Change so that it's undefined.
• ChoosePixelFormat can return numFormats == 0 even on success. If it fails, contents of piFormats is undefined.
• ChoosePixelFormat will change to respect {COLOR,RED,GREEN,BLUE}_BITS_ARB rather than ignoring them when DRAW_TO_WINDOW is TRUE (this behavior wasn't specified in the EXT).

Sorting criteria for returned formats is much less rigorous than GLX.

VOTE: 8Y/0A/2N; PASSES dependent on updated spec being sent out by end of the ARB meeting.

WGL_ARB_pbuffer

Dale led working group. This started from the SGI GLX extension. WGL version drops the asynchronous clobber behavior, since there's no way to implement that on Windows. Instead adds a query as to whether a buffer was damaged after a mode change.

Open issue: when buffer is damaged, are just the contents damaged, or must the buffer be recreated? Dale will rephrase.

OPTIMAL_{WIDTH,HEIGHT} will be removed (as with GLX 1.3 spec).

Need to change dependency from WGL_EXT_pixel_format to WGL_ARB_pixel_format.

Proposed conformance test will require rewriting ctk.

Dale will revise spec and bring back tomorrow.

WGL_ARB_make_current_read

Dale led working group. Questions arose about compatiblity of two different "devices" being used as read/draw DCs. What really distinguishes them? Do we want to try and say that the same client driver must support both formats? What if a future multimon-capable ICD allowed different manufacturer's cards to interoperate in this fashion?

Will state that both pixel formats must be supported by the same driver.

Questions arose about ability to use accumulation buffers in this context. Accumulation should really be tied to write operations, not read operations. As is, it has difficult constraints on the buffers. Since it's hard to make work, we could just make it not work.

Will get rid of changes to chapter 4 of the GL spec and migrate them to comments in the WGL spec.

Change "device" to "physical device" in the 3rd paragraph of "Additions to the WGL Specification".

New error ERROR_INCOMPATIBLE_DEVICE which may occur when the draw and read HDCs are managed by different drivers.

Change dependencies to ARB instead of EXT_extensions_string.

PopAttrib may generate an error if new READ_BUFFER is mismatched.

ARB_texture_compression

Pat led working group. This introduces compressed internal formats: generic and specific. Generic is mapped to a renderer-chosen specific format. A query enumerates all supported specific formats.

Introduces new entry points for specifying pre-compressed data. Pixel transfer operations are bypassed in part when specifying pre-compressed data.

Compressed textures can be retrieved in either compressed or uncompressed form via GetTexImage. Size is returned via a separate query.

Lots of new GLX protocol and error semantics.

Pat worked through the issues list (see extension spec).

David and Kurt point out that there are problems doing the round-trip with compressed data and TexSubImage. It's actually a larger problem: since the formats are opaque, if the specified image size doesn't match the actual opaque image data, bad things will result. This turned into a very long discussion about validation and whether to mandate or allow error reporting if the actual image size is inconsistent with the specified size. If it's not checked, applications using direct renderers may become used to specifying a size of 0 and just passing the data block.

We suspended discussion at this point so David Blythe and others could report status on some outstanding extensions before David had to leave.

Outstanding Extension Status

State objects are kind of a typed display list. The number of fine-grained calls apps are making to specify state has been growing. There's a first cut of a spec put together, with examples for material and texture environment state objects; David will send this out on the participant's list, but wants to see more implementation experience.

Vertex array objects: started by looking at compiled vertex array, which is too vague. Desirable notions:

• locked memory that can be cached in accelerator or DMA-able (compiled vertex arrays)
• encapsulations of vertex array data (NV extension doesn't allow multiple sets of data)

Want one extension covering both. Will try and hammer out tonight at the meeting.

ARB_video_source - Jon reported that this didn't progress far for lack of a dmedia API. Intel believes dmedia and 3D integration is an up and coming area. Bill Clifford described Intel's interest in content creation "stuff" and their belief that it will push down to consumer level. Intel is putting together an ARB-like alliance to address this with OS-independent, platform-independent open standards.

Two meetings of interested parties held so far. Lots of problems to address. Bill showed block diagram slide (can we get a copy?). Dmedia API is at level of, and needs to integrate with OpenGL. Effort will be very OpenGL-centric. Needs to be extended for different types of compositing, addressing image quality, texturing quality, video data types (YUV), etc.

Post-meeting vertex array object discussion

Lots of discussion; high points:

• Multiple named array sets.
• Independently markable as immutable (e.g. cachable).
• Enable DMA (ability to place data into DMA-able memory).
• Need to be able to change some of the arrays while maintaining the others cached (partial cachability). Is it important to be able to change some of the pointers in a pool of locked arrays?

Just want to specify the objects - not define how the data in them is used (e.g. not incorporate compiled_vertex_array functionality).

How does this work when app wants to use texcoords in an array set, then later not use them? Should lock work on a per-array basis, or should it be possible to enable/disable individual arrays while locked?

Common usage pattern is static vertex coordinates, changing texture coordinates.

Thursday, March 16

ARB Extensions (continued)

ARB_texture_compression (cont.)

Issue 14 - hard to validate imageSize parameter in general (variable-length codings). Allow layered format-specific extensions to determine whether or not they can validate.

Jon pointed out that GLX client library may not be able to support the special treatment of compressed textures required by GetTexImage, since the client library doesn't have to know that the extension exists in order to advertise it (in the glXGetProcAddress scenario).

Summary of issues:

• Add GetCompressedTexImage call and GLX protocol, including imageSize.
• Add imageSize field to download calls.
• Querying TEXTURE_COMPRESSED_IMAGE_SIZE for uncompressed textures generates INVALID_OPERATION.
• Passing compressed formats to calls not accepting them (e.g. 2D compressed format for a 3D texture) generates INVALID_ENUM.

Some quality issues with conformance test. How do you specify allowed quality when the test iterates over unknown formats (layered on the base and exposed via the query)? The existing test is very loose; specific tests for layered format-specific extensions can be added too.

Related extensions:

• FXT1 extension proposed by 3Dfx - if other vendors are interested in this, it could be made into an EXT, and perhaps an ARB extension. Contact Paula if interested.
• S3TC extension proposed by Intel - subject to S3 licensing constraints.

Conformance Digression

Several people reiterated a desire for stronger (more precise) conformance tests, but nobody seems to have the bandwidth for this. Dr. Goldiez mentioned that research is going on in this area at UCF and that possibly they could do some of this work.

WGL_ARB_pixel_format (Paula)

Changes from yesterday circulated in updated document.

WGL_TRANSPARENT_INDEX -> WGL_TRANSPARENT_INDEX_VALUE to follow GLX notation.

Jon will update the extension template so extensions specify a "last substantially modified" Date instead of RCS strings that get trashed as specs move between companies and source trees and revision control systems.

WGL_ARB_extensions_string (Paula)

Changes from yesterday were circulated and approved.

WGL_ARB_make_current_read (Dale)

Changes:

• Name change to WGL_ARB_make_current_read. Status updated. Version / Date updated. Revision History updated.
• "Changes to Chapter 4" removed.
• Second para. under "Additions to the WGL Specification" added reference to "physical device".
• Bullet 1 - added INVALID_OPERATION for accumulation.
• Para. starting "Error Conditions" rewritten to add description of PopAttrib error behavior.
• ERROR_INCOMPATIBLE_DEVICE_ARB added.
• Dependencies updated from EXT -> ARB_extensions_string.

VOTE; 10Y/0A/0N, PASSES.

WGL_ARB_pbuffer (Dale)

Changes:

• Name change. Status updated. Version / Date updates. Revision History updated.
• Overview bullet 4 - modify "mode change" to "display mode change".
• Last para. in "Overview" should also allow pbuffer resources to be deallocated when a display mode change occurs.
• Add DECLARE_HANDLE(HPBUFFERARB) (or whatever correct spelling is) to "New Procedures and Functions".
• Removed OPTIMAL_PBUFFER_{WIDTH,HEIGHT} enums, and all references to them, to follow GLX 1.3.
• PBUFFER_DAMAGED -> PBUFFER_LOST.
• New para. following description of wglQueryPbufferARB on PBUFFER_LOST behavior.
• Dependencies updated from EXT -> ARB_extensions_string.

VOTE; 10Y/0A/0N, PASSES.

ARB_texture_compression

Pat circulated handwritten list of revisions.

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

ARB_point_parameters

Michael found more issues while cleaning this up; will do email vote next week.

Jon will update Participants website with final specs by next week.

New and Continuing ARB Extensions

ATI (Tom) wants to form a working group for vertex blending / skinning, based on their example ATI_vertex_blend (demos shown). James Bowman asked about type of weights - ATI spec supports only float/double, but small types (normalized unsigned byte) may also be of interest.

Tom also wants to build on EXT_texture_env_combine. At least 4 vendors are shipping this as an EXT today. To aggrandize this into an ARB extension, might make more orthogonal (remove some existing restrictions).

Paula wants a working group to extend pbuffers with "render to texture" semantics.

Blythe will lead vertex object working group.

State object working group is interesting, but Blythe probably won't be able to lead working group due to time constraints - should try and get someone else to do this.

ChrisF expressed some concern that most of the newer extensions are dealing with data movement and optimizations, rather than splashy visual features. This led to some discussion about "point solutions" vs. general programmable solutions and trying to predict the future and/or simplify what the spec looks like in a few years.

Conformance issues

• Conform script not Y2K compatible.
• Intel has miscellaneous proposed fixes.
• Sun handout w/3 proposed fixes: - C -> GL type corrections in ZeroBuf - Empty structure fix in glext.c

Changes all sound reasonable; Jon will update conform source once he has these changes and circulate for approval.

Spec issues

RasterPos doesn't have a secondary color. Dan, Bill, Dale, Bimal, ChrisF all have ideas on resolving the resulting unspecified fragment generation behavior. ChrisF will lead group to propose alternatives.

Pat observed that clamping after texture application isn't specified, which causes problems WRT texture_env_add. Straw poll showed strong support for clamping after each texture application stage. Michael will draft language to update core spec and multitexture appendix and bring back for comment.

Next Meeting

The next ARB meeting will be June 20-21 in the Raleigh area, hosted by NVIDIA.

3Dfx will host in California in September, and ATI will host in Orlando in December. Exact dates TBD.

Thanks to Intel for hosting this meeting!