GLU 1.3 Discusion

Discussion of possible additions to GLU to go with OpenGL 1.2. There were three suggestions: promoting the nurbs_tesselator and object_space_tess GLU extensions to the core, adding a gluBuild3DMipmaps function to go with the new 3D texturing capabilities, and supporting the new packed pixel types in all gluBuildxDMipmaps calls. A straw poll showed majority support for all three. A decisive vote will be held by email after the ARB meeting.

Magician is available free for personal use; educational and commercial runtime licenses are available, as are source licenses.

David Yu pointed out that there are two parts to OpenGL bindings: core library bindings and window management/utility library classes. The ARB might be more interested in standardizing the core bindings as a first step.

SGI's Java bindings went a different direction with respect to window system bindings (more like GLX/WGL), but the API bindings are close to Magician.

Alligator said that API bindings were only a few days work, while window system work was much more complex. He thinks Sun JDK 1.2 work doesn't support enough Java implementations (Microsoft is incompatible, and 1.2 is at best going to ship at end of summer '98).

Most Magician users are Windows-based (96% of downloads). There's still value in a portable standard; can consider window system bindings separately.

Sun wants to see a proposal for the core bindings and a separate (later) proposal for window system bindings. They suggest forming an ARB subgroup to develop these proposals. Who other than ARB members should be involved in such a proposal?

IBM thinks that, in the absence of standard Java windowing interfaces, we shouldn't proceed with the high-level bindings. Sun suggests establishing a second working group for this purpose.

SGI agreed to establish a Java interest subgroup. The javagl@postofc.corp.sgi.com mailing list has been created for this purpose. You can add yourself to the list by sending a message containing
subscribe javagl
to external-majordomo@postofc.corp.sgi.com

EXT_multitexture is the first candidate. Rendition thinks EXT_texture_env can be easily extended for vendor-specific capabilities.

Raycer is concerned about virtualizing texture chains. Is the MAX_TEXTURES query adequate? Do you return the minimum or maximum number of units supported depending on the environment state?

Several types of proxy queries may be relevant: proxy for multiple simultaneously resident textures, proxy for whether a texture chain is supported.

AreTexturesResident doesn't answer the right question for multiple texture images (e.g. whether they're all simultaneously available for texturing). Matt Papakipos thinks that image proxy queries must return the conservative answer: TRUE iff MAX_TEXTURES images of this size can be supported.

Matt P. wants to move for a vote today. Very little support for this; 3dfx wants to hold vote by email. IBM feels strongly that proxy issue needs to be addressed.

Kurt Akeley talked about the background of multitexture. Proxies were not put into the original SGIS_multitexture spec; really hard problem. Should be solved, but too complicated for now.

Will try to hold a vote on ARB_multitexture tomorrow.

Very brief discussion (only mentioning the names as a reminder, really) of other extension specs which may soon be candidates as ARB extensions. SGI will send the location of some of these to the opengl-arb-interest list. Potential candidates include fragment lighting, Blinn-style bump mapping, point parameters, fog coordinate, secondary color.

PixelFusion is interested in driving some of these to completion, particularly EXT_scene_marker. They'll try to form a subgroup to discuss it.

For all tests, state which paths are tested (e.g. should be enabled).

Chris Frazier, who was involved in initial development of the conformance suite, discussed the purpose of the "mustpass" tests.

Rendition & Nvidia both observed that texdecal.c assumes that texture component resolution >= frame buffer component resolution, which is often not the case. This needs to be looked at.

Comments on individual tests:

• DrawRangeElements - Add mustpass.c test that draws a primitive with both DrawElements and DrawRangeElements, and makes sure it got drawn.

• Blend Color/BlendEquation - Use a non-random blend color (partially saturated?)

  Currently specified tests are really both "conform". For mustpass tests:

  • BlendColor - draw black polygon against a white constant color and make sure some blending occurred.
  • Blend Equation - draw with FUNC_MIN, black source/white dest and white source/black dest.

