From 2fb58f16eeec8ef3ec2a25e246477aab64e38a7d Mon Sep 17 00:00:00 2001 From: marha Date: Sun, 10 Apr 2011 18:43:19 +0000 Subject: mesa git update --- mesalib/docs/MESA_agp_offset.spec | 190 ++-- mesalib/docs/MESA_drm_image.spec | 4 +- mesalib/docs/MESA_pack_invert.spec | 276 ++--- mesalib/docs/MESA_release_buffers.spec | 170 +-- mesalib/docs/MESA_resize_buffers.spec | 162 +-- mesalib/docs/MESA_swap_control.spec | 258 ++--- mesalib/docs/MESA_texture_array.spec | 1608 ++++++++++++++-------------- mesalib/docs/MESA_texture_signed_rgba.spec | 428 ++++---- mesalib/docs/MESA_window_pos.spec | 252 ++--- mesalib/docs/MESA_ycbcr_texture.spec | 408 +++---- mesalib/docs/WL_bind_wayland_display.spec | 184 ++-- mesalib/docs/contents.html | 211 ++-- mesalib/docs/llvmpipe.html | 204 ++++ 13 files changed, 2280 insertions(+), 2075 deletions(-) create mode 100644 mesalib/docs/llvmpipe.html (limited to 'mesalib/docs') 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 parameter of PixelStorei and PixelStoref - and the 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 parameter of PixelStorei and PixelStoref + and the 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 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 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 is set to a value of 0, buffer swaps are not synchron- - ized to a video frame. The 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 is set to a value of 0, buffer swaps are not synchro- + nized to a video frame. The 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 parameter of Enable, Disable, and IsEnabled, by - the parameter of GetBooleanv, GetIntegerv, GetFloatv, and - GetDoublev, and by the parameter of TexImage3D, GetTexImage, - GetTexLevelParameteriv, GetTexLevelParameterfv, GetTexParameteriv, and - GetTexParameterfv: - - TEXTURE_1D_ARRAY_EXT 0x8C18 - TEXTURE_2D_ARRAY_EXT 0x8C1A - - Accepted by the parameter of TexImage2D, TexSubImage2D, - CopyTexImage2D, CopyTexSubImage2D, CompressedTexImage2D, - CompressedTexSubImage2D, GetTexLevelParameteriv, and - GetTexLevelParameterfv: - - TEXTURE_1D_ARRAY_EXT - PROXY_TEXTURE_1D_ARRAY_EXT 0x8C19 - - Accepted by the parameter of TexImage3D, TexSubImage3D, - CopyTexSubImage3D, CompressedTexImage3D, CompressedTexSubImage3D, - GetTexLevelParameteriv, and GetTexLevelParameterfv: - - TEXTURE_2D_ARRAY_EXT - PROXY_TEXTURE_2D_ARRAY_EXT 0x8C1B - - Accepted by the 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 parameter of TexParameterf, TexParameteri, - TexParameterfv, and TexParameteriv when the 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 parameter of TexImage3D and - CompressedTexImage3D, and by the 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 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 - "" 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 is - TEXTURE_1D_ARRAY_EXT, and 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 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 . ..." - - -- 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 set to the desired texture target and 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 - texture coordinate, clamped to the range [0, 1]. For texture lookups - from two-dimesional array texture targets, let R be the interpolated - 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) - - ::= "MESA_texture_array" - - ::= "1D" - | "2D" - | "3D" - | "CUBE" - | "RECT" - | (if program option is present) - | (if program option is present) - - ::= "ARRAY1D" - | "ARRAY2D" - - ::= "SHADOW1D" - | "SHADOW2D" - | "SHADOWRECT" - | (if program option is present) - - ::= "SHADOWARRAY1D" - | "SHADOWARRAY2D" - - - -- Add Section 3.11.4.5.4 "Texture Stack Option" - - "If a fragment program specifies the "MESA_texture_array" program - option, the 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 - are used by all texture targets. Component usage for each - 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 , 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. is an integer indicating the - layer number, and is treated identically to the parameter in - FramebufferTexture3DEXT. The error INVALID_VALUE is generated if - is negative. The error INVALID_OPERATION is generated if - is non-zero and is not the name of a three dimensional - texture or one- or two-dimensional array texture. Unlike - FramebufferTexture3D, no parameter is accepted. - - If is non-zero and the command does not result in an error, - the framebuffer attachment state corresponding to is - updated as in the other FramebufferTexture commands, except that - FRAMEBUFFER_ATTACHMENT_TEXTURE_LAYER_EXT is set to ." - - -- 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 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 will contain the number of texture layer attached to the - attachment point. Otherwise, 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 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 parameter of Enable, Disable, and IsEnabled, by + the parameter of GetBooleanv, GetIntegerv, GetFloatv, and + GetDoublev, and by the parameter of TexImage3D, GetTexImage, + GetTexLevelParameteriv, GetTexLevelParameterfv, GetTexParameteriv, and + GetTexParameterfv: + + TEXTURE_1D_ARRAY_EXT 0x8C18 + TEXTURE_2D_ARRAY_EXT 0x8C1A + + Accepted by the parameter of TexImage2D, TexSubImage2D, + CopyTexImage2D, CopyTexSubImage2D, CompressedTexImage2D, + CompressedTexSubImage2D, GetTexLevelParameteriv, and + GetTexLevelParameterfv: + + TEXTURE_1D_ARRAY_EXT + PROXY_TEXTURE_1D_ARRAY_EXT 0x8C19 + + Accepted by the parameter of TexImage3D, TexSubImage3D, + CopyTexSubImage3D, CompressedTexImage3D, CompressedTexSubImage3D, + GetTexLevelParameteriv, and GetTexLevelParameterfv: + + TEXTURE_2D_ARRAY_EXT + PROXY_TEXTURE_2D_ARRAY_EXT 0x8C1B + + Accepted by the 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 parameter of TexParameterf, TexParameteri, + TexParameterfv, and TexParameteriv when the 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 parameter of TexImage3D and + CompressedTexImage3D, and by the 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 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 + "" 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 is + TEXTURE_1D_ARRAY_EXT, and 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 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 . ..." + + -- 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 set to the desired texture target and 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 + texture coordinate, clamped to the range [0, 1]. For texture lookups + from two-dimensional array texture targets, let R be the interpolated + 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) + + ::= "MESA_texture_array" + + ::= "1D" + | "2D" + | "3D" + | "CUBE" + | "RECT" + | (if program option is present) + | (if program option is present) + + ::= "ARRAY1D" + | "ARRAY2D" + + ::= "SHADOW1D" + | "SHADOW2D" + | "SHADOWRECT" + | (if program option is present) + + ::= "SHADOWARRAY1D" + | "SHADOWARRAY2D" + + + -- Add Section 3.11.4.5.4 "Texture Stack Option" + + "If a fragment program specifies the "MESA_texture_array" program + option, the 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 + are used by all texture targets. Component usage for each + 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 , 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. is an integer indicating the + layer number, and is treated identically to the parameter in + FramebufferTexture3DEXT. The error INVALID_VALUE is generated if + is negative. The error INVALID_OPERATION is generated if + is non-zero and is not the name of a three dimensional + texture or one- or two-dimensional array texture. Unlike + FramebufferTexture3D, no parameter is accepted. + + If is non-zero and the command does not result in an error, + the framebuffer attachment state corresponding to is + updated as in the other FramebufferTexture commands, except that + FRAMEBUFFER_ATTACHMENT_TEXTURE_LAYER_EXT is set to ." + + -- 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 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 will contain the number of texture layer attached to the + attachment point. Otherwise, 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 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 parameter of - TexImage1D, TexImage2D, TexImage3D, CopyTexImage1D, and CopyTexImage2D: - - RGBA_SNORM 0x8F93 - RGBA8_SNORM 0x8F97 - - Returned by the 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 - 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 parameter of + TexImage1D, TexImage2D, TexImage3D, CopyTexImage1D, and CopyTexImage2D: + + RGBA_SNORM 0x8F93 + RGBA8_SNORM 0x8F97 + + Returned by the 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 + 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 and parameters of - TexImage2D and TexSubImage2D: - - YCBCR_MESA 0x8757 - - Accepted by the 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 is - MESA_YCBCR but is not MESA_YCBCR. - - INVALID_ENUM is generated by TexImage2D if is MESA_YCBCR but - is not MESA_YCBCR. - - INVALID_VALUE is generated by TexImage2D if is MESA_YCBCR and - is MESA_YCBCR and is not zero. - - INVALID_OPERATION is generated by TexSubImage2D if the internal image - format is YCBCR_MESA and 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 and parameters of + TexImage2D and TexSubImage2D: + + YCBCR_MESA 0x8757 + + Accepted by the 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 is + MESA_YCBCR but is not MESA_YCBCR. + + INVALID_ENUM is generated by TexImage2D if is MESA_YCBCR but + is not MESA_YCBCR. + + INVALID_VALUE is generated by TexImage2D if is MESA_YCBCR and + is MESA_YCBCR and is not zero. + + INVALID_OPERATION is generated by TexSubImage2D if the internal image + format is YCBCR_MESA and 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 - Benjamin Franzke - -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 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 + Benjamin Franzke + +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 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 @@ - - -Contents - - - - - - - -Documentation - - -Download / Install - - -Resources - - -User Topics - - -Developer Topics - - -Links - - -Hosted by: -
-
-Sourceforge.net -
- - - + + +Contents + + + + + + + +Documentation + + +Download / Install + + +Resources + + +User Topics + + +Developer Topics + + +Links + + +Hosted by: +
+
+Sourceforge.net +
+ + + 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 @@ + + +llvmpipe + + + + + +

