| 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 |