blob: 00ac98a5990fe648863dcd9d8fe994fb75d488a3 [file] [log] [blame]
Name Strings
$Date: 1997/10/29 20:41:07 $ $Revision: 1.2 $
GL_SGIS_multisample and GLX_SGIS_multisample are required
While the OpenGL multisample extension (SGIS_multisample) provides
good out-of-order antialiasing via subpixel samples, multisample
hardware is very expensive because it multiplies the per-pixel
framebuffer memory required to maintain color, depth, and stencil
state by the number of samples.
The cost-sensitive Location Based Entertainment (LBE) market
desires good quality antialiasing, but the cost of maintaining
multisample memory for every pixel in the framebuffer managed area
is often prohibitive. Low-end multi-channel visual simulation may
have similar cost constraints.
LBE applications typically render several channels that are output
to different video display devices. For example, an LBE
application may render four 800x600 resolution channels, one per
game player. While the total managed area may be 1600x1200, each
channel ends up being rendered serially. With traditional
multisampling (as specified by SGIS_multisample), multisample
memory must be retained across the entire 1600x1200 managed area
though in fact the application is never using more than an 800x600
rectangle of multisample pixel state at any given time.
This sharing of multisample framebuffer state can result in a
substantial competitive advantage for high-end multi-channel
multisampling hardware for LBE applications. Unlike a "cheap PC
per seat" solution, a high-end solution can be amortized by sharing
both texture and multisample memory between the multiple channels
(as well as host resources such as disk and CPUs). For cheap PCs
to have the same amount of texture memory and quality of
antialiasing, texture and multisample memory have to be replicated
in every PC.
In a typical windowed environment, the entire framebuffer managed
area must retain multisample state because windows can be moved
dynamically and resized (up to the entire size of the managed
area). For LBE applications though, the layout of channel
subrectangles in the framebuffer managed area is static and the
LBE application monopolizes the graphics device (no other
concurrent windowed apps). Because of their channel-oriented,
dedicated, cost-sensitive nature, LBE applications can benefit from
a means to share the available multisample memory resources among
all the channels.
The SGIS_shared_multisample extension specifies a single
multisample buffer subrectangle sized smaller than the total
managed area that is both shared among multiple windows and
repositionable within in a window.
Use of the SGIS_shared_multisample extension is predicated on
specially configuring the window system, typically via a command
line option added to the window system server's startup command.
When run in this mode, OpenGL applications will see the
GL_SGIS_shared_multisample string advertised in the GL_EXTENSIONS
string (along with the GL_SGIS_multisample string). In this mode,
the behavior of multisample extension changes. Instead of the
multisample buffer memory being retained per-pixel across the
entire managed area, multisample memory is shared among multisample
windows and repositionable within a multisample window.
Switching windows or repositioning the multisample subrectangle
will make undefined the shared state within the multisample, depth,
stencil, and accumulation buffers.
When rendering into a multisample window, fragments that fall
outside the window's multisample subrectangle are discarded
(scissored). By default, the window's multisample rectangle is
positioned at its window origin.
* As part of the pixel ownership test, when doing a ReadPixels,
CopyPixels, CopyTexImage, or CopySubTexImage operation, are the
sourced color pixels undefined if they are outside the
multisample subrectangle, but otherwise would pass the pixel
ownership test? NO, such pixel read/copies should be DEFINED.
This behavior is justified because the resolved color buffer is
available for copying outside the multisample subrectangle, just
not the multisample, depth, stencil, or accumulation buffer
values. LBE applications will likely find it useful to copy
rendering results from the first channel into the others. For
example, copying a radar view shared among all the players into
each channel.
Note that copies or reads of depth or stencil (or multisamples
or accumulation buffer contents if such contents were actually
readable) will NOT be expected to be defined.
The specification additions below only amend this with respect
to ReadPixels, but other language in the 4.3.3 "Copying Pixels"
and 3.8 "Texturing, Alternative Texture Image Specification
Commands" sections imply that CopyPixels, CopyTexImage2D, and
CopyTexImage1D will also not include scissoring against the
multisample subrectangle as part of the pixel ownership test
when sourcing from color buffers (not depth or stencil though).
This is because these other operations read pixels as specified
by the ReadPixels operation.
* Should the accumulation buffer be associated with the the
multisample subrectangle, or should the accumulation buffer be
retained (as are the color buffers) for pixels not within the
multisample subrectangle? If an accumulation buffer exists, it
should be SHARED like the multisample buffer.
This behavior is justified because accumulation buffers are big
and expensive just like multisample buffers. LBE apps still may
want to use the accumulation buffer for motion blur or depth of
field. Like the multisample buffer, the accumulation buffer
should be shared and retained only within the multisample
* What about auxiliary buffers? Does the same logic for
accumulation buffers apply? UNRESOLVED. This specification is
currently written to assume that an auxiliary buffer is a color
buffer and is not shared.
* If multiple GL clients must use framebuffers with a shared
multisample subrectangle, how can they guarantee reliable
rendering results? WITH GLFLUSH. Keep rendering temporally
distinct with glFlush issued before rendering thread switches.
* Does it make sense for hardware to advertise more than one
multisample subrectangle? NO. It would justified if you had
two parallel command streams updating distinct channels since
two channels would be rendering in parallel. But if this was
the case (thinking in the context of LBE applications), it
probably makes more sense simply to have two distinct pipes.
That's cheaper than trying to support a single pipe with
parallel rendering streams, plus the channels are rendering
independently (via screen space subdivision) anyway.
* Can you clear a window using a shared multisample buffer
outside the multisample subrectangle? NO.
glClear is controlled by the pixel ownership test and if a
fragment is not within the multisample subrectangle, it cannot
pass the pixel ownership test when using a multisample
* What happens if you run a traditional (existing) multisample
application on a window system advertising the shared
The app runs, but its multisample rendering will be constrained
to the multisample subrectangle. Multiple concurrent apps using
multisampling will "fight" for their use of the shared
multisample rectangle.
The expectation is that you only configure a window system
server to support shared multisample mode when running a single
dedicated LBE-style channel API. Note that you can still run
non-multisampled windowed apps just fine concurrently with a
shared multisample app.
* As written, this extension CHANGES the semantics of the
existing GL_SGIS_multisample extension. Should this new
extension use a GLX attribute distinct from the one used by the
GLX_SGIS_multisample extension? NO.
Users have to specially configure their window system server to
get the special overloaded sharing behavior. Plus LBE
applications monopolize the system anyway.
The advantage of overloading the existing multisample GLX
attributes is that 3D toolkits (IRIS Performer, OpenGL++, OpenGL
Optimizer) and multisample apps themselves won't have to be
specially tweaked to try them out using the shared multisample
* Can a single window system server be configured to advertise
an 8 sample shared multisample framebuffer configuration and an
4 sample shared multisample framebuffer configuration? YES,
the extension would allow such a case to be advertised.
The idea would be perhaps the 4 sample shared multisample
configuration could have a large width and height than the more
memory intensive 8 sample shared multisample configuration.
* Both a GLX and GL extension? YES. The multisample subrectangle
dimensions can be advertised for X visuals before actually
creating an actual window. Also allows different numbers of
samples to be advertised (see above).
New Procedures and Functions
void glMultisampleSubRectPosSGIS(GLint x,
GLint y);
New Tokens
Accepted by the <pname> parameter of GetBooleanv, GetDoublev,
GetIntegerv, and GetFloatv:
Accepted by the <attrib> parameter of glXGetConfig, and by the
<attrib_list> parameter of glXChooseVisual:
Additions to Chapter 2 of the 1.1 Specification (OpenGL Operation)
Additions to Chapter 3 of the 1.1 Specification (Rasterization)
Additions to Chapter 4 of the 1.1 Specification (Per-Fragment Operations and
the Framebuffer)
Section 4.1.1 (Pixel Ownership Test) is augmented as follows:
4.1.1.x "Scissoring to the Multisample Subrectangle"
The value of MULTISAMPLE_SUB_RECT_DIMS_SGIS is an implementation
dependent constant, and is queried by calling GetIntegerv with
MULTISAMPLE_SUB_RECT_DIMS_SGIS specifies the width and height of
the multisample subrectangle. Neither the
MULTISAMPLE_SUB_RECT_DIMS_SGIS width or height should be greater
than zero if SAMPLE_BUFFERS_SGIS is zero.
If SAMPLE_BUFFERS_SGIS is one and the
MULTISAMPLE_SUB_RECT_DIMS_SGIS width and height are both greater
than zero, the pixel ownership test is augmented to also discard
fragments not within the multisample subrectangle. Otherwise, the
pixel ownership operates normally and irrespective of the
multisample subrectangle.
void MultisampleSubRectPosSGIS(GLint x,
GLint y);
If either MULTISAMPLE_SUB_RECT_DIMS_SGIS width or height is zero or
the GL is in color index mode, MultisampleSubRectPosSGIS generates
When MultisampleSubRectPosSGIS is executed, the contents of the
multisample, depth, stencil, and accumulation buffers retained in
the multisample subrectangle (but not the contents of the resolved
color buffers) become undefined. Also when a GL client connects to
a different GL context, the multisample, depth, stencil and
accumulation buffer values for all pixels within the multisample
subrectangle (but not the resolved color buffers) become
The multisample subrectangle can be shared between multiple
framebuffers (windows). Whenever the multisample subrectangle
becomes undefined, the contents of the multisample, depth, stencil,
and accumulation buffers (but not the contents of the resolved
color buffers) for all GL framebuffers sharing the multisample
subrectangle state become undefined. When two or more GL clients
access (render or readback) concurrently framebuffers that share
the same multisample subrectangle (whether or not MULTISAMPLE_SGIS
is enabled), the rendering results for ALL buffers (including color
buffers) of all involved framebuffers are undefined.
The origin of the multisample subrectangle is defined by
(msrx,msry) specified by MULTISAMPLE_SUB_RECT_POSITION_SGIS in
window coordinates. The extent of the multisample subrectangle is
defined by (msrwidth,msrheight) specified by
MULTISAMPLE_SUB_RECT_DIMS_SGIS in window coordinates.
A fragment with window coordinates (xw,yw) is within the
multisample subrectangle if msrx <= xw < msrx + msrwidth and msry
<= yw < msry + msrheight.
4.2.4 "The Accumulation Buffer"
Rewrite the sentence beginning "When the scissor test is enabled"
that describes what color buffer pixels are updated by a RETURN
Accum operation to read:
If either of the MULTISAMPLE_SUB_RECT_DIMS_SGIS width or height is
zero, when the scissor test is enabled, then only those pixels
within the current scissor box are updated; otherwise, all pixels
in the window are updated. If the MULTISAMPLE_SUB_RECT_DIMS_SGIS
width and height are both greater than zero, only those pixels
within the current multisample subrectangle are updated; in
addition, if scissoring is enabled, the updated pixels are further
constrained to be within the scissor rectangle.
4.3.2 "Reading Pixels"
In the subsection "Obtaining Pixels from the Framebuffer", follow
the sentence "Results are also undefined for individual pixels that
are not owned by the current context." with: For the purpose of
reading the color buffers (not depth and stencil though), the pixel
ownership test does not include scissoring against the multisample
Additions to Chapter 5 of the 1.1 Specification (Special Functions)
Additions to Chapter 6 of the 1.1 Specification (State and State Requests)
Additions to the GLX Specification
When called with <attribute> set to
parameter <value> the respective multisample subrectangle width or
height of the specified visual.
GLX_MULTISAMPLE_SUB_RECT_HEIGHT_SGIS attributes of a visual or
framebuffer configuration determine the respective width and
height dimensions of MULTISAMPLE_SUB_RECT_DIMS_SGIS for
GLXDrawables created with the visual or framebuffer
GLX_MULTISAMPLE_SUB_RECT_HEIGHT_SGIS in <attribList>, followed by
the respective desired (non-negative) width or height of the
multisample rectangle. The smallest width or height of at least
the specified size is preferred. If the desired value is zero,
visuals with zero multisample rectangle width or height are
Multisample GLXDrawables that reside on the same screen share the
same multisample subrectangle. There is at most one shared
multisample subrectangle per screen.
GLX Protocol
A new GL rendering command is added. The following command is sent
to the server as part of a glXRender request:
2 12 rendering command length
2 ?? rendering command opcode
4 INT32 x
4 INT32 y
Two new property type/property value pairs are included in the
property list of each visual returned by glXGetVisualConfigs
request. The property type/property value pairs are encoded as.
4 ENUM property type
4 INT32 property value
4 ENUM property type
4 INT32 property value
New State
Get Value Get Command Type Initial Value Attribute
--------- ----------- ----- ------------- ---------
MULTISAMPLE_SUB_RECT_POSITION_SGIS GetIntegerv 2 x Z 0,0 multisample
New Implementation Dependent State
Get Value Get Command Type Minimum Value
--------- ----------- ----- -------------