Google Git Google Git
Sign in
skia/external/github.com/KhronosGroup/OpenGL-Registry/refs/heads/add-contributing-file/./extensions/ARB/ARB_framebuffer_object.txt
blob: ced9a1e24d3c51630c7c0066cac74dbc4fda966a [file] [edit]
Name
ARB_framebuffer_object
Name Strings
GL_ARB_framebuffer_object
Contributors
Kurt Akeley
Jason Allen
Rob Barris
Bob Beretta
Pat Brown
Matt Craighead
Alex Eddy
Cass Everitt
Mark Galvan
Michael Gold
Evan Hart
Jeff Juliano
John Kessenich
Mark Kilgard
Dale Kirkland
Daniel Koch
Jon Leech
Bill Licea-Kane
Barthold Lichtenbelt
Kent Lin
Rob Mace
Teri Morrison
Chris Niederauer
Brian Paul
Paul Puey
Ian Romanick
John Rosasco
R. Jason Sams
Jeremy Sandmel
Mark Segal
Avinash Seetharamaiah
Folker Schamel
Eskil Steenberg
Daniel Vogel
Eric Werness
Cliff Woolley
Contacts
Rob Barris (rbarris 'at' gmail.com)
Daniel Koch, TransGaming Inc.
Notice
Copyright (c) 2008-2013 The Khronos Group Inc. Copyright terms at
http://www.khronos.org/registry/speccopyright.html
Specification Update Policy
Khronos-approved extension specifications are updated in response to
issues and bugs prioritized by the Khronos OpenGL Working Group. For
extensions which have been promoted to a core Specification, fixes will
first appear in the latest version of that core Specification, and will
eventually be backported to the extension document. This policy is
described in more detail at
https://www.khronos.org/registry/OpenGL/docs/update_policy.php
Status
Approved by the ARB on August 4, 2008
Version
Last Modified Date: October 6, 2016
Revision: #38
Number
ARB Extension #45
Dependencies
OpenGL 1.1 is required.
WGL_ARB_make_current_read affects the definition of this extension.
GLX 1.3 / GLX_SGI_make_current_read affects the definition of this
extension.
ATI_draw_buffers affects the definition of this extension.
ARB_draw_buffers affects the definition of this extension.
ARB_fragment_program affects the definition of this extension.
ARB_fragment_shader affects the definition of this extension.
ARB_texture_rectangle affects the definition of this extension.
ARB_vertex_shader affects the definition of this extension.
NV_float_buffer affects the definition of this extension.
ARB_color_buffer_float affects the definition of this extension.
NV_texture_shader affects the definition of this extension.
This extension modifies NV_packed_depth_stencil.
ARB_depth_texture affects the definition of this extension.
SGIX_depth_texture affects the definition of this extension.
ARB_texture_rg affects the definition of this extension.
EXT_texture_array affects the definition of this extension.
EXT_texture_integer affects the definition of this extension.
ARB_framebuffer_sRGB affects the definition of this extension.
Written based on the wording of the OpenGL 2.1 specification.
Overview
ARB_framebuffer_object is an extension intended to address the following
goals:
- Reflect FBO-related functionality found in the OpenGL 3.0 specification.
- Integrate multiple disjoint extensions into a single ARB extension.
These extensions are:
EXT_framebuffer_object
EXT_framebuffer_blit
EXT_framebuffer_multisample
EXT_packed_depth_stencil
- Where appropriate, relax some of the constraints expressed by previous
FBO-related extensions. In particular the requirement of matching
attachment dimensions and component sizes has been relaxed, to allow
implementations the freedom to support more flexible usages where
possible.
ARB_framebuffer_object defines an interface for drawing to rendering
destinations other than the buffers provided to the GL by the
window-system.
In this extension, these newly defined rendering destinations are
known collectively as "framebuffer-attachable images". This
extension provides a mechanism for attaching framebuffer-attachable
images to the GL framebuffer as one of the standard GL logical
buffers: color, depth, and stencil. (Attaching a
framebuffer-attachable image to the accum logical buffer is left for
a future extension to define). When a framebuffer-attachable image
is attached to the framebuffer, it is used as the source and
destination of fragment operations as described in Chapter 4.
By allowing the use of a framebuffer-attachable image as a rendering
destination, this extension enables a form of "offscreen" rendering.
Furthermore, "render to texture" is supported by allowing the images
of a texture to be used as framebuffer-attachable images. A
particular image of a texture object is selected for use as a
framebuffer-attachable image by specifying the mipmap level, cube
map face (for a cube map texture), and layer (for a 3D texture)
that identifies the image. The "render to texture" semantics of
this extension are similar to performing traditional rendering to
the framebuffer, followed immediately by a call to CopyTexSubImage.
However, by using this extension instead, an application can achieve
the same effect, but with the advantage that the GL can usually
eliminate the data copy that would have been incurred by calling
CopyTexSubImage.
This extension also defines a new GL object type, called a
"renderbuffer", which encapsulates a single 2D pixel image. The
image of renderbuffer can be used as a framebuffer-attachable image
for generalized offscreen rendering and it also provides a means to
support rendering to GL logical buffer types which have no
corresponding texture format (stencil, accum, etc). A renderbuffer
is similar to a texture in that both renderbuffers and textures can
be independently allocated and shared among multiple contexts. The
framework defined by this extension is general enough that support
for attaching images from GL objects other than textures and
renderbuffers could be added by layered extensions.
To facilitate efficient switching between collections of
framebuffer-attachable images, this extension introduces another new
GL object, called a framebuffer object. A framebuffer object
contains the state that defines the traditional GL framebuffer,
including its set of images. Prior to this extension, it was the
window-system which defined and managed this collection of images,
traditionally by grouping them into a "drawable". The window-system
API's would also provide a function (i.e., wglMakeCurrent,
glXMakeCurrent, aglSetDrawable, etc.) to bind a drawable with a GL
context (as is done in the WGL_ARB_pbuffer extension). In this
extension however, this functionality is subsumed by the GL and the
GL provides the function BindFramebufferARB to bind a framebuffer
object to the current context. Later, the context can bind back to
the window-system-provided framebuffer in order to display rendered
content.
Previous extensions that enabled rendering to a texture have been
much more complicated. One example is the combination of
ARB_pbuffer and ARB_render_texture, both of which are window-system
extensions. This combination requires calling MakeCurrent, an
operation that may be expensive, to switch between the window and
the pbuffer drawables. An application must create one pbuffer per
renderable texture in order to portably use ARB_render_texture. An
application must maintain at least one GL context per texture
format, because each context can only operate on a single
pixelformat or FBConfig. All of these characteristics make
ARB_render_texture both inefficient and cumbersome to use.
ARB_framebuffer_object, on the other hand, is both simpler to use
and more efficient than ARB_render_texture. The
ARB_framebuffer_object API is contained wholly within the GL API and
has no (non-portable) window-system components. Under
ARB_framebuffer_object, it is not necessary to create a second GL
context when rendering to a texture image whose format differs from
that of the window. Finally, unlike the pbuffers of
ARB_render_texture, a single framebuffer object can facilitate
rendering to an unlimited number of texture objects.
This extension differs from EXT_framebuffer_object by splitting the
framebuffer object binding point into separate DRAW and READ
bindings (incorporating functionality introduced by
EXT_framebuffer_blit). This allows copying directly from one
framebuffer to another. In addition, a new high performance blit
function is added to facilitate these blits and perform some data
conversion where allowed.
This extension also enables usage of multisampling in conjunction with
renderbuffers (incorporating functionality from
EXT_packed_depth_stencil), as follows:
The new operation RenderbufferStorageMultisample() allocates
storage for a renderbuffer object that can be used as a multisample
buffer. A multisample render buffer image differs from a
single-sample render buffer image in that a multisample image has a
number of SAMPLES that is greater than zero. No method is provided
for creating multisample texture images.
All of the framebuffer-attachable images attached to a framebuffer
object must have the same number of SAMPLES or else the framebuffer
object is not "framebuffer complete". If a framebuffer object with
multisample attachments is "framebuffer complete", then the
framebuffer object behaves as if SAMPLE_BUFFERS is one.
In traditional multisample rendering, where
DRAW_FRAMEBUFFER_BINDING is zero and SAMPLE_BUFFERS is one, the
GL spec states that "the color sample values are resolved to a
single, displayable color each time a pixel is updated." There are,
however, several modern hardware implementations that do not
actually resolve for each sample update, but instead postpones the
resolve operation to a later time and resolve a batch of sample
updates at a time. This is OK as long as the implementation behaves
"as if" it had resolved a sample-at-a-time. Unfortunately, however,
honoring the "as if" rule can sometimes degrade performance.
In contrast, when DRAW_FRAMEBUFFER_BINDING is an
application-created framebuffer object, MULTISAMPLE is enabled, and
SAMPLE_BUFFERS is one, there is no implicit per-sample-update
resolve. Instead, the application explicitly controls when the
resolve operation is performed. The resolve operation is affected
by calling BlitFramebuffer where the source is a multisample
application-created framebuffer object and the destination is a
single-sample framebuffer object (either application-created or
window-system provided).
This design for multisample resolve more closely matches current
hardware, but still permits implementations which choose to resolve
a single sample at a time. If hardware that implements the
multisample resolution "one sample at a time" exposes
ARB_framebuffer_object, it could perform the implicit resolve
to a driver-managed hidden surface, then read from that surface when
the application calls BlitFramebuffer.
Another motivation for granting the application explicit control
over the multisample resolve operation has to do with the
flexibility afforded by ARB_framebuffer_object. Previously, a
drawable (window or pbuffer) had exclusive access to all of its
buffers. There was no mechanism for sharing a buffer across
multiple drawables. Under ARB_framebuffer_object, however, a
mechanism exists for sharing a framebuffer-attachable image across
several framebuffer objects, as well as sharing an image between a
framebuffer object and a texture. If we had retained the "implicit"
resolve from traditional multisampled rendering, and allowed the
creation of "multisample" format renderbuffers, then this type of
sharing would have lead to two problematic situations:
* Two contexts, which shared renderbuffers, might perform
competing resolve operations into the same single-sample buffer
with ambiguous results.
* It would have introduced the unfortunate ability to use the
single-sample buffer as a texture while MULTISAMPLE is ENABLED.
Using BlitFramebuffer as an explicit resolve to serialize access to
the multisampled contents and eliminate the implicit per-sample
resolve operation, we avoid both of these problems.
This extension also enables usage of packed depth-stencil formats in
renderbuffers (incorporating functionality from
EXT_packed_depth_stencil), as follows:
Many OpenGL implementations have chosen to interleave the depth and
stencil buffers into one buffer, often with 24 bits of depth
precision and 8 bits of stencil data. 32 bits is more than is
needed for the depth buffer much of the time; a 24-bit depth buffer,
on the other hand, requires that reads and writes of depth data be
unaligned with respect to power-of-two boundaries. On the other
hand, 8 bits of stencil data is more than sufficient for most
applications, so it is only natural to pack the two buffers into a
single buffer with both depth and stencil data. OpenGL never
provides direct access to the buffers, so the OpenGL implementation
can provide an interface to applications where it appears the one
merged buffer is composed of two logical buffers.
One disadvantage of this scheme is that OpenGL lacks any means by
which this packed data can be handled efficiently. For example,
when an application reads from the 24-bit depth buffer, using the
type GL_UNSIGNED_SHORT will lose 8 bits of data, while
GL_UNSIGNED_INT has 8 too many. Both require expensive format
conversion operations. A 24-bit format would be no more suitable,
because it would also suffer from the unaligned memory accesses that
made the standalone 24-bit depth buffer an unattractive proposition
in the first place.
Many applications, such as parallel rendering applications, may also
wish to draw to or read back from both the depth and stencil buffers
at the same time. Currently this requires two separate operations,
reducing performance. Since the buffers are interleaved, drawing to
or reading from both should be no more expensive than using just
one; in some cases, it may even be cheaper.
This extension provides a new data format, GL_DEPTH_STENCIL,
that can be used with the glDrawPixels, glReadPixels, and
glCopyPixels commands, as well as a packed data type,
GL_UNSIGNED_INT_24_8, that is meant to be used with
GL_DEPTH_STENCIL. No other data types are supported with
GL_DEPTH_STENCIL. If ARB_depth_texture or SGIX_depth_texture is
supported, GL_DEPTH_STENCIL/GL_UNSIGNED_INT_24_8 data can
also be used for textures; this provides a more efficient way to
supply data for a 24-bit depth texture.
GL_DEPTH_STENCIL data, when passed through the pixel path,
undergoes both depth and stencil operations. The depth data is
scaled and biased by the current GL_DEPTH_SCALE and GL_DEPTH_BIAS,
while the stencil data is shifted and offset by the current
GL_INDEX_SHIFT and GL_INDEX_OFFSET. The stencil data is also put
through the stencil-to-stencil pixel map.
glDrawPixels of GL_DEPTH_STENCIL data operates similarly to that
of GL_STENCIL_INDEX data, bypassing the OpenGL fragment pipeline
entirely, unlike the treatment of GL_DEPTH_COMPONENT data. The
stencil and depth masks are applied, as are the pixel ownership and
scissor tests, but all other operations are skipped.
glReadPixels of GL_DEPTH_STENCIL data reads back a rectangle
from both the depth and stencil buffers.
glCopyPixels of GL_DEPTH_STENCIL data copies a rectangle from
both the depth and stencil buffers. Like glDrawPixels, it applies
both the stencil and depth masks but skips the remainder of the
OpenGL fragment pipeline.
glTex[Sub]Image[1,2,3]D of GL_DEPTH_STENCIL data loads depth and
stencil data into a depth_stencil texture. glGetTexImage of
GL_DEPTH_STENCIL data can be used to retrieve depth and stencil
data from a depth/stencil texture.
In addition, a new base internal format, GL_DEPTH_STENCIL, can
be used by both texture images and renderbuffer storage. When an
image with a DEPTH_STENCIL internal format is attached to both
the depth and stencil attachment points of a framebuffer object,
then it becomes both the depth and stencil
buffers of the framebuffer. This fits nicely with hardware that
interleaves both depth and stencil data into a single buffer. When
a texture with DEPTH_STENCIL data is bound for texturing, only
the depth component is accessible through the texture fetcher. The
stencil data can be written with TexImage or CopyTexImage, and can
be read with GetTexImage. When a DEPTH_STENCIL image is
attached to the stencil attachment of the bound framebuffer object,
the stencil data can be accessed through any operation that reads
from or writes to the framebuffer's stencil buffer.
Glossary of Helpful Terms
logical buffer:
One of the color, depth, or stencil buffers of the
framebuffer.
framebuffer:
The collection of logical buffers and associated state
defining where the output of GL rendering is directed.
texture:
an object which consists of one or more 2D arrays of pixel
images and associated state that can be used as a source of
data during the texture-mapping process described in section
3.8.
texture image:
one of the 2D arrays of pixels that are part of a texture
object as defined in section 3.8. Texture images contain
and define the texels of the texture object.
renderbuffer:
A new type of storage object which contains a single 2D
array of pixels and associated state that can be used as a
destination for pixel data written during the rendering
process described in Chapter 4.
renderbuffer image:
The 2D array of pixels that is part of a renderbuffer
object. A renderbuffer image contains and defines the
pixels of the renderbuffer object.
framebuffer-attachable image:
A 2D pixel image that can be attached to one of the logical
buffer attachment points of a framebuffer object. Texture
images and renderbuffer images are two examples of
framebuffer-attachable images.
attachment point:
The set of state which references a specific
framebuffer-attachable image, and allows that
framebuffer-attachable image to be used to store the
contents of a logical buffer of a framebuffer object. There
is an attachment point state vector for each color, depth,
and stencil buffer of a framebuffer.
attach:
The act of connecting one object to another object.
An "attach" operation is similar to a "bind" operation in
that both represent a reference to the attached or bound
object for the purpose of managing object lifetimes and both
enable manipulation of the state of the attached or bound
object.
However, an "attach" is also different from a "bind" in that
"binding" an unused object creates a new object, while
"attaching" does not. Additionally, "bind" establishes a
connection between a context and an object, while "attach"
establishes a connection between two objects.
Finally, if object "A" is attached to object "B" and object
"B" is bound to context "C", then in most respects, we treat
"A" as if it is <implicitly> bound to "C".
framebuffer attachment completeness:
Similar to texture "mipmap" or "cube" completeness from
section 3.8.10, defines a minimum set of criteria for
framebuffer attachment points. (for complete definition,
see section 4.4.4.1)
framebuffer completeness:
Similar to texture "mipmap cube completeness", defines a
composite set of "completeness" requirements and
relationships among the attached framebuffer-attachable
images. (for complete definition, see section 4.4.4.2)
New Procedures and Functions
boolean IsRenderbuffer(uint renderbuffer);
void BindRenderbuffer(enum target, uint renderbuffer);
void DeleteRenderbuffers(sizei n, const uint *renderbuffers);
void GenRenderbuffers(sizei n, uint *renderbuffers);
void RenderbufferStorage(enum target, enum internalformat,
sizei width, sizei height);
void RenderbufferStorageMultisample(enum target, sizei samples,
enum internalformat,
sizei width, sizei height);
void GetRenderbufferParameteriv(enum target, enum pname, int *params);
boolean IsFramebuffer(uint framebuffer);
void BindFramebuffer(enum target, uint framebuffer);
void DeleteFramebuffers(sizei n, const uint *framebuffers);
void GenFramebuffers(sizei n, uint *framebuffers);
enum CheckFramebufferStatus(enum target);
void FramebufferTexture1D(enum target, enum attachment,
enum textarget, uint texture, int level);
void FramebufferTexture2D(enum target, enum attachment,
enum textarget, uint texture, int level);
void FramebufferTexture3D(enum target, enum attachment,
enum textarget, uint texture,
int level, int layer);
void FramebufferTextureLayer(enum target,enum attachment,
uint texture,int level,int layer);
void FramebufferRenderbuffer(enum target, enum attachment,
enum renderbuffertarget, uint renderbuffer);
void GetFramebufferAttachmentParameteriv(enum target, enum attachment,
enum pname, int *params);
void BlitFramebuffer(int srcX0, int srcY0, int srcX1, int srcY1,
int dstX0, int dstY0, int dstX1, int dstY1,
bitfield mask, enum filter);
void GenerateMipmap(enum target);
New Types
None.
New Tokens
Accepted by the <target> parameter of BindFramebuffer,
CheckFramebufferStatus, FramebufferTexture{1D|2D|3D},
FramebufferRenderbuffer, and
GetFramebufferAttachmentParameteriv:
FRAMEBUFFER 0x8D40
READ_FRAMEBUFFER 0x8CA8
DRAW_FRAMEBUFFER 0x8CA9
Accepted by the <target> parameter of BindRenderbuffer,
RenderbufferStorage, and GetRenderbufferParameteriv, and
returned by GetFramebufferAttachmentParameteriv:
RENDERBUFFER 0x8D41
Accepted by the <internalformat> parameter of
RenderbufferStorage:
STENCIL_INDEX1 0x8D46
STENCIL_INDEX4 0x8D47
STENCIL_INDEX8 0x8D48
STENCIL_INDEX16 0x8D49
Accepted by the <pname> parameter of GetRenderbufferParameteriv:
RENDERBUFFER_WIDTH 0x8D42
RENDERBUFFER_HEIGHT 0x8D43
RENDERBUFFER_INTERNAL_FORMAT 0x8D44
RENDERBUFFER_RED_SIZE 0x8D50
RENDERBUFFER_GREEN_SIZE 0x8D51
RENDERBUFFER_BLUE_SIZE 0x8D52
RENDERBUFFER_ALPHA_SIZE 0x8D53
RENDERBUFFER_DEPTH_SIZE 0x8D54
RENDERBUFFER_STENCIL_SIZE 0x8D55
RENDERBUFFER_SAMPLES 0x8CAB
Accepted by the <pname> parameter of
GetFramebufferAttachmentParameteriv:
FRAMEBUFFER_ATTACHMENT_OBJECT_TYPE 0x8CD0
FRAMEBUFFER_ATTACHMENT_OBJECT_NAME 0x8CD1
FRAMEBUFFER_ATTACHMENT_TEXTURE_LEVEL 0x8CD2
FRAMEBUFFER_ATTACHMENT_TEXTURE_CUBE_MAP_FACE 0x8CD3
FRAMEBUFFER_ATTACHMENT_TEXTURE_LAYER 0x8CD4
FRAMEBUFFER_ATTACHMENT_COLOR_ENCODING 0x8210
FRAMEBUFFER_ATTACHMENT_COMPONENT_TYPE 0x8211
FRAMEBUFFER_ATTACHMENT_RED_SIZE 0x8212
FRAMEBUFFER_ATTACHMENT_GREEN_SIZE 0x8213
FRAMEBUFFER_ATTACHMENT_BLUE_SIZE 0x8214
FRAMEBUFFER_ATTACHMENT_ALPHA_SIZE 0x8215
FRAMEBUFFER_ATTACHMENT_DEPTH_SIZE 0x8216
FRAMEBUFFER_ATTACHMENT_STENCIL_SIZE 0x8217
Returned in <params> by GetFramebufferAttachmentParameteriv:
SRGB 0x8C40
UNSIGNED_NORMALIZED 0x8C17
FRAMEBUFFER_DEFAULT 0x8218
INDEX 0x8222
Accepted by the <attachment> parameter of
FramebufferTexture{1D|2D|3D}, FramebufferRenderbuffer, and
GetFramebufferAttachmentParameteriv
COLOR_ATTACHMENT0 0x8CE0
COLOR_ATTACHMENT1 0x8CE1
COLOR_ATTACHMENT2 0x8CE2
COLOR_ATTACHMENT3 0x8CE3
COLOR_ATTACHMENT4 0x8CE4
COLOR_ATTACHMENT5 0x8CE5
COLOR_ATTACHMENT6 0x8CE6
COLOR_ATTACHMENT7 0x8CE7
COLOR_ATTACHMENT8 0x8CE8
COLOR_ATTACHMENT9 0x8CE9
COLOR_ATTACHMENT10 0x8CEA
COLOR_ATTACHMENT11 0x8CEB
COLOR_ATTACHMENT12 0x8CEC
COLOR_ATTACHMENT13 0x8CED
COLOR_ATTACHMENT14 0x8CEE
COLOR_ATTACHMENT15 0x8CEF
DEPTH_ATTACHMENT 0x8D00
STENCIL_ATTACHMENT 0x8D20
DEPTH_STENCIL_ATTACHMENT 0x821A
Accepted by the <pname> parameter of GetBooleanv, GetIntegerv,
GetFloatv, and GetDoublev:
MAX_SAMPLES 0x8D57
FRAMEBUFFER_BINDING 0x8CA6 // alias DRAW_FRAMEBUFFER_BINDING
DRAW_FRAMEBUFFER_BINDING 0x8CA6
READ_FRAMEBUFFER_BINDING 0x8CAA
RENDERBUFFER_BINDING 0x8CA7
MAX_COLOR_ATTACHMENTS 0x8CDF
MAX_RENDERBUFFER_SIZE 0x84E8
Returned by CheckFramebufferStatus():
FRAMEBUFFER_COMPLETE 0x8CD5
FRAMEBUFFER_INCOMPLETE_ATTACHMENT 0x8CD6
FRAMEBUFFER_INCOMPLETE_MISSING_ATTACHMENT 0x8CD7
FRAMEBUFFER_INCOMPLETE_DRAW_BUFFER 0x8CDB
FRAMEBUFFER_INCOMPLETE_READ_BUFFER 0x8CDC
FRAMEBUFFER_UNSUPPORTED 0x8CDD
FRAMEBUFFER_INCOMPLETE_MULTISAMPLE 0x8D56
FRAMEBUFFER_UNDEFINED 0x8219
Returned by GetError():
INVALID_FRAMEBUFFER_OPERATION 0x0506
Accepted by the <format> parameter of DrawPixels, ReadPixels,
TexImage1D, TexImage2D, TexImage3D, TexSubImage1D, TexSubImage2D,
TexSubImage3D, and GetTexImage, by the <type> parameter of
CopyPixels, by the <internalformat> parameter of TexImage1D,
TexImage2D, TexImage3D, CopyTexImage1D, CopyTexImage2D, and
RenderbufferStorage, and returned in the <data> parameter of
GetTexLevelParameter and GetRenderbufferParameteriv:
DEPTH_STENCIL 0x84F9
Accepted by the <type> parameter of DrawPixels, ReadPixels,
TexImage1D, TexImage2D, TexImage3D, TexSubImage1D, TexSubImage2D,
TexSubImage3D, and GetTexImage:
UNSIGNED_INT_24_8 0x84FA
Accepted by the <internalformat> parameter of TexImage1D,
TexImage2D, TexImage3D, CopyTexImage1D, CopyTexImage2D, and
RenderbufferStorage, and returned in the <data> parameter of
GetTexLevelParameter and GetRenderbufferParameteriv:
DEPTH24_STENCIL8 0x88F0
Accepted by the <value> parameter of GetTexLevelParameter:
TEXTURE_STENCIL_SIZE 0x88F1
Additions to Chapter 2 of the 2.1 Specification (OpenGL Operation)
"The GL interacts with two classes of framebuffers: window
system-provided and application-created. There is at most one window
system-provided framebuffer at any time, referred to as the <default
framebuffer>. Application-created framebuffers, referred to as
<framebuffer objects>, may be created as desired. These two types of
framebuffer are distinguished primarily by the interface for configuring
and managing their state.
The effects of GL commands on the default framebuffer are ultimately
controlled by the window system, which allocates framebuffer resources,
determines what portions of the default framebuffer the GL may access at
any given time, and communicates to the GL how those portions are
structured. Therefore, there are no GL commands to initialize a GL
context or configure the default framebuffer. Similarly, display of
framebuffer contents on a physical display device (including the
transformation of individual framebuffer values by such techniques as
gamma correction) is not addressed by the GL.
Allocation and configuration of the default framebuffer occurs outside
of the GL in conjunction with the window system, using companion APIs
such as GLX, WGL, and AGL for GL implementations running on the X Window
System, Microsoft Windows, and MacOS X respectively.
Allocation and initialization of GL contexts is also done using these
companion APIs. GL contexts can typically be associated with different
default framebuffers, and some context state is determined at the time
this association is performed.
It is possible to use a GL context <without> a default framebuffer, in
which case a framebuffer object must be used to perform all rendering.
This is useful for applications needing to perform <offscreen
rendering>."
Add to table 2.3, "Summary of GL errors":
Error Description Offending command
ignored?
----------------------------- ------------------ -----------------
...
INVALID_FRAMEBUFFER_OPERATION Framebuffer object Yes
is not complete
Append the following to section 2.6.1 "Begin and End":
"Calling Begin will result in an INVALID_FRAMEBUFFER_OPERATION
error if the object bound to DRAW_FRAMEBUFFER_BINDING is not
"framebuffer complete" (see section 4.4.4.2)."
Update the bulleted list in section 2.15.4 "Shader Execution" in
the subsection titled "Texture Access" to say:
"* The sampler used in a texture lookup function is not one of
the shadow sampler types, the texture object's base internal
format is DEPTH_COMPONENT or DEPTH_STENCIL, and the
TEXTURE_COMPARE_MODE is not NONE.
* The sampler used in a texture lookup function is one of the
shadow sampler types, the texture object's base
internal format is DEPTH_COMPONENT or DEPTH_STENCIL, and the
TEXTURE_COMPARE_MODE is NONE.
* The sampler used in a texture lookup function is one of the
shadow sampler types, and the texture object's base
internal format is not DEPTH_COMPONENT or DEPTH_STENCIL.
The stencil index texture internal component is ignored if the base
internal format is DEPTH_STENCIL.
If a vertex shader uses..."
Additions to Chapter 3 of the OpenGL 2.1 Specification (Rasterization)
Update section 3.6.3 "Pixel Transfer Modes", the first paragraph of
the subsection "Color Table Specification", in the definition of
ColorTable, to say:
"... The <formats> COLOR_INDEX, DEPTH_COMPONENT, DEPTH_STENCIL,
and STENCIL_INDEX and the <type> BITMAP are not allowed."
Update section 3.6.3 "Pixel Transfer Modes", the third paragraph of
the subsection "Color Table Specification", in the definition of
ColorTable, to say:
"... <internalformat> must be one of the formats in table 3.15 or
table 3.16, other than the DEPTH_COMPONENT or DEPTH_STENCIL
formats in those tables."
Add to section 3.6.3 "Pixel Transfer Modes", at the end of the
subsection titled "Alternate Color Table Specification Commands":
"Calling CopyColorTable or CopyColorSubTable will result in an
INVALID_FRAMEBUFFER_OPERATION error if the object bound to
READ_FRAMEBUFFER_BINDING is not "framebuffer complete"
(see section 4.4.4.2)."
In section 3.6.3 "Pixel Transfer Modes", the subsection "Covolution
Filter Specification", update the first paragraph in the definition
of ConvolutionFilter2D to say:
"... The formats COLOR_INDEX, DEPTH_COMPONENT, DEPTH_STENCIL,
and STENCIL_INDEX and the type BITMAP are not allowed."
In section 3.6.3 "Pixel Transfer Modes", update the third paragraph
of the subsection "Convolution Filter Specification", in the definition
of ConvolutionFilter2D, to say:
"... <internalformat> accepts the same values as the corresponding
argument of ColorTable."
Add to section 3.6.3 "Pixel Transfer Modes", at the end of the
subsection titled "Alternate Convolution Filter Specification Commands":
"Calling CopyConvolutionFilter1D or CopyConvolutionFilter2D will
result in an INVALID_FRAMEBUFFER_OPERATION error if the object
bound to READ_FRAMEBUFFER_BINDING is not "framebuffer
complete" (see section 4.4.4.2)."
In section 3.6.3 "Pixel Transfer Modes", update the third paragraph
of the "Histogram Table Specification" subsection , in the definition of
Histogram, to say:
"... is too large for the implementation. <internalformat> accepts the
same values as the corresponding argument of ColorTable, with the
exception of the values 1, 2, 3, and 4."
In section 3.6.3 "Pixel Transfer Modes", update the second paragraph
in the subsection titled "Minmax Table Specification", in the definition
of Minmax to say:
"<internalformat> accepts the same values as the corresponding argument
of ColorTable, with the exception of the values 1, 2, 3, and 4, as well
as the INTENSITY base and sized internal formats."
In section 3.6.4 "Rasterization of Pixel Rectangles", modify the final
paragraph of the definition of DrawPixels as follows:
"... If the GL is in color index mode and <format> is not one of
COLOR_INDEX, STENCIL_INDEX, DEPTH_COMPONENT, or DEPTH_STENCIL,
then the error INVALID_OPERATION occurs. If <type> is BITMAP and
<format> is not COLOR_INDEX or STENCIL_INDEX then the error
INVALID_ENUM occurs. If <format> is DEPTH_STENCIL and <type> is
not UNSIGNED_INT_24_8 then the error INVALID_ENUM occurs. Some
additional constraints on the combinations of <format> and <type>
values that are accepted is discussed below.
"Calling DrawPixels
will result in an INVALID_FRAMEBUFFER_OPERATION error if the
object bound to DRAW_FRAMEBUFFER_BINDING is not
"framebuffer complete" (see section 4.4.4.2)."
Add a row to Table 3.5, in section 3.6.4:
type Parameter GL Type Special
--------------------------- ------- -------
... ... ...
UNSIGNED_INT_2_10_10_10_REV uint Yes
UNSIGNED_INT_24_8 uint Yes
Add a row to Table 3.6, in section 3.6.4:
Format Name Element Meaning and Order Target Buffer
--------------- ------------------------- -----------------
... ... ...
DEPTH_COMPONENT Depth Depth
DEPTH_STENCIL Depth and Stencil Index Depth and Stencil
... ... ...
In section 3.6.4 "Rasterization of Pixel Rectangles", in the subsection
titled "Unpacking", update the last paragraph on page 131 to say:
"Calling DrawPixels with a <type> matching one of the types in table 3.8
is a special case in which all the components of each group are packed
into a single unsigned byte, unsigned short, or unsigned int, depending
on the type. The number of components..."
Add a row to Table 3.8, in section 3.6.4:
type Parameter GL Type Components Pixel Formats
--------------------------- ------- ---------- -------------
... ... ... ...
UNSIGNED_INT_2_10_10_10_REV uint 4 RGBA,BGRA
UNSIGNED_INT_24_8 uint 2 DEPTH_STENCIL
Add the following diagram to Table 3.11, in section 3.6.4:
UNSIGNED_INT_24_8
31 30 29 28 27 26 ... 12 11 10 9 8 7 6 5 4 3 2 1 0
+----------------------------------+---------------+
| 1st Component | 2nd Component |
+----------------------------------+---------------+
Add a row to Table 3.12, in section 3.6.4:
Format | 1st 2nd 3rd 4th
--------------+-------------------------------
... | ... ... ... ...
BGRA | blue green red alpha
DEPTH_STENCIL | depth stencil N/A N/A
In section 3.6.4 "Rasterization of Pixel Rectangles", add the
following sentence to the end of the first paragraph in "Conversion
to floating-point":
"For groups containing both components and indices, such as
DEPTH_STENCIL, the indices are not converted."
In section 3.6.4 "Rasterization of Pixel Rectangles", update the
last paragraph in the section "Conversion to Fragments" to say:
"... Groups arising from DrawPixels with a <format> of STENCIL_INDEX
or DEPTH_STENCIL are treated specially and are described in
section 4.3.1."
Update the first paragraph of section 3.6.5 "Pixel Transfer
Operations" to say:
"The GL defines five kinds of pixel groups:
1. RGBA component: Each group comprises four color components:
red, green, blue, and alpha.
2. Depth component: Each group comprises a single depth
component.
3. Color index: Each group comprises a single color index.
4. Stencil index: Each group comprises a single stencil index.
5. Depth/stencil: Each group comprises a single depth component
and a single stencil index."
In section 3.6.5 "Pixel Transfer Operations" update the first paragraph
in the subsection "Arithmetic on Components" to say:
"This step applies only to RGBA component and depth component
groups, and to the depth components in depth/stencil groups. ..."
In section 3.6.5 "Pixel Transfer Operations" update the first paragraph
in the subsection "Arithmetic on Indices" to say:
"This step applies only to color index and stencil index groups, and
to the stencil indices in depth/stencil groups. ..."
In section 3.6.5 "Pixel Transfer Operations" update the first paragraph
in the subsection "Stencil Index Lookup" to say:
"This step applies only to stencil index groups and to the stencil
indices in depth/stencil groups. ..."
Add the following to section 3.7 "Bitmaps", following the description of
Bitmap:
"Calling Bitmap will result in an
INVALID_FRAMEBUFFER_OPERATION error if the object bound to
DRAW_FRAMEBUFFER_BINDING is not "framebuffer complete"
(see section 4.4.4.2)."
In section 3.8.1 "Texture Image Specification", update the following
paragraphs as follows:
Update the fourth paragraph to say:
"The selected groups are processed exactly as for DrawPixels,
stopping just before final conversion. Each R, G, B, A, or depth
value so generated is clamped to [0, 1], while the stencil index
values are masked by 2^n-1, where n is the number of stencil bits in
the internal format resolution (see below). If the base internal
format is DEPTH_STENCIL and <format> is not DEPTH_STENCIL,
then the values of the stencil index texture component are
undefined."
Update the fifth paragraph to say:
"Components are then selected from the resulting R, G, B, A, depth,
or stencil index values to obtain a texture with the base internal
format specified by (or derived from) <internalformat>. Table 3.15
summarizes the mapping of R, G, B, A, depth, or stencil values to
texture components, as a function of the base internal format of the
texture image. <internalformat> may be specified as one of the
eight internal format symbolic constants listed in table 3.15, as
one of ..."
Update the sixth paragraph to say:
"Textures with a base internal format of DEPTH_COMPONENT or
DEPTH_STENCIL are supported by texture image specification
commands only if <target> is TEXTURE_1D, TEXTURE_2D,
PROXY_TEXTURE_1D or PROXY_TEXTURE_2D. Using these formats in
conjunction with any other <target> will result in an
INVALID_OPERATION error."
Update the seventh paragraph to say:
Textures with a base internal format of DEPTH_COMPONENT or
DEPTH_STENCIL require either depth component data or
depth/stencil component data. Textures with other base internal
formats require RGBA component data. The error INVALID_OPERATION is
generated if one of the base internal format and <format>
is DEPTH_COMPONENT or DEPTH_STENCIL, and the other is neither
of these values."
Update the tenth paragraph to say:
"...the mapping of the R, G, B, A, depth and stencil values to
texture components..."
Add a row to table 3.15 in section 3.8.1, and update the title of the
second column:
Base Internal Format RGBA and Depth and Stencil Values Internal Components
-------------------- --------------------------------- -------------------
... ... ...
DEPTH_STENCIL Depth,Stencil D,S
... ... ...
Update the caption for table 3.15
"Table 3.15: Conversion from RGBA, depth, and stencil pixel
components to internal texture, table, or filter components. See
section 3.8.13 for a description of the texture components R, G, B,
A, L, I, D, and S."
Add a new column to table 3.16, in section 3.8.1, labeled "S bits". The
value of this column is blank for all rows except a new row:
Sized Base R G B A L I D S
Internal Format InternalFormat bits bits bits bits bits bits bits bits
---------------- -------------- ---- ---- ---- ---- ---- ---- ---- ----
... ... ... ... ... ... ... ... ... ...
DEPTH24_STENCIL8 DEPTH_STENCIL 24 8
... ... ... ... ... ... ... ... ... ...
In section 3.8.2 "Alternate Texture Image Specification Commands",
update the second paragraph, in the definition of CopyTexImage2D, to
say:
"...The image is taken from the framebuffer exactly as if these
arguments were passed to CopyPixels with argument type set to COLOR
DEPTH, or DEPTH_STENCIL, depending on <internalformat>, stopping
after pixel transfer processing is complete. RGBA data is taken
from the current color buffer, while depth component and stencil
index data are taken from the depth and stencil buffers,
respectively. If depth component data is required and no depth
buffer is present, or if stencil index data is required and there is
no stencil buffer, the error INVALID_OPERATION is generated.
Subsequent processing is identical to that described for TexImage2D,
beginning with clamping of the R, G, B, A, or depth values, and
masking of the stencil index value, from the resulting pixel
groups..."
Update the third paragraph to say:
"Subsequent processing is identical to that described for TexImage2D,
beginning with clamping of the R, G, B, A, or depth values, and masking
of the stencil index values from the resulting pixel groups..."
In section 3.8.2 "Alternate Texture Image Specification Commands",
update the seventh paragraph, in the description of the
CopyTexSubImage{2|3}D arguments, to say:
"...except that the assignment of R, G, B, A, depth, and stencil
pixel group values to the texture components is controlled by the
internalformat of the texture array, not by an argument to the
command..."
Append the following to section 3.8.2 "Alternate Texture Image
Specification Commands":
"Calling CopyTexSubImage3D, CopyTexImage2D,
CopyTexSubImage2D, CopyTexImage1D or CopyTexSubImage1D will result
in an INVALID_FRAMEBUFFER_OPERATION error if the object bound
to READ_FRAMEBUFFER_BINDING is not "framebuffer complete"
(see section 4.4.4.2)."
Update section 3.8.5 "Depth Component Textures" to say:
"Depth textures and the depth components of depth/stencil textures
can be treated as LUMINANCE, INTENSITY or ALPHA textures during
texture filtering and application. The initial state for depth and
depth/stencil textures treats them as LUMINANCE textures."
In section 3.8.8 "Texture Minification", add the following text
immediately before the subsection "Mipmapping":
"If all of the following conditions are satisfied, then the value of
the selected Tau(ijk), Tau(ij), or Tau(i) in the above equations is
undefined instead of referring to the value of the texel at location
(i), (i,j), or (i,j,k). See Chapter 4 for discussion of framebuffer
objects and their attachments.
* The current DRAW_FRAMEBUFFER_BINDING names an application-created
framebuffer object <F>.
* The texture is attached to one of the attachment points, <A>, of
framebuffer object <F>.
* The value of TEXTURE_MIN_FILTER is NEAREST or LINEAR, and the value
of FRAMEBUFFER_ATTACHMENT_TEXTURE_LEVEL for attachment point <A>
is equal to the value of TEXTURE_BASE_LEVEL
-or-
The value of TEXTURE_MIN_FILTER is NEAREST_MIPMAP_NEAREST,
NEAREST_MIPMAP_LINEAR, LINEAR_MIPMAP_NEAREST, or
LINEAR_MIPMAP_LINEAR, and the value of
FRAMEBUFFER_ATTACHMENT_TEXTURE_LEVEL for attachment point
<A> is within the inclusive range from TEXTURE_BASE_LEVEL to q."
In subsection "Automatic Mipmap Generation" to section 3.8.8,
replace the first paragraph with the following text and footnote:
"If the value of texture parameter GENERATE MIPMAP is TRUE and a
change is made to the interior or border texels of the level_base
array of a mipmap by one of the texture image specification
operations defined in sections 3.8.1 through 3.8.3, then a complete
set of mipmap arrays (as defined in section 3.8.10) will be
computed. Array levels level_base + 1 through p are replaced with
arrays derived from the modified level_base, regardless of their
previous contents. All other mipmap arrays, including the
level_base array, are left unchanged by this computation[fn1]."
"[fn1] Automatic mipmap generation is not performed for changes
resulting from rendering operations targeting a texture array
bound as a color buffer of a framebuffer object."
Add a new subsection "Manual Mipmap Generation" to section 3.8.8,
after "Automatic Mipmap Generation":
"Manual Mipmap Generation
Mipmaps can be generated manually with the command
void GenerateMipmap(enum target);
where <target> is one of TEXTURE_1D, TEXTURE_2D, TEXTURE_CUBE_MAP, or
TEXTURE_3D. Mipmap generation affects the texture image attached to
<target>. For cube map textures, an INVALID_OPERATION error is generated
if the texture bound to <target> is not cube complete, as defined in
section 3.8.10.
Mipmap generation replaces texture array levels level_base + 1
through q with arrays derived from the level_base array, as
described above under Automatic Mipmap Generation. All other mipmap
arrays, including the level_base array, are left unchanged by this
computation. For arrays in the range level_base+1 through q,
inclusive, automatic and manual mipmap generation generate the same
derived arrays, given identical level_base arrays."
Add a new section between sections 3.8.9 and 3.8.10:
"3.8.10 DEPTH_STENCIL Textures
If the texture image has a base internal format of
DEPTH_STENCIL, then the stencil index texture component is
ignored. The texture value Tau does not include a stencil index
component, but includes only the depth component."
Update the first paragraph of section 3.8.11 "Texture State and
Proxy State" to say:
"...eight integer values describing the resolutions of each of the
red, green, blue, alpha, luminance, intensity, depth, and stencil
components of the image..."
Update the second paragraph of section 3.8.11 "Texture State and
Proxy State" to say:
"... and internal format state values, as well as state for the red,
green, blue, alpha, luminance, intensity, depth, and stencil
component resolutions."
Modify the definition of DeleteTextures in section 3.8.12 "Texture
Objects", to read:
"Texture objects are deleted by calling
void DeleteTextures( sizei n, uint *textures );
textures contains n names of texture objects to be deleted. After a
texture object is deleted, it has no contents or dimensionality, and
its name is again unused. If a texture that is currently bound to
one of the targets TEXTURE 1D, TEXTURE 2D, TEXTURE 3D, or TEXTURE
CUBE MAP is deleted, it is as though BindTexture had been executed
with the same target and texture zero. Additionally, special care
must be taken when deleting a texture if any of the images of the
texture are attached to a framebuffer object. See section 4.4.2.3
for details.
Unused names in textures are silently ignored, as is the value
zero."
In section 3.8.14 "Texture Comparison Modes", update the first
paragraph of "Depth Texture Comparison Mode" subsection to say:
"If the currently bound texture's base internal format is
DEPTH_COMPONENT or DEPTH_STENCIL..."
In the section 3.8.16 "Texture Application", update the first
paragraph of to say:
"...Otherwise, a texture value is found according to the parameter
values of the currently bound texture image of the appropriate
dimensionality using the rules given in sections 3.8.6 through
3.8.9. Note that the texture value may contain R, G, B, A, L, I, or
D components, but it does not contain an S component. If the
texture's base internal format is DEPTH_STENCIL, for the
purposes of texture application, it is as if the base internal
format were DEPTH_COMPONENT..."
In section 3.11.2 "Shader Execution", in the bulleted list
in the "Texture Access" subsection to say:
"* The sampler used in a texture lookup function is not one of the
shadow sampler types, the texture object's base internal
format is DEPTH_COMPONENT or DEPTH_STENCIL, and the
TEXTURE_COMPARE_MODE is not NONE.
* The sampler used in a texture lookup function is one of the
shadow sampler types, the texture object's base
internal format is DEPTH_COMPONENT or DEPTH_STENCIL, and the
TEXTURE_COMPARE_MODE is NONE.
* The sampler used in a texture lookup function is one of the
shadow sampler types, and the texture object's base
internal format is not DEPTH_COMPONENT or DEPTH_STENCIL.
The stencil index texture internal component is ignored if the base
internal format is DEPTH_STENCIL.
If a fragment shader uses..."
Additions to Chapter 4 of the OpenGL 2.1 Specification (Per-Fragment
Operations and the Framebuffer)
In the introduction to chapter 4, modify the first
three paragraphs to read as follows:
"The framebuffer, whether it is the default framebuffer or a framebuffer
object (see section 2.1), consists of a set of pixels arranged as a
two-dimensional array.
For purposes of this
discussion, each pixel in the framebuffer is simply a set of some
number of bits. The number of bits per pixel may vary
depending on the GL implementation, the type of framebuffer
selected, and parameters specified when the framebuffer was created.
Creation and management of the default framebuffer is outside the scope
of this specification, while creation and management of framebuffer
objects is described in detail in section 4.4
Corresponding bits from each pixel in the framebuffer are grouped
together into a <bitplane>; each bitplane contains a single bit from
each pixel. These bitplanes are grouped into several <logical
buffers>. These are the color, accumulation, depth, and stencil
buffers. The color buffer actually consists of a number of buffers,
and these color buffers serve related but slightly different
purposes depending on whether the GL is bound to the default
framebuffer or a framebuffer object.
For the default framebuffer, the color buffers are the <front left>
buffer, the <front right> buffer, the <back left> buffer, the <back
right> buffer, and some number of <auxiliary> buffers. Typically, the
contents of the front buffers are displayed on a color monitor while the
contents of the back buffers are invisible. (Monoscopic contexts display
only the front left buffer; stereoscopic contexts display both the front
left and the front right buffers.) The contents of the auxiliary buffers
are never visible. All color buffers must have the same number of
bitplanes, although an implementation or context may choose not to
provide right buffers, back buffers, or auxiliary buffers at all.
Further, an implementation or context may choose not to provide
accumulation, depth, or stencil buffers. If no default framebuffer is
associated with the GL context, the framebuffer is incomplete except
when a framebuffer object is bound (see sections 4.4.1 and 4.4.4).
Framebuffer objects are not visible, and do not have any of the color
buffers present in the default framebuffer. Instead, the buffers of an
framebuffer object are specified by attaching individual textures or
renderbuffers (see section 4.4) to a set of attachment points. A
framebuffer object has an array of color buffer attachment points,
numbered zero through <n>, a depth buffer attachment point, and a
stencil buffer attachment point. In order to be used for rendering, a
framebuffer object must be complete, as described in section 4.4.4. Not
all attachments of a framebuffer object need to be populated.
Each pixel in a color buffer consists of either an unsigned integer
color index or of up to four color components. The four color components
are named R, G, B, and A, in that order; color buffers are not required
to have all four color components. R, G, B, and A components may be
represented as signed or unsigned normalized fixed-point,
floating-point, or signed or unsigned integer values; all components
must have the same representation. Each pixel in a depth buffer consists
of a single unsigned integer value in the format described in section
2.12.1 or a floating-point value. Each pixel in a stencil buffer
consists of a single unsigned integer value. Each pixel in an
accumulation buffer consists of up to four color components. If an
accumulation buffer is present, it must have at least as many bitplanes
per component as in the color buffers.
The number of bitplanes in the accumulation, color, depth, and stencil
buffers is dependent on the currently bound framebuffer. For the default
framebuffer, the number of bitplanes is fixed. For framebuffer objects,
the number of bitplanes in a given logical buffer may change if the
image attached to the corresponding attachment point changes.
The GL has two active framebuffers; the <draw framebuffer> is the
destination for rendering operations, and the <read framebuffer> is the
source for readback operations. The same framebuffer may be used for
both drawing and reading. Section 4.4.1 describes the mechanism for
controlling framebuffer usage."
The default framebuffer is initially used as the draw and read
framebuffer [fn1], and the initial state of all provided bitplanes is
undefined. The format and encoding of buffers in the draw and read
framebuffers can be queried as described in section 6.1.3.
[fn1] The window system binding API may allow associating a GL
context with two separate ``default framebuffers'' provided by
the window system as the draw and read framebuffers, but if
so, both default framebuffers are referred to by the name zero
at their respective binding points.
Add a new paragraph to the end of section 4.1.1 "Pixel Ownership Test":
"If the draw framebuffer is a framebuffer object (see section 4.2.1),
the pixel ownership test always passes, since the pixels of framebuffer
objects are owned by the GL, not the window system. If the draw
framebuffer is the default framebuffer, the window system controls pixel
ownership."
Change section 4.1.5 "Stencil Test", the fifth paragraph,
the second and third sentences, to read as follows:
"<ref> is an integer reference value that is used in the unsigned
stencil comparison. Stencil comparison operations and queries of
of <ref> clamp its value to the range [0,(2^s)-1], where <s> is the
number of bits in the stencil buffer attached to the draw framebuffer.
Replace the first three sentences of 4.1.10 "Logical Operation":
"Finally, a logical operation is applied between the incoming
fragment's color or index values and the color or index values
stored at the corresponding location in the framebuffer. The result
replaces the values in the framebuffer at the fragment's (x[w],
y[w]) coordinates. If the selected draw buffers refer to the same
framebuffer-attachable image more than once, then the values stored
in that image are undefined."
Change section 4.2.1 "Selecting a Buffer for Writing", to read as follows:
"The first such operation is controlling the buffers into which each of
the fragment color values is written. This is accomplished with either
DrawBuffer or DrawBuffers. The command
void DrawBuffer( enum buf );
defines the set of color buffers to which fragment color zero is
written. <buf> must be one of the values from tables 4.4 or 10.nnn. In
addition, acceptable values for <buf> depend on whether the GL is using
the default framebuffer (i.e., DRAW_FRAMEBUFFER_BINDING is zero), or a
framebuffer object (i.e., DRAW_FRAMEBUFFER_BINDING is non-zero). In the
initial state, the GL is bound to the default framebuffer. For more
information about framebuffer objects, see section 4.4.
If the GL is bound to the default framebuffer, then
<buf> must be one the values listed in table 4.4, which summarizes
the constants and the buffers they indicate. In this case, <buf> is
a symbolic constant specifying zero, one, two, or four buffers for
writing. These constants refer to the four potentially visible
buffers front left, front right, back left, and back right, and to
the auxiliary buffers. Arguments other than AUXi that omit
reference to LEFT or RIGHT refer to both left and right buffers.
Arguments other than AUXi that omit reference to FRONT or BACK refer
to both front and back buffers. AUXi enables drawing only to
auxiliary buffer i. Each AUXi adheres to AUXi = AUX0 + i,
and i must be in the range 0 to the value of AUX_BUFFERS minus one.
If the GL is bound to a framebuffer object,
<buf> must be one of the values listed in table 10.nnn, which
summarizes the constants and the buffers they indicate. In this
case, <buf> is a symbolic constant specifying a single color buffer
for writing. Specifying COLOR_ATTACHMENTi enables drawing only
to the image attached to the framebuffer at COLOR_ATTACHMENTi.
Each COLOR_ATTACHMENTi adheres to COLOR_ATTACHMENTi =
COLOR_ATTACHMENT0 + i. The initial value of DRAW_BUFFER for
application-created framebuffer objects is COLOR_ATTACHMENT0.
Symbolic Constant Meaning
----------------- -------
NONE no buffer
COLOR_ATTACHMENTi (see caption) output fragment color to image attached
at color attachment point i
-------------------------------------------------------------------
Table 10.nnn: Arguments to DrawBuffer(s) and ReadBuffer when the
context is bound to a framebuffer object, and
the buffers they indicate. i in COLOR_ATTACHMENTi may range from
zero to the value of MAX_COLOR_ATTACHMENTS - 1.
If the GL is bound to the default framebuffer and
DrawBuffer is supplied with a constant (other than NONE) that does
not indicate any of the color buffers allocated to the GL context,
the error INVALID_OPERATION results.
If the GL is bound to a framebuffer object and <buf> is one of the
constants from table 4.4, then the error INVALID_OPERATION results.
If <buf> is COLOR_ATTACHMENT<m> and <m> is greater than or equal to
the value of MAX_COLOR_ATTACHMENTS, then the error INVALID_VALUE
results.
If DrawBuffer is supplied with a constant that is neither legal for
the default framebuffer nor a framebuffer object, then the error
INVALID_ENUM results.
DrawBuffer will set the draw buffer for fragment colors other than
zero to NONE.
The command
void DrawBuffers( sizei n, const enum *bufs );
defines the draw buffers to which all fragment colors are written.
<n> specifies the number of buffers in <bufs>. <bufs> is a pointer
to an array of symbolic constants specifying the buffer to which
each fragment color is written.
Each buffer listed in <bufs> must be one of the values from tables
10.nnn or 11.nnn. Otherwise, an INVALID_ENUM error is generated.
Further, acceptable values for the constants in <bufs> depend on
whether the GL is using the default
framebuffer (i.e., DRAW_FRAMEBUFFER_BINDING is zero), or an
framebuffer object (i.e.,
DRAW_FRAMEBUFFER_BINDING is non-zero). For more information about
framebuffer objects, see section 4.4.
symbolic front front back back aux
constant left right left right i
-------- ----- ----- ---- ----- ---
NONE
FRONT LEFT X
FRONT RIGHT X
BACK LEFT X
BACK RIGHT X
AUXi X
--------------------------------------------------
Table 11.nnn: Arguments to DrawBuffers, when the context is bound
to the default framebuffer, and the buffers that they indicate.
If the GL is bound to the default
framebuffer, then each of the constants must be one of the
values listed in table 11.nnn.
If the GL is bound to a framebuffer object,
then each of the constants must be one of the values listed in table
10.nnn.
In both cases, the draw buffers being defined correspond in order to
the respective fragment colors. The draw buffer for fragment colors
beyond <n> is set to NONE.
The maximum number of draw buffers is implementation dependent and
must be at least 1. The number of draw buffers supported can be
queried by calling GetIntegerv with the symbolic constant
MAX_DRAW_BUFFERS. An INVALID_VALUE error is generated if <n> is
greater than MAX_DRAW_BUFFERS.
Except for NONE, a buffer may not appear more then once in the array
pointed to by <bufs>. Specifying a buffer more then once will
result in the error INVALID_OPERATION.
If fixed-function fragment shading is being performed, DrawBuffers
specifies a set of draw buffers into which the fragment color is
written.
If a fragment shader writes to "gl_FragColor", DrawBuffers specifies
a set of draw buffers into which the single fragment color defined
by "gl_FragColor" is written. If a fragment shader writes to
"gl_FragData", DrawBuffers specifies a set of draw buffers into which
each of the multiple fragment colors defined by "gl_FragData" are
separately written. If a fragment shader writes to neither
"gl_FragColor" nor "gl_FragData", the values of the fragment colors
following shader execution are undefined, and may differ for each
fragment color.
For both the default framebuffer and framebuffer objects,
the constants FRONT, BACK, LEFT, RIGHT, and
FRONT_AND_BACK are not valid in the <bufs> array passed to
DrawBuffers, and will result in the error INVALID_OPERATION. This
restriction is because these constants may themselves refer to
multiple buffers, as shown in table 4.4.
If the GL is bound to the default framebuffer and
DrawBuffers is supplied with a constant (other than NONE) that does
not indicate any of the color buffers allocated to the GL context by
the window system, the error INVALID_OPERATION will be generated.
If the GL is bound to a framebuffer object and
DrawBuffers is supplied with a constant from table 11.nnn, or
COLOR_ATTACHMENTm where m is greater than or equal to the value of
MAX_COLOR_ATTACHMENTS, then the error INVALID_OPERATION results.
Indicating a buffer or buffers using DrawBuffer or DrawBuffers
causes subsequent pixel color value writes to affect the indicated
buffers.
Specifying NONE as the draw buffer for a fragment color will inhibit
that fragment color from being written to any buffer.
Monoscopic contexts include only left buffers, while stereoscopic
contexts include both left and right buffers. Likewise, single
buffered contexts include only front buffers, while double buffered
contexts include both front and back buffers. The type of context
is selected at GL initialization.
The state required to handle color buffer selection for each
framebuffer is an integer
for each supported fragment color. For the default
framebuffer, in the initial state, the draw
buffer for fragment color zero is FRONT if there are no back
buffers; otherwise it is BACK. For framebuffer
objects, in the initial state the draw buffer for fragment color zero is
COLOR_ATTACHMENT0. For both the default
framebuffer and framebuffers objects, the initial state
of draw buffers for fragment colors other then zero is NONE.
The value of the draw buffer selected for fragment color <i> can be
queried by calling GetIntegerv with the symbolic constant DRAW_BUFFERi.
DRAW_BUFFER is equivalent to DRAW_BUFFER0."
In section 4.2.2 "Fine Control of Buffer Updates", modify the beginning
of the paragraph defining <mask> for StencilMask and StencilMaskSeparate
as follows:
Modify the second to last paragraph of section 4.2.4 "The Accumulation
Buffer" as follows:
"If there is no accumulation buffer, or if the DRAW_FRAMEBUFFER
and READ_FRAMEBUFFER bindings (see section 4.4.4.2) do not refer to
the same object, or if the GL is in color index mode, Accum
generates the error INVALID_OPERATION."
Replace section 4.3.1 "Writing to the Stencil Buffer" with the following:
"4.3.1 Writing to the Stencil Buffer or to the Depth and Stencil
Buffers
The operation of DrawPixels was described in section 3.6.4, except
if the <format> argument was STENCIL_INDEX or DEPTH_STENCIL. In
this case, all operations described for DrawPixels take place, but
window (x,y) coordinates, each with the corresponding stencil index,
or depth value and stencil index, are produced in lieu of fragments.
Each coordinate-data pair is sent directly to the per-fragment
operations, bypassing the texture, fog, and antialiasing application
stages of rasterization. Each pair is then treated as a fragment
for purposes of the pixel ownership and scissor tests; all other
per-fragment operations are bypassed. Finally, each stencil index
is written to its indicated location in the framebuffer, subject to
the current front stencil mask (set with StencilMask or
StencilMaskSeparate). If a depth component is present, and if the
setting of DepthMask is not FALSE, the depth component is also
written to the framebuffer; the setting of DepthTest is ignored.
The error INVALID_OPERATION results if the <format> argument is
STENCIL_INDEX and there is no stencil buffer, or if <format> is
DEPTH_STENCIL and there is not both a depth buffer and a stencil
buffer."
Add to 4.3.2 "Reading Pixels", right before the subsection titled
"Obtaining Pixels from the Framebuffer":
"ReadPixels generates an INVALID_OPERATION error
if READ_FRAMEBUFFER_BINDING
(see section 4.4) is non-zero, the read framebuffer is framebuffer
complete, and the value of SAMPLE_BUFFERS for the read framebuffer
is greater than zero."
In section 4.3.2 "Reading Pixels", add the following paragraph
after the second paragraph of the section "Obtaining Pixels from
the Framebuffer":
"If the <format> is DEPTH_STENCIL, then values are taken from
both the depth buffer and the stencil buffer. If there is no depth
buffer or if there is no stencil buffer, then the error
INVALID_OPERATION occurs. If the <type> parameter is not
UNSIGNED_INT_24_8, then the error INVALID_ENUM occurs.
If there is a multisample buffer, then values are obtained from the
depth and stencil samples in this buffer. It is recommended that the
depth and stencil values of the centermost sample be used, though
implementations may choose any function of the depth and stencil
sample values at each pixel."
In section 4.3.2 "Reading Pixels" in the subsection "Obtaining Pixels
from the Framebuffer", modify the first two paragraphs of the
definition of ReadBuffer to read as follows:
"The command
void ReadBuffer( enum src );
takes a symbolic constant as argument. <src> must be one of the
values from tables 4.4 or 10.nnn. Otherwise, INVALID_ENUM is
generated. Further, the acceptable values for <src> depend on
whether the GL is using the default
framebuffer (i.e., READ_FRAMEBUFFER_BINDING is zero), or a
framebuffer object (i.e.,
READ_FRAMEBUFFER_BINDING is non-zero). For more information about
framebuffer objects, see section 4.4.
If the object bound to READ_FRAMEBUFFER_BINDING is not <framebuffer
complete> (as defined in section 4.4.4.2), then ReadPixels generates
the error INVALID_FRAMEBUFFER_OPERATION. If ReadBuffer is
supplied with a constant that is neither legal for the default
framebuffer, nor legal for a
framebuffer object, then the error INVALID_ENUM results.
When READ_FRAMEBUFFER_BINDING is zero, i.e. the default framebuffer,
<src> must be one of the values listed in table 4.4, including NONE.
FRONT_AND_BACK, FRONT, and LEFT refer to the front left buffer, BACK
refers to the back left buffer, and RIGHT refers to the front right
buffer. The other constants correspond directly to the buffers that they
name. If the requested buffer is missing, then the error
INVALID_OPERATION is generated. For the default framebuffer, the initial
setting for ReadBuffer is FRONT if there is no back buffer and BACK
otherwise.
When the GL is using a framebuffer object, <src> must be one of the
values listed in table 10.nnn, including NONE. In a manner analogous to
how the DRAW_BUFFERs state is handled, specifying COLOR_ATTACHMENTi
enables reading from the image attached to the framebuffer at
COLOR_ATTACHMENTi. For framebuffer objects, the initial setting for
ReadBuffer is COLOR_ATTACHMENT0.
ReadPixels generates an INVALID_OPERATION error if it attempts to select
a color buffer while READ_BUFFER is NONE.
ReadPixels obtains values from the selected buffer from each pixel
with lower left hand corner at (x+i, y+j) for (0 <= i < width) and
(0 <= j < height); this pixel is said to be the ith pixel in the jth
row. If any of these pixels lies outside of the window allocated to
the current GL context, or outside of the image attached to the
currently bound framebuffer object, then the values obtained for
those pixels are undefined. When READ_FRAMEBUFFER_BINDING is zero,
results are also undefined for individual pixels that are not owned
by the current context. Otherwise, ReadPixels obtains values from
the selected buffer, regardless of how those values were placed
there."
In section 4.3.2 "Reading Pixels", modify the last paragraph of the
subsection "Obtaining Pixels from the Framebuffer", to say:
"... If the GL is in color index mode, and <format> is not
DEPTH_COMPONENT, STENCIL_INDEX, or DEPTH_STENCIL, then the color
index is obtained at each pixel location."
In section 4.3.2 "Reading Pixels", add a paragraph at the end of the
subsection "Obtaining Pixels from the Framebuffer" immediately before
"Conversion of RGBA values":
"When READ_FRAMEBUFFER_BINDING is non-zero, the red, green, blue, and
alpha values are obtained by first reading the internal component
values of the corresponding value in the image attached to the
selected logical buffer. Internal components are converted to an
RGBA color by taking each R, G, B, and A component present according
to the base internal format of the buffer (as shown in table 3.15).
If G, B, or A values are not present in the internal format, they
are taken to be zero, zero, and one respectively.
In section 4.3.2 "Reading Pixels", update the first sentence of the
subsection "Conversion of RGBA values" to say:
"This step applies only if the GL is in RGBA mode, and then only if
<format> is neither STENCIL_INDEX, DEPTH_COMPONENT, nor
DEPTH_STENCIL."
In section 4.3.2 "Reading Pixels", update the section "Conversion
of Depth values" to say:
"This step applies only if <format> is DEPTH_COMPONENT or
DEPTH_STENCIL. Each element taken from the depth buffer is
taken to be a fixed-point value in [0,1] with m bits, where m is the
number of bits in the depth buffer (see section 2.11.1)."
Add a row to Table 4.6, in section 4.3.2 "Reading Pixels":
type Parameter Index Mask
----------------- ----------
... ...
INT 2^31-1
UNSIGNED_INT_24_8 2^8-1
Modify the first sentence of section 4.3.3 "Copying Pixels" as follows:
"CopyPixels transfers a rectangle of pixel values from one region
of the read framebuffer to another in the draw framebuffer."
In section 4.3.3 "Copying Pixels", update the second and third
paragraphs to say:
"<type> is a symbolic constant that must be one of COLOR, STENCIL,
DEPTH, or DEPTH_STENCIL, indicating that the values to be
transferred are colors, stencil values, depth values, or
depth/stencil values, respectively. The first four arguments have the
same interpretation as the corresponding arguments to ReadPixels.
Values are obtained from the framebuffer, converted (if
appropriate), then subjected to the pixel transfer operations
described in section 3.6.5, just as if ReadPixels were called with
the corresponding arguments. If the <type> is STENCIL or DEPTH,
then it is as if the <format> for ReadPixels were STENCIL_INDEX, or
DEPTH_COMPONENT, respectively. If the <type> is DEPTH_STENCIL,
then it is as if the <format> for ReadPixels were specified as
described in table 4.6b. If the <type> is COLOR, then if the GL is
in RGBA mode, it is as if the <format> were RGBA, while if the GL is
in color index mode, it is as if the <format> were COLOR_INDEX."
Add Table 4.6b:
DEPTH_BITS STENCIL_BITS format
---------- ------------ ---------------
zero zero DEPTH_STENCIL
zero non-zero DEPTH_COMPONENT
non-zero zero STENCIL_INDEX
non-zero non-zero DEPTH_STENCIL
Table 4.6b: Effective ReadPixels format for DEPTH_STENCIL
CopyPixels operation.
Add a row to Table 4.7 (page 224):
type Parameter GL Type Component Conversion ...
--------------------------- ------- ---------------------------
... ... ...
UNSIGNED_INT_2_10_10_10_REV uint c = (2^N - 1)f
UNSIGNED_INT_24_8 uint c = (2^N - 1)f (depth only)
Add the following text to section 4.3.3 "Copying Pixels", inside the
definition of CopyPixels:
"Finally, the behavior of several GL operations is specified "as if
the arguments were passed to CopyPixels." These operations include:
CopyTex{Sub}Image*, CopyColor{Sub}Table, and CopyConvolutionFilter*.
An INVALID_FRAMEBUFFER_OPERATION error will be generated if an attempt is
made to execute one of these operations, or CopyPixels, while the
object bound to READ_FRAMEBUFFER_BINDING (see section 4.4) is not
"framebuffer complete" (as defined in section 4.4.4.2).
An INVALID_OPERATION error will be generated if the object bound to
READ_FRAMEBUFFER_BINDING is "framebuffer complete" and the value
of SAMPLE_BUFFERS is greater than zero.
CopyPixels will generate an INVALID_FRAMEBUFFER_OPERATION error
if the object bound to DRAW_FRAMEBUFFER_BINDING (see section
4.4) is not "framebuffer complete".
Append to section 4.3.3 "Copying Pixels":
"The command
BlitFramebuffer(int srcX0, int srcY0, int srcX1, int srcY1,
int dstX0, int dstY0, int dstX1, int dstY1,
bitfield mask, enum filter);
transfers a rectangle of pixel values from one
region of the read framebuffer to another in the draw framebuffer.
There are some important distinctions from CopyPixels, as
described below.
<mask> is the bitwise OR of a number of values indicating which
buffers are to be copied. The values are COLOR_BUFFER_BIT,
DEPTH_BUFFER_BIT, and STENCIL_BUFFER_BIT, which are described in
section 4.2.3. The pixels corresponding to these buffers are
copied from the source rectangle bounded by the locations (srcX0,
srcY0) and (srcX1, srcY1), to the destination rectangle bounded by
the locations (dstX0, dstY0) and (dstX1, dstY1). The lower bounds
of the rectangle are inclusive, while the upper bounds are
exclusive.
When the color buffer is transferred, values are taken from the read
buffer of the read framebuffer and written to each of the draw buffers
of the draw framebuffer, just as with CopyPixels.
The actual region taken from the read framebuffer is limited to the
intersection of the source buffers being transferred, which may include
the color buffer selected by the read buffer, the depth buffer, and/or
the stencil buffer depending on <mask>.
The actual region written to the draw framebuffer is limited to the
intersection of the destination buffers being written, which may include
multiple draw buffers, the depth buffer, and/or the stencil buffer
depending on <mask>
Whether or not the source or destination regions are altered due to
these limits, the scaling and offset applied to pixels being transferred
is performed as though no such limits were present.
If the source and destination rectangle dimensions do not match,
the source image is stretched to fit the destination
rectangle. <filter> must be LINEAR or NEAREST and specifies the
method of interpolation to be applied if the image is
stretched. LINEAR filtering is allowed only for the color buffer;
if <mask> includes DEPTH_BUFFER_BIT or STENCIL_BUFFER_BIT, and
filter is not NEAREST, no copy is performed and an
INVALID_OPERATION error is generated. If the source and
destination dimensions are identical, no filtering is applied. If
either the source or destination rectangle specifies a negative
width or height (X1 < X0 or Y1 < Y0),
the image is reversed in the corresponding direction.
If both the source and destination rectangles specify a negative
dimension for the same direction, no reversal is performed.
If a linear filter is selected and the rules of LINEAR sampling
would require sampling outside the bounds of a source buffer, it is
as though CLAMP_TO_EDGE texture sampling were being performed. If a
linear filter is selected and sampling would be required outside the
bounds of the specified source region, but within the bounds of a
source buffer, the implementation may choose to clamp while sampling
or not.
If the source and destination buffers are identical, and the
source and destination rectangles overlap, the result of the blit
operation is undefined.
Blit operations bypass the fragment pipeline. The only fragment
operations which affect a blit are the pixel ownership test and
the scissor test.
If a buffer is specified in <mask> and does not exist in both the
read and draw framebuffers, the corresponding bit is silently
ignored.
If the color formats of the read and draw framebuffers do not
match, and <mask> includes COLOR_BUFFER_BIT, pixel groups are
converted to match the destination format as in CopyPixels.
However, no pixel transfer operations are applied, and clamping
behaves as if CLAMP_FRAGMENT_COLOR_ARB is set to FIXED_ONLY_ARB.
Format conversion is not supported for all data types. If the read
buffer contains floating-point values and any draw buffer does not
contain floating-point values, or if the read buffer contains
non-floating-point values and any draw buffer contains
floating-point values, an INVALID_OPERATION error is generated.
Calling BlitFramebuffer will result in an
INVALID_FRAMEBUFFER_OPERATION error if the objects bound to
DRAW_FRAMEBUFFER_BINDING and READ_FRAMEBUFFER_BINDING are
not "framebuffer complete" (see section 4.4.4.2)."
Calling BlitFramebuffer will result in an INVALID_OPERATION
error if <mask> includes DEPTH_BUFFER_BIT or STENCIL_BUFFER_BIT
and the source and destination depth and stencil buffer formats do
not match.
If SAMPLE_BUFFERS for the read framebuffer is greater than zero and
SAMPLE_BUFFERS for the draw framebuffer is zero, the samples
corresponding to each pixel location in the source are converted to
a single sample before being written to the destination.
If SAMPLE_BUFFERS for the read framebuffer is zero and
SAMPLE_BUFFERS for the draw framebuffer is greater than zero, the
value of the source sample is replicated in each of the destination
samples.
If SAMPLE_BUFFERS for both the read and draw framebuffers are
greater than zero, and the values of SAMPLES for the read and draw
framebuffers are identical, the samples are copied without
modification from the read framebuffer to the draw framebuffer.
Otherwise, no copy is performed and an INVALID_OPERATION error is
generated. Note that the samples in the draw buffer are not
guaranteed to be at the same sample location as the read buffer,
so rendering using this newly created buffer can potentially
have geometry cracks or incorrect antialiasing. This may occur
if the sizes of the framebuffers do not match, if the
formats differ, or if the source and destination rectangles are
not defined with the same (X0,Y0) and (X1,Y1) bounds.
If SAMPLE_BUFFERS for either the read framebuffer or
draw framebuffer is greater than zero, no copy is performed and an
INVALID_OPERATION error is generated if the dimensions of the source
and destination rectangles provided to BlitFramebuffer are not
identical, or if the formats of the read and draw framebuffers are
not identical.
Add a new section "Framebuffer Objects" after section 4.3:
"4.4 Framebuffer Objects
As described in chapters 1 and 2, GL renders into (and reads values
from) a framebuffer. GL defines two classes of framebuffers:
window-system-provided framebuffers and application-created
framebuffers. For each GL context, there is a single framebuffer
provided by the window-system, and there may also be one or more
framebuffer objects created and managed by the application.
By default, the GL uses the window-system-provided framebuffer. The
storage, dimensions, allocation, and format of the images attached
to this framebuffer are managed entirely by the window-system.
Consequently, the state of the window-system-provided framebuffer,
including its images, can not be changed by the GL, nor can the
window-system-provided framebuffer itself, or its images, be deleted
by the GL.
The routines described in the following sections, however, can be
used to create, destroy, and modify the state and attachments of
application-created framebuffer objects.
Application-created framebuffer objects encapsulate the state of a
framebuffer in a similar manner to the way texture objects
encapsulate the state of a texture. In particular, a framebuffer
object encapsulates state necessary to describe a collection of
color, depth, and stencil logical buffers (accumulation and
auxiliary buffers are not allowed). For each
logical buffer, a framebuffer-attachable image can be attached to
the framebuffer to store the rendered output for that logical
buffer. Examples of framebuffer-attachable images include texture
images and renderbuffer images. Renderbuffers are described further
in section 4.4.2.1
By allowing the images of a renderbuffer to be attached to a
framebuffer, the GL provides a mechanism to support "off-screen"
rendering. Further, by allowing the images of a texture to be
attached to a framebuffer, the GL provides a mechanism to support
"render to texture".
4.4.1 Binding and Managing Framebuffer Objects
The default framebuffer for rendering and readback operations is
provided by the window system. In addition, named framebuffer
objects can be created and operated upon. The namespace for
framebuffer objects is the unsigned integers, with zero reserved
by the GL for the default framebuffer.
A framebuffer object is created by binding
a name returned by GenFramebuffers (see below) to
DRAW_FRAMEBUFFER or READ_FRAMEBUFFER. The binding is
effected by calling
void BindFramebuffer(enum target, uint framebuffer);
with <target> set to the desired framebuffer target and
<framebuffer> set to the framebuffer object name.
The resulting framebuffer
object is a new state vector, comprising all the state values
listed in table 4.nnn, as well as one set of the state values
listed in table 5.nnn for each attachment point of the
framebuffer, set to the same initial values. There are
MAX_COLOR_ATTACHMENTS color attachment points, plus one each
for the depth and stencil attachment points.
BindFramebuffer may also be used to bind an existing
framebuffer object to DRAW_FRAMEBUFFER or
READ_FRAMEBUFFER. If the bind is successful no change is made
to the state of the bound framebuffer object, and any previous
binding to <target> is broken.
BindFramebuffer fails and an INVALID_OPERATION error is generated if
<framebuffer> is not zero or a name returned from a previous call to
GenFramebuffers, or if such a name has since been deleted with
DeleteFramebuffers.
If a framebuffer object is bound to DRAW_FRAMEBUFFER or
READ_FRAMEBUFFER, it becomes the target for rendering or
readback operations, respectively, until it is deleted or another
framebuffer is bound to the corresponding bind point. Calling
BindFramebuffer with <target> set to FRAMEBUFFER binds the
framebuffer to both the draw and read targets.
While a framebuffer object is bound, GL operations on the target
to which it is bound affect the images attached to the bound
framebuffer object, and queries of the target to which it is bound
return state from the bound object. Queries of the values
specified in table 6.31 (Implementation Dependent Pixel Depths)
and table 8.nnn (Framebuffer-Dependent State Variables) are
derived from the framebuffer object bound to DRAW_FRAMEBUFFER.
The initial state of DRAW_FRAMEBUFFER and READ_FRAMEBUFFER
refers to the default framebuffer.
In order that access to the default framebuffer is not
lost, it is treated as a framebuffer object with the name of zero.
The default framebuffer is therefore rendered to and read from
while zero is bound to the corresponding targets. On some
implementations, the properties of the default framebuffer can
change over time (e.g., in response to window system events
such as attaching the context to a new window system drawable.)
Framebuffer objects (those with a non-zero
name) differ from the default framebuffer in
a few important ways. First and foremost, unlike the
default framebuffer, framebuffer objects
have modifiable attachment points for each logical buffer in the
framebuffer. Framebuffer-attachable images can be attached to and
detached from these attachment points, which are described further
in section 4.4.2. Also, the size and format of the images attached
to application-created framebuffers are controlled entirely within
the GL interface, and are not affected by window system events, such
as pixel format selection, window resizes, and display mode changes.
Additionally, when rendering to or reading from an application
created-framebuffer object,
- The pixel ownership test always succeeds. In other words,
framebuffer objects own all of their pixels.
- There are no visible color buffer bitplanes. This means
there is no color buffer corresponding to the back, front,
left, or right color bitplanes.
- The only color buffer bitplanes are the ones defined by the
framebuffer attachment points named COLOR_ATTACHMENT0
through COLOR_ATTACHMENTn.
- The only depth buffer bitplanes are the ones defined by the
framebuffer attachment point DEPTH_ATTACHMENT.
- The only stencil buffer bitplanes are the ones defined by
the framebuffer attachment point STENCIL_ATTACHMENT.
- There are no accum buffer bitplanes, so the value of the
implementation-dependent state variables ACCUM_RED_BITS,
ACCUM_GREEN_BITS, ACCUM_BLUE_BITS, and ACCUM_ALPHA_BITS, are
all zero.
- There are no AUX buffer bitplanes, so the value of the
implementation-dependent state variable AUX_BUFFERS is zero.
- If the attachment sizes are not all identical, rendering will be
limited to the largest area that can fit in all of the
attachments (i.e. an intersection of rectangles having a lower
left of (0,0) and an upper right of (width,height) for each
attachment)
- If the attachment sizes are not all identical, the values of
pixels outside the common intersection area after rendering are
undefined.
Framebuffer objects are deleted by calling
void DeleteFramebuffers(sizei n, uint *framebuffers);
<framebuffers> contains <n> names of framebuffer objects to be
deleted. After a framebuffer object is deleted, it has no
attachments, and its name is again unused. If a framebuffer that
is currently bound to one or more of the targets
DRAW_FRAMEBUFFER or READ_FRAMEBUFFER is deleted, it is as
though BindFramebuffer had been executed with the corresponding
<target> and <framebuffer> zero. Unused names in
<framebuffers> are silently ignored, as is the value zero.
The command
void GenFramebuffers(sizei n, uint *ids);
returns <n> previously unused framebuffer object names in <ids>.
These names are marked as used, for the purposes of
GenFramebuffers only, but they acquire state and type only when
they are first bound, just as if they were unused.
The names bound to the draw and read framebuffer bindings can be
queried by calling GetIntegerv with the symbolic constants
DRAW_FRAMEBUFFER_BINDING and READ_FRAMEBUFFER_BINDING
respectively. FRAMEBUFFER_BINDING is equivalent to
DRAW_FRAMEBUFFER_BINDING.
4.4.2 Attaching Images to Framebuffer Objects
Framebuffer-attachable images may be attached to, and detached from,
framebuffer objects. In contrast, the image
attachments of the default framebuffer may not be
changed by the GL.
A single framebuffer-attachable image may be attached to multiple
framebuffer objects, potentially avoiding some
data copies, and possibly decreasing memory consumption.
For each logical buffer, a framebuffer object stores a set of
state which defines the logical buffer's <attachment point>. The
attachment point state contains enough information to identify the
single image attached to the attachment point, or to indicate that
no image is attached. The per-logical buffer attachment point
state is listed in table 5.nnn
There are two types of framebuffer-attachable images: the image of a
renderbuffer object, and an image of a texture object.
4.4.2.1 Renderbuffer Objects
A renderbuffer is a data storage object containing a single image of
a renderable internal format. GL provides the methods described
below to allocate and delete a renderbuffer's image, and to attach a
renderbuffer's image to a framebuffer object.
The name space for renderbuffer objects is the unsigned integers,
with zero reserved for the GL. A renderbuffer object is created by
binding a name returned by GenRenderbuffers (see below)
to RENDERBUFFER. The binding is effected by calling
void BindRenderbuffer( enum target, uint renderbuffer );
with <target> set to RENDERBUFFER and <renderbuffer> set to the
unused name. If <renderbuffer> is not zero, then the resulting
renderbuffer object is a new state vector, initialized with a
zero-sized memory buffer, and comprising the state values listed in
Table 8.nnn. Any previous binding to <target> is broken.
BindRenderbuffer may also be used to bind an existing
renderbuffer object. If the bind is successful, no change is made
to the state of the newly bound renderbuffer object, and any
previous binding to <target> is broken.
While a renderbuffer object is bound, GL operations on the target to
which it is bound affect the bound renderbuffer object, and queries
of the target to which a renderbuffer object is bound return state
from the bound object.
The name zero is reserved. A renderbuffer object cannot be created
with the name zero. If <renderbuffer> is zero, then any previous
binding to <target> is broken and the <target> binding is restored
to the initial state.
In the initial state, the reserved name zero is bound to
RENDERBUFFER. There is no renderbuffer object corresponding to
the name zero, so client attempts to modify or query renderbuffer
state for the target RENDERBUFFER while zero is bound will
generate GL errors, as described in section 6.1.3.
The current RENDERBUFFER binding can be determined by calling
GetIntegerv with the symbolic constant RENDERBUFFER_BINDING.
BindRenderbuffer fails and an INVALID_OPERATION error is generated
if <renderbuffer> is not a name returned from a previous call to
GenRenderbuffers, or if such a name has since been deleted with
DeleteRenderbuffers.
Renderbuffer objects are deleted by calling
void DeleteRenderbuffers( sizei n, const uint *renderbuffers );
where <renderbuffers> contains <n> names of renderbuffer objects to be
deleted. After a renderbuffer object is deleted, it has no
contents, and its name is again unused. If a renderbuffer that is
currently bound to RENDERBUFFER is deleted, it is as though
BindRenderbuffer had been executed with the <target>
RENDERBUFFER and <name> of zero. Additionally, special care
must be taken when deleting a renderbuffer if the image of the
renderbuffer is attached to a framebuffer object (see section
4.4.2.2 for details). Unused names in <renderbuffers> are silently
ignored, as is the value zero.
The command
void GenRenderbuffers( sizei n, uint *renderbuffers );
returns <n> previously unused renderbuffer object names in
<renderbuffers>. These names are marked as used, for the purposes
of GenRenderbuffers only, but they acquire renderbuffer state
only when they are first bound, just as if they were unused.
The command
void RenderbufferStorageMultisample(enum target, sizei samples,
enum internalformat,
sizei width, sizei height);
establishes the data storage, format, dimensions, and number of
samples of a renderbuffer object's image. <target> must be
RENDERBUFFER. <internalformat> must be color-renderable, depth-
renderable, or stencil-renderable (as defined in section 4.4.4).
<width> and <height> are the dimensions in pixels of the renderbuffer.
If either <width> or <height> is greater than MAX_RENDERBUFFER_SIZE,
or if <samples> is greater than MAX_SAMPLES,
then the error INVALID_VALUE is
generated. If the GL is unable to create a data store of the
requested size, the error OUT_OF_MEMORY is generated.
Upon success, RenderbufferStorageMultisample deletes any existing
data store for the renderbuffer image and the contents of the data
store after calling RenderbufferStorageMultisample are undefined.
RENDERBUFFER_WIDTH is set to <width>, RENDERBUFFER_HEIGHT is
set to <height>, and RENDERBUFFER_INTERNAL_FORMAT is set to
<internalformat>.
If <samples> is zero, then RENDERBUFFER_SAMPLES is set to zero.
Otherwise <samples> represents a request for a desired minimum
number of samples. Since different implementations may support
different sample counts for multisampled rendering, the actual
number of samples allocated for the renderbuffer image is
implementation dependent. However, the resulting value for
RENDERBUFFER_SAMPLES is guaranteed to be greater than or equal
to <samples> and no more than the next larger sample count supported
by the implementation.
Sized Base S
Internal Format Internal format Bits
--------------- --------------- ----
STENCIL_INDEX1 STENCIL_INDEX 1
STENCIL_INDEX4 STENCIL_INDEX 4
STENCIL_INDEX8 STENCIL_INDEX 8
STENCIL_INDEX16 STENCIL_INDEX 16
----------------------------------------------------------------
Table 2.nnn Desired component resolution for each sized internal
format that can be used only with renderbuffers.
A GL implementation may vary its allocation of internal component
resolution based on any RenderbufferStorage parameter (except
target), but the allocation and chosen internal format must not be a
function of any other state and cannot be changed once they are
established.
The command
void RenderbufferStorage(enum target, enum internalformat,
sizei width, sizei height);
is equivalent to calling RenderbufferStorageMultisample with
<samples> equal to zero."
4.4.2.2 Attaching Renderbuffer Images to a Framebuffer
A renderbuffer can be attached as one of the logical buffers of the
currently bound framebuffer object by calling
void FramebufferRenderbuffer(enum target,
enum attachment,
enum renderbuffertarget,
uint renderbuffer);
<target> must be DRAW_FRAMEBUFFER, READ_FRAMEBUFFER, or
FRAMEBUFFER. FRAMEBUFFER is equivalent to
DRAW_FRAMEBUFFER.
An INVALID_OPERATION error is generated if the value of the
corresponding binding is zero. <attachment> should be set to
one of the attachment points of the framebuffer listed in table
1.nnn. <renderbuffertarget> must be RENDERBUFFER and
<renderbuffer> should be set to the name of the renderbuffer object
to be attached to the framebuffer. <renderbuffer> must be either
zero or the name of an existing renderbuffer object of type
<renderbuffertarget>, otherwise an INVALID_OPERATION error is
generated. If <renderbuffer> is zero, then the value of
<renderbuffertarget> is ignored.
If <renderbuffer> is not zero and if FramebufferRenderbuffer is
successful, then the renderbuffer named <renderbuffer> will be used
as the logical buffer identified by <attachment> of the framebuffer
currently bound to <target>. The value of
FRAMEBUFFER_ATTACHMENT_OBJECT_TYPE for the specified attachment
point is set to RENDERBUFFER and the value of
FRAMEBUFFER_ATTACHMENT_OBJECT_NAME is set to <renderbuffer>. All
other state values of the attachment point specified by <attachment>
are set to their default values listed in table 5.nnn. No change is
made to the state of the renderbuffer object and any previous
attachment to the <attachment> logical buffer of the framebuffer
object bound to framebuffer <target> is broken. If
the attachment is not successful, then no change is made to
the state of either the renderbuffer object or the framebuffer
object.
Calling FramebufferRenderbuffer with the <renderbuffer> name zero
will detach the image, if any, identified by <attachment>, in the
framebuffer currently bound to <target>. All state values of the
attachment point specified by <attachment> in the object bound to
<target> are set to their default values listed in table 5.nnn.
Setting <attachment> to the value DEPTH_STENCIL_ATTACHMENT is a
special case causing both the depth and stencil attachments of the
framebuffer object to be set to <renderbuffer>, which should have
base internal format DEPTH_STENCIL.
If a renderbuffer object is deleted while its image is attached to
one or more attachment points in the currently bound framebuffer,
then it is as if FramebufferRenderbuffer had been called, with
a <renderbuffer> of 0, for each attachment point to which this image
was attached in the currently bound framebuffer. In other words,
this renderbuffer image is first detached from all attachment points
in the currently bound framebuffer. Note that the renderbuffer
image is specifically *not* detached from any non-bound
framebuffers. Detaching the image from any non-bound framebuffers
is the responsibility of the application.
Name of attachment
-----------------------------------------------------
COLOR_ATTACHMENTi (see caption)
DEPTH_ATTACHMENT
STENCIL_ATTACHMENT
DEPTH_STENCIL_ATTACHMENT
-----------------------------------------------------
Table 1.nnn: Framebuffer attachment points. <i> in
COLOR_ATTACHMENTi may range from zero to the value of
MAX_COLOR_ATTACHMENTS - 1.
4.4.2.3 Attaching Texture Images to a Framebuffer
GL supports copying the rendered contents of the framebuffer into
the images of a texture object through the use of the routines
CopyTexImage{1D|2D}, and CopyTexSubImage{1D|2D|3D}. Additionally,
GL supports rendering directly into the images of a texture object.
To render directly into a texture image, a specified image from a
texture object can be attached as one of the logical buffers of the
currently bound framebuffer object by calling one of the following
routines, depending on the type of the texture:
void FramebufferTexture1D(enum target, enum attachment,
enum textarget, uint texture,
int level);
void FramebufferTexture2D(enum target, enum attachment,
enum textarget, uint texture,
int level);
void FramebufferTexture3D(enum target, enum attachment,
enum textarget, uint texture,
int level, int layer);
In all three routines, <target> must be DRAW_FRAMEBUFFER,
READ_FRAMEBUFFER or FRAMEBUFFER. FRAMEBUFFER is
equivalent to DRAW_FRAMEBUFFER.
An INVALID_OPERATION error is generated if the
value of the corresponding binding is zero.
<attachment> must be one of the attachment points of the
framebuffer listed in table 1.nnn.
If <texture> is zero, the image identified by <attachment>, if
any, will be detached from the framebuffer currently bound to
<target>. <textarget>, <level>, and <layer> are ignored. All
state values of the attachment point specified by <attachment> are
set to their default values listed in table 5.nnn.
If <texture> is not zero, then <texture> must either name an existing
texture object with a target of <textarget>, or <texture> must name an
existing cube map texture and <textarget> must be one of
TEXTURE_CUBE_MAP_POSITIVE_X, TEXTURE_CUBE_MAP_POSITIVE_Y,
TEXTURE_CUBE_MAP_POSITIVE_Z, TEXTURE_CUBE_MAP_NEGATIVE_X,
TEXTURE_CUBE_MAP_NEGATIVE_Y, or TEXTURE_CUBE_MAP_NEGATIVE_Z. Otherwise,
an INVALID_OPERATION error is generated.
<level> specifies the mipmap level of the texture image to be
attached to the framebuffer.
If <textarget> is TEXTURE_RECTANGLE_ARB, then <level> must be zero.
If <textarget> is TEXTURE_3D, then <level> must be greater than or
equal to zero and less than or equal to log base 2 of the value of
MAX_3D_TEXTURE_SIZE. If <textarget> is one of
TEXTURE_CUBE_MAP_POSITIVE_X, TEXTURE_CUBE_MAP_POSITIVE_Y,
TEXTURE_CUBE_MAP_POSITIVE_Z, TEXTURE_CUBE_MAP_NEGATIVE_X,
TEXTURE_CUBE_MAP_NEGATIVE_Y, or TEXTURE_CUBE_MAP_NEGATIVE_Z, then
<level> must be greater than or equal to zero and less than or equal
to log base 2 of the value of MAX_CUBE_MAP_TEXTURE_SIZE. For all other
values of <textarget>, <level> must be greater than or equal to zero and
no larger than log base 2 of the value of MAX_TEXTURE_SIZE. Otherwise,
an INVALID_VALUE error is generated.
<layer> specifies the layer of a 2-dimensional image within a
3-dimensional texture. An INVALID_VALUE error is generated if
<layer> is larger than the value of MAX_3D_TEXTURE_SIZE-1.
For FramebufferTexture1D, if <texture> is not zero, then
<textarget> must be TEXTURE_1D.
For FramebufferTexture2D, if <texture> is not zero, then
<textarget> must be one of TEXTURE_2D, TEXTURE_RECTANGLE_ARB,
TEXTURE_CUBE_MAP_POSITIVE_X, TEXTURE_CUBE_MAP_POSITIVE_Y,
TEXTURE_CUBE_MAP_POSITIVE_Z, TEXTURE_CUBE_MAP_NEGATIVE_X,
TEXTURE_CUBE_MAP_NEGATIVE_Y, or TEXTURE_CUBE_MAP_NEGATIVE_Z.
For FramebufferTexture3D, if <texture> is not zero, then
<textarget> must be TEXTURE_3D.
If <texture> is not zero, and if FramebufferTexture{1D|2D|3D} is
successful, then the specified texture image will be used as the
logical buffer identified by <attachment> of the framebuffer
currently bound to <target>. The value of
FRAMEBUFFER_ATTACHMENT_OBJECT_TYPE for the specified attachment
point is set to TEXTURE and the value of
FRAMEBUFFER_ATTACHMENT_OBJECT_NAME is set to <texture>.
Additionally, the value of FRAMEBUFFER_ATTACHMENT_TEXTURE_LEVEL for
the named attachment point is set to <level>. If <texture> is a
cube map texture, then the value of
FRAMEBUFFER_ATTACHMENT_TEXTURE_CUBE_MAP_FACE the named attachment
point is set to <textarget>. If <texture> is a 3D texture, then the
value of FRAMEBUFFER_ATTACHMENT_TEXTURE_LAYER for the named
attachment point is set to <layer>. All other state values of the
attachment point specified by <attachment> are set to their default
values listed in table 5.nnn. No change is made to the state of the
texture object, and any previous attachment to the <attachment>
logical buffer of the framebuffer object bound to framebuffer
<target> is broken. If the attachment is not
successful, then no change is made to the state of either the
texture object or the framebuffer object.
Setting <attachment> to the value DEPTH_STENCIL_ATTACHMENT is a
special case causing both the depth and stencil attachments of the
framebuffer object to be set to <texture>. <texture> must have base
internal format DEPTH_STENCIL, or the depth and stencil
framebuffer attachments will be incomplete (see section 4.4.4.1).
The command
void FramebufferTextureLayer(enum target,enum attachment,
uint texture,int level,int layer);
operates identically to FramebufferTexture3D, except that it
attaches a single layer of a three-dimensional texture, or one- or
two-dimensional array texture. <layer> is an integer indicating the
layer number, and is treated identically to the <layer> parameter in
FramebufferTexture3D. The error INVALID_VALUE is generated if
<layer> is negative. The error INVALID_OPERATION is generated if
<texture> is non-zero and is not the name of a three dimensional
texture, or one- or two-dimensional array texture.
Unlike FramebufferTexture3D, no <textarget> parameter is accepted.
If <texture> is non-zero and the command does not result in an
error, the framebuffer attachment state corresponding to
<attachment> is updated as in the other FramebufferTexture commands,
except that FRAMEBUFFER_ATTACHMENT_TEXTURE_LAYER is set to
<layer>.
If a texture object is deleted while its image is attached to one or
more attachment points in the currently bound framebuffer, then it
is as if FramebufferTexture* had been called, with a <texture> of
zero, for each attachment point to which this image was attached in
the currently bound framebuffer. In other words, this texture image
is first detached from all attachment points in the currently bound
framebuffer. Note that the texture image is specifically *not*
detached from any other framebuffer objects. Detaching the texture
image from any other framebuffer objects is the responsibility of
the application.
4.4.3 Rendering When an Image of a Bound Texture Object is Also
Attached to the Framebuffer
The mechanisms for attaching textures to a framebuffer object do not
prevent a one- or two-dimensional texture level, a face of a cube
map texture level, or a layer of a two-dimensional array or
three-dimensional texture from being attached to the draw
framebuffer while the same texture is bound to a texture unit. While
any of these conditions hold, texturing operations accessing that
image will produce undefined results, as described at the end of
section 3.8.8. Conditions resulting in such undefined behavior are
defined in more detail below. Such undefined texturing operations
are likely to leave the final results of the shader or
fixed-function fragment processing operations undefined, and should
be avoided.
Special precautions need to be taken to avoid attaching a texture
image to the currently bound framebuffer while the texture object is
currently bound and enabled for texturing. Doing so could lead to
the creation of a <feedback loop> between the writing of pixels by
the GL's rendering operations and the simultaneous reading of those
same pixels when used as texels in the currently bound texture. In
this scenario, the framebuffer will be considered framebuffer
complete (see section 4.4.4), but the values of fragments rendered
while in this state will be undefined. The values of texture
samples may be undefined as well, as described at the end of the
"Scale Factor and Level of Detail" subsection of section 3.8.8.
Specifically, the values of rendered fragments are undefined if all
of the following conditions are true:
- an image from texture object <T> is attached to the currently
bound framebuffer at attachment point <A>, and
- the texture object <T> is currently bound to a texture unit
<U>, and
- the current fixed-function texture state or programmable
vertex and/or fragment processing state makes it possible(*)
to sample from the texture object <T> bound to texture unit
<U>
while either of the following conditions are true:
- the value of TEXTURE MIN FILTER for texture object <T> is
NEAREST or LINEAR, and the value of
FRAMEBUFFER_ATTACHMENT_TEXTURE_LEVEL for attachment point
<A> is equal to the value of TEXTURE_BASE_LEVEL for the
texture object <T>, or
- the value of TEXTURE_MIN_FILTER for texture object <T> is one
of NEAREST_MIPMAP_NEAREST, NEAREST_MIPMAP LINEAR, LINEAR
MIPMAP_NEAREST, or LINEAR_MIPMAP_LINEAR, and the value of
FRAMEBUFFER_ATTACHMENT_TEXTURE_LEVEL for attachment point
<A> is within the range specified by the current values of
TEXTURE_BASE_LEVEL to q, inclusive, for the texture object
<T>. (q is defined in the Mipmapping discussion of section
3.8.8),
(*) For the purpose of this discussion, it is <possible>
to sample from the texture object <T> bound to texture unit <U>
if any of the following are true:
- Programmable vertex and fragment processing is disabled
and the target of texture object <T> is enabled according
to the texture target precedence rules of section 3.8.15
- FRAGMENT_PROGRAM_ARB is enabled and the currently bound
fragment program contains any instructions that
sample from the texture object <T> bound to <U>
- The active fragment or vertex shader contains any instructions
that might sample from the texture object <T> bound to <U> if even
those instructions might only be executed conditionally.
Note that if TEXTURE_BASE_LEVEL and TEXTURE_MAX_LEVEL exclude any
levels containing image(s) attached to the currently bound
framebuffer, then the above conditions will not be met, (i.e., the
above rule will not cause the values of rendered fragments to be
undefined.)
4.4.4 Framebuffer Completeness
A framebuffer must be <framebuffer complete> to effectively be used
as the draw or read framebuffer of the GL.
The default framebuffer is always complete if it exists; however, if no
default framebuffer exists (no window system-provided drawable is
associated with the GL context), it is deemed to be incomplete.
A framebuffer object is said to be framebuffer complete if all of
its attached images, and all framebuffer parameters required to
utilize the framebuffer for rendering and reading, are consistently
defined and meet the requirements defined below. The rules of
framebuffer completeness are dependent on the properties of the
attached images, and on certain implementation dependent
restrictions.
The internal formats of the attached images can affect the
completeness of the framebuffer, so it is useful to first define the
relationship between the internal format of an image and the
attachment points to which it can be attached.
* The following base internal formats from table 3.15 are
<color-renderable>: ALPHA, LUMINANCE, LUMINANCE_ALPHA,
INTENSITY, RED, RG, RGB, RGBA, FLOAT_R_NV, FLOAT_RG_NV,
FLOAT_RGB_NV, and FLOAT_RGBA_NV. The sized
internal formats from table 3.16 that have a color-renderable
base internal format are also color-renderable. No other
formats, including compressed internal formats, are
color-renderable.
* An internal format is <depth-renderable> if it is
DEPTH_COMPONENT or one of the formats from table 3.16 whose
base internal format is DEPTH_COMPONENT or DEPTH_STENCIL.
No other formats are depth-renderable.
* An internal format is <stencil-renderable> if it is
STENCIL_INDEX or DEPTH_STENCIL, if it is one of the
STENCIL_INDEX formats from table 2.nnn, or if it is one of the
formats from table 3.16 whose base internal format is
DEPTH_STENCIL. No other formats are stencil-renderable."
4.4.4.1 Framebuffer Attachment Completeness
If the value of FRAMEBUFFER_ATTACHMENT_OBJECT_TYPE for the
framebuffer attachment point <attachment> is not NONE, then it is
said that a framebuffer-attachable image, named <image>, is attached
to the framebuffer at the attachment point. <image> is identified
by the state in <attachment> as described in section 4.4.2.
The framebuffer attachment point <attachment> is said to be
<framebuffer attachment complete> if the value of
FRAMEBUFFER_ATTACHMENT_OBJECT_TYPE for <attachment> is NONE
(i.e., no image is attached), or if all of the following conditions
are true:
* <image> is a component of an existing object with the name
specified by FRAMEBUFFER_ATTACHMENT_OBJECT_NAME, and of the
type specified by FRAMEBUFFER_ATTACHMENT_OBJECT_TYPE.
* The width and height of <image> must be non-zero.
* If FRAMEBUFFER_ATTACHMENT_OBJECT_TYPE is TEXTURE and
FRAMEBUFFER_ATTACHMENT_OBJECT_NAME names a 3-dimensional
texture, then FRAMEBUFFER_ATTACHMENT_TEXTURE_LAYER must be
smaller than the depth of the texture.
* If <attachment> is COLOR_ATTACHMENTi, then <image> must have
a color-renderable internal format.
* If <attachment> is DEPTH_ATTACHMENT, then <image> must have
a depth-renderable internal format.
* If <attachment> is STENCIL_ATTACHMENT, then <image> must
have a stencil-renderable internal format.
4.4.4.2 Whole Framebuffer Completeness
Each rule below is followed by an error enum enclosed in { brackets }.
The meaning of these errors is explained below and under ``Effects of
Framebuffer Completeness on Framebuffer Operations'' later in section
4.4.4.
The framebuffer object <target> is said to be "framebuffer complete" if
all the following conditions are true:
* <target> is the default framebuffer, and the default framebuffer
exists.
{ FRAMEBUFFER_UNDEFINED }
* All framebuffer attachment points are framebuffer attachment
complete.
{ FRAMEBUFFER_INCOMPLETE_ATTACHMENT }
* There is at least one image attached to the framebuffer.
{ FRAMEBUFFER_INCOMPLETE_MISSING_ATTACHMENT }
* The value of FRAMEBUFFER_ATTACHMENT_OBJECT_TYPE must not be
NONE for any color attachment point(s) named by DRAW_BUFFERi.
{ FRAMEBUFFER_INCOMPLETE_DRAW_BUFFER }
* If READ_BUFFER is not NONE, then the value of
FRAMEBUFFER_ATTACHMENT_OBJECT_TYPE must not be NONE for the
color attachment point named by READ_BUFFER.
{ FRAMEBUFFER_INCOMPLETE_READ_BUFFER }
* The combination of internal formats of the attached
images does not violate an implementation-dependent set of
restrictions.
{ FRAMEBUFFER_UNSUPPORTED }
* The value of RENDERBUFFER_SAMPLES is the same for all attached
images.
{ FRAMEBUFFER_INCOMPLETE_MULTISAMPLE }
The token in { brackets } after each clause of the framebuffer
completeness rules specifies the return value of
CheckFramebufferStatus (see below) that is generated when that
clause is violated. If more than one clause is violated, it is
implementation-dependent exactly which value will be returned by
CheckFramebufferStatus.
Performing any of the following actions may change whether the
framebuffer is considered complete or incomplete.
- Binding to a different framebuffer with BindFramebuffer.
- Attaching an image to the framebuffer with
FramebufferTexture{1D|2D|3D} or FramebufferRenderbuffer.
- Detaching an image from the framebuffer with
FramebufferTexture{1D|2D|3D} or FramebufferRenderbuffer.
- Changing the internal format of a texture image that is attached
to the framebuffer by calling {Copy|Compressed}TexImage{1D|2D|3D}.
- Changing the internal format of a renderbuffer that is attached
to the framebuffer by calling RenderbufferStorage.
- Deleting, with DeleteTextures or DeleteRenderbuffers, an object
containing an image that is attached to a framebuffer object
that is bound to the framebuffer.
- Changing READ_BUFFER or one of the DRAW_BUFFERS.
- Associating a different window system-provided drawable, or no
drawable, with the default framebuffer using a window system binding
API such as GLX, WGL, CGL, or EGL.
Although GL defines a wide variety of internal formats for
framebuffer-attachable images, such as texture images and
renderbuffer images, some implementations may not support rendering
to particular combinations of internal formats. If the combination
of formats of the images attached to a framebuffer object are not
supported by the implementation, then the framebuffer is not
complete under the clause labeled FRAMEBUFFER_UNSUPPORTED. There
must exist, however, at least one combination of internal formats
for which the framebuffer cannot be FRAMEBUFFER_UNSUPPORTED.
Because of the <implementation-dependent> clause of the framebuffer
completeness test in particular, and because framebuffer
completeness can change when the set of attached images is modified,
it is strongly advised, though is not required, that an application
check to see if the framebuffer is complete prior to rendering. The
status of the framebuffer object currently bound to <target> can be
queried by calling
enum CheckFramebufferStatus(enum target);
<target> must be DRAW_FRAMEBUFFER, READ_FRAMEBUFFER or
FRAMEBUFFER. FRAMEBUFFER is equivalent to DRAW_FRAMEBUFFER.
If CheckFramebufferStatus is called within a Begin/End pair,
an INVALID_OPERATION error is generated. If
CheckFramebufferStatus generates an error, 0 is returned.
Otherwise, an enum is returned that identifies whether
or not the framebuffer bound to <target> is complete, and if not
complete the enum identifies one of the rules of framebuffer
completeness that is violated. If the framebuffer is complete, then
FRAMEBUFFER_COMPLETE is returned.
The values of SAMPLE_BUFFERS and SAMPLES are derived from the
attachments of the currently bound framebuffer object. If the
current DRAW_FRAMEBUFFER_BINDING is not framebuffer complete,
then both SAMPLE_BUFFERS and SAMPLES are undefined. Otherwise,
SAMPLES is equal to the value of RENDERBUFFER_SAMPLES for the
attached images (which all must have the same value for
RENDERBUFFER_SAMPLES). Further, SAMPLE_BUFFERS is one if
SAMPLES is non-zero. Otherwise, SAMPLE_BUFFERS is zero.
4.4.4.3 Effects of Framebuffer Completeness on Framebuffer Operations
Attempting to render to or read from a framebuffer which is not
framebuffer complete will generate an INVALID_FRAMEBUFFER_OPERATION
error. This means that rendering commands such as Begin,
RasterPos, any command that performs an implicit Begin, as well as
commands that read the framebuffer such as ReadPixels and
CopyTex{Sub}Image will generate the error
INVALID_FRAMEBUFFER_OPERATION if called while the framebuffer is
not framebuffer complete.
4.4.5 Effects of Framebuffer State on Framebuffer Dependent Values
The values of the state variables listed in table 9.nnn (Framebuffer
Dependent Values) may change when a change is made to
DRAW_FRAMEBUFFER_BINDING, to the state of the currently bound
framebuffer object, or to an image attached to the currently bound
framebuffer object.
When DRAW_FRAMEBUFFER_BINDING is zero, the values of the state
variables listed in table 9.nnn are implementation defined.
When DRAW_FRAMEBUFFER_BINDING is non-zero, if the currently bound
framebuffer object is not framebuffer complete, then the values of
the state variables listed in table 9.nnn are undefined.
When DRAW_FRAMEBUFFER_BINDING is non-zero and the currently bound
framebuffer object is framebuffer complete, then the values of the
state variables listed in table 9.nnn are completely determined by
DRAW_FRAMEBUFFER_BINDING, the state of the currently bound
framebuffer object, and the state of the images attached to the
currently bound framebuffer object.
The values of RED_BITS, GREEN_BITS, BLUE_BITS, and ALPHA_BITS are
defined only if all color attachments of the draw framebuffer have
identical formats, in which case the color component depths of color
attachment zero are returned. The values returned for DEPTH_BITS and
STENCIL_BITS are the depth or stencil component depth of the
corresponding attachment of the draw framebuffer, respectively. The
actual sizes of the color, depth, or stencil bit planes can be
obtained by querying an attachment point using
GetFramebufferAttachmentParameteriv,
or querying the object attached at that point. If the value of
FRAMEBUFFER_ATTACHMENT_OBJECT_TYPE at a particular attachment
point is RENDERBUFFER, the sizes may be determined by calling
GetRenderbufferParameteriv as described in section 6.1.3. If
the value of FRAMEBUFFER_ATTACHMENT_OBJECT_TYPE at a particular
attachment point is TEXTURE, the sizes may be determined by calling
GetTexParameter, as described in section 6.1.3.
4.4.6 Mapping between Pixel and Element in Attached Image
When DRAW_FRAMEBUFFER_BINDING is non-zero, an operation that writes
to the framebuffer modifies the image attached to the selected
logical buffer, and an operation that reads from the framebuffer
reads from the image attached to the selected logical buffer.
If the attached image is a renderbuffer image, then the window
coordinates (x[w], y[w]) corresponds to the value in the
renderbuffer image at the same coordinates.
If the attached image is a texture image, then the window
coordinates (x[w], y[w]) correspond to the texel (i, j, k), from
figure 3.10 as follows:
i = (x[w] - b)
j = (y[w] - b)
k = (layer - b)
where <b> is the texture image's border width, and <layer> is the
value of FRAMEBUFFER_ATTACHMENT_TEXTURE_LAYER for the selected
logical buffer. For a two-dimensional texture, <k> and <layer> are
irrelevant; for a one-dimensional texture, <j>, <k>, and <layer> are
both irrelevant.
(x[w], y[w]) corresponds to a border texel if x[w], y[w], or
<layer> is less than the border width, or if x[w], y[w], or <layer>
is greater than or equal to the border width plus the width or height or
depth, respectively, of the texture image.
Conversion to Framebuffer-Attachable Image Components
When an enabled color value is written to the framebuffer while the
draw framebuffer binding is non-zero, for each draw buffer the R, G, B,
and A values are converted to internal components as described in
table 3.15, according to the table row corresponding to the internal
format of the framebuffer-attachable image attached to the selected
logical buffer, and the resulting internal components are written to
the image attached to logical buffer. The masking operations
described in section 4.2.2 are also effective.
Conversion to RGBA Values
When a color value is read or is used as the source of a logical
operation or blending while the read framebuffer binding is non-zero,
the components of the framebuffer-attachable image that is attached to
the logical buffer selected by READ_BUFFER are first converted to R, G,
B, and A values according to table 3.21 and the internal format of the
attached image."
Additions to Chapter 5 of the OpenGL 2.1 Specification (Special Functions)
Added to section 5.4, as part of the discussion of which commands
are not compiled into display lists:
"Certain commands, when called while compiling a display list, are
not compiled into the display list but are executed immediately.
These are: ..., GenFramebuffers, BindFramebuffer,
DeleteFramebuffers, CheckFramebufferStatus,
GenRenderbuffers, BindRenderbuffer, DeleteRenderbuffers,
RenderbufferStorage, RenderbufferStorageMultisample,
FramebufferTexture1D, FramebufferTexture2D,
FramebufferTexture3D, FramebufferRenderbuffer, BlitFramebuffer,
GenerateMipmap..."
Additions to Chapter 6 of the OpenGL 2.1 Specification (State and State
Requests)
In section 6.1.3 "Enumerated Queries", modify the seventh paragraph
to say:
"For texture images with uncompressed internal formats, queries of
<value> of TEXTURE_RED_SIZE, TEXTURE_GREEN_SIZE, TEXTURE_BLUE_SIZE,
TEXTURE_ALPHA_SIZE, TEXTURE_LUMINANCE_SIZE, TEXTURE_INTENSITY_SIZE,
TEXTURE_DEPTH_SIZE, and TEXTURE_STENCIL_SIZE return the actual
resolutions of the stored image array components..."
Section 6.1.4 "Texture Queries", in the second paragraph, replace
the first second and third sentences as follows:
"Calling GetTexImage with a color format (one of RED, GREEN,
BLUE, ALPHA, RGB, BGR, RGBA, BGRA, LUMINANCE, or
LUMINANCE_ALPHA) when the internal format of the texture image
is not a color format causes the error INVALID_OPERATION.
Calling GetTexImage with a <format> of DEPTH_COMPONENT when the
base internal format of the texture image is not DEPTH_COMPONENT
or DEPTH_STENCIL causes the error INVALID_OPERATION.
Calling GetTexImage with a <format> of DEPTH_STENCIL when
the base internal format of the texture image is not
DEPTH_STENCIL causes the error INVALID_OPERATION.
GetTexImage obtains component groups from a texture image with
the indicated level-of-detail. If <format> is a color format,
then the components are assigned among R, G, B, and A according
to Table 6.1, starting with the first group in the first row,
and continuing by obtaining groups in order from each row and
proceeding from the first row to the last, and from the first
image to the last for three-dimensional textures. If <format>
is DEPTH_COMPONENT, then each depth component is assigned with
the same ordering of rows and images. If <format> is
DEPTH_STENCIL, then each depth component and each stencil
index is assigned with the same ordering of rows and images."
After section 6.1.14 and before section 6.1.15 (which should be
renumbered 6.1.17), add two new sections:
"6.1.15 Framebuffer Object Queries
The command
boolean IsFramebuffer( uint framebuffer );
returns TRUE if <framebuffer> is the name of a framebuffer
object. If <framebuffer> is zero, or if <framebuffer> is a
non-zero value that is not the name of a framebuffer object,
IsFramebuffer return FALSE.
The command
void GetFramebufferAttachmentParameteriv(enum target,
enum attachment,
enum pname,
int *params);
returns information about attachments of a bound framebuffer object.
<target> must be DRAW_FRAMEBUFFER, READ_FRAMEBUFFER or FRAMEBUFFER.
FRAMEBUFFER is equivalent to DRAW_FRAMEBUFFER.
If the default framebuffer is bound to <target>, then <attachment>
must be one of FRONT_LEFT, FRONT_RIGHT, BACK_LEFT, BACK_RIGHT, or
AUXi, identifying a color buffer; DEPTH, identifying the depth
buffer; or STENCIL, identifying the stencil buffer.
If a framebuffer object is bound to <target>, then <attachment> must
be one of the attachment points of the framebuffer listed in table
1.nnn.
If <attachment> is DEPTH_STENCIL_ATTACHMENT, and different objects
are bound to the depth and stencil attachment points of <target>,
the query will fail and generate an INVALID_OPERATION error. If the
same object is bound to both attachment points, information about
that object will be returned.
Upon successful return from GetFramebufferAttachmentParameteriv, if
<pname> is FRAMEBUFFER_ATTACHMENT_OBJECT_TYPE, then <param> will
contain one of NONE, FRAMEBUFFER_DEFAULT, TEXTURE, or RENDERBUFFER,
identifying the type of object which contains the attached image.
Other values accepted for <pname> depend on the type of object, as
described below.
If the value of FRAMEBUFFER_ATTACHMENT_OBJECT_TYPE is
NONE, no framebuffer is bound to <target>. In this case
querying <pname> FRAMEBUFFER_ATTACHMENT_OBJECT_NAME
will return zero, and all other queries will generate an
INVALID_OPERATION error.
If the value of FRAMEBUFFER_ATTACHMENT_OBJECT_TYPE is not
NONE, these queries apply to all other framebuffer types:
* If <pname> is FRAMEBUFFER_ATTACHMENT_RED_SIZE,
FRAMEBUFFER_ATTACHMENT_GREEN_SIZE,
FRAMEBUFFER_ATTACHMENT_BLUE_SIZE,
FRAMEBUFFER_ATTACHMENT_ALPHA_SIZE,
FRAMEBUFFER_ATTACHMENT_DEPTH_SIZE, or
FRAMEBUFFER_ATTACHMENT_STENCIL_SIZE, then <param> will contain
the number of bits in the corresponding red, green, blue, alpha,
depth, or stencil component of the specified <attachment>. Zero
is returned if the requested component is not present in
<attachment>.
* If <pname> is FRAMEBUFFER_ATTACHMENT_COMPONENT_TYPE, <param>
will contain the format of components of the specified
attachment, one of FLOAT, INT, UNSIGNED_INT, UNSIGNED_NORMALIZED
or INDEX for floating-point, signed integer, unsigned integer,
unsigned fixed-point, or index components respectively. Only
color buffers may have index or integer components.
* If <pname> is FRAMEBUFFER_ATTACHMENT_COLOR_ENCODING, <param>
will contain the encoding of components of the specified
attachment, one of LINEAR or SRGB for linear or sRGB-encoded
components, respectively. Only color buffer components may be
sRGB-encoded; such components are treated as described in
sections 4.1.8 "Blending" and 4.1.X "sRGB Conversion" (as
modified by ARB_framebuffer_sRGB). For the default framebuffer,
color encoding is determined by the implementation. For
framebuffer objects, components are sRGB-encoded if the internal
format of a color attachment is one of the color-renderable SRGB
formats described in section 3.8.15 "sRGB Texture Color
Conversion".
If the value of FRAMEBUFFER_ATTACHMENT_OBJECT_TYPE is RENDERBUFFER,
then
* If <pname> is FRAMEBUFFER_ATTACHMENT_OBJECT_NAME, <params> will
contain the name of the renderbuffer object which contains the
attached image.
If the value of FRAMEBUFFER_ATTACHMENT_OBJECT_TYPE is TEXTURE, then
* If <pname> is FRAMEBUFFER_ATTACHMENT_OBJECT_NAME, then <params>
will contain the name of the texture object which contains the
attached image.
* If <pname> is FRAMEBUFFER_ATTACHMENT_TEXTURE_LEVEL, then
<params> will contain the mipmap level of the texture object
which contains the attached image.
* If <pname> is FRAMEBUFFER_ATTACHMENT_TEXTURE_CUBE_MAP_FACE and
the texture object named FRAMEBUFFER_ATTACHMENT_OBJECT_NAME is a
cube map texture, then <params> will contain the cube map face
of the cubemap texture object which contains the attached image.
Otherwise <params> will contain the value zero.
* If <pname> is FRAMEBUFFER_ATTACHMENT_TEXTURE_LAYER and the
texture object named FRAMEBUFFER_ATTACHMENT_OBJECT_NAME is a
three-dimensional texture, then <params> will contain the layer
of the 2D image of the 3D texture object which contains the
attached image. Otherwise <params> will contain the value zero.
Any combinations of framebuffer type and <pname> not described above
will generate an INVALID_ENUM error."
6.1.16 Renderbuffer Object Queries
"The command
boolean IsRenderbuffer( uint renderbuffer );
returns TRUE if <renderbuffer> is the name of a renderbuffer
object. If <renderbuffer> is zero, or if <renderbuffer> is a
non-zero value that is not the name of a renderbuffer object,
IsRenderbuffer return FALSE.
The command
void GetRenderbufferParameteriv(enum target, enum pname,
int* params);
returns information about a bound renderbuffer object. <target> must
be RENDERBUFFER and <pname> must be one of the symbolic values in
table 8.nnn. If the renderbuffer currently bound to <target> is
zero, then an INVALID_OPERATION error is generated.
Upon successful return from GetRenderbufferParameteriv, if <pname>
is RENDERBUFFER_WIDTH, RENDERBUFFER_HEIGHT,
RENDERBUFFER_INTERNAL_FORMAT, or RENDERBUFFER_SAMPLES, then <params>
will contain the width in pixels, height in pixels, internal format,
or number of samples, respectively, of the image of the renderbuffer
currently bound to <target>.
If <pname> is RENDERBUFFER_RED_SIZE, RENDERBUFFER_GREEN_SIZE,
RENDERBUFFER_BLUE_SIZE, RENDERBUFFER_ALPHA_SIZE,
RENDERBUFFER_DEPTH_SIZE, or RENDERBUFFER_STENCIL_SIZE, then <params>
will contain the actual resolutions, (not the resolutions specified
when the image array was defined), for the red, green, blue, alpha
depth, or stencil components, respectively, of the image of the
renderbuffer currently bound to <target>.
Otherwise, an INVALID_ENUM error is generated."
In section 6.2 "State Tables", add a row to table 6.18 "Textures
(state per texture image)":
Get value Type Get Cmd IV Description Sec.
------------------ ------ -------------------- --- ---------------------------------- -----
... ... ... ... ... ...
TEXTURE_STENCIL_SIZE n x Z+ GetTexLevelParameter 0 texture image's stencil resolution 3.8.3
Errors
The error INVALID_OPERATION is generated if DRAW_FRAMEBUFFER_BINDING
is zero and DrawBuffer or DrawBuffers is called with a <buf>
constant (other than NONE) that does not correspond to a buffer
allocated to the GL by the window-system, including the constants
COLOR_ATTACHMENT0 through COLOR_ATTACHMENTn, where n is
MAX_COLOR_ATTACHMENTS - 1.
The error INVALID_OPERATION is generated if DRAW_FRAMEBUFFER_BINDING
is non-zero and DrawBuffer or DrawBuffer is called
with a <buf> constant (other than NONE) that is not in the range
COLOR_ATTACHMENT0 through COLOR_ATTACHMENTn, where n is
MAX_COLOR_ATTACHMENTS - 1.
The error INVALID_OPERATION is generated if READ_FRAMEBUFFER_BINDING
is non-zero and ReadBuffer is called
with a <buf> constant (other than NONE) that is not in the range
COLOR_ATTACHMENT0 through COLOR_ATTACHMENTn, where n is
MAX_COLOR_ATTACHMENTS - 1.
The error INVALID_ENUM is generated if DrawBuffer or ReadBuffer is
called with a <buf> constant that is not listed in table 4.4 or
10.nnn.
The error INVALID_ENUM is generated if DrawBuffers is called with a
<buf> constant that is not listed in table 10.nnn or 11.nnn.
The error INVALID_FRAMEBUFFER_OPERATION is generated if
BlitFramebuffer, DrawPixels, or CopyPixels is called while the
draw framebuffer is not framebuffer complete.
The error INVALID_FRAMEBUFFER_OPERATION is generated if
BlitFramebuffer, ReadPixels, CopyPixels, CopyTex{Sub}Image*,
CopyColor{Sub}Table, or CopyConvolutionFilter* is called while the
read framebuffer is not framebuffer complete.
The error INVALID_OPERATION is generated if
GetFramebufferAttachmentParameteriv is called while the value of
DRAW_FRAMEBUFFER_BINDING is zero.
The error INVALID_OPERATION is generated if
FramebufferRenderbuffer or FramebufferTexture{1D|2D|3D} is
called while the value of DRAW_FRAMEBUFFER_BINDING is zero.
The error INVALID_OPERATION is generated if RenderbufferStorage
or GetRenderbufferParameteriv is called while the value of
RENDERBUFFER_BINDING is zero.
The error INVALID_ENUM is generated if
GetFramebufferAttachmentParameteriv is called with an
<attachment> other than COLOR_ATTACHMENT0 through
COLOR_ATTACHMENTn, where n is MAX_COLOR_ATTACHMENTS - 1.
The error INVALID_ENUM is generated if
GetFramebufferAttachmentParameteriv is called with a <pname>
other than FRAMEBUFFER_ATTACHMENT_OBJECT_NAME when the type of
the attached object at the named attachment point is
RENDERBUFFER.
The error INVALID_ENUM is generated if
GetFramebufferAttachmentParameteriv is called with a <pname>
other than FRAMEBUFFER_ATTACHMENT_OBJECT_NAME,
FRAMEBUFFER_ATTACHMENT_TEXTURE_LEVEL,
FRAMEBUFFER_ATTACHMENT_TEXTURE_CUBE_MAP_FACE, or
FRAMEBUFFER_ATTACHMENT_TEXTURE_LAYER when the type of the
attached object at the named attachment point is TEXTURE.
The error INVALID_ENUM is generated if GetRenderbufferParameteriv
is called with a <pname> other than RENDERBUFFER_WIDTH,
RENDERBUFFER_HEIGHT, or RENDERBUFFER_INTERNAL_FORMAT,
RENDERBUFFER_RED_SIZE, RENDERBUFFER_GREEN_SIZE,
RENDERBUFFER_BLUE_SIZE, RENDERBUFFER_ALPHA_SIZE,
RENDERBUFFER_DEPTH_SIZE, or RENDERBUFFER_STENCIL_SIZE.
The error INVALID_VALUE is generated if RenderbufferStorage is
called with a <width> or <height> that is greater than
MAX_RENDERBUFFER_SIZE.
The error INVALID_ENUM is generated if RenderbufferStorage is
called with an <internalformat> that is not RGB, RGBA,
DEPTH_COMPONENT, STENCIL_INDEX, DEPTH_STENCIL, or one of the
internal formats from table 3.16 or table 2.nnn that has a base
internal format of RGB, RGBA, DEPTH_COMPONENT, STENCIL_INDEX, r
DEPTH_STENCIL.
The error INVALID_OPERATION is generated if
FramebufferRenderbuffer is called and <renderbuffer> is not the
name of a renderbuffer object.
The error INVALID_OPERATION is generated if
FramebufferTexture{1D|2D|3D} is called and <texture> is not the
name of a texture object.
The error INVALID_VALUE is generated if
FramebufferTexture{1D|2D|3D} is called with a <level> that is
less than zero.
The error INVALID_VALUE is generated if FramebufferTexture2D is
called with a <level> that is not zero and <textarget> is
TEXTURE_RECTANGLE_ARB.
The error INVALID_VALUE is generated if FramebufferTexture{1D|2D}
is called with a <level> that is greater than the log base 2 of
MAX_TEXTURE_SIZE and <texture> is a 1D or 2D texture.
The error INVALID_VALUE is generated if FramebufferTexture2D
is called with a <level> that is greater than the log base 2 of
MAX_CUBE_MAP_TEXTURE_SIZE and <texture> is a cubemap texture.
The error INVALID_VALUE is generated if FramebufferTexture3D is
called with a <level> greater than the log base 2 of the
MAX_3D_TEXTURE_SIZE.
The error INVALID_VALUE is generated if FramebufferTexture3D is
called with a <layer> that is larger than MAX_3D_TEXTURE_SIZE-1.
The error INVALID_VALUE is generated by BlitFramebuffer if
<mask> has any bits set other than those named by
COLOR_BUFFER_BIT, DEPTH_BUFFER_BIT or STENCIL_BUFFER_BIT.
The error INVALID_OPERATION is generated if BlitFramebuffer is
called and <mask> includes DEPTH_BUFFER_BIT or STENCIL_BUFFER_BIT
and <filter> is not NEAREST.
The error INVALID_OPERATION is generated if BlitFramebuffer is
called and <mask> includes DEPTH_BUFFER_BIT or STENCIL_BUFFER_BIT
and the source and destination depth or stencil buffer formats do
not match.
The error INVALID_ENUM is generated by BlitFramebuffer if
<filter> is not LINEAR or NEAREST.
The error INVALID_OPERATION is generated if BlitFramebuffer
is called within a Begin/End pair.
The error INVALID_ENUM is generated if BindFramebuffer,
CheckFramebufferStatus, FramebufferTexture{1D|2D|3D},
FramebufferRenderbuffer, or
GetFramebufferAttachmentParameteriv is called and <target> is
not DRAW_FRAMEBUFFER, READ_FRAMEBUFFER or FRAMEBUFFER.
The error INVALID_OPERATION is generated if
CheckFramebufferStatus is called within a Begin/End pair.
The error OUT_OF_MEMORY is generated if the GL is unable to create a
data store of the required size when calling RenderbufferStorage.
The error INVALID_OPERATION is generated if GenerateMipmap is
called with a <target> of TEXTURE_CUBE_MAP and the texture object
currently bound to TEXTURE_CUBE_MAP is not "cube complete" as
defined in section 3.8.10
The error INVALID_OPERATION is generated if ReadPixels,
CopyPixels, CopyTex{Sub}Image*, CopyColor{Sub}Table, or
CopyConvolutionFilter* is called while READ_FRAMEBUFFER_BINDING
is non-zero, the read framebuffer is framebuffer complete, and the
value of SAMPLE_BUFFERS for the read framebuffer is greater than
zero.
The error OUT_OF_MEMORY is generated when
RenderbufferStorageMultisample cannot create storage of the
specified size.
If both the draw and read framebuffers are framebuffer complete and
both have a value of SAMPLE_BUFFERS that is greater than zero, then
the error INVALID_OPERATION is generated if BlitFramebuffer is
called and the values of SAMPLES for the draw and read framebuffers
do not match.
If both the draw and read framebuffers are framebuffer complete and
either has a value of SAMPLE_BUFFERS that is greater than zero, then
the error INVALID_OPERATION is generated if BlitFramebuffer is
called and the formats of the draw and read framebuffers are not
identical.
If either the draw or read framebuffer is framebuffer complete and
has a value of SAMPLE_BUFFERS that is greater than zero, then the
error INVALID_OPERATION is generated if BlitFramebuffer is called
and the specified source and destination dimensions are not
identical.
If RenderbufferStorageMultisample is called with a value of
<samples> that is greater than MAX_SAMPLES, then the error
INVALID_VALUE is generated.
The error INVALID_ENUM is generated if DrawPixels or ReadPixels is
called where format is DEPTH_STENCIL and type is not
UNSIGNED_INT_24_8.
The error INVALID_OPERATION is generated if DrawPixels or ReadPixels
is called where type is UNSIGNED_INT_24_8 and format is not
DEPTH_STENCIL.
The error INVALID_OPERATION is generated if DrawPixels or ReadPixels
is called where format is DEPTH_STENCIL and there is not both a
depth buffer and a stencil buffer.
The error INVALID_OPERATION is generated if CopyPixels is called
where type is DEPTH_STENCIL and there is not both a depth buffer
and a stencil buffer.
New State
(add new table 3.nnn, "Framebuffer (state per framebuffer target binding point)")
Get Value Type Get Command Initial Value Description Section Attribute
------------------------ ---- ----------- -------------- ------------------- ------------ ---------
DRAW_FRAMEBUFFER_BINDING Z+ GetIntegerv 0 Framebuffer object bound 4.4.1 -
to DRAW_FRAMEBUFFER
READ_FRAMEBUFFER_BINDING Z+ GetIntegerv 0 Framebuffer object 4.4.1 -
to READ_FRAMEBUFFER
(insert new table 4.nnn, "Framebuffer (state per framebuffer object)")
Get Value Type Get Command Initial Value Description Section Attribute
---------------- ------ ------------- ------------- -------------------- ------------ ---------
DRAW_BUFFERi [1] 1 + xZ(10*) GetIntegerv see 4.2.1 Draw buffer selected 4.2.1 color-buffer
for color output i
READ_BUFFER [2] Z(3) GetIntegerv see 4.3.2 Read source buffer 4.3.2 pixel
[1] prior to this extension, the DRAW_BUFFERi state was
described in table 6.21 "Framebuffer Control" of the OpenGL
2.0 specification.
[2] prior to this extension, the READ_BUFFER state was described
in table 6.26 "Pixel" of the OpenGL 2.0 specification.
(insert new table 5.nnn, "Framebuffer (state per framebuffer object attachment point)")
Get Value Type Get Command Initial Value Description Section Attribute
-------------------------------------------- ---- -------------------------------------- ------------- -------------------- ------------ ---------
FRAMEBUFFER_ATTACHMENT_OBJECT_TYPE Z GetFramebufferAttachmentParameteriv NONE type of 4.4.2.2 and -
image attached to 4.4.2.3
framebuffer attachment
point
FRAMEBUFFER_ATTACHMENT_OBJECT_NAME Z GetFramebufferAttachmentParameteriv 0 name of object 4.4.2.2 and -
attached to 4.4.2.3
framebuffer attachment
point
FRAMEBUFFER_ATTACHMENT_TEXTURE_LEVEL Z GetFramebufferAttachmentParameteriv 0 mipmap level of 4.4.2.2 and -
texture image 4.4.2.3
attached, if object
attached is texture.
FRAMEBUFFER_ATTACHMENT_TEXTURE_CUBE_MAP_FACE Z+ GetFramebufferAttachmentParameteriv NONE cubemap face of 4.4.2.2 and -
texture image 4.4.2.3
attached, if object
attached is cubemap
texture.
FRAMEBUFFER_ATTACHMENT_TEXTURE_LAYER Z GetFramebufferAttachmentParameteriv 0 layer of 4.4.2.2 and -
texture image 4.4.2.3
attached, if object
attached is 3D texture.
FRAMEBUFFER_ATTACHMENT_COLOR_ENCODING Z_2 GetFramebufferAttachmentParameteriv - Encoding of components 6.1.3 -
in the attached image
FRAMEBUFFER_ATTACHMENT_COMPONENT_TYPE Z_4 GetFramebufferAttachmentParameteriv - Data type of components 6.1.3 -
in the attached image
FRAMEBUFFER_ATTACHMENT_RED_SIZE Z+ GetFramebufferAttachmentParameteriv - Size in bits of att. 6.1.3 -
image's red component
FRAMEBUFFER_ATTACHMENT_GREEN_SIZE Z+ GetFramebufferAttachmentParameteriv - Size in bits of att. 6.1.3 -
image's green component
FRAMEBUFFER_ATTACHMENT_BLUE_SIZE Z+ GetFramebufferAttachmentParameteriv - Size in bits of att. 6.1.3 -
image's blue component
FRAMEBUFFER_ATTACHMENT_ALPHA_SIZE Z+ GetFramebufferAttachmentParameteriv - Size in bits of att. 6.1.3 -
image's alpha component
FRAMEBUFFER_ATTACHMENT_DEPTH_SIZE Z+ GetFramebufferAttachmentParameteriv - Size in bits of att. 6.1.3 -
image's depth component
FRAMEBUFFER_ATTACHMENT_STENCIL_SIZE Z+ GetFramebufferAttachmentParameteriv - Size in bits of att. 6.1.3 -
image's stencil component
(insert new table 7.nnn, "Renderbuffers (state per renderbuffer target and binding point)")
Get Value Type Get Command Initial Value Description Section Attribute
---------------------------- ------ ------------- ------------- -------------------- ------------ ---------
RENDERBUFFER_BINDING Z GetIntegerv 0 renderbuffer object 4.4.2.1 -
bound to RENDERBUFFER
(insert new table 8.nnn, "Renderbuffers (state per renderbuffer object)")
Get Value Type Get Command Initial Value Description Section Attribute
---------------------------- ------ ------------- ------------- -------------------- ------------ ---------
RENDERBUFFER_WIDTH Z GetRenderbufferParameteriv 0 width of renderbuffer 4.4.2.1 -
RENDERBUFFER_HEIGHT Z GetRenderbufferParameteriv 0 height of renderbuffer 4.4.2.1 -
RENDERBUFFER_INTERNAL_FORMAT Z+ GetRenderbufferParameteriv RGBA internal format 4.4.2.1 -
of renderbuffer
RENDERBUFFER_RED_SIZE Z GetRenderbufferParameteriv 0 size in bits of 4.4.2.1 -
renderbuffer image's
red component
RENDERBUFFER_GREEN_SIZE Z GetRenderbufferParameteriv 0 size in bits of 4.4.2.1 -
renderbuffer image's
green component
RENDERBUFFER_BLUE_SIZE Z GetRenderbufferParameteriv 0 size in bits of 4.4.2.1 -
renderbuffer image's
blue component
RENDERBUFFER_ALPHA_SIZE Z GetRenderbufferParameteriv 0 size in bits of 4.4.2.1 -
renderbuffer image's
alpha component
RENDERBUFFER_DEPTH_SIZE Z GetRenderbufferParameteriv 0 size in bits of 4.4.2.1 -
renderbuffer image's
depth component
RENDERBUFFER_STENCIL_SIZE Z GetRenderbufferParameteriv 0 size in bits of 4.4.2.1 -
renderbuffer image's
stencil component
RENDERBUFFER_SAMPLES Z+ GetRenderbufferParameteriv 0 number of samples 4.4.2.1 -
Move the following existing state from "Implementation Dependent
Values", tables 6.33-6.37 to into a new table called "Framebuffer
Dependent Values", table 9.nnn.
Get Value
---------
AUX_BUFFERS
MAX_DRAW_BUFFERS
RGBA_MODE
INDEX_MODE
DOUBLEBUFFER
STEREO
SAMPLE_BUFFERS
SAMPLES
RED_BITS
GREEN_BITS
BLUE_BITS
ALPHA_BITS
INDEX_BITS
DEPTH_BITS
STENCIL_BITS
ACCUM_RED_BITS
ACCUM_GREEN_BITS
ACCUM_BLUE_BITS
ACCUM_ALPHA_BITS
To the same table called "Framebuffer Dependent Values", table 9.nnn
add the following new framebuffer dependent state.
Get Value Type Get Command Minimum Value Description Section Attribute
--------- ---- ----------- ------------- ------------------- ------- ---------
MAX_COLOR_ATTACHMENTS Z+ GetIntegerv 1 Maximum number of 4.4.2.2 -
attachment points
for color buffers
when using framebuffer
objects
MAX_SAMPLES Z+ GetIntegerv 0 Maximum number of 4.4.2.1 -
samples supported
for multisampling
New Implementation Dependent State
Get Value Type Get Command Minimum Value Description Section Attribute
--------- ---- ----------- ------------- ------------------- ------- ---------
MAX_RENDERBUFFER_SIZE Z+ GetIntegerv 64 Maximum width and 4.4.2.1 -
height of
renderbuffers
supported by
the implementation
Additions to the AGL/GLX/WGL Specifications and dependencies on
WGL_ARB_make_current_read, GLX_SGI_make_current_read, and GLX 1.3
The color, depth, stencil, aux, and accum logical buffers defined by
the <draw> and <read> drawables passed to glXMakeContextCurrent,
glXMakeCurrent, and glXMakeCurrentRead are ignored while the value
of DRAW_FRAMEBUFFER_BINDING is non-zero.
Dependencies on ATI_draw_buffers and ARB_draw_buffers
If neither ATI_draw_buffers nor ARB_draw_buffers are supported, then
all discussions of DrawBuffers should be ignored.
In addition, the language describing DrawBuffers are derived from a
combination of the ARB_draw_buffers specification and section 4.2.1
of the OpenGL 2.0 specification.
Dependencies on ARB_fragment_program, ARB_fragment_shader, and
ARB_vertex_shader
If ARB_fragment_program, ARB_fragment_shader, and ARB_vertex_shader
are all not supported, then all references to the currently bound
program or shader should be ignored.
Dependencies on ARB_texture_rectangle
If ARB_texture_rectangle is not supported, then all references to
TEXTURE_RECTANGLE_ARB should be ignored.
Dependencies on ARB_color_buffer_float
The reference to CLAMP_FRAGMENT_COLOR_ARB in section 4.3.3 applies
only if ARB_color_buffer_float is supported.
Dependencies on ARB_texture_rg
If ARB_texture_rg is not supported, delete the references to RED and
RG from the list of color-renderable base internal formats from
section 4.4.4.
Dependencies on NV_float_buffer
If NV_float_buffer is not supported, delete the references to
FLOAT_R_NV, FLOAT_RG_NV, FLOAT_RGB_NV and FLOAT_RGBA_NV from the list
of color-renderable base internal formats from section 4.4.4
Dependencies on EXT_framebuffer_object
Framebuffer objects created with the commands defined by the
GL_EXT_framebuffer_object extension are defined to be shared, while
FBOs created with commands defined by the OpenGL core or
GL_ARB_framebuffer_object extension are defined *not* to be shared.
However, the following functions are viewed as aliases (in particular
the opcodes for X are also the same) between the functions of
GL_EXT_framebuffer_object and GL_ARB_framebuffer_object:
IsRenderbufferEXT / IsRenderbuffer
DeleteRenderbuffersEXT / DeleteRenderbuffers
GenRenderbuffersEXT / GenRenderbuffers
RenderbufferStorageEXT / RenderbufferStorage
GetRenderbufferParameterivEXT / GetRenderbufferParameteriv
IsFramebufferEXT / IsFramebuffer
DeleteFramebuffersEXT / DeleteFramebuffers
GenFramebuffersEXT / GenFramebuffers
CheckFramebufferStatusEXT / CheckFramebufferStatus
FramebufferTexture1DEXT / FramebufferTexture1D
FramebufferTexture2DEXT / FramebufferTexture2D
FramebufferRenderbufferEXT / FramebufferRenderbuffer
GenerateMipmapEXT / GenerateMipmap
GetFramebufferAttachmentParameterivEXT / GetFramebufferAttachmentParameteriv
Since the above pairs are aliases, the functions of a pair are
equivalent. Note that the functions BindFramebuffer and
BindFramebufferEXT are not aliases and neither are the functions
BindRenderbuffer and BindRenderbufferEXT. Because object creation
occurs when the framebuffer object is bound for the first time, a
framebuffer object can be shared across contexts only if it was first
bound with BindFramebufferEXT. Framebuffers first bound with
BindFramebuffer may not be shared across contexts. Framebuffer
objects created with BindFramebufferEXT may subsequently be bound
using BindFramebuffer. Framebuffer objects created with
BindFramebuffer may be bound with BindFramebufferEXT provided they are
bound to the same context they were created on.
Dependencies on EXT_texture_array
If EXT_texture_array is not supported, delete all references to
one- and two-dimensional array textures.
Dependencies on EXT_texture_integer
If EXT_texture_integer is not supported, the following changes should
be made:
The definition of GetFramebufferAttachmentParameteriv should be
modified to remove any references to signed and unsigned integer
components for color buffers and the values of INT and UNSIGNED_INT
should be removed from the list of possible values for <param> when
<pname> is FRAMEBUFFER_ATTACHMENT_COMPONENT_TYPE.
Dependencies on ARB_framebuffer_sRGB
If ARB_framebuffer_sRGB is not supported, the following changes should
be made:
The definition of GetFramebufferAttachmentParameteriv should be
modified to remove any reference to sRGB-encoded components or
color buffers and sRGB conversion. The value of SRGB should be
removed from the list of possible values for <param> when <pname> is
FRAMEBUFFER_ATTACHMENT_COLOR_ENCODING.
GLX Protocol
Nineteen new GL commands are added.
The following thirteen rendering commands are sent to the server
as part of a glXRender request:
BindRenderbuffer
2 12 rendering command length
2 235 rendering command opcode
4 ENUM target
4 CARD32 renderbuffer
DeleteRenderbuffer
2 8+n*4 rendering command length
2 4317 rendering command opcode
4 CARD32 n
n*4 LISTofCARD32 renderbuffers
RenderbufferStorage
2 20 rendering command length
2 4318 rendering command opcode
4 ENUM target
4 ENUM internalFormat
4 CARD32 width
4 CARD32 height
RenderbufferStorageMultisample
2 24 rendering command length
2 4331 rendering command opcode
4 ENUM target
4 CARD32 samples
4 ENUM internalformat
4 CARD32 width
4 CARD32 height
BindFramebuffer
2 12 rendering command length
2 236 rendering command opcode
4 ENUM target
4 CARD32 framebuffer
DeleteFramebuffer
2 8+n*4 rendering command length
2 4320 rendering command opcode
4 CARD32 n
n*4 LISTofCARD32 framebuffers
FramebufferTexture1D
2 24 rendering command length
2 4321 rendering command opcode
4 ENUM target
4 ENUM attachment
4 ENUM textarget
4 CARD32 texture
4 CARD32 level
FramebufferTexture2D
2 24 rendering command length
2 4322 rendering command opcode
4 ENUM target
4 ENUM attachment
4 ENUM textarget
4 CARD32 texture
4 CARD32 level
FramebufferTexture3D
2 28 rendering command length
2 4323 rendering command opcode
4 ENUM target
4 ENUM attachment
4 ENUM textarget
4 CARD32 texture
4 CARD32 level
4 CARD32 layer
FramebufferTextureLayer
2 24 rendering command length
2 237 rendering command opcode
4 ENUM target
4 ENUM attachment
4 CARD32 texture
4 CARD32 level
4 CARD32 layer
FramebufferRenderbuffer
2 20 rendering command length
2 4324 rendering command opcode
4 ENUM target
4 ENUM attachment
4 ENUM renderbuffertarget
4 CARD32 renderbuffer
BlitFramebuffer
2 44 rendering command length
2 4330 rendering command opcode
4 CARD32 source X0
4 CARD32 source Y0
4 CARD32 source X1
4 CARD32 source Y1
4 CARD32 destination X0
4 CARD32 destination Y0
4 CARD32 destination X1
4 CARD32 destination Y1
4 CARD32 mask
4 ENUM filter
GenerateMipmap
2 8 rendering command length
2 4325 rendering command opcode
4 ENUM target
The remaining seven commands are non-rendering commands. These
commands are sent separately (i.e., not as part of a glXRender or
glXRenderLarge request), using the glXVendorPrivateWithReply
request:
IsRenderbuffer
1 CARD8 opcode (X assigned)
1 17 GLX opcode (X_GLXVendorPrivateWithReply)
2 4 request length
4 1422 vendor specific opcode
4 GLX_CONTEXT_TAG context tag
4 CARD32 renderbuffer
=>
1 1 reply
1 unused
2 CARD16 sequence number
4 0 reply length
4 BOOL32 return value
20 unused
GenRenderbuffers
1 CARD8 opcode (X assigned)
1 17 GLX opcode (X_GLXVendorPrivateWithReply)
2 4 request length
4 1423 vendor specific opcode
4 GLX_CONTEXT_TAG context tag
4 CARD32 n
=>
1 1 reply
1 unused
2 CARD16 sequence number
4 m reply length
4 unused
4 CARD32 n
16 unused
n*4 LISTofCARD32 renderbuffers
GetRenderbufferParameteriv
1 CARD8 opcode (X assigned)
1 17 GLX opcode (X_GLXVendorPrivateWithReply)
2 5 request length
4 1424 vendor specific opcode
4 GLX_CONTEXT_TAG context tag
4 ENUM target
4 ENUM pname
=>
1 1 reply
1 unused
2 CARD16 sequence number
4 m reply length, m = (n == 1 ? 0 : n)
4 unused
4 CARD32 n
if (n = 1) this follows:
4 CARD32 params
12 unused
otherwise this follows:
16 unused
n*4 LISTofCARD32 params
IsFramebuffer
1 CARD8 opcode (X assigned)
1 17 GLX opcode (X_GLXVendorPrivateWithReply)
2 4 request length
4 1425 vendor specific opcode
4 GLX_CONTEXT_TAG context tag
4 CARD32 framebuffer
=>
1 1 reply
1 unused
2 CARD16 sequence number
4 0 reply length
4 BOOL32 return value
20 unused
GenFramebuffers
1 CARD8 opcode (X assigned)
1 17 GLX opcode (X_GLXVendorPrivateWithReply)
2 4 request length
4 1426 vendor specific opcode
4 GLX_CONTEXT_TAG context tag
4 CARD32 n
=>
1 1 reply
1 unused
2 CARD16 sequence number
4 n reply length
4 unused
4 CARD32 n
16 unused
n*4 LISTofCARD32 framebuffers
CheckFramebufferStatus
1 CARD8 opcode (X assigned)
1 17 GLX opcode (X_GLXVendorPrivateWithReply)
2 4 request length
4 1427 vendor specific opcode
4 GLX_CONTEXT_TAG context tag
4 ENUM target
=>
1 1 reply
1 unused
2 CARD16 sequence number
4 0 reply length
4 ENUM return value
20 unused
GetFramebufferAttachmentParameteriv
1 CARD8 opcode (X assigned)
1 17 GLX opcode (X_GLXVendorPrivateWithReply)
2 6 request length
4 1428 vendor specific opcode
4 GLX_CONTEXT_TAG context tag
4 ENUM target
4 ENUM attachment
4 ENUM pname
=>
1 1 reply
1 unused
2 CARD16 sequence number
4 m reply length, m = (n == 1 ? 0 : n)
4 unused
4 CARD32 n
if (n = 1) this follows:
4 CARD32 params
12 unused
otherwise this follows:
16 unused
n*4 LISTofCARD32 params
Usage Examples
The following examples use a helper macro for
CHECK_FRAMEBUFFER_STATUS, defined below.
Example (6) gives a (very slightly) more robust example of handling
the possible return values for glCheckFramebufferStatus.
#define CHECK_FRAMEBUFFER_STATUS() \
{ \
GLenum status; \
status = glCheckFramebufferStatus(GL_DRAW_FRAMEBUFFER); \
switch(status) { \
case GL_FRAMEBUFFER_COMPLETE: \
break; \
case GL_FRAMEBUFFER_UNSUPPORTED: \
/* choose different formats */ \
break; \
default: \
/* programming error; will fail on all hardware */ \
assert(0); \
}
}
(1) Render to 2D texture with a depth buffer
// Given: color_tex - TEXTURE_2D color texture object
// depth_rb - GL_DEPTH renderbuffer object
// fb - framebuffer object
// Enable render-to-texture
glBindFramebuffer(GL_DRAW_FRAMEBUFFER, fb);
// Set up color_tex and depth_rb for render-to-texture
glFramebufferTexture2D(GL_DRAW_FRAMEBUFFER,
GL_COLOR_ATTACHMENT0,
GL_TEXTURE_2D, color_tex, 0);
glFramebufferRenderbuffer(GL_DRAW_FRAMEBUFFER,
GL_DEPTH_ATTACHMENT,
GL_RENDERBUFFER, depth_rb);
// Check framebuffer completeness at the end of initialization.
CHECK_FRAMEBUFFER_STATUS();
<draw to the texture and renderbuffer>
// Re-enable rendering to the window
glBindFramebuffer(GL_DRAW_FRAMEBUFFER, 0);
glBindTexture(GL_TEXTURE_2D, color_tex);
<draw to the window, reading from the color_tex>
(2) Application that supports both RBBCTT (render back buffer, copy to
texture) and RTT (render to texture). The migration path from RBBCTT
to RTT is easy.
if (useFramebuffer) {
glBindFramebuffer(GL_DRAW_FRAMEBUFFER, fb);
glFramebufferTexture2D(GL_DRAW_FRAMEBUFFER,
GL_COLOR_ATTACHMENT0,
GL_TEXTURE_2D, color_tex, 0);
CHECK_FRAMEBUFFER_STATUS();
}
draw_to_texture();
glBindTexture (GL_TEXTURE_2D, color_tex);
if (useFramebuffer) {
glBindFramebuffer(GL_DRAW_FRAMEBUFFER, 0);
} else { // copy tex path
glCopyTexSubImage(...);
}
(3) Simple render-to-texture loop with initialization. Create an
RGB8 texture, a 24-bit depth renderbuffer, and a stencil
renderbuffer. In a loop, alternate between rendering to, and
texturing out of, the color texture.
glGenFramebuffers(1, &fb);
glGenTextures(1, &color_tex);
glGenRenderbuffers(1, &depth_rb);
glGenRenderbuffers(1, &stencil_rb);
glBindFramebuffer(GL_DRAW_FRAMEBUFFER, fb);
// initialize color texture
glBindTexture(GL_TEXTURE_2D, color_tex);
glTexParameterf(GL_TEXTURE_2D, GL_TEXTURE_MIN_FILTER, GL_LINEAR);
glTexImage2D(GL_TEXTURE_2D, 0, GL_RGB8, 512, 512, 0,
GL_RGB, GL_INT, NULL);
glFramebufferTexture2D(GL_DRAW_FRAMEBUFFER,
GL_COLOR_ATTACHMENT0,
GL_TEXTURE_2D, color_tex, 0);
// initialize depth renderbuffer
glBindRenderbuffer(GL_RENDERBUFFER, depth_rb);
glRenderbufferStorage(GL_RENDERBUFFER,
GL_DEPTH_COMPONENT24, 512, 512);
glFramebufferRenderbuffer(GL_DRAW_FRAMEBUFFER,
GL_DEPTH_ATTACHMENT,
GL_RENDERBUFFER, depth_rb);
// initialize stencil renderbuffer
glBindRenderbuffer(GL_RENDERBUFFER, stencil_rb);
glRenderbufferStorage(GL_RENDERBUFFER,
GL_STENCIL_INDEX, 512, 512);
glFramebufferRenderbuffer(GL_DRAW_FRAMEBUFFER,
GL_STENCIL_ATTACHMENT,
GL_RENDERBUFFER, stencil_rb);
// Check framebuffer completeness at the end of initialization.
CHECK_FRAMEBUFFER_STATUS();
loop {
glBindTexture(GL_TEXTURE_2D, 0);
glBindFramebuffer(GL_DRAW_FRAMEBUFFER, fb);
<draw to the texture>
glBindFramebuffer(GL_DRAW_FRAMEBUFFER, 0);
glBindTexture(GL_TEXTURE_2D, color_tex);
<draw to the window, reading from the color texture>
}
(4) Render-to-texture loop with automatic mipmap generation. There
are N framebuffers, N mipmap color textures, and a single shared
depth renderbuffer. The depth renderbuffer is not a mipmap.
GLuint fb_array[N];
GLuint color_tex_array[N];
GLuint depth_rb;
glGenFramebuffers(N, fb_array);
glGenTextures(N, color_tex_array);
glGenRenderbuffers(1, &depth_rb);
// initialize color textures
for (int i=0; i<N; i++) {
glBindTexture(GL_TEXTURE_2D, color_tex_array[N]);
glTexImage2D(GL_TEXTURE_2D, 0, GL_RGB8, 512, 512, 0,
GL_RGB, GL_INT, NULL);
// establish a mipmap chain for the texture
glGenerateMipmap(GL_TEXTURE_2D);
}
// initialize depth renderbuffer
glBindRenderbuffer(GL_RENDERBUFFER, depth_rb);
glRenderbufferStorage(GL_RENDERBUFFER,
GL_DEPTH_COMPONENT24, 512, 512);
// setup framebuffers, sharing depth
for (int i=0; i<N; i++) {
glBindFramebuffer(GL_DRAW_FRAMEBUFFER, fb_array[i]);
glFramebufferTexture2D(GL_DRAW_FRAMEBUFFER,
GL_COLOR_ATTACHMENT0,
GL_TEXTURE_2D, color_tex_array[i], 0);
glFramebufferRenderbuffer(GL_DRAW_FRAMEBUFFER,
GL_DEPTH_ATTACHMENT,
GL_RENDERBUFFER, depth_rb);
}
// Check framebuffer completeness at the end of initialization.
CHECK_FRAMEBUFFER_STATUS();
loop {
glBindTexture(GL_TEXTURE_2D, 0);
for (int i=0; i<N; i++) {
glBindFramebuffer(GL_DRAW_FRAMEBUFFER, fb_array[i]);
<draw to texture i>
}
glBindFramebuffer(GL_DRAW_FRAMEBUFFER, 0);
// automatically generate mipmaps
for (int i=0; i<N; i++) {
glBindTexture(GL_TEXTURE_2D, color_tex_array[i]);
glGenerateMipmap(GL_TEXTURE_2D);
}
<draw to the window, reading from the color textures>
}
(5) Render-to-texture loop with custom mipmap generation.
The depth renderbuffer is not a mipmap.
glGenFramebuffers(1, &fb);
glGenTextures(1, &color_tex);
glGenRenderbuffers(1, &depth_rb);
glBindFramebuffer(GL_DRAW_FRAMEBUFFER, fb);
// initialize color texture and establish mipmap chain
glBindTexture(GL_TEXTURE_2D, color_tex);
glTexImage2D(GL_TEXTURE_2D, 0, GL_RGB8, 512, 512, 0,
GL_RGB, GL_INT, NULL);
glGenerateMipmap(GL_TEXTURE_2D);
glFramebufferTexture2D(GL_DRAW_FRAMEBUFFER,
GL_COLOR_ATTACHMENT0,
GL_TEXTURE_2D, color_tex, 0);
// initialize depth renderbuffer
glBindRenderbuffer(GL_RENDERBUFFER, depth_rb);
glRenderbufferStorage(GL_RENDERBUFFER,
GL_DEPTH_COMPONENT24, 512, 512);
glFramebufferRenderbuffer(GL_DRAW_FRAMEBUFFER,
GL_DEPTH_ATTACHMENT,
GL_RENDERBUFFER, depth_rb);
// Check framebuffer completeness at the end of initialization.
CHECK_FRAMEBUFFER_STATUS();
loop {
glBindTexture(GL_TEXTURE_2D, 0);
glBindFramebuffer(GL_DRAW_FRAMEBUFFER, fb);
glFramebufferTexture2D(GL_DRAW_FRAMEBUFFER,
GL_COLOR_ATTACHMENT0,
GL_TEXTURE_2D, color_tex, 0);
glFramebufferRenderbuffer(GL_DRAW_FRAMEBUFFER,
GL_DEPTH_ATTACHMENT,
GL_RENDERBUFFER, depth_rb);
<draw to the base level of the color texture>
// custom-generate successive mipmap levels
glFramebufferRenderbuffer(GL_DRAW_FRAMEBUFFER,
GL_DEPTH_ATTACHMENT,
GL_RENDERBUFFER, 0);
glBindTexture(GL_TEXTURE_2D, color_tex);
foreach (level > 0, in order of increasing values of level) {
glFramebufferTexture2D(GL_DRAW_FRAMEBUFFER,
GL_COLOR_ATTACHMENT0,
GL_TEXTURE_2D, color_tex, level);
glTexParameteri(TEXTURE_2D, TEXTURE_BASE_LEVEL, level-1);
glTexParameteri(TEXTURE_2D, TEXTURE_MAX_LEVEL, level-1);
<draw to level>
}
glTexParameteri(TEXTURE_2D, TEXTURE_BASE_LEVEL, 0);
glTexParameteri(TEXTURE_2D, TEXTURE_MAX_LEVEL, max);
glBindFramebuffer(GL_DRAW_FRAMEBUFFER, 0);
<draw to the window, reading from the color texture>
}
(6) Pseudo-code example of one method of responding to
FRAMEBUFFER_UNSUPPORTED
bool done = false;
bool success = false;
int configurationNumber = 0;
GLenum status;
while (!done)
{
for (each framebuffer-attachable image)
{
ChooseInternalFormatForFramebufferAttachableImage(configurationNumber);
CreateFramebufferAttachableImage();
AttachFramebufferAttachableImageToFramebuffer();
}
status = glCheckFramebufferStatus(GL_DRAW_FRAMEBUFFER);
switch(status)
{
case GL_FRAMEBUFFER_COMPLETE:
success = true;
done = true;
break;
case GL_FRAMEBUFFER_UNSUPPORTED:
if (configCount < MAX_NUM_CONFIGS_I_WANT_TO_TRY)
{
printf("current config not supported, trying again);
configurationNumber++;
}
else
{
printf("couldn't find a supported config\n");
success = false;
done = true;
}
break;
default:
// programming error; will fail on all hardware
FatalError();
exit(1);
}
}
if (!success)
{
printf("couldn't find a supported config\n");
FatalError();
exit(1);
}
// Current framebuffer is supported and complete!!
Draw();
(7) Render to depth texture with no color attachments
// Given: depth_tex - TEXTURE_2D depth texture object
// fb - framebuffer object
// Enable render-to-texture
glBindFramebuffer(GL_DRAW_FRAMEBUFFER, fb);
// Set up depth_tex for render-to-texture
glFramebufferTexture2D(GL_DRAW_FRAMEBUFFER,
GL_DEPTH_ATTACHMENT,
GL_TEXTURE_2D, depth_tex, 0);
// No color buffer to draw to or read from
glDrawBuffer(GL_NONE);
glReadBuffer(GL_NONE);
// Check framebuffer completeness at the end of initialization.
CHECK_FRAMEBUFFER_STATUS();
<draw something>
// Re-enable rendering to the window
glBindFramebuffer(GL_DRAW_FRAMEBUFFER, 0);
glBindTexture(GL_TEXTURE_2D, depth_tex);
<draw to the window, reading from the depth_tex>
(8) FBO and ARB_draw_buffers
// Given: color_texA - TEXTURE_2D color texture object
// Given: color_texB - TEXTURE_2D color texture object
// depth_rb - GL_DEPTH renderbuffer object
// fb - framebuffer object
// Set up the framebuffer object
glBindFramebuffer(GL_DRAW_FRAMEBUFFER, fb);
glFramebufferTexture2D(GL_DRAW_FRAMEBUFFER,
GL_COLOR_ATTACHMENT0,
GL_TEXTURE_2D, color_texA, 0);
glFramebufferTexture2D(GL_DRAW_FRAMEBUFFER,
GL_COLOR_ATTACHMENT1,
GL_TEXTURE_2D, color_texB, 0);
glFramebufferRenderbuffer(GL_DRAW_FRAMEBUFFER,
GL_DEPTH_ATTACHMENT,
GL_RENDERBUFFER, depth_rb);
// Enable both attachments as draw buffers
GLenum drawbuffers = {GL_COLOR_ATTACHMENT0,
GL_COLOR_ATTACHMENT1};
glDrawBuffers(2, drawbuffers);
// Check framebuffer completeness at the end of initialization.
CHECK_FRAMEBUFFER_STATUS();
// Enable fragment program that writes to both gl_FragData[0]
// and gl_FragData[1]
<draw something>
// Disable fragment program
// Re-enable rendering to the window
glBindFramebuffer(GL_DRAW_FRAMEBUFFER, 0);
// Bind both textures, each to a different texture unit
glActiveTexture(GL_TEXTURE0);
glBindTexture(GL_TEXTURE_2D, color_texA);
glActiveTexture(GL_TEXTURE1);
glBindTexture(GL_TEXTURE_2D, color_texB);
<draw to the window>
Sample Code (from framebuffer_blit)
/* Render to framebuffer object 2 */
glBindFramebuffer(DRAW_FRAMEBUFFER, 2);
RenderScene();
/* Blit contents of color buffer, depth buffer and stencil buffer
* from framebuffer object 2 to framebuffer object 1.
*/
glBindFramebuffer(GL_READ_FRAMEBUFFER, 2);
glBindFramebuffer(GL_DRAW_FRAMEBUFFER, 1);
glBlitFramebuffer(0, 0, 640, 480,
0, 0, 640, 480,
GL_COLOR_BUFFER_BIT |
GL_DEPTH_BUFFER_BIT |
GL_STENCIL_BUFFER_BIT,
GL_NEAREST);
/* Blit contents of color buffer from framebuffer object 1 to
* framebuffer object 2, inverting the image in the X direction.
*/
glBindFramebuffer(GL_READ_FRAMEBUFFER, 1);
glBindFramebuffer(GL_DRAW_FRAMEBUFFER, 2);
glBlitFramebuffer(0, 0, 640, 480,
640, 0, 0, 480,
GL_COLOR_BUFFER_BIT,
GL_NEAREST);
/* Blit color buffer from framebuffer object 1 to framebuffer
* object 3 with a 2X zoom and linear filtering.
*/
glBindFramebuffer(GL_READ_FRAMEBUFFER, 1);
glBindFramebuffer(GL_DRAW_FRAMEBUFFER, 3);
glBlitFramebuffer(0, 0, 640, 480,
0, 0, 1280, 960,
GL_COLOR_BUFFER_BIT, GL_LINEAR);
Usage Examples (from packed_depth_stencil)
(1) Attach a DEPTH_STENCIL texture image to an FBO as both the
depth and stencil buffers.
glGenFramebuffers(1, &fb);
glGenTextures(1, &tex_color);
glGenTextures(1, &tex_depthstencil);
glBindFramebuffer(GL_DRAW_FRAMEBUFFER, fb);
// Setup color texture (mipmap)
glBindTexture(GL_TEXTURE_2D, tex_color);
glTexImage2D(GL_TEXTURE_2D, 0, GL_RGB8,
512, 512, 0, GL_RGBA, GL_INT, NULL);
glGenerateMipmap(GL_TEXTURE_2D);
glFramebufferTexture2D(GL_DRAW_FRAMEBUFFER,
GL_COLOR_ATTACHMENT0,
GL_TEXTURE_2D, tex_color, 0);
// Setup depth_stencil texture (not mipmap)
glBindTexture(GL_TEXTURE_2D, tex_depthstencil);
glTexParameterf(GL_TEXTURE_2D, GL_TEXTURE_MIN_FILTER, GL_LINEAR);
glTexImage2D(GL_TEXTURE_2D, 0, GL_DEPTH24_STENCIL8,
512, 512, 0, GL_DEPTH_STENCIL,
GL_UNSIGNED_INT_24_8, NULL);
glFramebufferTexture2D(GL_DRAW_FRAMEBUFFER,
GL_DEPTH_ATTACHMENT,
GL_TEXTURE_2D, tex_depthstencil, 0);
glFramebufferTexture2D(GL_DRAW_FRAMEBUFFER,
GL_STENCIL_ATTACHMENT,
GL_TEXTURE_2D, tex_depthstencil, 0);
// Check framebuffer completeness at the end of initialization.
loop {
glBindTexture(GL_TEXTURE_2D, 0);
glBindFramebuffer(GL_DRAW_FRAMEBUFFER, fb);
<render to color, depth, and stencil textures>
glBindFramebuffer(GL_FRAMEBUFFER, 0);
glBindTexture(GL_TEXTURE_2D, tex_color);
glGenerateMipmap(GL_TEXTURE_2D);
<draw to the window, reading from the color texture>
glBindTexture(GL_TEXTURE_2D, tex_depthstencil);
<draw to the window, reading depth from the depthstencil texture>
}
Issues
(1) What should this extension be named?
RESOLVED. We will call this ARB_framebuffer_object.
(2) What additional functionality does this extension include over
EXT_framebuffer_object?
RESOLVED.
Currently we incorporate the following layered extensions:
* EXT_framebuffer_multisample
* EXT_framebuffer_blit
* EXT_packed_depth_stencil
As well as the following features:
* Permit attachments with different width and height (mixed
dimensions)
* Permit color attachments with different formats (mixed
formats).
* Render to 1 and 2 component R/RG formats that are provided
via the ARB_texture_rg extension. L/A/LA/I will be
left for a separate (trivial) extension.
* Gen'ed names must be used for framebuffer objects and
renderbuffers.
* Added FramebufferTextureLayer.
Other features we have considered include:
* Render to Vertex Attrib (RTVA)
* Format compatibility API that can guarantee a set of textures
images have framebuffer-compatible formats.
* Infolog or other means for communicating framebuffer
incompleteness information to the application for debugging
purposes.
* A technique for page flipping framebuffer-attachable images.
* Relaxing framebuffer completeness restrictions, possibly even
remove FRAMEBUFFER_UNSUPPORTED. Maybe go so far as to remove
CheckFramebufferStatus.
Features we have rejected include:
* GetRenderbufferImage (benefit/demand does not seem to
outweigh the additional complexity.)
* READ_BUFFER == NONE for framebuffer zero.
* Attach images from a window or from a pbuffer to an
application-created framebuffer object.
(3) What are the other differences from EXT_framebuffer_object.
* Framebuffer completeness only considers the attachments named
by DRAW_BUFFERi and READ_BUFFER. Any other attachments do
not affect framebuffer completeness. (In
EXT_framebuffer_object, all attachments affected framebuffer
completeness, independent of the DRAW_BUFFERi and READ_BUFFER
state.)
* Added new queries for the sizes of the bit planes for color,
depth and stencil attachments at a framebuffer attachment point.
* Added new queries for framebuffer attachment component type and
color encoding.
* Many other minor tweaks to synchronize with the GL3 framebuffer
objects.
* ARB FBOs are not shareable.
(4) Do we need new enum values, or can we re-use the ones from the EXT
versions?
RESOLVED. This extension is designed to be compatible with
EXT_framebuffer_object, and thus we can reuse the enumerants. There
are also a number of additional enumerants added in this extension.
(5) What should a query of RED_BITS, GREEN_BITS, BLUE_BITS, ALPHA_BITS.
return if the attached color-renderable images have different
formats?
RESOLVED. The values of RED_BITS, GREEN_BIT, BLUE_BITS and
ALPHA_BITS are only defined if all color attachments of the draw
framebuffer have identical formats, in which case the color
component sizes of color attachment zero are return. This is
necessary for backwards compatibility with EXT_framebuffer_object.
The actual sizes of the color, depth, or stencil bit planes can be
obtained by querying an attachment point using
GetFramebufferAttachmentParameteriv using the new
FRAMEBUFFER_ATTACHMENT_*_SIZE enumerants, or by querying the object
attached at that point.
(6) What are the proper names for the 1 and 2 component fixed-point,
float, and pure integer texture formats?
RESOLVED: as introduced in the 3.0 spec, using RED and RG base
internal format terminology. The new RED/RG formats have also been
spun out of 3.0 as the ARB_texture_rg extension.
(7) This extension and EXT_framebuffer_object both have "bind
framebuffer" functions (BindFramebuffer and BindFramebufferEXT). Are
there any differences in functionality between the two functions?
RESOLVED: Yes. Both extensions will create a new framebuffer object
if called with an unused name. However, BindFramebuffer defined in
this extension will generate an INVALID_OPERATION error if the name
provided has not been generated by GenFramebuffer. That error did
not exist in EXT_framebuffer_object, and this extension does not
modify the behavior of BindFramebufferEXT. This difference also
applies to BindRenderbuffer from this extension vs.
BindRenderbufferEXT from EXT_framebuffer_object.
(8) Why don't the new tokens and entry points in this extension have
"ARB" suffixes like other ARB extensions?
RESOLVED: Unlike most ARB extensions, this is a strict subset of
functionality already approved in OpenGL 3.0. This extension
exists only to support that functionality on older hardware that
cannot implement a full OpenGL 3.0 driver. Since there are no
possible behavior changes between the ARB extension and core
features, source code compatibility is improved by not using
suffixes on the extension.
(9) Should color-renderable textures be limited to a subset of
color base internal formats?
RESOLVED: No, all color base internal formats and
sized internal formats should be supported by FBO; the FBO
status can report what works and doesn't work.
The glCheckFramebufferStatus provides a mechanism for FBOs to
report whether or not the FBO configuration is supported or
not (i.e. GL_FRAMEBUFFER_UNSUPPORTED). If implementations
have issues supporting certain color formats for rendering,
the existing FBO mechanism is sufficient to report their lack
of support.
Prior to revision 29, the list of color-renderable base internal
formats did not include LUMINANCE, LUMINANCE_ALPHA, or INTENSITY
(and the EXT version of FBO did not list ALPHA either).
This lead to inconsistent operation of FBO. For example, you
could use a glFramebufferTexture2D to attach a texture that
was LUMINANCE, LUMINANCE_ALPHA, or INTENSITY to an FBO and find
out via glCheckFramebufferStatus that this combination wasn't
considered color-renderable, but if an internal format for one of
these base internal formats was used with glRenderbufferStorage,
then an OpenGL error would be generated according to the
specification. Such inconsistencies are undesirable and
unnecessarily limit the render-to-texture functionality exposed by
some implementations when hardware capable of rendering to
LUMINANCE, LUMINANCE_ALPHA, and INTENSITY textures does exist.
For this reason, revision 29 (specification version 1.1) adds
these previously missing based internal formats. Developers are
warned that some implementations (specification version 1.0)
will report OpenGL errors if glRenderbufferStorage is called for
LUMINANCE, INTENSITY, LUMINANCE_ALPHA formats (or even possibly
ALPHA in the case of the EXT version of FBO).
Some thought was given to introducing a new, one-off extension
(instead of a version 1.1) to allow the LUMINANCE, INTENSITY,
LUMINANCE_ALPHA base internal formats and their respective
sized formats to be color-renderable (both otherwise introduce
no new API). Given the existence of a mechanism for determine
whether or not an FBO is supported, simply providing this version
1.1 clarification was judged to be the most expedient approach.
This approach also provides consistency with other approved
ARB specifications such as ARB_framebuffer_sRGB which describes
(see its issue #9) that formats such as GL_SLUMINANCE8.
(10) Can ARB framebuffer objects be shared between contexts?
ARB_framebuffer_object is supposed to be compatible with
EXT_framebuffer_object, but also a subset of OpenGL 3.0.
EXT_framebuffer_object (rev. 120) explicitly allows sharing in
issue 76, but the 3.0 spec explicitly disallows it in Appendix D.
Resolved: No. ARB_framebuffer_object is intended to capture the
functionality that went into GL 3.0. Furthermore, given that the
entry points and tokens in this extension and the core are identical
there is no way that an implementation could differentiate FBOs
created with this extension from those created by core GL.
ADDITIONAL COMMENTS:
See the "Dependencies on EXT_framebuffer_object" section above for
the interaction behaviour between EXT and non-EXT FBO interfaces.
Revision History
#1, October 20, 2005: jjuliano
- branch from EXT_framebuffer_object
- Delete old issues and revision history
#2, November 28, 2005: jjuliano
- Add issues 1 and 2.
- Describe RenderbufferStorage in terms of color/depth/stencil
renderable with forward reference to 4.4.4.
- Reword the definitions of color/depth/stencil renderable.
- Explicitly state how framebuffer operations write to and read
from texture images.
- Incorporate feedback from Barthold.
#3-draft2, January 16, 2006: jjuliano
- Define the conversions to/from framebuffer in terms of the
internal format(s) of the attached image(s).
- Handle color mask in RGBA to internal component conversion.
- Improve language in section 4.4.5.
- Add dependencies on more extensions.
#4c April 28, 2008: dgkoch
- merge in framebuffer_blit and update other references to
FRAMEBUFFER_EXT and FRAMEBUFFER_BINDING_EXT, eliminating all
references to the obsolete bindings.
#5 May 2, 2008: rbarris, dgkoch
- merge in framebuffer_multisample
#6 May 8, 2008: dgkoch
- rebase against OpenGL 2.1 spec
#7 May 8, 2008: dgkoch
- merge in packed_depth_stencil
#8 May 8, 2008: dgkoch
- add caveat that MSAA to MSAA blit may have issues (khronos bug
#3005)
#9 May 9, 2008: dgkoch
- renamed from EXT_fbo2 to ARB_fbo. Changed all suffixes to _ARB
instead of _EXT.
#10 May 19, 2008: rbarris
- Bugzilla 3013: allow dimension mismatches (esp. depth)
#11 May 21, 2008: dgkoch
- Bugzilla 3014: allow different color formats when using MRT.
- added Issues 4, 5
- deleted FRAMEBUFFER_INCOMPLETE_FORMATS &
FRAMEBUFFER_INCOMPLETE_DIMENSIONS
- added text for proposed resolution of Issue (5)
#12 May 22, 2008: dgkoch
- Bugzilla 3015: define one- and two- component formats to be
color-renderable
- added Issue 6
#13 May 29, 2008: Jon Leech
- Many updates and minor fixes for consistency with the 3.0 spec
draft. Replace DEPTH with DEPTH_COMPONENT in most uses. Increase
MAX_RENDERBUFFER_SIZE to 64 matching MAX_TEXTURE_SIZE (pending
resolution of bug 3454). Pose some open questions preceded by
"***".
#14 June 26: dgkoch
- change MAX_SAMPLES to 0, to indicate the multisampling is not
required. (bug 3551)
#15 July 2: Jon Leech
- More updates for 3.0 spec consistency. Define meaning of <src>
NONE and FRONT_AND_BACK for ReadBuffer() - this was an
oversight introduced with the original extension. Replace
reference to nonexistent table 12.nnn with reference to
table 3.15. Start introducing RED and RG formats from 3.0 spec.
#16 July 10: dgkoch
- backport error change for DrawBuffer in 4.2.1 (bug 3530)
#17 July 12, 2008: Jon Leech
- Use 'layer' instead of 'zoffset' terminology. Add
FramebufferTextureLayer.
- Add framebuffer attachment queries for attachment component
size / type / color encoding.
- Allow framebuffer incomplete if no default framebuffer is made
current, with new framebuffer status error.
- Allow multisample buffers in framebuffer objects.
- Global renaming / simplification to "default framebuffer" and
"framebuffer object". Did not yet re-flow those paragraphs for
ease of comparison.
- Add more introductory material about framebuffers in chapter 2.
- Remove requirement that all color attachments have the same
depth.
- Restrict FBOs and renderbuffers to Gen'ed names as agreed for
3.0.
- Update clipping / buffer intersection / filtering rules for
BlitFramebuffer.
- Allow FRAMEBUFFER as a bind pseudotarget aliasing both read
and draw framebuffer targets. Allow DEPTH_STENCIL_ATTACHMENT
as an attachment alias for both depth and stencil attachments.
- Add Pat's introductory paragraph describing feedback loops in
section 4.4.3.
- Make RED_BITS etc. context queries defined iff all draw color
buffers have the same format.
- Remove "Dependencies" sections for NV extensions since we no
longer refer to their tokens. Need to add some dependencies
sections for new ARB extensions and figure out which language
goes here and which language with those extensions (e.g.
texture_rg, framebuffer_sRGB,
- Many minor non-functional language tweaks to match 3.0 core
language.
#18 July 14, 2008: Rob Barris
- Tidy up introductory/overview section
#19 July 16, 2008: Daniel Koch, Rob Barris
- add interactions with ARB_texture_rg, EXT_texture_array and
NV_float_buffer
- restore FRAMEBUFFER enumerant and restore all the text where
it had been accepted before (removed in version 4).
- allow texture arrays via FramebufferTextureLayer
- removed reference to required format list which we don't have here.
- updated resolution of issue (6)
#20 July 16, 2008: Daniel Koch, Rob Barris
- simplification of language for logical operation when a FB-image
is attached more than once
- add interactions with EXT_texture_integer and ARB_framebuffer_sRGB
- Resolved issues (2), (4) and (5)
- Updated issue (3) (although the list is still not exhaustive)
#21 July 17, 2008: Daniel Koch
- add Issue (7) as suggested by pbrown
- restore FRAMEBUFFER_BINDING alias
- fix incorrect references to FRAMEBUFFER_BINDING
#22 July 17, 2008: Jon Leech
- minor language cleanup for consistency with the 3.0 core spec.
#23 July 24, 2008: Jon Leech
- Use new GLX rendering opcodes for BindRenderbuffer and
BindFramebuffer so they can be semantically distinguished
from the EXT entry points.
- Add GLX protocol for FramebufferTextureLayer.
#24 August 7, 2008: Jon Leech
- Remove ARB suffixes.
#25 August 8, 2008: Jon Leech
- Add missing framebuffer attachment state for component type /
encoding / size to state tables.
#26 August 8, 2008: Jon Leech
- Add missing INDEX token for legacy default framebuffer
color buffer component types.
#27 August 20, 2008: Jon Leech
- Add ALPHA to list of color-renderable base internal formats to
sync with 3.0 spec language.
#28 November 17, 2008: Mark Kilgard & Nigel Stewart
- glFramebufferTexturLayerARB -> glFramebufferTextureLayerARB
(add final e to Texture)
#29 March 12, 2009: Jon Leech
- Edits in chapter 4 intro for consistency with GL core spec
language, including removing the completeness requirement that all
color buffers of an FBO be the same depth. Reflow some text for
readability.
#30 March 31, 2009: Mark Kilgard & Jeff Juliano
- Change color-renderable to be any color texture format.
Fix some typos.
#31 May 27, 2009: Jon Leech
- Change default value of FRAMEBUFFER_ATTACHMENT_TEXTURE_CUBE_MAP_FACE
to NONE (bug 4407).
#32 July 21, 2010: Daniel Koch
- Add issue 10 clarifying that ARB fbos cannot be shared.
#33 July 22, 2011: Jon Leech
- Remove error which disallowed non-multisample <-> sample blits
(bug 7367).
#34 October 2, 2011: Jon Leech
- Bring chapter 6 language changes in sync with the OpenGL 3.0 API
specification phrasing, and fix the description of
GetFramebufferAttachmentParameteriv to use DEPTH and STENCIL as
attachment names, rather than the nonexistent DEPTH_BUFFER and
STENCIL_BUFFER tokens (Bug 8102).
#35 June 29, 2013: Jon Leech
- Rearrange New Tokens section to allow all simple queries to be
queried with GetBooleanv as well, since it's defined to work for
all of them (Bug 6838).
#36, September 23, 2013: Jon Leech
- Specify that undefined behavior results when mixing EXT and
ARB_framebuffer_object / OpenGL 3.0 API framebuffer objects
(Bug 10738).
#37, June 20, 2016: Kevin Rogvin, James Jones
- Specify behaviour of mixing EXT and ARB_framebuffer_object /
OpenGL 3.0 framebuffer objects so that the aliases of the
functions are correctly observed (Bug 1485)
#38, October 6, 2016: Jon Leech
- Remove STENCIL_REF from list of state moved to become framebuffer
dependent (Bug 8422).