• Color Matrix - Change existing test to be part of mustpass.c, not a conform-style test.

  Bimal proposes adding a new mustpass test which draws small images repeatedly while shifting matrix components (1->0, 0->1) and checking the results each time. Bill Armstrong wants to test negative matrix components too, since they're allowed. Base on existing color.c.

• Texture3D -

  Use a smaller window.

  Disable dithering.

  Extend mipsel.c (or clone it) to work with 16^3 3D textures.

  Chris Frazier suggests adding a conform test which uses the alpha test - one side red with 0 alpha, one side green with 1 alpha. Then flip texture matrix (or flip sense of the blend test) and repeat. Use a reference value of 0.5 (greater or less).

• Color Table -

  Disable dithering.

  Compare only to within 2.5 shades to allow for precision loss in several places

  Opt out for too-shallow visuals.

  Currently specified tests are all "conform". For mustpass tests, setup a reverse linear ramp color table. Draw a linear ramp image. Check that last pixels are <= 1/2, first pixels are >= 1/2.

• Convolution -

  Chris Frazier recommends a larger image size.

  Uses REDUCE border mode (default).

  Need to take discussion of allowed precision & range offline.

  Currently specified tests are all "conform". For mustpass tests:

  • Use test 2, but with only second filter and with simplified image.
  • Also test that CopyPixels isn't implemented as Read followed by Draw, to make sure convolution doesn't happen twice.

• Convolution Border Modes -

  Need to remove IGNORE_BORDER mode, since it didn't go into OpenGL 1.2.

  Several comments which Jack Middleton recorded and will incorporate into the test proposal.

• Histogram -

  Disable dithering.

  Need to take discussion of allowed precision & range/error bounds offline.

  Currently specified tests are all "conform". Need to do a mustpass test.

• Minmax -

  Could use fully saturated colors in test image.

  Currently specified tests are all "conform". Need to do a mustpass test.

Tuesday, June 23

Procedural Issues

The ARB is interested in adding new members to represent the new PC IHV community. There's concern about the committee getting too big to make progress, and it's not clear how to do this in a way that's fair to the large number of IHVs.

To begin with, we need to clearly articulate the criteria for adding new members. SGI will do this by the next meeting, and propose ~2 IHVs as candidates for membership, to be voted on by the entire ARB.

The next meeting will be hosted by Nvidia in Sunnyvale, CA in September. Probably 9/15-9/16 (moving to Tue-Wed so people don't have to travel on a weekend).

For the following meeting, both S3 (Bay Area) and Metrolink (Orlando) have volunteered to host. We'll decide later.

Status update - Mark Kilgard is indeed working on a new release of GLUT (3.7). It's currently in beta, should be out soon.

Dale Kirkland asks where to send bug reports on the sample codes from the Addison-Wesley "Red Book". Use opengl-redbook@sgi.com.

Matt Papakipos presented his proposal. Chris Frazier observed that we need to rev the conformance tests to allow for ARB extension tests. This runs into problems with Microsoft licensees, who do not submit conformance results to SGI, and who rely on Microsoft for conformance test updates.

Some Windows licensees may not currently have conformance source access, but MS will ship source as part of the 1.1 DDK.

• Packed Pixels - should add a ReadPixels test as well.

• BGRA Pixel Formats - this again raised the issue of whether we modify the existing tests or add new OpenGL 1.2 specific tests. To be decided in process of writing the code for the tests.

• Rescale Normal - several comments from Chris Frazier to IBM, recorded by them as the proposal authors.

• Separate Specular Color - several comments from Chris Frazier to Evans and Sutherland, recorded by them as the proposal authors.

• Texture Edge Clamping -

  Bimal Poddar suggests testing 2D and 3D textures separately, with the expectation that 2D textures will be hardware accelerated on many platforms while 3D textures will not.

  • Specify LINEAR filter.
  • Make texture body some color (green?).
  • Sample only at midpoint of edges.
  • Use texture border color either instead of, or in addition to border texels.

• Texture LOD -
  • Use NEAREST filter.
  • Error bounds are tricky. Can we assure that specified mipmap levels are chosen?
  • Nvidia is concerned about interaction with anisotropic filtering, e.g. implementations that only do center weighted filters (32 samples mentioned) on a single level rather than linear combination of levels.
  • Bimal suggests using current mipsel.c and making sure you never exceed the range defined by BASE/MAX level and MIN/MAX lod. This finesses issues of sloppy LOD computation and strange default filters.
  • mipsel.c actually only uses 7 mipmap levels, though the documentation says 8. This should be reflected in the new conformance proposal.

GLX 1.3

Windows-only licensees left at this point, with the understanding that if the Unix licensees agreed on GLX 1.3, they would rubber-stamp the decision (since the bylaws require unanimous approval of specification revisions, but GLX is Unix-specific).

Jon Leech summarized changes between the May and June drafts, then the group discussed and resolved remaining issues:

Pg. 18: Specify that GLX_DONT_CARE is not allowed for GLX_LEVEL [negative levels specify underlay planes in some implementations].

Pp. 18-19: remove comments about "with precedence given to to larger/smaller values..." and "when the value is not specified or if it is specified as..."

Pg. 20: Change "Selection Critera" to "Selection and Sorting Critera". Remove "ignored" rows from the table.

Pg. 22: Remove GLX_BAD_FBCONFIG error return from glXGetFBConfigAttrib (actually, it's not there in the present draft).

Pg. 32: Remove GLX_BAD_CONTEXT error return from glXQueryContext. Instead, specify that a GLXBadContext error may be generated (if round trip to server is involved and ctx is invalid).

Throughout: strike all references to OPTIMAL_PBUFFER_{WIDTH,HEIGHT}, since we haven't defined that behavior very well.

Pbuffer clobber events vs. windows: windows don't generate these events when clobbering each other's ancillary buffers (just standard X damage events). Pbuffers may clobber window ancillary buffers, but will only ever cause GLX_SAVED PbufferClobberEvents when (temporarily) clobbering the ancillary buffers.

Pg. 22: remove GLX_PRESERVED_CONTENTS attribute from glXCreateWindow - now has an attribute list which must (currently) be empty.

Pg. 11: Move first sentence following PbufferClobberEvent struct definition on page 34 to the definition of the GLXPbufferClobber event in section 3.2.

Add GLX_FBCONFIG_ID attribute to table 3.7 on page 38; remove glXGetFBConfigFromVisual on page 22. Add GLX_VISUAL_ID attribute to table 3.1 on page 14. We need to make sure GLX_VISUAL_ID gets added to protocol spec.

Pg. 50: Change to "Each version of GLX supports all versions of OpenGL up to the version shown in table 6.1 corresponding to the given GLX version."

Assign a different opcode for DestroyGLXPixmap and DestroyPixmap to make sure we can distinguish them on the server.

All of Kurt's edits for typos accepted without comment.

Document that table 3.3 may also return GLX_NONE for an FBConfig which doesn't support rendering to windows.

Section 3.4.2 and later: change "X is identical to Y" to "X is equivalent to Y(...GetFBConfigFromVisual(visual))"

Pg. 30: Enumerate cases where the draw drawable is destroyed and what happens (e.g. if the core X11 Window is destroyed, GLX window remains valid - like rendering to the NULL clip, values read back are undefined. Return BadWindow error the next time the GLX window is made current or passed to SwapBuffers.

Pg. 26: Similar clarification on what happens when a pbuffer is damaged - change "effect is undefined" to "effect is the same as if the pbuffer were destroyed".

Vote: all Unix ARB members (HP, DEC, IBM, SGI) in favor. Windows-only ARB members will be polled by email, but for practical purposes, GLX 1.3 is approved modulo the changes discussed in the meeting.