1Name 2 3 EXT_framebuffer_multisample 4 5Name Strings 6 7 GL_EXT_framebuffer_multisample 8 9Contributors 10 11 Pat Brown 12 Michael Gold 13 Evan Hart 14 Jeff Juliano 15 Jon Leech 16 Bill Licea-Kane 17 Barthold Lichtenbelt 18 Kent Lin 19 Ian Romanick 20 John Rosasco 21 Jeremy Sandmel 22 23Contacts 24 25 Jeff Juliano, NVIDIA Corporation (jjuliano 'at' nvidia.com) 26 Jeremy Sandmel, Apple Computer (jsandmel 'at' apple.com) 27 28Status 29 30 Complete 31 Approved by the ARB "superbuffers" Working Group on November 8, 2005 32 33Version 34 35 Last Modified Date: January 10, 2007 36 Revision: #7 37 38Number 39 40 317 41 42Dependencies 43 44 Requires GL_EXT_framebuffer_object. 45 46 Requires GL_EXT_framebuffer_blit. 47 48 Written based on the wording of the OpenGL 1.5 specification. 49 50Overview 51 52 This extension extends the EXT_framebuffer_object framework to 53 enable multisample rendering. 54 55 The new operation RenderbufferStorageMultisampleEXT() allocates 56 storage for a renderbuffer object that can be used as a multisample 57 buffer. A multisample render buffer image differs from a 58 single-sample render buffer image in that a multisample image has a 59 number of SAMPLES that is greater than zero. No method is provided 60 for creating multisample texture images. 61 62 All of the framebuffer-attachable images attached to a framebuffer 63 object must have the same number of SAMPLES or else the framebuffer 64 object is not "framebuffer complete". If a framebuffer object with 65 multisample attachments is "framebuffer complete", then the 66 framebuffer object behaves as if SAMPLE_BUFFERS is one. 67 68 In traditional multisample rendering, where 69 DRAW_FRAMEBUFFER_BINDING_EXT is zero and SAMPLE_BUFFERS is one, the 70 GL spec states that "the color sample values are resolved to a 71 single, displayable color each time a pixel is updated." There are, 72 however, several modern hardware implementations that do not 73 actually resolve for each sample update, but instead postpones the 74 resolve operation to a later time and resolve a batch of sample 75 updates at a time. This is OK as long as the implementation behaves 76 "as if" it had resolved a sample-at-a-time. Unfortunately, however, 77 honoring the "as if" rule can sometimes degrade performance. 78 79 In contrast, when DRAW_FRAMEBUFFER_BINDING_EXT is an 80 application-created framebuffer object, MULTISAMPLE is enabled, and 81 SAMPLE_BUFFERS is one, there is no implicit per-sample-update 82 resolve. Instead, the application explicitly controls when the 83 resolve operation is performed. The resolve operation is affected 84 by calling BlitFramebufferEXT (provided by the EXT_framebuffer_blit 85 extension) where the source is a multisample application-created 86 framebuffer object and the destination is a single-sample 87 framebuffer object (either application-created or window-system 88 provided). 89 90 This design for multisample resolve more closely matches current 91 hardware, but still permits implementations which choose to resolve 92 a single sample at a time. If hardware that implementes the 93 multisample resolution "one sample at a time" exposes 94 EXT_framebuffer_multisample, it could perform the implicit resolve 95 to a driver-managed hidden surface, then read from that surface when 96 the application calls BlitFramebufferEXT. 97 98 Another motivation for granting the application explicit control 99 over the multisample resolve operation has to do with the 100 flexibility afforded by EXT_framebuffer_object. Previously, a 101 drawable (window or pbuffer) had exclusive access to all of its 102 buffers. There was no mechanism for sharing a buffer across 103 multiple drawables. Under EXT_framebuffer_object, however, a 104 mechanism exists for sharing a framebuffer-attachable image across 105 several framebuffer objects, as well as sharing an image between a 106 framebuffer object and a texture. If we had retained the "implicit" 107 resolve from traditional multisampled rendering, and allowed the 108 creation of "multisample" format renderbuffers, then this type of 109 sharing would have lead to two problematic situations: 110 111 * Two contexts, which shared renderbuffers, might perform 112 competing resolve operations into the same single-sample buffer 113 with ambiguous results. 114 115 * It would have introduced the unfortunate ability to use the 116 single-sample buffer as a texture while MULTISAMPLE is ENABLED. 117 118 By using the BlitFramebufferEXT from EXT_framebuffer_blit as an 119 explicit resolve to serialize access to the multisampled contents 120 and eliminate the implicit per-sample resolve operation, we avoid 121 both of these problems. 122 123Issues 124 125 Breaking from past convention, the issues section has been moved to 126 the end of the document. It can be found after Examples, before 127 Revision History. 128 129New Procedures and Functions 130 131 void RenderbufferStorageMultisampleEXT( 132 enum target, sizei samples, 133 enum internalformat, 134 sizei width, sizei height); 135 136New Types 137 138 None. 139 140New Tokens 141 142 Accepted by the <pname> parameter of GetRenderbufferParameterivEXT: 143 144 RENDERBUFFER_SAMPLES_EXT 0x8CAB 145 146 Returned by CheckFramebufferStatusEXT: 147 148 FRAMEBUFFER_INCOMPLETE_MULTISAMPLE_EXT 0x8D56 149 150 Accepted by the <pname> parameter of GetBooleanv, GetIntegerv, 151 GetFloatv, and GetDoublev: 152 153 MAX_SAMPLES_EXT 0x8D57 154 155Additions to Chapter 2 of the 1.5 Specification (OpenGL Operation) 156 157Additions to Chapter 3 of the OpenGL 1.5 Specification (Rasterization) 158 159Additions to Chapter 4 of the OpenGL 1.5 Specification (Per-Fragment 160Operations and the Framebuffer) 161 162Add to 4.3.2 (Reading Pixels), right before the subsection titled 163"Obtaining Pixels form the Framebuffer": 164 165 "ReadPixels generates INVALID_OPERATION if READ_FRAMEBUFFER_BINDING 166 (section 4.4) is non-zero, the read framebuffer is framebuffer 167 complete, and the value of SAMPLE_BUFFERS for the read framebuffer 168 is greater than zero." 169 170Modify the following text to section 4.3.3, page 194, that was added to 171the definition of CopyPixels by EXT_framebuffer_blit: 172 173 "Finally, the behavior of several GL operations is specified "as if 174 the arguments were passed to CopyPixels." These operations include: 175 CopyTex{Sub}Image*, CopyColor{Sub}Table, and CopyConvolutionFilter*. 176 INVALID_FRAMEBUFFER_OPERATION_EXT will be generated if an attempt is 177 made to execute one of these operations, or CopyPixels, while the 178 object bound to READ_FRAMEBUFFER_BINDING_EXT (section 4.4) is not 179 "framebuffer complete" (as defined in section 4.4.4.2). 180 INVALID_OPERATION will be generated if the object bound to 181 READ_FRAMEBUFFER_BINDING_EXT is "framebuffer complete" and the value 182 of SAMPLE_BUFFERS is greater than zero. 183 184 Furthermore, an attempt to execute CopyPixels will generate 185 INVALID_FRAMEBUFFER_OPERATION_EXT while the object bound to 186 DRAW_FRAMEBUFFER_BINDING_EXT (section 4.4) is not "framebuffer 187 complete". 188 189In 4.3.3 (Copying Pixels), add to the section describing BlitFramebuffer 190that was added by EXT_framebuffer_blit. 191 192 "If SAMPLE_BUFFERS for the read framebuffer is greater than zero and 193 SAMPLE_BUFFERS for the draw framebuffer is zero, the samples 194 corresponding to each pixel location in the source are converted to 195 a single sample before being written to the destination. 196 197 If SAMPLE_BUFFERS for the read framebuffer is zero and 198 SAMPLE_BUFFERS for the draw framebuffer is greater than zero, the 199 value of the source sample is replicated in each of the destination 200 samples. 201 202 If SAMPLE_BUFFERS for both the read and draw framebuffers are 203 greater than zero, and the values of SAMPLES for the read and draw 204 framebuffers are identical, the samples are copied without 205 modification from the read framebuffer to the draw framebuffer. 206 Otherwise, no copy is performed and an INVALID_OPERATION error is 207 generated. 208 209 Furthermore, if SAMPLE_BUFFERS for either the read framebuffer or 210 draw framebuffer is greater than zero, no copy is performed and an 211 INVALID_OPERATION error is generated if the dimensions of the source 212 and destination rectangles provided to BlitFramebuffer are not 213 identical, or if the formats of the read and draw framebuffers are 214 not identical." 215 216Modification to 4.4.2.1 (Renderbuffer Objects) 217 218 Add, just above the definition of RenderbufferStorageEXT: 219 220 "The command 221 222 void RenderbufferStorageMultisampleEXT( 223 enum target, sizei samples, 224 enum internalformat, 225 sizei width, sizei height); 226 227 establishes the data storage, format, dimensions, and number of 228 samples of a renderbuffer object's image. <target> must be 229 RENDERBUFFER_EXT. <internalformat> must be RGB, RGBA, 230 DEPTH_COMPONENT, STENCIL_INDEX, or one of the internal formats from 231 table 3.16 or table 2.nnn that has a base internal format of RGB, 232 RGBA, DEPTH_COMPONENT, or STENCIL_INDEX. <width> and <height> are 233 the dimensions in pixels of the renderbuffer. If either <width> or 234 <height> is greater than MAX_RENDERBUFFER_SIZE_EXT, or if <samples> 235 is greater than MAX_SAMPLES_EXT, then the error INVALID_VALUE is 236 generated. If the GL is unable to create a data store of the 237 requested size, the error OUT_OF_MEMORY is generated. 238 239 Upon success, RenderbufferStorageMultisampleEXT deletes any existing 240 data store for the renderbuffer image and the contents of the data 241 store after calling RenderbufferStorageMultisampleEXT are undefined. 242 RENDERBUFFER_WIDTH_EXT is set to <width>, RENDERBUFFER_HEIGHT_EXT is 243 set to <height>, and RENDERBUFFER_INTERNAL_FORMAT_EXT is set to 244 <internalformat>. 245 246 If <samples> is zero, then RENDERBUFFER_SAMPLES_EXT is set to zero. 247 Otherwise <samples> represents a request for a desired minimum 248 number of samples. Since different implementations may support 249 different sample counts for multisampled rendering, the actual 250 number of samples allocated for the renderbuffer image is 251 implementation dependent. However, the resulting value for 252 RENDERBUFFER_SAMPLES_EXT is guaranteed to be greater than or equal 253 to <samples> and no more than the next larger sample count supported 254 by the implementation. 255 256 Sized Base S 257 Internal Format Internal format Bits 258 --------------- --------------- ---- 259 STENCIL_INDEX1_EXT STENCIL_INDEX 1 260 STENCIL_INDEX4_EXT STENCIL_INDEX 4 261 STENCIL_INDEX8_EXT STENCIL_INDEX 8 262 STENCIL_INDEX16_EXT STENCIL_INDEX 16 263 ------------------------------------------------------------------ 264 Table 2.nnn Desired component resolution for each sized internal 265 format that can be used only with renderbuffers. 266 267 A GL implementation may vary its allocation of internal component 268 resolution based on any RenderbufferStorage parameter (except 269 target), but the allocation and chosen internal format must not be a 270 function of any other state and cannot be changed once they are 271 established." 272 273 Modify the definiton of RenderbufferStorageEXT as follows: 274 275 "The command 276 277 void RenderbufferStorageEXT(enum target, enum internalformat, 278 sizei width, sizei height); 279 280 is equivalent to calling RenderbufferStorageMultisampleEXT with 281 <samples> equal to zero." 282 283Modification to 4.4.4.2 (Framebuffer Completeness) 284 285 Add an entry to the bullet list: 286 287 * The value of RENDERBUFFER_SAMPLES_EXT is the same for all attached 288 images. 289 { FRAMEBUFFER_INCOMPLETE_MULTISAMPLE_EXT } 290 291 Also add a paragraph to the end of the section: 292 293 "The values of SAMPLE_BUFFERS and SAMPLES are derived from the 294 attachments of the currently bound framebuffer object. If the 295 current DRAW_FRAMEBUFFER_BINDING_EXT is not "framebuffer complete", 296 then both SAMPLE_BUFFERS and SAMPLES are undefined. Otherwise, 297 SAMPLES is equal to the value of RENDERBUFFER_SAMPLES_EXT for the 298 attached images (which all must have the same value for 299 RENDERBUFFER_SAMPLES_EXT). Further, SAMPLE_BUFFERS is one if 300 SAMPLES is non-zero. Otherwise, SAMPLE_BUFFERS is zero. 301 302Additions to Chapter 5 of the OpenGL 1.5 Specification (Special Functions) 303 304 Added to section 5.4, as part of the discussion of which commands 305 are not compiled into display lists: 306 307 "Certain commands, when called while compiling a display list, are 308 not compiled into the display list but are executed immediately. 309 These are: ..., RenderbufferStorageMultisampleEXT..." 310 311Additions to Chapter 6 of the OpenGL 1.5 Specification (State and State 312Requests) 313 314Modification to 6.1.3 (Enumerated Queries): 315 316 In the list of state query functions, modify the definition of 317 GetRenderbufferParameterivEXT as follows: 318 319 "void GetRenderbufferParameterivEXT(enum target, enum pname, 320 int* params); 321 322 <target> must be RENDERBUFFER_EXT. <pname> must be one of the 323 symbolic values in table 8.nnn. 324 325 If the renderbuffer currently bound to <target> is zero, then 326 INVALID_OPERATION is generated. 327 328 Upon successful return from GetRenderbufferParameterivEXT, if 329 <pname> is RENDERBUFFER_WIDTH_EXT, RENDERBUFFER_HEIGHT_EXT, 330 RENDERBUFFER_INTERNAL_FORMAT_EXT, or RENDERBUFFER_SAMPLES_EXT, 331 then <params> will contain the width in pixels, height in 332 pixels, internal format, or number of samples, respectively, of 333 the renderbuffer currently bound to <target>. 334 335 Otherwise, INVALID_ENUM is generated." 336 337GLX Protocol 338 339 RenderbufferStorageMultisampleEXT 340 341 2 24 rendering command length 342 2 4331 rendering command opcode 343 4 ENUM target 344 4 CARD32 samples 345 4 ENUM internalformat 346 4 CARD32 width 347 4 CARD32 height 348 349Dependencies on EXT_framebuffer_object 350 351 EXT_framebuffer_object is required. 352 353Dependencies on EXT_framebuffer_blit 354 355 EXT_framebuffer_blit is required. Technically, EXT_framebuffer_blit 356 would not be required to support multisampled rendering, except for 357 the fact that it provides the only method of doing a multisample 358 resovle from a multisample renderbuffer. 359 360Errors 361 362 The error INVALID_OPERATION_EXT is generated if ReadPixels, 363 CopyPixels, CopyTex{Sub}Image*, CopyColor{Sub}Table, or 364 CopyConvolutionFilter* is called while READ_FRAMEBUFFER_BINDING_EXT 365 is non-zero, the read framebuffer is framebuffer complete, and the 366 value of SAMPLE_BUFFERS for the read framebuffer is greater than 367 zero. 368 369 The error OUT_OF_MEMORY is generated when 370 RenderbufferStorageMultisampleEXT cannot create storage of the 371 specified size. 372 373 If both the draw and read framebuffers are framebuffer complete and 374 both have a value of SAMPLE_BUFFERS that is greater than zero, then 375 the error INVALID_OPERATION is generated if BlitFramebufferEXT is 376 called and the values of SAMPLES for the draw and read framebuffers 377 do not match. 378 379 If both the draw and read framebuffers are framebuffer complete and 380 either has a value of SAMPLE_BUFFERS that is greater than zero, then 381 the error INVALID_OPERATION is generated if BlitFramebufferEXT is 382 called and the formats of the draw and read framebuffers are not 383 identical. 384 385 If either the draw or read framebuffer is framebuffer complete and 386 has a value of SAMPLE_BUFFERS that is greater than zero, then the 387 error INVALID_OPERATION is generated if BlitFramebufferEXT is called 388 and the specified source and destination dimensions are not 389 identical. 390 391 If RenderbufferStorageMultisampleEXT is called with a value of 392 <samples> that is greater than MAX_SAMPLES_EXT, then the error 393 INVALID_VALUE is generated. 394 395New State 396 397 (add to table 8.nnn, "Renderbuffers (state per renderbuffer object)") 398 399 Get Value Type Get Command Initial Value Description Section Attribute 400 ------------------------------- ------ ------------- ------------- -------------------- ------------ --------- 401 RENDERBUFFER_SAMPLES_EXT Z+ GetRenderbufferParameterivEXT 0 number of samples 4.4.2.1 - 402 403 404To the table added by EXT_framebuffer_object called "Framebuffer 405Dependent Values", table 9.nnn, add the following new framebuffer 406dependent state. 407 408 Get Value Type Get Command Minimum Value Description Section Attribute 409 --------- ---- ----------- ------------- ------------------- ------- --------- 410 MAX_SAMPLES_EXT Z+ GetIntegerv 1 Maximum number of 4.4.2.1 - 411 samples supported 412 for multisampling 413 414 415 416Usage Examples 417 418 XXX add examples XXX 419 420Issues 421 422 (1) Should this be a separate extension or should it be included in 423 a revision of EXT_framebuffer_object? 424 425 RESOLVED, separate extension 426 427 Resolved by consensus, May 9, 2005 428 429 This extension requires EXT_framebuffer_object but the reverse 430 is not true. In addition, the cross framebuffer copy operation 431 that will be used to handle the multisample resolution 432 operation may be generally useful for non-multisampled 433 rendering, but is pretty much required for multisampled 434 rendering to be useful. Since we don't want 435 EXT_framebuffer_object to require that functionality either, we 436 split EXT_framebuffer_multisample into its own extension. 437 EXT_framebuffer_multisample might include the "cross 438 framebuffer copy" operation or might simply require the 439 presence of that third extension. See issue (8). 440 441 (2) What happens when <samples> is zero or one? 442 443 RESOLVED, 0 = single sample, 1 = minimum multisample 444 445 Resolved by consensus, May 9, 2005 446 447 Zero means single sample, as if RenderbufferStorageEXT had been 448 called instead of RenderbufferStorageMultisampleEXT. One means 449 minimum number of samples supported by implementation. 450 451 There was a question if one should mean the same thing as 452 single-sample (one sample), or if it should mean the minimum 453 supported number of samples for multisample rendering. The 454 rules for rasterizing in "multisample" mode are different than 455 "non-multisample" mode. In the end, we decided that some 456 implementations may wish to support a "one-sample" multisample 457 buffer to allow for multipass multisampling where the sample 458 location can be varied either by the implementation or perhaps 459 explicitly by a "multisample location" extension. 460 461 (3) Is ReadPixels (or CopyPixels or CopyTexImage) permitted when 462 bound to a multisample framebuffer object? 463 464 RESOLVED, no 465 466 Resolved by consensus, prior to May 9, 2005 467 468 No, those operations will produce INVALID_OPERATION. To read 469 the contents of a multisample framebuffer, it must first be 470 "downsampled" into a non-multisample destination, then read 471 from there. For downsample, see EXT_framebuffer_blit. 472 473 The concern is fallback due to out of memory conditions. Even 474 if no memory is available to allocate a temporary buffer at the 475 time ReadPixels is called, an implementation should be able to 476 make this work by pre-allocating a small tile and doing the 477 downsample in tiles, or by falling back to software to copy a 478 pixel at a time. 479 480 (4) Does the resolution from <samples> to RENDERBUFFER_SAMPLES_EXT 481 depend on any other parameters to 482 RenderbufferStorageMultisampleEXT, or must a given value of 483 <samples> always resolve to the same number of actual samples? 484 485 RESOLVED, no, further, user must get at least what they asked 486 for, or Storage call fails: 487 488 Resolved by consensus, May 23, 2005 489 490 491 Given the routine, 492 493 void RenderbufferStorageMultisampleEXT( 494 enum target, uint samples, 495 enum internalformat, 496 uint width, uint height); 497 498 If an implementation supports several sample counts (say, 2x, 499 4x, 8x multisample), and the user requests a sample count of 500 <samples>, the implementation must do one of the following: 501 502 - succeed in giving the user exactly <samples>, or 503 504 - succeed in giving the user a number of samples greater 505 than <samples> but no more than the next highest number of 506 samples supported by the implementation, or 507 508 - fail the request to RenderbufferStorageMultisampleEXT with 509 an OUT_OF_MEMORY error 510 511 (5) Is an implementation allowed to create single-sample storage 512 when RenderbufferStorageMultisampleEXT is called with <samples> 513 larger than one? 514 515 RESOLVED, no 516 517 Resolved by consensus, May 23, 2005 518 519 No, by resolution of issue (4) above, the user must get at 520 least what they asked for or higher, which precludes getting 521 a single sampled format if they asked for a multisampled 522 format. 523 524 (6) Should OUT_OF_MEMORY be generated when 525 RenderbufferStorageMultisampleEXT cannot create storage of the 526 requested size? 527 528 RESOLVED, yes 529 530 Resolved by consensus, May 23, 2005 531 532 Yes. Success or failure is determined by <width>, <height>, 533 <internalformat>, and <samples>, and the implementation can 534 always return OUT_OF_MEMORY. Note that while an implementation 535 may give a different internal format with either higher or 536 lower resolution per component than the internal requested, by 537 issue of resolution (4), it must give at least the number of 538 samples requested or it must fail the 539 RenderbufferStorageMultisampleEXT call. 540 541 Update from June 2006 ARB meeting: 542 543 The appropriate error for the case where the number of 544 samples is larger than the maximum supported by the 545 implementation is INVALID_VALUE. To allow an application 546 to know the maximum legal value, we add a GetInteger query 547 MAX_SAMPLES. 548 549 (7) Is there a query for the maximum size of <samples>? 550 551 RESOLVED, Yes 552 553 There was some discussion about whether it was useful to return 554 a maximum sample count supported by the implementation as a 555 convenenience to the developer so that the developer doesn't 556 need to try increasingly smaller counts until it finds one that 557 succeeds. Originally this query was ommitted, but later it was 558 added (MAX_SAMPLES_EXT). 559 560 (8) Does this extension require our new framebuffer-to-framebuffer 561 copy extension, EXT_framebuffer_blit, or is it merely affected 562 by the presence of that extension. 563 564 RESOLVED, EXT_framebuffer_blit is required. 565 566 EXT_framebuffer_multisample by itself enable the user to 567 perform multisampled rendering. However, you can't copy or 568 read from a multisampled renderbuffer using {Read|Copy}Pixels 569 or CopyTex{Sub}Image - as per issue (3). Consequently, there 570 is no way to actually use the results of multisampled rendering 571 without EXT_framebuffer_blit. That makes the 572 EXT_framebuffer_multisample extension arguably kind of useless 573 without the EXT_framebuffer_blit. 574 575 However, the reverse is not true. The EXT_framebuffer_blit is 576 useful on its own, which is why it is a separate extension from 577 this one. 578 579 So we decided to state that EXT_framebuffer_multisample 580 requires EXT_framebuffer_blit instead of merely stating that 581 that extension affects this one. 582 583 (9) Is DrawPixels allowed when the draw framebuffer is multisample? 584 585 RESOLVED, yes 586 587 This is no different than DrawPixels to a multisample window 588 (framebuffer zero). Note that ReadPixels and CopyPixels are 589 disallowed when the read framebuffer is multisample. 590 591Revision History 592 #7, Jan 10, 2007: jjuliano 593 - add missing constraint that a multisample blit requires 594 identical formats for the read and draw framebuffers 595 - correct the resolution of issue 7 (MAX_SAMPLES_EXT) 596 - fix typos 597 598 #6c, November 6, 2006: jjuliano 599 - changes from June #6 merged back in 600 601 #6b, October 13, 2006: Jon Leech 602 - added token values for MAX_SAMPLES_EXT and 603 FRAMEBUFFER_INCOMPLETE_MULTISAMPLE_EXT. 604 605 #6a, September 6, 2006: jsandmel 606 - added language describing MAX_SAMPLES query 607 - clarified that RenderbufferStorageMultisampleEXT can fail 608 with INVALID_VALUE if <samples> is greater than MAX_SAMPLES 609 610 #6, June 1, 2006: jjuliano 611 - add missing errors to Errors section 612 - clarify the modifications to 4.3.2 and 4.3.3. 613 - add issue 9 to document that multisample DrawPixels is allowed 614 615 #5, December 22, 2005: Jon Leech 616 - added GLX protocol, assigned enumerant values 617 618 #4, September 28, 2005: jsandmel, jjuliano 619 - moved the multisample languge from GL_EXT_framebuffer_blit to 620 this spec. 621 - added description of using BlitFramebufferEXT for resolving 622 multisample buffer 623 - added language referring to DRAW_/READ_FRAMEBUFFER_BINDING 624 instead of just FRAMEBUFFER_BINDING. 625 - minor updates to reflect new EXT_framebuffer_blit spec 626 that provides the multisample resolve function 627 - resolve issue (8) 628 - rename framebuffer_object_multisample to 629 framebuffer_multisample 630 631 #3, May 26, 2005: jsandmel 632 - added recent workgroup resolutions 633 - resolved issues (4), (5), (6), (7) based on decisions from the 634 work group on May 9 and 23, 2005 635 - added issue (8), does this extension require our new 636 cross-framebuffer copy extension? 637 - removed MAX_RENDERBUFFER_SAMPLES_EXT enum as per work group 638 decision - issue (7) 639 - changed prototype for RenderbufferStorageMultisampleEXT to use 640 sizei for sample count 641 642 #2, May 16, 2005: jsandmel 643 - revised to account for recent work group meeting decisions 644 - removed erroneous inclusion of GenerateMipmaps as a new 645 function 646 - resolved issue (1), this will be a separate extension 647 - resolved issue (2), zero means non-multisample, one means 648 minimum number of samples 649 650 #1, May 9, 2005: jjuliano 651 - first revision 652