A Proposal for OpenGL 1.4 Matt Craighead NVIDIA Corporation

Transcription

1 1. Introduction A Proposal for OpenGL 1.4 Matt Craighead NVIDIA Corporation mcraighead@nvidia.com This document proposes OpenGL 1.4. This standard, if adopted by the ARB, would build on the successful base of OpenGL 1.3 by incorporating a set of proven extensions into the core specification. Standardizing OpenGL 1.4 is compatible with efforts to standardize OpenGL 2.0. We believe OpenGL 1.4 provides an improved feature set for OpenGL 2.0 standardization. There is no reason to believe that OpenGL 1.4 will present a significant distraction from work on OpenGL 2.0, as demonstrated by the rapid ratification, adoption, and rollout of OpenGL 1.3. Realistically, an OpenGL 2.0 standard is some time off. The OpenGL 1.4 standard serves the interests of OpenGL in the interim between now and OpenGL 2.0 s standardization and widespread adoption. We believe that the standardization of OpenGL 1.4 can occur quickly and without adversely affecting the OpenGL 2.0 efforts if OpenGL 1.4 focuses on standardizing existing proven extensions. OpenGL 1.3 showed how this can be done rapidly. There was a substantial body of existing ARB extensions to work from, and there was general consensus about which ones made sense to standardize and which ones did not. NVIDIA believes a similar consensus can be reached today for OpenGL 1.4. This proposal presents a coherent set of proven extensions that are well-qualified to be added as new core OpenGL features. There are good reasons for an OpenGL 1.4. OpenGL has, in numerous areas, fallen behind Direct3D in functionality; standardizing new functionality keeps OpenGL competitive. Some of the extensions we propose match functionality available in Direct3D; others add functionality beyond what Direct3D offers. And, in general, standardizing new functionality as part of the core OpenGL standard drives the adoption of new features far more rapidly than if those features are exposed only through extensions. 2. Criteria for Including New Extensions NVIDIA has identified the following criteria for deciding which features to add and not to add. None of these criteria should be taken as a deciding factor all by itself, but each Copyright 2001, NVIDIA Corporation Page 1 of 7

2 one is important. The criteria are listed in order of importance, from most important to least. Consider extensions with shipping, proven implementations from three or more vendors; extensions with no shipping implementations should not be considered. Prefer ARB and EXT extensions over vendor extensions. Avoid extensions with outstanding intellectual property concerns. Avoid functionality exposed by different extensions in divergent ways. Consider extensions that bring OpenGL closer to parity with Direct3D or fix significant deficiencies in OpenGL. Prefer extensions used by real applications. 3. Vertex Programmability The topic of vertex programmability deserves mention. It has been proposed that OpenGL 1.4 might standardize vertex programmability in OpenGL. This proposal does not include any vertex programmability extensions. While standardizing vertex programmability might appear to give OpenGL 1.4 a single killer feature, it would in fact threaten the very goals of this proposal especially the goal that the proposal could be adopted quickly. Examining the criteria above puts the issue in perspective. There is currently no vertex programmability extension implemented by three or more OpenGL vendors. There are several different proposals. The feature is clearly controversial. Additionally, the feature is not free of intellectual property concerns. NVIDIA recommends that the ARB continue to consider vertex programmability in parallel with this proposal, waiting until a single final proposal emerges and the intellectual property concerns are addressed. Until then, it is better to agree to leave vertex programmability for a future standard rather than jeopardize this opportunity to adopt a new standard quickly. 4. Proposed OpenGL 1.4 Feature Set The extensions NVIDIA recommends for inclusion in OpenGL 1.4 are the following: ARB_depth_texture ARB_point_parameters ARB_shadow ARB_window_pos EXT_fog_coord EXT_multi_draw_arrays EXT_secondary_color EXT_stencil_wrap EXT_texture_lod_bias NV_blend_square Copyright 2001, NVIDIA Corporation Page 2 of 7

