Summary of Discussion Topics

• Fahrenheit Scene Graph Status
• ICD / SI Status
• Invariance
• Extensions
• Extension Registry
• Enum Clashes
• Extension Headers
• OpenGL Installation and Setup
• OpenGL History/Future
• Conformance
• Next Meeting

Tuesday, June 15

Fahrenheit Scene Graph Status

Although not really an ARB topic, Steve Wright reported on status of the joint SGI/Microsoft Fahrenheit Scene Graph project. FSG is in alpha at about 2 dozen sites. SGI is managing most of the alpha relationships. Alpha 2 update in mid-summer, beta in fall, shipping in early 2000. The beta program will involve about 100 ISVs.

With the recent Microsoft reorg, their OpenGL group has moved back into the NT group. Steve is looking for engineers to work on OpenGL.

ICD / SI Status

Ken Nicholson, who recently joined SGI as manager of the OpenGL Group, reported on schedules. The OpenGL 1.2 ICD is going to beta on July 1st; remaining work is putting the remainder of the imaging subset in. Expected to finish by SIGGRAPH. Microsoft can release a beta ICD kit to IHVs in about 3 weeks.

A potential holdup is the conformance test source code contributed by companies other than SGI. SGI needs copyright clearance before they can redistribute that code electronically, and Microsoft requires it before they can issue the final 1.2 ICD kit.

The ogl-win-{interest,support,announce} mailing lists for ICD licensees have seen very little traffic. One thread requested clarification of mode switching semantics.

Extensions

The texenv_combine extension has been shipping in ATI's driver for about a month, NVIDIA's driver for about a week.

Michael Gold reported that the proposed texenv_object extension, or the "state object" counterproposal by David Blythe, is still in process. He wants to resolve this before moving forward on future extensions for additional texture combiner modes.

Texture compression is also still in process. Michael suggested moving towards a format-neutral extension to avoid 3rd-party licensing issues. Rob asked about interest in finishing this - ATI, NVIDIA, Intel, Raycer, SGI.

John Dennis asked about extensions to expose surface information at API level for Windows - e.g. making host textures or draw/read pixels client data resident in AGP memory. Steve will look into reviving DirectDraw bindings document.

Demand seems to be for rendering into textures, not necessarily having data in host memory. Kurt suggests that we might add a "move" semantic which would allow repurposing a pbuffer style image to a texture and removing renderable semantics.

ChrisF asked about obtaining status of extensions - hard to do retroactively, but planned going forward with new extension templates.

John Dennis and Chris brought up KTX_buffer_region and related Autodesk extensions again. Some concern about ISVs convincing IHVs to support extensions by claiming "everyone else" is shipping it. IHVs need to treat such claims with scepticism, insist on a spec, and coordinate with each other in future cases.

KTX_buffer_region is also underspecified, and now other ISVs are starting to use it. Intergraph has an internal spec. Steve can have evangelism folks work on Kinetix to promote this to an EXT. Pbuffers appear to be a better longterm solution to the backing store problem that buffer_region addresses.

Concern about ARB_multitexture allowing a minimum of one multitexture unit. Should we change to two? Straw poll indicates that essentially everyone except IBM would support this, but there may not be strong enough feeling to make the change.

In retrospect, might have been wiser to separate the entry points as one extension, and the existence of more than 2 textures as a separate extension string.

Extension Registry

Add "how to get started" section for new developers.

For people not already licensees, list contact points at different vendors.

ChrisF, Michael Gold, Dale Kirkland, Dan Brokenshire, Bill Armstrong volunteer as contacts for new extensions. Might set up mail alias to forward to all of them?

John Dennis suggests that PC ISVs are reluctant to go to anyone other than "their vendor". Might just not list affiliations of contacts.

Are extension dependencies well understood? Old model was that extensions should address all interactions with lower-numbered extensions.

Issues in bringing extensions to a new platform: GLX protocol, GLX/WGL interactions, whether extensions are implementable under the "other OS". Conceptual points to address:

• buffer/surface interaction
• buffer memory space (e.g. AGP)
• context interaction
• client/server (e.g. remote rendering)

Should put a strong recommendation about anticipating platform issues on platforms you're not writing the extension for.

Notify arb-interest list again of draft registry location.

In writing specs, be more verbose - include more context. Perhaps recommend that both tables and paragraphs being changed be included in their entirety.

Should dependency list also say that extensions require that other extensions not be implemented?

Enum Clashes

Should push enum registry out to the website on a continual basis as it's updated at SGI.

Would be nice to have a complete enum list, but probably impractical.

Extension Headers

Four possibilities

• In gl.h (not practical; system component)
• In glEXT.h (must be centrally located)
• In vendor-specific header files
• In extension-specific header files

Might add the interface to the extension template.

Dale and Michael are interested in helping out with maintaining a global header file on opengl.org.

OpenGL Installation and Setup

