| Name | |
| EXT_window_rectangles | |
| Name Strings | |
| GL_EXT_window_rectangles | |
| Contact | |
| Mark J. Kilgard, NVIDIA Corporation (mjk 'at' nvidia.com) | |
| Contributors | |
| Jeff Bolz, NVIDIA | |
| Mark Callow, Khronos | |
| Chris Dalton, NVIDIA | |
| Arthur Huillet, NVIDIA | |
| Ilia Mirkin | |
| Kai Ninomiya, Google | |
| Marek Olsak, AMD | |
| Brian Paul, VMware Inc. | |
| Brian Salomon, Google | |
| Walt Steiner, NVIDIA | |
| Status | |
| Complete | |
| Implemeneted in NVIDIA late-2016 drivers | |
| Version | |
| Last Modified Date: 2017/11/03 | |
| Public Revision: 3 | |
| Number | |
| OpenGL Extension #490 | |
| OpenGL ES Extension #263 | |
| Dependencies | |
| Written based on the wording of the OpenGL 4.5 (Compatibility Profile) | |
| specification. | |
| This extension requires OpenGL 3.0 (for glGet*i_v queries) or | |
| EXT_draw_buffers2 (for glGet*IndexedvEXT queries). | |
| This extension interacts with EXT_direct_state_access. | |
| Also written based on the wording of the OpenGL ES 3.2 specification. | |
| This extension requires OpenGL ES 3.0 (for glGet*i_v queries) or ES | |
| 2.0 with EXT_multiview_draw_buffers (for glGet*i_vEXT queries). | |
| Overview | |
| This extension provides additional orthogonally aligned "window | |
| rectangles" specified in window-space coordinates that restrict | |
| rasterization of all primitive types (geometry, images, paths) | |
| and framebuffer clears. | |
| When rendering to the framebuffer of an on-screen window, these | |
| window rectangles are ignored so these window rectangles apply to | |
| rendering to non-zero framebuffer objects only. | |
| From zero to an implementation-dependent limit (specified by | |
| GL_MAX_WINDOW_RECTANGLES_EXT) number of window rectangles can be | |
| operational at once. When one or more window rectangles are active, | |
| rasterized fragments can either survive if the fragment is within | |
| any of the operational window rectangles (GL_INCLUSIVE_EXT mode) or | |
| be rejected if the fragment is within any of the operational window | |
| rectangles (GL_EXCLUSIVE_EXT mode). | |
| These window rectangles operate orthogonally to the existing scissor | |
| test functionality. | |
| This extension has specification language for both OpenGL and ES so | |
| EXT_window_rectangles can be implemented and advertised for either | |
| or both API contexts. | |
| New Procedures and Functions | |
| void WindowRectanglesEXT(enum mode, sizei count, const int box[]); | |
| New Tokens | |
| Accepted by the <mode> parameter of WindowRectanglesEXT: | |
| INCLUSIVE_EXT 0x8F10 | |
| EXCLUSIVE_EXT 0x8F11 | |
| Accepted by the <pname> parameter of GetIntegeri_v, GetInteger64i_v, | |
| GetBooleani_v, GetFloati_v, GetDoublei_v, GetIntegerIndexedvEXT, | |
| GetFloatIndexedvEXT, GetDoubleIndexedvEXT, GetBooleanIndexedvEXT, and | |
| GetIntegeri_vEXT: | |
| WINDOW_RECTANGLE_EXT 0x8F12 | |
| Accepted by the <pname> parameter of GetBooleanv, GetIntegerv, | |
| GetInteger64v, GetFloatv, and GetDoublev: | |
| WINDOW_RECTANGLE_MODE_EXT 0x8F13 | |
| MAX_WINDOW_RECTANGLES_EXT 0x8F14 | |
| NUM_WINDOW_RECTANGLES_EXT 0x8F15 | |
| Additions to Chapter 14 of the OpenGL 4.5 (Compatibility Profile) | |
| Specification (Fixed-Function Primitive Assembly and Rasterization) | |
| -- Change the second and third paragraph of section 14.9 "Early | |
| Per-Fragment Tests" to read: | |
| "Up to five operations are performed on each fragment, in the | |
| following order: | |
| * the pixel ownership test (see section 17.3.1); | |
| * the window rectangles test (see section 17.3.X); | |
| * the scissor test (see section 17.3.2); | |
| * the stencil test (see section 17.3.5); | |
| * the depth buffer test (see section 17.3.6); and | |
| * occlusion query sample counting (see section 17.3.7). | |
| The pixel ownership, window rectangles test, and scissor tests are | |
| always performed." | |
| Additions to Chapter 17 of the OpenGL 4.5 (Compatibility Profile) | |
| Specification (Writing Fragments and Samples to the Framebuffer) | |
| -- Update figure 7.1 "Per-fragment operations" to insert a box labeled | |
| "Window Rectangles Test" with an arrow from the "Pixel Ownership Test" | |
| box and an arrow to the "Scissor Test" box. | |
| -- Insert section 17.3.X "Window Rectangles Test" after section 17.3.1 | |
| "Pixel Ownership Test" | |
| "The window rectangles test determines if window-space fragment | |
| position (xw,yw) is inclusive or exclusive to a set of window-space | |
| rectangles. The window rectangles are set with | |
| void WindowRectanglesEXT(enum mode, sizei n, const int box[]); | |
| where /mode/ is either INCLUSIVE_EXT or EXCLUSIVE_EXT (and otherwise | |
| generates INVALID_ENUM), /n/ is a count of active window rectangles (and | |
| generates INVALID_VALUE when /n/ is less than zero or greater than | |
| the implementation-dependent value of MAX_WINDOW_RECTANGLES_EXT), and | |
| an array of 4*/n/ elements. | |
| When the WindowRectanglesEXT command is processed without error, | |
| the /i/th window rectangle box is set to the corresponding four | |
| parameters (box[4*i],box[4*i+1],box[4*i+2],box[4*i+3) for values | |
| of /i/ less then /n/. For values of /i/ greater than /n/, each | |
| window rectangle box is set to (0,0,0,0). | |
| Each four elements (x_i,y_i,w_i,h_i) corresponds to the /i/th window | |
| rectangle indicating a box of pixels specified with window-space | |
| coordinates. Each window rectangle box /i/ has a lower-left origin at | |
| (x_i,y_i) and upper-right corner at (x_i+w_i,y_i+h_i). | |
| The INVALID_VALUE error is generated if any element w_i or h_i, | |
| corresponding to each box's respective width and height, is negative. | |
| Each rasterized or cleared fragment with a window-space position | |
| (xw,yw) is within the /i/th window rectangle box when both of these | |
| equations are satisfied for all /i/ less than /n/: | |
| x_i <= xw < x_i+w_i | |
| y_i <= yw < y_i+h_i, | |
| When the window rectangles mode is INCLUSIVE_EXT mode and the | |
| bound framebuffer object is non-zero, a fragment passes the window | |
| rectangles test if the fragment's window-space position is within | |
| at least one of the current /n/ active window rectangles; otherwise | |
| the window rectangles test fails and the fragment is discarded. | |
| When the window rectangles mode is EXCLUSIVE_EXT mode and the bound | |
| framebuffer object is non-zero, a fragment fails the window rectangles | |
| test and is discarded if the fragment's window-space position is | |
| within at least one of the current /n/ active window rectangles; | |
| otherwise the window rectangles test passes and the fragment passes | |
| the window rectangles test. | |
| When the bound framebuffer object is zero, the window rectangles | |
| test always passes. | |
| The state required for the window rectangles test is a bit | |
| indicating if the mode is inclusive or exclusive, an array with | |
| /max/ elements, each element consisting of 2 integers for (x,y) and | |
| 2 non-negative integers for width & height where /max/ is the value | |
| of the implementation-dependent constant MAX_WINDOW_RECTANGLES_EXT, | |
| and a non-negative integer indicating the number of active window | |
| rectangles. This initial state is EXCLUSIVE_EXT for the bit, all | |
| zero for each integer in the array of window rectangles, and zero | |
| for the count." | |
| -- Update section 17.4.3 "Clearing the Buffers" | |
| Replace the first sentence of the seventh paragraph with: | |
| "When Clear is called, the only per-fragment operations that are | |
| applied (if enabled) are the pixel ownership test, the window | |
| rectangles test (17.3.X), the scissor test, sRGB conversion (see | |
| section 17.3.9), and dithering." | |
| -- Update section 17.4.3.2 "Clearing the Multisample Buffer" | |
| Replace the final paragraph with: | |
| "Masking, window rectangle testing, and scissoring affect clearing | |
| the multisample buffer in the same way as they affect clearing the | |
| corresponding color, depth, and stencil buffers." | |
| -- Update section 18.1.2 "Conversion to Fragments" | |
| Change the third sentence of the second paragraph to read: | |
| "However, the histogram and minmax tables are updated even if the | |
| corresponding fragments are later rejected by the pixel ownership | |
| (section 17.3.1), window rectangles test (section 17.3.X), or scissor | |
| (section 17.3.2) tests." | |
| -- Update section 18.1.4 "Writing to the Stencil or Depth/Stencil Buffers" | |
| Change the third sentence to read: | |
| "Each pair is then treated as a fragment for purposes of the pixel | |
| ownership, window rectangle tests, and scissor tests; all other | |
| per-fragment operations are bypassed." | |
| -- Update section 18.3.2 "Blitting Pixel Rectangles" | |
| Update the second sentence of the fourteenth paragraph to read: | |
| "The only fragment operations which affect a blit are the pixel | |
| ownership test, the window rectangles test, the scissor test, and | |
| sRGB conversion (see section 17.3.9)." | |
| Additions to Chapter 7 of the OpenGL ES 3.2 Specification (Programs and | |
| Shaders) | |
| -- Change the second bullet in section 7.11.1 "Shader Memory Access | |
| Ordering" to read: | |
| "For each fragment generated by the GL, the number of fragment shader | |
| invocations depends on a number of factors. If the fragment fails | |
| the pixel ownership test (see section 13.8.1), window rectangles | |
| test (see section 13.8.X), scissor test (see section 13.8.2), or is | |
| discarded by any of the multisample fragment operations (see section | |
| 13.8.3), the fragment shader will not be executed." | |
| Additions to Chapter 13 of the OpenGL ES 3.2 | |
| Specification (Fixed-Function Primitive Assembly and Rasterization) | |
| -- Update figure 13.1 "Rasterization, early per-fragment tests, and | |
| fragment shading" to insert a box labeled "Window Rectangles Test" | |
| with an arrow from the "Pixel Ownership Test" box and an arrow to the | |
| "Scissor Test" box. | |
| -- Change the beginning of the second of section 13.8 "Early Per-Fragment | |
| Tests" to read: | |
| "Four fragment operations are performed, and a further three are | |
| optionally performed on each fragment, in the following order: | |
| * the pixel ownership test (see section 13.8.1); | |
| * the window rectangles test (see section 13.8.X); | |
| * the scissor test (see section 13.8.2); | |
| * multisample fragment operations (see section 13.8.3); | |
| If early per-fragment operations ..." | |
| -- Insert section 13.8.X "Window Rectangles Test" after section 13.8.1 | |
| "Pixel Ownership Test" | |
| "The window rectangles test determines if window-space fragment | |
| position (xw,yw) is inclusive or exclusive to a set of window-space | |
| rectangles. The window rectangles are set with | |
| void WindowRectanglesEXT(enum mode, sizei n, const int box[]); | |
| where /mode/ is either INCLUSIVE_EXT or EXCLUSIVE_EXT (and otherwise | |
| generates INVALID_ENUM), /n/ is a count of active window rectangles (and | |
| generates INVALID_VALUE when /n/ is less than zero or greater than | |
| the implementation-dependent value of MAX_WINDOW_RECTANGLES_EXT), and | |
| an array of 4*/n/ elements. | |
| When the WindowRectanglesEXT command is processed without error, | |
| the /i/th window rectangle box is set to the corresponding four | |
| parameters (box[4*i],box[4*i+1],box[4*i+2],box[4*i+3) for values | |
| of /i/ less then /n/. For values of /i/ greater than /n/, each | |
| window rectangle box is set to (0,0,0,0). | |
| Each four elements (x_i,y_i,w_i,h_i) corresponds to the /i/th window | |
| rectangle indicating a box of pixels specified with window-space | |
| coordinates. Each window rectangle box /i/ has a lower-left origin at | |
| (x_i,y_i) and upper-right corner at (x_i+w_i,y_i+h_i). | |
| The INVALID_VALUE error is generated if any element w_i or h_i, | |
| corresponding to each box's respective width and height, is negative. | |
| Each rasterized or cleared fragment with a window-space position | |
| (xw,yw) is within the /i/th window rectangle box when both of these | |
| equations are satisfied for all /i/ less than /n/: | |
| x_i <= xw < x_i+w_i | |
| y_i <= yw < y_i+h_i, | |
| When the window rectangles mode is INCLUSIVE_EXT mode and the | |
| bound framebuffer object is non-zero, a fragment passes the window | |
| rectangles test if the fragment's window-space position is within | |
| at least one of the current /n/ active window rectangles; otherwise | |
| the window rectangles test fails and the fragment is discarded. | |
| When the window rectangles mode is EXCLUSIVE_EXT mode and the bound | |
| framebuffer object is non-zero, a fragment fails the window rectangles | |
| test and is discarded if the fragment's window-space position is | |
| within at least one of the current /n/ active window rectangles; | |
| otherwise the window rectangles test passes and the fragment passes | |
| the window rectangles test. | |
| When the bound framebuffer object is zero, the window rectangles | |
| test always passes. | |
| The state required for the window rectangles test is a bit | |
| indicating if the mode is inclusive or exclusive, an array with | |
| /max/ elements, each element consisting of 2 integers for (x,y) and | |
| 2 non-negative integers for width & height where /max/ is the value | |
| of the implementation-dependent constant MAX_WINDOW_RECTANGLES_EXT, | |
| and a non-negative integer indicating the number of active window | |
| rectangles. This initial state is EXCLUSIVE_EXT for the bit, all | |
| zero for each integer in the array of window rectangles, and zero | |
| for the count." | |
| Additions to Chapter 15 of the OpenGL ES 3.2 Specification (Writing | |
| Fragments and Samples to the Framebuffer) | |
| -- Update section 15.2.3 "Clearing the Buffers" | |
| Replace the first sentence of the sixth paragraph with: | |
| "When Clear is called, the only per-fragment operations that are | |
| applied (if enabled) are the pixel ownership test, the window | |
| rectangles test (13.8.X), the scissor test, sRGB conversion (see | |
| section 15.1.6), and dithering." | |
| -- Update section 15.2.3.2 "Clearing the Multisample Buffer" | |
| Replace the final paragraph with: | |
| "Masking, window rectangle testing, and scissoring affect clearing | |
| the multisample buffer in the same way as they affect clearing the | |
| corresponding color, depth, and stencil buffers." | |
| Additions to Chapter 16 of the OpenGL ES 3.2 Specification (Reading and | |
| Copying Pixels) | |
| -- Update section 16.2.1 "Blitting Pixel Rectangles" | |
| Update the second sentence of the thirteenth paragraph to read: | |
| "The only fragment operations which affect a blit are the pixel | |
| ownership test, the window rectangles test, the scissor test, and | |
| sRGB conversion (see section 15.1.6)." | |
| Interactions with the EXT_draw_buffers2 specification | |
| If EXT_draw_buffers2 is NOT supported, ignore references to | |
| GetIntegerIndexedvEXT and GetBooleanIndexedvEXT. | |
| Interactions with the EXT_direct_state_access specification | |
| If EXT_direct_state_access is NOT supported, ignore references to | |
| GetFloatIndexedvEXT and GetDoubleIndexedvEXT. | |
| Interactions with the EXT_multiview_draw_buffers | |
| If EXT_multiview_draw_buffers is NOT supported, ignore references to | |
| GetIntegeri_vEXT. | |
| Additions to the AGL/GLX/WGL Specifications | |
| None | |
| GLX Protocol | |
| A new GL rendering command is added. The following command is sent to the | |
| server as part of a glXRender request: | |
| WindowRectanglesEXT | |
| 2 12+4*n rendering command length | |
| 2 XXX rendering command opcode | |
| 4 ENUM mode | |
| 4 CARD32 count | |
| 4*n LISTofINT32 box | |
| Errors | |
| The error INVALID_ENUM is generated by WindowRectanglesEXT if mode | |
| is not INCLUSIVE_EXT or EXCLUSIVE_EXT. | |
| The error INVALID_VALUE is generated by WindowRectanglesEXT if count | |
| is negative. | |
| The error INVALID_VALUE is generated by WindowRectanglesEXT if | |
| count is greater than the value of the implementation-dependent | |
| limit MAX_WINDOW_RECTANGLES_EXT. | |
| The error INVALID_VALUE is generated by WindowRectanglesEXT if any | |
| of the w_i or h_i elements of the box array are negative. | |
| The error INVALID_VALUE is generated by GetIntegeri_v, | |
| GetInteger64i_v, GetBooleani_v, GetFloati_v, and GetDoublei_v when | |
| pname is WINDOW_RECTANGLE_EXT and index is greater or equal to the | |
| implementation-dependent value of MAX_WINDOW_RECTANGLES_EXT. | |
| New State | |
| (table 23.26, p724) add the following entry: | |
| Get Value Type Get Command Initial Value Description Sec Attribute | |
| ------------------------- ------- ------------- ------------- ------------------------ ------ --------- | |
| NUM_WINDOW_RECTANGLE_EXT Z+ GetIntegerv 0 Active window rectangles 17.3.X scissor | |
| count | |
| WINDOW_RECTANGLE_EXT 4*x4xZ+ GetIntegeri_v 4*x(0,0,0,0) Window rectangle box 17.3.X scissor | |
| WINDOW_RECTANGLE_MODE_EXT Z2 GetIntegerv EXCLUSIVE_EXT Window rectangle mode 17.3.X scissor | |
| New Implementation Dependent State | |
| (table 23.66, p764) add the following entry: | |
| Get Value Type Get Command Minimum Value Description Sec Attribute | |
| ------------------------- ---- ----------- ------------- ----------------- ------ -------------- | |
| MAX_WINDOW_RECTANGLES_EXT Z+ GetIntegerv 4 Maximum num of 17.3.X - | |
| window rectangles | |
| Issues | |
| 1) What should this extension be called? | |
| RESOLVED: EXT_window_rectangles as this extension introduces | |
| a new per-fragment test, called the window rectangles test, | |
| that operates on (x,y) window-space coordinates of the fragment, | |
| testing those coordinates against a set of rectangles. | |
| We avoid the term "scissor" because that describes preexisting | |
| OpenGL functionality orthogonal to this extension's | |
| functionality. | |
| We also avoid the term "clip" because clipping operates on | |
| primitives (triangles, lines, points) rather than fragments | |
| as the window rectangles test does. | |
| The "window" in the name does not refer to the often rectangular | |
| surface for managing application rendering within a desktop user | |
| interface metaphor. "window" refers to window-space following | |
| the precedent of the ARB_window_pos extension. | |
| Each rectangle is specified as a box in (integer) window-space | |
| coordinates. Multiple such rectangles are supported hence | |
| "rectangles" in the name. | |
| Intuitively, we can think of the rectangles carving out by | |
| exclusion (or selecting by inclusion) rectangular boxes in | |
| the region of window space either not allowed (or allowed) for | |
| rasterization. | |
| 2) Should there be an enable? | |
| RESOLVED: No, configuring zero exclusive window rectangles is | |
| the same as disabling window rectangles. Example: | |
| // disable window rectangles | |
| glWindowRectanglesEXT(GL_EXCLUSIVE, 0, NULL); | |
| 3) Should all the window rectangles be specified in a single call | |
| with the mode? | |
| RESOLVED: Yes. | |
| The expectation is that the configuration of window rectangles | |
| is typically updated once per frame. Hence it makes sense to | |
| have a single API call that takes an array of window rectangle | |
| boxes rather than requiring one call to specify each window | |
| rectangle box. This means all the window rectangles must be | |
| specified "as a unit" but this is likely an advantage. | |
| 4) What performance expectations should applications have when | |
| window rectangles are configured? | |
| RESOLVED: Applications should assume window rectangles | |
| discard work (rasterized fragments) and there is effectively | |
| no cost to enable the window rectangles, even including the | |
| implementation-dependent limit number of window rectangles. | |
| 5) How does this extension's window rectangles interact with OpenGL's | |
| existing scissor test functionality? | |
| RESOLVED: The scissor test and window rectangles are orthogonal. | |
| In window rectangle inclusive mode, a fragment survives the | |
| scissor test and window rectangles when the fragment's window space | |
| position is within any one of the window rectangles and also | |
| inside the scissor box. | |
| In window rectangle exclusive mode, a fragment survives the | |
| scissor test and window rectangles when the fragment's window | |
| space position is within the scissor box and NOT within any of | |
| the window rectangles. | |
| 6) What should an application do if it needs more than the | |
| implementation-dependent maximum number of window rectangles? | |
| RESOLVED: The application can use stencil testing as a way to | |
| simulate more than the implementation-dependent maximum. | |
| The application may find it is possible to express a more complex | |
| clipping region by merging or overlapping window rectangles. | |
| 7) What are some intended applications for this extension? | |
| RESOLVED: There are several envisioned applications: | |
| a) For a simple user interface managed in OpenGL, the window | |
| rectangles in exclusive mode can be used to avoid rendering | |
| into one or more rectangular sub-windows, dialog boxes, | |
| or menus "overlapping" some rendering window. | |
| While stencil testing could be used in this application, | |
| that requires rendering the extents of all the windows into | |
| the stencil buffer. Managing exclusive window rectangles | |
| is simpler for simple configurations and leaves the stencil | |
| buffer for other purposes. | |
| b) Minimizing rasterization to non-animating regions of a | |
| framebuffer. Say much of the background of a game is not | |
| actually updating; for example, a board game or puzzle game | |
| where rendering updates are highly localized. Inclusive | |
| rectangles can restrict rendering to just the rectangles | |
| of the screen that require updates. | |
| The scissor could be used for this purpose but would | |
| only represent a single rectangle so the application would | |
| have to repeat the rendering process multiple times at | |
| different scissor locations. | |
| 8) Does the window rectangles test affect rasterization of geometric | |
| primitive (polygons, lines, points), image rectangles (glBitmap, | |
| glDrawPixels, glCopyPixels), and path rendering? | |
| RESOLVED: Yes. | |
| 9) Does the window rectangles test affect clears? | |
| RESOLVED: Yes. | |
| 10) If you specify a subset (or none) of the window rectangles, | |
| what happens to the state of the unspecified window rectangles? | |
| RESOLVED: The state of such boxes is set to (0,0,0,0). | |
| This only matters to the extent that you can query that state | |
| with glGetIntegerv_i, etc. and get reliable values returned. | |
| 11) What if negative values are specified for box coordinates? | |
| RESOLVED: The values of the window rectangles box elements are | |
| typed GLint, however the width and height parameters of each | |
| box are required to be non-negative (otherwise GL_INVALID_VALUE | |
| results). | |
| This matches the behavior of existing commands such | |
| as glScissorArrayv and glViewportArrayv, part of the | |
| ARB_viewport_array extension. | |
| 12) What about really huge values for the box coordinates? | |
| RESOLVED: That should be fine. In theory, OpenGL has an | |
| implementation-dependent limit GL_MAX_VIEWPORT_DIMS so there is | |
| a bound on the (xw,yw) of rasterized fragments. | |
| There is not any implicit or explicit clamping of the box | |
| coordinates. | |
| 13) What happens when the window rectangles mode is GL_INCLUSIVE_EXT but | |
| zero window rectangles are specified? | |
| RESOLVED: All rasterization and clearing is discarded. Effectively | |
| there's no way for a fragment to be "inside" the window clips | |
| if there are none. | |
| This is just one of many ways to throw away all rasterized | |
| fragments in OpenGL. A similiar effect could be accomplished with | |
| a zero width or height scissor (or zero width and height inclusive | |
| window rectangles for that matter). | |
| This behavior is why GL_EXCLUSIVE_EXT is the initial context state. | |
| 14) Should this work when rendering to windows? | |
| RESOLVED: No, the hardware functionality for window rectangles | |
| may be used by the window system for pixel-ownership tests. Instead | |
| this functionality is limited to FBOs. | |
| 15) Should this work when rendering to non-FBO off-screen rendering | |
| resources such pbuffers, GLX bitmaps, and Windows | |
| device-independent bitmaps? | |
| RESOLVED: No. | |
| For simplicity of specification, the language is written to | |
| refer only to non-zero framebuffer objects supporting the window | |
| rectangles test so pbuffers, etc. wouldn't support the window | |
| rectangles test. | |
| Off-screen rendering mechanisms such as pbuffers are legacy | |
| mechanisms that predated FBOs so it makes sense to not aggrandize | |
| them. This eases the implementation and testing burden for | |
| supporting the window rectangles test. | |
| 16) Should the viewport index index into an array of window rectangle | |
| arrays, similar to viewport and scissor arrays? | |
| RESOLVED: No. This functionality is disconnected from the | |
| viewport index (see ARB_viewport_array) but orthogonal to that | |
| functionality. | |
| The current set of window rectangles applies to rasterization | |
| independent of the viewport index. | |
| 17) Does the window rectangles test affect glBlitFramebuffer and | |
| similar blit operations? | |
| RESOLVED: Yes. | |
| One of the key applications is limiting opaque compositing so | |
| clipping blit framebuffer operations is important to support. | |
| 18) Does the window rectangles test affect glAccum operations? | |
| RESOLVED: No, because framebuffer objects do not support | |
| accumulation buffer attachments and the window rectangles test | |
| only operates on FBOs (see issue 15). | |
| If support for accumulation buffer bindings were supported for | |
| FBOs (as unlikely though would be), it would make sense for | |
| language to be added to support window rectangles on FBOs. | |
| That language would read: | |
| -- Update section 17.4.5 "The Accumulation Buffer" | |
| Change the second paragraph's first sentence to read: | |
| "When the scissor test is enabled (section 17.3.2), then only those | |
| pixels within the current scissor box are updated by any Accum | |
| operation; otherwise, all pixels in the window that survive the | |
| window rectangles test (section 17.3.X) are updated." | |
| Change the second sentence of the fifth paragraph to read: | |
| "If fragment color clamping is enabled, the results are then clamped | |
| to the range [0,1]. The resulting color value is placed in the | |
| buffers currently enabled for color writing as if it were a fragment | |
| produced from rasterization, except that the only per-fragment | |
| operations that are applied (if enabled) are the pixel ownership | |
| test, the window rectangles test (section 17.3.X), the scissor test | |
| (section 17.3.2), sRGB conversion (see section 17.3.9), and dithering | |
| (section 17.3.10)." | |
| 19) Is glInvalidateSubFramebuffer affected by window rectangles test? | |
| RESOLVED: No. The window rectangles test applies to | |
| rasterization, and invalidating a region of the framebuffer is | |
| not a rasterization operation. | |
| 20) Should the window rectangles state be subject to | |
| glPushAttrib/glPopAttrib? | |
| RESOLVED: Yes, as part of the GL_SCISSOR_BIT state. | |
| Being able to push/pop window rectangles is a natural notion for | |
| hierachical clipping. The scissor state group is most similar | |
| to window rectangles. | |
| 21) Since shader memory accesses are possible from a fragment shader, | |
| can side effects from shader execution occur before the window | |
| rectangles test discards fragments? | |
| RESOLVED: No. | |
| No changes are made to section 7.12.1 "Shader Memory Access | |
| Ordering" when the window rectangles test is supported. | |
| An implementation could implement the window rectangles test | |
| as a fragment shader prologue, but if so, it needs to happen | |
| before any fragment shader side-effects that might occur if the | |
| fragment was not discarded by the window rectangles test. | |
| 22) Can a software rasterizer efficiently exploit this functionality? | |
| RESOLVED: Yes. For an existing software rasterizer, the window | |
| rectangles test could be implementing naively, just testing every | |
| pixel position against all the active inclusive or exclusive | |
| window rectanges. | |
| For a bit more sophisticated software rasterizer, the nice thing | |
| is the window rectangles are "known up front" so they can be | |
| statically Y-sorted and then X-sorted for primitives bounding | |
| boxes to minimize the window rectangle intersection costs. In a | |
| smart scan-line rasterizer, once you detect and excluded pixel | |
| position, you can skip over pixels to advance past exclusive | |
| window rectangles rather than naively testing every fragment. | |
| MMX should be useful for it. | |
| 23) Is this functionality useful for rendering virtual reality eye | |
| views? | |
| RESOLVED: Yes. Often when rendering to a view frustum for a | |
| virtual reality eye view, the edges of the field of view are | |
| not do not contribute to the warped version of the image to be | |
| displayed on the Head Mounted Display (HMD). | |
| By overlapping multiple inclusive window rectangles, the shape | |
| of an stair-stepped approximate circle or ellipse can be formed | |
| so rasterization to the corners is skipped. | |
| 24) Can the glWindowRectanglesEXT command be compiled into a display | |
| list? | |
| RESOLVED: Yes (as the specification language does not say | |
| otherwise) and the command is a rendering state command logically | |
| similar to glScissor and glViewport. | |
| 25) How does the window rectangles test operated in layered | |
| framebuffer (see section 9.8) rendering? | |
| RESOLVED: The window rectangles test affects rendering to any | |
| and all layers. The test itself just depends on the window | |
| coordinates of a pixel, not its layer. | |
| 26) Does the window rectangles state affect glReadPixels or the | |
| reading of pixels by glCopyPixels or glBlitFramebuffer? | |
| RESOLVED: No. The window rectangles test is a fragment operation | |
| for pixel updates. Pixel values are read irrespective of the | |
| window rectangles test state. This is matches the behavior of | |
| the existing scissor test. | |
| That said, the window rectangles test does affect the | |
| blitted/copied pixel written by glBlitFramebuffer and glCopyPixels | |
| operations. This could allow an implementation to skip reading | |
| pixels that will be discarded by the window rectangles test on | |
| the pixel update operations that are discarded by the window | |
| rectangles test on a blit or copy operation. | |
| 27) Is this extension functionally and interface identical in its | |
| OpenGL and ES versions? | |
| RESOLVED: Yes, the API and functionality is identical. | |
| 28) What should the minimum implementation-dependent limit for | |
| GL_MAX_WINDOW_RECTANGLES_EXT be? | |
| RESOLVED: 4 (was 8 originally). | |
| While NVIDIA GPUs can support 8 window rectangles, feedback from | |
| AMD is they could support the extension if the limit was 4. | |
| 29) Is there a Vulkan version of this functionality? | |
| RESOLVED: Yes, VK_EXT_discard_rectangles. See: | |
| https://www.khronos.org/registry/vulkan/specs/1.0-extensions/html/vkspec.html#VK_EXT_discard_rectangles | |
| Revision History | |
| Rev. Date Author Changes | |
| ---- -------- --------- ------------------------------------------------ | |
| 1 06/09/16 mjk Public release | |
| 2 06/27/16 mjk Change limit to 4 based on AMD feedback | |
| 3 11/03/17 mjk Fix state table for limit of 4, add issue 29 |