3 SGIS_generate_mipmap Our reasoning in choosing each of these extensions follows. We attempt to list vendors that support each particular extension based on available information. ARB_depth_texture, ARB_shadow: The only mechanism that OpenGL currently supports for rendering arbitrary shadows is stencil shadow volumes. While shadow volumes work, they are complicated to implement correctly and impose a significant burden on the CPU for shadow volume computation. Shadow maps provide a useful alternative mechanism for rendering shadows. Pixar s RenderMan and numerous other software renderers use shadow maps as the basis for their shadow generation. Shadow mapping techniques are well-developed. Although these two extensions have not yet been approved by the ARB, Brian Paul has written ARB proposals based on the existing SGIX extensions. The SGIX_depth_texture and SGIX_shadow extensions have existed for years on SGI s RealityEngine and InfiniteReality systems. Brian Paul s ARB proposals address the couple of minor specification issues with the original SGIX specifications. Brian has also proposed an ARB version of SGIX_shadow_ambient. NVIDIA considers this extension controversial because it requires an extra dedicated per-texture unit blend operation. Existing ARB_texture_env extensions and other extensions provide more general ways to account for ambient terms. The ARB_shadow_ambient extension is useful and should be approved as an ARB standard, but is not justified for inclusion in the core OpenGL standard. Mesa, NVIDIA, and SGI support this functionality. Note that DirectX 8 does not support this feature. ARB_point_parameters: In its EXT form, this functionality has been a de facto standard feature for some time, starting with its inclusion in the Quake2 engine. It is useful for particle effects. DirectX 7 also supports the functionality. The widespread support for and usage of this feature single it out as a good candidate for being adopted as a core API feature. ATI, Mesa, NVIDIA, SGI, and other OpenGL implementations support this functionality. ARB_window_pos: This extension has not yet been adopted officially by the ARB, but it solves numerous long-standing gripes about OpenGL raster positions that have widely been recognized as flaws in the API both regarding the unintuitive need to disable all transform and lighting functionality before calling glrasterpos, and glrasterpos s behavior with respect to clipping. In turn, applications have been compelled to use strange workarounds for these problems, such as the glbitmap hack for moving the raster position outside the viewport. This extension requires no special hardware support. Copyright 2001, NVIDIA Corporation Page 3 of 7

4 Mesa implements this extension today. EXT_fog_coord: DirectX 5 allows applications to specify a fog blend factor using the alpha component of the secondary color. Though this design decision has been criticized as unintuitive, it remains useful functionality. EXT_fog_coord goes one step further by allowing applications to specify a per-vertex fog distance. GL_LINEAR fog can be used to match DirectX 5 s fog factor functionality. ATI, IBM, Mesa, NVIDIA, and other OpenGL vendors support this extension today. NVIDIA recommends that the eye distance and fog coordinate vertex processing outputs be folded into a single fog coordinate output. The present behavior creates unnecessary extra state and poses an implementation burden, especially if glrasterpos is implemented in hardware. EXT_multi_draw_arrays: This extension provides a faster interface for applications to submit multiple groups of primitives. The most obvious application for it is to submit several triangle strips at once, reducing the significant API overhead from calling into OpenGL multiple times and avoiding the use of degenerate triangles (which also cost performance). It can also allow implementations to process larger batches of data at a time. IBM, NVIDIA, Sun, and other OpenGL vendors support this extension today. NVIDIA recommends that, as part of adopting this extension, a new glmultidrawrangeelements entry point be added that takes a single start and end value for all of the groups of primitives submitted. This allows for many additional driver optimizations. (Adding pointers to arrays of start and end values is clumsier and will likely force drivers to simply traverse these arrays to find the real minimum and maximum index in order to take advantage of vertex reuse across many primitives.) EXT_secondary_color: Although separate specular color, introduced in OpenGL 1.2, was a welcome addition to the API, OpenGL still lacks parity with DirectX 5 in that applications not using GL lighting cannot specify their own per-vertex secondary color. This extension can also play a role in fragment programmability by providing applications with another interpolated color. ATI, IBM, Mesa, NVIDIA, and other OpenGL implementations support this extension today. EXT_stencil_wrap: These stencil modes are useful in many circumstances, not the least of which is for stencil shadow volumes. These modes are in DirectX 6 and beyond. ATI, IBM, Matrox, Mesa, NVIDIA, 3Dlabs, S3, and other OpenGL implementations support this extension today. Copyright 2001, NVIDIA Corporation Page 4 of 7

