1Name 2 3 SGIS_shared_multisample 4 5Name Strings 6 7 GL_SGIS_shared_multisample 8 GLX_SGIS_shared_multisample 9 10Version 11 12 $Date: 1997/10/29 20:41:07 $ $Revision: 1.2 $ 13 14Number 15 16 143 17 18Dependencies 19 20 GL_SGIS_multisample and GLX_SGIS_multisample are required 21 22Overview 23 24 While the OpenGL multisample extension (SGIS_multisample) provides 25 good out-of-order antialiasing via subpixel samples, multisample 26 hardware is very expensive because it multiplies the per-pixel 27 framebuffer memory required to maintain color, depth, and stencil 28 state by the number of samples. 29 30 The cost-sensitive Location Based Entertainment (LBE) market 31 desires good quality antialiasing, but the cost of maintaining 32 multisample memory for every pixel in the framebuffer managed area 33 is often prohibitive. Low-end multi-channel visual simulation may 34 have similar cost constraints. 35 36 LBE applications typically render several channels that are output 37 to different video display devices. For example, an LBE 38 application may render four 800x600 resolution channels, one per 39 game player. While the total managed area may be 1600x1200, each 40 channel ends up being rendered serially. With traditional 41 multisampling (as specified by SGIS_multisample), multisample 42 memory must be retained across the entire 1600x1200 managed area 43 though in fact the application is never using more than an 800x600 44 rectangle of multisample pixel state at any given time. 45 46 This sharing of multisample framebuffer state can result in a 47 substantial competitive advantage for high-end multi-channel 48 multisampling hardware for LBE applications. Unlike a "cheap PC 49 per seat" solution, a high-end solution can be amortized by sharing 50 both texture and multisample memory between the multiple channels 51 (as well as host resources such as disk and CPUs). For cheap PCs 52 to have the same amount of texture memory and quality of 53 antialiasing, texture and multisample memory have to be replicated 54 in every PC. 55 56 In a typical windowed environment, the entire framebuffer managed 57 area must retain multisample state because windows can be moved 58 dynamically and resized (up to the entire size of the managed 59 area). For LBE applications though, the layout of channel 60 subrectangles in the framebuffer managed area is static and the 61 LBE application monopolizes the graphics device (no other 62 concurrent windowed apps). Because of their channel-oriented, 63 dedicated, cost-sensitive nature, LBE applications can benefit from 64 a means to share the available multisample memory resources among 65 all the channels. 66 67 The SGIS_shared_multisample extension specifies a single 68 multisample buffer subrectangle sized smaller than the total 69 managed area that is both shared among multiple windows and 70 repositionable within in a window. 71 72 Use of the SGIS_shared_multisample extension is predicated on 73 specially configuring the window system, typically via a command 74 line option added to the window system server's startup command. 75 When run in this mode, OpenGL applications will see the 76 GL_SGIS_shared_multisample string advertised in the GL_EXTENSIONS 77 string (along with the GL_SGIS_multisample string). In this mode, 78 the behavior of multisample extension changes. Instead of the 79 multisample buffer memory being retained per-pixel across the 80 entire managed area, multisample memory is shared among multisample 81 windows and repositionable within a multisample window. 82 83 Switching windows or repositioning the multisample subrectangle 84 will make undefined the shared state within the multisample, depth, 85 stencil, and accumulation buffers. 86 87 When rendering into a multisample window, fragments that fall 88 outside the window's multisample subrectangle are discarded 89 (scissored). By default, the window's multisample rectangle is 90 positioned at its window origin. 91 92Issues 93 94 * As part of the pixel ownership test, when doing a ReadPixels, 95 CopyPixels, CopyTexImage, or CopySubTexImage operation, are the 96 sourced color pixels undefined if they are outside the 97 multisample subrectangle, but otherwise would pass the pixel 98 ownership test? NO, such pixel read/copies should be DEFINED. 99 100 This behavior is justified because the resolved color buffer is 101 available for copying outside the multisample subrectangle, just 102 not the multisample, depth, stencil, or accumulation buffer 103 values. LBE applications will likely find it useful to copy 104 rendering results from the first channel into the others. For 105 example, copying a radar view shared among all the players into 106 each channel. 107 108 Note that copies or reads of depth or stencil (or multisamples 109 or accumulation buffer contents if such contents were actually 110 readable) will NOT be expected to be defined. 111 112 The specification additions below only amend this with respect 113 to ReadPixels, but other language in the 4.3.3 "Copying Pixels" 114 and 3.8 "Texturing, Alternative Texture Image Specification 115 Commands" sections imply that CopyPixels, CopyTexImage2D, and 116 CopyTexImage1D will also not include scissoring against the 117 multisample subrectangle as part of the pixel ownership test 118 when sourcing from color buffers (not depth or stencil though). 119 This is because these other operations read pixels as specified 120 by the ReadPixels operation. 121 122 * Should the accumulation buffer be associated with the the 123 multisample subrectangle, or should the accumulation buffer be 124 retained (as are the color buffers) for pixels not within the 125 multisample subrectangle? If an accumulation buffer exists, it 126 should be SHARED like the multisample buffer. 127 128 This behavior is justified because accumulation buffers are big 129 and expensive just like multisample buffers. LBE apps still may 130 want to use the accumulation buffer for motion blur or depth of 131 field. Like the multisample buffer, the accumulation buffer 132 should be shared and retained only within the multisample 133 subrectangle. 134 135 * What about auxiliary buffers? Does the same logic for 136 accumulation buffers apply? UNRESOLVED. This specification is 137 currently written to assume that an auxiliary buffer is a color 138 buffer and is not shared. 139 140 * If multiple GL clients must use framebuffers with a shared 141 multisample subrectangle, how can they guarantee reliable 142 rendering results? WITH GLFLUSH. Keep rendering temporally 143 distinct with glFlush issued before rendering thread switches. 144 145 * Does it make sense for hardware to advertise more than one 146 multisample subrectangle? NO. It would justified if you had 147 two parallel command streams updating distinct channels since 148 two channels would be rendering in parallel. But if this was 149 the case (thinking in the context of LBE applications), it 150 probably makes more sense simply to have two distinct pipes. 151 That's cheaper than trying to support a single pipe with 152 parallel rendering streams, plus the channels are rendering 153 independently (via screen space subdivision) anyway. 154 155 * Can you clear a window using a shared multisample buffer 156 outside the multisample subrectangle? NO. 157 158 glClear is controlled by the pixel ownership test and if a 159 fragment is not within the multisample subrectangle, it cannot 160 pass the pixel ownership test when using a multisample 161 subrectangle. 162 163 * What happens if you run a traditional (existing) multisample 164 application on a window system advertising the shared 165 multisample extension? VERY UNSIGHTLY FRAME BUFFER FIGHTING. 166 167 The app runs, but its multisample rendering will be constrained 168 to the multisample subrectangle. Multiple concurrent apps using 169 multisampling will "fight" for their use of the shared 170 multisample rectangle. 171 172 The expectation is that you only configure a window system 173 server to support shared multisample mode when running a single 174 dedicated LBE-style channel API. Note that you can still run 175 non-multisampled windowed apps just fine concurrently with a 176 shared multisample app. 177 178 * As written, this extension CHANGES the semantics of the 179 existing GL_SGIS_multisample extension. Should this new 180 extension use a GLX attribute distinct from the one used by the 181 GLX_SGIS_multisample extension? NO. 182 183 Users have to specially configure their window system server to 184 get the special overloaded sharing behavior. Plus LBE 185 applications monopolize the system anyway. 186 187 The advantage of overloading the existing multisample GLX 188 attributes is that 3D toolkits (IRIS Performer, OpenGL++, OpenGL 189 Optimizer) and multisample apps themselves won't have to be 190 specially tweaked to try them out using the shared multisample 191 mode. 192 193 * Can a single window system server be configured to advertise 194 an 8 sample shared multisample framebuffer configuration and an 195 4 sample shared multisample framebuffer configuration? YES, 196 the extension would allow such a case to be advertised. 197 198 The idea would be perhaps the 4 sample shared multisample 199 configuration could have a large width and height than the more 200 memory intensive 8 sample shared multisample configuration. 201 202 * Both a GLX and GL extension? YES. The multisample subrectangle 203 dimensions can be advertised for X visuals before actually 204 creating an actual window. Also allows different numbers of 205 samples to be advertised (see above). 206 207New Procedures and Functions 208 209 void glMultisampleSubRectPosSGIS(GLint x, 210 GLint y); 211 212New Tokens 213 214 Accepted by the <pname> parameter of GetBooleanv, GetDoublev, 215 GetIntegerv, and GetFloatv: 216 217 MULTISAMPLE_SUB_RECT_POSITION_SGIS 218 MULTISAMPLE_SUB_RECT_DIMS_SGIS 219 220 Accepted by the <attrib> parameter of glXGetConfig, and by the 221 <attrib_list> parameter of glXChooseVisual: 222 223 GLX_MULTISAMPLE_SUB_RECT_WIDTH_SGIS 0x8026 224 GLX_MULTISAMPLE_SUB_RECT_HEIGHT_SGIS 0x8027 225 226Additions to Chapter 2 of the 1.1 Specification (OpenGL Operation) 227 228 None 229 230Additions to Chapter 3 of the 1.1 Specification (Rasterization) 231 232 None 233 234Additions to Chapter 4 of the 1.1 Specification (Per-Fragment Operations and 235the Framebuffer) 236 237 Section 4.1.1 (Pixel Ownership Test) is augmented as follows: 238 239 4.1.1.x "Scissoring to the Multisample Subrectangle" 240 241 The value of MULTISAMPLE_SUB_RECT_DIMS_SGIS is an implementation 242 dependent constant, and is queried by calling GetIntegerv with 243 <pname> set to MULTISAMPLE_SUB_RECT_DIMS_SGIS. 244 MULTISAMPLE_SUB_RECT_DIMS_SGIS specifies the width and height of 245 the multisample subrectangle. Neither the 246 MULTISAMPLE_SUB_RECT_DIMS_SGIS width or height should be greater 247 than zero if SAMPLE_BUFFERS_SGIS is zero. 248 249 If SAMPLE_BUFFERS_SGIS is one and the 250 MULTISAMPLE_SUB_RECT_DIMS_SGIS width and height are both greater 251 than zero, the pixel ownership test is augmented to also discard 252 fragments not within the multisample subrectangle. Otherwise, the 253 pixel ownership operates normally and irrespective of the 254 multisample subrectangle. 255 256 The state of MULTISAMPLE_SUB_RECT_POSITION_SGIS is set by: 257 258 void MultisampleSubRectPosSGIS(GLint x, 259 GLint y); 260 261 If either MULTISAMPLE_SUB_RECT_DIMS_SGIS width or height is zero or 262 the GL is in color index mode, MultisampleSubRectPosSGIS generates 263 the error INVALID_OPERATION. 264 265 When MultisampleSubRectPosSGIS is executed, the contents of the 266 multisample, depth, stencil, and accumulation buffers retained in 267 the multisample subrectangle (but not the contents of the resolved 268 color buffers) become undefined. Also when a GL client connects to 269 a different GL context, the multisample, depth, stencil and 270 accumulation buffer values for all pixels within the multisample 271 subrectangle (but not the resolved color buffers) become 272 undefined. 273 274 The multisample subrectangle can be shared between multiple 275 framebuffers (windows). Whenever the multisample subrectangle 276 becomes undefined, the contents of the multisample, depth, stencil, 277 and accumulation buffers (but not the contents of the resolved 278 color buffers) for all GL framebuffers sharing the multisample 279 subrectangle state become undefined. When two or more GL clients 280 access (render or readback) concurrently framebuffers that share 281 the same multisample subrectangle (whether or not MULTISAMPLE_SGIS 282 is enabled), the rendering results for ALL buffers (including color 283 buffers) of all involved framebuffers are undefined. 284 285 The origin of the multisample subrectangle is defined by 286 (msrx,msry) specified by MULTISAMPLE_SUB_RECT_POSITION_SGIS in 287 window coordinates. The extent of the multisample subrectangle is 288 defined by (msrwidth,msrheight) specified by 289 MULTISAMPLE_SUB_RECT_DIMS_SGIS in window coordinates. 290 291 A fragment with window coordinates (xw,yw) is within the 292 multisample subrectangle if msrx <= xw < msrx + msrwidth and msry 293 <= yw < msry + msrheight. 294 295 4.2.4 "The Accumulation Buffer" 296 297 Rewrite the sentence beginning "When the scissor test is enabled" 298 that describes what color buffer pixels are updated by a RETURN 299 Accum operation to read: 300 301 If either of the MULTISAMPLE_SUB_RECT_DIMS_SGIS width or height is 302 zero, when the scissor test is enabled, then only those pixels 303 within the current scissor box are updated; otherwise, all pixels 304 in the window are updated. If the MULTISAMPLE_SUB_RECT_DIMS_SGIS 305 width and height are both greater than zero, only those pixels 306 within the current multisample subrectangle are updated; in 307 addition, if scissoring is enabled, the updated pixels are further 308 constrained to be within the scissor rectangle. 309 310 4.3.2 "Reading Pixels" 311 312 In the subsection "Obtaining Pixels from the Framebuffer", follow 313 the sentence "Results are also undefined for individual pixels that 314 are not owned by the current context." with: For the purpose of 315 reading the color buffers (not depth and stencil though), the pixel 316 ownership test does not include scissoring against the multisample 317 subrectangle. 318 319Additions to Chapter 5 of the 1.1 Specification (Special Functions) 320 321 None 322 323Additions to Chapter 6 of the 1.1 Specification (State and State Requests) 324 325 None 326 327Additions to the GLX Specification 328 329 When called with <attribute> set to 330 GLX_MULTISAMPLE_SUB_RECT_WIDTH_SGI or 331 GLX_MULTISAMPLE_SUB_RECT_HEIGHT_SGIS, glXGetConfig returns in 332 parameter <value> the respective multisample subrectangle width or 333 height of the specified visual. 334 335 The GLX_MULTISAMPLE_SUB_RECT_WIDTH_SGI and 336 GLX_MULTISAMPLE_SUB_RECT_HEIGHT_SGIS attributes of a visual or 337 framebuffer configuration determine the respective width and 338 height dimensions of MULTISAMPLE_SUB_RECT_DIMS_SGIS for 339 GLXDrawables created with the visual or framebuffer 340 configuration. 341 342 glXChooseVisual accepts GLX_MULTISAMPLE_SUB_RECT_WIDTH_SGI and 343 GLX_MULTISAMPLE_SUB_RECT_HEIGHT_SGIS in <attribList>, followed by 344 the respective desired (non-negative) width or height of the 345 multisample rectangle. The smallest width or height of at least 346 the specified size is preferred. If the desired value is zero, 347 visuals with zero multisample rectangle width or height are 348 preferred. 349 350 Multisample GLXDrawables that reside on the same screen share the 351 same multisample subrectangle. There is at most one shared 352 multisample subrectangle per screen. 353 354GLX Protocol 355 356 A new GL rendering command is added. The following command is sent 357 to the server as part of a glXRender request: 358 359 MultisampleSubRectPosSGIS 360 2 12 rendering command length 361 2 ?? rendering command opcode 362 4 INT32 x 363 4 INT32 y 364 365 Two new property type/property value pairs are included in the 366 property list of each visual returned by glXGetVisualConfigs 367 request. The property type/property value pairs are encoded as. 368 369 4 ENUM property type 370 0x8026 GLX_MULTISAMPLE_SUB_RECT_WIDTH 371 4 INT32 property value 372 373 4 ENUM property type 374 0x8027 GLX_MULTISAMPLE_SUB_RECT_HEIGHT 375 4 INT32 property value 376 377Errors 378 379 None 380 381New State 382 383 Get Value Get Command Type Initial Value Attribute 384 --------- ----------- ----- ------------- --------- 385 MULTISAMPLE_SUB_RECT_POSITION_SGIS GetIntegerv 2 x Z 0,0 multisample 386 387New Implementation Dependent State 388 389 Get Value Get Command Type Minimum Value 390 --------- ----------- ----- ------------- 391 MULTISAMPLE_SUB_RECT_DIMS_SGIS GetIntegerv 2 x Z 0,0 392 393