Introduction

+ +

+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. +

+ + +

Requirements

+ +
+
An x86 or amd64 processor. 64-bit mode is preferred.
+
+

+ 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. +

+

+ See /proc/cpuinfo to know what your CPU supports. +

+
+
LLVM. Version 2.8 recommended. 2.6 or later required.
+
+

+ NOTE: 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. +

+

+ For Linux, on a recent Debian based distribution do: +

+
+     aptitude install llvm-dev
+
+ For a RPM-based distribution do: +

+
+     yum install llvm-devel
+
+ +

+ 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. +

+ +

+ For MSVC there are two set of binaries: llvm-x.x-msvc32mt.7z and + llvm-x.x-msvc32mtd.7z . +

+ +

+ 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. +

+
+ +
scons (optional)
+
+ + + +

Building

+ +To build everything on Linux invoke scons as: + +
+  scons build=debug libgl-xlib
+
+ +Alternatively, you can build it with GNU make, if you prefer, by invoking it as + +
+  make linux-llvm
+
+ +but the rest of these instructions assume that scons is used. + +For windows is everything the except except the winsys: + +
+  scons build=debug libgl-gdi
+
+ + +

Using

+ +On Linux, building will create a drop-in alternative for libGL.so into + +
+  build/foo/gallium/targets/libgl-xlib/libGL.so
+
+or +
+  lib/gallium/libGL.so
+
+ +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. + + +

Profiling

+ +To profile llvmpipe you should pass the options + +
+  scons build=profile 
+
+ +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. + +
+  ./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
+
+ +The you should define + +
+  export LLVM=/path/to/llvm-2.6-profile
+
+ +and rebuild. + + +

Unit testing

+ +

+Building will also create several unit tests in +build/linux-???-debug/gallium/drivers/llvmpipe: +

+ + +
  • lp_test_blend: blending +
  • lp_test_conv: SIMD vector conversion +
  • lp_test_format: pixel unpacking/packing + + +

    +Some of this tests can output results and benchmarks to a tab-separated-file +for posterior analysis, e.g.: +

    +
    +  build/linux-x86_64-debug/gallium/drivers/llvmpipe/lp_test_blend -o blend.tsv
+
    + + +

    Development Notes

    + +
      +
    • + 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. +
      • +
    • + 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. +
      • +
    • + 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. +
      • +
    -- cgit v1.2.3