GLSetup was recently released, solving a problem (getting the right Win9x OpenGL drivers) and creating a problem (crashing servers hosting GLSetup due to high traffic).

This might be solving a short-term need (drivers new enough to work with the app), with better drivers becoming widespread.

Ken Nicholson wondered about longterm maintenance of GLSetup - is this something that someone other than Definition 6 might pick up? Or similar utility for other platforms?

Michael suggests a "how do I get OpenGL on my system" page on opengl.org. Address different Windows 9x/NT issues, legacy drivers like 3dfx non-ICD, etc.

Steve Wright suggested that several different technology paths might solve the longterm problem, and that opengl.org should be prepared to pick up GLSetup if Chris Hecker drops it for some reason. "Windows Update" web site might provide a central source for updating drivers and solve this problem, too.

OpenGL History/Future

Development effort began in 1989. Experience of trying to write a spec for IrisGL evolved to OpenGL.

Kurt has notes on things that were done well and poorly. In this context, where should we go? OpenGL 2.0? Initially planned not to, but 10 years has passed.

Good Stuff

• Specification is good
  Defined error semantics
  Agreeing that OpenGL isn't pixel-exact (geometry processing using different FP formats)
• Designing for orthogonality (functions are as separate as possible - operations on vertices, operations on pixels).
  • Formalizing notion of rasterization converting whatever the input is to fragments.
  • Didn't draw block diagram to place equal emphasis on pixels and geometry.
  • Thought through images, geometry, and their interactions at the start. Textures were cleanly integrated.
  • Consequence is that OpenGL can be treated as an instruction set, as shown by:
    Lots of research and algorithms - recent 3DI and SIGGRAPH papers.
    Lots of interesting multipass apps; games, visual simulation.
    However, invariance isn't treated as rigorously as it might be.
• Window-system independent design
• Concentrated on a procedural interface, not scene graph library (took much longer to standardize higher levels built on OpenGL than anyone thought)
• Cleanups
  Everything queryable
  Everything settable both in dlist and immediate mode
  Consistent syntax (still a few bobbles)
• Requiring that implementations be complete. But:
  Don't know performance of features
  Outside of frame buffer resource issues - destination alpha, etc.
• Extensibility (for implementers, not apps) breaks completeness, but overall has been critical to success. Kurt thinks that extensibility is as core to OpenGL as other qualities.
• Dealing with endianness.

Bad Stuff

• Eliminating objects, trying to use display lists as the only encapsulation method for bundles of state changes, network problems, etc. Some objects need persistance across modification, particularly textures - too big to recreate all state when changing it. Editing was specifically left out of dlists, so texture objects had to be created. Didn't work out as planned.
• Saying what you mean vs. what you want. E.g. no means to turn off transformation other than implicit (set matrix to identity). Implying what you want this way means there's no way to know if the implementation will recognize the fast path. Probably not many implementations indicate what the fast paths are.
• Memory management isn't explicit enough. E.g. textures have lots of machinery (priorities, proxies) to avoid knowing what the actual limits are - but proxies can't deal with storage allocation spanning more than one API call.
• If we were to redo, OpenGL might enforce notion of a 1D texture allocation paradigm.
• Small stuff:
  ColorMaterial is unnecessarily complex and obtuse.
  Texture borders. More reasonable default edge filters.
  Normal transformation - making a 4x4 matrix meaningful.

Others mentioned by attendees:

• Dale - Evaluators affecting current state, trim curves.
• Bimal - Edge flags.
• ChrisF - Specification of default state for everything causes some of these issues.
• John Dennis - Explosion of vertex formats (Kurt isn't sure about this, or about finegrained calls).
• Would explicit context parameters be useful for multithreaded apps? Kurt isn't sure.
• Bimal - can't query hardware accelerated paths from the app.
• Andy V - polygon antialiasing; sorting; FTB vs. BTF rendering. Hard enough to use that it won't be commonly used. Painful for implementations, so it isn't done as often as we'd like.
• Dale - merging of specular lighting component prior to texture (prior to OpenGL 1.2) [but requires separate interpolator]
• John D - synchronization; getting ISVs to understand and respect Finish() and Flush(); interacting properly with environment (swap stuff); pixel move/copy operations which are defined sequentially but may operate on asynchronous hardware.
• Dale - Color index mode.
• Bimal - Texture mapping applies to both pixel and geometry path. Apps must remember to enable/disable.
• Brian Paul - Mesa has non-transformed RasterPos extension.
• Jon L - Underspecified internal operation precision in pixel path.
• ChrisF - Artificial binding of fog to eyespace.

How to Move Forward

• ChrisF thinks we're not moving as fast as D3D - what can we do to address this?
• Jon L - geometry operation state machine?
• Bimal - curved surfaces, other high-order primitives
• John D - OpenGL codified best of existing practice. Should we look at this for 2.0 instead of trying to anticipate hardware?
• Mahesh - emergence of extensions causes defacto "subsetting". Should we standardize on sets of these?
• Jon L - PixelFlow badly broke OpenGL in 3 ways - per-pixel deferred shading, region architecture, image composition. PowerVR has the problem to lesser degree. Should we try and support such variant architectures?
• John D - OpenGL just doesn't map onto some architectures. What problems are we trying to solve? Better access to existing hardware model, or defining an abstract interface?
• ChrisF - OpenGL picked a direction and pushed it.
• Andy V - might for example not require that OpenGL have a depth buffer, to support tiled architectures.
• Dale - lack of multiple depth/accum/etc. buffers impacts stereo rendering.
• Jon L - is texture filtering overspecified? Is trilinear interpolation relevant in a world of 16-tap anisotropic filtering?
• Kurt - should filtering be as explicit as it is?
• Kurt - emerging theme is that 2.0 shouldn't be fundamentally different, but should leave some stuff behind.
• ChrisF - would rather shoot for the future and hit 50%, than codify existing practice.
• Ken Cameron - have fundamental CPU / bandwidth / rasterization balances changed such that we should reassess? Parallelism is much more prevalent.
• ChrisF - stratification is unavoidable. E.g. small screens will care a lot about antialiasing, big screens may not. Subsetting or stratification heuristic will help cover range of platforms.
• Dale - requiring extensions be shipped and tested before going into spec was a good idea.
• Jon L - OpenGL user base has changed dramatically even as the API has not.
• John D - ARB has been very engineering-oriented. How would OpenGL have differed had a more time-to-market group been running things?
• Dale - another success was splitting OPC and ARB.
• John D - influx of very proprietary organizations is threatening. ARB has moved from being a cooperative body to one composed more of individual entities concerned about their competitive position. Important to recognize and manage this.
• ChrisF - function of size of companies. Larger companies aren't adopting aggressive IP strategies / aggressive IPO strategies so much.

Multitexture

The sense of the meeting is that ARB_multitexture should be changed to enforce a minimum of two texture units if the extension is supported. Jon will send out an updated spec for evaluation.

Conformance

General issue: make sure RasterPos is drawing pixels in the exact needed locations - probably bias by .5 from integer coordinates.

mustpass.c

• Need to strip out comments that ignore ERROR returns and debug printfs
• SpecularColorTestColor runs the last two pixel tests on interpolated values, which is very hard to verify because of interpolation rule laxness. Would like to test that two interpolators really do exist.
• Bimal suggests that POINTS and LINES vertices may not guarantee landing on specific XY coordinates. Either bias vertex coordinates to pixel centers, or draw multiple adjacent primitives to ensure coverage. Make texture 2x2 texels.
• Mark specular test for review and move on. E&S and SGI will handle.
• DrawElements test should work in CI mode. Add call from MustpassExec and add glIndex(1) for primitive color in index mode.
• RescaleNormal test has a bunch of loop invariants for setting AMBIENT etc. material properties which should be pulled outside the loop. Also clips the primitive, which shouldn't be done so we aren't testing two features at once. IBM will handle this and resubmit test.
• Texture3D is setting TEXTURE_2D parameters in Texture2DSetup. Drop scale TEXTURE matrix test.
• After much abstract discussion of conformance test history and principles, voted 7:3 to move EdgeClamp and LOD test from mustpass to conform.
• Add all packed pixel formats to PackedPixels test. Also need to do the right thing to guarantee pixel exactness (RasterPos coordinates may be off).
• Bimal will take up texture coordinate selection for TextureLOD on arb mailing list.

ARB_imaging mustpass tests

• May want to opt out for too-shallow visuals.
• Dale suggests using integer source formats for ColorTable as more representative of actual use, but doesn't feel strongly about it.
• Pixel path operation precision is unknown and essentially uncomputable; however, 2.5 * color.epsilon accuracy seems loose enough.
• MinMax needs to add a test that min strictly < max.
• BlendColor should change to actually test blending, by making both clear and polygon color be 0.5 intensity and testing same result.
• BlendEquation needs to check that frame buffer clear actually cleared to black or white respectively prior to drawing the polygon.

Conform tests

shell.c needs to use GL_ARB_imaging and GL_ARB_multitexture instead of ARB_imaging and ARB_multitexture.

Michael proposes making wrapper code for calling extensions live in the platform-dependent section of ctk. Entry points would actually be defined in ctk, call wglGetProcAddress or equivalent, etc. Function pointers would be cached away in dispatch table, buffer., or similar location.

Testlist structure in tests.c will call tests even if they are noops because e.g. ARB_multitexture isn't supported. Michael proposes adding a new return code for Exec routines to indicate that the routine is not supported, so that the conform.x printout doesn't say an extension passes even though it isn't actually running the test.

Remaining test proposals will be finalized online.

Next Meeting

SGI suggested they host the next ARB meeting near Mountain View, CA, Tue-Wed, September 14-15 1999. Subject to discussion with volunteers.

Thanks to ATI for hosting this meeting!