OpenGL ARB (Spring) Meeting May 15-16, 1995 Perdido Beach Resort, Orange Beach, AL (Revision 2) Attendees --------- Fred Fisher Accel Graphics fred_fisher@ag3d.com Hock Lee Microsoft hockl@microsoft.com Linas Vepstas IBM linas@austin.ibm.com Dale Kirkland Intergraph kirkland@ingr.com Ken Garnett NCD keg@ncd.com Bruce D'Amora GE Medical Systems damorab@med.ge.com Bimal Poddar IBM poddar@austin.ibm.com Kurt Akeley SGI kurt@sgi.com Jim Cobb E&S jcobb@es.com John Dennis DEC jdennis@eng.pko.dec.com Chris Frazier SGI frazier@sgi.com Paula Womack SGI womack@sgi.com Randi Rost HP rost@tortola.fc.hp.com Alberto Savoia Sun Labs alberto.savoia@eng.sun.com Igor Sinyak Intel igor_sinyak@ccm11.sc.intel.com Phil Huxley 3D Labs phil.huxley@3dlabs.com Henri Warren Megatek warren@megatek.com Steve Wright Microsoft swright@microsoft.com David Higgins IBM dwh@austin.ibm.com ARB Membership -------------- Next meeting will be the fifth one for E&S and Intergraph. Need to meet tomorrow early to discuss whether they should become permanent members. Current permanent members should arrive at 8:30 and others should arrive at 9 p.m. OpenGL Bugs, Typos, Clarifications ---------------------------------- In the never-ending quest to perfect the OpenGL spec, man pages, and conformance tests, :-) Chris Frazier handed out a list of typos, clarifications, and additions and we proceeded through it. Some highlights: Corollary 18 was added to the OpenGL spec: "GL state continues to be modified in FEEDBACK mode and in SELECT mode. The contents of the framebuffer are not modified." Corollary 19 was added to the OpenGL spec: "Evaluator colors generated with GL_MAP2_COLOR or GL_MAP1_COLOR do not affect the current color. This means that ColorMaterial cannot transmit these colors into the lighting equation." In the man page for glXCreateGLXPixmap, it says "Direct rendering contexts cannot be used to render into GLX pixmaps." This was modified to say "Some implementations may not support GLX pixmaps with direct rendering contexts." In the man page for glGet, the constant GL_NAME_STACK_DEPTH is defined "params returns one value, the number of names on the selection name stack. See glPushMatrix." glPushMatrix is changed to glPushName. As a result of incorporating the visual info extension into the sample implementation, a number of conformance test failures occurred. This is because the visual info extension defines support for RGBA rendering into visuals that have >0 bits of red and zero bits of green and blue. The conformance tests had some incorrect assumptions of the form "if the visual supports RGBA rendering and red bits is >0, then green bits and blue bits must also be >0." The ARB voted to modify the conformance tests to fix these problems. OpenGL Test Suite ----------------- Alberto updated the ARB on his proposal for doing automated testing for OpenGL. Feedback from the last meeting was that there was good interest from the companies represented, but there was concern about the number of test cases and the applicability of the testing methodology to OpenGL. The effort to develop an OpenGL test suite is called OGLE. ADL - Assertion Definition Language - would be used to develop a formal specification for the OpenGL API, and this could be combined with some high level test description files to automatically generate a thorough test suite. ADLT is available via ftp - "world's most powerful test generator". This group at Sun is also working on a test suite for PIKS. Alberto's group spent a couple of man weeks, including some OpenGL learning curve, to develop a partial test suite for OpenGL. A sanity test for all of OpenGL was developed by a graduate student in less then a day. Developing tests for non-graphical functions (e.g., state-setting commands) was also found to be straightforward and easy. Some examples were shown to illustrate that simple graphical functions (e.g., glScissor) could be easily tested. For a more complex example, glDrawPixels was used. Alberto described some results from other research showing that it isn't really helpful to test all combinations of all parameters for a routine with more than two parameters. To test all possible combinations of input values for glDrawPixels would require 10^24 tests. It's been shown that 1-way testing (varying just one of the input parameters) finds 80% of the bugs, and 2-way testing (varying two parameters together) finds 98% of the bugs, so it doesn't really pay to vary all parameters simultaneously. Limiting testing to 2-way testing would cut down the number of test cases immensely. Sun Labs is willing to commit $300K to developing a complete OpenGL test suite. To develop a very thorough OpenGL test suite, the estimated cost of the project is about $600K. Alberto would like to get up to six OpenGL licensees to contribute $50K each in order to completely fund the project. Sun Labs is not doing this to make money, but to promote the use of ADL. To do this in the schedule proposed, Sun Labs would staff this project and make it happen (i.e., they would want the money, not the warm bodies). SIGGRAPH Marketing Efforts -------------------------- Mason is putting together some things for SIGGRAPH: more T-shirts (similar to previous ones with licensees on the front of the shirt and ISVs on the back - ISV list is needed by June 15); show description for SIGGRAPH (needs booth number, 25-word description of company, and artwork for logo - Mason will alphabetize vendor names this year); there will be an OpenGL SIG this year, also two SIGGRAPH courses - OpenGL for beginners and OpenGL/X programming. Anyone with issues for SIGGRAPH marketing should contact Mason Woo ASAP. If anyone is interested in showing an NCD terminal in their booth running a technology demo of OpenGL, they should contact Ken Garnett (keg@ncd.com). OpenGL Sample Implementation ---------------------------- Next sample OpenGL release is coming out in mid-June. Things in this release: Ada bindings GLS stuff (GL stream stuff - some documentation, ability to encode and decode OpenGL streams) GLU 1.2 (already out on sgiblab) A slew of extensions: all the blending extensions texture object texture polygon offset visual rating visual info transparent pixel folded into visual info import context (allows sharing GLXcontexts between clients) The Ada bindings were defined to conform to the Ada '83 specification, which allows them to be used by both Ada '83 and Ada '95 applications. The Ada bindings for OpenGL do not take advantage of the stronger type checking in Ada. It was decided that the Ada bindings will not do any stronger type checking than currently defined in the OpenGL C API. There won't be any compiler dependencies in the Ada bindings. There are some system dependencies when implementing the Ada bindings for Ada '83 (e.g., how to handle strings). However, portable bindings can be provided for Ada '95 compilers because Ada '95 provides a C interface file. The bindings will be the same for Ada '83 and Ada '95, but the implementation of the bindings will probably be different. The GL bindings will be in a separate package from the GLU bindings to allow applications to forego using GLU if they so choose. OpenGL as an Imaging API ------------------------ Bruce D'Amora from GE Medical Systems talked to the group about the type of work being being done at GEMS. Their 2D application is called Advantage Windows and their 3D application is called VoxTool. The GEMS development team in Milwaukee is trying to develop a level of middleware that supports graphics, imaging, and video. They thought that OpenGL would be a good base for developing this middleware layer. OpenGL could provide acceleration for things that are currently unaccelerated (they use X on Sun platforms). The extensions that GEMS considers current requirements: texture3D - used in volume rendering apps that allow user to specify cut planes (multiplanar reformatting) texture_object - texture objects preferred over display lists pbuffer - offscreen memory is important for window/level and convolution operations blend_minmax - used as the basis for maximum intensity projection (MIP) rendering convolution - frequently used image processing filter subtexture - certain algorithms preprocess the volume into different size subvolumes that may be stored in non-contiguous memory texture - LUMINANCE16 can be used for loading images into texture memory The extensions that GEMS considers future requirements: blend_subtract - possibly used to segment certain features of scanned volume histogram - certain segmentation techniques may require analysis of histogram distributions cmyk - color management system for matching screen to printer color swap_control - might provide greater control over cine loop rates texture_filter4 - would like to specify higher order filters video_source - support applications that merge video of operation in progress with previously scanned MR data video_zoom - used with video source Possible extension proposals: Ability to load list of textures that reside in non-contiguous memory locations Texture support for non-RGB visual types since CT/MR data is usually 16-bit FFT and FFT-1 As an aside, Siemens sent mail to Mason, which Paula also shared. Their high priority extensions are: blending extensions convolution histogram visual info Lower priority for Siemens are: copy texture texture object video sync pbuffer Paula has provided the mail (from Lawrence Tarbox of Siemens) for inclusion in the minutes: > We are interested in basing an medical image processing library on top > of OpenGL. OpenGL would serve as the hardware independent interface to > (potentially) a variety of accelerators. Paramount is the ability to > do motion picture displays (cine loops) of sets of images, possibly > with interpolation (zoom), image subtraction and spatial filtering > (i.e., convolution) on the fly. (Actually, SGI has a demo similar to > the types of things I'm interested in that runs on a Reality Engine.) > > It seems that OpenGL with certain of the proposed extensions is a > strong candidate for a hardware independent interface. The extensions > in particular that we are interested in are: > > EXT_blend_color > EXT_blend_logic_op > EXT_blend_minmax > EXT_blend_subtract > EXT_convolution > EXT_histogram > EXT_visual_info > > The following extensions may also be of interest, but much less so than > the previous (their availability might simplify implementation of > certain functions, but until we work out a more complete design, > we can't be sure): > > EXT_copy_texture > EXT_texture_object > SGIX_pbuffer > SGI_video_sync > > The 3D texture extensions are also of interest to the medical imaging > community for volume visualization. Bruce posed the question to attendees, "What are your plans with respect to imaging in OpenGL and do you think OpenGL is a reasonable start for an imaging API?" There was general consensus that OpenGL did go a long way toward providing a reasonable imaging API. Several vendors did say that they did not plan to offer extensions that supported capabilities that they did not accelerate. What Goes Into OpenGL V1.1? --------------------------- Brainstorming on OpenGL V1.1 ensued. Paula wrote the list on the board that we had arrived at last meeting: OpenGL V1.1 GLX V1.2 High confidence Support OGL 1.1 vertex array visual rating texture object visual info blend logic op rescale normal new: import context polygon offset make current read Low confidence copy texture subtexture texture imaging? Issues Should we consider blend_minmax, blend_color, blend_subtract? What is the criteria for acceptance? practicality on existing hardware proof of concept on more than one platform timeliness customer pull is understood Should we consider lit texture from E&S? Should we consider the packed pixel extension? Should anything in low confidence bucket be moved to high? Or vice versa? Microsoft and Intergraph have customers using the vertex array extension Intergraph has customers using the texture object extension SGI has customers using the blend logic ops extension SGI has customers using the polygon offset extension Normal Scale ------------ Is the normal scale a worthy extension? The API has some issues...what happens if the user passes non-unit normals? It was defined for performance reasons, but SGI implemented it and found very little performance benefit. The one customer that wanted this (computational chemistry) has found a workaround. But others argued that this is fundamentally wrong in OpenGL and should be fixed. No one has yet shipped this in a product, though it has been implemented by two vendors. Straw Poll: Who wants to see rescale normal in OpenGL V1.1? (Every company present gets one vote) In: 4 Out: 5 Abstain: 2 Polygon Offset -------------- Polygon offset was designed to allow primitives like points and lines to be correctly drawn on top of area-filling primitives like triangles. Part of the problem is caused by the fact that lines are sampled incorrectly. You could solve this problem in another way by drawing lines as two triangles, which the Reality Engine does, but it wasn't thought to be a reasonable expectation to require this type of rendering in order to get correct results. The main argument against incorporating this extension in OpenGL V1.1 was that you end up writing incorrect z values in the frame buffer. "It's a mistake to apply a hack to a topological problem." You also need to eliminate backfacing polygons or you can have mistakes near the silhouette edges. What are the uses for polygon offset? It can be used to draw coplanar polygons, edges on top of polygons, or shadows. If you want to avoid self-shadowing, you have to move the shadow away from the surface that created it. And the amount you have to move it is proportional to the slope of the depth. The reason polygon offset was applied only in FILL mode was that it allowed a program to draw its whole scene with no mode changes if you draw all the surface first and then draw the lines and points next. Kurt proposed modifying the extension to also apply to polygons drawn in POINT and LINE mode. Who wants to see polygon offset in OpenGL V1.1? In: 8 Out: 1 Abstain: 2 Kurt will investigate applying polygon offset to polygons in LINE mode as well. One proposal was to have the API affect POINT, LINE, and FILL mode. This could break compatibility for existing applications that might depend on the fact that polygon offset does not apply to LINE and FILL modes. Another alternative is to enable polygon offset independently for FILL mode and LINE mode. Kurt will make a recommendation. Vertex Array ------------ One issue with the vertex array is that it has client side state (array enables) that forces checking of glEnable calls (the vertex array enables are client-side state, so cannot be stored in display lists). It would be better if the enables for this extension were defined as new entry points rather than being lumped in with glEnable/glDisable. Also, if people were interested in this extension for DMA purposes it might not be spec'ed correctly. In order to see whether the data is interleaved, some checking must be done every time to see if the data is contiguous. This checking can be awkward to implement. Another issue is that vertex attributes like color and normal must be shared when the vertex data is shared. What are the benefits of this extension? can be used to specify data for DMA transfer regularizes the data reduces subroutine call overhead makes the data more like a display list sharing vertex data can be used to specify all of the data for a specific vertex in a single call A straw poll showed that most vendors felt the two biggest benefits to this extension were the reduction in subroutine call overhead and the fact that the data was provided in a more regular form. In: 10 Out: 0 Abstain: 1 There was a desire to investigate an addition to the spec to support an array of vertex indices. Texture Object -------------- One issue with texture object is that people don't realize that texture object is different from texture environment. Kurt thinks that where we're moving is to allow multiple textures to be applied to geometry (e.g., a diffuse reflection texture, an environment texture, and a "roughness" texture). These textures should stand alone, and some other state (texture environment) will be used to determine how to combine the textures and the geometry. Therefore it would be a mistake in the short term to combine the notions "here's a texture" and "here are the rules for applying it to some geometry", even though this is what most applications will typically think of doing. In: 11 Out: 0 Abstain: 1 Blend Logic Op -------------- The blend logic op extension has been implemented by a couple of vendors. In: 10 Out: 0 Abstain: 2 Visual Rating ------------- The visual rating extension proposes three categories of visuals: good, bad, and ugly (ugly is worse than bad). The third category allows implementors to provide a set of capabilities to a small, select audience without having the general population trip over it. A comment was made that this is one extension that would benefit from an implementation and real field usage. *Please* provide suggestions for different names. In: 7 Out: 0 Abstain: 5 Import Context -------------- This is a pretty new extension proposed by SGI. It solves a couple of issues when an application is working with a library that shields you from making direct calls to GLX routines. The import context extension contains two things. It provides a way to query the display associated with a rendering context. It also provides a way for two process to share an indirect rendering context (except that client-side state is not shared). OpenGL says you can query any state that you can set, but GLX doesn't let you do this. Perhaps we should also consider adding queries to obtain the visual info structure and the list of shared display lists. In: 3 Out: 1 Abstain: 5 Make Current Read ----------------- The make current read extension was explained. Some customers complain about the strict definition of similarity between visuals. This extension allows you to define one drawable to be the source of read pixel operations and another to be the destination for writing pixels, and thus transfer pixel values within the framebuffer without dragging the pixels through the application's address space. A couple of people thought that this extension would be a good candidate for implementation and experimentation before it's included in OpenGL. There was some concern about maintaining the necessary window state for a second drawable that is associated with a rendering context. This has been implemented by SGI, but "we had to hack the kernel a little bit" to get it to work. In: 0 Out: 6 Abstain: 5 Visual Info ----------- Visual info extension now includes transparent pixel stuff. Might be nice to have a "don't care" visual type. Concern is that existing software has built into it that if RGBA is true, then they will expect either a TrueColor or DirectColor visual. But if you read the spec carefully, you will see that this assumption is erroneous. Another way to approach this problem is to define a third rendering mode for OpenGL - "luminance mode". Will people trip over this? Visual selection is one of the most difficult parts of getting a 3D application to work in the X environment. In: 8 Out: 0 Abstain: 3 Get Current Display ------------------- Is there interest in something that just does a get current display? If we take just this capability from the import context extension and make it into its own extension, would people want to see it in OpenGL V1.1. In: 7 Out: 0 Abstain: 3 Other Extensions ---------------- Quick straw poll to see if other extensions can be quickly eliminated or need more discussion: talk out abstain packed pixel 2 4 4 lit texture 7 1 1 blending 7 2 3 copy texture 8 1 3 subtexture 9 0 2 texture 10 0 2 texture3D 1 3 7 Imaging extensions were not deemed ready for prime time. They really need hardware support to make them viable, and only one company has near term plans for supporting these in hardware. Texture ------- A discussion of the texture extension ensued. This extension defines a more robust mechanism for querying the system's texture map capacity as well as internal formats for use in describing pixel processing, color table formats, and texture map formats. What is the difference between luminance and intensity? Luminance treats alpha specially, intensity treats all four channels the same way. Are there some combinations of things that people don't care about but we'd end up being forced to implement in software? What about proxy stuff? Some people liked it, some people thought it was too complex. Perhaps it would be better to define a few more enums to make querying simple things easier. Who wants it if it only covers internal format and texture environment (e.g, rethink proxy)? In: 7 Out: 0 Abstain: 5 Who is in favor of texture proxy in its current form? In: 3 Out: 0 Abstain: 7 Subtexture ---------- In: 9 Out: 0 Abstain: 3 Copy Texture ------------ This does not buy anything if you don't store textures in hardware. Yes, but it's not hard to implement, do a read followed by a write (just be careful not to apply the transfer functions twice). This doesn't work well on systems with non-readable texture memory. But if people want to support OpenGL, they shouldn't be building systems with non-readable texture memory. In: 7 Out: 1 Abstain: 4 Lit Texture ----------- Should the lit texture extension (newly proposed by E&S) be added to to OpenGL V1.1? This extension provides mechanism for adding specular highlight to a textured surface without resorting to any multipass operations. Biggest issue is difficulty of supporting in hardware except for E&S. Not approved for inclusion in OpenGL V1.1. E&S will develop the spec into a formal OpenGL extension specification. Brief Digression ---------------- The results of permanent member voting for Intergraph and E&S were announced. Intergraph was accepted as a permanent member. There was one abstention on the vote for E&S. The ARB will revisit the vote for E&S in one month. If not approved at that time there will be a year's extension. Other Blending Extensions ------------------------- Should the blending extensions (other than blend_logic_op) be added to OpenGL V1.1? Minmax, subtract - basic imaging operations Color - specifies constant color to use as one element of blending op Issue - not easily supportable on most (if any) existing hardware Minmax/subtract vote: 1 for, 7 against, 4 abstain Color vote: 0 for (rest not taken) Review of Timeline ------------------ Should have a spec by 7/95 for internal review, and vote on it by 9/95 ARB meeting. Notes from last meeting included reference to spec'ing conformance issues. Review of Conformance Issues ---------------------------- Discussion of conformance tests to be spec'd. Proposed that covgl, covglx be extended as the minimal acceptable test for all new entry points. Approved 11 / 0 / 0 (yes/no/abstain) Chris to write up a list of basic feature existence tests for 11 approved extensions (must pass tests only, can't do full enumerant testing). Approved 6 / 0 / 1 (yes/no/abstain) vote of ARB members only Final Worklist for OpenGL V1.1 and GLX V1.2 ------------------------------------------- Results of preceding straw votes were discussed. It was proposed to move forward with the following work lists: OpenGL 1.1 worklist: Vertex array Texture object Blend logic op Polygon offset Copy texture Subtexture Texture Voted: 7 / 0 / 0 (yes/no/abstain) ARB members only GLX 1.2 worklist Support OGL 1.1 Visual rating Visual info get_current_dpy Voted: 6 / 0 / 1 (yes/no/abstain) ARB members only Next ARB meeting ---------------- Mon 9/11 through Wed 9/13 - go for 3 days 8:30-5 at SGI Exact details and times to follow After that: Austin, 12/4-12/6 - go for 3 days