michael@0: Name michael@0: michael@0: EXT_draw_buffers michael@0: michael@0: Name Strings michael@0: michael@0: GL_EXT_draw_buffers michael@0: michael@0: Contributors michael@0: michael@0: Contributors to GL_NV_draw_buffers michael@0: Contributors to GL_NV_fbo_color_attachments michael@0: Contributors to the OpenGL ES 2.0 specification michael@0: Contributors to the OpenGLSL ES 1.0.17 specification michael@0: Contributors to the OpenGL ES 3.0 specification michael@0: Nicolas Capens, TransGaming Inc. michael@0: Daniel Koch, TransGaming Inc. michael@0: Alastair Patrick, Google Inc. michael@0: Kenneth Russell, Google Inc. michael@0: Greg Roth, NVIDIA Corporation michael@0: Ben Bowman, Imagination Technologies michael@0: Members of the WebGL and OpenGL ES working groups michael@0: michael@0: Contact michael@0: michael@0: Daniel Koch (daniel 'at' transgaming.com) michael@0: michael@0: Status michael@0: michael@0: Draft Complete michael@0: michael@0: Version michael@0: michael@0: Last Modified Date: January 30, 2013 michael@0: Revision: #7 michael@0: michael@0: Number michael@0: michael@0: TBD michael@0: michael@0: Dependencies michael@0: michael@0: OpenGL ES 2.0 is required. michael@0: michael@0: The extension is written against the OpenGL ES 2.0 specification. michael@0: michael@0: ANGLE_framebuffer_blit affects the definition of this extension. michael@0: APPLE_framebuffer_multisample affects the definitin of this extension. michael@0: michael@0: Overview michael@0: michael@0: This extension increases the number of available framebuffer object michael@0: color attachment points, extends OpenGL ES 2.0 to allow multiple output michael@0: colors, and provides a mechanism for directing those outputs to michael@0: multiple color buffers. michael@0: michael@0: This extension is similar to the combination of the GL_NV_draw_buffers michael@0: and GL_NV_fbo_color_attachments extensions, but imposes certain michael@0: restrictions informed by the OpenGL ES 3.0 API. michael@0: michael@0: New Procedures and Functions michael@0: michael@0: void DrawBuffersEXT(sizei n, const enum *bufs); michael@0: michael@0: New Tokens michael@0: michael@0: Accepted by the parameter of GetIntegerv: michael@0: michael@0: MAX_COLOR_ATTACHMENTS_EXT 0x8CDF michael@0: michael@0: Accepted by the parameters of GetIntegerv and GetFloatv: michael@0: michael@0: MAX_DRAW_BUFFERS_EXT 0x8824 michael@0: DRAW_BUFFER0_EXT 0x8825 michael@0: DRAW_BUFFER1_EXT 0x8826 michael@0: DRAW_BUFFER2_EXT 0x8827 michael@0: DRAW_BUFFER3_EXT 0x8828 michael@0: DRAW_BUFFER4_EXT 0x8829 michael@0: DRAW_BUFFER5_EXT 0x882A michael@0: DRAW_BUFFER6_EXT 0x882B michael@0: DRAW_BUFFER7_EXT 0x882C michael@0: DRAW_BUFFER8_EXT 0x882D michael@0: DRAW_BUFFER9_EXT 0x882E michael@0: DRAW_BUFFER10_EXT 0x882F michael@0: DRAW_BUFFER11_EXT 0x8830 michael@0: DRAW_BUFFER12_EXT 0x8831 michael@0: DRAW_BUFFER13_EXT 0x8832 michael@0: DRAW_BUFFER14_EXT 0x8833 michael@0: DRAW_BUFFER15_EXT 0x8834 michael@0: michael@0: Accepted by the parameter of FramebufferRenderbuffer, michael@0: FramebufferTexture2D and GetFramebufferAttachmentParameteriv, and by michael@0: the parameter of DrawBuffersEXT: michael@0: michael@0: COLOR_ATTACHMENT0_EXT 0x8CE0 michael@0: COLOR_ATTACHMENT1_EXT 0x8CE1 michael@0: COLOR_ATTACHMENT2_EXT 0x8CE2 michael@0: COLOR_ATTACHMENT3_EXT 0x8CE3 michael@0: COLOR_ATTACHMENT4_EXT 0x8CE4 michael@0: COLOR_ATTACHMENT5_EXT 0x8CE5 michael@0: COLOR_ATTACHMENT6_EXT 0x8CE6 michael@0: COLOR_ATTACHMENT7_EXT 0x8CE7 michael@0: COLOR_ATTACHMENT8_EXT 0x8CE8 michael@0: COLOR_ATTACHMENT9_EXT 0x8CE9 michael@0: COLOR_ATTACHMENT10_EXT 0x8CEA michael@0: COLOR_ATTACHMENT11_EXT 0x8CEB michael@0: COLOR_ATTACHMENT12_EXT 0x8CEC michael@0: COLOR_ATTACHMENT13_EXT 0x8CED michael@0: COLOR_ATTACHMENT14_EXT 0x8CEE michael@0: COLOR_ATTACHMENT15_EXT 0x8CEF michael@0: michael@0: The COLOR_ATTACHMENT0_EXT constant is equal to the michael@0: COLOR_ATTACHMENT0 constant. michael@0: michael@0: Each COLOR_ATTACHMENT_EXT adheres to COLOR_ATTACHMENT_EXT michael@0: = COLOR_ATTACHMENT0_EXT + . michael@0: michael@0: Changes to Chapter 3 of the OpenGL ES 2.0 Specification (Rasterization) michael@0: michael@0: Section 3.2, (Multisampling). Replace the second paragraph: michael@0: michael@0: An additional buffer, called the multisample buffer, is added to the michael@0: window system-provided framebuffer. Pixel sample values, including michael@0: color, depth, and stencil values, are stored in this buffer. Samples michael@0: contain separate color values for each fragment color. When the michael@0: window system-provided framebuffer includes a multisample buffer, it michael@0: does not include depth or stencil buffers, even if the multisample michael@0: buffer does not store depth or stencil values. Color buffers do michael@0: coexist with the multisample buffer, however. michael@0: michael@0: Section 3.8.2, (Shader Execution) Replace subsection "Shader michael@0: Outputs": michael@0: michael@0: The OpenGL ES Shading Language specification describes the values michael@0: that may be output by a fragment shader. These are gl_FragColor and michael@0: gl_FragData[n]. The final fragment color values or the final michael@0: fragment data values written by a fragment shader are clamped to the michael@0: range [0, 1] and then converted to fixed-point as described in michael@0: section 2.1.2 for framebuffer color components. michael@0: michael@0: Writing to gl_FragColor specifies the fragment color (color number michael@0: zero) that will be used by subsequent stages of the pipeline. michael@0: Writing to gl_FragData[n] specifies the value of fragment color michael@0: number n. Any colors, or color components, associated with a michael@0: fragment that are not written by the fragment shader are undefined. michael@0: A fragment shader may not statically assign values to both michael@0: gl_FragColor and gl_FragData. In this case, a compile or link error michael@0: will result. A shader statically assigns a value to a variable if, michael@0: after preprocessing, it contains a statement that would write to the michael@0: variable, whether or not run-time flow of control will cause that michael@0: statement to be executed. michael@0: michael@0: Changes to Chapter 4 of the OpenGL ES 2.0 Specification (Per-Fragment michael@0: Operations and the Frame Buffer) michael@0: michael@0: Modify the overview of Chapter 4 and replace the sentences michael@0: of the fifth paragraph which read: michael@0: michael@0: "The name of the color buffer of an application-created framebuffer michael@0: object is COLOR_ATTACHMENT0. The names of the depth and stencil buffers michael@0: are DEPTH_ATTACHMENT and STENCIL_ATTACHMENT." michael@0: michael@0: With the following: michael@0: michael@0: "A framebuffer object has an array of color buffer attachment points, michael@0: numbered zero through , a depth buffer attachment point, and a michael@0: stencil buffer attachment point." michael@0: michael@0: Insert Table 4.3 to Section 4.2.1 (and renumber subsequent tables): michael@0: michael@0: Symbolic Constant Meaning michael@0: ----------------- --------------------- michael@0: NONE No buffer michael@0: michael@0: COLOR_ATTACHMENT_EXT (see caption) Output fragment color to image michael@0: attached at color attachment michael@0: point i michael@0: michael@0: Table 4.3: Arguments to DrawBuffersEXT when the context is bound to a michael@0: framebuffer object, and the buffers they indicate. in michael@0: COLOR_ATTACHMENT_EXT may range from zero to the value of michael@0: MAX_COLOR_ATTACHMENTS_EXT minus one. michael@0: michael@0: Replace Section 4.2.1, "Selecting a Buffer for Writing" with the following: michael@0: michael@0: "By default, color values are written into the front buffer for michael@0: single buffered surfaces or into the back buffer for back buffered michael@0: surfaces as determined when making the context current. To control michael@0: the color buffer into which each of the fragment color values is michael@0: written, DrawBuffersEXT is used. michael@0: michael@0: The command michael@0: michael@0: void DrawBuffersEXT(sizei n, const enum *bufs); michael@0: michael@0: defines the draw buffers to which all fragment colors are written. michael@0: specifies the number of buffers in . is a pointer michael@0: to an array of symbolic constants specifying the buffer to which michael@0: each fragment color is written. michael@0: michael@0: Each buffer listed in must be BACK, NONE, or one of the michael@0: values from table 4.3. Further, acceptable values for the constants michael@0: in depend on whether the GL is using the default framebuffer michael@0: (i.e., DRAW_FRAMEBUFFER_BINDING is zero), or a framebuffer object michael@0: (i.e., DRAW_FRAMEBUFFER_BINDING is non-zero). For more information michael@0: about framebuffer objects, see section 4.4. michael@0: michael@0: If the GL is bound to the default framebuffer, then must be 1 michael@0: and the constant must be BACK or NONE. When draw buffer zero is michael@0: BACK, color values are written into the sole buffer for single- michael@0: buffered contexts, or into the back buffer for double-buffered michael@0: contexts. If DrawBuffersEXT is supplied with a constant other than michael@0: BACK and NONE, the error INVALID_OPERATION is generated. michael@0: michael@0: If the GL is bound to a draw framebuffer object, then each of the michael@0: constants must be one of the values listed in table 4.3. michael@0: michael@0: In both cases, the draw buffers being defined correspond in order to michael@0: the respective fragment colors. The draw buffer for fragment michael@0: colors beyond is set to NONE. michael@0: michael@0: The maximum number of draw buffers is implementation-dependent. The michael@0: number of draw buffers supported can be queried by calling michael@0: GetIntegerv with the symbolic constant MAX_DRAW_BUFFERS_EXT. An michael@0: INVALID_VALUE error is generated if is greater than michael@0: MAX_DRAW_BUFFERS_EXT. michael@0: michael@0: If the GL is bound to a draw framebuffer object, the th buffer listed michael@0: in must be COLOR_ATTACHMENT_EXT or NONE. Specifying a michael@0: buffer out of order, BACK, or COLOR_ATTACHMENT_EXT where is michael@0: greater than or equal to the value of MAX_COLOR_ATTACHMENTS_EXT, michael@0: will generate the error INVALID_OPERATION. michael@0: michael@0: If a fragment shader writes to "gl_FragColor", DrawBuffersEXT michael@0: specifies the set of draw buffers into which the color michael@0: written to "gl_FragColor" is written. If a fragment shader writes to michael@0: "gl_FragData", DrawBuffersEXT specifies a set of draw buffers michael@0: into which each of the multiple output colors defined by these michael@0: variables are separately written. If a fragment shader writes to michael@0: neither "gl_FragColor" nor "gl_FragData" the values of the michael@0: fragment colors following shader execution are undefined, and may michael@0: differ for each fragment color. michael@0: michael@0: Indicating a buffer or buffers using DrawBuffersEXT causes michael@0: subsequent pixel color value writes to affect the indicated michael@0: buffers. If the GL is bound to a draw framebuffer object and a draw michael@0: buffer selects an attachment that has no image attached, then that michael@0: fragment color is not written. michael@0: michael@0: Specifying NONE as the draw buffer for a fragment color will inhibit michael@0: that fragment color from being written. michael@0: michael@0: The state required to handle color buffer selection for each michael@0: framebuffer is an integer for each supported fragment color. For the michael@0: default framebuffer, in the initial state the draw buffer for michael@0: fragment color zero is BACK if there is a default framebuffer michael@0: associated with the context, otherwise NONE. For framebuffer michael@0: objects, in the initial state the draw buffer for fragment color michael@0: zero is COLOR_ATTACHMENT0_EXT. michael@0: michael@0: For both the default framebuffer and framebuffer objects, the michael@0: initial state of draw buffers for fragment colors other than zero is michael@0: NONE. michael@0: michael@0: The value of the draw buffer selected for fragment color can be michael@0: queried by calling GetIntegerv with the symbolic constant michael@0: DRAW_BUFFER_EXT." michael@0: michael@0: Modify Section 4.2.3 (Clearing the Buffers) and replace the first michael@0: two paragraphs with the following: michael@0: michael@0: "The GL provides a means for setting portions of every pixel in a michael@0: particular buffer to the same value. The argument to michael@0: michael@0: void Clear(bitfield buf); michael@0: michael@0: is the bitwise OR of a number of values indicating which buffers are michael@0: to be cleared. The values are COLOR_BUFFER_BIT, DEPTH_BUFFER_BIT, and michael@0: STENCIL_BUFFER_BIT, indicating the buffers currently enabled for color michael@0: writing, the depth buffer, and the stencil buffer (see below), michael@0: respectively. The value to which each buffer is cleared depends on michael@0: the setting of the clear value for that buffer. If the mask is not a michael@0: bitwise OR of the specified values, then the error INVALID_VALUE is michael@0: generated. michael@0: michael@0: void ClearColor(clampf r, clampf, g, clampf b, clampf a); michael@0: michael@0: sets the clear value for fixed-point color buffers. Each of the michael@0: specified components is clamped to [0, 1] and converted to fixed-point michael@0: as described in section 2.1.2 for framebuffer color components." michael@0: michael@0: Replace the second paragraph of Section 4.4.1 (Binding and Managing michael@0: Framebuffer Objects) with the following: michael@0: michael@0: "The namespace for framebuffer objects is the unsigned integers, with michael@0: zero reserved by OpenGL ES to refer to the default framebuffer. A michael@0: framebuffer object is created by binding an unused name to the michael@0: target FRAMEBUFFER, DRAW_FRAMEBUFFER, or READ_FRAMEBUFFER. The binding michael@0: is effected by calling michael@0: michael@0: void BindFramebuffer(enum target, uint framebuffer); michael@0: michael@0: with set the desired framebuffer target and set michael@0: to the unused name. The resulting framebuffer object is a new state michael@0: vector. There is a number of color attachment points, plus one each michael@0: for the depth and stencil attachment points. The number of color attachment michael@0: points is equal to the value of MAX_COLOR_ATTACHMENTS_EXT." michael@0: michael@0: Replace the third item in the bulleted list in Section 4.4.1 (Binding michael@0: and Managing Framebuffer Objects) with the following: michael@0: michael@0: " * The only color buffer bitplanes are the ones defined by the michael@0: framebuffer attachments points named COLOR_ATTACHMENT0_EXT through michael@0: COLOR_ATTACHMENT_EXT." michael@0: michael@0: Modify Section 4.4.3 (Renderbuffer Objects) in the michael@0: "Attaching Renderbuffer Images to a Framebuffer" subsection as follows: michael@0: michael@0: Insert the following table: michael@0: michael@0: Name of attachment michael@0: --------------------------------------- michael@0: COLOR_ATTACHMENT_EXT (see caption) michael@0: DEPTH_ATTACHMENT michael@0: STENCIL_ATTACHMENT michael@0: michael@0: Table 4.x: Framebuffer attachment points. in COLOR_ATTACHMENT_EXT michael@0: may range from zero to the value of MAX_COLOR_ATTACHMENTS_EXT minus 1. michael@0: michael@0: Modify the third sentence of the paragraph following the definition of michael@0: FramebufferRenderbuffer to be as follows: michael@0: michael@0: " should be set to one of the attachment points of the michael@0: framebuffer listed in Table 4.x." michael@0: michael@0: Modify Section 4.4.3 (Renderbuffer Objects) in the "Attaching Texture michael@0: Images to a Framebuffer" subsection as follows: michael@0: michael@0: Modify the last sentence of the paragraph following the definition of michael@0: FramebufferTexture2D to be as follows: michael@0: michael@0: " must be one of the attachment points of the framebuffer michael@0: listed in Table 4.x." michael@0: michael@0: Modify Section 4.4.5 (Framebuffer Completeness) and replace the 3rd michael@0: item in the bulleted list in the "Framebuffer Attachment Completeness" michael@0: subsection with the following: michael@0: michael@0: " * If is COLOR_ATTACHMENT_EXT, then must michael@0: have a color-renderable internal format." michael@0: michael@0: Changes to Chapter 6 of the OpenGL ES 2.0 Specification (State and michael@0: State Requests) michael@0: michael@0: In section 6.1.3 (Enumerated Queries) modify the third sentence in michael@0: the definition of GetFramebufferAttachmentParameteriv to be as follows: michael@0: michael@0: " must be one of the attachment points of the framebuffer michael@0: listed in Table 4.x." michael@0: michael@0: Changes to Chapter 3 of the OpenGL ES Shading Language 1.0.17 Specification (Basics) michael@0: michael@0: Add a new section: michael@0: michael@0: 3.4.1 GL_EXT_draw_buffers Extension michael@0: michael@0: To use the GL_EXT_draw_buffers extension in a shader it michael@0: must be enabled using the #extension directive. michael@0: michael@0: The shading language preprocessor #define michael@0: GL_EXT_draw_buffers will be defined to 1, if the michael@0: GL_EXT_draw_buffers extension is supported. michael@0: michael@0: Dependencies on ANGLE_framebuffer_blit and APPLE_framebuffer_multisample: michael@0: michael@0: If neither ANGLE_framebuffer_blit nor APPLE_framebuffer_multisample are michael@0: supported, then all references to "draw framebuffers" should be replaced michael@0: with references to "framebuffers". References to DRAW_FRAMEBUFFER_BINDING michael@0: should be replaced with references to FRAMEBUFFER_BINDING. References to michael@0: DRAW_FRAMEBUFFER and READ_FRAMEBUFFER should be removed. michael@0: michael@0: If ANGLE_framebuffer_blit is supported, DRAW_FRAMEBUFFER_BINDING, DRAW_FRAMEBUFFER michael@0: and READ_FRAMEBUFFER all refer to corresponding _ANGLE suffixed names michael@0: (they have the same token values). michael@0: michael@0: If APPLE_framebuffer_multisample is supported, DRAW_FRAMEBUFFER_BINDING, michael@0: DRAW_FRAMEBUFFER and READ_FRAMEBUFFER all refer to the corresponding _APPLE michael@0: suffixed names (they have the same token values). michael@0: michael@0: Errors michael@0: michael@0: The INVALID_OPERATION error is generated if DrawBuffersEXT is called michael@0: when the default framebuffer is bound and any of the following conditions michael@0: hold: michael@0: - is greater than 1 and less than MAX_DRAW_BUFFERS_EXT, michael@0: - contains a value other than BACK or NONE. michael@0: michael@0: The INVALID_OPERATION error is generated if DrawBuffersEXT is called michael@0: when bound to a draw framebuffer object and any of the following michael@0: conditions hold: michael@0: - the th value in is not COLOR_ATTACHMENT_EXT or NONE. michael@0: michael@0: The INVALID_VALUE error is generated if DrawBuffersEXT is called michael@0: with a value of which is greater than MAX_DRAW_BUFFERS_EXT. michael@0: michael@0: The INVALID_ENUM error is generated by FramebufferRenderbuffer if michael@0: the parameter is not one of the values listed in Table 4.x. michael@0: michael@0: The INVALID_ENUM error is generated by FramebufferTexture2D if michael@0: the parameter is not one of the values listed in Table 4.x. michael@0: michael@0: The INVALID_ENUM error is generated by GetFramebufferAttachmentParameteriv michael@0: if the parameter is not one of the values listed in Table 4.x. michael@0: michael@0: New State michael@0: michael@0: Add Table 6.X Framebuffer (State per framebuffer object): michael@0: michael@0: State Type Get Command Initial Value Description michael@0: ------------------ ---- ------------ ------------- ----------- michael@0: DRAW_BUFFER_EXT Z10* GetIntegerv see 4.2.1 Draw buffer selected michael@0: for fragment color i michael@0: michael@0: Add to Table 6.18 (Implementation Dependent Values) michael@0: michael@0: Get value Type Get Cmnd Minimum Value Description Sec. michael@0: -------------------- ---- ----------- ------------- ----------- ----- michael@0: MAX_DRAW_BUFFERS_EXT Z+ GetIntegerv 1 Maximum number of 4.2.1 michael@0: active draw buffers michael@0: MAX_COLOR_ATTACHMENTS_EXT Z+ GetIntegerv 1 Number of framebuffer 4.4.1 michael@0: color attachment points michael@0: Issues michael@0: michael@0: See ARB_draw_buffers for relevant issues. michael@0: michael@0: 1) What are the differences between this extension and NV_draw_buffers michael@0: + NV_fbo_color_attachments? michael@0: michael@0: RESOLVED. This extension: michael@0: - adds interactions with blit_framebuffer and the separate michael@0: draw/read binding points michael@0: - The draw buffer and color attachment limits are global instead michael@0: of per-fbo (see Issue 2) michael@0: - can be used to with default framebuffer to set NONE/BACK (see Issue 4) michael@0: - retains the ordering restrictions on color attachments that are michael@0: imposed by ES 3.0. michael@0: michael@0: 2) Should the MAX_DRAW_BUFFERS_EXT and MAX_COLOR_ATTACHMENTS_EXT limits michael@0: be per-framebuffer values or implementation dependent constants? michael@0: michael@0: DISCUSSION: In ARB_draw_buffers this was per-context (see Issue 2). michael@0: EXT_framebuffer_object (and subsequently ARB_framebuffer_object, and GL 3.0 michael@0: through GL 4.2) made these queries framebuffer-dependent. michael@0: However in GL 4.3 and GLES 3.0, these limits were changed from michael@0: framebuffer-dependent state to implementation-dependent state after michael@0: much discussion (Bug 7990). michael@0: michael@0: NV_draw_buffers has MAX_DRAW_BUFFERS listed as per-framebuffer state, michael@0: but NV_fbo_color_attachments has MAX_COLOR_ATTACHMENTS as an michael@0: implementation-dependent constant. michael@0: michael@0: This is relevant because some implementations are not able to support michael@0: multisampling in conjuction with multiple color attachments. If the michael@0: query is per-framebuffer, they can report a maximum of one attachment michael@0: when there are multisampled attachments, but a higher limit when only michael@0: single-sampled attachments are present. michael@0: michael@0: RESOLVED. Make this global context state as this is most consistent michael@0: with GLES 3.0 and updated GL drivers. In an implementation cannot michael@0: support multisampling in conjunction with multiple color attachments, michael@0: perhaps such an implementation could report FBO incomplete in this michael@0: situation, but this is less than desirable. michael@0: michael@0: 3) Should we support broadcast from gl_FragColor to all gl_FragData[x] michael@0: or should it be synonymous with gl_FragData[0]? michael@0: michael@0: DISCUSSION: With NV_draw_buffers, writing to gl_FragColor writes to all michael@0: the enabled draw buffers (ie broadcast). In OpenGL ES 3.0 when using michael@0: ESSL 1.0, gl_FragColor is equivalent to writing a single output to michael@0: gl_FragData[0] and multiple outputs are not possible. When using ESSL 3.0, michael@0: only user-defined out variables may be used. michael@0: michael@0: If broadcast is supported, some implementations may have to replace michael@0: writes to gl_FragColor with replicated writes to all possible gl_FragData michael@0: locations when this extension is enabled. michael@0: michael@0: RESOLVED: Writes to gl_FragColor are broadcast to all enabled color michael@0: buffers. ES 3.0 using ESSL 1.0 doesn't support broadcast because michael@0: ESSL 1.0 was not extended to have multiple color outputs (but that is michael@0: what this extension adds). ESSL 3.0 doesn't support the broadcast because michael@0: it doesn't have the gl_FragColor variable at all, and only has user- michael@0: defined out variables. This extension extends ESSL 1.0 to have multiple michael@0: color outputs. Broadcasting from gl_FragColor to all enabled color michael@0: buffers is the most consistent with existing draw buffer extensions to michael@0: date (both NV_draw_buffers and desktop GL). michael@0: michael@0: 4) Should we allow DrawBuffersEXT to be called when the default FBO is michael@0: bound? michael@0: michael@0: DISCUSSION: NV_draw_buffers specifies that DrawBuffersNV errors with michael@0: INVALID_OPERATION when the default FBO is bound. OpenGL ES 3.0 allows michael@0: DrawBuffers to toggle between BACK and NONE on the default FBO. michael@0: michael@0: An implementation that does not natively support disabling the drawbuffer michael@0: on the default FBO could emulate this by disabling color writes. michael@0: michael@0: RESOLVED: Allow DrawBuffersEXT to be called for the default FBO. This michael@0: is more forward looking and is compatible with ES 3.0. michael@0: michael@0: 5) What are the requirements on the color attachment sizes and formats? michael@0: michael@0: RESOLVED: ES 2.0 requires that all color buffers attached to application- michael@0: created framebuffer objects must have the same number of bitplanes michael@0: (Chapter 4 overview p91). ES 2.0 also requires that all attached images michael@0: have the same width and height (Section 4.4.5 Framebuffer Completeness). michael@0: This extension does not lift those requirements, and failing to meet michael@0: them will result in an incomplete FBO. michael@0: michael@0: 6) Does this have any interactions with glClear? michael@0: michael@0: RESOLVED: Yes. When multiple color buffers are enabled for writing, michael@0: glClear clears all of the color buffers. Added language clarifying michael@0: that glClear and glClearColor may affect multiple color buffers. michael@0: michael@0: Revision History michael@0: michael@0: 01/30/2013 dgkoch add issue 6 and clear interactions michael@0: renamed to EXT_draw_buffers based on feedback michael@0: changed resolution of issue 3. michael@0: 01/23/2013 dgkoch add resolutions to issues 2-4. michael@0: add issue 5. michael@0: Add Table 4.x and update various explicit michael@0: references to COLOR_ATTACHMENT0. michael@0: Add errors. michael@0: 11/13/2012 dgkoch add revision history michael@0: add text from updated ES 3.0 spec michael@0: add issues for discussion michael@0: 10/16/2012 kbr update name string michael@0: 10/16/2012 kbr remove restrition requiring draw buffer 0 to be non-NULL michael@0: 10/12/2012 kbr remove references to GetDoublev and ReadBuffer michael@0: 10/11/2012 kbr initial draft extension michael@0: