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