OpenGL extension specification (from openGL.org)

Shader read/write/atomic into UAV global memory (need manual sync)

http://www.opengl.org/registry/specs/EXT/shader_image_load_store.txt

Render to Texture

http://www.opengl.org/registry/specs/ARB/wgl_render_texture.txt

Depth Texture for "Shadow Casting", "Image-based render" or "Displacement Mapping"

http://www.opengl.org/registry/specs/SGIX/depth_texture.txt

 This extension defines a new depth texture format.  An important
    application of depth texture images is shadow casting, but separating
    this from the shadow extension allows for the potential use of depth
    textures in other applications such as image-based rendering or
    displacement mapping.  This extension does not define new depth-texture
    environment functions, such as filtering or applying the depth values
    computed from a texture, but leaves this to other extensions, such as
    the shadow extension.

http://www.opengl.org/registry/specs/ARB/fragment_shader.txt

Float format to Color buffer and Depth buffer

http://www.opengl.org/registry/specs/ARB/color_buffer_float.txt

http://www.opengl.org/registry/specs/ARB/depth_buffer_float.txt

Texture swizzle:

http://www.opengl.org/registry/specs/ARB/texture_swizzle.txt

Classic OpenGL texture formats conflate texture storage and
    interpretation, and assume that textures represent color. In
    modern applications, a significant quantity of textures don't
    represent color, but rather data like shadow maps, normal maps,
    page tables, occlusion data, etc.. For the latter class of data,
    calling the data "RGBA" is just a convenient mapping of what the
    data is onto the current model, but isn't an accurate reflection
    of the reality of the data.

    The existing texture formats provide an almost orthogonal set of
    data types, sizes, and number of components, but the mappings of
    this storage into what the shader or fixed-function pipeline
    fetches is very much non-orthogonal. Previous extensions have
    added some of the most demanded missing formats, but the problem
    has not been solved once and for all.

    This extension provides a mechanism to swizzle the components
    of a texture before they are applied according to the texture
    environment in fixed-function or as they are returned to the
    shader.

http://www.opengl.org/registry/specs/ARB/blend_func_extended.txt

   Traditional OpenGL includes fixed-function blending that combines source
    colors with the existing content of a render buffer in a variety of ways.
    A number of extensions have enhanced this functionality by adding further
    sources of blending weights and methods to combine them. However, the inputs
    to the fixed-function blending units are constrained to a source color (as
    output from fragment shading), destination color (as the current content
    of the frame buffer) or constants that may be used in their place.

    This extension adds new blending functions whereby a fragment shader may
    output two colors, one of which is treated as the source color, and the
    other used as a blending factor for either source or destination colors.
    Furthermore, this extension increases orthogonality by allowing the
    SRC_ALPHA_SATURATE function to be used as the destination weight.

http://www.opengl.org/registry/specs/ARB/sync.txt

Overview

    This extension introduces the concept of "sync objects". Sync
    objects are a synchronization primitive - a representation of events
    whose completion status can be tested or waited upon. One specific
    type of sync object, the "fence sync object", is supported in this
    extension, and additional types can easily be added in the future.

    Fence sync objects have corresponding fences, which are inserted
    into the OpenGL command stream at the time the sync object is
    created. A sync object can be queried for a given condition. The
    only condition supported for fence sync objects is completion of the
    corresponding fence command. Fence completion allows applications to
    request a partial Finish, wherein all commands prior to the fence
    will be forced to complete before control is returned to the calling
    process.

    These new mechanisms allow for synchronization between the host CPU
    and the GPU, which may be accessing the same resources (typically
    memory), as well as between multiple GL contexts bound to multiple
    threads in the host CPU.

http://www.opengl.org/registry/specs/ARB/sparse_texture.txt

Overview

    Recent advances in application complexity and a desire for higher
    resolutions have pushed texture sizes up considerably. Often, the amount
    of physical memory available to a graphics processor is a limiting factor
    in the performance of texture-heavy applications. Once the available
    physical memory is exhausted, paging may occur bringing performance down
    considerably - or worse, the application may fail. Nevertheless, the amount
    of address space available to the graphics processor has increased to the
    point where many gigabytes - or even terabytes of address space may be
    usable even though that amount of physical memory is not present.

    This extension allows the separation of the graphics processor's address
    space (reservation) from the requirement that all textures must be
    physically backed (commitment). This exposes a limited form of
    virtualization for textures. Use cases include sparse (or partially
    resident) textures, texture paging, on-demand and delayed loading of
    texture assets and application controlled level of detail.

http://www.opengl.org/registry/specs/ARB/texture_multisample.txt

Overview

    This extension provides support for two new types of "multisample
    textures" - two-dimensional and two-dimensional array - as well as
    mechanisms to fetch a specific sample from such a texture in a shader,
    and to attach such textures to FBOs for rendering.

    This extension also includes the following functionality, first described
    in NV_explicit_multisample:

     * A query in the API to query the location of samples within the pixel

     * An explicit control for the multisample sample mask to augment the
       control provided by SampleCoverage