| Name |
| |
| EXT_framebuffer_multisample |
| |
| Name Strings |
| |
| GL_EXT_framebuffer_multisample |
| |
| Contributors |
| |
| Pat Brown |
| Michael Gold |
| Evan Hart |
| Jeff Juliano |
| Jon Leech |
| Bill Licea-Kane |
| Barthold Lichtenbelt |
| Kent Lin |
| Ian Romanick |
| John Rosasco |
| Jeremy Sandmel |
| |
| Contacts |
| |
| Jeff Juliano, NVIDIA Corporation (jjuliano 'at' nvidia.com) |
| Jeremy Sandmel, Apple Computer (jsandmel 'at' apple.com) |
| |
| Status |
| |
| Complete |
| Approved by the ARB "superbuffers" Working Group on November 8, 2005 |
| |
| Version |
| |
| Last Modified Date: January 10, 2007 |
| Revision: #7 |
| |
| Number |
| |
| 317 |
| |
| Dependencies |
| |
| Requires GL_EXT_framebuffer_object. |
| |
| Requires GL_EXT_framebuffer_blit. |
| |
| Written based on the wording of the OpenGL 1.5 specification. |
| |
| Overview |
| |
| This extension extends the EXT_framebuffer_object framework to |
| enable multisample rendering. |
| |
| The new operation RenderbufferStorageMultisampleEXT() 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_EXT 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_EXT 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 BlitFramebufferEXT (provided by the EXT_framebuffer_blit |
| extension) 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 implementes the |
| multisample resolution "one sample at a time" exposes |
| EXT_framebuffer_multisample, it could perform the implicit resolve |
| to a driver-managed hidden surface, then read from that surface when |
| the application calls BlitFramebufferEXT. |
| |
| Another motivation for granting the application explicit control |
| over the multisample resolve operation has to do with the |
| flexibility afforded by EXT_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 EXT_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. |
| |
| By using the BlitFramebufferEXT from EXT_framebuffer_blit 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. |
| |
| Issues |
| |
| Breaking from past convention, the issues section has been moved to |
| the end of the document. It can be found after Examples, before |
| Revision History. |
| |
| New Procedures and Functions |
| |
| void RenderbufferStorageMultisampleEXT( |
| enum target, sizei samples, |
| enum internalformat, |
| sizei width, sizei height); |
| |
| New Types |
| |
| None. |
| |
| New Tokens |
| |
| Accepted by the <pname> parameter of GetRenderbufferParameterivEXT: |
| |
| RENDERBUFFER_SAMPLES_EXT 0x8CAB |
| |
| Returned by CheckFramebufferStatusEXT: |
| |
| FRAMEBUFFER_INCOMPLETE_MULTISAMPLE_EXT 0x8D56 |
| |
| Accepted by the <pname> parameter of GetBooleanv, GetIntegerv, |
| GetFloatv, and GetDoublev: |
| |
| MAX_SAMPLES_EXT 0x8D57 |
| |
| Additions to Chapter 2 of the 1.5 Specification (OpenGL Operation) |
| |
| Additions to Chapter 3 of the OpenGL 1.5 Specification (Rasterization) |
| |
| Additions to Chapter 4 of the OpenGL 1.5 Specification (Per-Fragment |
| Operations and the Framebuffer) |
| |
| Add to 4.3.2 (Reading Pixels), right before the subsection titled |
| "Obtaining Pixels form the Framebuffer": |
| |
| "ReadPixels generates INVALID_OPERATION if READ_FRAMEBUFFER_BINDING |
| (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." |
| |
| Modify the following text to section 4.3.3, page 194, that was added to |
| the definition of CopyPixels by EXT_framebuffer_blit: |
| |
| "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*. |
| INVALID_FRAMEBUFFER_OPERATION_EXT will be generated if an attempt is |
| made to execute one of these operations, or CopyPixels, while the |
| object bound to READ_FRAMEBUFFER_BINDING_EXT (section 4.4) is not |
| "framebuffer complete" (as defined in section 4.4.4.2). |
| INVALID_OPERATION will be generated if the object bound to |
| READ_FRAMEBUFFER_BINDING_EXT is "framebuffer complete" and the value |
| of SAMPLE_BUFFERS is greater than zero. |
| |
| Furthermore, an attempt to execute CopyPixels will generate |
| INVALID_FRAMEBUFFER_OPERATION_EXT while the object bound to |
| DRAW_FRAMEBUFFER_BINDING_EXT (section 4.4) is not "framebuffer |
| complete". |
| |
| In 4.3.3 (Copying Pixels), add to the section describing BlitFramebuffer |
| that was added by EXT_framebuffer_blit. |
| |
| "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. |
| |
| Furthermore, 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." |
| |
| Modification to 4.4.2.1 (Renderbuffer Objects) |
| |
| Add, just above the definition of RenderbufferStorageEXT: |
| |
| "The command |
| |
| void RenderbufferStorageMultisampleEXT( |
| 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_EXT. <internalformat> must be RGB, RGBA, |
| DEPTH_COMPONENT, STENCIL_INDEX, 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, or STENCIL_INDEX. <width> and <height> are |
| the dimensions in pixels of the renderbuffer. If either <width> or |
| <height> is greater than MAX_RENDERBUFFER_SIZE_EXT, or if <samples> |
| is greater than MAX_SAMPLES_EXT, 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, RenderbufferStorageMultisampleEXT deletes any existing |
| data store for the renderbuffer image and the contents of the data |
| store after calling RenderbufferStorageMultisampleEXT are undefined. |
| RENDERBUFFER_WIDTH_EXT is set to <width>, RENDERBUFFER_HEIGHT_EXT is |
| set to <height>, and RENDERBUFFER_INTERNAL_FORMAT_EXT is set to |
| <internalformat>. |
| |
| If <samples> is zero, then RENDERBUFFER_SAMPLES_EXT 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_EXT 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_EXT STENCIL_INDEX 1 |
| STENCIL_INDEX4_EXT STENCIL_INDEX 4 |
| STENCIL_INDEX8_EXT STENCIL_INDEX 8 |
| STENCIL_INDEX16_EXT 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." |
| |
| Modify the definiton of RenderbufferStorageEXT as follows: |
| |
| "The command |
| |
| void RenderbufferStorageEXT(enum target, enum internalformat, |
| sizei width, sizei height); |
| |
| is equivalent to calling RenderbufferStorageMultisampleEXT with |
| <samples> equal to zero." |
| |
| Modification to 4.4.4.2 (Framebuffer Completeness) |
| |
| Add an entry to the bullet list: |
| |
| * The value of RENDERBUFFER_SAMPLES_EXT is the same for all attached |
| images. |
| { FRAMEBUFFER_INCOMPLETE_MULTISAMPLE_EXT } |
| |
| Also add a paragraph to the end of the section: |
| |
| "The values of SAMPLE_BUFFERS and SAMPLES are derived from the |
| attachments of the currently bound framebuffer object. If the |
| current DRAW_FRAMEBUFFER_BINDING_EXT is not "framebuffer complete", |
| then both SAMPLE_BUFFERS and SAMPLES are undefined. Otherwise, |
| SAMPLES is equal to the value of RENDERBUFFER_SAMPLES_EXT for the |
| attached images (which all must have the same value for |
| RENDERBUFFER_SAMPLES_EXT). Further, SAMPLE_BUFFERS is one if |
| SAMPLES is non-zero. Otherwise, SAMPLE_BUFFERS is zero. |
| |
| Additions to Chapter 5 of the OpenGL 1.5 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: ..., RenderbufferStorageMultisampleEXT..." |
| |
| Additions to Chapter 6 of the OpenGL 1.5 Specification (State and State |
| Requests) |
| |
| Modification to 6.1.3 (Enumerated Queries): |
| |
| In the list of state query functions, modify the definition of |
| GetRenderbufferParameterivEXT as follows: |
| |
| "void GetRenderbufferParameterivEXT(enum target, enum pname, |
| int* params); |
| |
| <target> must be RENDERBUFFER_EXT. <pname> must be one of the |
| symbolic values in table 8.nnn. |
| |
| If the renderbuffer currently bound to <target> is zero, then |
| INVALID_OPERATION is generated. |
| |
| Upon successful return from GetRenderbufferParameterivEXT, if |
| <pname> is RENDERBUFFER_WIDTH_EXT, RENDERBUFFER_HEIGHT_EXT, |
| RENDERBUFFER_INTERNAL_FORMAT_EXT, or RENDERBUFFER_SAMPLES_EXT, |
| then <params> will contain the width in pixels, height in |
| pixels, internal format, or number of samples, respectively, of |
| the renderbuffer currently bound to <target>. |
| |
| Otherwise, INVALID_ENUM is generated." |
| |
| GLX Protocol |
| |
| RenderbufferStorageMultisampleEXT |
| |
| 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 |
| |
| Dependencies on EXT_framebuffer_object |
| |
| EXT_framebuffer_object is required. |
| |
| Dependencies on EXT_framebuffer_blit |
| |
| EXT_framebuffer_blit is required. Technically, EXT_framebuffer_blit |
| would not be required to support multisampled rendering, except for |
| the fact that it provides the only method of doing a multisample |
| resovle from a multisample renderbuffer. |
| |
| Errors |
| |
| The error INVALID_OPERATION_EXT is generated if ReadPixels, |
| CopyPixels, CopyTex{Sub}Image*, CopyColor{Sub}Table, or |
| CopyConvolutionFilter* is called while READ_FRAMEBUFFER_BINDING_EXT |
| 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 |
| RenderbufferStorageMultisampleEXT 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 BlitFramebufferEXT 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 BlitFramebufferEXT 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 BlitFramebufferEXT is called |
| and the specified source and destination dimensions are not |
| identical. |
| |
| If RenderbufferStorageMultisampleEXT is called with a value of |
| <samples> that is greater than MAX_SAMPLES_EXT, then the error |
| INVALID_VALUE is generated. |
| |
| New State |
| |
| (add to table 8.nnn, "Renderbuffers (state per renderbuffer object)") |
| |
| Get Value Type Get Command Initial Value Description Section Attribute |
| ------------------------------- ------ ------------- ------------- -------------------- ------------ --------- |
| RENDERBUFFER_SAMPLES_EXT Z+ GetRenderbufferParameterivEXT 0 number of samples 4.4.2.1 - |
| |
| |
| To the table added by EXT_framebuffer_object 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_SAMPLES_EXT Z+ GetIntegerv 1 Maximum number of 4.4.2.1 - |
| samples supported |
| for multisampling |
| |
| |
| |
| Usage Examples |
| |
| XXX add examples XXX |
| |
| Issues |
| |
| (1) Should this be a separate extension or should it be included in |
| a revision of EXT_framebuffer_object? |
| |
| RESOLVED, separate extension |
| |
| Resolved by consensus, May 9, 2005 |
| |
| This extension requires EXT_framebuffer_object but the reverse |
| is not true. In addition, the cross framebuffer copy operation |
| that will be used to handle the multisample resolution |
| operation may be generally useful for non-multisampled |
| rendering, but is pretty much required for multisampled |
| rendering to be useful. Since we don't want |
| EXT_framebuffer_object to require that functionality either, we |
| split EXT_framebuffer_multisample into its own extension. |
| EXT_framebuffer_multisample might include the "cross |
| framebuffer copy" operation or might simply require the |
| presence of that third extension. See issue (8). |
| |
| (2) What happens when <samples> is zero or one? |
| |
| RESOLVED, 0 = single sample, 1 = minimum multisample |
| |
| Resolved by consensus, May 9, 2005 |
| |
| Zero means single sample, as if RenderbufferStorageEXT had been |
| called instead of RenderbufferStorageMultisampleEXT. One means |
| minimum number of samples supported by implementation. |
| |
| There was a question if one should mean the same thing as |
| single-sample (one sample), or if it should mean the minimum |
| supported number of samples for multisample rendering. The |
| rules for rasterizing in "multisample" mode are different than |
| "non-multisample" mode. In the end, we decided that some |
| implementations may wish to support a "one-sample" multisample |
| buffer to allow for multipass multisampling where the sample |
| location can be varied either by the implementation or perhaps |
| explicitly by a "multisample location" extension. |
| |
| (3) Is ReadPixels (or CopyPixels or CopyTexImage) permitted when |
| bound to a multisample framebuffer object? |
| |
| RESOLVED, no |
| |
| Resolved by consensus, prior to May 9, 2005 |
| |
| No, those operations will produce INVALID_OPERATION. To read |
| the contents of a multisample framebuffer, it must first be |
| "downsampled" into a non-multisample destination, then read |
| from there. For downsample, see EXT_framebuffer_blit. |
| |
| The concern is fallback due to out of memory conditions. Even |
| if no memory is available to allocate a temporary buffer at the |
| time ReadPixels is called, an implementation should be able to |
| make this work by pre-allocating a small tile and doing the |
| downsample in tiles, or by falling back to software to copy a |
| pixel at a time. |
| |
| (4) Does the resolution from <samples> to RENDERBUFFER_SAMPLES_EXT |
| depend on any other parameters to |
| RenderbufferStorageMultisampleEXT, or must a given value of |
| <samples> always resolve to the same number of actual samples? |
| |
| RESOLVED, no, further, user must get at least what they asked |
| for, or Storage call fails: |
| |
| Resolved by consensus, May 23, 2005 |
| |
| |
| Given the routine, |
| |
| void RenderbufferStorageMultisampleEXT( |
| enum target, uint samples, |
| enum internalformat, |
| uint width, uint height); |
| |
| If an implementation supports several sample counts (say, 2x, |
| 4x, 8x multisample), and the user requests a sample count of |
| <samples>, the implementation must do one of the following: |
| |
| - succeed in giving the user exactly <samples>, or |
| |
| - succeed in giving the user a number of samples greater |
| than <samples> but no more than the next highest number of |
| samples supported by the implementation, or |
| |
| - fail the request to RenderbufferStorageMultisampleEXT with |
| an OUT_OF_MEMORY error |
| |
| (5) Is an implementation allowed to create single-sample storage |
| when RenderbufferStorageMultisampleEXT is called with <samples> |
| larger than one? |
| |
| RESOLVED, no |
| |
| Resolved by consensus, May 23, 2005 |
| |
| No, by resolution of issue (4) above, the user must get at |
| least what they asked for or higher, which precludes getting |
| a single sampled format if they asked for a multisampled |
| format. |
| |
| (6) Should OUT_OF_MEMORY be generated when |
| RenderbufferStorageMultisampleEXT cannot create storage of the |
| requested size? |
| |
| RESOLVED, yes |
| |
| Resolved by consensus, May 23, 2005 |
| |
| Yes. Success or failure is determined by <width>, <height>, |
| <internalformat>, and <samples>, and the implementation can |
| always return OUT_OF_MEMORY. Note that while an implementation |
| may give a different internal format with either higher or |
| lower resolution per component than the internal requested, by |
| issue of resolution (4), it must give at least the number of |
| samples requested or it must fail the |
| RenderbufferStorageMultisampleEXT call. |
| |
| Update from June 2006 ARB meeting: |
| |
| The appropriate error for the case where the number of |
| samples is larger than the maximum supported by the |
| implementation is INVALID_VALUE. To allow an application |
| to know the maximum legal value, we add a GetInteger query |
| MAX_SAMPLES. |
| |
| (7) Is there a query for the maximum size of <samples>? |
| |
| RESOLVED, Yes |
| |
| There was some discussion about whether it was useful to return |
| a maximum sample count supported by the implementation as a |
| convenenience to the developer so that the developer doesn't |
| need to try increasingly smaller counts until it finds one that |
| succeeds. Originally this query was ommitted, but later it was |
| added (MAX_SAMPLES_EXT). |
| |
| (8) Does this extension require our new framebuffer-to-framebuffer |
| copy extension, EXT_framebuffer_blit, or is it merely affected |
| by the presence of that extension. |
| |
| RESOLVED, EXT_framebuffer_blit is required. |
| |
| EXT_framebuffer_multisample by itself enable the user to |
| perform multisampled rendering. However, you can't copy or |
| read from a multisampled renderbuffer using {Read|Copy}Pixels |
| or CopyTex{Sub}Image - as per issue (3). Consequently, there |
| is no way to actually use the results of multisampled rendering |
| without EXT_framebuffer_blit. That makes the |
| EXT_framebuffer_multisample extension arguably kind of useless |
| without the EXT_framebuffer_blit. |
| |
| However, the reverse is not true. The EXT_framebuffer_blit is |
| useful on its own, which is why it is a separate extension from |
| this one. |
| |
| So we decided to state that EXT_framebuffer_multisample |
| requires EXT_framebuffer_blit instead of merely stating that |
| that extension affects this one. |
| |
| (9) Is DrawPixels allowed when the draw framebuffer is multisample? |
| |
| RESOLVED, yes |
| |
| This is no different than DrawPixels to a multisample window |
| (framebuffer zero). Note that ReadPixels and CopyPixels are |
| disallowed when the read framebuffer is multisample. |
| |
| Revision History |
| #7, Jan 10, 2007: jjuliano |
| - add missing constraint that a multisample blit requires |
| identical formats for the read and draw framebuffers |
| - correct the resolution of issue 7 (MAX_SAMPLES_EXT) |
| - fix typos |
| |
| #6c, November 6, 2006: jjuliano |
| - changes from June #6 merged back in |
| |
| #6b, October 13, 2006: Jon Leech |
| - added token values for MAX_SAMPLES_EXT and |
| FRAMEBUFFER_INCOMPLETE_MULTISAMPLE_EXT. |
| |
| #6a, September 6, 2006: jsandmel |
| - added language describing MAX_SAMPLES query |
| - clarified that RenderbufferStorageMultisampleEXT can fail |
| with INVALID_VALUE if <samples> is greater than MAX_SAMPLES |
| |
| #6, June 1, 2006: jjuliano |
| - add missing errors to Errors section |
| - clarify the modifications to 4.3.2 and 4.3.3. |
| - add issue 9 to document that multisample DrawPixels is allowed |
| |
| #5, December 22, 2005: Jon Leech |
| - added GLX protocol, assigned enumerant values |
| |
| #4, September 28, 2005: jsandmel, jjuliano |
| - moved the multisample languge from GL_EXT_framebuffer_blit to |
| this spec. |
| - added description of using BlitFramebufferEXT for resolving |
| multisample buffer |
| - added language referring to DRAW_/READ_FRAMEBUFFER_BINDING |
| instead of just FRAMEBUFFER_BINDING. |
| - minor updates to reflect new EXT_framebuffer_blit spec |
| that provides the multisample resolve function |
| - resolve issue (8) |
| - rename framebuffer_object_multisample to |
| framebuffer_multisample |
| |
| #3, May 26, 2005: jsandmel |
| - added recent workgroup resolutions |
| - resolved issues (4), (5), (6), (7) based on decisions from the |
| work group on May 9 and 23, 2005 |
| - added issue (8), does this extension require our new |
| cross-framebuffer copy extension? |
| - removed MAX_RENDERBUFFER_SAMPLES_EXT enum as per work group |
| decision - issue (7) |
| - changed prototype for RenderbufferStorageMultisampleEXT to use |
| sizei for sample count |
| |
| #2, May 16, 2005: jsandmel |
| - revised to account for recent work group meeting decisions |
| - removed erroneous inclusion of GenerateMipmaps as a new |
| function |
| - resolved issue (1), this will be a separate extension |
| - resolved issue (2), zero means non-multisample, one means |
| minimum number of samples |
| |
| #1, May 9, 2005: jjuliano |
| - first revision |