Deep understanding of OpenGL-OpenGL Evolution

Before opengl2.0, OpenGL was designed as a fixed-function state machine, so the only way to modify OpenGL was to define extensions for it. In this way, in various OpenGL implementations, new functions should be exposed in the form of extensions, resulting in a large number of available extensions. OpenGL has a well-defined Scaling Mechanism, and hardware manufacturers can freely define and implement features of new hardware features. However, since only OpenGL implementers can implement the extension, the OpenGL function cannot be extended for the application in advance until the OpenGL provider provides the extension implementation.

 

So far, there have been more than 400 OpenGL extensions. Extensions supported by only one manufacturer are identified by a short prefix that uniquely identifies the manufacturer (for example, SGI is an extension developed by Silicon Graphics, Inc ). Extensions supported by more than one manufacturer are represented by the prefix ext in the extension. Extensions thoroughly reviewed by ARB are marked with the ARB prefix in the extension to indicate that they have a special State as a recommendation method for exposing a function. Extension of the ARB tag will be added as a candidate to the standard OpenGL. Detailed descriptions of OpenGL extensions can be found at www.opengl.org/registry.

 

Extensions supported by a specific OpenGL implementation can be called by OpenGL functions.GlgetstringiTo confirm the parameter transferGl_extensions. The returned string contains the extension supported by this implementation. Some manufacturers currently support more than 100 separate OpenGL extensions (for example, Apple uses geforce 9400 GPU on Mac OS X snow leopard to support more than 120 independent extensions ). This is a daunting step for an application to determine whether the required extensions are supported in various existing implementations and what to do if they are not supported. The increasing expansion is fundamentally a positive factor for OpenGL development, but in a sense it has become the victim of its own success. It allows hardware manufacturers to easily expose new features, but it brings a series of dazzling non-standard options to application developers. Like any standard system, ARB is very cautious about upgrading from extended state functions to OpenGL standards.

 

Before OpenGL version 2.0, the underlying programmability of the graphic hardware was not exposed. The original OpenGL designers Mark Segal and Kurt Akeley stated: "One reason for this decision is that for performance reasons, graphical hardware is usually designed to provide certain operations in a specific order; replacing these operations with any algorithms is usually not feasible." This was basically true in the 1994 s (and even had a programmable graphic architecture ). But today, all the graphic hardware being produced is programmable. Due to the constant expansion of OpenGL and the need to support Microsoft's DirectX API, hardware manufacturers have no choice but to design a programmable graphics architecture.