1.2. OpenGL演进 OpenGL Evolution

1.2. OpenGL演进 OpenGL Evolution

因为在2.0之前，它的基础设计为固定功能的状态机，所以修改OpenGL的唯一方法就是给它定义扩展。

因此，大量的以扩展形式提供的功能在各种不同的OpenGL实现中可用，这些扩展揭示新的硬件功能。

OpenGL有一套定义明确的扩展机制，硬件供应商可以自由地定义和实现揭示新硬件功能的特性。

因为只有OpenGL的实现者可以实施扩展，所以，在以前应用没有办法在OpenGL提供者提供的内容

之上扩展OpenGL的功能。

迄今为止，有将近300个扩展已经被定义。只被某一个供应商支持的扩展通过唯一标识这个供应商的

短前缀来标识（例如，SGI用于Silicon Graphics开发的扩展）。

Because of its fundamental design as a fixed function state machine, before OpenGL 2.0, the

only way to modify OpenGL was to define extensions to it. Therefore, a great deal of

functionality is available in various OpenGL implementations in the form of extensions that

expose new hardware functionality. OpenGL has a well-defined extension mechanism, and

hardware vendors are free to define and implement features that expose new hardware

functionality. Since only OpenGL implementors can implement extensions, there was previously

no way for applications to extend the functionality of OpenGL beyond what was provided by

their OpenGL provider.

To date, close to 300 extensions have been defined. Extensions that are supported by only one

vendor are identified by a short prefix unique to that vendor (e.g., SGI for extensions

developed by Silicon Graphics, Inc.). Extensions that are supported by more than one vendor

are denoted by the prefix EXT in the extension name. Extensions that have been thoroughly

reviewed by the ARB are designated with an ARB prefix in the extension name to indicate that

they have a special status as a recommended way of exposing a certain piece of functionality.

Extensions that achieve the ARB designation are candidates to be added to standard OpenGL.

Published specifications for OpenGL extensions are available at the OpenGL extension registry

at http://oss.sgi.com/projects/ogl-sample/registry.

The extensions supported by a particular OpenGL implementation can be determined by calling

the OpenGL glGetString function with the symbolic constant GL_EXTENSIONS. The returned

string contains a list of all the extensions supported in the implementation, and some vendors

currently support close to 100 separate OpenGL extensions. It can be a little bit daunting for an

application to try and determine whether the needed extensions are present on a variety of

implementations, and what to do if they're not. The proliferation of extensions has been

primarily a positive factor for the development of OpenGL, but in a sense, it has become a

victim of its own success. It allows hardware vendors to expose new features easily, but it

presents application developers with a dizzying array of nonstandard options. Like any

standards body, the ARB is cautious about promoting functionality from extension status to

standard OpenGL.

Before version 2.0 of OpenGL, none of the underlying programmability of graphics hardware

was exposed. The original designers of OpenGL, Mark Segal and Kurt Akeley, stated, "One

reason for this decision is that, for performance reasons, graphics hardware is usually designed

to apply certain operations in a specific order; replacing these operations with arbitrary

algorithms is usually infeasible." This statement may have been mostly true when it was written

in 1994 (there were programmable graphics architectures even then). But today, all of the

graphics hardware that is being produced is programmable. Because of the proliferation of

OpenGL extensions and the need to support Microsoft's DirectX API, hardware vendors have no

choice but to design programmable graphics architectures. As discussed in the remaining

chapters of this book, providing application programmers with access to this programmability is

the purpose of the OpenGL Shading Language.