blob: 026a0638f593305e6f75c2ddfcf6fa749c03cea7 [file] [log] [blame]
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