1Name 2 3 NV_pixel_data_range 4 5Name Strings 6 7 GL_NV_pixel_data_range 8 9Contact 10 11 Matt Craighead, NVIDIA Corporation (mcraighead 'at' nvidia.com) 12 13Notice 14 15 Copyright NVIDIA Corporation, 2000, 2001, 2002. 16 17IP Status 18 19 NVIDIA Proprietary. 20 21Status 22 23 Shipping (version 1.0) 24 25Version 26 27 NVIDIA Date: November 7, 2002 (version 1.0) 28 29Number 30 31 284 32 33Dependencies 34 35 Written based on the wording of the OpenGL 1.3 specification. 36 37 If this extension is implemented, the WGL or GLX memory allocator 38 interface specified in NV_vertex_array_range must also be 39 implemented. Please refer to the NV_vertex_array_range specification 40 for further information on this interface. 41 42Overview 43 44 The vertex array range extension is intended to improve the 45 efficiency of OpenGL vertex arrays. OpenGL vertex arrays' coherency 46 model and ability to access memory from arbitrary locations in memory 47 prevented implementations from using DMA (Direct Memory Access) 48 operations. 49 50 Many image-intensive applications, such as those that use dynamically 51 generated textures, face similar problems. These applications would 52 like to be able to sustain throughputs of hundreds of millions of 53 pixels per second through DrawPixels and hundreds of millions of 54 texels per second through TexSubImage. 55 56 However, the same restrictions that limited vertex throughput also 57 limit pixel throughput. 58 59 By the time that any pixel operation that reads data from user memory 60 returns, OpenGL requires that it must be safe for the application to 61 start using that memory for a different purpose. This coherency 62 model prevents asynchronous DMA transfers directly out of the user's 63 buffer. 64 65 There are also no restrictions on the pointer provided to pixel 66 operations or on the size of the data. To facilitate DMA 67 implementations, the driver needs to know in advance what region of 68 the address space to lock down. 69 70 Vertex arrays faced both of these restrictions already, but pixel 71 operations have one additional complicating factor -- they are 72 bidirectional. Vertex array data is always being transfered from the 73 application to the driver and the HW, whereas pixel operations 74 sometimes transfer data to the application from the driver and HW. 75 Note that the types of memory that are suitable for DMA for reading 76 and writing purposes are often different. For example, on many PC 77 platforms, DMA pulling is best accomplished with write-combined 78 (uncached) AGP memory, while pushing data should use cached memory so 79 that the application can read the data efficiently once it has been 80 read back over the AGP bus. 81 82 This extension defines an API where an application can specify two 83 pixel data ranges, which are analogous to vertex array ranges, except 84 that one is for operations where the application is reading data 85 (e.g. glReadPixels) and one is for operations where the application 86 is writing data (e.g. glDrawPixels, glTexSubImage2D, etc.). Each 87 pixel data range has a pointer to its start and a length in bytes. 88 89 When the pixel data range is enabled, and if the pointer specified 90 as the argument to a pixel operation is inside the corresponding 91 pixel data range, the implementation may choose to asynchronously 92 pull data from the pixel data range or push data to the pixel data 93 range. Data pulled from outside the pixel data range is undefined, 94 while pushing data to outside the pixel data range produces undefined 95 results. 96 97 The application may synchronize with the hardware in one of two ways: 98 by flushing the pixel data range (or causing an implicit flush) or by 99 using the NV_fence extension to insert fences in the command stream. 100 101Issues 102 103 * The vertex array range extension required that all active vertex 104 arrays must be located inside the vertex array range. Should 105 this extension be equally strict? 106 107 RESOLVED: No, because a user may want to use the pixel data range 108 for one type of operation (say, texture downloads) but still be 109 able to use standard non-PDR pixel operations for everything 110 else. Requiring that apps disable PDR every time such an 111 operation occurs would be burdensome and make it difficult to 112 integrate this extension into a larger app with minimal changes. 113 So, for each pixel operation, we will look at the pointer 114 provided by the application. If it's inside the PDR, the PDR 115 rules apply, and if it's not inside the PDR, it's a standard GL 116 pixel operation, even if some of the data is actually inside the 117 PDR. 118 119 * Reads and writes may require different types of memory. How do 120 we handle this? 121 122 RESOLVED: The allocator interface already provides the ability to 123 specify different read and write frequencies. A buffer for a 124 write PDR should probably be allocated with a high write 125 frequency and low read frequency, while a read PDR's buffer 126 should have a low write and high read frequency. 127 128 Having two PDRs is essential because a single application may 129 want to perform both asynchronous reads and writes 130 simultaneously. 131 132 * What happens if a PDR pixel operation pulls data from a location 133 outside the PDR? 134 135 RESOLVED: The data pulled is undefined, and program termination 136 may result. 137 138 * What happens if a PDR pixel operation pushes data to a location 139 outside the PDR? 140 141 RESOLVED: The contents of that memory location become undefined, 142 and program termination may result. 143 144 * What happens if the hardware can't support the operation? 145 146 RESOLVED: The operation may be slow, because we may need to, for 147 example, read the pixel data out of uncached memory with the CPU, 148 but it should still work. So this should never be a problem; in 149 fact, it means that a basic implementation that accelerates only, 150 say, one operation is quite trivial. 151 152 * Should there be any limitations to what operations should be 153 supported? 154 155 RESOLVED: No, in theory any pixel operation that accesses a 156 user's buffer can work with PDR. This includes Bitmap, 157 PolygonStipple, GetTexImage, ConvolutionFilter2D, etc. Many are 158 unlikely to be accelerated, but there is no reason to place 159 arbitrary restrictions. A list of possibly supported operations 160 is provided for OpenGL 1.2.1 with ARB_imaging support and for all 161 the extensions currently supported by NVIDIA. Developers should 162 carefully read the Implementation Details provided by their 163 vendor before using the extension. 164 165 * Should PixelMap and GetPixelMap be supported? 166 167 RESOLVED: Yes. They're not really pixel path operations, but, 168 again, there is no good reason to omit operations, and they _are_ 169 operations that pass around big chunks of pixel-related data. If 170 we support PolygonStipple, surely we should support this. 171 172 * Can the PDRs and the VAR overlap and/or be the same buffer? 173 174 RESOLVED: Yes. In fact, it is expected that one of the preferred 175 modes of usage for this extension will be to use the same AGP 176 buffer for both the write PDR and the VAR, so it can be used for 177 both dynamic texturing and dynamic geometry. 178 179 * Can video memory buffers be used? 180 181 RESOLVED: Yes, assuming the implementation supports using them 182 for PDR. On systems with AGP Fast Writes, this may be 183 interesting in some cases. Another possible use for this is to 184 treat a video memory buffer as an offscreen surface, where 185 DrawPixels can be thought of as a blit from offscreen memory to 186 a GL surface, and ReadPixels can be thought of as a blit from a 187 GL surface to offscreen memory. This technique should be used 188 with caution, because there are other alternatives, such as 189 pbuffers, aux buffers, and even textures. 190 191 * Do we want to support more than one read and one write PDR? 192 193 RESOLVED: No, but I could imagine uses for it. For example, an 194 app could use two system memory buffers (one read, one write PDR) 195 and a single video memory buffer (both read and write). Do we 196 need a scheme where an unlimited number of PDR buffers can be 197 specified? Ugh. I hope not. I can't think of a good reason to 198 use more than 3 buffers, and even that is stretching it. 199 200 * Do we want a separate enable for both the read and write PDR? 201 202 RESOLVED: Yes. In theory, they are completely independent, and 203 we should treat them as such. 204 205 * Is there an equivalent to the VAR validity check? 206 207 RESOLVED: No. When a vertex array call occurs, all the vertex 208 array state is already set. We can know in advance whether all 209 the pointers, strides, etc. are set up in a satisfactory way. 210 However, for a pixel operation, much of the state is provided on 211 the same function call that performs the operation. For example, 212 the pixel format of the data may need to match that of the 213 framebuffer. We can't know this without looking at the format 214 and type arguments. 215 216 An alternative might be some sort of "proxy" mechanism for pixel 217 operations, but this seems to be very complicated. 218 219 * Do we want a more generalized API? What stops us from needing a 220 DMA extension for every single conceivable use in the future? 221 222 RESOLVED: No, this is good enough. Since new extensions will 223 probably require new semantics anyhow, we'll just live with that. 224 Maybe if the ARB wants to create a more generic "DMA" extension, 225 these issues can be revisited. 226 227 * How do applications synchronize with the hardware? 228 229 RESOLVED: A new command, FlushPixelDataRangeNV, is provided, that 230 is analogous to FlushVertexArrayRangeNV. Applications can also 231 use the Finish command. The NV_fence extension is best for 232 applications that need fine-grained synchronization. 233 234 * Should enabling or disabling a PDR induce an implicit PDR flush? 235 236 RESOLVED: No. In the VAR extension, enabling and disabling the 237 VAR does induce a VAR flush, but this has proven to be more 238 problematic than helpful, because it makes it much more difficult 239 to switch between VAR and non-VAR rendering; the VAR2 extension 240 lifts this restriction, and there is no reason to get this wrong 241 a second time. 242 243 The PDR extension does not suffer from the problem of enabling 244 and disabling frequently, because non-PDR operations are 245 permitted simply by providing a pointer outside of the PDR, but 246 there is no clear reason why the enable or disable should cause 247 a quite unnecessary PDR flush. 248 249 * Should this state push/pop? 250 251 RESOLVED: Yes, but via a Push/PopClientAttrib and the 252 GL_CLIENT_PIXEL_STORE_BIT bit. Although this is heavyweight 253 state, VAR also allowed push/pop. It does fit nicely into an 254 existing category, too. 255 256 * Should making another context current cause a PDR flush? 257 258 RESOLVED: No. There's no fundamental reason it should. Note 259 that apps should be careful to not free their memory until the 260 hardware is not using it... note also that this decision is 261 inconsistent with VAR, which did guarantee a flush here. 262 263 * Is the read PDR guaranteed to give you either old or new values, 264 or is it truly undefined? 265 266 RESOLVED: Undefined. This may ease implementation constraints 267 slightly. Apps must not rely at all on the contents of the 268 region where the readback is occurring until it is known to be 269 finished. 270 271 An example of how an implementation might conceivably require 272 this is as follows. Suppose that a piece of hardware, for some 273 reason, can only write full 32-byte chunks of data. Any bytes 274 that were supposed to be unwritten are in fact trashed by the 275 hardware, filled with garbage. By careful fixups (read the 276 contents before the operation, restore when done), the driver may 277 be able to hide this fact, but a requirement that either new or 278 old data must show up would be violated. 279 280 Or, more trivially, you might implement certain pixel operations 281 as an in-place postprocess on the returned data. 282 283 It is not anticipated that NVIDIA implementations will need this 284 flexibility, but it is nevertheless provided. 285 286 * How should an application allocate its PDR memory? 287 288 The app should use wglAllocateMemoryNV, even for a read PDR in 289 system memory. Using malloc may result in suboptimal 290 performance, because the driver will not be able to choose an 291 optimal memory type. For ReadPixels to system memory, you might 292 set a read frequency of 1.0, a write frequency of 0.0, and a 293 priority of 1.0. The driver might allocate PCI memory, or 294 physically contiguous PCI memory, or cachable AGP memory, all 295 depending on the performance characteristics of the device. 296 While memory from malloc will work, it does not allow the driver 297 to make these decisions, and it will certainly never give you AGP 298 memory. 299 300 Write PDR memory for purposes of streaming textures, etc. works 301 exactly the same as VAR memory for streaming vertices. You can, 302 and in fact are encouraged to, use the same circular buffer for 303 both vertices and textures. 304 305 If you have different needs (not just streaming textures or 306 asynchronous readbacks), you may want your pixel data in video 307 memory. 308 309New Procedures and Functions 310 311 void PixelDataRangeNV(enum target, sizei length, void *pointer) 312 void FlushPixelDataRangeNV(enum target) 313 314New Tokens 315 316 Accepted by the <target> parameter of PixelDataRangeNV and 317 FlushPixelDataRangeNV, and by the <cap> parameter of 318 EnableClientState, DisableClientState, and IsEnabled: 319 320 WRITE_PIXEL_DATA_RANGE_NV 0x8878 321 READ_PIXEL_DATA_RANGE_NV 0x8879 322 323 Accepted by the <pname> parameter of GetBooleanv, GetIntegerv, 324 GetFloatv, and GetDoublev: 325 326 WRITE_PIXEL_DATA_RANGE_LENGTH_NV 0x887A 327 READ_PIXEL_DATA_RANGE_LENGTH_NV 0x887B 328 329 Accepted by the <pname> parameter of GetPointerv: 330 331 WRITE_PIXEL_DATA_RANGE_POINTER_NV 0x887C 332 READ_PIXEL_DATA_RANGE_POINTER_NV 0x887D 333 334Additions to Chapter 2 of the OpenGL 1.3 Specification (OpenGL Operation) 335 336 None. 337 338Additions to Chapter 3 of the OpenGL 1.3 Specification (Rasterization) 339 340 341 Add new section to Section 3.6, "Pixel Rectangles", on page 113: 342 343 "3.6.7 Write Pixel Data Range Operation 344 345 Applications can enhance the performance of DrawPixels and other 346 commands that transfer large amounts of pixel data by using a pixel 347 data range. The command 348 349 void PixelDataRangeNV(enum target, sizei length, void *pointer) 350 351 specifies one of the current pixel data ranges. When the write pixel 352 data range is enabled and valid, pixel data transfers from within 353 the pixel data range are potentially faster. The pixel data range is 354 a contiguous region of (virtual) address space for placing pixel 355 data. The "pointer" parameter is a pointer to the base of the pixel 356 data range. The "length" pointer is the length of the pixel data 357 range in basic machine units (typically unsigned bytes). For the 358 write pixel data range, "target" must be WRITE_PIXEL_DATA_RANGE_NV. 359 360 The pixel data range address space region extends from "pointer" 361 to "pointer + length - 1" inclusive. 362 363 There is some system burden associated with establishing a pixel data 364 range (typically, the memory range must be locked down). If either 365 the pixel data range pointer or size is set to zero, the previously 366 established pixel data range is released (typically, unlocking the 367 memory). 368 369 The pixel data range may not be established for operating system 370 dependent reasons, and therefore, not valid. Reasons that a pixel 371 data range cannot be established include spanning different memory 372 types, the memory could not be locked down, alignment restrictions 373 are not met, etc. 374 375 The write pixel data range is enabled or disabled by calling 376 EnableClientState or DisableClientState with the symbolic constant 377 WRITE_PIXEL_DATA_RANGE_NV. 378 379 The write pixel data range is valid when the following conditions are 380 met: 381 382 o WRITE_PIXEL_DATA_RANGE_NV is enabled. 383 384 o PixelDataRangeNV has been called with a non-null pointer and 385 non-zero size, for target WRITE_PIXEL_DATA_RANGE_NV. 386 387 o The write pixel data range has been established. 388 389 o An implementation-dependent validity check based on the 390 pointer alignment, size, and underlying memory type of the 391 write pixel data range region of memory. 392 393 Otherwise, the write pixel data range is not valid. 394 395 The commands, such as DrawPixels, that may be made faster by the 396 write pixel data range are listed in the Appendix. 397 398 When the write pixel data range is valid, an attempt will be made to 399 accelerate these commands if and only if the data pointer argument to 400 the command lies within the write pixel data range. No attempt will 401 be made to accelerate commands whose base pointer is outside this 402 range. Accessing data outside the write pixel data range when the 403 base pointer lies within the range and the range is valid will 404 produce undefined results and may cause program termination. 405 406 The standard OpenGL pixel data coherency model requires that pixel 407 data be extracted from the user's buffer immediately, before the 408 pixel command returns. When the write pixel data range is valid, 409 this model is relaxed so that changes made to pixel data until the 410 next "write pixel data range flush" may affect pixel commands in non- 411 sequential ways. That is, a call to a pixel command that precedes 412 a change to pixel data (without an intervening "write pixel data 413 range flush") may access the changed data; though a call to a pixel 414 command following a change to pixel data must always access the 415 changed data, and never the original data. 416 417 A 'write pixel data range flush' occurs when one of the following 418 operations occur: 419 420 o Finish returns. 421 422 o FlushPixelDataRangeNV (with target WRITE_PIXEL_DATA_RANGE_NV) 423 returns. 424 425 o PixelDataRangeNV (with target WRITE_PIXEL_DATA_RANGE_NV) 426 returns. 427 428 The client state required to implement the write pixel data range 429 consists of an enable bit, a memory pointer, and an integer size. 430 431 If the memory mapping of pages within the pixel data range changes, 432 using the pixel data range has undefined effects. To ensure that the 433 pixel data range reflects the address space's current state, the 434 application is responsible for calling PixelDataRange again after any 435 memory mapping changes within the pixel data range." 436 437Additions to Chapter 4 of the OpenGL 1.3 Specification (Per-Fragment 438Operations and the Frame Buffer) 439 440 Add new section to Section 4.3, "Pixel Draw/Read State", on page 180: 441 442 "4.3.5 Read Pixel Data Range Operation 443 444 The read pixel data range is similar to the write pixel data range 445 (see section 3.6.7), but is specified with PixelDataRangeNV with a 446 target READ_PIXEL_DATA_RANGE_NV. It is exactly analogous to the 447 write pixel data range, but applies to commands where OpenGL returns 448 pixel data to the caller, such as ReadPixels. The list of commands 449 to which the read pixel data range applies can be found in the 450 Appendix. 451 452 Validity checks and flushes of the read pixel data range behave in a 453 manner exactly analogous to those of the write pixel data range, 454 though any implementation-dependent checks may differ between the two 455 types of pixel data range. 456 457 The standard OpenGL pixel data coherency model requires that pixel 458 data be written into the user's buffer immediately, before the 459 pixel command returns. When the read pixel data range is valid, 460 this model is relaxed so that this data may not necessarily be 461 available until the next "read pixel data range flush". Until such 462 point in time, an attempt to read the buffer returns undefined 463 values. 464 465 If both the read and write pixel data ranges are valid and overlap, 466 then all operations involving both in the same thread are 467 automatically synchronized. That is, the write pixel data range 468 operation will automatically wait for any pending read pixel data 469 range results to become available before attempting to retrieve them. 470 However, if the operations are performed from different threads, the 471 user is responsible for all such synchronization. 472 473 Read pixel data range operations are also synchronized with vertex 474 array range operations in the same way. 475 476 The client state required to implement the read pixel data range 477 consists of an enable bit, a memory pointer, and an integer size." 478 479Additions to Chapter 5 of the OpenGL 1.3 Specification (Special Functions) 480 481 Add the following to the end of Section 5.4 "Display Lists" (page 482 179): 483 484 "PixelDataRangeNV and FlushPixelDataRangeNV are not complied into 485 display lists but are executed immediately. 486 487 If a display list is compiled while WRITE_PIXEL_DATA_RANGE_NV is 488 enabled, all commands affected by that enable are accumulated into a 489 display list as if WRITE_PIXEL_DATA_RANGE_NV is disabled. 490 491 The state of the read pixel data range does not affect display list 492 compilation, because those commands that might be accelerated by a 493 read pixel data range are commands that are executed immediately 494 rather than being compiled into a display list (ReadPixels and 495 GetTexImage, for example)." 496 497Additions to Chapter 6 of the OpenGL 1.3 Specification (State and 498State Requests) 499 500 None. 501 502Additions to the GLX Specification 503 504 "OpenGL implementations using GLX indirect rendering should fail to 505 set up the pixel data range and will not accelerate any pixel 506 operations using it. Additionally, glXAllocateMemoryNV always fails 507 to allocate memory (returns NULL) when used with an indirect 508 rendering context." 509 510GLX Protocol 511 512 None 513 514Errors 515 516 INVALID_OPERATION is generated if PixelDataRangeNV or 517 FlushPixelDataRangeNV is called between the execution of Begin and 518 the corresponding execution of End. 519 520 INVALID_ENUM is generated if PixelDataRangeNV or 521 FlushPixelDataRangeNV is called when target is not 522 WRITE_PIXEL_DATA_RANGE_NV or READ_PIXEL_DATA_RANGE_NV. 523 524 INVALID_VALUE is generated if PixelDataRangeNV is called when length 525 is negative. 526 527New State 528 529 Initial 530 Get Value Get Command Type Value Attrib 531 --------- ----------- ---- ------- ------ 532 WRITE_PIXEL_DATA_RANGE_NV IsEnabled B False pixel-store 533 READ_PIXEL_DATA_RANGE_NV IsEnabled B False pixel-store 534 WRITE_PIXEL_DATA_RANGE_POINTER_NV GetPointerv Z+ 0 pixel-store 535 READ_PIXEL_DATA_RANGE_POINTER_NV GetPointerv Z+ 0 pixel-store 536 WRITE_PIXEL_DATA_RANGE_LENGTH_NV GetIntegerv Z+ 0 pixel-store 537 READ_PIXEL_DATA_RANGE_LENGTH_NV GetIntegerv Z+ 0 pixel-store 538 539Appendix: Operations Supported 540 541 In unextended OpenGL 1.3 with ARB_imaging support, the following 542 commands may take advantage of the write PDR: 543 544 glBitmap 545 glColorSubTable 546 glColorTable 547 glCompressedTexImage1D 548 glCompressedTexImage2D 549 glCompressedTexImage3D 550 glCompressedTexSubImage1D 551 glCompressedTexSubImage2D 552 glCompressedTexSubImage3D 553 glConvolutionFilter1D 554 glConvolutionFilter2D 555 glDrawPixels 556 glPixelMapfv 557 glPixelMapuiv 558 glPixelMapusv 559 glPolygonStipple 560 glSeparableFilter2D 561 glTexImage1D 562 glTexImage2D 563 glTexImage3D 564 glTexSubImage1D 565 glTexSubImage2D 566 glTexSubImage3D 567 568 In unextended OpenGL 1.3 with ARB_imaging support, the following 569 commands may take advantage of the read PDR: 570 571 glGetColorTable 572 glGetCompressedTexImage 573 glGetConvolutionFilter 574 glGetHistogram 575 glGetMinmax 576 glGetPixelMapfv 577 glGetPixelMapuiv 578 glGetPixelMapusv 579 glGetPolygonStipple 580 glGetSeparableFilter 581 glGetTexImage 582 glReadPixels 583 584 No other extensions shipping in the NVIDIA OpenGL drivers add any 585 other new commands that may take advantage of this extension, 586 although in a few cases there are new commands that alias to other 587 commands that may be accelerated by this extension. These commands 588 are: 589 590 glCompressedTexImage1DARB (ARB_texture_compression) 591 glCompressedTexImage2DARB (ARB_texture_compression) 592 glCompressedTexImage3DARB (ARB_texture_compression) 593 glCompressedTexSubImage1DARB (ARB_texture_compression) 594 glCompressedTexSubImage2DARB (ARB_texture_compression) 595 glCompressedTexSubImage3DARB (ARB_texture_compression) 596 glColorSubTableEXT (EXT_paletted_texture) 597 glColorTableEXT (EXT_paletted_texture) 598 glGetCompressedTexImageARB (ARB_texture_compression) 599 glTexImage3DEXT (EXT_texture3D) 600 glTexSubImage3DEXT (EXT_texture3D) 601 602NVIDIA Implementation Details 603 604 In the Release 40 OpenGL drivers, the NV_pixel_data_range extension 605 is supported on all GeForce/Quadro-class hardware. The following 606 commands may potentially be accelerated in this release: 607 608 glReadPixels 609 glTexImage2D 610 glTexSubImage2D 611 glCompressedTexImage2D 612 glCompressedTexImage3D 613 glCompressedTexSubImage2D 614 615 The following type/format/buffer format sets are accelerated for 616 glReadPixels: 617 618 type format buffer format 619 ----------------------------------------------------------------------------------------------- 620 GL_UNSIGNED_SHORT_5_6_5 GL_RGB 16-bit color (PCs only -- Macs use 555) 621 GL_UNSIGNED_INT_8_8_8_8_REV GL_BGRA 32-bit color w/ alpha 622 GL_UNSIGNED_BYTE GL_BGRA 32-bit color w/ alpha (little endian only) 623 GL_UNSIGNED_SHORT GL_DEPTH_COMPONENT 16-bit depth 624 GL_UNSIGNED_INT_24_8_NV GL_DEPTH_STENCIL_NV 24-bit depth, 8-bit stencil 625 626 The following internalformat/type/format sets are accelerated for 627 glTex[Sub]Image2D: 628 629 internalformat type format 630 ------------------------------------------------------------------------------- 631 GL_RGB5 GL_UNSIGNED_SHORT_5_6_5 GL_RGB 632 GL_RGB8 GL_UNSIGNED_INT_8_8_8_8_REV GL_BGRA 633 GL_RGBA4 GL_UNSIGNED_SHORT_4_4_4_4_REV GL_BGRA 634 GL_RGB5_A1 GL_UNSIGNED_SHORT_1_5_5_5_REV GL_BGRA 635 GL_RGBA8 GL_UNSIGNED_INT_8_8_8_8_REV GL_BGRA 636 637 GL_DEPTH_COMPONENT16_SGIX GL_UNSIGNED_SHORT GL_DEPTH_COMPONENT 638 GL_DEPTH_COMPONENT24_SGIX GL_UNSIGNED_INT_24_8_NV GL_DEPTH_STENCIL_NV 639 640 The following internalformat/type/format sets will be accelerated for 641 glTex[Sub]Image2D on little-endian machines only: 642 643 internalformat type format 644 ------------------------------------------------------------------------------- 645 GL_LUMINANCE8_ALPHA8 GL_UNSIGNED_BYTE GL_LUMINANCE_ALPHA 646 647 GL_RGB8 GL_UNSIGNED_BYTE GL_BGRA 648 GL_RGBA8 GL_UNSIGNED_BYTE GL_BGRA 649 650 All compressed texture formats are supported for 651 glCompressedTex[Sub]Image[2,3]D. 652 653 The following restrictions apply to all commands: 654 - No pixel transfer operations of any kind may be in use. 655 - The base address of the PDR must be aligned to a 32-byte boundary. 656 - The data pointer must be aligned to boundaries of the size of one 657 group of pixels. For example, GL_UNSIGNED_SHORT_5_6_5 data must 658 be aligned to 2-byte boundaries, GL_UNSIGNED_INT_24_8_NV data must 659 be aligned to 4-byte boundaries, and GL_BGRA/GL_UNSIGNED_BYTE data 660 must be aligned to 4-byte boundaries (not 1-byte boundaries). 661 Compressed texture data must be aligned to a block boundary. 662 663 No additional restrictions apply to glReadPixels or 664 glCompressedTex[Sub]Image[2,3]D. 665 666 The following additional restrictions apply to glTex[Sub]Image2D: 667 - The texture must fit in video memory. 668 - The texture must have a border size of zero. 669 - The stride (in bytes) between two lines of source data must not 670 exceed 65535. 671 - For non-rectangle textures, the width and height of the destination 672 mipmap level must not exceed 2048, nor be below 2; also, the 673 destination mipmap level must not be 2x2 (for 16-bit textures) or 674 2x2, 4x2, or 2x4 (for 8-bit textures). 675 676 Future software releases may increase the number of accelerated 677 commands and the number of accelerated data formats for each command. 678 Note also that although all of the formats and commands listed are 679 guaranteed to be accelerated, there may be limitations in the actual 680 implementation not as strict as those stated here; for example, some 681 data formats not listed here may turn out to be accelerated. 682 However, it is highly recommended that you stick to the formats and 683 commands listed in this section. In cases where actual restrictions 684 are less strict, future implementations may very well enforce the 685 listed restriction. 686 687 It is also possible that some of these restrictions may become _more_ 688 strict on future chips; though at present no such additional 689 restrictions are known to be likely. Such restrictions would likely 690 take the form of more stringent pitch or alignment restrictions, if 691 they proved to be necessary. 692 693 In practice, you should expect that several of these restrictions 694 will be more lenient in a future release. 695 696Revision History 697 698 November 7, 2002 - Updated implementation details section with most 699 up-to-date rules on PDR usage. Lifted rule that texture downloads 700 must be 2046 pixels in size or smaller. Removed support for 8-bit 701 texture downloads. Increased max TexSubImage pitch to 65535 from 702 8191. 703