diff options
Diffstat (limited to 'mesalib/docs')
| -rw-r--r-- | mesalib/docs/MESA_agp_offset.spec | 190 | ||||
| -rw-r--r-- | mesalib/docs/MESA_drm_image.spec | 4 | ||||
| -rw-r--r-- | mesalib/docs/MESA_pack_invert.spec | 276 | ||||
| -rw-r--r-- | mesalib/docs/MESA_release_buffers.spec | 170 | ||||
| -rw-r--r-- | mesalib/docs/MESA_resize_buffers.spec | 162 | ||||
| -rw-r--r-- | mesalib/docs/MESA_swap_control.spec | 258 | ||||
| -rw-r--r-- | mesalib/docs/MESA_texture_array.spec | 1608 | ||||
| -rw-r--r-- | mesalib/docs/MESA_texture_signed_rgba.spec | 428 | ||||
| -rw-r--r-- | mesalib/docs/MESA_window_pos.spec | 252 | ||||
| -rw-r--r-- | mesalib/docs/MESA_ycbcr_texture.spec | 408 | ||||
| -rw-r--r-- | mesalib/docs/WL_bind_wayland_display.spec | 184 | ||||
| -rw-r--r-- | mesalib/docs/contents.html | 211 | ||||
| -rw-r--r-- | mesalib/docs/llvmpipe.html | 204 |
13 files changed, 2280 insertions, 2075 deletions
diff --git a/mesalib/docs/MESA_agp_offset.spec b/mesalib/docs/MESA_agp_offset.spec index 8dcc72379..bf3ea1748 100644 --- a/mesalib/docs/MESA_agp_offset.spec +++ b/mesalib/docs/MESA_agp_offset.spec @@ -1,95 +1,95 @@ -Name - - MESA_agp_offset - -Name Strings - - GLX_MESA_agp_offset - -Contact - - Brian Paul, Tungsten Graphics, Inc. (brian.paul 'at' tungstengraphics.com) - Keith Whitwell, Tungsten Graphics, Inc. (keith 'at' tungstengraphics.com) - -Status - - Shipping (Mesa 4.0.4 and later. Only implemented in particular - XFree86/DRI drivers.) - -Version - - 1.0 - -Number - - TBD - -Dependencies - - OpenGL 1.0 or later is required - GLX_NV_vertex_array_range is required. - This extensions is written against the OpenGL 1.4 Specification. - -Overview - - This extensions provides a way to convert pointers in an AGP memory - region into byte offsets into the AGP aperture. - Note, this extension depends on GLX_NV_vertex_array_range, for which - no real specification exists. See GL_NV_vertex_array_range for more - information. - -IP Status - - None - -Issues - - None - -New Procedures and Functions - - unsigned int glXGetAGPOffsetMESA( const void *pointer ) - -New Tokens - - None - -Additions to the OpenGL 1.4 Specification - - None - -Additions to Chapter 3 the GLX 1.4 Specification (Functions and Errors) - - Add a new section, 3.6 as follows: - - 3.6 AGP Memory Access - - On "PC" computers, AGP memory can be allocated with glXAllocateMemoryNV - and freed with glXFreeMemoryNV. Sometimes it's useful to know where a - block of AGP memory is located with respect to the start of the AGP - aperature. The function - - GLuint glXGetAGPOffsetMESA( const GLvoid *pointer ) - - Returns the offset of the given memory block from the start of AGP - memory in basic machine units (i.e. bytes). If pointer is invalid - the value ~0 will be returned. - -GLX Protocol - - None. This is a client side-only extension. - -Errors - - glXGetAGPOffsetMESA will return ~0 if the pointer does not point to - an AGP memory region. - -New State - - None - -Revision History - - 20 September 2002 - Initial draft - 2 October 2002 - finished GLX chapter 3 additions - 27 July 2004 - use unsigned int instead of GLuint, void instead of GLvoid +Name
+
+ MESA_agp_offset
+
+Name Strings
+
+ GLX_MESA_agp_offset
+
+Contact
+
+ Brian Paul, Tungsten Graphics, Inc. (brian.paul 'at' tungstengraphics.com)
+ Keith Whitwell, Tungsten Graphics, Inc. (keith 'at' tungstengraphics.com)
+
+Status
+
+ Shipping (Mesa 4.0.4 and later. Only implemented in particular
+ XFree86/DRI drivers.)
+
+Version
+
+ 1.0
+
+Number
+
+ TBD
+
+Dependencies
+
+ OpenGL 1.0 or later is required
+ GLX_NV_vertex_array_range is required.
+ This extensions is written against the OpenGL 1.4 Specification.
+
+Overview
+
+ This extensions provides a way to convert pointers in an AGP memory
+ region into byte offsets into the AGP aperture.
+ Note, this extension depends on GLX_NV_vertex_array_range, for which
+ no real specification exists. See GL_NV_vertex_array_range for more
+ information.
+
+IP Status
+
+ None
+
+Issues
+
+ None
+
+New Procedures and Functions
+
+ unsigned int glXGetAGPOffsetMESA( const void *pointer )
+
+New Tokens
+
+ None
+
+Additions to the OpenGL 1.4 Specification
+
+ None
+
+Additions to Chapter 3 the GLX 1.4 Specification (Functions and Errors)
+
+ Add a new section, 3.6 as follows:
+
+ 3.6 AGP Memory Access
+
+ On "PC" computers, AGP memory can be allocated with glXAllocateMemoryNV
+ and freed with glXFreeMemoryNV. Sometimes it's useful to know where a
+ block of AGP memory is located with respect to the start of the AGP
+ aperture. The function
+
+ GLuint glXGetAGPOffsetMESA( const GLvoid *pointer )
+
+ Returns the offset of the given memory block from the start of AGP
+ memory in basic machine units (i.e. bytes). If pointer is invalid
+ the value ~0 will be returned.
+
+GLX Protocol
+
+ None. This is a client side-only extension.
+
+Errors
+
+ glXGetAGPOffsetMESA will return ~0 if the pointer does not point to
+ an AGP memory region.
+
+New State
+
+ None
+
+Revision History
+
+ 20 September 2002 - Initial draft
+ 2 October 2002 - finished GLX chapter 3 additions
+ 27 July 2004 - use unsigned int instead of GLuint, void instead of GLvoid
diff --git a/mesalib/docs/MESA_drm_image.spec b/mesalib/docs/MESA_drm_image.spec index 5f58f620f..76de3f8b6 100644 --- a/mesalib/docs/MESA_drm_image.spec +++ b/mesalib/docs/MESA_drm_image.spec @@ -24,7 +24,7 @@ Number Dependencies
- Reguires EGL 1.4 or later. This extension is written against the
+ Requires EGL 1.4 or later. This extension is written against the
wording of the EGL 1.4 specification.
EGL_KHR_base_image is required.
@@ -134,7 +134,7 @@ Issues RESOLVED: The eglQueryImage function has been proposed often,
but it goes against the EGLImage design. EGLImages are opaque
handles to a 2D array of pixels, which can be passed between
- client APIs. By referenceing an EGLImage in a client API, the
+ client APIs. By referencing an EGLImage in a client API, the
EGLImage target (a texture, a renderbuffer or such) can be
used to query the attributes of the EGLImage. We don't have a
full client API for creating and querying DRM buffers, though,
diff --git a/mesalib/docs/MESA_pack_invert.spec b/mesalib/docs/MESA_pack_invert.spec index 53d5fca71..0eeb58c13 100644 --- a/mesalib/docs/MESA_pack_invert.spec +++ b/mesalib/docs/MESA_pack_invert.spec @@ -1,138 +1,138 @@ -Name - - MESA_pack_invert - -Name Strings - - GL_MESA_pack_invert - -Contact - - Brian Paul, Tungsten Graphics, Inc. (brian.paul 'at' tungstengraphics.com) - Keith Whitwell, Tungsten Graphics, Inc. (keith 'at' tungstengraphics.com) - -Status - - Shipping (Mesa 4.0.4 and later) - -Version - - 1.0 - -Number - - TBD - -Dependencies - - OpenGL 1.0 or later is required - This extensions is written against the OpenGL 1.4 Specification. - -Overview - - This extension adds a new pixel storage parameter to indicate that - images are to be packed in top-to-bottom order instead of OpenGL's - conventional bottom-to-top order. Only pixel packing can be - inverted (i.e. for glReadPixels, glGetTexImage, glGetConvolutionFilter, - etc). - - Almost all known image file formats store images in top-to-bottom - order. As it is, OpenGL reads images from the frame buffer in - bottom-to-top order. Thus, images usually have to be inverted before - writing them to a file with image I/O libraries. This extension - allows images to be read such that inverting isn't needed. - -IP Status - - None - -Issues - - 1. Should we also defined UNPACK_INVERT_MESA for glDrawPixels, etc? - - Resolved: No, we're only concerned with pixel packing. There are other - solutions for inverting images when using glDrawPixels (negative Y pixel - zoom) or glTexImage (invert the vertex T coordinates). It would be easy - enough to define a complementary extension for pixel packing in the - future if needed. - -New Procedures and Functions - - None - -New Tokens - - Accepted by the <pname> parameter of PixelStorei and PixelStoref - and the <pname> parameter of GetIntegerv, GetFloatv, GetDoublev - and GetBooleanv: - - PACK_INVERT_MESA 0x8758 - -Additions to Chapter 2 of the OpenGL 1.4 Specification (OpenGL Operation) - - None - -Additions to Chapter 3 of the OpenGL 1.4 Specification (Rasterization) - - None - -Additions to Chapter 4 of the OpenGL 1.4 Specification (Per-Fragment -Operations and the Frame Buffer) - - Add the following entry to table 4.4 (PixelStore parameters) on page 182: - - Parameter Name Type Initial Value Valid Range - --------------------------------------------------------- - PACK_INVERT_MESA boolean FALSE TRUE/FALSE - - In the section labeled "Placement in Client Memory" on page 184 - insert the following text into the paragraph before the sentence - that starts with "If the format is RED, GREEN, BLUE...": - - "The parameter PACK_INVERT_MESA controls whether the image is packed - in bottom-to-top order (the default) or top-to-bottom order. Equation - 3.8 is modified as follows: - - ... the first element of the Nth row is indicated by - - p + Nk, if PACK_INVERT_MESA is false - p + k * (H - 1) - Nk, if PACK_INVERT_MESA is true, where H is the - image height - " - -Additions to Chapter 5 of the OpenGL 1.4 Specification (Special Functions) - - None - -Additions to Chapter 6 of the OpenGL 1.4 Specification (State and -State Requests) - - None - -Additions to Appendix A of the OpenGL 1.4 Specification (Invariance) - - None - -Additions to the AGL/GLX/WGL Specifications - - None - -GLX Protocol - - None - -Errors - - None - -New State - - Add the following entry to table 6.20 (Pixels) on page 235: - - Get Value Type Get Cmd Initial Value Description Sec Attribute - -------------------------------------------------------------------------------------------------- - PACK_INVERT_MESA boolean GetBoolean FALSE Value of PACK_INVERT_MESA 4.3.2 pixel-store - -Revision History - - 21 September 2002 - Initial draft +Name
+
+ MESA_pack_invert
+
+Name Strings
+
+ GL_MESA_pack_invert
+
+Contact
+
+ Brian Paul, Tungsten Graphics, Inc. (brian.paul 'at' tungstengraphics.com)
+ Keith Whitwell, Tungsten Graphics, Inc. (keith 'at' tungstengraphics.com)
+
+Status
+
+ Shipping (Mesa 4.0.4 and later)
+
+Version
+
+ 1.0
+
+Number
+
+ TBD
+
+Dependencies
+
+ OpenGL 1.0 or later is required
+ This extensions is written against the OpenGL 1.4 Specification.
+
+Overview
+
+ This extension adds a new pixel storage parameter to indicate that
+ images are to be packed in top-to-bottom order instead of OpenGL's
+ conventional bottom-to-top order. Only pixel packing can be
+ inverted (i.e. for glReadPixels, glGetTexImage, glGetConvolutionFilter,
+ etc).
+
+ Almost all known image file formats store images in top-to-bottom
+ order. As it is, OpenGL reads images from the frame buffer in
+ bottom-to-top order. Thus, images usually have to be inverted before
+ writing them to a file with image I/O libraries. This extension
+ allows images to be read such that inverting isn't needed.
+
+IP Status
+
+ None
+
+Issues
+
+ 1. Should we also define UNPACK_INVERT_MESA for glDrawPixels, etc?
+
+ Resolved: No, we're only concerned with pixel packing. There are other
+ solutions for inverting images when using glDrawPixels (negative Y pixel
+ zoom) or glTexImage (invert the vertex T coordinates). It would be easy
+ enough to define a complementary extension for pixel packing in the
+ future if needed.
+
+New Procedures and Functions
+
+ None
+
+New Tokens
+
+ Accepted by the <pname> parameter of PixelStorei and PixelStoref
+ and the <pname> parameter of GetIntegerv, GetFloatv, GetDoublev
+ and GetBooleanv:
+
+ PACK_INVERT_MESA 0x8758
+
+Additions to Chapter 2 of the OpenGL 1.4 Specification (OpenGL Operation)
+
+ None
+
+Additions to Chapter 3 of the OpenGL 1.4 Specification (Rasterization)
+
+ None
+
+Additions to Chapter 4 of the OpenGL 1.4 Specification (Per-Fragment
+Operations and the Frame Buffer)
+
+ Add the following entry to table 4.4 (PixelStore parameters) on page 182:
+
+ Parameter Name Type Initial Value Valid Range
+ ---------------------------------------------------------
+ PACK_INVERT_MESA boolean FALSE TRUE/FALSE
+
+ In the section labeled "Placement in Client Memory" on page 184
+ insert the following text into the paragraph before the sentence
+ that starts with "If the format is RED, GREEN, BLUE...":
+
+ "The parameter PACK_INVERT_MESA controls whether the image is packed
+ in bottom-to-top order (the default) or top-to-bottom order. Equation
+ 3.8 is modified as follows:
+
+ ... the first element of the Nth row is indicated by
+
+ p + Nk, if PACK_INVERT_MESA is false
+ p + k * (H - 1) - Nk, if PACK_INVERT_MESA is true, where H is the
+ image height
+ "
+
+Additions to Chapter 5 of the OpenGL 1.4 Specification (Special Functions)
+
+ None
+
+Additions to Chapter 6 of the OpenGL 1.4 Specification (State and
+State Requests)
+
+ None
+
+Additions to Appendix A of the OpenGL 1.4 Specification (Invariance)
+
+ None
+
+Additions to the AGL/GLX/WGL Specifications
+
+ None
+
+GLX Protocol
+
+ None
+
+Errors
+
+ None
+
+New State
+
+ Add the following entry to table 6.20 (Pixels) on page 235:
+
+ Get Value Type Get Cmd Initial Value Description Sec Attribute
+ --------------------------------------------------------------------------------------------------
+ PACK_INVERT_MESA boolean GetBoolean FALSE Value of PACK_INVERT_MESA 4.3.2 pixel-store
+
+Revision History
+
+ 21 September 2002 - Initial draft
diff --git a/mesalib/docs/MESA_release_buffers.spec b/mesalib/docs/MESA_release_buffers.spec index 8db9350d8..e906e1459 100644 --- a/mesalib/docs/MESA_release_buffers.spec +++ b/mesalib/docs/MESA_release_buffers.spec @@ -1,85 +1,85 @@ -Name - - MESA_release_buffers - -Name Strings - - GLX_MESA_release_buffers - -Contact - - Brian Paul (brian.paul 'at' tungstengraphics.com) - -Status - - Shipping since Mesa 2.0 in October, 1996. - -Version - - Last Modified Date: 8 June 2000 - -Number - - 217 - -Dependencies - - OpenGL 1.0 or later is required. - GLX 1.0 or later is required. - -Overview - - Mesa's implementation of GLX is entirely implemented on the client side. - Therefore, Mesa cannot immediately detect when an X window or pixmap is - destroyed in order to free any ancilliary data associated with the window - or pixmap. - - The glxMesaReleaseBuffers() function can be used to explicitly indicate - when the back color buffer, depth buffer, stencil buffer, and/or accum- - ulation buffer associated with a drawable can be freed. - -IP Status - - Open-source; freely implementable. - -Issues - - None. - -New Procedures and Functions - - Bool glXReleaseBuffersMESA( Display *dpy, GLXDrawable d ); - -New Tokens - - None. - -Additions to Chapter 3 of the GLX 1.3 Specification (Functions and Errors) - - The function - - Bool glXReleaseBuffersMESA( Display *dpy, GLXDrawable d ); - - causes all software ancilliary buffers (back buffer, depth, stencil, - accum, etc) associated with the named drawable to be immediately - deallocated. True is returned if <d> is a valid Mesa GLX drawable, - else False is returned. After calling glXReleaseBuffersMESA, the - drawable should no longer be used for GL rendering. Results of - attempting to do so are undefined. - - -GLX Protocol - - None, since this is a client-side operation. - -Errors - - None. - -New State - - None. - -Revision History - - 8 June 2000 - initial specification +Name
+
+ MESA_release_buffers
+
+Name Strings
+
+ GLX_MESA_release_buffers
+
+Contact
+
+ Brian Paul (brian.paul 'at' tungstengraphics.com)
+
+Status
+
+ Shipping since Mesa 2.0 in October, 1996.
+
+Version
+
+ Last Modified Date: 8 June 2000
+
+Number
+
+ 217
+
+Dependencies
+
+ OpenGL 1.0 or later is required.
+ GLX 1.0 or later is required.
+
+Overview
+
+ Mesa's implementation of GLX is entirely implemented on the client side.
+ Therefore, Mesa cannot immediately detect when an X window or pixmap is
+ destroyed in order to free any ancillary data associated with the window
+ or pixmap.
+
+ The glxMesaReleaseBuffers() function can be used to explicitly indicate
+ when the back color buffer, depth buffer, stencil buffer, and/or accumu-
+ lation buffer associated with a drawable can be freed.
+
+IP Status
+
+ Open-source; freely implementable.
+
+Issues
+
+ None.
+
+New Procedures and Functions
+
+ Bool glXReleaseBuffersMESA( Display *dpy, GLXDrawable d );
+
+New Tokens
+
+ None.
+
+Additions to Chapter 3 of the GLX 1.3 Specification (Functions and Errors)
+
+ The function
+
+ Bool glXReleaseBuffersMESA( Display *dpy, GLXDrawable d );
+
+ causes all software ancillary buffers (back buffer, depth, stencil,
+ accum, etc) associated with the named drawable to be immediately
+ deallocated. True is returned if <d> is a valid Mesa GLX drawable,
+ else False is returned. After calling glXReleaseBuffersMESA, the
+ drawable should no longer be used for GL rendering. Results of
+ attempting to do so are undefined.
+
+
+GLX Protocol
+
+ None, since this is a client-side operation.
+
+Errors
+
+ None.
+
+New State
+
+ None.
+
+Revision History
+
+ 8 June 2000 - initial specification
diff --git a/mesalib/docs/MESA_resize_buffers.spec b/mesalib/docs/MESA_resize_buffers.spec index 533d017c9..4d6e9f720 100644 --- a/mesalib/docs/MESA_resize_buffers.spec +++ b/mesalib/docs/MESA_resize_buffers.spec @@ -1,81 +1,81 @@ -Name - - MESA_resize_buffers - -Name Strings - - GL_MESA_resize_buffers - -Contact - - Brian Paul (brian.paul 'at' tungstengraphics.com) - -Status - - Shipping (since Mesa version 2.2) - -Version - - -Number - - 196 - -Dependencies - - Mesa 2.2 or later is required. - -Overview - - Mesa is often used as a client library with no integration with - the computer's window system (an X server, for example). And since - Mesa does not have an event loop nor window system callbacks, it - cannot properly respond to window system events. In particular, - Mesa cannot automatically detect when a window has been resized. - - Mesa's glViewport command queries the current window size and updates - its internal data structors accordingly. This normally works fine - since most applications call glViewport in responce to window size - changes. - - In some situations, however, the application may not call glViewport - when a window size changes but would still like Mesa to adjust to - the new window size. This extension exports a new function to solve - this problem. - -New Procedures and Functions - - void glResizeBuffersMESA( void ) - -New Tokens - - none - -Additions to the OpenGL Specification (no particular section) - - The glResizeBuffersMESA command may be called when the client - determines that a window has been resized. Calling - glResizeBuffersMESA causes Mesa to query the current window size - and adjust its internal data structures. This may include - reallocating depth, stencil, alpha and accumulation buffers. - -Additions to the AGL/GLX/WGL Specifications - - None - -Errors - - INVALID_OPERATION is generated if ResizeBuffersMESA is called betweeen - Begin and End. - -New State - - None. - -New Implementation Dependent State - - None. - -Revision History - - * Revision 1.0 - Initial specification +Name
+
+ MESA_resize_buffers
+
+Name Strings
+
+ GL_MESA_resize_buffers
+
+Contact
+
+ Brian Paul (brian.paul 'at' tungstengraphics.com)
+
+Status
+
+ Shipping (since Mesa version 2.2)
+
+Version
+
+
+Number
+
+ 196
+
+Dependencies
+
+ Mesa 2.2 or later is required.
+
+Overview
+
+ Mesa is often used as a client library with no integration with
+ the computer's window system (an X server, for example). And since
+ Mesa does not have an event loop nor window system callbacks, it
+ cannot properly respond to window system events. In particular,
+ Mesa cannot automatically detect when a window has been resized.
+
+ Mesa's glViewport command queries the current window size and updates
+ its internal data structors accordingly. This normally works fine
+ since most applications call glViewport in response to window size
+ changes.
+
+ In some situations, however, the application may not call glViewport
+ when a window size changes but would still like Mesa to adjust to
+ the new window size. This extension exports a new function to solve
+ this problem.
+
+New Procedures and Functions
+
+ void glResizeBuffersMESA( void )
+
+New Tokens
+
+ none
+
+Additions to the OpenGL Specification (no particular section)
+
+ The glResizeBuffersMESA command may be called when the client
+ determines that a window has been resized. Calling
+ glResizeBuffersMESA causes Mesa to query the current window size
+ and adjust its internal data structures. This may include
+ reallocating depth, stencil, alpha and accumulation buffers.
+
+Additions to the AGL/GLX/WGL Specifications
+
+ None
+
+Errors
+
+ INVALID_OPERATION is generated if glResizeBuffersMESA is called between
+ Begin and End.
+
+New State
+
+ None.
+
+New Implementation Dependent State
+
+ None.
+
+Revision History
+
+ * Revision 1.0 - Initial specification
diff --git a/mesalib/docs/MESA_swap_control.spec b/mesalib/docs/MESA_swap_control.spec index 856978b53..31340772f 100644 --- a/mesalib/docs/MESA_swap_control.spec +++ b/mesalib/docs/MESA_swap_control.spec @@ -1,129 +1,129 @@ -Name - - MESA_swap_control - -Name Strings - - GLX_MESA_swap_control - -Contact - - Ian Romanick, IBM, idr at us.ibm.com - -Status - - Deployed in DRI drivers post-XFree86 4.3. - -Version - - Date: 5/1/2003 Revision: 1.1 - -Number - - ??? - -Dependencies - - None - - Based on GLX_SGI_swap_control version 1.9 and WGL_EXT_swap_control - version 1.5. - -Overview - - This extension allows an application to specify a minimum periodicity - of color buffer swaps, measured in video frame periods. - -Issues - - * Should implementations that export GLX_MESA_swap_control also export - GL_EXT_swap_control for compatibility with WGL_EXT_swap_control? - - UNRESOLVED. - -New Procedures and Functions - - int glXSwapIntervalMESA(unsigned int interval) - int glXGetSwapIntervalMESA(void) - -New Tokens - - None - -Additions to Chapter 2 of the 1.4 GL Specification (OpenGL Operation) - - None - -Additions to Chapter 3 of the 1.4 GL Specification (Rasterization) - - None - -Additions to Chapter 4 of the 1.4 GL Specification (Per-Fragment Operations -and the Framebuffer) - - None - -Additions to Chapter 5 of the 1.4 GL Specification (Special Functions) - - None - -Additions to Chapter 6 of the 1.4 GL Specification (State and State Requests) - - None - -Additions to the GLX 1.3 Specification - - [Add the following to Section 3.3.10 of the GLX Specification (Double - Buffering)] - - glXSwapIntervalMESA specifies the minimum number of video frame periods - per buffer swap. (e.g. a value of two means that the color buffers - will be swapped at most every other video frame.) A return value - of zero indicates success; otherwise an error occurred. The interval - takes effect when glXSwapBuffers is first called subsequent to the - glXSwapIntervalMESA call. - - A video frame period is the time required by the monitor to display a - full frame of video data. In the case of an interlaced monitor, - this is typically the time required to display both the even and odd - fields of a frame of video data. - - If <interval> is set to a value of 0, buffer swaps are not synchron- - ized to a video frame. The <interval> value is silently clamped to - the maximum implementation-dependent value supported before being - stored. - - The swap interval is not part of the render context state. It cannot - be pushed or popped. The current swap interval for the window - associated with the current context can be obtained by calling - glXGetSwapIntervalMESA. The default swap interval is 0. - - On XFree86, setting the environment variable LIBGL_THROTTLE_REFRESH sets - the swap interval to 1. - -Errors - - glXSwapIntervalMESA returns GLX_BAD_CONTEXT if there is no current - GLXContext or if the current context is not a direct rendering context. - -GLX Protocol - - None. This extension only extends to direct rendering contexts. - -New State - - Get Value Get Command Type Initial Value - --------- ----------- ---- ------------- - [swap interval] GetSwapInterval Z+ 0 - -New Implementation Dependent State - - None - - -Revision History - - 1.1, 5/1/03 Added the issues section and contact information. - Changed the default swap interval to 0. - 1.0, 3/17/03 Initial version based on GLX_SGI_swap_control and - WGL_EXT_swap_control. +Name
+
+ MESA_swap_control
+
+Name Strings
+
+ GLX_MESA_swap_control
+
+Contact
+
+ Ian Romanick, IBM, idr at us.ibm.com
+
+Status
+
+ Deployed in DRI drivers post-XFree86 4.3.
+
+Version
+
+ Date: 5/1/2003 Revision: 1.1
+
+Number
+
+ ???
+
+Dependencies
+
+ None
+
+ Based on GLX_SGI_swap_control version 1.9 and WGL_EXT_swap_control
+ version 1.5.
+
+Overview
+
+ This extension allows an application to specify a minimum periodicity
+ of color buffer swaps, measured in video frame periods.
+
+Issues
+
+ * Should implementations that export GLX_MESA_swap_control also export
+ GL_EXT_swap_control for compatibility with WGL_EXT_swap_control?
+
+ UNRESOLVED.
+
+New Procedures and Functions
+
+ int glXSwapIntervalMESA(unsigned int interval)
+ int glXGetSwapIntervalMESA(void)
+
+New Tokens
+
+ None
+
+Additions to Chapter 2 of the 1.4 GL Specification (OpenGL Operation)
+
+ None
+
+Additions to Chapter 3 of the 1.4 GL Specification (Rasterization)
+
+ None
+
+Additions to Chapter 4 of the 1.4 GL Specification (Per-Fragment Operations
+and the Framebuffer)
+
+ None
+
+Additions to Chapter 5 of the 1.4 GL Specification (Special Functions)
+
+ None
+
+Additions to Chapter 6 of the 1.4 GL Specification (State and State Requests)
+
+ None
+
+Additions to the GLX 1.3 Specification
+
+ [Add the following to Section 3.3.10 of the GLX Specification (Double
+ Buffering)]
+
+ glXSwapIntervalMESA specifies the minimum number of video frame periods
+ per buffer swap. (e.g. a value of two means that the color buffers
+ will be swapped at most every other video frame.) A return value
+ of zero indicates success; otherwise an error occurred. The interval
+ takes effect when glXSwapBuffers is first called subsequent to the
+ glXSwapIntervalMESA call.
+
+ A video frame period is the time required by the monitor to display a
+ full frame of video data. In the case of an interlaced monitor,
+ this is typically the time required to display both the even and odd
+ fields of a frame of video data.
+
+ If <interval> is set to a value of 0, buffer swaps are not synchro-
+ nized to a video frame. The <interval> value is silently clamped to
+ the maximum implementation-dependent value supported before being
+ stored.
+
+ The swap interval is not part of the render context state. It cannot
+ be pushed or popped. The current swap interval for the window
+ associated with the current context can be obtained by calling
+ glXGetSwapIntervalMESA. The default swap interval is 0.
+
+ On XFree86, setting the environment variable LIBGL_THROTTLE_REFRESH sets
+ the swap interval to 1.
+
+Errors
+
+ glXSwapIntervalMESA returns GLX_BAD_CONTEXT if there is no current
+ GLXContext or if the current context is not a direct rendering context.
+
+GLX Protocol
+
+ None. This extension only extends to direct rendering contexts.
+
+New State
+
+ Get Value Get Command Type Initial Value
+ --------- ----------- ---- -------------
+ [swap interval] GetSwapInterval Z+ 0
+
+New Implementation Dependent State
+
+ None
+
+
+Revision History
+
+ 1.1, 5/1/03 Added the issues section and contact information.
+ Changed the default swap interval to 0.
+ 1.0, 3/17/03 Initial version based on GLX_SGI_swap_control and
+ WGL_EXT_swap_control.
diff --git a/mesalib/docs/MESA_texture_array.spec b/mesalib/docs/MESA_texture_array.spec index 9dee65b04..1cc2217f3 100644 --- a/mesalib/docs/MESA_texture_array.spec +++ b/mesalib/docs/MESA_texture_array.spec @@ -1,804 +1,804 @@ -Name - - MESA_texture_array - -Name Strings - - GL_MESA_texture_array - -Contact - - Ian Romanick, IBM (idr 'at' us.ibm.com) - -IP Status - - No known IP issues. - -Status - - Shipping in Mesa 7.1 - -Version - - -Number - - TBD - -Dependencies - - OpenGL 1.2 or GL_EXT_texture3D is required. - - Support for ARB_fragment_program is assumed, but not required. - - Support for ARB_fragment_program_shadow is assumed, but not required. - - Support for EXT_framebuffer_object is assumed, but not required. - - Written based on the wording of the OpenGL 2.0 specification and - ARB_fragment_program_shadow but not dependent on them. - -Overview - - There are a number of circumstances where an application may wish to - blend two textures out of a larger set of textures. Moreover, in some - cases the selected textures may vary on a per-fragment basis within - a polygon. Several examples include: - - 1. High dynamic range textures. The application stores several - different "exposures" of an image as different textures. On a - per-fragment basis, the application selects which exposures are - used. - - 2. A terrain engine where the altitude of a point determines the - texture applied to it. If the transition is from beach sand to - grass to rocks to snow, the application will store each texture - in a different texture map, and dynamically select which two - textures to blend at run-time. - - 3. Storing short video clips in textures. Each depth slice is a - single frame of video. - - Several solutions to this problem have been proposed, but they either - involve using a separate texture unit for each texture map or using 3D - textures without mipmaps. Both of these options have major drawbacks. - - This extension provides a third alternative that eliminates the major - drawbacks of both previous methods. A new texture target, - TEXTURE_2D_ARRAY, is added that functions identically to TEXTURE_3D in - all aspects except the sizes of the non-base level images. In - traditional 3D texturing, the size of the N+1 LOD is half the size - of the N LOD in all three dimensions. For the TEXTURE_2D_ARRAY target, - the height and width of the N+1 LOD is halved, but the depth is the - same for all levels of detail. The texture then becomes an array of - 2D textures. The per-fragment texel is selected by the R texture - coordinate. - - References: - - http://www.opengl.org/discussion_boards/cgi_directory/ultimatebb.cgi?ubb=get_topic;f=3;t=011557 - http://www.opengl.org/discussion_boards/cgi_directory/ultimatebb.cgi?ubb=get_topic;f=3;t=000516 - http://www.opengl.org/discussion_boards/cgi_directory/ultimatebb.cgi?ubb=get_topic;f=3;t=011903 - http://www.delphi3d.net/articles/viewarticle.php?article=terraintex.htm - -New Procedures and Functions - - All functions come directly from EXT_texture_array. - - void FramebufferTextureLayerEXT(enum target, enum attachment, - uint texture, int level, int layer); - -New Tokens - - All token names and values come directly from EXT_texture_array. - - Accepted by the <cap> parameter of Enable, Disable, and IsEnabled, by - the <pname> parameter of GetBooleanv, GetIntegerv, GetFloatv, and - GetDoublev, and by the <target> parameter of TexImage3D, GetTexImage, - GetTexLevelParameteriv, GetTexLevelParameterfv, GetTexParameteriv, and - GetTexParameterfv: - - TEXTURE_1D_ARRAY_EXT 0x8C18 - TEXTURE_2D_ARRAY_EXT 0x8C1A - - Accepted by the <target> parameter of TexImage2D, TexSubImage2D, - CopyTexImage2D, CopyTexSubImage2D, CompressedTexImage2D, - CompressedTexSubImage2D, GetTexLevelParameteriv, and - GetTexLevelParameterfv: - - TEXTURE_1D_ARRAY_EXT - PROXY_TEXTURE_1D_ARRAY_EXT 0x8C19 - - Accepted by the <target> parameter of TexImage3D, TexSubImage3D, - CopyTexSubImage3D, CompressedTexImage3D, CompressedTexSubImage3D, - GetTexLevelParameteriv, and GetTexLevelParameterfv: - - TEXTURE_2D_ARRAY_EXT - PROXY_TEXTURE_2D_ARRAY_EXT 0x8C1B - - Accepted by the <pname> parameter of GetBooleanv, GetIntegerv, - GetFloatv, and GetDoublev - - TEXTURE_BINDING_1D_ARRAY_EXT 0x8C1C - TEXTURE_BINDING_2D_ARRAY_EXT 0x8C1D - MAX_ARRAY_TEXTURE_LAYERS_EXT 0x88FF - - Accepted by the <param> parameter of TexParameterf, TexParameteri, - TexParameterfv, and TexParameteriv when the <pname> parameter is - TEXTURE_COMPARE_MODE_ARB: - - COMPARE_REF_DEPTH_TO_TEXTURE_EXT 0x884E - - (Note: COMPARE_REF_DEPTH_TO_TEXTURE_EXT is simply an alias for the - existing COMPARE_R_TO_TEXTURE token in OpenGL 2.0; the alternate name - reflects the fact that the R coordinate is not always used.) - - Accepted by the <internalformat> parameter of TexImage3D and - CompressedTexImage3D, and by the <format> parameter of - CompressedTexSubImage3D: - - COMPRESSED_RGB_S3TC_DXT1_EXT - COMPRESSED_RGBA_S3TC_DXT1_EXT - COMPRESSED_RGBA_S3TC_DXT3_EXT - COMPRESSED_RGBA_S3TC_DXT5_EXT - - Accepted by the <pname> parameter of - GetFramebufferAttachmentParameterivEXT: - - FRAMEBUFFER_ATTACHMENT_TEXTURE_LAYER_EXT 0x8CD4 - - (Note: FRAMEBUFFER_ATTACHMENT_TEXTURE_LAYER is simply an alias for the - FRAMEBUFFER_ATTACHMENT_TEXTURE_3D_ZOFFSET_EXT token provided in - EXT_framebuffer_object. This extension generalizes the notion of - "<zoffset>" to include layers of an array texture.) - -Additions to Chapter 2 of the OpenGL 2.0 Specification (OpenGL Operation) - - None - -Additions to Chapter 3 of the OpenGL 2.0 Specification (Rasterization) - - -- Section 3.8.1 "Texture Image Specification" - - Change the first paragraph (page 150) to say (spec changes identical to - EXT_texture_array): - - "The command - - void TexImage3D(enum target, int level, int internalformat, - sizei width, sizei height, sizei depth, int border, - enum format, enum type, void *data); - - is used to specify a three-dimensional texture image. target must be one - one of TEXTURE_3D for a three-dimensional texture or - TEXTURE_2D_ARRAY_EXT for an two-dimensional array texture. - Additionally, target may be either PROXY_TEXTURE_3D for a - three-dimensional proxy texture, or PROXY_TEXTURE_2D_ARRAY_EXT for a - two-dimensional proxy array texture." - - Change the fourth paragraph on page 151 to say (spec changes identical - to EXT_texture_array): - - "Textures with a base internal format of DEPTH_COMPONENT are supported - by texture image specification commands only if target is TEXTURE_1D, - TEXTURE_2D, TEXTURE_1D_ARRAY_EXT, TEXTURE_2D_ARRAY_EXT, - PROXY_TEXTURE_1D, PROXY_TEXTURE_2D, PROXY_TEXTURE_1D_ARRAY_EXT, or - PROXY_TEXTURE_2D_ARRAY_EXT. Using this format in conjunction with any - other target will result in an INVALID_OPERATION error." - - - Change the fourth paragraph on page 156 to say (spec changes identical - to EXT_texture_array): - - "The command - - void TexImage2D(enum target, int level, - int internalformat, sizei width, sizei height, - int border, enum format, enum type, void *data); - - is used to specify a two-dimensional texture image. target must be one - of TEXTURE_2D for a two-dimensional texture, TEXTURE_1D_ARRAY_EXT for a - one-dimensional array texture, or one of TEXTURE_CUBE_MAP_POSITIVE_X, - TEXTURE_CUBE_MAP_NEGATIVE_X, TEXTURE_CUBE_MAP_POSITIVE_Y, - TEXTURE_CUBE_MAP_NEGATIVE_Y, TEXTURE_CUBE_MAP_POSITIVE_Z, or - TEXTURE_CUBE_MAP_NEGATIVE_Z for a cube map texture. Additionally, - target may be either PROXY_TEXTURE_2D for a two-dimensional proxy - texture, PROXY_TEXTURE_1D_ARRAY_EXT for a one-dimensional proxy array - texture, or PROXY TEXTURE_CUBE_MAP for a cube map proxy texture in the - special case discussed in section 3.8.11. The other parameters match - the corresponding parameters of TexImage3D. - - For the purposes of decoding the texture image, TexImage2D is - equivalent to calling TexImage3D with corresponding arguments and depth - of 1, except that - - * The border depth, d_b, is zero, and the depth of the image is - always 1 regardless of the value of border. - - * The border height, h_b, is zero if <target> is - TEXTURE_1D_ARRAY_EXT, and <border> otherwise. - - * Convolution will be performed on the image (possibly changing its - width and height) if SEPARABLE 2D or CONVOLUTION 2D is enabled. - - * UNPACK SKIP IMAGES is ignored." - - -- Section 3.8.2 "Alternate Texture Image Specification Commands" - - Change the second paragraph (page 159) (spec changes identical - to EXT_texture_array): - - "The command - - void CopyTexImage2D(enum target, int level, - enum internalformat, int x, int y, sizei width, - sizei height, int border); - - defines a two-dimensional texture image in exactly the manner of - TexImage2D, except that the image data are taken from the framebuffer - rather than from client memory. Currently, target must be one of - TEXTURE_2D, TEXTURE_1D_ARRAY_EXT, TEXTURE_CUBE_MAP_POSITIVE_X, - TEXTURE_CUBE_MAP_NEGATIVE_X, TEXTURE_CUBE MAP_POSITIVE_Y, - TEXTURE_CUBE_MAP_NEGATIVE_Y, TEXTURE_CUBE_MAP_POSITIVE_Z, or - TEXTURE_CUBE_MAP_NEGATIVE_Z. - - - Change the last paragraph on page 160 to say (spec changes identical - to EXT_texture_array): - - "Currently the target arguments of TexSubImage1D and CopyTexSubImage1D - must be TEXTURE_1D, the target arguments of TexSubImage2D and - CopyTexSubImage2D must be one of TEXTURE_2D, TEXTURE_1D_ARRAY_EXT, - TEXTURE_CUBE_MAP_POSITIVE_X, TEXTURE_CUBE_MAP_NEGATIVE_X, - TEXTURE_CUBE_MAP_POSITIVE_Y, TEXTURE_CUBE_MAP_NEGATIVE_Y, - TEXTURE_CUBE_MAP_POSITIVE_Z, or TEXTURE_CUBE_MAP_NEGATIVE_Z, and the - target arguments of TexSubImage3D and CopyTexSubImage3D must be - TEXTURE_3D or TEXTURE_2D_ARRAY_EXT. ..." - - - -- Section 3.8.4 "Texture Parameters" - - Change the first paragraph (page 166) to say: - - "Various parameters control how the texel array is treated when - specified or changed, and when applied to a fragment. Each parameter is - set by calling - - void TexParameter{if}(enum target, enum pname, T param); - void TexParameter{if}v(enum target, enum pname, T params); - - target is the target, either TEXTURE_1D, TEXTURE_2D, TEXTURE_3D, - TEXTURE_CUBE_MAP, TEXTURE_1D_ARRAY_EXT, or TEXTURE_2D_ARRAY_EXT." - - - -- Section 3.8.8 "Texture Minification" in the section "Scale Factor and Level of Detail" - - Change the first paragraph (page 172) to say: - - "Let s(x,y) be the function that associates an s texture coordinate - with each set of window coordinates (x,y) that lie within a primitive; - define t(x,y) and r(x,y) analogously. Let u(x,y) = w_t * s(x,y), - v(x,y) = h_t * t(x,y), and w(x,y) = d_t * r(x,y), where w_t, h_t, - and d_t are as defined by equations 3.15, 3.16, and 3.17 with - w_s, h_s, and d_s equal to the width, height, and depth of the - image array whose level is level_base. For a one-dimensional - texture or a one-dimensional array texture, define v(x,y) = 0 and - w(x,y) = 0; for a two-dimensional texture or a two-dimensional array - texture, define w(x,y) = 0..." - - -- Section 3.8.8 "Texture Minification" in the section "Mipmapping" - - Change the third paragraph (page 174) to say: - - "For a two-dimensional texture, two-dimensional array texture, or - cube map texture," - - Change the fourth paragraph (page 174) to say: - - "And for a one-dimensional texture or a one-dimensional array texture," - - After the first paragraph (page 175) add: - - "For one-dimensional array textures, h_b and d_b are treated as 1, - regardless of the actual values, when performing mipmap calculations. - For two-dimensional array textures, d_b is always treated as one, - regardless of the actual value, when performing mipmap calculations." - - -- Section 3.8.8 "Automatic Mipmap Generation" in the section "Mipmapping" - - Change the third paragraph (page 176) to say (spec changes identical - to EXT_texture_array): - - "The contents of the derived arrays are computed by repeated, filtered - reduction of the level_base array. For one- and two-dimensional array - textures, each layer is filtered independently. ..." - - -- Section 3.8.8 "Manual Mipmap Generation" in the section "Mipmapping" - - Change first paragraph to say (spec changes identical to - EXT_texture_array): - - "Mipmaps can be generated manually with the command - - void GenerateMipmapEXT(enum target); - - where <target> is one of TEXTURE_1D, TEXTURE_2D, TEXTURE_CUBE_MAP, - TEXTURE_3D, TEXTURE_1D_ARRAY, or TEXTURE_2D_ARRAY. Mipmap generation - affects the texture image attached to <target>. ..." - - -- Section 3.8.10 "Texture Completeness" - - Change the second paragaph (page 177) to say (spec changes identical - to EXT_texture_array): - - "For one-, two-, or three-dimensional textures and one- or - two-dimensional array textures, a texture is complete if the following - conditions all hold true:" - - -- Section 3.8.11 "Texture State and Proxy State" - - Change the second and third paragraphs (page 179) to say (spec changes - identical to EXT_texture_array): - - "In addition to image arrays for one-, two-, and three-dimensional - textures, one- and two-dimensional array textures, and the six image - arrays for the cube map texture, partially instantiated image arrays - are maintained for one-, two-, and three-dimensional textures and one- - and two-dimensional array textures. Additionally, a single proxy image - array is maintained for the cube map texture. Each proxy image array - includes width, height, depth, border width, and internal format state - values, as well as state for the red, green, blue, alpha, luminance, - and intensity component resolutions. Proxy image arrays do not include - image data, nor do they include texture properties. When TexImage3D is - executed with target specified as PROXY_TEXTURE_3D, the - three-dimensional proxy state values of the specified level-of-detail - are recomputed and updated. If the image array would not be supported - by TexImage3D called with target set to TEXTURE 3D, no error is - generated, but the proxy width, height, depth, border width, and - component resolutions are set to zero. If the image array would be - supported by such a call to TexImage3D, the proxy state values are set - exactly as though the actual image array were being specified. No pixel - data are transferred or processed in either case. - - Proxy arrays for one- and two-dimensional textures and one- and - two-dimensional array textures are operated on in the same way when - TexImage1D is executed with target specified as PROXY_TEXTURE_1D, - TexImage2D is executed with target specified as PROXY_TEXTURE_2D or - PROXY_TEXTURE_1D_ARRAY_EXT, or TexImage3D is executed with target - specified as PROXY_TETXURE_2D_ARRAY_EXT." - - -- Section 3.8.12 "Texture Objects" - - Change section (page 180) to say (spec changes identical to - EXT_texture_array): - - "In addition to the default textures TEXTURE_1D, TEXTURE_2D, - TEXTURE_3D, TEXTURE_CUBE_MAP, TEXTURE_1D_ARRAY_EXT, and TEXTURE_2D_EXT, - named one-, two-, and three-dimensional, cube map, and one- and - two-dimensional array texture objects can be created and operated upon. - The name space for texture objects is the unsigned integers, with zero - reserved by the GL. - - A texture object is created by binding an unused name to TEXTURE_1D, - TEXTURE_2D, TEXTURE_3D, TEXTURE_CUBE_MAP, TEXTURE_1D_ARRAY_EXT, or - TEXTURE_2D_ARRAY_EXT. The binding is effected by calling - - void BindTexture(enum target, uint texture); - - with <target> set to the desired texture target and <texture> set to - the unused name. The resulting texture object is a new state vector, - comprising all the state values listed in section 3.8.11, set to the - same initial values. If the new texture object is bound to TEXTURE_1D, - TEXTURE_2D, TEXTURE_3D, TEXTURE_CUBE_MAP, TEXTURE_1D_ARRAY_EXT, or - TEXTURE_2D_ARRAY_EXT, it is and remains a one-, two-, - three-dimensional, cube map, one- or two-dimensional array texture - respectively until it is deleted. - - BindTexture may also be used to bind an existing texture object to - either TEXTURE_1D, TEXTURE_2D, TEXTURE_3D, TEXTURE_CUBE_MAP, - TEXTURE_1D_ARRAY_EXT, or TEXTURE_2D_ARRAY_EXT. The error - INVALID_OPERATION is generated if an attempt is made to bind a texture - object of different dimensionality than the specified target. If the - bind is successful no change is made to the state of the bound texture - object, and any previous binding to target is broken. - - While a texture object is bound, GL operations on the target to which - it is bound affect the bound object, and queries of the target to which - it is bound return state from the bound object. If texture mapping of - the dimensionality of the target to which a texture object is bound is - enabled, the state of the bound texture object directs the texturing - operation. - - In the initial state, TEXTURE_1D, TEXTURE_2D, TEXTURE_3D, - TEXTURE_CUBE_MAP, TEXTURE_1D_ARRAY_EXT, and TEXTURE_2D_ARRAY_EXT have - one-, two-, three-dimensional, cube map, and one- and two-dimensional - array texture state vectors respectively associated with them. In order - that access to these initial textures not be lost, they are treated as - texture objects all of whose names are 0. The initial one-, two-, - three-dimensional, cube map, one- and two-dimensional array textures - are therefore operated upon, queried, and applied as TEXTURE_1D, - TEXTURE_2D, TEXTURE_3D, TEXTURE_CUBE_MAP, TEXTURE_1D_ARRAY_EXT, and - TEXTURE_2D_ARRAY_EXT respectively while 0 is bound to the corresponding - targets. - - Change second paragraph on page 181 to say (spec changes identical to - EXT_texture_array): - - "... If a texture that is currently bound to one of the targets - TEXTURE_1D, TEXTURE_2D, TEXTURE_3D, TEXTURE_CUBE_MAP, - TEXTURE_1D_ARRAY_EXT, or TEXTURE_2D_ARRAY_EXT is deleted, it is as - though BindTexture had been executed with the same target and texture - zero. ..." - - Change second paragraph on page 182 to say (spec changes identical to - EXT_texture_array): - - "The texture object name space, including the initial one-, two-, and - three dimensional, cube map, and one- and two-dimensional array texture - objects, is shared among all texture units. ..." - - - -- Section 3.8.14 "Depth Texture Comparison Modes" in "Texture Comparison Modes" - - Change second through fourth paragraphs (page 188) to say: - - "Let D_t be the depth texture value, in the range [0, 1]. For - texture lookups from one- and two-dimesional, rectangle, and - one-dimensional array targets, let R be the interpolated <r> - texture coordinate, clamped to the range [0, 1]. For texture lookups - from two-dimesional array texture targets, let R be the interpolated - <q> texture coordinate, clamped to the range [0, 1]. Then the - effective texture value L_t, I_t, or A_t is computed as follows: - - If the value of TEXTURE_COMPARE_MODE is NONE, then - - r = Dt - - If the value of TEXTURE_COMPARE_MODE is - COMPARE_REF_DEPTH_TO_TEXTURE_EXT), then r depends on the texture - comparison function as shown in table 3.27." - - -- Section 3.8.15 "Texture Application" - - Change the first paragraph (page 189) to say: - - "Texturing is enabled or disabled using the generic Enable and Disable - commands, respectively, with the symbolic constants TEXTURE_1D, - TEXTURE_2D, TEXTURE_3D, TEXTURE_CUBE_MAP, TEXTURE_1D_ARRAY_EXT, or - TEXTURE_2D_ARRAY_EXT to enable one-, two-, three-dimensional, cube - map, one-dimensional array, or two-dimensional array texture, - respectively. If both two- and one-dimensional textures are enabled, - the two-dimensional texture is used. If the three-dimensional and - either of the two- or one-dimensional textures is enabled, the - three-dimensional texture is used. If the cube map texture and any of - the three-, two-, or one-dimensional textures is enabled, then cube map - texturing is used. If one-dimensional array texture is enabled and any - of cube map, three-, two-, or one-dimensional textures is enabled, - one-dimensional array texturing is used. If two-dimensional array - texture is enabled and any of cube map, three-, two-, one-dimensional - textures or one-dimensional array texture is enabled, two-dimensional - array texturing is used..." - - -- Section 3.11.2 of ARB_fragment_program (Fragment Program Grammar and Restrictions): - - (mostly add to existing grammar rules) - - <optionName> ::= "MESA_texture_array" - - <texTarget> ::= "1D" - | "2D" - | "3D" - | "CUBE" - | "RECT" - | <arrayTarget> (if program option is present) - | <shadowTarget> (if program option is present) - - <arrayTarget> ::= "ARRAY1D" - | "ARRAY2D" - - <shadowTarget> ::= "SHADOW1D" - | "SHADOW2D" - | "SHADOWRECT" - | <shadowArrayTarget> (if program option is present) - - <shadowArrayTarget> ::= "SHADOWARRAY1D" - | "SHADOWARRAY2D" - - - -- Add Section 3.11.4.5.4 "Texture Stack Option" - - "If a fragment program specifies the "MESA_texture_array" program - option, the <texTarget> rule is modified to add the texture targets - ARRAY1D and ARRAY2D (See Section 3.11.2)." - - -- Section 3.11.6 "Fragment Program Texture Instruction Set" - - (replace 1st and 2nd paragraphs with the following paragraphs) - - "The first three texture instructions described below specify the - mapping of 4-tuple input vectors to 4-tuple output vectors. - The sampling of the texture works as described in section 3.8, - except that texture environments and texture functions are not - applicable, and the texture enables hierarchy is replaced by explicit - references to the desired texture target (i.e., 1D, 2D, 3D, cube map, - rectangle, ARRAY1D, ARRAY2D). These texture instructions specify - how the 4-tuple is mapped into the coordinates used for sampling. The - following function is used to describe the texture sampling in the - descriptions below: - - vec4 TextureSample(vec4 coord, float lodBias, int texImageUnit, - enum texTarget); - - Note that not all four components of the texture coordinates <coord> - are used by all texture targets. Component usage for each <texTarget> - is defined in table X. - - coordinates used - texTarget Texture Type s t r layer shadow - ---------------- --------------------- ----- ----- ------ - 1D TEXTURE_1D x - - - - - 2D TEXTURE_2D x y - - - - 3D TEXTURE_3D x y z - - - CUBE TEXTURE_CUBE_MAP x y z - - - RECT TEXTURE_RECTANGLE_ARB x y - - - - ARRAY1D TEXTURE_1D_ARRAY_EXT x - - y - - ARRAY2D TEXTURE_2D_ARRAY_EXT x y - z - - SHADOW1D TEXTURE_1D x - - - z - SHADOW2D TEXTURE_2D x y - - z - SHADOWRECT TEXTURE_RECTANGLE_ARB x y - - z - SHADOWARRAY1D TEXTURE_1D_ARRAY_EXT x - - y z - SHADOWARRAY2D TEXTURE_2D_ARRAY_EXT x y - z w - - Table X: Texture types accessed for each of the <texTarget>, and - coordinate mappings. The "coordinates used" column indicate the - input values used for each coordinate of the texture lookup, the - layer selector for array textures, and the reference value for - texture comparisons." - - -- Section 3.11.6.2 "TXP: Project coordinate and map to color" - - Add to the end of the section: - - "A program will fail to load if the TXP instruction is used in - conjunction with the SHADOWARRAY2D target." - -Additions to Chapter 4 of the OpenGL 2.0 Specification (Per-Fragment Operations) - - -- Section 4.4.2.3 "Attaching Texture Images to a Framebuffer" - - Add to the end of the section (spec changes identical to - EXT_texture_array): - - "The command - - void FramebufferTextureLayerEXT(enum target, enum attachment, - uint texture, int level, int layer); - - operates identically to FramebufferTexture3DEXT, except that it - attaches a single layer of a three-dimensional texture or a one- or - two-dimensional array texture. <layer> is an integer indicating the - layer number, and is treated identically to the <zoffset> parameter in - FramebufferTexture3DEXT. The error INVALID_VALUE is generated if - <layer> is negative. The error INVALID_OPERATION is generated if - <texture> is non-zero and is not the name of a three dimensional - texture or one- or two-dimensional array texture. Unlike - FramebufferTexture3D, no <textarget> parameter is accepted. - - If <texture> is non-zero and the command does not result in an error, - the framebuffer attachment state corresponding to <attachment> is - updated as in the other FramebufferTexture commands, except that - FRAMEBUFFER_ATTACHMENT_TEXTURE_LAYER_EXT is set to <layer>." - - -- Section 4.4.4.1 "Framebuffer Attachment Completeness" - - Add to the end of the list of completeness rules (spec changes - identical to EXT_texture_array): - - "* If FRAMEBUFFER_ATTACHMENT_OBJECT_TYPE_EXT is TEXTURE and - FRAMEBUFFER_ATTACHMENT_OBJECT_NAME_EXT names a one- or - two-dimensional array texture, then - FRAMEBUFFER_ATTACHMENT_TEXTURE_LAYER_EXT must be smaller than the - number of layers in the texture." - -Additions to Chapter 5 of the OpenGL 2.0 Specification (Special Functions) - - -- Section 5.4 "Display Lists" - - Change the first paragraphi on page 242 to say (spec changes - identical to EXT_texture_array): - - "TexImage3D, TexImage2D, TexImage1D, Histogram, and ColorTable are - executed immediately when called with the corresponding proxy arguments - PROXY_TEXTURE_3D or PROXY_TEXTURE_2D_ARRAY_EXT; PROXY_TEXTURE_2D, - PROXY_TEXTURE_CUBE_MAP, or PROXY_TEXTURE_1D_ARRAY_EXT; - PROXY_TEXTURE_1D; PROXY_HISTOGRAM; and PROXY_COLOR_TABLE, - PROXY_POST_CONVOLUTION_COLOR_TABLE, or - PROXY_POST_COLOR_MATRIX_COLOR_TABLE." - -Additions to Chapter 6 of the OpenGL 2.0 Specification (State and State Requests) - - -- Section 6.1.3 "Enumerated Queries" - - Add after the line beginning "If the value of - FRAMEBUFFER_ATTACHMENT_OBJECT_TYPE_EXT is TEXTURE" (spec changes - identical to EXT_texture_array): - - "If <pname> is FRAMEBUFFER_ATTACHMENT_TEXTURE_LAYER_EXT and the - texture object named FRAMEBUFFER_ATTACHMENT_OBJECT_NAME_EXT is a - three-dimensional texture or a one- or two-dimensional array texture, - then <params> will contain the number of texture layer attached to the - attachment point. Otherwise, <params> will contain the value zero." - - -- Section 6.1.4 "Texture Queries" - - Change the first three paragraphs (page 248) to say (spec changes - identical to EXT_texture_array): - - "The command - - void GetTexImage(enum tex, int lod, enum format, - enum type, void *img); - - is used to obtain texture images. It is somewhat different from the - other get commands; tex is a symbolic value indicating which texture - (or texture face in the case of a cube map texture target name) is to - be obtained. TEXTURE_1D, TEXTURE_2D, TEXTURE_3D, TEXTURE_1D_ARRAY_EXT, - and TEXTURE_2D_ARRAY_EXT indicate a one-, two-, or three-dimensional - texture, or one- or two-dimensional array texture, respectively. - TEXTURE_CUBE_MAP_POSITIVE_X, ... - - GetTexImage obtains... from the first image to the last for - three-dimensional textures. One- and two-dimensional array textures - are treated as two- and three-dimensional images, respectively, where - the layers are treated as rows or images. These groups are then... - - For three-dimensional and two-dimensional array textures, pixel storage - operations are applied as if the image were two-dimensional, except - that the additional pixel storage state values PACK_IMAGE_HEIGHT and - PACK_SKIP_IMAGES are applied. ..." - -Additions to Appendix A of the OpenGL 2.0 Specification (Invariance) - - None - -Additions to the AGL/GLX/WGL Specifications - - None - -GLX Protocol - - None - -Dependencies on ARB_fragment_program - - If ARB_fragment_program is not supported, the changes to section 3.11 - should be ignored. - -Dependencies on EXT_framebuffer_object - - If EXT_framebuffer_object is not supported, the changes to section - 3.8.8 ("Manual Mipmap Generation"), 4.4.2.3, and 6.1.3 should be ignored. - -Dependencies on EXT_texture_compression_s3tc and NV_texture_compression_vtc - - (Identical dependency as EXT_texture_array.) - - S3TC texture compression is supported for two-dimensional array textures. - When <target> is TEXTURE_2D_ARRAY_EXT, each layer is stored independently - as a compressed two-dimensional textures. When specifying or querying - compressed images using one of the S3TC formats, the images are provided - and/or returned as a series of two-dimensional textures stored - consecutively in memory, with the layer closest to zero specified first. - For array textures, images are not arranged in 4x4x4 or 4x4x2 blocks as in - the three-dimensional compression format provided in the - EXT_texture_compression_vtc extension. Pixel store parameters, including - those specific to three-dimensional images, are ignored when compressed - image data are provided or returned, as in the - EXT_texture_compression_s3tc extension. - - S3TC compression is not supported for one-dimensional texture targets in - EXT_texture_compression_s3tc, and is not supported for one-dimensional - array textures in this extension. If compressed one-dimensional arrays - are needed, use a two-dimensional texture with a height of one. - - This extension allows the use of the four S3TC internal format types in - TexImage3D, CompressedTexImage3D, and CompressedTexSubImage3D calls. - -Errors - - None - -New State - - (add to table 6.15, p. 276) - - Initial - Get Value Type Get Command Value Description Sec. Attribute - ---------------------------- ----- ----------- ----- -------------------- ------ --------- - TEXTURE_BINDING_1D_ARRAY_EXT 2*xZ+ GetIntegerv 0 texture object bound 3.8.12 texture - to TEXTURE_1D_ARRAY - TEXTURE_BINDING_2D_ARRAY_EXT 2*xZ+ GetIntegerv 0 texture object bound 3.8.12 texture - to TEXTURE_2D_ARRAY - - -New Implementation Dependent State - - (add to Table 6.32, p. 293) - - Minimum - Get Value Type Get Command Value Description Sec. Attribute - ---------------------------- ---- ----------- ------- ------------------ ----- --------- - MAX_TEXTURE_ARRAY_LAYERS_EXT Z+ GetIntegerv 64 maximum number of 3.8.1 - - layers for texture - arrays - -Issues - - (1) Is "texture stack" a good name for this functionality? - - NO. The name is changed to "array texture" to match the - nomenclature used by GL_EXT_texture_array. - - (2) Should the R texture coordinate be treated as normalized or - un-normalized? If it were un-normalized, floor(R) could be thought - of as a direct index into the array texture. This may be more - convenient for applications. - - RESOLVED. All texture coordinates are normalized. The issue of - un-normalized texture coordinates has been discussed in the ARB - before and should be left for a layered extension. - - RE-RESOLVED. The R coordinate is un-normalized. Accessing an array - using [0, layers-1] coordinates is much more natural. - - (3) How does LOD selection work for stacked textures? - - RESOLVED. For 2D array textures the R coordinate is ignored, and - the LOD selection equations for 2D textures are used. For 1D - array textures the T coordinate is ignored, and the LOD selection - equations for 1D textures are used. The expected usage is in a - fragment program with an explicit LOD selection. - - (4) What is the maximum size of a 2D array texture? Is it the same - as for a 3D texture, or should a new query be added? How about for 1D - array textures? - - RESOLVED. A new query is added. - - (5) How are array textures exposed in GLSL? - - RESOLVED. Use GL_EXT_texture_array. - - (6) Should a 1D array texture also be exposed? - - RESOLVED. For orthogonality, yes. - - (7) How are stacked textures attached to framebuffer objects? - - RESOLVED. Layers of both one- and two-dimensional array textures - are attached using FreambufferTextureLayerEXT. Once attached, the - array texture layer behaves exactly as either a one- or - two-dimensional texture. - - (8) How is this extension related to GL_EXT_texture_array? - - This extension adapats GL_MESAX_texture_stack to the notation, - indexing, and FBO access of GL_EXT_texture_array. This extension - replaces the GLSL support of GL_EXT_texture_array with - GL_ARB_fragment_program support. - - Assembly program support is also provided by GL_NV_gpu_program4. - GL_NV_gpu_program4 also adds support for other features that are - specific to Nvidia hardware, while this extension adds only support - for array textures. - - Much of text of this extension that has changed since - GL_MESAX_texture_stack comes directly from either - GL_EXT_texture_array or GL_NV_gpu_program4. - -Revision History - - ||2005/11/15||0.1||idr||Initial draft MESAX version.|| - ||2005/12/07||0.2||idr||Added framebuffer object interactions.|| - ||2005/12/12||0.3||idr||Updated fragment program interactions.|| - ||2007/05/16||0.4||idr||Converted to MESA_texture_array. Brought in line with EXT_texture_array and NV_gpu_program4.|| +Name
+
+ MESA_texture_array
+
+Name Strings
+
+ GL_MESA_texture_array
+
+Contact
+
+ Ian Romanick, IBM (idr 'at' us.ibm.com)
+
+IP Status
+
+ No known IP issues.
+
+Status
+
+ Shipping in Mesa 7.1
+
+Version
+
+
+Number
+
+ TBD
+
+Dependencies
+
+ OpenGL 1.2 or GL_EXT_texture3D is required.
+
+ Support for ARB_fragment_program is assumed, but not required.
+
+ Support for ARB_fragment_program_shadow is assumed, but not required.
+
+ Support for EXT_framebuffer_object is assumed, but not required.
+
+ Written based on the wording of the OpenGL 2.0 specification and
+ ARB_fragment_program_shadow but not dependent on them.
+
+Overview
+
+ There are a number of circumstances where an application may wish to
+ blend two textures out of a larger set of textures. Moreover, in some
+ cases the selected textures may vary on a per-fragment basis within
+ a polygon. Several examples include:
+
+ 1. High dynamic range textures. The application stores several
+ different "exposures" of an image as different textures. On a
+ per-fragment basis, the application selects which exposures are
+ used.
+
+ 2. A terrain engine where the altitude of a point determines the
+ texture applied to it. If the transition is from beach sand to
+ grass to rocks to snow, the application will store each texture
+ in a different texture map, and dynamically select which two
+ textures to blend at run-time.
+
+ 3. Storing short video clips in textures. Each depth slice is a
+ single frame of video.
+
+ Several solutions to this problem have been proposed, but they either
+ involve using a separate texture unit for each texture map or using 3D
+ textures without mipmaps. Both of these options have major drawbacks.
+
+ This extension provides a third alternative that eliminates the major
+ drawbacks of both previous methods. A new texture target,
+ TEXTURE_2D_ARRAY, is added that functions identically to TEXTURE_3D in
+ all aspects except the sizes of the non-base level images. In
+ traditional 3D texturing, the size of the N+1 LOD is half the size
+ of the N LOD in all three dimensions. For the TEXTURE_2D_ARRAY target,
+ the height and width of the N+1 LOD is halved, but the depth is the
+ same for all levels of detail. The texture then becomes an array of
+ 2D textures. The per-fragment texel is selected by the R texture
+ coordinate.
+
+ References:
+
+ http://www.opengl.org/discussion_boards/cgi_directory/ultimatebb.cgi?ubb=get_topic;f=3;t=011557
+ http://www.opengl.org/discussion_boards/cgi_directory/ultimatebb.cgi?ubb=get_topic;f=3;t=000516
+ http://www.opengl.org/discussion_boards/cgi_directory/ultimatebb.cgi?ubb=get_topic;f=3;t=011903
+ http://www.delphi3d.net/articles/viewarticle.php?article=terraintex.htm
+
+New Procedures and Functions
+
+ All functions come directly from EXT_texture_array.
+
+ void FramebufferTextureLayerEXT(enum target, enum attachment,
+ uint texture, int level, int layer);
+
+New Tokens
+
+ All token names and values come directly from EXT_texture_array.
+
+ Accepted by the <cap> parameter of Enable, Disable, and IsEnabled, by
+ the <pname> parameter of GetBooleanv, GetIntegerv, GetFloatv, and
+ GetDoublev, and by the <target> parameter of TexImage3D, GetTexImage,
+ GetTexLevelParameteriv, GetTexLevelParameterfv, GetTexParameteriv, and
+ GetTexParameterfv:
+
+ TEXTURE_1D_ARRAY_EXT 0x8C18
+ TEXTURE_2D_ARRAY_EXT 0x8C1A
+
+ Accepted by the <target> parameter of TexImage2D, TexSubImage2D,
+ CopyTexImage2D, CopyTexSubImage2D, CompressedTexImage2D,
+ CompressedTexSubImage2D, GetTexLevelParameteriv, and
+ GetTexLevelParameterfv:
+
+ TEXTURE_1D_ARRAY_EXT
+ PROXY_TEXTURE_1D_ARRAY_EXT 0x8C19
+
+ Accepted by the <target> parameter of TexImage3D, TexSubImage3D,
+ CopyTexSubImage3D, CompressedTexImage3D, CompressedTexSubImage3D,
+ GetTexLevelParameteriv, and GetTexLevelParameterfv:
+
+ TEXTURE_2D_ARRAY_EXT
+ PROXY_TEXTURE_2D_ARRAY_EXT 0x8C1B
+
+ Accepted by the <pname> parameter of GetBooleanv, GetIntegerv,
+ GetFloatv, and GetDoublev
+
+ TEXTURE_BINDING_1D_ARRAY_EXT 0x8C1C
+ TEXTURE_BINDING_2D_ARRAY_EXT 0x8C1D
+ MAX_ARRAY_TEXTURE_LAYERS_EXT 0x88FF
+
+ Accepted by the <param> parameter of TexParameterf, TexParameteri,
+ TexParameterfv, and TexParameteriv when the <pname> parameter is
+ TEXTURE_COMPARE_MODE_ARB:
+
+ COMPARE_REF_DEPTH_TO_TEXTURE_EXT 0x884E
+
+ (Note: COMPARE_REF_DEPTH_TO_TEXTURE_EXT is simply an alias for the
+ existing COMPARE_R_TO_TEXTURE token in OpenGL 2.0; the alternate name
+ reflects the fact that the R coordinate is not always used.)
+
+ Accepted by the <internalformat> parameter of TexImage3D and
+ CompressedTexImage3D, and by the <format> parameter of
+ CompressedTexSubImage3D:
+
+ COMPRESSED_RGB_S3TC_DXT1_EXT
+ COMPRESSED_RGBA_S3TC_DXT1_EXT
+ COMPRESSED_RGBA_S3TC_DXT3_EXT
+ COMPRESSED_RGBA_S3TC_DXT5_EXT
+
+ Accepted by the <pname> parameter of
+ GetFramebufferAttachmentParameterivEXT:
+
+ FRAMEBUFFER_ATTACHMENT_TEXTURE_LAYER_EXT 0x8CD4
+
+ (Note: FRAMEBUFFER_ATTACHMENT_TEXTURE_LAYER is simply an alias for the
+ FRAMEBUFFER_ATTACHMENT_TEXTURE_3D_ZOFFSET_EXT token provided in
+ EXT_framebuffer_object. This extension generalizes the notion of
+ "<zoffset>" to include layers of an array texture.)
+
+Additions to Chapter 2 of the OpenGL 2.0 Specification (OpenGL Operation)
+
+ None
+
+Additions to Chapter 3 of the OpenGL 2.0 Specification (Rasterization)
+
+ -- Section 3.8.1 "Texture Image Specification"
+
+ Change the first paragraph (page 150) to say (spec changes identical to
+ EXT_texture_array):
+
+ "The command
+
+ void TexImage3D(enum target, int level, int internalformat,
+ sizei width, sizei height, sizei depth, int border,
+ enum format, enum type, void *data);
+
+ is used to specify a three-dimensional texture image. target must be one
+ one of TEXTURE_3D for a three-dimensional texture or
+ TEXTURE_2D_ARRAY_EXT for an two-dimensional array texture.
+ Additionally, target may be either PROXY_TEXTURE_3D for a
+ three-dimensional proxy texture, or PROXY_TEXTURE_2D_ARRAY_EXT for a
+ two-dimensional proxy array texture."
+
+ Change the fourth paragraph on page 151 to say (spec changes identical
+ to EXT_texture_array):
+
+ "Textures with a base internal format of DEPTH_COMPONENT are supported
+ by texture image specification commands only if target is TEXTURE_1D,
+ TEXTURE_2D, TEXTURE_1D_ARRAY_EXT, TEXTURE_2D_ARRAY_EXT,
+ PROXY_TEXTURE_1D, PROXY_TEXTURE_2D, PROXY_TEXTURE_1D_ARRAY_EXT, or
+ PROXY_TEXTURE_2D_ARRAY_EXT. Using this format in conjunction with any
+ other target will result in an INVALID_OPERATION error."
+
+
+ Change the fourth paragraph on page 156 to say (spec changes identical
+ to EXT_texture_array):
+
+ "The command
+
+ void TexImage2D(enum target, int level,
+ int internalformat, sizei width, sizei height,
+ int border, enum format, enum type, void *data);
+
+ is used to specify a two-dimensional texture image. target must be one
+ of TEXTURE_2D for a two-dimensional texture, TEXTURE_1D_ARRAY_EXT for a
+ one-dimensional array texture, or one of TEXTURE_CUBE_MAP_POSITIVE_X,
+ TEXTURE_CUBE_MAP_NEGATIVE_X, TEXTURE_CUBE_MAP_POSITIVE_Y,
+ TEXTURE_CUBE_MAP_NEGATIVE_Y, TEXTURE_CUBE_MAP_POSITIVE_Z, or
+ TEXTURE_CUBE_MAP_NEGATIVE_Z for a cube map texture. Additionally,
+ target may be either PROXY_TEXTURE_2D for a two-dimensional proxy
+ texture, PROXY_TEXTURE_1D_ARRAY_EXT for a one-dimensional proxy array
+ texture, or PROXY TEXTURE_CUBE_MAP for a cube map proxy texture in the
+ special case discussed in section 3.8.11. The other parameters match
+ the corresponding parameters of TexImage3D.
+
+ For the purposes of decoding the texture image, TexImage2D is
+ equivalent to calling TexImage3D with corresponding arguments and depth
+ of 1, except that
+
+ * The border depth, d_b, is zero, and the depth of the image is
+ always 1 regardless of the value of border.
+
+ * The border height, h_b, is zero if <target> is
+ TEXTURE_1D_ARRAY_EXT, and <border> otherwise.
+
+ * Convolution will be performed on the image (possibly changing its
+ width and height) if SEPARABLE 2D or CONVOLUTION 2D is enabled.
+
+ * UNPACK SKIP IMAGES is ignored."
+
+ -- Section 3.8.2 "Alternate Texture Image Specification Commands"
+
+ Change the second paragraph (page 159) (spec changes identical
+ to EXT_texture_array):
+
+ "The command
+
+ void CopyTexImage2D(enum target, int level,
+ enum internalformat, int x, int y, sizei width,
+ sizei height, int border);
+
+ defines a two-dimensional texture image in exactly the manner of
+ TexImage2D, except that the image data are taken from the framebuffer
+ rather than from client memory. Currently, target must be one of
+ TEXTURE_2D, TEXTURE_1D_ARRAY_EXT, TEXTURE_CUBE_MAP_POSITIVE_X,
+ TEXTURE_CUBE_MAP_NEGATIVE_X, TEXTURE_CUBE MAP_POSITIVE_Y,
+ TEXTURE_CUBE_MAP_NEGATIVE_Y, TEXTURE_CUBE_MAP_POSITIVE_Z, or
+ TEXTURE_CUBE_MAP_NEGATIVE_Z.
+
+
+ Change the last paragraph on page 160 to say (spec changes identical
+ to EXT_texture_array):
+
+ "Currently the target arguments of TexSubImage1D and CopyTexSubImage1D
+ must be TEXTURE_1D, the target arguments of TexSubImage2D and
+ CopyTexSubImage2D must be one of TEXTURE_2D, TEXTURE_1D_ARRAY_EXT,
+ TEXTURE_CUBE_MAP_POSITIVE_X, TEXTURE_CUBE_MAP_NEGATIVE_X,
+ TEXTURE_CUBE_MAP_POSITIVE_Y, TEXTURE_CUBE_MAP_NEGATIVE_Y,
+ TEXTURE_CUBE_MAP_POSITIVE_Z, or TEXTURE_CUBE_MAP_NEGATIVE_Z, and the
+ target arguments of TexSubImage3D and CopyTexSubImage3D must be
+ TEXTURE_3D or TEXTURE_2D_ARRAY_EXT. ..."
+
+
+ -- Section 3.8.4 "Texture Parameters"
+
+ Change the first paragraph (page 166) to say:
+
+ "Various parameters control how the texel array is treated when
+ specified or changed, and when applied to a fragment. Each parameter is
+ set by calling
+
+ void TexParameter{if}(enum target, enum pname, T param);
+ void TexParameter{if}v(enum target, enum pname, T params);
+
+ target is the target, either TEXTURE_1D, TEXTURE_2D, TEXTURE_3D,
+ TEXTURE_CUBE_MAP, TEXTURE_1D_ARRAY_EXT, or TEXTURE_2D_ARRAY_EXT."
+
+
+ -- Section 3.8.8 "Texture Minification" in the section "Scale Factor and Level of Detail"
+
+ Change the first paragraph (page 172) to say:
+
+ "Let s(x,y) be the function that associates an s texture coordinate
+ with each set of window coordinates (x,y) that lie within a primitive;
+ define t(x,y) and r(x,y) analogously. Let u(x,y) = w_t * s(x,y),
+ v(x,y) = h_t * t(x,y), and w(x,y) = d_t * r(x,y), where w_t, h_t,
+ and d_t are as defined by equations 3.15, 3.16, and 3.17 with
+ w_s, h_s, and d_s equal to the width, height, and depth of the
+ image array whose level is level_base. For a one-dimensional
+ texture or a one-dimensional array texture, define v(x,y) = 0 and
+ w(x,y) = 0; for a two-dimensional texture or a two-dimensional array
+ texture, define w(x,y) = 0..."
+
+ -- Section 3.8.8 "Texture Minification" in the section "Mipmapping"
+
+ Change the third paragraph (page 174) to say:
+
+ "For a two-dimensional texture, two-dimensional array texture, or
+ cube map texture,"
+
+ Change the fourth paragraph (page 174) to say:
+
+ "And for a one-dimensional texture or a one-dimensional array texture,"
+
+ After the first paragraph (page 175) add:
+
+ "For one-dimensional array textures, h_b and d_b are treated as 1,
+ regardless of the actual values, when performing mipmap calculations.
+ For two-dimensional array textures, d_b is always treated as one,
+ regardless of the actual value, when performing mipmap calculations."
+
+ -- Section 3.8.8 "Automatic Mipmap Generation" in the section "Mipmapping"
+
+ Change the third paragraph (page 176) to say (spec changes identical
+ to EXT_texture_array):
+
+ "The contents of the derived arrays are computed by repeated, filtered
+ reduction of the level_base array. For one- and two-dimensional array
+ textures, each layer is filtered independently. ..."
+
+ -- Section 3.8.8 "Manual Mipmap Generation" in the section "Mipmapping"
+
+ Change first paragraph to say (spec changes identical to
+ EXT_texture_array):
+
+ "Mipmaps can be generated manually with the command
+
+ void GenerateMipmapEXT(enum target);
+
+ where <target> is one of TEXTURE_1D, TEXTURE_2D, TEXTURE_CUBE_MAP,
+ TEXTURE_3D, TEXTURE_1D_ARRAY, or TEXTURE_2D_ARRAY. Mipmap generation
+ affects the texture image attached to <target>. ..."
+
+ -- Section 3.8.10 "Texture Completeness"
+
+ Change the second paragraph (page 177) to say (spec changes identical
+ to EXT_texture_array):
+
+ "For one-, two-, or three-dimensional textures and one- or
+ two-dimensional array textures, a texture is complete if the following
+ conditions all hold true:"
+
+ -- Section 3.8.11 "Texture State and Proxy State"
+
+ Change the second and third paragraphs (page 179) to say (spec changes
+ identical to EXT_texture_array):
+
+ "In addition to image arrays for one-, two-, and three-dimensional
+ textures, one- and two-dimensional array textures, and the six image
+ arrays for the cube map texture, partially instantiated image arrays
+ are maintained for one-, two-, and three-dimensional textures and one-
+ and two-dimensional array textures. Additionally, a single proxy image
+ array is maintained for the cube map texture. Each proxy image array
+ includes width, height, depth, border width, and internal format state
+ values, as well as state for the red, green, blue, alpha, luminance,
+ and intensity component resolutions. Proxy image arrays do not include
+ image data, nor do they include texture properties. When TexImage3D is
+ executed with target specified as PROXY_TEXTURE_3D, the
+ three-dimensional proxy state values of the specified level-of-detail
+ are recomputed and updated. If the image array would not be supported
+ by TexImage3D called with target set to TEXTURE 3D, no error is
+ generated, but the proxy width, height, depth, border width, and
+ component resolutions are set to zero. If the image array would be
+ supported by such a call to TexImage3D, the proxy state values are set
+ exactly as though the actual image array were being specified. No pixel
+ data are transferred or processed in either case.
+
+ Proxy arrays for one- and two-dimensional textures and one- and
+ two-dimensional array textures are operated on in the same way when
+ TexImage1D is executed with target specified as PROXY_TEXTURE_1D,
+ TexImage2D is executed with target specified as PROXY_TEXTURE_2D or
+ PROXY_TEXTURE_1D_ARRAY_EXT, or TexImage3D is executed with target
+ specified as PROXY_TETXURE_2D_ARRAY_EXT."
+
+ -- Section 3.8.12 "Texture Objects"
+
+ Change section (page 180) to say (spec changes identical to
+ EXT_texture_array):
+
+ "In addition to the default textures TEXTURE_1D, TEXTURE_2D,
+ TEXTURE_3D, TEXTURE_CUBE_MAP, TEXTURE_1D_ARRAY_EXT, and TEXTURE_2D_EXT,
+ named one-, two-, and three-dimensional, cube map, and one- and
+ two-dimensional array texture objects can be created and operated upon.
+ The name space for texture objects is the unsigned integers, with zero
+ reserved by the GL.
+
+ A texture object is created by binding an unused name to TEXTURE_1D,
+ TEXTURE_2D, TEXTURE_3D, TEXTURE_CUBE_MAP, TEXTURE_1D_ARRAY_EXT, or
+ TEXTURE_2D_ARRAY_EXT. The binding is effected by calling
+
+ void BindTexture(enum target, uint texture);
+
+ with <target> set to the desired texture target and <texture> set to
+ the unused name. The resulting texture object is a new state vector,
+ comprising all the state values listed in section 3.8.11, set to the
+ same initial values. If the new texture object is bound to TEXTURE_1D,
+ TEXTURE_2D, TEXTURE_3D, TEXTURE_CUBE_MAP, TEXTURE_1D_ARRAY_EXT, or
+ TEXTURE_2D_ARRAY_EXT, it is and remains a one-, two-,
+ three-dimensional, cube map, one- or two-dimensional array texture
+ respectively until it is deleted.
+
+ BindTexture may also be used to bind an existing texture object to
+ either TEXTURE_1D, TEXTURE_2D, TEXTURE_3D, TEXTURE_CUBE_MAP,
+ TEXTURE_1D_ARRAY_EXT, or TEXTURE_2D_ARRAY_EXT. The error
+ INVALID_OPERATION is generated if an attempt is made to bind a texture
+ object of different dimensionality than the specified target. If the
+ bind is successful no change is made to the state of the bound texture
+ object, and any previous binding to target is broken.
+
+ While a texture object is bound, GL operations on the target to which
+ it is bound affect the bound object, and queries of the target to which
+ it is bound return state from the bound object. If texture mapping of
+ the dimensionality of the target to which a texture object is bound is
+ enabled, the state of the bound texture object directs the texturing
+ operation.
+
+ In the initial state, TEXTURE_1D, TEXTURE_2D, TEXTURE_3D,
+ TEXTURE_CUBE_MAP, TEXTURE_1D_ARRAY_EXT, and TEXTURE_2D_ARRAY_EXT have
+ one-, two-, three-dimensional, cube map, and one- and two-dimensional
+ array texture state vectors respectively associated with them. In order
+ that access to these initial textures not be lost, they are treated as
+ texture objects all of whose names are 0. The initial one-, two-,
+ three-dimensional, cube map, one- and two-dimensional array textures
+ are therefore operated upon, queried, and applied as TEXTURE_1D,
+ TEXTURE_2D, TEXTURE_3D, TEXTURE_CUBE_MAP, TEXTURE_1D_ARRAY_EXT, and
+ TEXTURE_2D_ARRAY_EXT respectively while 0 is bound to the corresponding
+ targets.
+
+ Change second paragraph on page 181 to say (spec changes identical to
+ EXT_texture_array):
+
+ "... If a texture that is currently bound to one of the targets
+ TEXTURE_1D, TEXTURE_2D, TEXTURE_3D, TEXTURE_CUBE_MAP,
+ TEXTURE_1D_ARRAY_EXT, or TEXTURE_2D_ARRAY_EXT is deleted, it is as
+ though BindTexture had been executed with the same target and texture
+ zero. ..."
+
+ Change second paragraph on page 182 to say (spec changes identical to
+ EXT_texture_array):
+
+ "The texture object name space, including the initial one-, two-, and
+ three dimensional, cube map, and one- and two-dimensional array texture
+ objects, is shared among all texture units. ..."
+
+
+ -- Section 3.8.14 "Depth Texture Comparison Modes" in "Texture Comparison Modes"
+
+ Change second through fourth paragraphs (page 188) to say:
+
+ "Let D_t be the depth texture value, in the range [0, 1]. For
+ texture lookups from one- and two-dimensional, rectangle, and
+ one-dimensional array targets, let R be the interpolated <r>
+ texture coordinate, clamped to the range [0, 1]. For texture lookups
+ from two-dimensional array texture targets, let R be the interpolated
+ <q> texture coordinate, clamped to the range [0, 1]. Then the
+ effective texture value L_t, I_t, or A_t is computed as follows:
+
+ If the value of TEXTURE_COMPARE_MODE is NONE, then
+
+ r = Dt
+
+ If the value of TEXTURE_COMPARE_MODE is
+ COMPARE_REF_DEPTH_TO_TEXTURE_EXT), then r depends on the texture
+ comparison function as shown in table 3.27."
+
+ -- Section 3.8.15 "Texture Application"
+
+ Change the first paragraph (page 189) to say:
+
+ "Texturing is enabled or disabled using the generic Enable and Disable
+ commands, respectively, with the symbolic constants TEXTURE_1D,
+ TEXTURE_2D, TEXTURE_3D, TEXTURE_CUBE_MAP, TEXTURE_1D_ARRAY_EXT, or
+ TEXTURE_2D_ARRAY_EXT to enable one-, two-, three-dimensional, cube
+ map, one-dimensional array, or two-dimensional array texture,
+ respectively. If both two- and one-dimensional textures are enabled,
+ the two-dimensional texture is used. If the three-dimensional and
+ either of the two- or one-dimensional textures is enabled, the
+ three-dimensional texture is used. If the cube map texture and any of
+ the three-, two-, or one-dimensional textures is enabled, then cube map
+ texturing is used. If one-dimensional array texture is enabled and any
+ of cube map, three-, two-, or one-dimensional textures is enabled,
+ one-dimensional array texturing is used. If two-dimensional array
+ texture is enabled and any of cube map, three-, two-, one-dimensional
+ textures or one-dimensional array texture is enabled, two-dimensional
+ array texturing is used..."
+
+ -- Section 3.11.2 of ARB_fragment_program (Fragment Program Grammar and Restrictions):
+
+ (mostly add to existing grammar rules)
+
+ <optionName> ::= "MESA_texture_array"
+
+ <texTarget> ::= "1D"
+ | "2D"
+ | "3D"
+ | "CUBE"
+ | "RECT"
+ | <arrayTarget> (if program option is present)
+ | <shadowTarget> (if program option is present)
+
+ <arrayTarget> ::= "ARRAY1D"
+ | "ARRAY2D"
+
+ <shadowTarget> ::= "SHADOW1D"
+ | "SHADOW2D"
+ | "SHADOWRECT"
+ | <shadowArrayTarget> (if program option is present)
+
+ <shadowArrayTarget> ::= "SHADOWARRAY1D"
+ | "SHADOWARRAY2D"
+
+
+ -- Add Section 3.11.4.5.4 "Texture Stack Option"
+
+ "If a fragment program specifies the "MESA_texture_array" program
+ option, the <texTarget> rule is modified to add the texture targets
+ ARRAY1D and ARRAY2D (See Section 3.11.2)."
+
+ -- Section 3.11.6 "Fragment Program Texture Instruction Set"
+
+ (replace 1st and 2nd paragraphs with the following paragraphs)
+
+ "The first three texture instructions described below specify the
+ mapping of 4-tuple input vectors to 4-tuple output vectors.
+ The sampling of the texture works as described in section 3.8,
+ except that texture environments and texture functions are not
+ applicable, and the texture enables hierarchy is replaced by explicit
+ references to the desired texture target (i.e., 1D, 2D, 3D, cube map,
+ rectangle, ARRAY1D, ARRAY2D). These texture instructions specify
+ how the 4-tuple is mapped into the coordinates used for sampling. The
+ following function is used to describe the texture sampling in the
+ descriptions below:
+
+ vec4 TextureSample(vec4 coord, float lodBias, int texImageUnit,
+ enum texTarget);
+
+ Note that not all four components of the texture coordinates <coord>
+ are used by all texture targets. Component usage for each <texTarget>
+ is defined in table X.
+
+ coordinates used
+ texTarget Texture Type s t r layer shadow
+ ---------------- --------------------- ----- ----- ------
+ 1D TEXTURE_1D x - - - -
+ 2D TEXTURE_2D x y - - -
+ 3D TEXTURE_3D x y z - -
+ CUBE TEXTURE_CUBE_MAP x y z - -
+ RECT TEXTURE_RECTANGLE_ARB x y - - -
+ ARRAY1D TEXTURE_1D_ARRAY_EXT x - - y -
+ ARRAY2D TEXTURE_2D_ARRAY_EXT x y - z -
+ SHADOW1D TEXTURE_1D x - - - z
+ SHADOW2D TEXTURE_2D x y - - z
+ SHADOWRECT TEXTURE_RECTANGLE_ARB x y - - z
+ SHADOWARRAY1D TEXTURE_1D_ARRAY_EXT x - - y z
+ SHADOWARRAY2D TEXTURE_2D_ARRAY_EXT x y - z w
+
+ Table X: Texture types accessed for each of the <texTarget>, and
+ coordinate mappings. The "coordinates used" column indicate the
+ input values used for each coordinate of the texture lookup, the
+ layer selector for array textures, and the reference value for
+ texture comparisons."
+
+ -- Section 3.11.6.2 "TXP: Project coordinate and map to color"
+
+ Add to the end of the section:
+
+ "A program will fail to load if the TXP instruction is used in
+ conjunction with the SHADOWARRAY2D target."
+
+Additions to Chapter 4 of the OpenGL 2.0 Specification (Per-Fragment Operations)
+
+ -- Section 4.4.2.3 "Attaching Texture Images to a Framebuffer"
+
+ Add to the end of the section (spec changes identical to
+ EXT_texture_array):
+
+ "The command
+
+ void FramebufferTextureLayerEXT(enum target, enum attachment,
+ uint texture, int level, int layer);
+
+ operates identically to FramebufferTexture3DEXT, except that it
+ attaches a single layer of a three-dimensional texture or a one- or
+ two-dimensional array texture. <layer> is an integer indicating the
+ layer number, and is treated identically to the <zoffset> parameter in
+ FramebufferTexture3DEXT. The error INVALID_VALUE is generated if
+ <layer> is negative. The error INVALID_OPERATION is generated if
+ <texture> is non-zero and is not the name of a three dimensional
+ texture or one- or two-dimensional array texture. Unlike
+ FramebufferTexture3D, no <textarget> parameter is accepted.
+
+ If <texture> is non-zero and the command does not result in an error,
+ the framebuffer attachment state corresponding to <attachment> is
+ updated as in the other FramebufferTexture commands, except that
+ FRAMEBUFFER_ATTACHMENT_TEXTURE_LAYER_EXT is set to <layer>."
+
+ -- Section 4.4.4.1 "Framebuffer Attachment Completeness"
+
+ Add to the end of the list of completeness rules (spec changes
+ identical to EXT_texture_array):
+
+ "* If FRAMEBUFFER_ATTACHMENT_OBJECT_TYPE_EXT is TEXTURE and
+ FRAMEBUFFER_ATTACHMENT_OBJECT_NAME_EXT names a one- or
+ two-dimensional array texture, then
+ FRAMEBUFFER_ATTACHMENT_TEXTURE_LAYER_EXT must be smaller than the
+ number of layers in the texture."
+
+Additions to Chapter 5 of the OpenGL 2.0 Specification (Special Functions)
+
+ -- Section 5.4 "Display Lists"
+
+ Change the first paragraph on page 242 to say (spec changes
+ identical to EXT_texture_array):
+
+ "TexImage3D, TexImage2D, TexImage1D, Histogram, and ColorTable are
+ executed immediately when called with the corresponding proxy arguments
+ PROXY_TEXTURE_3D or PROXY_TEXTURE_2D_ARRAY_EXT; PROXY_TEXTURE_2D,
+ PROXY_TEXTURE_CUBE_MAP, or PROXY_TEXTURE_1D_ARRAY_EXT;
+ PROXY_TEXTURE_1D; PROXY_HISTOGRAM; and PROXY_COLOR_TABLE,
+ PROXY_POST_CONVOLUTION_COLOR_TABLE, or
+ PROXY_POST_COLOR_MATRIX_COLOR_TABLE."
+
+Additions to Chapter 6 of the OpenGL 2.0 Specification (State and State Requests)
+
+ -- Section 6.1.3 "Enumerated Queries"
+
+ Add after the line beginning "If the value of
+ FRAMEBUFFER_ATTACHMENT_OBJECT_TYPE_EXT is TEXTURE" (spec changes
+ identical to EXT_texture_array):
+
+ "If <pname> is FRAMEBUFFER_ATTACHMENT_TEXTURE_LAYER_EXT and the
+ texture object named FRAMEBUFFER_ATTACHMENT_OBJECT_NAME_EXT is a
+ three-dimensional texture or a one- or two-dimensional array texture,
+ then <params> will contain the number of texture layer attached to the
+ attachment point. Otherwise, <params> will contain the value zero."
+
+ -- Section 6.1.4 "Texture Queries"
+
+ Change the first three paragraphs (page 248) to say (spec changes
+ identical to EXT_texture_array):
+
+ "The command
+
+ void GetTexImage(enum tex, int lod, enum format,
+ enum type, void *img);
+
+ is used to obtain texture images. It is somewhat different from the
+ other get commands; tex is a symbolic value indicating which texture
+ (or texture face in the case of a cube map texture target name) is to
+ be obtained. TEXTURE_1D, TEXTURE_2D, TEXTURE_3D, TEXTURE_1D_ARRAY_EXT,
+ and TEXTURE_2D_ARRAY_EXT indicate a one-, two-, or three-dimensional
+ texture, or one- or two-dimensional array texture, respectively.
+ TEXTURE_CUBE_MAP_POSITIVE_X, ...
+
+ GetTexImage obtains... from the first image to the last for
+ three-dimensional textures. One- and two-dimensional array textures
+ are treated as two- and three-dimensional images, respectively, where
+ the layers are treated as rows or images. These groups are then...
+
+ For three-dimensional and two-dimensional array textures, pixel storage
+ operations are applied as if the image were two-dimensional, except
+ that the additional pixel storage state values PACK_IMAGE_HEIGHT and
+ PACK_SKIP_IMAGES are applied. ..."
+
+Additions to Appendix A of the OpenGL 2.0 Specification (Invariance)
+
+ None
+
+Additions to the AGL/GLX/WGL Specifications
+
+ None
+
+GLX Protocol
+
+ None
+
+Dependencies on ARB_fragment_program
+
+ If ARB_fragment_program is not supported, the changes to section 3.11
+ should be ignored.
+
+Dependencies on EXT_framebuffer_object
+
+ If EXT_framebuffer_object is not supported, the changes to section
+ 3.8.8 ("Manual Mipmap Generation"), 4.4.2.3, and 6.1.3 should be ignored.
+
+Dependencies on EXT_texture_compression_s3tc and NV_texture_compression_vtc
+
+ (Identical dependency as EXT_texture_array.)
+
+ S3TC texture compression is supported for two-dimensional array textures.
+ When <target> is TEXTURE_2D_ARRAY_EXT, each layer is stored independently
+ as a compressed two-dimensional textures. When specifying or querying
+ compressed images using one of the S3TC formats, the images are provided
+ and/or returned as a series of two-dimensional textures stored
+ consecutively in memory, with the layer closest to zero specified first.
+ For array textures, images are not arranged in 4x4x4 or 4x4x2 blocks as in
+ the three-dimensional compression format provided in the
+ EXT_texture_compression_vtc extension. Pixel store parameters, including
+ those specific to three-dimensional images, are ignored when compressed
+ image data are provided or returned, as in the
+ EXT_texture_compression_s3tc extension.
+
+ S3TC compression is not supported for one-dimensional texture targets in
+ EXT_texture_compression_s3tc, and is not supported for one-dimensional
+ array textures in this extension. If compressed one-dimensional arrays
+ are needed, use a two-dimensional texture with a height of one.
+
+ This extension allows the use of the four S3TC internal format types in
+ TexImage3D, CompressedTexImage3D, and CompressedTexSubImage3D calls.
+
+Errors
+
+ None
+
+New State
+
+ (add to table 6.15, p. 276)
+
+ Initial
+ Get Value Type Get Command Value Description Sec. Attribute
+ ---------------------------- ----- ----------- ----- -------------------- ------ ---------
+ TEXTURE_BINDING_1D_ARRAY_EXT 2*xZ+ GetIntegerv 0 texture object bound 3.8.12 texture
+ to TEXTURE_1D_ARRAY
+ TEXTURE_BINDING_2D_ARRAY_EXT 2*xZ+ GetIntegerv 0 texture object bound 3.8.12 texture
+ to TEXTURE_2D_ARRAY
+
+
+New Implementation Dependent State
+
+ (add to Table 6.32, p. 293)
+
+ Minimum
+ Get Value Type Get Command Value Description Sec. Attribute
+ ---------------------------- ---- ----------- ------- ------------------ ----- ---------
+ MAX_TEXTURE_ARRAY_LAYERS_EXT Z+ GetIntegerv 64 maximum number of 3.8.1 -
+ layers for texture
+ arrays
+
+Issues
+
+ (1) Is "texture stack" a good name for this functionality?
+
+ NO. The name is changed to "array texture" to match the
+ nomenclature used by GL_EXT_texture_array.
+
+ (2) Should the R texture coordinate be treated as normalized or
+ un-normalized? If it were un-normalized, floor(R) could be thought
+ of as a direct index into the array texture. This may be more
+ convenient for applications.
+
+ RESOLVED. All texture coordinates are normalized. The issue of
+ un-normalized texture coordinates has been discussed in the ARB
+ before and should be left for a layered extension.
+
+ RE-RESOLVED. The R coordinate is un-normalized. Accessing an array
+ using [0, layers-1] coordinates is much more natural.
+
+ (3) How does LOD selection work for stacked textures?
+
+ RESOLVED. For 2D array textures the R coordinate is ignored, and
+ the LOD selection equations for 2D textures are used. For 1D
+ array textures the T coordinate is ignored, and the LOD selection
+ equations for 1D textures are used. The expected usage is in a
+ fragment program with an explicit LOD selection.
+
+ (4) What is the maximum size of a 2D array texture? Is it the same
+ as for a 3D texture, or should a new query be added? How about for 1D
+ array textures?
+
+ RESOLVED. A new query is added.
+
+ (5) How are array textures exposed in GLSL?
+
+ RESOLVED. Use GL_EXT_texture_array.
+
+ (6) Should a 1D array texture also be exposed?
+
+ RESOLVED. For orthogonality, yes.
+
+ (7) How are stacked textures attached to framebuffer objects?
+
+ RESOLVED. Layers of both one- and two-dimensional array textures
+ are attached using FreambufferTextureLayerEXT. Once attached, the
+ array texture layer behaves exactly as either a one- or
+ two-dimensional texture.
+
+ (8) How is this extension related to GL_EXT_texture_array?
+
+ This extension adapats GL_MESAX_texture_stack to the notation,
+ indexing, and FBO access of GL_EXT_texture_array. This extension
+ replaces the GLSL support of GL_EXT_texture_array with
+ GL_ARB_fragment_program support.
+
+ Assembly program support is also provided by GL_NV_gpu_program4.
+ GL_NV_gpu_program4 also adds support for other features that are
+ specific to Nvidia hardware, while this extension adds only support
+ for array textures.
+
+ Much of text of this extension that has changed since
+ GL_MESAX_texture_stack comes directly from either
+ GL_EXT_texture_array or GL_NV_gpu_program4.
+
+Revision History
+
+ ||2005/11/15||0.1||idr||Initial draft MESAX version.||
+ ||2005/12/07||0.2||idr||Added framebuffer object interactions.||
+ ||2005/12/12||0.3||idr||Updated fragment program interactions.||
+ ||2007/05/16||0.4||idr||Converted to MESA_texture_array. Brought in line with EXT_texture_array and NV_gpu_program4.||
diff --git a/mesalib/docs/MESA_texture_signed_rgba.spec b/mesalib/docs/MESA_texture_signed_rgba.spec index 49c8e9e5d..bcc4d4203 100644 --- a/mesalib/docs/MESA_texture_signed_rgba.spec +++ b/mesalib/docs/MESA_texture_signed_rgba.spec @@ -1,214 +1,214 @@ -Name - - MESA_texture_signed_rgba - -Name Strings - - GL_MESA_texture_signed_rgba - -Contact - - - -Notice - - - -IP Status - - No known IP issues - -Status - - - -Version - - 0.3, 2009-03-24 - -Number - - Not assigned ? - -Dependencies - - Written based on the wording of the OpenGL 2.0 specification. - - This extension trivially interacts with ARB_texture_float. - This extension shares some language with ARB_texture_compression_rgtc - but does not depend on it. - -Overview - - OpenGL prior to 3.1 does not support any signed texture formats. - ARB_texture_compression_rgtc introduces some compressed red and - red_green signed formats but no uncompressed ones, which might - still be useful. NV_texture_shader adds signed texture formats, - but also a lot of functionality which has been superceded by fragment - shaders. - It is usually possible to get the same functionality - using a unsigned format by doing scale and bias in a shader, but this - is undesirable since modern hardware has direct support for this. - This extension adds a signed 4-channel texture format by backporting - the relevant features from OpenGL 3.1, as a means to support this in - OpenGL implementations only supporting older versions. - -Issues - - 1) What should this extension be called? - - RESOLVED: MESA_texture_signed_rgba seems reasonable. - The rgba part is there because only 4 channel format is supported. - - - 2) Should the full set of signed formats (alpha, luminance, rgb, etc.) - be supported? - - RESOLVED: NO. To keep this extension simple, only add the most - universal format, rgba. alpha/luminance can't be trivially supported - since OpenGL 3.1 does not support them any longer, and there is some - implied dependency on ARB_texture_rg for red/red_green formats so - avoid all this. Likewise, only 8 bits per channel is supported. - - - 3) Should this extension use new enums for the texture formats? - - RESOLVED: NO. Same enums as those used in OpenGL 3.1. - - - 4) How are signed integer values mapped to floating-point values? - - RESOLVED: Same as described in issue 5) of - ARB_texture_compression_rgtc (quote): - A signed 8-bit two's complement value X is computed to - a floating-point value Xf with the formula: - - { X / 127.0, X > -128 - Xf = { - { -1.0, X == -128 - - This conversion means -1, 0, and +1 are all exactly representable, - however -128 and -127 both map to -1.0. Mapping -128 to -1.0 - avoids the numerical awkwardness of have a representable value - slightly more negative than -1.0. - - This conversion is intentionally NOT the "byte" conversion listed - in Table 2.9 for component conversions. That conversion says: - - Xf = (2*X + 1) / 255.0 - - The Table 2.9 conversion is incapable of exactly representing - zero. - - (Difference to ARB_texture_compression_rgtc): - This is the same mapping as OpenGL 3.1 uses. - This is also different to what NV_texture_shader used. - The above mapping should be considered the reference, but there - is some leeway so other mappings are allowed for implementations which - cannot do this. Particulary the mapping given in NV_texture_shader or - the standard OpenGL byte/float mapping is considered acceptable too, as - might be a mapping which represents -1.0 by -128, 0.0 by 0 and 1.0 by - 127 (that is, uses different scale factors for negative and positive - numbers). - Also, it is ok to store incoming GL_BYTE user data as-is, without - converting to GL_FLOAT (using the standard OpenGL float/byte mapping) - and converting back (using the mapping described here). - Other than those subtle issues there are no other non-standard - conversions used, so when using for instance CopyTexImage2D with - a framebuffer clamped to [0,1] all converted numbers will be in the range - [0, 127] (and not scaled and biased). - - - 5) How will signed components resulting from RGBA8_SNORM texture - fetches interact with fragment coloring? - - RESOLVED: Same as described in issue 6) of - ARB_texture_compression_rgtc (quote): - The specification language for this extension is silent - about clamping behavior leaving this to the core specification - and other extensions. The clamping or lack of clamping is left - to the core specification and other extensions. - - For assembly program extensions supporting texture fetches - (ARB_fragment_program, NV_fragment_program, NV_vertex_program3, - etc.) or the OpenGL Shading Language, these signed formats will - appear as expected with unclamped signed components as a result - of a texture fetch instruction. - - If ARB_color_buffer_float is supported, its clamping controls - will apply. - - NV_texture_shader extension, if supported, adds support for - fixed-point textures with signed components and relaxed the - fixed-function texture environment clamping appropriately. If the - NV_texture_shader extension is supported, its specified behavior - for the texture environment applies where intermediate values - are clamped to [-1,1] unless stated otherwise as in the case - of explicitly clamped to [0,1] for GL_COMBINE. or clamping the - linear interpolation weight to [0,1] for GL_DECAL and GL_BLEND. - - Otherwise, the conventional core texture environment clamps - incoming, intermediate, and output color components to [0,1]. - - This implies that the conventional texture environment - functionality of unextended OpenGL 1.5 or OpenGL 2.0 without - using GLSL (and with none of the extensions referred to above) - is unable to make proper use of the signed texture formats added - by this extension because the conventional texture environment - requires texture source colors to be clamped to [0,1]. Texture - filtering of these signed formats would be still signed, but - negative values generated post-filtering would be clamped to - zero by the core texture environment functionality. The - expectation is clearly that this extension would be co-implemented - with one of the previously referred to extensions or used with - GLSL for the new signed formats to be useful. - - - 6) Should the RGBA_SNORM tokens also be accepted by CopyTexImage - functions? - - RESOLVED: YES. - - - 7) What to do with GetTexParameter if ARB_texture_float is supported, - in particular what datatype should this return for TEXTURE_RED_TYPE_ARB, - TEXTURE_GREEN_TYPE_ARB, TEXTURE_BLUE_TYPE_ARB, TEXTURE_ALPHA_TYPE_ARB? - - RESOLVED: ARB_texture_float states type is either NONE, - UNSIGNED_NORMALIZED_ARB, or FLOAT. This extension adds a new enum, - SIGNED_NORMALIZED, which will be returned accordingly. This is the - same behaviour as in OpenGL 3.1. - - -New Tokens - - - Accepted by the <internalformat> parameter of - TexImage1D, TexImage2D, TexImage3D, CopyTexImage1D, and CopyTexImage2D: - - RGBA_SNORM 0x8F93 - RGBA8_SNORM 0x8F97 - - Returned by the <params> parameter of GetTexLevelParameter: - - SIGNED_NORMALIZED 0x8F9C - - -Additions to Chapter 3 of the OpenGL 2.0 Specification (Rasterization): - - -- Section 3.8.1, Texture Image Specification - - Add to Table 3.16 (page 154): Sized internal formats - - Sized Base R G B A L I D - Internal Format Internal Format bits bits bits bits bits bits bits - --------------- --------------- ---- ---- ---- ---- ---- ---- ---- - RGBA8_SNORM RGBA 8 8 8 8 0 0 0 - - -Dependencies on ARB_texture_float extension: - - If ARB_texture_float is supported, GetTexParameter queries with <value> - of TEXTURE_RED_TYPE_ARB, TEXTURE_GREEN_TYPE_ARB, TEXTURE_BLUE_TYPE_ARB or - TEXTURE_ALPHA_TYPE_ARB return SIGNED_NORMALIZED if - the base internal format is RGBA_SNORM. +Name
+
+ MESA_texture_signed_rgba
+
+Name Strings
+
+ GL_MESA_texture_signed_rgba
+
+Contact
+
+
+
+Notice
+
+
+
+IP Status
+
+ No known IP issues
+
+Status
+
+
+
+Version
+
+ 0.3, 2009-03-24
+
+Number
+
+ Not assigned ?
+
+Dependencies
+
+ Written based on the wording of the OpenGL 2.0 specification.
+
+ This extension trivially interacts with ARB_texture_float.
+ This extension shares some language with ARB_texture_compression_rgtc
+ but does not depend on it.
+
+Overview
+
+ OpenGL prior to 3.1 does not support any signed texture formats.
+ ARB_texture_compression_rgtc introduces some compressed red and
+ red_green signed formats but no uncompressed ones, which might
+ still be useful. NV_texture_shader adds signed texture formats,
+ but also a lot of functionality which has been superseded by fragment
+ shaders.
+ It is usually possible to get the same functionality
+ using a unsigned format by doing scale and bias in a shader, but this
+ is undesirable since modern hardware has direct support for this.
+ This extension adds a signed 4-channel texture format by backporting
+ the relevant features from OpenGL 3.1, as a means to support this in
+ OpenGL implementations only supporting older versions.
+
+Issues
+
+ 1) What should this extension be called?
+
+ RESOLVED: MESA_texture_signed_rgba seems reasonable.
+ The rgba part is there because only 4 channel format is supported.
+
+
+ 2) Should the full set of signed formats (alpha, luminance, rgb, etc.)
+ be supported?
+
+ RESOLVED: NO. To keep this extension simple, only add the most
+ universal format, rgba. alpha/luminance can't be trivially supported
+ since OpenGL 3.1 does not support them any longer, and there is some
+ implied dependency on ARB_texture_rg for red/red_green formats so
+ avoid all this. Likewise, only 8 bits per channel is supported.
+
+
+ 3) Should this extension use new enums for the texture formats?
+
+ RESOLVED: NO. Same enums as those used in OpenGL 3.1.
+
+
+ 4) How are signed integer values mapped to floating-point values?
+
+ RESOLVED: Same as described in issue 5) of
+ ARB_texture_compression_rgtc (quote):
+ A signed 8-bit two's complement value X is computed to
+ a floating-point value Xf with the formula:
+
+ { X / 127.0, X > -128
+ Xf = {
+ { -1.0, X == -128
+
+ This conversion means -1, 0, and +1 are all exactly representable,
+ however -128 and -127 both map to -1.0. Mapping -128 to -1.0
+ avoids the numerical awkwardness of have a representable value
+ slightly more negative than -1.0.
+
+ This conversion is intentionally NOT the "byte" conversion listed
+ in Table 2.9 for component conversions. That conversion says:
+
+ Xf = (2*X + 1) / 255.0
+
+ The Table 2.9 conversion is incapable of exactly representing
+ zero.
+
+ (Difference to ARB_texture_compression_rgtc):
+ This is the same mapping as OpenGL 3.1 uses.
+ This is also different to what NV_texture_shader used.
+ The above mapping should be considered the reference, but there
+ is some leeway so other mappings are allowed for implementations which
+ cannot do this. Particularly the mapping given in NV_texture_shader or
+ the standard OpenGL byte/float mapping is considered acceptable too, as
+ might be a mapping which represents -1.0 by -128, 0.0 by 0 and 1.0 by
+ 127 (that is, uses different scale factors for negative and positive
+ numbers).
+ Also, it is ok to store incoming GL_BYTE user data as-is, without
+ converting to GL_FLOAT (using the standard OpenGL float/byte mapping)
+ and converting back (using the mapping described here).
+ Other than those subtle issues there are no other non-standard
+ conversions used, so when using for instance CopyTexImage2D with
+ a framebuffer clamped to [0,1] all converted numbers will be in the range
+ [0, 127] (and not scaled and biased).
+
+
+ 5) How will signed components resulting from RGBA8_SNORM texture
+ fetches interact with fragment coloring?
+
+ RESOLVED: Same as described in issue 6) of
+ ARB_texture_compression_rgtc (quote):
+ The specification language for this extension is silent
+ about clamping behavior leaving this to the core specification
+ and other extensions. The clamping or lack of clamping is left
+ to the core specification and other extensions.
+
+ For assembly program extensions supporting texture fetches
+ (ARB_fragment_program, NV_fragment_program, NV_vertex_program3,
+ etc.) or the OpenGL Shading Language, these signed formats will
+ appear as expected with unclamped signed components as a result
+ of a texture fetch instruction.
+
+ If ARB_color_buffer_float is supported, its clamping controls
+ will apply.
+
+ NV_texture_shader extension, if supported, adds support for
+ fixed-point textures with signed components and relaxed the
+ fixed-function texture environment clamping appropriately. If the
+ NV_texture_shader extension is supported, its specified behavior
+ for the texture environment applies where intermediate values
+ are clamped to [-1,1] unless stated otherwise as in the case
+ of explicitly clamped to [0,1] for GL_COMBINE. or clamping the
+ linear interpolation weight to [0,1] for GL_DECAL and GL_BLEND.
+
+ Otherwise, the conventional core texture environment clamps
+ incoming, intermediate, and output color components to [0,1].
+
+ This implies that the conventional texture environment
+ functionality of unextended OpenGL 1.5 or OpenGL 2.0 without
+ using GLSL (and with none of the extensions referred to above)
+ is unable to make proper use of the signed texture formats added
+ by this extension because the conventional texture environment
+ requires texture source colors to be clamped to [0,1]. Texture
+ filtering of these signed formats would be still signed, but
+ negative values generated post-filtering would be clamped to
+ zero by the core texture environment functionality. The
+ expectation is clearly that this extension would be co-implemented
+ with one of the previously referred to extensions or used with
+ GLSL for the new signed formats to be useful.
+
+
+ 6) Should the RGBA_SNORM tokens also be accepted by CopyTexImage
+ functions?
+
+ RESOLVED: YES.
+
+
+ 7) What to do with GetTexParameter if ARB_texture_float is supported,
+ in particular what datatype should this return for TEXTURE_RED_TYPE_ARB,
+ TEXTURE_GREEN_TYPE_ARB, TEXTURE_BLUE_TYPE_ARB, TEXTURE_ALPHA_TYPE_ARB?
+
+ RESOLVED: ARB_texture_float states type is either NONE,
+ UNSIGNED_NORMALIZED_ARB, or FLOAT. This extension adds a new enum,
+ SIGNED_NORMALIZED, which will be returned accordingly. This is the
+ same behaviour as in OpenGL 3.1.
+
+
+New Tokens
+
+
+ Accepted by the <internalformat> parameter of
+ TexImage1D, TexImage2D, TexImage3D, CopyTexImage1D, and CopyTexImage2D:
+
+ RGBA_SNORM 0x8F93
+ RGBA8_SNORM 0x8F97
+
+ Returned by the <params> parameter of GetTexLevelParameter:
+
+ SIGNED_NORMALIZED 0x8F9C
+
+
+Additions to Chapter 3 of the OpenGL 2.0 Specification (Rasterization):
+
+ -- Section 3.8.1, Texture Image Specification
+
+ Add to Table 3.16 (page 154): Sized internal formats
+
+ Sized Base R G B A L I D
+ Internal Format Internal Format bits bits bits bits bits bits bits
+ --------------- --------------- ---- ---- ---- ---- ---- ---- ----
+ RGBA8_SNORM RGBA 8 8 8 8 0 0 0
+
+
+Dependencies on ARB_texture_float extension:
+
+ If ARB_texture_float is supported, GetTexParameter queries with <value>
+ of TEXTURE_RED_TYPE_ARB, TEXTURE_GREEN_TYPE_ARB, TEXTURE_BLUE_TYPE_ARB or
+ TEXTURE_ALPHA_TYPE_ARB return SIGNED_NORMALIZED if
+ the base internal format is RGBA_SNORM.
diff --git a/mesalib/docs/MESA_window_pos.spec b/mesalib/docs/MESA_window_pos.spec index 4d01f1814..ac3e5b1b3 100644 --- a/mesalib/docs/MESA_window_pos.spec +++ b/mesalib/docs/MESA_window_pos.spec @@ -1,126 +1,126 @@ -Name - - MESA_window_pos - -Name Strings - - GL_MESA_window_pos - -Contact - - Brian Paul, brian.paul 'at' tungstengraphics.com - -Status - - Shipping (since Mesa version 1.2.8) - -Version - - -Number - - 197 - -Dependencies - - OpenGL 1.0 is required. - The extension is written against the OpenGL 1.2 Specification - -Overview - - In order to set the current raster position to a specific window - coordinate with the RasterPos command, the modelview matrix, projection - matrix and viewport must be set very carefully. Furthermore, if the - desired window coordinate is outside of the window's bounds one must - rely on a subtle side-effect of the Bitmap command in order to circumvent - frustum clipping. - - This extension provides a set of functions to directly set the - current raster position, bypassing the modelview matrix, the - projection matrix and the viewport to window mapping. Furthermore, - clip testing is not performed. - - This greatly simplifies the process of setting the current raster - position to a specific window coordinate prior to calling DrawPixels, - CopyPixels or Bitmap. - -New Procedures and Functions - - void WindowPos2dMESA(double x, double y) - void WindowPos2fMESA(float x, float y) - void WindowPos2iMESA(int x, int y) - void WindowPos2sMESA(short x, short y) - void WindowPos2ivMESA(const int *p) - void WindowPos2svMESA(const short *p) - void WindowPos2fvMESA(const float *p) - void WindowPos2dvMESA(const double *p) - void WindowPos3iMESA(int x, int y, int z) - void WindowPos3sMESA(short x, short y, short z) - void WindowPos3fMESA(float x, float y, float z) - void WindowPos3dMESA(double x, double y, double z) - void WindowPos3ivMESA(const int *p) - void WindowPos3svMESA(const short *p) - void WindowPos3fvMESA(const float *p) - void WindowPos3dvMESA(const double *p) - void WindowPos4iMESA(int x, int y, int z, int w) - void WindowPos4sMESA(short x, short y, short z, short w) - void WindowPos4fMESA(float x, float y, float z, float w) - void WindowPos4dMESA(double x, double y, double z, double ) - void WindowPos4ivMESA(const int *p) - void WindowPos4svMESA(const short *p) - void WindowPos4fvMESA(const float *p) - void WindowPos4dvMESA(const double *p) - -New Tokens - - none - -Additions to Chapter 2 of the OpenGL 1.2 Specification (OpenGL Operation) - - - (2.12, p. 41) Insert after third paragraph: - - Alternately, the current raster position may be set by one of the - WindowPosMESA commands: - - void WindowPos{234}{sidf}MESA( T coords ); - void WindowPos{234}{sidf}vMESA( T coords ); - - WindosPos4MESA takes four values indicating x, y, z, and w. - WindowPos3MESA (or WindowPos2MESA) is analaguos, but sets only - x, y, and z with w implicitly set to 1 (or only x and y with z - implicititly set to 0 and w implicitly set to 1). - - WindowPosMESA operates like RasterPos except that the current modelview - matrix, projection matrix and viewport parameters are ignored and the - clip test operation always passes. The current raster position values - are directly set to the parameters passed to WindowPosMESA. The current - color, color index and texture coordinate update the current raster - position's associated data. - -Additions to the AGL/GLX/WGL Specifications - - None - -GLX Protocol - - Not specified at this time. However, a protocol message very similar - to that of RasterPos is expected. - -Errors - - INVALID_OPERATION is generated if WindowPosMESA is called betweeen - Begin and End. - -New State - - None. - -New Implementation Dependent State - - None. - -Revision History - - * Revision 1.0 - Initial specification - * Revision 1.1 - Minor clean-up (7 Jan 2000, Brian Paul) - +Name
+
+ MESA_window_pos
+
+Name Strings
+
+ GL_MESA_window_pos
+
+Contact
+
+ Brian Paul, brian.paul 'at' tungstengraphics.com
+
+Status
+
+ Shipping (since Mesa version 1.2.8)
+
+Version
+
+
+Number
+
+ 197
+
+Dependencies
+
+ OpenGL 1.0 is required.
+ The extension is written against the OpenGL 1.2 Specification
+
+Overview
+
+ In order to set the current raster position to a specific window
+ coordinate with the RasterPos command, the modelview matrix, projection
+ matrix and viewport must be set very carefully. Furthermore, if the
+ desired window coordinate is outside of the window's bounds one must
+ rely on a subtle side-effect of the Bitmap command in order to circumvent
+ frustum clipping.
+
+ This extension provides a set of functions to directly set the
+ current raster position, bypassing the modelview matrix, the
+ projection matrix and the viewport to window mapping. Furthermore,
+ clip testing is not performed.
+
+ This greatly simplifies the process of setting the current raster
+ position to a specific window coordinate prior to calling DrawPixels,
+ CopyPixels or Bitmap.
+
+New Procedures and Functions
+
+ void WindowPos2dMESA(double x, double y)
+ void WindowPos2fMESA(float x, float y)
+ void WindowPos2iMESA(int x, int y)
+ void WindowPos2sMESA(short x, short y)
+ void WindowPos2ivMESA(const int *p)
+ void WindowPos2svMESA(const short *p)
+ void WindowPos2fvMESA(const float *p)
+ void WindowPos2dvMESA(const double *p)
+ void WindowPos3iMESA(int x, int y, int z)
+ void WindowPos3sMESA(short x, short y, short z)
+ void WindowPos3fMESA(float x, float y, float z)
+ void WindowPos3dMESA(double x, double y, double z)
+ void WindowPos3ivMESA(const int *p)
+ void WindowPos3svMESA(const short *p)
+ void WindowPos3fvMESA(const float *p)
+ void WindowPos3dvMESA(const double *p)
+ void WindowPos4iMESA(int x, int y, int z, int w)
+ void WindowPos4sMESA(short x, short y, short z, short w)
+ void WindowPos4fMESA(float x, float y, float z, float w)
+ void WindowPos4dMESA(double x, double y, double z, double )
+ void WindowPos4ivMESA(const int *p)
+ void WindowPos4svMESA(const short *p)
+ void WindowPos4fvMESA(const float *p)
+ void WindowPos4dvMESA(const double *p)
+
+New Tokens
+
+ none
+
+Additions to Chapter 2 of the OpenGL 1.2 Specification (OpenGL Operation)
+
+ - (2.12, p. 41) Insert after third paragraph:
+
+ Alternately, the current raster position may be set by one of the
+ WindowPosMESA commands:
+
+ void WindowPos{234}{sidf}MESA( T coords );
+ void WindowPos{234}{sidf}vMESA( T coords );
+
+ WindosPos4MESA takes four values indicating x, y, z, and w.
+ WindowPos3MESA (or WindowPos2MESA) is analaguos, but sets only
+ x, y, and z with w implicitly set to 1 (or only x and y with z
+ implicitly set to 0 and w implicitly set to 1).
+
+ WindowPosMESA operates like RasterPos except that the current modelview
+ matrix, projection matrix and viewport parameters are ignored and the
+ clip test operation always passes. The current raster position values
+ are directly set to the parameters passed to WindowPosMESA. The current
+ color, color index and texture coordinate update the current raster
+ position's associated data.
+
+Additions to the AGL/GLX/WGL Specifications
+
+ None
+
+GLX Protocol
+
+ Not specified at this time. However, a protocol message very similar
+ to that of RasterPos is expected.
+
+Errors
+
+ INVALID_OPERATION is generated if WindowPosMESA is called between
+ Begin and End.
+
+New State
+
+ None.
+
+New Implementation Dependent State
+
+ None.
+
+Revision History
+
+ * Revision 1.0 - Initial specification
+ * Revision 1.1 - Minor clean-up (7 Jan 2000, Brian Paul)
+
diff --git a/mesalib/docs/MESA_ycbcr_texture.spec b/mesalib/docs/MESA_ycbcr_texture.spec index 0fa1f7b39..e865039fb 100644 --- a/mesalib/docs/MESA_ycbcr_texture.spec +++ b/mesalib/docs/MESA_ycbcr_texture.spec @@ -1,204 +1,204 @@ -Name - - MESA_ycbcr_texture - -Name Strings - - GL_MESA_ycbcr_texture - -Contact - - Brian Paul, Tungsten Graphics, Inc. (brian.paul 'at' tungstengraphics.com) - Keith Whitwell, Tungsten Graphics, Inc. (keith 'at' tungstengraphics.com) - -Status - - Shipping (Mesa 4.0.4 and later) - -Version - - 1.0 - -Number - - TBD - -Dependencies - - OpenGL 1.0 or later is required - This extensions is written against the OpenGL 1.4 Specification. - NV_texture_rectangle effects the definition of this extension. - -Overview - - This extension supports texture images stored in the YCbCr format. - There is no support for converting YCbCr images to RGB or vice versa - during pixel transfer. The texture's YCbCr colors are converted to - RGB during texture sampling, after-which, all the usual per-fragment - operations take place. Only 2D texture images are supported (not - glDrawPixels, glReadPixels, etc). - - A YCbCr pixel (texel) is a 16-bit unsigned short with two components. - The first component is luminance (Y). For pixels in even-numbered - image columns, the second component is Cb. For pixels in odd-numbered - image columns, the second component is Cr. If one were to convert the - data to RGB one would need to examine two pixels from columns N and N+1 - (where N is even) to deduce the RGB color. - -IP Status - - None - -Issues - - None - -New Procedures and Functions - - None - -New Tokens - - Accepted by the <internalFormat> and <format> parameters of - TexImage2D and TexSubImage2D: - - YCBCR_MESA 0x8757 - - Accepted by the <type> parameter of TexImage2D and TexSubImage2D: - - UNSIGNED_SHORT_8_8_MESA 0x85BA /* same as Apple's */ - UNSIGNED_SHORT_8_8_REV_MESA 0x85BB /* same as Apple's */ - -Additions to Chapter 2 of the OpenGL 1.4 Specification (OpenGL Operation) - - None - -Additions to Chapter 3 of the OpenGL 1.4 Specification (Rasterization) - - In section 3.6.4, Rasterization of Pixel Rectangles, on page 101, - add the following to Table 3.8 (Packed pixel formats): - - type Parameter GL Data Number of Matching - Token Name Type Components Pixel Formats - -------------- ------- ---------- ------------- - UNSIGNED_SHORT_8_8_MESA ushort 2 YCBCR_MESA - UNSIGNED_SHORT_8_8_REV_MESA ushort 2 YCBCR_MESA - - - In section 3.6.4, Rasterization of Pixel Rectangles, on page 102, - add the following to Table 3.10 (UNSIGNED_SHORT formats): - - UNSIGNED_SHORT_8_8_MESA: - - 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0 - +-------------------------------+-------------------------------+ - | 1st | 2nd | - +-------------------------------+-------------------------------+ - - UNSIGNED_SHORT_8_8_REV_MESA: - - 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0 - +-------------------------------+-------------------------------+ - | 2nd | 1st | - +-------------------------------+-------------------------------+ - - - In section 3.6.4, Rasterization of Pixel Rectangles, on page 104, - add the following to Table 3.12 (Packed pixel fiedl assignments): - - First Second Third Fourth - Format Element Element Element Element - ------ ------- ------- ------- ------- - YCBCR_MESA luminance chroma - - - In section 3.8.1, Texture Image Specification, on page 125, add - another item to the list of TexImage2D and TexImage3D equivalence - exceptions: - - * The value of internalformat and format may be YCBCR_MESA to - indicate that the image data is in YCbCr format. type must - be either UNSIGNED_SHORT_8_8_MESA or UNSIGNED_SHORT_8_8_REV_MESA - as seen in tables 3.8 and 3.10. Table 3.12 describes the mapping - between Y and Cb/Cr to the components. - If NV_texture_rectangle is supported target may also be - TEXTURE_RECTANGLE_NV or PROXY_TEXTURE_RECTANGLE_NV. - All pixel transfer operations are bypassed. The texture is stored as - YCbCr, not RGB. Queries of the texture's red, green and blue component - sizes will return zero. The YCbCr colors are converted to RGB during - texture sampling using an implementation dependent conversion. - - - In section 3.8.1, Texture Image Specification, on page 126, add - another item to the list of TexImage1D and TexImage2D equivalence - exceptions: - - * The value of internalformat and format can not be YCBCR_MESA. - - - In section 3.8.2, Alternate Texture Image Specification Commands, on - page 129, insert this paragraph after the first full paragraph on the - page: - - "If the internal storage format of the image being updated by - TexSubImage2D is YCBCR_MESA then format must be YCBCR_MESA. - The error INVALID_OPERATION will be generated otherwise." - - -Additions to Chapter 4 of the OpenGL 1.4 Specification (Per-Fragment -Operations and the Frame Buffer) - - None - -Additions to Chapter 5 of the OpenGL 1.4 Specification (Special Functions) - - None - -Additions to Chapter 6 of the OpenGL 1.4 Specification (State and -State Requests) - - None - -Additions to Appendix A of the OpenGL 1.4 Specification (Invariance) - - None - -Additions to the AGL/GLX/WGL Specifications - - None - -GLX Protocol - - None - -Errors - - INVALID_ENUM is generated by TexImage2D if <internalFormat> is - MESA_YCBCR but <format> is not MESA_YCBCR. - - INVALID_ENUM is generated by TexImage2D if <format> is MESA_YCBCR but - <internalFormat> is not MESA_YCBCR. - - INVALID_VALUE is generated by TexImage2D if <format> is MESA_YCBCR and - <internalFormat> is MESA_YCBCR and <border> is not zero. - - INVALID_OPERATION is generated by TexSubImage2D if the internal image - format is YCBCR_MESA and <format> is not YCBCR_MESA. - - INVALID_OPERATION is generated by CopyTexSubImage2D if the internal - image is YCBCR_MESA. - -New State - - Edit table 6.16 on page 231: change the type of TEXTURE_INTERNAL_FORMAT - from n x Z42 to n x Z43 to indicate that internal format may also be - YCBCR_MESA. - -Revision History - - 20 September 2002 - Initial draft - 29 April 2003 - minor updates - 3 September 2003 - further clarify when YCbCr->RGB conversion takes place - 19 September 2003 - a few more updates prior to submitting to extension - registry. - 3 April 2004 - fix assorted inaccuracies +Name
+
+ MESA_ycbcr_texture
+
+Name Strings
+
+ GL_MESA_ycbcr_texture
+
+Contact
+
+ Brian Paul, Tungsten Graphics, Inc. (brian.paul 'at' tungstengraphics.com)
+ Keith Whitwell, Tungsten Graphics, Inc. (keith 'at' tungstengraphics.com)
+
+Status
+
+ Shipping (Mesa 4.0.4 and later)
+
+Version
+
+ 1.0
+
+Number
+
+ TBD
+
+Dependencies
+
+ OpenGL 1.0 or later is required
+ This extension is written against the OpenGL 1.4 Specification.
+ NV_texture_rectangle effects the definition of this extension.
+
+Overview
+
+ This extension supports texture images stored in the YCbCr format.
+ There is no support for converting YCbCr images to RGB or vice versa
+ during pixel transfer. The texture's YCbCr colors are converted to
+ RGB during texture sampling, after-which, all the usual per-fragment
+ operations take place. Only 2D texture images are supported (not
+ glDrawPixels, glReadPixels, etc).
+
+ A YCbCr pixel (texel) is a 16-bit unsigned short with two components.
+ The first component is luminance (Y). For pixels in even-numbered
+ image columns, the second component is Cb. For pixels in odd-numbered
+ image columns, the second component is Cr. If one were to convert the
+ data to RGB one would need to examine two pixels from columns N and N+1
+ (where N is even) to deduce the RGB color.
+
+IP Status
+
+ None
+
+Issues
+
+ None
+
+New Procedures and Functions
+
+ None
+
+New Tokens
+
+ Accepted by the <internalFormat> and <format> parameters of
+ TexImage2D and TexSubImage2D:
+
+ YCBCR_MESA 0x8757
+
+ Accepted by the <type> parameter of TexImage2D and TexSubImage2D:
+
+ UNSIGNED_SHORT_8_8_MESA 0x85BA /* same as Apple's */
+ UNSIGNED_SHORT_8_8_REV_MESA 0x85BB /* same as Apple's */
+
+Additions to Chapter 2 of the OpenGL 1.4 Specification (OpenGL Operation)
+
+ None
+
+Additions to Chapter 3 of the OpenGL 1.4 Specification (Rasterization)
+
+ In section 3.6.4, Rasterization of Pixel Rectangles, on page 101,
+ add the following to Table 3.8 (Packed pixel formats):
+
+ type Parameter GL Data Number of Matching
+ Token Name Type Components Pixel Formats
+ -------------- ------- ---------- -------------
+ UNSIGNED_SHORT_8_8_MESA ushort 2 YCBCR_MESA
+ UNSIGNED_SHORT_8_8_REV_MESA ushort 2 YCBCR_MESA
+
+
+ In section 3.6.4, Rasterization of Pixel Rectangles, on page 102,
+ add the following to Table 3.10 (UNSIGNED_SHORT formats):
+
+ UNSIGNED_SHORT_8_8_MESA:
+
+ 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
+ +-------------------------------+-------------------------------+
+ | 1st | 2nd |
+ +-------------------------------+-------------------------------+
+
+ UNSIGNED_SHORT_8_8_REV_MESA:
+
+ 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
+ +-------------------------------+-------------------------------+
+ | 2nd | 1st |
+ +-------------------------------+-------------------------------+
+
+
+ In section 3.6.4, Rasterization of Pixel Rectangles, on page 104,
+ add the following to Table 3.12 (Packed pixel field assignments):
+
+ First Second Third Fourth
+ Format Element Element Element Element
+ ------ ------- ------- ------- -------
+ YCBCR_MESA luminance chroma
+
+
+ In section 3.8.1, Texture Image Specification, on page 125, add
+ another item to the list of TexImage2D and TexImage3D equivalence
+ exceptions:
+
+ * The value of internalformat and format may be YCBCR_MESA to
+ indicate that the image data is in YCbCr format. type must
+ be either UNSIGNED_SHORT_8_8_MESA or UNSIGNED_SHORT_8_8_REV_MESA
+ as seen in tables 3.8 and 3.10. Table 3.12 describes the mapping
+ between Y and Cb/Cr to the components.
+ If NV_texture_rectangle is supported target may also be
+ TEXTURE_RECTANGLE_NV or PROXY_TEXTURE_RECTANGLE_NV.
+ All pixel transfer operations are bypassed. The texture is stored as
+ YCbCr, not RGB. Queries of the texture's red, green and blue component
+ sizes will return zero. The YCbCr colors are converted to RGB during
+ texture sampling using an implementation dependent conversion.
+
+
+ In section 3.8.1, Texture Image Specification, on page 126, add
+ another item to the list of TexImage1D and TexImage2D equivalence
+ exceptions:
+
+ * The value of internalformat and format can not be YCBCR_MESA.
+
+
+ In section 3.8.2, Alternate Texture Image Specification Commands, on
+ page 129, insert this paragraph after the first full paragraph on the
+ page:
+
+ "If the internal storage format of the image being updated by
+ TexSubImage2D is YCBCR_MESA then format must be YCBCR_MESA.
+ The error INVALID_OPERATION will be generated otherwise."
+
+
+Additions to Chapter 4 of the OpenGL 1.4 Specification (Per-Fragment
+Operations and the Frame Buffer)
+
+ None
+
+Additions to Chapter 5 of the OpenGL 1.4 Specification (Special Functions)
+
+ None
+
+Additions to Chapter 6 of the OpenGL 1.4 Specification (State and
+State Requests)
+
+ None
+
+Additions to Appendix A of the OpenGL 1.4 Specification (Invariance)
+
+ None
+
+Additions to the AGL/GLX/WGL Specifications
+
+ None
+
+GLX Protocol
+
+ None
+
+Errors
+
+ INVALID_ENUM is generated by TexImage2D if <internalFormat> is
+ MESA_YCBCR but <format> is not MESA_YCBCR.
+
+ INVALID_ENUM is generated by TexImage2D if <format> is MESA_YCBCR but
+ <internalFormat> is not MESA_YCBCR.
+
+ INVALID_VALUE is generated by TexImage2D if <format> is MESA_YCBCR and
+ <internalFormat> is MESA_YCBCR and <border> is not zero.
+
+ INVALID_OPERATION is generated by TexSubImage2D if the internal image
+ format is YCBCR_MESA and <format> is not YCBCR_MESA.
+
+ INVALID_OPERATION is generated by CopyTexSubImage2D if the internal
+ image is YCBCR_MESA.
+
+New State
+
+ Edit table 6.16 on page 231: change the type of TEXTURE_INTERNAL_FORMAT
+ from n x Z42 to n x Z43 to indicate that internal format may also be
+ YCBCR_MESA.
+
+Revision History
+
+ 20 September 2002 - Initial draft
+ 29 April 2003 - minor updates
+ 3 September 2003 - further clarify when YCbCr->RGB conversion takes place
+ 19 September 2003 - a few more updates prior to submitting to extension
+ registry.
+ 3 April 2004 - fix assorted inaccuracies
diff --git a/mesalib/docs/WL_bind_wayland_display.spec b/mesalib/docs/WL_bind_wayland_display.spec index 0ff49d6a7..577496af0 100644 --- a/mesalib/docs/WL_bind_wayland_display.spec +++ b/mesalib/docs/WL_bind_wayland_display.spec @@ -1,92 +1,92 @@ -Name - - WL_bind_wayland_display - -Name Strings - - EGL_WL_bind_wayland_display - -Contact - - Kristian Høgsberg <krh@bitplanet.net> - Benjamin Franzke <benjaminfranzke@googlemail.com> - -Status - - Proposal - -Version - - Version 1, March 1, 2011 - -Number - - EGL Extension #not assigned - -Dependencies - - Reguires EGL 1.4 or later. This extension is written against the - wording of the EGL 1.4 specification. - - EGL_KHR_base_image is required. - -Overview - - This extension provides entry points for binding and unbinding the - wl_display of a Wayland compositor to an EGLDisplay. Binding a - wl_display means that the EGL implementation should provide one or - more interfaces in the Wayland protocol to allow clients to create - wl_buffer objects. On the server side, this extension also - provides a new target for eglCreateImageKHR, to create an EGLImage - from a wl_buffer - - Adding a implementation specific wayland interface, allows the - EGL implementation to define specific wayland requests and events, - needed for buffer sharing in a EGL wayland platform. - -IP Status - - Open-source; freely implementable. - -New Procedures and Functions - - EGLBoolean eglBindWaylandDisplayWL(EGLDisplay dpy, - struct wl_display *display); - - EGLBoolean eglUnbindWaylandDisplayWL(EGLDisplay dpy, - struct wl_display *display); - -New Tokens - - Accepted as <target> in eglCreateImageKHR - - EGL_WAYLAND_BUFFER_WL 0x31D5 - -Additions to the EGL 1.4 Specification: - - To bind a server side wl_display to an EGLDisplay, call - - EGLBoolean eglBindWaylandDisplayWL(EGLDisplay dpy, - struct wl_display *display); - - To unbind a server side wl_display from an EGLDisplay, call - - EGLBoolean eglUnbindWaylandDisplayWL(EGLDisplay dpy, - struct wl_display *display); - - eglBindWaylandDisplayWL returns EGL_FALSE when there is already a - wl_display bound to EGLDisplay otherwise EGL_TRUE. - - eglUnbindWaylandDisplayWL returns EGL_FALSE when there is no - wl_display bound to the EGLDisplay currently otherwise EGL_TRUE. - - Import a wl_buffer by calling eglCreateImageKHR with - wl_buffer as EGLClientBuffer, EGL_WAYLAND_BUFFER_WL as the target, - and an empty attribute_list. - -Issues - -Revision History - - Version 1, March 1, 2011 - Initial draft (Benjamin Franzke) +Name
+
+ WL_bind_wayland_display
+
+Name Strings
+
+ EGL_WL_bind_wayland_display
+
+Contact
+
+ Kristian Høgsberg <krh@bitplanet.net>
+ Benjamin Franzke <benjaminfranzke@googlemail.com>
+
+Status
+
+ Proposal
+
+Version
+
+ Version 1, March 1, 2011
+
+Number
+
+ EGL Extension #not assigned
+
+Dependencies
+
+ Requires EGL 1.4 or later. This extension is written against the
+ wording of the EGL 1.4 specification.
+
+ EGL_KHR_base_image is required.
+
+Overview
+
+ This extension provides entry points for binding and unbinding the
+ wl_display of a Wayland compositor to an EGLDisplay. Binding a
+ wl_display means that the EGL implementation should provide one or
+ more interfaces in the Wayland protocol to allow clients to create
+ wl_buffer objects. On the server side, this extension also
+ provides a new target for eglCreateImageKHR, to create an EGLImage
+ from a wl_buffer
+
+ Adding an implementation specific wayland interface, allows the
+ EGL implementation to define specific wayland requests and events,
+ needed for buffer sharing in an EGL wayland platform.
+
+IP Status
+
+ Open-source; freely implementable.
+
+New Procedures and Functions
+
+ EGLBoolean eglBindWaylandDisplayWL(EGLDisplay dpy,
+ struct wl_display *display);
+
+ EGLBoolean eglUnbindWaylandDisplayWL(EGLDisplay dpy,
+ struct wl_display *display);
+
+New Tokens
+
+ Accepted as <target> in eglCreateImageKHR
+
+ EGL_WAYLAND_BUFFER_WL 0x31D5
+
+Additions to the EGL 1.4 Specification:
+
+ To bind a server side wl_display to an EGLDisplay, call
+
+ EGLBoolean eglBindWaylandDisplayWL(EGLDisplay dpy,
+ struct wl_display *display);
+
+ To unbind a server side wl_display from an EGLDisplay, call
+
+ EGLBoolean eglUnbindWaylandDisplayWL(EGLDisplay dpy,
+ struct wl_display *display);
+
+ eglBindWaylandDisplayWL returns EGL_FALSE when there is already a
+ wl_display bound to EGLDisplay otherwise EGL_TRUE.
+
+ eglUnbindWaylandDisplayWL returns EGL_FALSE when there is no
+ wl_display bound to the EGLDisplay currently otherwise EGL_TRUE.
+
+ Import a wl_buffer by calling eglCreateImageKHR with
+ wl_buffer as EGLClientBuffer, EGL_WAYLAND_BUFFER_WL as the target,
+ and an empty attribute_list.
+
+Issues
+
+Revision History
+
+ Version 1, March 1, 2011
+ Initial draft (Benjamin Franzke)
diff --git a/mesalib/docs/contents.html b/mesalib/docs/contents.html index cf1661e4e..bf5e9aa09 100644 --- a/mesalib/docs/contents.html +++ b/mesalib/docs/contents.html @@ -1,105 +1,106 @@ -<html> - -<title>Contents</title> - -<link rel="stylesheet" type="text/css" href="mesa.css"></head> - -<!--Override a few values from the style sheet: --> -<style> -<!-- -body { - background-color: #cccccc; - color: black; -} -a:link { - color: #000; -} -a:visited { - color: #000; -} ---> -</style> - - -<b>Documentation</b> -<ul> -<li><a href="intro.html" target="MainFrame">Introduction</a> -<li><a href="news.html" target="MainFrame">News</a> -<LI><A HREF="developers.html" target="MainFrame">Developers</A> -<li><a href="systems.html" target="MainFrame">Platforms and Drivers</a> -<li><a href="license.html" target="MainFrame">License & Copyright</a> -<li><a href="faq.html" target="MainFrame">FAQ</a> -<li><a href="relnotes.html" target="MainFrame">Release Notes</a> -<li><a href="thanks.html" target="MainFrame">Acknowledgements</a> -<li><a href="conform.html" target="MainFrame">Conformance Testing</a> -<li>more docs below... -</ul> - -<b>Download / Install</b> -<ul> -<li><a href="download.html" target="MainFrame">Downloading / Unpacking</a> -<li><a href="install.html" target="MainFrame">Compiling / Installing</a> -<li><a href="precompiled.html" target="MainFrame">Precompiled Libraries</a> -</ul> - -<b>Resources</b> -<ul> -<li><a href="lists.html" target="MainFrame">Mailing Lists</a> -<li><a href="bugs.html" target="MainFrame">Bug Database</a> -<li><a href="webmaster.html" target="MainFrame">Webmaster</a> -<li><a href="http://dri.freedesktop.org/" target="_parent">Mesa/DRI Wiki</a> -</ul> - -<b>User Topics</b> -<ul> -<li><a href="shading.html" target="MainFrame">Shading Language</a> -<li><a href="egl.html" target="MainFrame">EGL</a> -<li><a href="opengles.html" target="MainFrame">OpenGL ES</a> -<li><a href="openvg.html" target="MainFrame">OpenVG / Vega</a> -<LI><A HREF="envvars.html" target="MainFrame">Environment Variables</A> -<LI><A HREF="osmesa.html" target="MainFrame">Off-Screen Rendering</A> -<LI><A HREF="debugging.html" target="MainFrame">Debugging Tips</A> -<LI><A HREF="perf.html" target="MainFrame">Performance Tips</A> -<LI><A HREF="extensions.html" target="MainFrame">Mesa Extensions</A> -<LI><A HREF="mangling.html" target="MainFrame">Function Name Mangling</A> -</ul> - -<b>Developer Topics</b> -<ul> -<li><a href="http://sourceforge.net/projects/mesa3d" target="_parent">SourceForge homepage</a> -<li><a href="repository.html" target="MainFrame">Source Code Repository</a> -<li><a href="sourcetree.html" target="MainFrame">Source Code Tree</a> -<li><a href="glu.html" target="MainFrame">SGI's GLU</a> -<li><a href="utilities.html" target="MainFrame">Utilities</a> -<li><a href="helpwanted.html" target="MainFrame">Help Wanted</a> -<li><a href="devinfo.html" target="MainFrame">Development Notes</a> -<li><a href="sourcedocs.html" target="MainFrame">Source Documentation</a> -<li><a href="fbdev-dri.html" target="MainFrame">fbdev/DRI Environment</a> -<li><a href="subset.html" target="MainFrame">Mesa Subset Driver</a> -<li><a href="glfbdev-driver.html" target="MainFrame">glFBDev Driver</a> -<LI><A HREF="dispatch.html" target="MainFrame">GL Dispatch</A> -<li><a href="cell.html" target="MainFrame">Cell Driver</A> -</ul> - -<b>Links</b> -<ul> -<li><a href="http://www.opengl.org" target="_parent">OpenGL website</a> -<li><a href="http://dri.freedesktop.org" target="_parent">DRI website</a> -<li><a href="http://www.freedesktop.org" target="_parent">freedesktop.org</a> -<li><a href="games.html" target="MainFrame">Games and Entertainment</a> -<li><a href="libraries.html" target="MainFrame">Libraries and Toolkits</a> -<li><a href="modelers.html" target="MainFrame">Modeling and Rendering</a> -<li><a href="science.html" target="MainFrame">Science and Technical</a> -<li><a href="utility.html" target="MainFrame">Utilities</a> -</ul> - -<b>Hosted by:</b> -<br> -<blockquote> -<A HREF="http://sourceforge.net" -target="_parent"><IMG SRC="http://sourceforge.net/sflogo.php?group_id=3&type=1" -WIDTH="88" HEIGHT="31" ALIGN="BOTTOM" ALT="Sourceforge.net" BORDER="0"></A> -</blockquote> - -</body> -</html> +<html>
+
+<title>Contents</title>
+
+<link rel="stylesheet" type="text/css" href="mesa.css"></head>
+
+<!--Override a few values from the style sheet: -->
+<style>
+<!--
+body {
+ background-color: #cccccc;
+ color: black;
+}
+a:link {
+ color: #000;
+}
+a:visited {
+ color: #000;
+}
+-->
+</style>
+
+
+<b>Documentation</b>
+<ul>
+<li><a href="intro.html" target="MainFrame">Introduction</a>
+<li><a href="news.html" target="MainFrame">News</a>
+<LI><A HREF="developers.html" target="MainFrame">Developers</A>
+<li><a href="systems.html" target="MainFrame">Platforms and Drivers</a>
+<li><a href="license.html" target="MainFrame">License & Copyright</a>
+<li><a href="faq.html" target="MainFrame">FAQ</a>
+<li><a href="relnotes.html" target="MainFrame">Release Notes</a>
+<li><a href="thanks.html" target="MainFrame">Acknowledgements</a>
+<li><a href="conform.html" target="MainFrame">Conformance Testing</a>
+<li>more docs below...
+</ul>
+
+<b>Download / Install</b>
+<ul>
+<li><a href="download.html" target="MainFrame">Downloading / Unpacking</a>
+<li><a href="install.html" target="MainFrame">Compiling / Installing</a>
+<li><a href="precompiled.html" target="MainFrame">Precompiled Libraries</a>
+</ul>
+
+<b>Resources</b>
+<ul>
+<li><a href="lists.html" target="MainFrame">Mailing Lists</a>
+<li><a href="bugs.html" target="MainFrame">Bug Database</a>
+<li><a href="webmaster.html" target="MainFrame">Webmaster</a>
+<li><a href="http://dri.freedesktop.org/" target="_parent">Mesa/DRI Wiki</a>
+</ul>
+
+<b>User Topics</b>
+<ul>
+<li><a href="shading.html" target="MainFrame">Shading Language</a>
+<li><a href="egl.html" target="MainFrame">EGL</a>
+<li><a href="opengles.html" target="MainFrame">OpenGL ES</a>
+<li><a href="openvg.html" target="MainFrame">OpenVG / Vega</a>
+<LI><A HREF="envvars.html" target="MainFrame">Environment Variables</A>
+<LI><A HREF="osmesa.html" target="MainFrame">Off-Screen Rendering</A>
+<LI><A HREF="debugging.html" target="MainFrame">Debugging Tips</A>
+<LI><A HREF="perf.html" target="MainFrame">Performance Tips</A>
+<LI><A HREF="extensions.html" target="MainFrame">Mesa Extensions</A>
+<LI><A HREF="mangling.html" target="MainFrame">Function Name Mangling</A>
+<LI><A href="llvmpipe.html" target="MainFrame">Gallium llvmpipe driver</A>
+</ul>
+
+<b>Developer Topics</b>
+<ul>
+<li><a href="http://sourceforge.net/projects/mesa3d" target="_parent">SourceForge homepage</a>
+<li><a href="repository.html" target="MainFrame">Source Code Repository</a>
+<li><a href="sourcetree.html" target="MainFrame">Source Code Tree</a>
+<li><a href="glu.html" target="MainFrame">SGI's GLU</a>
+<li><a href="utilities.html" target="MainFrame">Utilities</a>
+<li><a href="helpwanted.html" target="MainFrame">Help Wanted</a>
+<li><a href="devinfo.html" target="MainFrame">Development Notes</a>
+<li><a href="sourcedocs.html" target="MainFrame">Source Documentation</a>
+<li><a href="fbdev-dri.html" target="MainFrame">fbdev/DRI Environment</a>
+<li><a href="subset.html" target="MainFrame">Mesa Subset Driver</a>
+<li><a href="glfbdev-driver.html" target="MainFrame">glFBDev Driver</a>
+<LI><A HREF="dispatch.html" target="MainFrame">GL Dispatch</A>
+<li><a href="cell.html" target="MainFrame">Cell Driver</A>
+</ul>
+
+<b>Links</b>
+<ul>
+<li><a href="http://www.opengl.org" target="_parent">OpenGL website</a>
+<li><a href="http://dri.freedesktop.org" target="_parent">DRI website</a>
+<li><a href="http://www.freedesktop.org" target="_parent">freedesktop.org</a>
+<li><a href="games.html" target="MainFrame">Games and Entertainment</a>
+<li><a href="libraries.html" target="MainFrame">Libraries and Toolkits</a>
+<li><a href="modelers.html" target="MainFrame">Modeling and Rendering</a>
+<li><a href="science.html" target="MainFrame">Science and Technical</a>
+<li><a href="utility.html" target="MainFrame">Utilities</a>
+</ul>
+
+<b>Hosted by:</b>
+<br>
+<blockquote>
+<A HREF="http://sourceforge.net"
+target="_parent"><IMG SRC="http://sourceforge.net/sflogo.php?group_id=3&type=1"
+WIDTH="88" HEIGHT="31" ALIGN="BOTTOM" ALT="Sourceforge.net" BORDER="0"></A>
+</blockquote>
+
+</body>
+</html>
diff --git a/mesalib/docs/llvmpipe.html b/mesalib/docs/llvmpipe.html new file mode 100644 index 000000000..5f4e9de3b --- /dev/null +++ b/mesalib/docs/llvmpipe.html @@ -0,0 +1,204 @@ +<HTML>
+
+<TITLE>llvmpipe</TITLE>
+
+<link rel="stylesheet" type="text/css" href="mesa.css"></head>
+
+<BODY>
+
+<H1>Introduction</H1>
+
+<p>
+The Gallium llvmpipe driver is a software rasterizer that uses LLVM to
+do runtime code generation.
+Shaders, point/line/triangle rasterization and vertex processing are
+implemented with LLVM IR which is translated to x86 or x86-64 machine
+code.
+Also, the driver is multithreaded to take advantage of multiple CPU cores
+(up to 8 at this time).
+It's the fastest software rasterizer for Mesa.
+</p>
+
+
+<h1>Requirements</h1>
+
+<dl>
+<dt>An x86 or amd64 processor. 64-bit mode is preferred.</dt>
+<dd>
+ <p>
+ Support for sse2 is strongly encouraged. Support for ssse3, and sse4.1 will
+ yield the most efficient code. The less features the CPU has the more
+ likely is that you ran into underperforming, buggy, or incomplete code.
+ </p>
+ <p>
+ See /proc/cpuinfo to know what your CPU supports.
+ </p>
+</dd>
+<dt>LLVM. Version 2.8 recommended. 2.6 or later required.</dt>
+<dd>
+ <p>
+ <b>NOTE</b>: LLVM 2.8 and earlier will not work on systems that support the
+ Intel AVX extensions (e.g. Sandybridge). LLVM's code generator will
+ fail when trying to emit AVX instructions. This was fixed in LLVM 2.9.
+ </p>
+ <p>
+ For Linux, on a recent Debian based distribution do:
+ </p>
+<pre>
+ aptitude install llvm-dev
+</pre>
+ For a RPM-based distribution do:
+ </p>
+<pre>
+ yum install llvm-devel
+</pre>
+
+ <p>
+ For Windows download pre-built MSVC 9.0 or MinGW binaries from
+ http://people.freedesktop.org/~jrfonseca/llvm/ and set the LLVM environment
+ variable to the extracted path.
+ </p>
+
+ <p>
+ For MSVC there are two set of binaries: llvm-x.x-msvc32mt.7z and
+ llvm-x.x-msvc32mtd.7z .
+ </p>
+
+ <p>
+ You have to set the LLVM=/path/to/llvm-x.x-msvc32mtd env var when passing
+ debug=yes to scons, and LLVM=/path/to/llvm-x.x-msvc32mt when building with
+ debug=no. This is necessary as LLVM builds as static library so the chosen
+ MS CRT must match.
+ </p>
+</dd>
+
+<dt>scons (optional)</dt>
+</dl>
+
+
+
+<h1>Building</h1>
+
+To build everything on Linux invoke scons as:
+
+<pre>
+ scons build=debug libgl-xlib
+</pre>
+
+Alternatively, you can build it with GNU make, if you prefer, by invoking it as
+
+<pre>
+ make linux-llvm
+</pre>
+
+but the rest of these instructions assume that scons is used.
+
+For windows is everything the except except the winsys:
+
+<pre>
+ scons build=debug libgl-gdi
+</pre>
+
+
+<h1>Using</h1>
+
+On Linux, building will create a drop-in alternative for libGL.so into
+
+<pre>
+ build/foo/gallium/targets/libgl-xlib/libGL.so
+</pre>
+or
+<pre>
+ lib/gallium/libGL.so
+</pre>
+
+To use it set the LD_LIBRARY_PATH environment variable accordingly.
+
+For performance evaluation pass debug=no to scons, and use the corresponding
+lib directory without the "-debug" suffix.
+
+On Windows, building will create a drop-in alternative for opengl32.dll. To use
+it put it in the same directory as the application. It can also be used by
+replacing the native ICD driver, but it's quite an advanced usage, so if you
+need to ask, don't even try it.
+
+
+<h1>Profiling</h1>
+
+To profile llvmpipe you should pass the options
+
+<pre>
+ scons build=profile <same-as-before>
+</pre>
+
+This will ensure that frame pointers are used both in C and JIT functions, and
+that no tail call optimizations are done by gcc.
+
+To better profile JIT code you'll need to build LLVM with oprofile integration.
+
+<pre>
+ ./configure \
+ --prefix=$install_dir \
+ --enable-optimized \
+ --disable-profiling \
+ --enable-targets=host-only \
+ --with-oprofile
+
+ make -C "$build_dir"
+ make -C "$build_dir" install
+
+ find "$install_dir/lib" -iname '*.a' -print0 | xargs -0 strip --strip-debug
+</pre>
+
+The you should define
+
+<pre>
+ export LLVM=/path/to/llvm-2.6-profile
+</pre>
+
+and rebuild.
+
+
+<h1>Unit testing</h1>
+
+<p>
+Building will also create several unit tests in
+build/linux-???-debug/gallium/drivers/llvmpipe:
+</p>
+
+</ul>
+<li> lp_test_blend: blending
+<li> lp_test_conv: SIMD vector conversion
+<li> lp_test_format: pixel unpacking/packing
+</ul>
+
+<p>
+Some of this tests can output results and benchmarks to a tab-separated-file
+for posterior analysis, e.g.:
+</p>
+<pre>
+ build/linux-x86_64-debug/gallium/drivers/llvmpipe/lp_test_blend -o blend.tsv
+</pre>
+
+
+<h1>Development Notes</h1>
+
+<ul>
+<li>
+ When looking to this code by the first time start in lp_state_fs.c, and
+ then skim through the lp_bld_* functions called in there, and the comments
+ at the top of the lp_bld_*.c functions.
+</li>
+<li>
+ The driver-independent parts of the LLVM / Gallium code are found in
+ src/gallium/auxiliary/gallivm/. The filenames and function prefixes
+ need to be renamed from "lp_bld_" to something else though.
+</li>
+<li>
+ We use LLVM-C bindings for now. They are not documented, but follow the C++
+ interfaces very closely, and appear to be complete enough for code
+ generation. See
+ http://npcontemplation.blogspot.com/2008/06/secret-of-llvm-c-bindings.html
+ for a stand-alone example. See the llvm-c/Core.h file for reference.
+</li>
+</ul>
|