5 EXT_texture_lod_bias: This feature has been supported in Direct3D since at least DirectX 6. Uses for this extension include allowing applications to make interesting performance/image quality tradeoffs; sharpening textures before applying accumulation buffer antialiasing; producing a generally blurry look as a special effect; and many other possibilities. Apple, ATI, Mesa, NVIDIA, and other OpenGL implementations support this extension today. Most DirectX 6-capable hardware supports this functionality. NVIDIA recommends that this feature be adopted without adding a per-texture-object LOD bias. We believe that this is not widely useful, and that in most circumstances this extra state will simply add overhead. On the other hand, having a single texture bound with multiple LOD biases is useful in some applications. We are willing to consider adding this per-texture-object LOD bias, but we prefer that it be omitted unless some compelling justification exists. NV_blend_square: This extension cleans up a small non-orthogonality in the OpenGL API by allowing all of the blend factors to be used for both source and destination (with the exception of source alpha saturate as destination factor). DirectX 5 and beyond have supported this feature. The most obvious application for this is for certain shader effects where an additional squaring is desired to produce a power term, but it can be used for other purposes at well. Although this is a vendor extension, we believe that this is a worthwhile feature to add. It should also be noted that the current limitation is confusing to many; some developers have even remarked that they had long been using NV_blend_square without even realizing that it was an extension! Mesa, NVIDIA, and other OpenGL implementations implement this extension. Most DirectX 5-capable hardware supports the functionality. SGIS_generate_mipmap: Although GLU has long supported building mipmaps automatically, this extension is worthwhile in the context of dynamic textures, especially when glcopyteximage and/or the render-to-texture extensions are used. NVIDIA has also found that, in many cases, its own implementation of this extension outperforms GLU in constructing mipmaps. Though this is a vendor extension, we believe that it should be included as well. ATI, Mesa, NVIDIA, and SGI support this extension today. NVIDIA recommends that this extension be amended to state that no texture levels beyond TEXTURE_MAX_LEVEL are constructed. This may present a possible backwards compatibility dilemma, and as a result it may be necessary to add a new parameter, but the current behavior does seem to be somewhat inconsistent with the intent of the base level/max level functionality. NVIDIA would appreciate feedback from other vendors on this issue. Copyright 2001, NVIDIA Corporation Page 5 of 7

6 NVIDIA is open to the inclusion of other extensions, but believes that, for an extension to be considered, it should meet most or all of the criteria listed in Section 2. We would also like to see the extensions above adopted unmodified whenever possible, except as noted; changing them will increase the implementation burden of the new specification and may jeopardize the timely standardization of OpenGL What Needs to be Done? The new features need to be integrated into the core OpenGL specification. In general, the existing extension specifications adequately explain how the specification needs to be updated, but in some cases they may be missing some details or may turn out to have unforeseen interactions with other features. Conformance tests need to be written for each of the new features. Such tests need to be sufficiently detailed to ensure that each new feature is essentially working, but not so detailed as to prevent vendors from implementing the features in good faith. The ARB should officially approve these conformance tests once they are written. NVIDIA volunteers to help Jon Leech at SGI with updating the OpenGL specification however Jon sees fit. NVIDIA also volunteers to lead the effort to specify conformance tests for OpenGL 1.4 and to implement all such tests. NVIDIA proposes a preliminary deadline that final draft -quality versions of the specification and conformance tests be finished no later than the March 2002 ARB meeting, assuming that the ARB can agree on the functionality soon. There are also questions as to how OpenGL 1.4 ought to be launched, promoted, etc., but these are beyond the scope of this whitepaper. We hope that by SIGGRAPH 2002, Mesa and multiple other OpenGL implementations of OpenGL 1.4 will be available. 6. Conclusion and Call to Action This proposal for OpenGL 1.4 adds a number of proven features to the core OpenGL API, helping to ensure that OpenGL is up-to-date and competitive. NVIDIA urges that this proposal be expedited. Specifically, we would like the ARB to hold a non-binding vote on whether to move forward on this functionality at the December 2001 meeting, and would then like to press for a deadline of rolling out OpenGL 1.4 no later than, and hopefully earlier than, SIGGRAPH NVIDIA pledges to commit the resources necessary to get the job done. NVIDIA also urges the ARB to move rapidly to adopt those ARB extensions suggested as features within this proposal, namely, ARB_depth_texture, ARB_shadow, and ARB_window_pos. Reaching agreement on these features as soon as possible will not only assist in achieving an aggressive OpenGL 1.4 schedule, but also enlarge the base of ARB-endorsed extensions, a benefit in its own right. Copyright 2001, NVIDIA Corporation Page 6 of 7

7 Finally, this proposal should not be held up by either the concern that it will delay OpenGL 2.0 (for we believe it will do nothing of the sort) or that the proposal does not include vertex program functionality (for the reasons stated earlier). When the ARB comes to a resolution of the issues surrounding vertex programmability, we suggest rolling it into a possible OpenGL 1.5 specification. Copyright 2001, NVIDIA Corporation Page 7 of 7