| Name |
| |
| NV_pixel_data_range |
| |
| Name Strings |
| |
| GL_NV_pixel_data_range |
| |
| Contact |
| |
| Matt Craighead, NVIDIA Corporation (mcraighead 'at' nvidia.com) |
| |
| Notice |
| |
| Copyright NVIDIA Corporation, 2000, 2001, 2002. |
| |
| IP Status |
| |
| NVIDIA Proprietary. |
| |
| Status |
| |
| Shipping (version 1.0) |
| |
| Version |
| |
| NVIDIA Date: November 7, 2002 (version 1.0) |
| |
| Number |
| |
| 284 |
| |
| Dependencies |
| |
| Written based on the wording of the OpenGL 1.3 specification. |
| |
| If this extension is implemented, the WGL or GLX memory allocator |
| interface specified in NV_vertex_array_range must also be |
| implemented. Please refer to the NV_vertex_array_range specification |
| for further information on this interface. |
| |
| Overview |
| |
| The vertex array range extension is intended to improve the |
| efficiency of OpenGL vertex arrays. OpenGL vertex arrays' coherency |
| model and ability to access memory from arbitrary locations in memory |
| prevented implementations from using DMA (Direct Memory Access) |
| operations. |
| |
| Many image-intensive applications, such as those that use dynamically |
| generated textures, face similar problems. These applications would |
| like to be able to sustain throughputs of hundreds of millions of |
| pixels per second through DrawPixels and hundreds of millions of |
| texels per second through TexSubImage. |
| |
| However, the same restrictions that limited vertex throughput also |
| limit pixel throughput. |
| |
| By the time that any pixel operation that reads data from user memory |
| returns, OpenGL requires that it must be safe for the application to |
| start using that memory for a different purpose. This coherency |
| model prevents asynchronous DMA transfers directly out of the user's |
| buffer. |
| |
| There are also no restrictions on the pointer provided to pixel |
| operations or on the size of the data. To facilitate DMA |
| implementations, the driver needs to know in advance what region of |
| the address space to lock down. |
| |
| Vertex arrays faced both of these restrictions already, but pixel |
| operations have one additional complicating factor -- they are |
| bidirectional. Vertex array data is always being transfered from the |
| application to the driver and the HW, whereas pixel operations |
| sometimes transfer data to the application from the driver and HW. |
| Note that the types of memory that are suitable for DMA for reading |
| and writing purposes are often different. For example, on many PC |
| platforms, DMA pulling is best accomplished with write-combined |
| (uncached) AGP memory, while pushing data should use cached memory so |
| that the application can read the data efficiently once it has been |
| read back over the AGP bus. |
| |
| This extension defines an API where an application can specify two |
| pixel data ranges, which are analogous to vertex array ranges, except |
| that one is for operations where the application is reading data |
| (e.g. glReadPixels) and one is for operations where the application |
| is writing data (e.g. glDrawPixels, glTexSubImage2D, etc.). Each |
| pixel data range has a pointer to its start and a length in bytes. |
| |
| When the pixel data range is enabled, and if the pointer specified |
| as the argument to a pixel operation is inside the corresponding |
| pixel data range, the implementation may choose to asynchronously |
| pull data from the pixel data range or push data to the pixel data |
| range. Data pulled from outside the pixel data range is undefined, |
| while pushing data to outside the pixel data range produces undefined |
| results. |
| |
| The application may synchronize with the hardware in one of two ways: |
| by flushing the pixel data range (or causing an implicit flush) or by |
| using the NV_fence extension to insert fences in the command stream. |
| |
| Issues |
| |
| * The vertex array range extension required that all active vertex |
| arrays must be located inside the vertex array range. Should |
| this extension be equally strict? |
| |
| RESOLVED: No, because a user may want to use the pixel data range |
| for one type of operation (say, texture downloads) but still be |
| able to use standard non-PDR pixel operations for everything |
| else. Requiring that apps disable PDR every time such an |
| operation occurs would be burdensome and make it difficult to |
| integrate this extension into a larger app with minimal changes. |
| So, for each pixel operation, we will look at the pointer |
| provided by the application. If it's inside the PDR, the PDR |
| rules apply, and if it's not inside the PDR, it's a standard GL |
| pixel operation, even if some of the data is actually inside the |
| PDR. |
| |
| * Reads and writes may require different types of memory. How do |
| we handle this? |
| |
| RESOLVED: The allocator interface already provides the ability to |
| specify different read and write frequencies. A buffer for a |
| write PDR should probably be allocated with a high write |
| frequency and low read frequency, while a read PDR's buffer |
| should have a low write and high read frequency. |
| |
| Having two PDRs is essential because a single application may |
| want to perform both asynchronous reads and writes |
| simultaneously. |
| |
| * What happens if a PDR pixel operation pulls data from a location |
| outside the PDR? |
| |
| RESOLVED: The data pulled is undefined, and program termination |
| may result. |
| |
| * What happens if a PDR pixel operation pushes data to a location |
| outside the PDR? |
| |
| RESOLVED: The contents of that memory location become undefined, |
| and program termination may result. |
| |
| * What happens if the hardware can't support the operation? |
| |
| RESOLVED: The operation may be slow, because we may need to, for |
| example, read the pixel data out of uncached memory with the CPU, |
| but it should still work. So this should never be a problem; in |
| fact, it means that a basic implementation that accelerates only, |
| say, one operation is quite trivial. |
| |
| * Should there be any limitations to what operations should be |
| supported? |
| |
| RESOLVED: No, in theory any pixel operation that accesses a |
| user's buffer can work with PDR. This includes Bitmap, |
| PolygonStipple, GetTexImage, ConvolutionFilter2D, etc. Many are |
| unlikely to be accelerated, but there is no reason to place |
| arbitrary restrictions. A list of possibly supported operations |
| is provided for OpenGL 1.2.1 with ARB_imaging support and for all |
| the extensions currently supported by NVIDIA. Developers should |
| carefully read the Implementation Details provided by their |
| vendor before using the extension. |
| |
| * Should PixelMap and GetPixelMap be supported? |
| |
| RESOLVED: Yes. They're not really pixel path operations, but, |
| again, there is no good reason to omit operations, and they _are_ |
| operations that pass around big chunks of pixel-related data. If |
| we support PolygonStipple, surely we should support this. |
| |
| * Can the PDRs and the VAR overlap and/or be the same buffer? |
| |
| RESOLVED: Yes. In fact, it is expected that one of the preferred |
| modes of usage for this extension will be to use the same AGP |
| buffer for both the write PDR and the VAR, so it can be used for |
| both dynamic texturing and dynamic geometry. |
| |
| * Can video memory buffers be used? |
| |
| RESOLVED: Yes, assuming the implementation supports using them |
| for PDR. On systems with AGP Fast Writes, this may be |
| interesting in some cases. Another possible use for this is to |
| treat a video memory buffer as an offscreen surface, where |
| DrawPixels can be thought of as a blit from offscreen memory to |
| a GL surface, and ReadPixels can be thought of as a blit from a |
| GL surface to offscreen memory. This technique should be used |
| with caution, because there are other alternatives, such as |
| pbuffers, aux buffers, and even textures. |
| |
| * Do we want to support more than one read and one write PDR? |
| |
| RESOLVED: No, but I could imagine uses for it. For example, an |
| app could use two system memory buffers (one read, one write PDR) |
| and a single video memory buffer (both read and write). Do we |
| need a scheme where an unlimited number of PDR buffers can be |
| specified? Ugh. I hope not. I can't think of a good reason to |
| use more than 3 buffers, and even that is stretching it. |
| |
| * Do we want a separate enable for both the read and write PDR? |
| |
| RESOLVED: Yes. In theory, they are completely independent, and |
| we should treat them as such. |
| |
| * Is there an equivalent to the VAR validity check? |
| |
| RESOLVED: No. When a vertex array call occurs, all the vertex |
| array state is already set. We can know in advance whether all |
| the pointers, strides, etc. are set up in a satisfactory way. |
| However, for a pixel operation, much of the state is provided on |
| the same function call that performs the operation. For example, |
| the pixel format of the data may need to match that of the |
| framebuffer. We can't know this without looking at the format |
| and type arguments. |
| |
| An alternative might be some sort of "proxy" mechanism for pixel |
| operations, but this seems to be very complicated. |
| |
| * Do we want a more generalized API? What stops us from needing a |
| DMA extension for every single conceivable use in the future? |
| |
| RESOLVED: No, this is good enough. Since new extensions will |
| probably require new semantics anyhow, we'll just live with that. |
| Maybe if the ARB wants to create a more generic "DMA" extension, |
| these issues can be revisited. |
| |
| * How do applications synchronize with the hardware? |
| |
| RESOLVED: A new command, FlushPixelDataRangeNV, is provided, that |
| is analogous to FlushVertexArrayRangeNV. Applications can also |
| use the Finish command. The NV_fence extension is best for |
| applications that need fine-grained synchronization. |
| |
| * Should enabling or disabling a PDR induce an implicit PDR flush? |
| |
| RESOLVED: No. In the VAR extension, enabling and disabling the |
| VAR does induce a VAR flush, but this has proven to be more |
| problematic than helpful, because it makes it much more difficult |
| to switch between VAR and non-VAR rendering; the VAR2 extension |
| lifts this restriction, and there is no reason to get this wrong |
| a second time. |
| |
| The PDR extension does not suffer from the problem of enabling |
| and disabling frequently, because non-PDR operations are |
| permitted simply by providing a pointer outside of the PDR, but |
| there is no clear reason why the enable or disable should cause |
| a quite unnecessary PDR flush. |
| |
| * Should this state push/pop? |
| |
| RESOLVED: Yes, but via a Push/PopClientAttrib and the |
| GL_CLIENT_PIXEL_STORE_BIT bit. Although this is heavyweight |
| state, VAR also allowed push/pop. It does fit nicely into an |
| existing category, too. |
| |
| * Should making another context current cause a PDR flush? |
| |
| RESOLVED: No. There's no fundamental reason it should. Note |
| that apps should be careful to not free their memory until the |
| hardware is not using it... note also that this decision is |
| inconsistent with VAR, which did guarantee a flush here. |
| |
| * Is the read PDR guaranteed to give you either old or new values, |
| or is it truly undefined? |
| |
| RESOLVED: Undefined. This may ease implementation constraints |
| slightly. Apps must not rely at all on the contents of the |
| region where the readback is occurring until it is known to be |
| finished. |
| |
| An example of how an implementation might conceivably require |
| this is as follows. Suppose that a piece of hardware, for some |
| reason, can only write full 32-byte chunks of data. Any bytes |
| that were supposed to be unwritten are in fact trashed by the |
| hardware, filled with garbage. By careful fixups (read the |
| contents before the operation, restore when done), the driver may |
| be able to hide this fact, but a requirement that either new or |
| old data must show up would be violated. |
| |
| Or, more trivially, you might implement certain pixel operations |
| as an in-place postprocess on the returned data. |
| |
| It is not anticipated that NVIDIA implementations will need this |
| flexibility, but it is nevertheless provided. |
| |
| * How should an application allocate its PDR memory? |
| |
| The app should use wglAllocateMemoryNV, even for a read PDR in |
| system memory. Using malloc may result in suboptimal |
| performance, because the driver will not be able to choose an |
| optimal memory type. For ReadPixels to system memory, you might |
| set a read frequency of 1.0, a write frequency of 0.0, and a |
| priority of 1.0. The driver might allocate PCI memory, or |
| physically contiguous PCI memory, or cachable AGP memory, all |
| depending on the performance characteristics of the device. |
| While memory from malloc will work, it does not allow the driver |
| to make these decisions, and it will certainly never give you AGP |
| memory. |
| |
| Write PDR memory for purposes of streaming textures, etc. works |
| exactly the same as VAR memory for streaming vertices. You can, |
| and in fact are encouraged to, use the same circular buffer for |
| both vertices and textures. |
| |
| If you have different needs (not just streaming textures or |
| asynchronous readbacks), you may want your pixel data in video |
| memory. |
| |
| New Procedures and Functions |
| |
| void PixelDataRangeNV(enum target, sizei length, void *pointer) |
| void FlushPixelDataRangeNV(enum target) |
| |
| New Tokens |
| |
| Accepted by the <target> parameter of PixelDataRangeNV and |
| FlushPixelDataRangeNV, and by the <cap> parameter of |
| EnableClientState, DisableClientState, and IsEnabled: |
| |
| WRITE_PIXEL_DATA_RANGE_NV 0x8878 |
| READ_PIXEL_DATA_RANGE_NV 0x8879 |
| |
| Accepted by the <pname> parameter of GetBooleanv, GetIntegerv, |
| GetFloatv, and GetDoublev: |
| |
| WRITE_PIXEL_DATA_RANGE_LENGTH_NV 0x887A |
| READ_PIXEL_DATA_RANGE_LENGTH_NV 0x887B |
| |
| Accepted by the <pname> parameter of GetPointerv: |
| |
| WRITE_PIXEL_DATA_RANGE_POINTER_NV 0x887C |
| READ_PIXEL_DATA_RANGE_POINTER_NV 0x887D |
| |
| Additions to Chapter 2 of the OpenGL 1.3 Specification (OpenGL Operation) |
| |
| None. |
| |
| Additions to Chapter 3 of the OpenGL 1.3 Specification (Rasterization) |
| |
| |
| Add new section to Section 3.6, "Pixel Rectangles", on page 113: |
| |
| "3.6.7 Write Pixel Data Range Operation |
| |
| Applications can enhance the performance of DrawPixels and other |
| commands that transfer large amounts of pixel data by using a pixel |
| data range. The command |
| |
| void PixelDataRangeNV(enum target, sizei length, void *pointer) |
| |
| specifies one of the current pixel data ranges. When the write pixel |
| data range is enabled and valid, pixel data transfers from within |
| the pixel data range are potentially faster. The pixel data range is |
| a contiguous region of (virtual) address space for placing pixel |
| data. The "pointer" parameter is a pointer to the base of the pixel |
| data range. The "length" pointer is the length of the pixel data |
| range in basic machine units (typically unsigned bytes). For the |
| write pixel data range, "target" must be WRITE_PIXEL_DATA_RANGE_NV. |
| |
| The pixel data range address space region extends from "pointer" |
| to "pointer + length - 1" inclusive. |
| |
| There is some system burden associated with establishing a pixel data |
| range (typically, the memory range must be locked down). If either |
| the pixel data range pointer or size is set to zero, the previously |
| established pixel data range is released (typically, unlocking the |
| memory). |
| |
| The pixel data range may not be established for operating system |
| dependent reasons, and therefore, not valid. Reasons that a pixel |
| data range cannot be established include spanning different memory |
| types, the memory could not be locked down, alignment restrictions |
| are not met, etc. |
| |
| The write pixel data range is enabled or disabled by calling |
| EnableClientState or DisableClientState with the symbolic constant |
| WRITE_PIXEL_DATA_RANGE_NV. |
| |
| The write pixel data range is valid when the following conditions are |
| met: |
| |
| o WRITE_PIXEL_DATA_RANGE_NV is enabled. |
| |
| o PixelDataRangeNV has been called with a non-null pointer and |
| non-zero size, for target WRITE_PIXEL_DATA_RANGE_NV. |
| |
| o The write pixel data range has been established. |
| |
| o An implementation-dependent validity check based on the |
| pointer alignment, size, and underlying memory type of the |
| write pixel data range region of memory. |
| |
| Otherwise, the write pixel data range is not valid. |
| |
| The commands, such as DrawPixels, that may be made faster by the |
| write pixel data range are listed in the Appendix. |
| |
| When the write pixel data range is valid, an attempt will be made to |
| accelerate these commands if and only if the data pointer argument to |
| the command lies within the write pixel data range. No attempt will |
| be made to accelerate commands whose base pointer is outside this |
| range. Accessing data outside the write pixel data range when the |
| base pointer lies within the range and the range is valid will |
| produce undefined results and may cause program termination. |
| |
| The standard OpenGL pixel data coherency model requires that pixel |
| data be extracted from the user's buffer immediately, before the |
| pixel command returns. When the write pixel data range is valid, |
| this model is relaxed so that changes made to pixel data until the |
| next "write pixel data range flush" may affect pixel commands in non- |
| sequential ways. That is, a call to a pixel command that precedes |
| a change to pixel data (without an intervening "write pixel data |
| range flush") may access the changed data; though a call to a pixel |
| command following a change to pixel data must always access the |
| changed data, and never the original data. |
| |
| A 'write pixel data range flush' occurs when one of the following |
| operations occur: |
| |
| o Finish returns. |
| |
| o FlushPixelDataRangeNV (with target WRITE_PIXEL_DATA_RANGE_NV) |
| returns. |
| |
| o PixelDataRangeNV (with target WRITE_PIXEL_DATA_RANGE_NV) |
| returns. |
| |
| The client state required to implement the write pixel data range |
| consists of an enable bit, a memory pointer, and an integer size. |
| |
| If the memory mapping of pages within the pixel data range changes, |
| using the pixel data range has undefined effects. To ensure that the |
| pixel data range reflects the address space's current state, the |
| application is responsible for calling PixelDataRange again after any |
| memory mapping changes within the pixel data range." |
| |
| Additions to Chapter 4 of the OpenGL 1.3 Specification (Per-Fragment |
| Operations and the Frame Buffer) |
| |
| Add new section to Section 4.3, "Pixel Draw/Read State", on page 180: |
| |
| "4.3.5 Read Pixel Data Range Operation |
| |
| The read pixel data range is similar to the write pixel data range |
| (see section 3.6.7), but is specified with PixelDataRangeNV with a |
| target READ_PIXEL_DATA_RANGE_NV. It is exactly analogous to the |
| write pixel data range, but applies to commands where OpenGL returns |
| pixel data to the caller, such as ReadPixels. The list of commands |
| to which the read pixel data range applies can be found in the |
| Appendix. |
| |
| Validity checks and flushes of the read pixel data range behave in a |
| manner exactly analogous to those of the write pixel data range, |
| though any implementation-dependent checks may differ between the two |
| types of pixel data range. |
| |
| The standard OpenGL pixel data coherency model requires that pixel |
| data be written into the user's buffer immediately, before the |
| pixel command returns. When the read pixel data range is valid, |
| this model is relaxed so that this data may not necessarily be |
| available until the next "read pixel data range flush". Until such |
| point in time, an attempt to read the buffer returns undefined |
| values. |
| |
| If both the read and write pixel data ranges are valid and overlap, |
| then all operations involving both in the same thread are |
| automatically synchronized. That is, the write pixel data range |
| operation will automatically wait for any pending read pixel data |
| range results to become available before attempting to retrieve them. |
| However, if the operations are performed from different threads, the |
| user is responsible for all such synchronization. |
| |
| Read pixel data range operations are also synchronized with vertex |
| array range operations in the same way. |
| |
| The client state required to implement the read pixel data range |
| consists of an enable bit, a memory pointer, and an integer size." |
| |
| Additions to Chapter 5 of the OpenGL 1.3 Specification (Special Functions) |
| |
| Add the following to the end of Section 5.4 "Display Lists" (page |
| 179): |
| |
| "PixelDataRangeNV and FlushPixelDataRangeNV are not complied into |
| display lists but are executed immediately. |
| |
| If a display list is compiled while WRITE_PIXEL_DATA_RANGE_NV is |
| enabled, all commands affected by that enable are accumulated into a |
| display list as if WRITE_PIXEL_DATA_RANGE_NV is disabled. |
| |
| The state of the read pixel data range does not affect display list |
| compilation, because those commands that might be accelerated by a |
| read pixel data range are commands that are executed immediately |
| rather than being compiled into a display list (ReadPixels and |
| GetTexImage, for example)." |
| |
| Additions to Chapter 6 of the OpenGL 1.3 Specification (State and |
| State Requests) |
| |
| None. |
| |
| Additions to the GLX Specification |
| |
| "OpenGL implementations using GLX indirect rendering should fail to |
| set up the pixel data range and will not accelerate any pixel |
| operations using it. Additionally, glXAllocateMemoryNV always fails |
| to allocate memory (returns NULL) when used with an indirect |
| rendering context." |
| |
| GLX Protocol |
| |
| None |
| |
| Errors |
| |
| INVALID_OPERATION is generated if PixelDataRangeNV or |
| FlushPixelDataRangeNV is called between the execution of Begin and |
| the corresponding execution of End. |
| |
| INVALID_ENUM is generated if PixelDataRangeNV or |
| FlushPixelDataRangeNV is called when target is not |
| WRITE_PIXEL_DATA_RANGE_NV or READ_PIXEL_DATA_RANGE_NV. |
| |
| INVALID_VALUE is generated if PixelDataRangeNV is called when length |
| is negative. |
| |
| New State |
| |
| Initial |
| Get Value Get Command Type Value Attrib |
| --------- ----------- ---- ------- ------ |
| WRITE_PIXEL_DATA_RANGE_NV IsEnabled B False pixel-store |
| READ_PIXEL_DATA_RANGE_NV IsEnabled B False pixel-store |
| WRITE_PIXEL_DATA_RANGE_POINTER_NV GetPointerv Z+ 0 pixel-store |
| READ_PIXEL_DATA_RANGE_POINTER_NV GetPointerv Z+ 0 pixel-store |
| WRITE_PIXEL_DATA_RANGE_LENGTH_NV GetIntegerv Z+ 0 pixel-store |
| READ_PIXEL_DATA_RANGE_LENGTH_NV GetIntegerv Z+ 0 pixel-store |
| |
| Appendix: Operations Supported |
| |
| In unextended OpenGL 1.3 with ARB_imaging support, the following |
| commands may take advantage of the write PDR: |
| |
| glBitmap |
| glColorSubTable |
| glColorTable |
| glCompressedTexImage1D |
| glCompressedTexImage2D |
| glCompressedTexImage3D |
| glCompressedTexSubImage1D |
| glCompressedTexSubImage2D |
| glCompressedTexSubImage3D |
| glConvolutionFilter1D |
| glConvolutionFilter2D |
| glDrawPixels |
| glPixelMapfv |
| glPixelMapuiv |
| glPixelMapusv |
| glPolygonStipple |
| glSeparableFilter2D |
| glTexImage1D |
| glTexImage2D |
| glTexImage3D |
| glTexSubImage1D |
| glTexSubImage2D |
| glTexSubImage3D |
| |
| In unextended OpenGL 1.3 with ARB_imaging support, the following |
| commands may take advantage of the read PDR: |
| |
| glGetColorTable |
| glGetCompressedTexImage |
| glGetConvolutionFilter |
| glGetHistogram |
| glGetMinmax |
| glGetPixelMapfv |
| glGetPixelMapuiv |
| glGetPixelMapusv |
| glGetPolygonStipple |
| glGetSeparableFilter |
| glGetTexImage |
| glReadPixels |
| |
| No other extensions shipping in the NVIDIA OpenGL drivers add any |
| other new commands that may take advantage of this extension, |
| although in a few cases there are new commands that alias to other |
| commands that may be accelerated by this extension. These commands |
| are: |
| |
| glCompressedTexImage1DARB (ARB_texture_compression) |
| glCompressedTexImage2DARB (ARB_texture_compression) |
| glCompressedTexImage3DARB (ARB_texture_compression) |
| glCompressedTexSubImage1DARB (ARB_texture_compression) |
| glCompressedTexSubImage2DARB (ARB_texture_compression) |
| glCompressedTexSubImage3DARB (ARB_texture_compression) |
| glColorSubTableEXT (EXT_paletted_texture) |
| glColorTableEXT (EXT_paletted_texture) |
| glGetCompressedTexImageARB (ARB_texture_compression) |
| glTexImage3DEXT (EXT_texture3D) |
| glTexSubImage3DEXT (EXT_texture3D) |
| |
| NVIDIA Implementation Details |
| |
| In the Release 40 OpenGL drivers, the NV_pixel_data_range extension |
| is supported on all GeForce/Quadro-class hardware. The following |
| commands may potentially be accelerated in this release: |
| |
| glReadPixels |
| glTexImage2D |
| glTexSubImage2D |
| glCompressedTexImage2D |
| glCompressedTexImage3D |
| glCompressedTexSubImage2D |
| |
| The following type/format/buffer format sets are accelerated for |
| glReadPixels: |
| |
| type format buffer format |
| ----------------------------------------------------------------------------------------------- |
| GL_UNSIGNED_SHORT_5_6_5 GL_RGB 16-bit color (PCs only -- Macs use 555) |
| GL_UNSIGNED_INT_8_8_8_8_REV GL_BGRA 32-bit color w/ alpha |
| GL_UNSIGNED_BYTE GL_BGRA 32-bit color w/ alpha (little endian only) |
| GL_UNSIGNED_SHORT GL_DEPTH_COMPONENT 16-bit depth |
| GL_UNSIGNED_INT_24_8_NV GL_DEPTH_STENCIL_NV 24-bit depth, 8-bit stencil |
| |
| The following internalformat/type/format sets are accelerated for |
| glTex[Sub]Image2D: |
| |
| internalformat type format |
| ------------------------------------------------------------------------------- |
| GL_RGB5 GL_UNSIGNED_SHORT_5_6_5 GL_RGB |
| GL_RGB8 GL_UNSIGNED_INT_8_8_8_8_REV GL_BGRA |
| GL_RGBA4 GL_UNSIGNED_SHORT_4_4_4_4_REV GL_BGRA |
| GL_RGB5_A1 GL_UNSIGNED_SHORT_1_5_5_5_REV GL_BGRA |
| GL_RGBA8 GL_UNSIGNED_INT_8_8_8_8_REV GL_BGRA |
| |
| GL_DEPTH_COMPONENT16_SGIX GL_UNSIGNED_SHORT GL_DEPTH_COMPONENT |
| GL_DEPTH_COMPONENT24_SGIX GL_UNSIGNED_INT_24_8_NV GL_DEPTH_STENCIL_NV |
| |
| The following internalformat/type/format sets will be accelerated for |
| glTex[Sub]Image2D on little-endian machines only: |
| |
| internalformat type format |
| ------------------------------------------------------------------------------- |
| GL_LUMINANCE8_ALPHA8 GL_UNSIGNED_BYTE GL_LUMINANCE_ALPHA |
| |
| GL_RGB8 GL_UNSIGNED_BYTE GL_BGRA |
| GL_RGBA8 GL_UNSIGNED_BYTE GL_BGRA |
| |
| All compressed texture formats are supported for |
| glCompressedTex[Sub]Image[2,3]D. |
| |
| The following restrictions apply to all commands: |
| - No pixel transfer operations of any kind may be in use. |
| - The base address of the PDR must be aligned to a 32-byte boundary. |
| - The data pointer must be aligned to boundaries of the size of one |
| group of pixels. For example, GL_UNSIGNED_SHORT_5_6_5 data must |
| be aligned to 2-byte boundaries, GL_UNSIGNED_INT_24_8_NV data must |
| be aligned to 4-byte boundaries, and GL_BGRA/GL_UNSIGNED_BYTE data |
| must be aligned to 4-byte boundaries (not 1-byte boundaries). |
| Compressed texture data must be aligned to a block boundary. |
| |
| No additional restrictions apply to glReadPixels or |
| glCompressedTex[Sub]Image[2,3]D. |
| |
| The following additional restrictions apply to glTex[Sub]Image2D: |
| - The texture must fit in video memory. |
| - The texture must have a border size of zero. |
| - The stride (in bytes) between two lines of source data must not |
| exceed 65535. |
| - For non-rectangle textures, the width and height of the destination |
| mipmap level must not exceed 2048, nor be below 2; also, the |
| destination mipmap level must not be 2x2 (for 16-bit textures) or |
| 2x2, 4x2, or 2x4 (for 8-bit textures). |
| |
| Future software releases may increase the number of accelerated |
| commands and the number of accelerated data formats for each command. |
| Note also that although all of the formats and commands listed are |
| guaranteed to be accelerated, there may be limitations in the actual |
| implementation not as strict as those stated here; for example, some |
| data formats not listed here may turn out to be accelerated. |
| However, it is highly recommended that you stick to the formats and |
| commands listed in this section. In cases where actual restrictions |
| are less strict, future implementations may very well enforce the |
| listed restriction. |
| |
| It is also possible that some of these restrictions may become _more_ |
| strict on future chips; though at present no such additional |
| restrictions are known to be likely. Such restrictions would likely |
| take the form of more stringent pitch or alignment restrictions, if |
| they proved to be necessary. |
| |
| In practice, you should expect that several of these restrictions |
| will be more lenient in a future release. |
| |
| Revision History |
| |
| November 7, 2002 - Updated implementation details section with most |
| up-to-date rules on PDR usage. Lifted rule that texture downloads |
| must be 2046 pixels in size or smaller. Removed support for 8-bit |
| texture downloads. Increased max TexSubImage pitch to 65535 from |
| 8191. |