Name SGIS_shared_multisample Name Strings GL_SGIS_shared_multisample GLX_SGIS_shared_multisample Version $Date: 1997/10/29 20:41:07 $ $Revision: 1.2 $ Number 143 Dependencies GL_SGIS_multisample and GLX_SGIS_multisample are required Overview 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. Issues * 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 subrectangle. * 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 subrectangle. * What happens if you run a traditional (existing) multisample application on a window system advertising the shared multisample extension? VERY UNSIGHTLY FRAME BUFFER FIGHTING. 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 mode. * 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 parameter of GetBooleanv, GetDoublev, GetIntegerv, and GetFloatv: MULTISAMPLE_SUB_RECT_POSITION_SGIS MULTISAMPLE_SUB_RECT_DIMS_SGIS Accepted by the parameter of glXGetConfig, and by the parameter of glXChooseVisual: GLX_MULTISAMPLE_SUB_RECT_WIDTH_SGIS 0x8026 GLX_MULTISAMPLE_SUB_RECT_HEIGHT_SGIS 0x8027 Additions to Chapter 2 of the 1.1 Specification (OpenGL Operation) None Additions to Chapter 3 of the 1.1 Specification (Rasterization) None 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 set to MULTISAMPLE_SUB_RECT_DIMS_SGIS. 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. The state of MULTISAMPLE_SUB_RECT_POSITION_SGIS is set by: 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 the error INVALID_OPERATION. 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 undefined. 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 subrectangle. Additions to Chapter 5 of the 1.1 Specification (Special Functions) None Additions to Chapter 6 of the 1.1 Specification (State and State Requests) None Additions to the GLX Specification When called with set to GLX_MULTISAMPLE_SUB_RECT_WIDTH_SGI or GLX_MULTISAMPLE_SUB_RECT_HEIGHT_SGIS, glXGetConfig returns in parameter the respective multisample subrectangle width or height of the specified visual. The GLX_MULTISAMPLE_SUB_RECT_WIDTH_SGI and 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 configuration. glXChooseVisual accepts GLX_MULTISAMPLE_SUB_RECT_WIDTH_SGI and GLX_MULTISAMPLE_SUB_RECT_HEIGHT_SGIS in , 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 preferred. 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: MultisampleSubRectPosSGIS 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 0x8026 GLX_MULTISAMPLE_SUB_RECT_WIDTH 4 INT32 property value 4 ENUM property type 0x8027 GLX_MULTISAMPLE_SUB_RECT_HEIGHT 4 INT32 property value Errors None 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 --------- ----------- ----- ------------- MULTISAMPLE_SUB_RECT_DIMS_SGIS GetIntegerv 2 x Z 0,0