docs: move specs to a separate folder
Handle legacy/obsolete specs as well List all specs in extensions.html Mark 'OLD' extensions as obsolete in extensions.html Update the spec location in old relnotes Signed-off-by: Emil Velikov <emil.l.velikov@gmail.com> Reviewed-by: Brian Paul <brianp@vmware.com>
This commit is contained in:
Emil Velikov
@@ -0,0 +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
|
||||
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
|
||||
@@ -0,0 +1,96 @@
|
||||
Name
|
||||
|
||||
MESA_copy_sub_buffer
|
||||
|
||||
Name Strings
|
||||
|
||||
GLX_MESA_copy_sub_buffer
|
||||
|
||||
Contact
|
||||
|
||||
Brian Paul (brian.paul 'at' tungstengraphics.com)
|
||||
|
||||
Status
|
||||
|
||||
Shipping since Mesa 2.6 in February, 1998.
|
||||
|
||||
Version
|
||||
|
||||
Last Modified Date: 12 January 2009
|
||||
|
||||
Number
|
||||
|
||||
215
|
||||
|
||||
Dependencies
|
||||
|
||||
OpenGL 1.0 or later is required.
|
||||
GLX 1.0 or later is required.
|
||||
|
||||
Overview
|
||||
|
||||
The glxCopySubBufferMESA() function copies a rectangular region
|
||||
of the back color buffer to the front color buffer. This can be
|
||||
used to quickly repaint 3D windows in response to expose events
|
||||
when the back color buffer cannot be damaged by other windows.
|
||||
|
||||
IP Status
|
||||
|
||||
Open-source; freely implementable.
|
||||
|
||||
Issues
|
||||
|
||||
None.
|
||||
|
||||
New Procedures and Functions
|
||||
|
||||
void glXCopySubBufferMESA( Display *dpy, GLXDrawable drawable,
|
||||
int x, int y, int width, int height );
|
||||
|
||||
New Tokens
|
||||
|
||||
None.
|
||||
|
||||
Additions to Chapter 3 of the GLX 1.3 Specification (Functions and Errors)
|
||||
|
||||
Add to section 3.3.10 Double Buffering:
|
||||
|
||||
The function
|
||||
|
||||
void glXCopySubBufferMESA( Display *dpy, GLXDrawable drawable,
|
||||
int x, int y, int width, int height );
|
||||
|
||||
may be used to copy a rectangular region of the back color buffer to
|
||||
the front color buffer. This can be used to quickly repaint 3D windows
|
||||
in response to expose events when the back color buffer cannot be
|
||||
damaged by other windows.
|
||||
|
||||
<x> and <y> indicates the lower-left corner of the region to copy and
|
||||
<width> and <height> indicate the size in pixels. Coordinate (0,0)
|
||||
corresponds to the lower-left pixel of the window, like glReadPixels.
|
||||
|
||||
If dpy and drawable are the display and drawable for the calling
|
||||
thread's current context, glXCopySubBufferMESA performs an
|
||||
implicit glFlush before it returns. Subsequent OpenGL commands
|
||||
may be issued immediately after calling glXCopySubBufferMESA, but
|
||||
are not executed until the copy is completed.
|
||||
|
||||
GLX Protocol
|
||||
|
||||
None at this time. The extension is implemented in terms of ordinary
|
||||
Xlib protocol inside of Mesa.
|
||||
|
||||
Errors
|
||||
|
||||
None.
|
||||
|
||||
New State
|
||||
|
||||
None.
|
||||
|
||||
Revision History
|
||||
|
||||
12 January 2009 Ian Romanick - Added language about implicit flush
|
||||
and command completion.
|
||||
8 June 2000 Brian Paul - initial specification
|
||||
|
||||
@@ -0,0 +1,153 @@
|
||||
Name
|
||||
|
||||
MESA_drm_image
|
||||
|
||||
Name Strings
|
||||
|
||||
EGL_MESA_drm_image
|
||||
|
||||
Contact
|
||||
|
||||
Kristian Høgsberg <krh@bitplanet.net>
|
||||
|
||||
Status
|
||||
|
||||
Proposal
|
||||
|
||||
Version
|
||||
|
||||
Version 2, August 25, 2010
|
||||
|
||||
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 integrating EGLImage with the
|
||||
Linux DRM mode setting and memory management drivers. The extension
|
||||
lets applications create EGLImages without a client API resource and
|
||||
lets the application get the DRM buffer handles.
|
||||
|
||||
IP Status
|
||||
|
||||
Open-source; freely implementable.
|
||||
|
||||
New Procedures and Functions
|
||||
|
||||
EGLImageKHR eglCreateDRMImageMESA(EGLDisplay dpy,
|
||||
const EGLint *attrib_list);
|
||||
|
||||
EGLBoolean eglExportDRMImageMESA(EGLDisplay dpy,
|
||||
EGLImageKHR image,
|
||||
EGLint *name,
|
||||
EGLint *handle,
|
||||
EGLint *stride);
|
||||
|
||||
New Tokens
|
||||
|
||||
Accepted in the <attrib_list> parameter of eglCreateDRMImageMESA:
|
||||
|
||||
EGL_DRM_BUFFER_FORMAT_MESA 0x31D0
|
||||
EGL_DRM_BUFFER_USE_MESA 0x31D1
|
||||
|
||||
Accepted as values for the EGL_IMAGE_FORMAT_MESA attribute:
|
||||
|
||||
EGL_DRM_BUFFER_FORMAT_ARGB32_MESA 0x31D2
|
||||
|
||||
Bits accepted in EGL_DRM_BUFFER_USE_MESA:
|
||||
|
||||
EGL_DRM_BUFFER_USE_SCANOUT_MESA 0x0001
|
||||
EGL_DRM_BUFFER_USE_SHARE_MESA 0x0002
|
||||
EGL_DRM_BUFFER_USE_CURSOR_MESA 0x0004
|
||||
|
||||
Accepted in the <target> parameter of eglCreateImageKHR:
|
||||
|
||||
EGL_DRM_BUFFER_MESA 0x31D3
|
||||
|
||||
Use when importing drm buffer:
|
||||
|
||||
EGL_DRM_BUFFER_STRIDE_MESA 0x31D4
|
||||
EGL_DRM_BUFFER_FORMAT_MESA 0x31D0
|
||||
|
||||
Additions to the EGL 1.4 Specification:
|
||||
|
||||
To create a DRM EGLImage, call
|
||||
|
||||
EGLImageKHR eglCreateDRMImageMESA(EGLDisplay dpy,
|
||||
const EGLint *attrib_list);
|
||||
|
||||
In the attribute list, pass EGL_WIDTH, EGL_HEIGHT and format and
|
||||
use in the attrib list using EGL_DRM_BUFFER_FORMAT_MESA and
|
||||
EGL_DRM_BUFFER_USE_MESA. The only format specified by this
|
||||
extension is EGL_DRM_BUFFER_FORMAT_ARGB32_MESA, where each pixel
|
||||
is a CPU-endian, 32-bit quantity, with alpha in the upper 8 bits,
|
||||
then red, then green, then blue. The bit values accepted by
|
||||
EGL_DRM_BUFFER_USE_MESA are EGL_DRM_BUFFER_USE_SCANOUT_MESA,
|
||||
EGL_DRM_BUFFER_USE_SHARE_MESA and EGL_DRM_BUFFER_USE_CURSOR_MESA.
|
||||
EGL_DRM_BUFFER_USE_SCANOUT_MESA requests that the created EGLImage
|
||||
should be usable as a scanout buffer with the DRM kernel
|
||||
modesetting API. EGL_DRM_BUFFER_USE_SHARE_MESA requests that the
|
||||
EGLImage can be shared with other processes by passing the
|
||||
underlying DRM buffer name. EGL_DRM_BUFFER_USE_CURSOR_MESA
|
||||
requests that the image must be usable as a cursor with KMS. When
|
||||
EGL_DRM_BUFFER_USE_CURSOR_MESA is set, width and height must both
|
||||
be 64.
|
||||
|
||||
To create a process local handle or a global DRM name for a
|
||||
buffer, call
|
||||
|
||||
EGLBoolean eglExportDRMImageMESA(EGLDisplay dpy,
|
||||
EGLImageKHR image,
|
||||
EGLint *name,
|
||||
EGLint *handle,
|
||||
EGLint *stride);
|
||||
|
||||
If <name> is non-NULL, a global name is assigned to the image and
|
||||
written to <name>, the handle (local to the DRM file descriptor,
|
||||
for use with DRM kernel modesetting API) is written to <handle> if
|
||||
non-NULL and the stride (in bytes) is written to <stride>, if
|
||||
non-NULL.
|
||||
|
||||
Import a shared buffer by calling eglCreateImageKHR with
|
||||
EGL_DRM_BUFFER_MESA as the target, using EGL_WIDTH, EGL_HEIGHT,
|
||||
EGL_DRM_BUFFER_FORMAT_MESA, EGL_DRM_BUFFER_STRIDE_MESA
|
||||
in the attrib list.
|
||||
|
||||
Issues
|
||||
|
||||
1. Why don't we use eglCreateImageKHR with a target that
|
||||
indicates that we want to create an EGLImage from scratch?
|
||||
|
||||
RESOLVED: The eglCreateImageKHR entry point is reserved for
|
||||
creating an EGLImage from an already existing client API
|
||||
resource. This is fine when we're creating the EGLImage from
|
||||
an existing DRM buffer name, it doesn't seem right to overload
|
||||
the function to also allocate the underlying resource.
|
||||
|
||||
2. Why don't we use an eglQueryImageMESA type functions for
|
||||
querying the DRM EGLImage attributes (name, handle, and stride)?
|
||||
|
||||
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 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,
|
||||
so we use a new EGL extension entry point instead.
|
||||
|
||||
Revision History
|
||||
|
||||
Version 1, June 3, 2010
|
||||
Initial draft (Kristian Høgsberg)
|
||||
Version 2, August 25, 2010
|
||||
Flesh out the extension a bit, add final EGL tokens, capture
|
||||
some of the original discussion in the issues section.
|
||||
@@ -0,0 +1,158 @@
|
||||
Name
|
||||
|
||||
MESA_multithread_makecurrent
|
||||
|
||||
Name Strings
|
||||
|
||||
GLX_MESA_multithread_makecurrent
|
||||
|
||||
Contact
|
||||
|
||||
Eric Anholt (eric@anholt.net)
|
||||
|
||||
Status
|
||||
|
||||
Not shipping.
|
||||
|
||||
Version
|
||||
|
||||
Last Modified Date: 21 February 2011
|
||||
|
||||
Number
|
||||
|
||||
TBD
|
||||
|
||||
Dependencies
|
||||
|
||||
OpenGL 1.0 or later is required.
|
||||
GLX 1.3 or later is required.
|
||||
|
||||
Overview
|
||||
|
||||
The GLX context setup encourages multithreaded applications to
|
||||
create a context per thread which each operate on their own
|
||||
objects in parallel, and leaves synchronization for write access
|
||||
to shared objects up to the application.
|
||||
|
||||
For some applications, maintaining per-thread contexts and
|
||||
ensuring that the glFlush happens in one thread before another
|
||||
thread starts working on that object is difficult. For them,
|
||||
using the same context across multiple threads and protecting its
|
||||
usage with a mutex is both higher performance and easier to
|
||||
implement. This extension gives those applications that option by
|
||||
relaxing the context binding requirements.
|
||||
|
||||
This new behavior matches the requirements of AGL, while providing
|
||||
a feature not specified in WGL.
|
||||
|
||||
IP Status
|
||||
|
||||
Open-source; freely implementable.
|
||||
|
||||
Issues
|
||||
|
||||
None.
|
||||
|
||||
New Procedures and Functions
|
||||
|
||||
None.
|
||||
|
||||
New Tokens
|
||||
|
||||
None.
|
||||
|
||||
Changes to Chapter 2 of the GLX 1.3 Specification (Functions and Errors)
|
||||
|
||||
Replace the following sentence from section 2.2 Rendering Contexts:
|
||||
In addition, a rendering context can be current for only one
|
||||
thread at a time.
|
||||
with:
|
||||
In addition, an indirect rendering context can be current for
|
||||
only one thread at a time. A direct rendering context may be
|
||||
current to multiple threads, with synchronization of access to
|
||||
the context thruogh the GL managed by the application through
|
||||
mutexes.
|
||||
|
||||
Changes to Chapter 3 of the GLX 1.3 Specification (Functions and Errors)
|
||||
|
||||
Replace the following sentence from section 3.3.7 Rendering Contexts:
|
||||
If ctx is current to some other thread, then
|
||||
glXMakeContextCurrent will generate a BadAccess error.
|
||||
with:
|
||||
If ctx is an indirect context current to some other thread,
|
||||
then glXMakeContextCurrent will generate a BadAccess error.
|
||||
|
||||
Replace the following sentence from section 3.5 Rendering Contexts:
|
||||
If ctx is current to some other thread, then
|
||||
glXMakeCurrent will generate a BadAccess error.
|
||||
with:
|
||||
If ctx is an indirect context current to some other thread,
|
||||
then glXMakeCurrent will generate a BadAccess error.
|
||||
|
||||
GLX Protocol
|
||||
|
||||
None. The GLX extension only extends to direct rendering contexts.
|
||||
|
||||
Errors
|
||||
|
||||
None.
|
||||
|
||||
New State
|
||||
|
||||
None.
|
||||
|
||||
Issues
|
||||
|
||||
(1) What happens if the app binds a context/drawable in multiple
|
||||
threads, then binds a different context/thread in one of them?
|
||||
|
||||
As with binding a new context from the current thread, the old
|
||||
context's refcount is reduced and the new context's refcount is
|
||||
increased.
|
||||
|
||||
(2) What happens if the app binds a context/drawable in multiple
|
||||
threads, then binds None/None in one of them?
|
||||
|
||||
The GLX context is unreferenced from that thread, and the other
|
||||
threads retain their GLX context binding.
|
||||
|
||||
(3) What happens if the app binds a context/drawable in 7 threads,
|
||||
then destroys the context in one of them?
|
||||
|
||||
As with GLX context destruction previously, the XID is destroyed
|
||||
but the context remains usable by threads that have the context
|
||||
current.
|
||||
|
||||
(4) What happens if the app binds a new drawable/readable with
|
||||
glXMakeCurrent() when it is already bound to another thread?
|
||||
|
||||
The context becomes bound to the new drawable/readable, and
|
||||
further rendering in either thread will use the new
|
||||
drawable/readable.
|
||||
|
||||
(5) What requirements should be placed on the user managing contexts
|
||||
from multiple threads?
|
||||
|
||||
The intention is to allow multithreaded access to the GL at the
|
||||
minimal performance cost, so requiring that the GL do general
|
||||
synchronization (beyond that already required by context sharing)
|
||||
is not an option, and synchronizing of GL's access to the GL
|
||||
context between multiple threads is left to the application to do
|
||||
across GL calls. However, it would be unfortunate for a library
|
||||
doing multithread_makecurrent to require that other libraries
|
||||
share in synchronization for binding of their own contexts, so the
|
||||
refcounting of the contexts is required to be threadsafe.
|
||||
|
||||
(6) Does this apply to indirect contexts?
|
||||
|
||||
This was ignored in the initial revision of the spec. Behavior
|
||||
for indirect contexts is left as-is.
|
||||
|
||||
Revision History
|
||||
|
||||
20 November 2009 Eric Anholt - initial specification
|
||||
22 November 2009 Eric Anholt - added issues from Ian Romanick.
|
||||
3 February 2011 Eric Anholt - updated with resolution to issues 1-3
|
||||
3 February 2011 Eric Anholt - added issue 4, 5
|
||||
21 February 2011 Eric Anholt - Include glXMakeCurrent() sentence
|
||||
along with glXMakeContextCurrent() for removal.
|
||||
@@ -0,0 +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 define UNPACK_INVERT_MESA for glDrawPixels, etc?
|
||||
|
||||
Resolved: No, we're only concerned with pixel packing. There are other
|
||||
solutions for inverting images when using glDrawPixels (negative Y pixel
|
||||
zoom) or glTexImage (invert the vertex T coordinates). It would be easy
|
||||
enough to define a complementary extension for pixel packing in the
|
||||
future if needed.
|
||||
|
||||
New Procedures and Functions
|
||||
|
||||
None
|
||||
|
||||
New Tokens
|
||||
|
||||
Accepted by the <pname> parameter of PixelStorei and PixelStoref
|
||||
and the <pname> parameter of GetIntegerv, GetFloatv, GetDoublev
|
||||
and GetBooleanv:
|
||||
|
||||
PACK_INVERT_MESA 0x8758
|
||||
|
||||
Additions to Chapter 2 of the OpenGL 1.4 Specification (OpenGL Operation)
|
||||
|
||||
None
|
||||
|
||||
Additions to Chapter 3 of the OpenGL 1.4 Specification (Rasterization)
|
||||
|
||||
None
|
||||
|
||||
Additions to Chapter 4 of the OpenGL 1.4 Specification (Per-Fragment
|
||||
Operations and the Frame Buffer)
|
||||
|
||||
Add the following entry to table 4.4 (PixelStore parameters) on page 182:
|
||||
|
||||
Parameter Name Type Initial Value Valid Range
|
||||
---------------------------------------------------------
|
||||
PACK_INVERT_MESA boolean FALSE TRUE/FALSE
|
||||
|
||||
In the section labeled "Placement in Client Memory" on page 184
|
||||
insert the following text into the paragraph before the sentence
|
||||
that starts with "If the format is RED, GREEN, BLUE...":
|
||||
|
||||
"The parameter PACK_INVERT_MESA controls whether the image is packed
|
||||
in bottom-to-top order (the default) or top-to-bottom order. Equation
|
||||
3.8 is modified as follows:
|
||||
|
||||
... the first element of the Nth row is indicated by
|
||||
|
||||
p + Nk, if PACK_INVERT_MESA is false
|
||||
p + k * (H - 1) - Nk, if PACK_INVERT_MESA is true, where H is the
|
||||
image height
|
||||
"
|
||||
|
||||
Additions to Chapter 5 of the OpenGL 1.4 Specification (Special Functions)
|
||||
|
||||
None
|
||||
|
||||
Additions to Chapter 6 of the OpenGL 1.4 Specification (State and
|
||||
State Requests)
|
||||
|
||||
None
|
||||
|
||||
Additions to Appendix A of the OpenGL 1.4 Specification (Invariance)
|
||||
|
||||
None
|
||||
|
||||
Additions to the AGL/GLX/WGL Specifications
|
||||
|
||||
None
|
||||
|
||||
GLX Protocol
|
||||
|
||||
None
|
||||
|
||||
Errors
|
||||
|
||||
None
|
||||
|
||||
New State
|
||||
|
||||
Add the following entry to table 6.20 (Pixels) on page 235:
|
||||
|
||||
Get Value Type Get Cmd Initial Value Description Sec Attribute
|
||||
--------------------------------------------------------------------------------------------------
|
||||
PACK_INVERT_MESA boolean GetBoolean FALSE Value of PACK_INVERT_MESA 4.3.2 pixel-store
|
||||
|
||||
Revision History
|
||||
|
||||
21 September 2002 - Initial draft
|
||||
@@ -0,0 +1,90 @@
|
||||
Name
|
||||
|
||||
MESA_pixmap_colormap
|
||||
|
||||
Name Strings
|
||||
|
||||
GLX_MESA_pixmap_colormap
|
||||
|
||||
Contact
|
||||
|
||||
Brian Paul (brian.paul 'at' tungstengraphics.com)
|
||||
|
||||
Status
|
||||
|
||||
Shipping since Mesa 1.2.8 in May, 1996.
|
||||
|
||||
Version
|
||||
|
||||
Last Modified Date: 8 June 2000
|
||||
|
||||
Number
|
||||
|
||||
216
|
||||
|
||||
Dependencies
|
||||
|
||||
OpenGL 1.0 or later is required.
|
||||
GLX 1.0 or later is required.
|
||||
|
||||
Overview
|
||||
|
||||
Since Mesa allows RGB rendering into drawables with PseudoColor,
|
||||
StaticColor, GrayScale and StaticGray visuals, Mesa needs a colormap
|
||||
in order to compute pixel values during rendering.
|
||||
|
||||
The colormap associated with a window can be queried with normal
|
||||
Xlib functions but there is no colormap associated with pixmaps.
|
||||
|
||||
The glXCreateGLXPixmapMESA function is an alternative to glXCreateGLXPixmap
|
||||
which allows specification of a colormap.
|
||||
|
||||
IP Status
|
||||
|
||||
Open-source; freely implementable.
|
||||
|
||||
Issues
|
||||
|
||||
None.
|
||||
|
||||
New Procedures and Functions
|
||||
|
||||
GLXPixmap glXCreateGLXPixmapMESA( Display *dpy, XVisualInfo *visual,
|
||||
Pixmap pixmap, Colormap cmap );
|
||||
|
||||
New Tokens
|
||||
|
||||
None.
|
||||
|
||||
Additions to Chapter 3 of the GLX 1.3 Specification (Functions and Errors)
|
||||
|
||||
Add to section 3.4.2 Off Screen Rendering
|
||||
|
||||
The Mesa implementation of GLX allows RGB rendering into X windows and
|
||||
pixmaps of any visual class, not just TrueColor or DirectColor. In order
|
||||
to compute pixel values from RGB values Mesa requires a colormap.
|
||||
|
||||
The function
|
||||
|
||||
GLXPixmap glXCreateGLXPixmapMESA( Display *dpy, XVisualInfo *visual,
|
||||
Pixmap pixmap, Colormap cmap );
|
||||
|
||||
allows one to create a GLXPixmap with a specific colormap. The image
|
||||
rendered into the pixmap may then be copied to a window (which uses the
|
||||
same colormap and visual) with the expected results.
|
||||
|
||||
GLX Protocol
|
||||
|
||||
None since this is a client-side extension.
|
||||
|
||||
Errors
|
||||
|
||||
None.
|
||||
|
||||
New State
|
||||
|
||||
None.
|
||||
|
||||
Revision History
|
||||
|
||||
8 June 2000 - initial specification
|
||||
@@ -0,0 +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 ancillary data associated with the window
|
||||
or pixmap.
|
||||
|
||||
The glxMesaReleaseBuffers() function can be used to explicitly indicate
|
||||
when the back color buffer, depth buffer, stencil buffer, and/or accumu-
|
||||
lation buffer associated with a drawable can be freed.
|
||||
|
||||
IP Status
|
||||
|
||||
Open-source; freely implementable.
|
||||
|
||||
Issues
|
||||
|
||||
None.
|
||||
|
||||
New Procedures and Functions
|
||||
|
||||
Bool glXReleaseBuffersMESA( Display *dpy, GLXDrawable d );
|
||||
|
||||
New Tokens
|
||||
|
||||
None.
|
||||
|
||||
Additions to Chapter 3 of the GLX 1.3 Specification (Functions and Errors)
|
||||
|
||||
The function
|
||||
|
||||
Bool glXReleaseBuffersMESA( Display *dpy, GLXDrawable d );
|
||||
|
||||
causes all software ancillary buffers (back buffer, depth, stencil,
|
||||
accum, etc) associated with the named drawable to be immediately
|
||||
deallocated. True is returned if <d> is a valid Mesa GLX drawable,
|
||||
else False is returned. After calling glXReleaseBuffersMESA, the
|
||||
drawable should no longer be used for GL rendering. Results of
|
||||
attempting to do so are undefined.
|
||||
|
||||
|
||||
GLX Protocol
|
||||
|
||||
None, since this is a client-side operation.
|
||||
|
||||
Errors
|
||||
|
||||
None.
|
||||
|
||||
New State
|
||||
|
||||
None.
|
||||
|
||||
Revision History
|
||||
|
||||
8 June 2000 - initial specification
|
||||
@@ -0,0 +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 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
|
||||
@@ -0,0 +1,85 @@
|
||||
Name
|
||||
|
||||
MESA_set_3dfx_mode
|
||||
|
||||
Name Strings
|
||||
|
||||
GLX_MESA_set_3dfx_mode
|
||||
|
||||
Contact
|
||||
|
||||
Brian Paul (brian.paul 'at' tungstengraphics.com)
|
||||
|
||||
Status
|
||||
|
||||
Shipping since Mesa 2.6 in February, 1998.
|
||||
|
||||
Version
|
||||
|
||||
Last Modified Date: 8 June 2000
|
||||
|
||||
Number
|
||||
|
||||
218
|
||||
|
||||
Dependencies
|
||||
|
||||
OpenGL 1.0 or later is required.
|
||||
GLX 1.0 or later is required.
|
||||
|
||||
Overview
|
||||
|
||||
The Mesa Glide driver allows full-screen rendering or rendering into
|
||||
an X window. The glXSet3DfxModeMESA() function allows an application
|
||||
to switch between full-screen and windowed rendering.
|
||||
|
||||
IP Status
|
||||
|
||||
Open-source; freely implementable.
|
||||
|
||||
Issues
|
||||
|
||||
None.
|
||||
|
||||
New Procedures and Functions
|
||||
|
||||
GLboolean glXSet3DfxModeMESA( GLint mode );
|
||||
|
||||
New Tokens
|
||||
|
||||
GLX_3DFX_WINDOW_MODE_MESA 0x1
|
||||
GLX_3DFX_FULLSCREEN_MODE_MESA 0x2
|
||||
|
||||
Additions to Chapter 3 of the GLX 1.3 Specification (Functions and Errors)
|
||||
|
||||
The Mesa Glide device driver allows either rendering in full-screen
|
||||
mode or rendering into an X window. An application can switch between
|
||||
full-screen and window rendering with the command:
|
||||
|
||||
GLboolean glXSet3DfxModeMESA( GLint mode );
|
||||
|
||||
<mode> may either be GLX_3DFX_WINDOW_MODE_MESA to indicate window
|
||||
rendering or GLX_3DFX_FULLSCREEN_MODE_MESA to indicate full-screen mode.
|
||||
|
||||
GL_TRUE is returned if <mode> is valid and the operation completed
|
||||
normally. GL_FALSE is returned if <mode> is invalid or if the Glide
|
||||
driver is not being used.
|
||||
|
||||
Note that only one drawable and context can be created at any given
|
||||
time with the Mesa Glide driver.
|
||||
|
||||
GLX Protocol
|
||||
|
||||
None since this is a client-side extension.
|
||||
|
||||
Errors
|
||||
|
||||
None.
|
||||
|
||||
New State
|
||||
|
||||
None.
|
||||
|
||||
Revision History
|
||||
|
||||
8 June 2000 - initial specification
|
||||
@@ -0,0 +1,264 @@
|
||||
Name
|
||||
|
||||
MESA_shader_debug
|
||||
|
||||
Name Strings
|
||||
|
||||
GL_MESA_shader_debug
|
||||
|
||||
Contact
|
||||
|
||||
Brian Paul (brian.paul 'at' tungstengraphics.com)
|
||||
Michal Krol (mjkrol 'at' gmail.com)
|
||||
|
||||
Status
|
||||
|
||||
Obsolete.
|
||||
|
||||
Version
|
||||
|
||||
Last Modified Date: July 30, 2006
|
||||
Author Revision: 0.2
|
||||
|
||||
Number
|
||||
|
||||
TBD
|
||||
|
||||
Dependencies
|
||||
|
||||
OpenGL 1.0 is required.
|
||||
|
||||
The ARB_shader_objects extension is required.
|
||||
|
||||
The ARB_shading_language_100 extension is required.
|
||||
|
||||
The extension is written against the OpenGL 1.5 specification.
|
||||
|
||||
The extension is written against the OpenGL Shading Language 1.10
|
||||
Specification.
|
||||
|
||||
Overview
|
||||
|
||||
This extension introduces a debug object that can be attached to
|
||||
a program object to enable debugging. Vertex and/or fragment shader,
|
||||
during execution, issue diagnostic function calls that are logged
|
||||
to the debug object's log. A separate debug log for each shader type
|
||||
is maintained. A debug object can be attached, detached and queried
|
||||
at any time outside the Begin/End pair. Multiple debug objects can
|
||||
be attached to a single program object.
|
||||
|
||||
IP Status
|
||||
|
||||
None
|
||||
|
||||
Issues
|
||||
|
||||
None
|
||||
|
||||
New Procedures and Functions
|
||||
|
||||
handleARB CreateDebugObjectMESA(void)
|
||||
void ClearDebugLogMESA(handleARB obj, enum logType, enum shaderType)
|
||||
void GetDebugLogMESA(handleARB obj, enum logType, enum shaderType,
|
||||
sizei maxLength, sizei *length,
|
||||
charARB *debugLog)
|
||||
sizei GetDebugLogLengthMESA(handleARB obj, enum logType,
|
||||
enum shaderType)
|
||||
|
||||
New Types
|
||||
|
||||
None
|
||||
|
||||
New Tokens
|
||||
|
||||
Returned by the <params> parameter of GetObjectParameter{fi}vARB:
|
||||
|
||||
DEBUG_OBJECT_MESA 0x8759
|
||||
|
||||
Accepted by the <logType> argument of ClearDebugLogMESA,
|
||||
GetDebugLogLengthMESA and GetDebugLogMESA:
|
||||
|
||||
DEBUG_PRINT_MESA 0x875A
|
||||
DEBUG_ASSERT_MESA 0x875B
|
||||
|
||||
Additions to Chapter 2 of the OpenGL 1.5 Specification
|
||||
(OpenGL Operation)
|
||||
|
||||
None
|
||||
|
||||
Additions to Chapter 3 of the OpenGL 1.5 Specification (Rasterization)
|
||||
|
||||
None
|
||||
|
||||
Additions to Chapter 4 of the OpenGL 1.5 Specification (Per-Fragment
|
||||
Operations and the Frame Buffer)
|
||||
|
||||
None
|
||||
|
||||
Additions to Chapter 5 of the OpenGL 1.5 Specification
|
||||
(Special Functions)
|
||||
|
||||
None
|
||||
|
||||
Additions to Chapter 6 of the OpenGL 1.5 Specification (State and State
|
||||
Requests)
|
||||
|
||||
None
|
||||
|
||||
Additions to Appendix A of the OpenGL 1.5 Specification (Invariance)
|
||||
|
||||
None
|
||||
|
||||
Additions to Chapter 1 of the OpenGL Shading Language 1.10 Specification
|
||||
(Introduction)
|
||||
|
||||
None
|
||||
|
||||
Additions to Chapter 2 of the OpenGL Shading Language 1.10 Specification
|
||||
(Overview of OpenGL Shading)
|
||||
|
||||
None
|
||||
|
||||
Additions to Chapter 3 of the OpenGL Shading Language 1.10 Specification
|
||||
(Basics)
|
||||
|
||||
None
|
||||
|
||||
Additions to Chapter 4 of the OpenGL Shading Language 1.10 Specification
|
||||
(Variables and Types)
|
||||
|
||||
None
|
||||
|
||||
Additions to Chapter 5 of the OpenGL Shading Language 1.10 Specification
|
||||
(Operators and Expressions)
|
||||
|
||||
None
|
||||
|
||||
Additions to Chapter 6 of the OpenGL Shading Language 1.10 Specification
|
||||
(Statements and Structure)
|
||||
|
||||
None
|
||||
|
||||
Additions to Chapter 7 of the OpenGL Shading Language 1.10 Specification
|
||||
(Built-in Variables)
|
||||
|
||||
None
|
||||
|
||||
Additions to Chapter 8 of the OpenGL Shading Language 1.10 Specification
|
||||
(Built-in Functions)
|
||||
|
||||
Add a new section 8.10 "Debug Functions":
|
||||
|
||||
Debug functions are available to both fragment and vertex shaders.
|
||||
They are used to track the execution of a shader by logging
|
||||
passed-in arguments to the debug object's log. Those values can be
|
||||
retrieved by the application for inspection after shader execution
|
||||
is complete.
|
||||
|
||||
The text, if any, produced by any of these functions is appended
|
||||
to each debug object that is attached to the program object.
|
||||
There are different debug log types
|
||||
|
||||
Add a new section 8.10.1 "Print Function":
|
||||
|
||||
The following printMESA prototypes are available.
|
||||
|
||||
void printMESA(const float value)
|
||||
void printMESA(const int value)
|
||||
void printMESA(const bool value)
|
||||
void printMESA(const vec2 value)
|
||||
void printMESA(const vec3 value)
|
||||
void printMESA(const vec4 value)
|
||||
void printMESA(const ivec2 value)
|
||||
void printMESA(const ivec3 value)
|
||||
void printMESA(const ivec4 value)
|
||||
void printMESA(const bvec2 value)
|
||||
void printMESA(const bvec3 value)
|
||||
void printMESA(const bvec4 value)
|
||||
void printMESA(const mat2 value)
|
||||
void printMESA(const mat3 value)
|
||||
void printMESA(const mat4 value)
|
||||
void printMESA(const sampler1D value)
|
||||
void printMESA(const sampler2D value)
|
||||
void printMESA(const sampler3D value)
|
||||
void printMESA(const samplerCube value)
|
||||
void printMESA(const sampler1DShadow value)
|
||||
void printMESA(const sampler2DShadow value)
|
||||
|
||||
The printMESA function writes the argument <value> to the "debug
|
||||
print log" (XXX DEBUG_PRINT_MESA?). Each component is written in
|
||||
text format (XXX format!) and is delimited by a white space (XXX 1
|
||||
or more?).
|
||||
|
||||
Add a new section 8.10.2 "Assert Function":
|
||||
|
||||
The following assertMESA prototypes are available.
|
||||
|
||||
void assertMESA(const bool condition)
|
||||
void assertMESA(const bool condition, const int cookie)
|
||||
void assertMESA(const bool condition, const int cookie,
|
||||
const int file, const int line)
|
||||
|
||||
The assertMESA function checks if the argument <condition> is
|
||||
true or false. If it is true, nothing happens. If it is false,
|
||||
a diagnostic message is written to the "debug assert log".
|
||||
The message contains the argument <file>, <line>, <cookie> and
|
||||
implementation dependent double-quoted string, each of this
|
||||
delimited by a white space. If the argument <cookie> is not present,
|
||||
it is meant as if it was of value 0. If the arguments <file> and
|
||||
<line> are not present, they are meant as if they were of values
|
||||
__FILE__ and __LINE__, respectively. The following three calls
|
||||
produce the same output, assuming they were issued from the same
|
||||
file and line.
|
||||
|
||||
assertMESA (false);
|
||||
assertMESA (false, 0);
|
||||
assertMESA (false, 0, __FILE__, __LINE__);
|
||||
|
||||
The diagnostic message examples follow.
|
||||
|
||||
1 89 0 ""
|
||||
1 45 333 "all (lessThanEqual (fragColor, vec4 (1.0)))"
|
||||
1 66 1 "assertion failed in file 1, line 66, cookie 1"
|
||||
|
||||
Additions to Chapter 9 of the OpenGL Shading Language 1.10 Specification
|
||||
(Shading Language Grammar)
|
||||
|
||||
None
|
||||
|
||||
Additions to Chapter 10 of the OpenGL Shading Language 1.10
|
||||
Specification (Issues)
|
||||
|
||||
None
|
||||
|
||||
Additions to the AGL/EGL/GLX/WGL Specifications
|
||||
|
||||
None
|
||||
|
||||
GLX Protocol
|
||||
|
||||
None
|
||||
|
||||
Errors
|
||||
|
||||
TBD
|
||||
|
||||
New State
|
||||
|
||||
TBD
|
||||
|
||||
New Implementation Dependent State
|
||||
|
||||
TBD
|
||||
|
||||
Sample Code
|
||||
|
||||
TBD
|
||||
|
||||
Revision History
|
||||
|
||||
29 May 2006
|
||||
Initial draft. (Michal Krol)
|
||||
30 July 2006
|
||||
Add Overview, New Procedures and Functions, New Tokens sections.
|
||||
Add sections 8.10.1, 8.10.2 to GLSL spec.
|
||||
@@ -0,0 +1,129 @@
|
||||
Name
|
||||
|
||||
MESA_swap_control
|
||||
|
||||
Name Strings
|
||||
|
||||
GLX_MESA_swap_control
|
||||
|
||||
Contact
|
||||
|
||||
Ian Romanick, IBM, idr at us.ibm.com
|
||||
|
||||
Status
|
||||
|
||||
Deployed in DRI drivers post-XFree86 4.3.
|
||||
|
||||
Version
|
||||
|
||||
Date: 5/1/2003 Revision: 1.1
|
||||
|
||||
Number
|
||||
|
||||
???
|
||||
|
||||
Dependencies
|
||||
|
||||
None
|
||||
|
||||
Based on GLX_SGI_swap_control version 1.9 and WGL_EXT_swap_control
|
||||
version 1.5.
|
||||
|
||||
Overview
|
||||
|
||||
This extension allows an application to specify a minimum periodicity
|
||||
of color buffer swaps, measured in video frame periods.
|
||||
|
||||
Issues
|
||||
|
||||
* Should implementations that export GLX_MESA_swap_control also export
|
||||
GL_EXT_swap_control for compatibility with WGL_EXT_swap_control?
|
||||
|
||||
UNRESOLVED.
|
||||
|
||||
New Procedures and Functions
|
||||
|
||||
int glXSwapIntervalMESA(unsigned int interval)
|
||||
int glXGetSwapIntervalMESA(void)
|
||||
|
||||
New Tokens
|
||||
|
||||
None
|
||||
|
||||
Additions to Chapter 2 of the 1.4 GL Specification (OpenGL Operation)
|
||||
|
||||
None
|
||||
|
||||
Additions to Chapter 3 of the 1.4 GL Specification (Rasterization)
|
||||
|
||||
None
|
||||
|
||||
Additions to Chapter 4 of the 1.4 GL Specification (Per-Fragment Operations
|
||||
and the Framebuffer)
|
||||
|
||||
None
|
||||
|
||||
Additions to Chapter 5 of the 1.4 GL Specification (Special Functions)
|
||||
|
||||
None
|
||||
|
||||
Additions to Chapter 6 of the 1.4 GL Specification (State and State Requests)
|
||||
|
||||
None
|
||||
|
||||
Additions to the GLX 1.3 Specification
|
||||
|
||||
[Add the following to Section 3.3.10 of the GLX Specification (Double
|
||||
Buffering)]
|
||||
|
||||
glXSwapIntervalMESA specifies the minimum number of video frame periods
|
||||
per buffer swap. (e.g. a value of two means that the color buffers
|
||||
will be swapped at most every other video frame.) A return value
|
||||
of zero indicates success; otherwise an error occurred. The interval
|
||||
takes effect when glXSwapBuffers is first called subsequent to the
|
||||
glXSwapIntervalMESA call.
|
||||
|
||||
A video frame period is the time required by the monitor to display a
|
||||
full frame of video data. In the case of an interlaced monitor,
|
||||
this is typically the time required to display both the even and odd
|
||||
fields of a frame of video data.
|
||||
|
||||
If <interval> is set to a value of 0, buffer swaps are not synchro-
|
||||
nized to a video frame. The <interval> value is silently clamped to
|
||||
the maximum implementation-dependent value supported before being
|
||||
stored.
|
||||
|
||||
The swap interval is not part of the render context state. It cannot
|
||||
be pushed or popped. The current swap interval for the window
|
||||
associated with the current context can be obtained by calling
|
||||
glXGetSwapIntervalMESA. The default swap interval is 0.
|
||||
|
||||
On XFree86, setting the environment variable LIBGL_THROTTLE_REFRESH sets
|
||||
the swap interval to 1.
|
||||
|
||||
Errors
|
||||
|
||||
glXSwapIntervalMESA returns GLX_BAD_CONTEXT if there is no current
|
||||
GLXContext or if the current context is not a direct rendering context.
|
||||
|
||||
GLX Protocol
|
||||
|
||||
None. This extension only extends to direct rendering contexts.
|
||||
|
||||
New State
|
||||
|
||||
Get Value Get Command Type Initial Value
|
||||
--------- ----------- ---- -------------
|
||||
[swap interval] GetSwapInterval Z+ 0
|
||||
|
||||
New Implementation Dependent State
|
||||
|
||||
None
|
||||
|
||||
|
||||
Revision History
|
||||
|
||||
1.1, 5/1/03 Added the issues section and contact information.
|
||||
Changed the default swap interval to 0.
|
||||
1.0, 3/17/03 Initial version based on GLX_SGI_swap_control and
|
||||
WGL_EXT_swap_control.
|
||||
@@ -0,0 +1,201 @@
|
||||
Name
|
||||
|
||||
MESA_swap_frame_usage
|
||||
|
||||
Name Strings
|
||||
|
||||
GLX_MESA_swap_frame_usage
|
||||
|
||||
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
|
||||
|
||||
GLX_SGI_swap_control affects the definition of this extension.
|
||||
GLX_MESA_swap_control affects the definition of this extension.
|
||||
GLX_OML_sync_control affects the definition of this extension.
|
||||
|
||||
Based on WGL_I3D_swap_frame_usage version 1.3.
|
||||
|
||||
Overview
|
||||
|
||||
This extension allows an application to determine what portion of the
|
||||
swap period has elapsed since the last swap operation completed. The
|
||||
"usage" value is a floating point value on the range [0,max] which is
|
||||
calculated as follows:
|
||||
|
||||
td
|
||||
percent = ----
|
||||
tf
|
||||
|
||||
where td is the time measured from the last completed buffer swap (or
|
||||
call to enable the statistic) to when the next buffer swap completes, tf
|
||||
is the entire time for a frame which may be multiple screen refreshes
|
||||
depending on the swap interval as set by the GLX_SGI_swap_control or
|
||||
GLX_OML_sync_control extensions.
|
||||
|
||||
The value, percent, indicates the amount of time spent between the
|
||||
completion of the two swaps. If the value is in the range [0,1], the
|
||||
buffer swap occurred within the time period required to maintain a
|
||||
constant frame rate. If the value is in the range (1,max], a constant
|
||||
frame rate was not achieved. The value indicates the number of frames
|
||||
required to draw.
|
||||
|
||||
This definition of "percent" differs slightly from
|
||||
WGL_I3D_swap_frame_usage. In WGL_I3D_swap_frame_usage, the measurement
|
||||
is taken from the completion of one swap to the issuance of the next.
|
||||
This representation may not be as useful as measuring between
|
||||
completions, as a significant amount of time may pass between the
|
||||
issuance of a swap and the swap actually occurring.
|
||||
|
||||
There is also a mechanism to determine whether a frame swap was
|
||||
missed.
|
||||
|
||||
New Procedures and Functions
|
||||
|
||||
int glXGetFrameUsageMESA(Display *dpy,
|
||||
GLXDrawable drawable,
|
||||
float *usage)
|
||||
|
||||
int glXBeginFrameTrackingMESA(Display *dpy,
|
||||
GLXDrawable drawable)
|
||||
|
||||
int glXEndFrameTrackingMESA(Display *dpy,
|
||||
GLXDrawable drawable)
|
||||
|
||||
int glXQueryFrameTrackingMESA(Display *dpy,
|
||||
GLXDrawable drawable,
|
||||
int64_t *swapCount,
|
||||
int64_t *missedFrames,
|
||||
float *lastMissedUsage)
|
||||
|
||||
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
|
||||
|
||||
The frame usage is measured as the percentage of the swap period elapsed
|
||||
between two buffer-swap operations being committed. In unextended GLX the
|
||||
swap period is the vertical refresh time. If SGI_swap_control or
|
||||
MESA_swap_control are supported, the swap period is the vertical refresh
|
||||
time multiplied by the swap interval (or one if the swap interval is set
|
||||
to zero).
|
||||
|
||||
If OML_sync_control is supported, the swap period is the vertical
|
||||
refresh time multiplied by the divisor parameter to
|
||||
glXSwapBuffersMscOML. The frame usage in this case is less than 1.0 if
|
||||
the swap is committed before target_msc, and is greater than or equal to
|
||||
1.0 otherwise. The actual usage value is based on the divisor and is
|
||||
never less than 0.0.
|
||||
|
||||
int glXBeginFrameTrackingMESA(Display *dpy,
|
||||
GLXDrawable drawable,
|
||||
float *usage)
|
||||
|
||||
glXGetFrameUsageMESA returns a floating-point value in <usage>
|
||||
that represents the current swap usage, as defined above.
|
||||
|
||||
Missed frame swaps can be tracked by calling the following function:
|
||||
|
||||
int glXBeginFrameTrackingMESA(Display *dpy,
|
||||
GLXDrawable drawable)
|
||||
|
||||
glXBeginFrameTrackingMESA resets a "missed frame" count and
|
||||
synchronizes with the next frame vertical sync before it returns.
|
||||
If a swap is missed based in the rate control specified by the
|
||||
<interval> set by glXSwapIntervalSGI or the default swap of once
|
||||
per frame, the missed frame count is incremented.
|
||||
|
||||
The current missed frame count and total number of swaps since
|
||||
the last call to glXBeginFrameTrackingMESA can be obtained by
|
||||
calling the following function:
|
||||
|
||||
int glXQueryFrameTrackingMESA(Display *dpy,
|
||||
GLXDrawable drawable,
|
||||
int64_t *swapCount,
|
||||
int64_t *missedFrames,
|
||||
float *lastMissedUsage)
|
||||
|
||||
The location pointed to by <swapCount> will be updated with the
|
||||
number of swaps that have been committed. This value may not match the
|
||||
number of swaps that have been requested since swaps may be
|
||||
queued by the implementation. This function can be called at any
|
||||
time and does not synchronize to vertical blank.
|
||||
|
||||
The location pointed to by <missedFrames> will contain the number
|
||||
swaps that missed the specified frame. The frame usage for the
|
||||
last missed frame is returned in the location pointed to by
|
||||
<lastMissedUsage>.
|
||||
|
||||
Frame tracking is disabled by calling the function
|
||||
|
||||
int glXEndFrameTrackingMESA(Display *dpy,
|
||||
GLXDrawable drawable)
|
||||
|
||||
This function will not return until all swaps have occurred. The
|
||||
application can call glXQueryFrameTrackingMESA for a final swap and
|
||||
missed frame count.
|
||||
|
||||
If these functions are successful, zero is returned. If the context
|
||||
associated with dpy and drawable is not a direct context,
|
||||
GLX_BAD_CONTEXT is returned.
|
||||
|
||||
Errors
|
||||
|
||||
If the function succeeds, zero is returned. If the function
|
||||
fails, one of the following error codes is returned:
|
||||
|
||||
GLX_BAD_CONTEXT The current rendering context is not a direct
|
||||
context.
|
||||
|
||||
GLX Protocol
|
||||
|
||||
None. This extension only extends to direct rendering contexts.
|
||||
|
||||
New State
|
||||
|
||||
None
|
||||
|
||||
New Implementation Dependent State
|
||||
|
||||
None
|
||||
|
||||
Revision History
|
||||
|
||||
1.1, 5/1/03 Added contact information.
|
||||
1.0, 3/17/03 Initial version based on WGL_I3D_swap_frame_usage.
|
||||
@@ -0,0 +1,804 @@
|
||||
Name
|
||||
|
||||
MESA_texture_array
|
||||
|
||||
Name Strings
|
||||
|
||||
GL_MESA_texture_array
|
||||
|
||||
Contact
|
||||
|
||||
Ian Romanick, IBM (idr 'at' us.ibm.com)
|
||||
|
||||
IP Status
|
||||
|
||||
No known IP issues.
|
||||
|
||||
Status
|
||||
|
||||
Shipping in Mesa 7.1
|
||||
|
||||
Version
|
||||
|
||||
|
||||
Number
|
||||
|
||||
TBD
|
||||
|
||||
Dependencies
|
||||
|
||||
OpenGL 1.2 or GL_EXT_texture3D is required.
|
||||
|
||||
Support for ARB_fragment_program is assumed, but not required.
|
||||
|
||||
Support for ARB_fragment_program_shadow is assumed, but not required.
|
||||
|
||||
Support for EXT_framebuffer_object is assumed, but not required.
|
||||
|
||||
Written based on the wording of the OpenGL 2.0 specification and
|
||||
ARB_fragment_program_shadow but not dependent on them.
|
||||
|
||||
Overview
|
||||
|
||||
There are a number of circumstances where an application may wish to
|
||||
blend two textures out of a larger set of textures. Moreover, in some
|
||||
cases the selected textures may vary on a per-fragment basis within
|
||||
a polygon. Several examples include:
|
||||
|
||||
1. High dynamic range textures. The application stores several
|
||||
different "exposures" of an image as different textures. On a
|
||||
per-fragment basis, the application selects which exposures are
|
||||
used.
|
||||
|
||||
2. A terrain engine where the altitude of a point determines the
|
||||
texture applied to it. If the transition is from beach sand to
|
||||
grass to rocks to snow, the application will store each texture
|
||||
in a different texture map, and dynamically select which two
|
||||
textures to blend at run-time.
|
||||
|
||||
3. Storing short video clips in textures. Each depth slice is a
|
||||
single frame of video.
|
||||
|
||||
Several solutions to this problem have been proposed, but they either
|
||||
involve using a separate texture unit for each texture map or using 3D
|
||||
textures without mipmaps. Both of these options have major drawbacks.
|
||||
|
||||
This extension provides a third alternative that eliminates the major
|
||||
drawbacks of both previous methods. A new texture target,
|
||||
TEXTURE_2D_ARRAY, is added that functions identically to TEXTURE_3D in
|
||||
all aspects except the sizes of the non-base level images. In
|
||||
traditional 3D texturing, the size of the N+1 LOD is half the size
|
||||
of the N LOD in all three dimensions. For the TEXTURE_2D_ARRAY target,
|
||||
the height and width of the N+1 LOD is halved, but the depth is the
|
||||
same for all levels of detail. The texture then becomes an array of
|
||||
2D textures. The per-fragment texel is selected by the R texture
|
||||
coordinate.
|
||||
|
||||
References:
|
||||
|
||||
http://www.opengl.org/discussion_boards/cgi_directory/ultimatebb.cgi?ubb=get_topic;f=3;t=011557
|
||||
http://www.opengl.org/discussion_boards/cgi_directory/ultimatebb.cgi?ubb=get_topic;f=3;t=000516
|
||||
http://www.opengl.org/discussion_boards/cgi_directory/ultimatebb.cgi?ubb=get_topic;f=3;t=011903
|
||||
http://www.delphi3d.net/articles/viewarticle.php?article=terraintex.htm
|
||||
|
||||
New Procedures and Functions
|
||||
|
||||
All functions come directly from EXT_texture_array.
|
||||
|
||||
void FramebufferTextureLayerEXT(enum target, enum attachment,
|
||||
uint texture, int level, int layer);
|
||||
|
||||
New Tokens
|
||||
|
||||
All token names and values come directly from EXT_texture_array.
|
||||
|
||||
Accepted by the <cap> parameter of Enable, Disable, and IsEnabled, by
|
||||
the <pname> parameter of GetBooleanv, GetIntegerv, GetFloatv, and
|
||||
GetDoublev, and by the <target> parameter of TexImage3D, GetTexImage,
|
||||
GetTexLevelParameteriv, GetTexLevelParameterfv, GetTexParameteriv, and
|
||||
GetTexParameterfv:
|
||||
|
||||
TEXTURE_1D_ARRAY_EXT 0x8C18
|
||||
TEXTURE_2D_ARRAY_EXT 0x8C1A
|
||||
|
||||
Accepted by the <target> parameter of TexImage2D, TexSubImage2D,
|
||||
CopyTexImage2D, CopyTexSubImage2D, CompressedTexImage2D,
|
||||
CompressedTexSubImage2D, GetTexLevelParameteriv, and
|
||||
GetTexLevelParameterfv:
|
||||
|
||||
TEXTURE_1D_ARRAY_EXT
|
||||
PROXY_TEXTURE_1D_ARRAY_EXT 0x8C19
|
||||
|
||||
Accepted by the <target> parameter of TexImage3D, TexSubImage3D,
|
||||
CopyTexSubImage3D, CompressedTexImage3D, CompressedTexSubImage3D,
|
||||
GetTexLevelParameteriv, and GetTexLevelParameterfv:
|
||||
|
||||
TEXTURE_2D_ARRAY_EXT
|
||||
PROXY_TEXTURE_2D_ARRAY_EXT 0x8C1B
|
||||
|
||||
Accepted by the <pname> parameter of GetBooleanv, GetIntegerv,
|
||||
GetFloatv, and GetDoublev
|
||||
|
||||
TEXTURE_BINDING_1D_ARRAY_EXT 0x8C1C
|
||||
TEXTURE_BINDING_2D_ARRAY_EXT 0x8C1D
|
||||
MAX_ARRAY_TEXTURE_LAYERS_EXT 0x88FF
|
||||
|
||||
Accepted by the <param> parameter of TexParameterf, TexParameteri,
|
||||
TexParameterfv, and TexParameteriv when the <pname> parameter is
|
||||
TEXTURE_COMPARE_MODE_ARB:
|
||||
|
||||
COMPARE_REF_DEPTH_TO_TEXTURE_EXT 0x884E
|
||||
|
||||
(Note: COMPARE_REF_DEPTH_TO_TEXTURE_EXT is simply an alias for the
|
||||
existing COMPARE_R_TO_TEXTURE token in OpenGL 2.0; the alternate name
|
||||
reflects the fact that the R coordinate is not always used.)
|
||||
|
||||
Accepted by the <internalformat> parameter of TexImage3D and
|
||||
CompressedTexImage3D, and by the <format> parameter of
|
||||
CompressedTexSubImage3D:
|
||||
|
||||
COMPRESSED_RGB_S3TC_DXT1_EXT
|
||||
COMPRESSED_RGBA_S3TC_DXT1_EXT
|
||||
COMPRESSED_RGBA_S3TC_DXT3_EXT
|
||||
COMPRESSED_RGBA_S3TC_DXT5_EXT
|
||||
|
||||
Accepted by the <pname> parameter of
|
||||
GetFramebufferAttachmentParameterivEXT:
|
||||
|
||||
FRAMEBUFFER_ATTACHMENT_TEXTURE_LAYER_EXT 0x8CD4
|
||||
|
||||
(Note: FRAMEBUFFER_ATTACHMENT_TEXTURE_LAYER is simply an alias for the
|
||||
FRAMEBUFFER_ATTACHMENT_TEXTURE_3D_ZOFFSET_EXT token provided in
|
||||
EXT_framebuffer_object. This extension generalizes the notion of
|
||||
"<zoffset>" to include layers of an array texture.)
|
||||
|
||||
Additions to Chapter 2 of the OpenGL 2.0 Specification (OpenGL Operation)
|
||||
|
||||
None
|
||||
|
||||
Additions to Chapter 3 of the OpenGL 2.0 Specification (Rasterization)
|
||||
|
||||
-- Section 3.8.1 "Texture Image Specification"
|
||||
|
||||
Change the first paragraph (page 150) to say (spec changes identical to
|
||||
EXT_texture_array):
|
||||
|
||||
"The command
|
||||
|
||||
void TexImage3D(enum target, int level, int internalformat,
|
||||
sizei width, sizei height, sizei depth, int border,
|
||||
enum format, enum type, void *data);
|
||||
|
||||
is used to specify a three-dimensional texture image. target must be one
|
||||
one of TEXTURE_3D for a three-dimensional texture or
|
||||
TEXTURE_2D_ARRAY_EXT for an two-dimensional array texture.
|
||||
Additionally, target may be either PROXY_TEXTURE_3D for a
|
||||
three-dimensional proxy texture, or PROXY_TEXTURE_2D_ARRAY_EXT for a
|
||||
two-dimensional proxy array texture."
|
||||
|
||||
Change the fourth paragraph on page 151 to say (spec changes identical
|
||||
to EXT_texture_array):
|
||||
|
||||
"Textures with a base internal format of DEPTH_COMPONENT are supported
|
||||
by texture image specification commands only if target is TEXTURE_1D,
|
||||
TEXTURE_2D, TEXTURE_1D_ARRAY_EXT, TEXTURE_2D_ARRAY_EXT,
|
||||
PROXY_TEXTURE_1D, PROXY_TEXTURE_2D, PROXY_TEXTURE_1D_ARRAY_EXT, or
|
||||
PROXY_TEXTURE_2D_ARRAY_EXT. Using this format in conjunction with any
|
||||
other target will result in an INVALID_OPERATION error."
|
||||
|
||||
|
||||
Change the fourth paragraph on page 156 to say (spec changes identical
|
||||
to EXT_texture_array):
|
||||
|
||||
"The command
|
||||
|
||||
void TexImage2D(enum target, int level,
|
||||
int internalformat, sizei width, sizei height,
|
||||
int border, enum format, enum type, void *data);
|
||||
|
||||
is used to specify a two-dimensional texture image. target must be one
|
||||
of TEXTURE_2D for a two-dimensional texture, TEXTURE_1D_ARRAY_EXT for a
|
||||
one-dimensional array texture, or one of TEXTURE_CUBE_MAP_POSITIVE_X,
|
||||
TEXTURE_CUBE_MAP_NEGATIVE_X, TEXTURE_CUBE_MAP_POSITIVE_Y,
|
||||
TEXTURE_CUBE_MAP_NEGATIVE_Y, TEXTURE_CUBE_MAP_POSITIVE_Z, or
|
||||
TEXTURE_CUBE_MAP_NEGATIVE_Z for a cube map texture. Additionally,
|
||||
target may be either PROXY_TEXTURE_2D for a two-dimensional proxy
|
||||
texture, PROXY_TEXTURE_1D_ARRAY_EXT for a one-dimensional proxy array
|
||||
texture, or PROXY TEXTURE_CUBE_MAP for a cube map proxy texture in the
|
||||
special case discussed in section 3.8.11. The other parameters match
|
||||
the corresponding parameters of TexImage3D.
|
||||
|
||||
For the purposes of decoding the texture image, TexImage2D is
|
||||
equivalent to calling TexImage3D with corresponding arguments and depth
|
||||
of 1, except that
|
||||
|
||||
* The border depth, d_b, is zero, and the depth of the image is
|
||||
always 1 regardless of the value of border.
|
||||
|
||||
* The border height, h_b, is zero if <target> is
|
||||
TEXTURE_1D_ARRAY_EXT, and <border> otherwise.
|
||||
|
||||
* Convolution will be performed on the image (possibly changing its
|
||||
width and height) if SEPARABLE 2D or CONVOLUTION 2D is enabled.
|
||||
|
||||
* UNPACK SKIP IMAGES is ignored."
|
||||
|
||||
-- Section 3.8.2 "Alternate Texture Image Specification Commands"
|
||||
|
||||
Change the second paragraph (page 159) (spec changes identical
|
||||
to EXT_texture_array):
|
||||
|
||||
"The command
|
||||
|
||||
void CopyTexImage2D(enum target, int level,
|
||||
enum internalformat, int x, int y, sizei width,
|
||||
sizei height, int border);
|
||||
|
||||
defines a two-dimensional texture image in exactly the manner of
|
||||
TexImage2D, except that the image data are taken from the framebuffer
|
||||
rather than from client memory. Currently, target must be one of
|
||||
TEXTURE_2D, TEXTURE_1D_ARRAY_EXT, TEXTURE_CUBE_MAP_POSITIVE_X,
|
||||
TEXTURE_CUBE_MAP_NEGATIVE_X, TEXTURE_CUBE MAP_POSITIVE_Y,
|
||||
TEXTURE_CUBE_MAP_NEGATIVE_Y, TEXTURE_CUBE_MAP_POSITIVE_Z, or
|
||||
TEXTURE_CUBE_MAP_NEGATIVE_Z.
|
||||
|
||||
|
||||
Change the last paragraph on page 160 to say (spec changes identical
|
||||
to EXT_texture_array):
|
||||
|
||||
"Currently the target arguments of TexSubImage1D and CopyTexSubImage1D
|
||||
must be TEXTURE_1D, the target arguments of TexSubImage2D and
|
||||
CopyTexSubImage2D must be one of TEXTURE_2D, TEXTURE_1D_ARRAY_EXT,
|
||||
TEXTURE_CUBE_MAP_POSITIVE_X, TEXTURE_CUBE_MAP_NEGATIVE_X,
|
||||
TEXTURE_CUBE_MAP_POSITIVE_Y, TEXTURE_CUBE_MAP_NEGATIVE_Y,
|
||||
TEXTURE_CUBE_MAP_POSITIVE_Z, or TEXTURE_CUBE_MAP_NEGATIVE_Z, and the
|
||||
target arguments of TexSubImage3D and CopyTexSubImage3D must be
|
||||
TEXTURE_3D or TEXTURE_2D_ARRAY_EXT. ..."
|
||||
|
||||
|
||||
-- Section 3.8.4 "Texture Parameters"
|
||||
|
||||
Change the first paragraph (page 166) to say:
|
||||
|
||||
"Various parameters control how the texel array is treated when
|
||||
specified or changed, and when applied to a fragment. Each parameter is
|
||||
set by calling
|
||||
|
||||
void TexParameter{if}(enum target, enum pname, T param);
|
||||
void TexParameter{if}v(enum target, enum pname, T params);
|
||||
|
||||
target is the target, either TEXTURE_1D, TEXTURE_2D, TEXTURE_3D,
|
||||
TEXTURE_CUBE_MAP, TEXTURE_1D_ARRAY_EXT, or TEXTURE_2D_ARRAY_EXT."
|
||||
|
||||
|
||||
-- Section 3.8.8 "Texture Minification" in the section "Scale Factor and Level of Detail"
|
||||
|
||||
Change the first paragraph (page 172) to say:
|
||||
|
||||
"Let s(x,y) be the function that associates an s texture coordinate
|
||||
with each set of window coordinates (x,y) that lie within a primitive;
|
||||
define t(x,y) and r(x,y) analogously. Let u(x,y) = w_t * s(x,y),
|
||||
v(x,y) = h_t * t(x,y), and w(x,y) = d_t * r(x,y), where w_t, h_t,
|
||||
and d_t are as defined by equations 3.15, 3.16, and 3.17 with
|
||||
w_s, h_s, and d_s equal to the width, height, and depth of the
|
||||
image array whose level is level_base. For a one-dimensional
|
||||
texture or a one-dimensional array texture, define v(x,y) = 0 and
|
||||
w(x,y) = 0; for a two-dimensional texture or a two-dimensional array
|
||||
texture, define w(x,y) = 0..."
|
||||
|
||||
-- Section 3.8.8 "Texture Minification" in the section "Mipmapping"
|
||||
|
||||
Change the third paragraph (page 174) to say:
|
||||
|
||||
"For a two-dimensional texture, two-dimensional array texture, or
|
||||
cube map texture,"
|
||||
|
||||
Change the fourth paragraph (page 174) to say:
|
||||
|
||||
"And for a one-dimensional texture or a one-dimensional array texture,"
|
||||
|
||||
After the first paragraph (page 175) add:
|
||||
|
||||
"For one-dimensional array textures, h_b and d_b are treated as 1,
|
||||
regardless of the actual values, when performing mipmap calculations.
|
||||
For two-dimensional array textures, d_b is always treated as one,
|
||||
regardless of the actual value, when performing mipmap calculations."
|
||||
|
||||
-- Section 3.8.8 "Automatic Mipmap Generation" in the section "Mipmapping"
|
||||
|
||||
Change the third paragraph (page 176) to say (spec changes identical
|
||||
to EXT_texture_array):
|
||||
|
||||
"The contents of the derived arrays are computed by repeated, filtered
|
||||
reduction of the level_base array. For one- and two-dimensional array
|
||||
textures, each layer is filtered independently. ..."
|
||||
|
||||
-- Section 3.8.8 "Manual Mipmap Generation" in the section "Mipmapping"
|
||||
|
||||
Change first paragraph to say (spec changes identical to
|
||||
EXT_texture_array):
|
||||
|
||||
"Mipmaps can be generated manually with the command
|
||||
|
||||
void GenerateMipmapEXT(enum target);
|
||||
|
||||
where <target> is one of TEXTURE_1D, TEXTURE_2D, TEXTURE_CUBE_MAP,
|
||||
TEXTURE_3D, TEXTURE_1D_ARRAY, or TEXTURE_2D_ARRAY. Mipmap generation
|
||||
affects the texture image attached to <target>. ..."
|
||||
|
||||
-- Section 3.8.10 "Texture Completeness"
|
||||
|
||||
Change the second paragraph (page 177) to say (spec changes identical
|
||||
to EXT_texture_array):
|
||||
|
||||
"For one-, two-, or three-dimensional textures and one- or
|
||||
two-dimensional array textures, a texture is complete if the following
|
||||
conditions all hold true:"
|
||||
|
||||
-- Section 3.8.11 "Texture State and Proxy State"
|
||||
|
||||
Change the second and third paragraphs (page 179) to say (spec changes
|
||||
identical to EXT_texture_array):
|
||||
|
||||
"In addition to image arrays for one-, two-, and three-dimensional
|
||||
textures, one- and two-dimensional array textures, and the six image
|
||||
arrays for the cube map texture, partially instantiated image arrays
|
||||
are maintained for one-, two-, and three-dimensional textures and one-
|
||||
and two-dimensional array textures. Additionally, a single proxy image
|
||||
array is maintained for the cube map texture. Each proxy image array
|
||||
includes width, height, depth, border width, and internal format state
|
||||
values, as well as state for the red, green, blue, alpha, luminance,
|
||||
and intensity component resolutions. Proxy image arrays do not include
|
||||
image data, nor do they include texture properties. When TexImage3D is
|
||||
executed with target specified as PROXY_TEXTURE_3D, the
|
||||
three-dimensional proxy state values of the specified level-of-detail
|
||||
are recomputed and updated. If the image array would not be supported
|
||||
by TexImage3D called with target set to TEXTURE 3D, no error is
|
||||
generated, but the proxy width, height, depth, border width, and
|
||||
component resolutions are set to zero. If the image array would be
|
||||
supported by such a call to TexImage3D, the proxy state values are set
|
||||
exactly as though the actual image array were being specified. No pixel
|
||||
data are transferred or processed in either case.
|
||||
|
||||
Proxy arrays for one- and two-dimensional textures and one- and
|
||||
two-dimensional array textures are operated on in the same way when
|
||||
TexImage1D is executed with target specified as PROXY_TEXTURE_1D,
|
||||
TexImage2D is executed with target specified as PROXY_TEXTURE_2D or
|
||||
PROXY_TEXTURE_1D_ARRAY_EXT, or TexImage3D is executed with target
|
||||
specified as PROXY_TETXURE_2D_ARRAY_EXT."
|
||||
|
||||
-- Section 3.8.12 "Texture Objects"
|
||||
|
||||
Change section (page 180) to say (spec changes identical to
|
||||
EXT_texture_array):
|
||||
|
||||
"In addition to the default textures TEXTURE_1D, TEXTURE_2D,
|
||||
TEXTURE_3D, TEXTURE_CUBE_MAP, TEXTURE_1D_ARRAY_EXT, and TEXTURE_2D_EXT,
|
||||
named one-, two-, and three-dimensional, cube map, and one- and
|
||||
two-dimensional array texture objects can be created and operated upon.
|
||||
The name space for texture objects is the unsigned integers, with zero
|
||||
reserved by the GL.
|
||||
|
||||
A texture object is created by binding an unused name to TEXTURE_1D,
|
||||
TEXTURE_2D, TEXTURE_3D, TEXTURE_CUBE_MAP, TEXTURE_1D_ARRAY_EXT, or
|
||||
TEXTURE_2D_ARRAY_EXT. The binding is effected by calling
|
||||
|
||||
void BindTexture(enum target, uint texture);
|
||||
|
||||
with <target> set to the desired texture target and <texture> set to
|
||||
the unused name. The resulting texture object is a new state vector,
|
||||
comprising all the state values listed in section 3.8.11, set to the
|
||||
same initial values. If the new texture object is bound to TEXTURE_1D,
|
||||
TEXTURE_2D, TEXTURE_3D, TEXTURE_CUBE_MAP, TEXTURE_1D_ARRAY_EXT, or
|
||||
TEXTURE_2D_ARRAY_EXT, it is and remains a one-, two-,
|
||||
three-dimensional, cube map, one- or two-dimensional array texture
|
||||
respectively until it is deleted.
|
||||
|
||||
BindTexture may also be used to bind an existing texture object to
|
||||
either TEXTURE_1D, TEXTURE_2D, TEXTURE_3D, TEXTURE_CUBE_MAP,
|
||||
TEXTURE_1D_ARRAY_EXT, or TEXTURE_2D_ARRAY_EXT. The error
|
||||
INVALID_OPERATION is generated if an attempt is made to bind a texture
|
||||
object of different dimensionality than the specified target. If the
|
||||
bind is successful no change is made to the state of the bound texture
|
||||
object, and any previous binding to target is broken.
|
||||
|
||||
While a texture object is bound, GL operations on the target to which
|
||||
it is bound affect the bound object, and queries of the target to which
|
||||
it is bound return state from the bound object. If texture mapping of
|
||||
the dimensionality of the target to which a texture object is bound is
|
||||
enabled, the state of the bound texture object directs the texturing
|
||||
operation.
|
||||
|
||||
In the initial state, TEXTURE_1D, TEXTURE_2D, TEXTURE_3D,
|
||||
TEXTURE_CUBE_MAP, TEXTURE_1D_ARRAY_EXT, and TEXTURE_2D_ARRAY_EXT have
|
||||
one-, two-, three-dimensional, cube map, and one- and two-dimensional
|
||||
array texture state vectors respectively associated with them. In order
|
||||
that access to these initial textures not be lost, they are treated as
|
||||
texture objects all of whose names are 0. The initial one-, two-,
|
||||
three-dimensional, cube map, one- and two-dimensional array textures
|
||||
are therefore operated upon, queried, and applied as TEXTURE_1D,
|
||||
TEXTURE_2D, TEXTURE_3D, TEXTURE_CUBE_MAP, TEXTURE_1D_ARRAY_EXT, and
|
||||
TEXTURE_2D_ARRAY_EXT respectively while 0 is bound to the corresponding
|
||||
targets.
|
||||
|
||||
Change second paragraph on page 181 to say (spec changes identical to
|
||||
EXT_texture_array):
|
||||
|
||||
"... If a texture that is currently bound to one of the targets
|
||||
TEXTURE_1D, TEXTURE_2D, TEXTURE_3D, TEXTURE_CUBE_MAP,
|
||||
TEXTURE_1D_ARRAY_EXT, or TEXTURE_2D_ARRAY_EXT is deleted, it is as
|
||||
though BindTexture had been executed with the same target and texture
|
||||
zero. ..."
|
||||
|
||||
Change second paragraph on page 182 to say (spec changes identical to
|
||||
EXT_texture_array):
|
||||
|
||||
"The texture object name space, including the initial one-, two-, and
|
||||
three dimensional, cube map, and one- and two-dimensional array texture
|
||||
objects, is shared among all texture units. ..."
|
||||
|
||||
|
||||
-- Section 3.8.14 "Depth Texture Comparison Modes" in "Texture Comparison Modes"
|
||||
|
||||
Change second through fourth paragraphs (page 188) to say:
|
||||
|
||||
"Let D_t be the depth texture value, in the range [0, 1]. For
|
||||
texture lookups from one- and two-dimensional, rectangle, and
|
||||
one-dimensional array targets, let R be the interpolated <r>
|
||||
texture coordinate, clamped to the range [0, 1]. For texture lookups
|
||||
from two-dimensional array texture targets, let R be the interpolated
|
||||
<q> texture coordinate, clamped to the range [0, 1]. Then the
|
||||
effective texture value L_t, I_t, or A_t is computed as follows:
|
||||
|
||||
If the value of TEXTURE_COMPARE_MODE is NONE, then
|
||||
|
||||
r = Dt
|
||||
|
||||
If the value of TEXTURE_COMPARE_MODE is
|
||||
COMPARE_REF_DEPTH_TO_TEXTURE_EXT), then r depends on the texture
|
||||
comparison function as shown in table 3.27."
|
||||
|
||||
-- Section 3.8.15 "Texture Application"
|
||||
|
||||
Change the first paragraph (page 189) to say:
|
||||
|
||||
"Texturing is enabled or disabled using the generic Enable and Disable
|
||||
commands, respectively, with the symbolic constants TEXTURE_1D,
|
||||
TEXTURE_2D, TEXTURE_3D, TEXTURE_CUBE_MAP, TEXTURE_1D_ARRAY_EXT, or
|
||||
TEXTURE_2D_ARRAY_EXT to enable one-, two-, three-dimensional, cube
|
||||
map, one-dimensional array, or two-dimensional array texture,
|
||||
respectively. If both two- and one-dimensional textures are enabled,
|
||||
the two-dimensional texture is used. If the three-dimensional and
|
||||
either of the two- or one-dimensional textures is enabled, the
|
||||
three-dimensional texture is used. If the cube map texture and any of
|
||||
the three-, two-, or one-dimensional textures is enabled, then cube map
|
||||
texturing is used. If one-dimensional array texture is enabled and any
|
||||
of cube map, three-, two-, or one-dimensional textures is enabled,
|
||||
one-dimensional array texturing is used. If two-dimensional array
|
||||
texture is enabled and any of cube map, three-, two-, one-dimensional
|
||||
textures or one-dimensional array texture is enabled, two-dimensional
|
||||
array texturing is used..."
|
||||
|
||||
-- Section 3.11.2 of ARB_fragment_program (Fragment Program Grammar and Restrictions):
|
||||
|
||||
(mostly add to existing grammar rules)
|
||||
|
||||
<optionName> ::= "MESA_texture_array"
|
||||
|
||||
<texTarget> ::= "1D"
|
||||
| "2D"
|
||||
| "3D"
|
||||
| "CUBE"
|
||||
| "RECT"
|
||||
| <arrayTarget> (if program option is present)
|
||||
| <shadowTarget> (if program option is present)
|
||||
|
||||
<arrayTarget> ::= "ARRAY1D"
|
||||
| "ARRAY2D"
|
||||
|
||||
<shadowTarget> ::= "SHADOW1D"
|
||||
| "SHADOW2D"
|
||||
| "SHADOWRECT"
|
||||
| <shadowArrayTarget> (if program option is present)
|
||||
|
||||
<shadowArrayTarget> ::= "SHADOWARRAY1D"
|
||||
| "SHADOWARRAY2D"
|
||||
|
||||
|
||||
-- Add Section 3.11.4.5.4 "Texture Stack Option"
|
||||
|
||||
"If a fragment program specifies the "MESA_texture_array" program
|
||||
option, the <texTarget> rule is modified to add the texture targets
|
||||
ARRAY1D and ARRAY2D (See Section 3.11.2)."
|
||||
|
||||
-- Section 3.11.6 "Fragment Program Texture Instruction Set"
|
||||
|
||||
(replace 1st and 2nd paragraphs with the following paragraphs)
|
||||
|
||||
"The first three texture instructions described below specify the
|
||||
mapping of 4-tuple input vectors to 4-tuple output vectors.
|
||||
The sampling of the texture works as described in section 3.8,
|
||||
except that texture environments and texture functions are not
|
||||
applicable, and the texture enables hierarchy is replaced by explicit
|
||||
references to the desired texture target (i.e., 1D, 2D, 3D, cube map,
|
||||
rectangle, ARRAY1D, ARRAY2D). These texture instructions specify
|
||||
how the 4-tuple is mapped into the coordinates used for sampling. The
|
||||
following function is used to describe the texture sampling in the
|
||||
descriptions below:
|
||||
|
||||
vec4 TextureSample(vec4 coord, float lodBias, int texImageUnit,
|
||||
enum texTarget);
|
||||
|
||||
Note that not all four components of the texture coordinates <coord>
|
||||
are used by all texture targets. Component usage for each <texTarget>
|
||||
is defined in table X.
|
||||
|
||||
coordinates used
|
||||
texTarget Texture Type s t r layer shadow
|
||||
---------------- --------------------- ----- ----- ------
|
||||
1D TEXTURE_1D x - - - -
|
||||
2D TEXTURE_2D x y - - -
|
||||
3D TEXTURE_3D x y z - -
|
||||
CUBE TEXTURE_CUBE_MAP x y z - -
|
||||
RECT TEXTURE_RECTANGLE_ARB x y - - -
|
||||
ARRAY1D TEXTURE_1D_ARRAY_EXT x - - y -
|
||||
ARRAY2D TEXTURE_2D_ARRAY_EXT x y - z -
|
||||
SHADOW1D TEXTURE_1D x - - - z
|
||||
SHADOW2D TEXTURE_2D x y - - z
|
||||
SHADOWRECT TEXTURE_RECTANGLE_ARB x y - - z
|
||||
SHADOWARRAY1D TEXTURE_1D_ARRAY_EXT x - - y z
|
||||
SHADOWARRAY2D TEXTURE_2D_ARRAY_EXT x y - z w
|
||||
|
||||
Table X: Texture types accessed for each of the <texTarget>, and
|
||||
coordinate mappings. The "coordinates used" column indicate the
|
||||
input values used for each coordinate of the texture lookup, the
|
||||
layer selector for array textures, and the reference value for
|
||||
texture comparisons."
|
||||
|
||||
-- Section 3.11.6.2 "TXP: Project coordinate and map to color"
|
||||
|
||||
Add to the end of the section:
|
||||
|
||||
"A program will fail to load if the TXP instruction is used in
|
||||
conjunction with the SHADOWARRAY2D target."
|
||||
|
||||
Additions to Chapter 4 of the OpenGL 2.0 Specification (Per-Fragment Operations)
|
||||
|
||||
-- Section 4.4.2.3 "Attaching Texture Images to a Framebuffer"
|
||||
|
||||
Add to the end of the section (spec changes identical to
|
||||
EXT_texture_array):
|
||||
|
||||
"The command
|
||||
|
||||
void FramebufferTextureLayerEXT(enum target, enum attachment,
|
||||
uint texture, int level, int layer);
|
||||
|
||||
operates identically to FramebufferTexture3DEXT, except that it
|
||||
attaches a single layer of a three-dimensional texture or a one- or
|
||||
two-dimensional array texture. <layer> is an integer indicating the
|
||||
layer number, and is treated identically to the <zoffset> parameter in
|
||||
FramebufferTexture3DEXT. The error INVALID_VALUE is generated if
|
||||
<layer> is negative. The error INVALID_OPERATION is generated if
|
||||
<texture> is non-zero and is not the name of a three dimensional
|
||||
texture or one- or two-dimensional array texture. Unlike
|
||||
FramebufferTexture3D, no <textarget> parameter is accepted.
|
||||
|
||||
If <texture> is non-zero and the command does not result in an error,
|
||||
the framebuffer attachment state corresponding to <attachment> is
|
||||
updated as in the other FramebufferTexture commands, except that
|
||||
FRAMEBUFFER_ATTACHMENT_TEXTURE_LAYER_EXT is set to <layer>."
|
||||
|
||||
-- Section 4.4.4.1 "Framebuffer Attachment Completeness"
|
||||
|
||||
Add to the end of the list of completeness rules (spec changes
|
||||
identical to EXT_texture_array):
|
||||
|
||||
"* If FRAMEBUFFER_ATTACHMENT_OBJECT_TYPE_EXT is TEXTURE and
|
||||
FRAMEBUFFER_ATTACHMENT_OBJECT_NAME_EXT names a one- or
|
||||
two-dimensional array texture, then
|
||||
FRAMEBUFFER_ATTACHMENT_TEXTURE_LAYER_EXT must be smaller than the
|
||||
number of layers in the texture."
|
||||
|
||||
Additions to Chapter 5 of the OpenGL 2.0 Specification (Special Functions)
|
||||
|
||||
-- Section 5.4 "Display Lists"
|
||||
|
||||
Change the first paragraph on page 242 to say (spec changes
|
||||
identical to EXT_texture_array):
|
||||
|
||||
"TexImage3D, TexImage2D, TexImage1D, Histogram, and ColorTable are
|
||||
executed immediately when called with the corresponding proxy arguments
|
||||
PROXY_TEXTURE_3D or PROXY_TEXTURE_2D_ARRAY_EXT; PROXY_TEXTURE_2D,
|
||||
PROXY_TEXTURE_CUBE_MAP, or PROXY_TEXTURE_1D_ARRAY_EXT;
|
||||
PROXY_TEXTURE_1D; PROXY_HISTOGRAM; and PROXY_COLOR_TABLE,
|
||||
PROXY_POST_CONVOLUTION_COLOR_TABLE, or
|
||||
PROXY_POST_COLOR_MATRIX_COLOR_TABLE."
|
||||
|
||||
Additions to Chapter 6 of the OpenGL 2.0 Specification (State and State Requests)
|
||||
|
||||
-- Section 6.1.3 "Enumerated Queries"
|
||||
|
||||
Add after the line beginning "If the value of
|
||||
FRAMEBUFFER_ATTACHMENT_OBJECT_TYPE_EXT is TEXTURE" (spec changes
|
||||
identical to EXT_texture_array):
|
||||
|
||||
"If <pname> is FRAMEBUFFER_ATTACHMENT_TEXTURE_LAYER_EXT and the
|
||||
texture object named FRAMEBUFFER_ATTACHMENT_OBJECT_NAME_EXT is a
|
||||
three-dimensional texture or a one- or two-dimensional array texture,
|
||||
then <params> will contain the number of texture layer attached to the
|
||||
attachment point. Otherwise, <params> will contain the value zero."
|
||||
|
||||
-- Section 6.1.4 "Texture Queries"
|
||||
|
||||
Change the first three paragraphs (page 248) to say (spec changes
|
||||
identical to EXT_texture_array):
|
||||
|
||||
"The command
|
||||
|
||||
void GetTexImage(enum tex, int lod, enum format,
|
||||
enum type, void *img);
|
||||
|
||||
is used to obtain texture images. It is somewhat different from the
|
||||
other get commands; tex is a symbolic value indicating which texture
|
||||
(or texture face in the case of a cube map texture target name) is to
|
||||
be obtained. TEXTURE_1D, TEXTURE_2D, TEXTURE_3D, TEXTURE_1D_ARRAY_EXT,
|
||||
and TEXTURE_2D_ARRAY_EXT indicate a one-, two-, or three-dimensional
|
||||
texture, or one- or two-dimensional array texture, respectively.
|
||||
TEXTURE_CUBE_MAP_POSITIVE_X, ...
|
||||
|
||||
GetTexImage obtains... from the first image to the last for
|
||||
three-dimensional textures. One- and two-dimensional array textures
|
||||
are treated as two- and three-dimensional images, respectively, where
|
||||
the layers are treated as rows or images. These groups are then...
|
||||
|
||||
For three-dimensional and two-dimensional array textures, pixel storage
|
||||
operations are applied as if the image were two-dimensional, except
|
||||
that the additional pixel storage state values PACK_IMAGE_HEIGHT and
|
||||
PACK_SKIP_IMAGES are applied. ..."
|
||||
|
||||
Additions to Appendix A of the OpenGL 2.0 Specification (Invariance)
|
||||
|
||||
None
|
||||
|
||||
Additions to the AGL/GLX/WGL Specifications
|
||||
|
||||
None
|
||||
|
||||
GLX Protocol
|
||||
|
||||
None
|
||||
|
||||
Dependencies on ARB_fragment_program
|
||||
|
||||
If ARB_fragment_program is not supported, the changes to section 3.11
|
||||
should be ignored.
|
||||
|
||||
Dependencies on EXT_framebuffer_object
|
||||
|
||||
If EXT_framebuffer_object is not supported, the changes to section
|
||||
3.8.8 ("Manual Mipmap Generation"), 4.4.2.3, and 6.1.3 should be ignored.
|
||||
|
||||
Dependencies on EXT_texture_compression_s3tc and NV_texture_compression_vtc
|
||||
|
||||
(Identical dependency as EXT_texture_array.)
|
||||
|
||||
S3TC texture compression is supported for two-dimensional array textures.
|
||||
When <target> is TEXTURE_2D_ARRAY_EXT, each layer is stored independently
|
||||
as a compressed two-dimensional textures. When specifying or querying
|
||||
compressed images using one of the S3TC formats, the images are provided
|
||||
and/or returned as a series of two-dimensional textures stored
|
||||
consecutively in memory, with the layer closest to zero specified first.
|
||||
For array textures, images are not arranged in 4x4x4 or 4x4x2 blocks as in
|
||||
the three-dimensional compression format provided in the
|
||||
EXT_texture_compression_vtc extension. Pixel store parameters, including
|
||||
those specific to three-dimensional images, are ignored when compressed
|
||||
image data are provided or returned, as in the
|
||||
EXT_texture_compression_s3tc extension.
|
||||
|
||||
S3TC compression is not supported for one-dimensional texture targets in
|
||||
EXT_texture_compression_s3tc, and is not supported for one-dimensional
|
||||
array textures in this extension. If compressed one-dimensional arrays
|
||||
are needed, use a two-dimensional texture with a height of one.
|
||||
|
||||
This extension allows the use of the four S3TC internal format types in
|
||||
TexImage3D, CompressedTexImage3D, and CompressedTexSubImage3D calls.
|
||||
|
||||
Errors
|
||||
|
||||
None
|
||||
|
||||
New State
|
||||
|
||||
(add to table 6.15, p. 276)
|
||||
|
||||
Initial
|
||||
Get Value Type Get Command Value Description Sec. Attribute
|
||||
---------------------------- ----- ----------- ----- -------------------- ------ ---------
|
||||
TEXTURE_BINDING_1D_ARRAY_EXT 2*xZ+ GetIntegerv 0 texture object bound 3.8.12 texture
|
||||
to TEXTURE_1D_ARRAY
|
||||
TEXTURE_BINDING_2D_ARRAY_EXT 2*xZ+ GetIntegerv 0 texture object bound 3.8.12 texture
|
||||
to TEXTURE_2D_ARRAY
|
||||
|
||||
|
||||
New Implementation Dependent State
|
||||
|
||||
(add to Table 6.32, p. 293)
|
||||
|
||||
Minimum
|
||||
Get Value Type Get Command Value Description Sec. Attribute
|
||||
---------------------------- ---- ----------- ------- ------------------ ----- ---------
|
||||
MAX_TEXTURE_ARRAY_LAYERS_EXT Z+ GetIntegerv 64 maximum number of 3.8.1 -
|
||||
layers for texture
|
||||
arrays
|
||||
|
||||
Issues
|
||||
|
||||
(1) Is "texture stack" a good name for this functionality?
|
||||
|
||||
NO. The name is changed to "array texture" to match the
|
||||
nomenclature used by GL_EXT_texture_array.
|
||||
|
||||
(2) Should the R texture coordinate be treated as normalized or
|
||||
un-normalized? If it were un-normalized, floor(R) could be thought
|
||||
of as a direct index into the array texture. This may be more
|
||||
convenient for applications.
|
||||
|
||||
RESOLVED. All texture coordinates are normalized. The issue of
|
||||
un-normalized texture coordinates has been discussed in the ARB
|
||||
before and should be left for a layered extension.
|
||||
|
||||
RE-RESOLVED. The R coordinate is un-normalized. Accessing an array
|
||||
using [0, layers-1] coordinates is much more natural.
|
||||
|
||||
(3) How does LOD selection work for stacked textures?
|
||||
|
||||
RESOLVED. For 2D array textures the R coordinate is ignored, and
|
||||
the LOD selection equations for 2D textures are used. For 1D
|
||||
array textures the T coordinate is ignored, and the LOD selection
|
||||
equations for 1D textures are used. The expected usage is in a
|
||||
fragment program with an explicit LOD selection.
|
||||
|
||||
(4) What is the maximum size of a 2D array texture? Is it the same
|
||||
as for a 3D texture, or should a new query be added? How about for 1D
|
||||
array textures?
|
||||
|
||||
RESOLVED. A new query is added.
|
||||
|
||||
(5) How are array textures exposed in GLSL?
|
||||
|
||||
RESOLVED. Use GL_EXT_texture_array.
|
||||
|
||||
(6) Should a 1D array texture also be exposed?
|
||||
|
||||
RESOLVED. For orthogonality, yes.
|
||||
|
||||
(7) How are stacked textures attached to framebuffer objects?
|
||||
|
||||
RESOLVED. Layers of both one- and two-dimensional array textures
|
||||
are attached using FreambufferTextureLayerEXT. Once attached, the
|
||||
array texture layer behaves exactly as either a one- or
|
||||
two-dimensional texture.
|
||||
|
||||
(8) How is this extension related to GL_EXT_texture_array?
|
||||
|
||||
This extension adapats GL_MESAX_texture_stack to the notation,
|
||||
indexing, and FBO access of GL_EXT_texture_array. This extension
|
||||
replaces the GLSL support of GL_EXT_texture_array with
|
||||
GL_ARB_fragment_program support.
|
||||
|
||||
Assembly program support is also provided by GL_NV_gpu_program4.
|
||||
GL_NV_gpu_program4 also adds support for other features that are
|
||||
specific to Nvidia hardware, while this extension adds only support
|
||||
for array textures.
|
||||
|
||||
Much of text of this extension that has changed since
|
||||
GL_MESAX_texture_stack comes directly from either
|
||||
GL_EXT_texture_array or GL_NV_gpu_program4.
|
||||
|
||||
Revision History
|
||||
|
||||
||2005/11/15||0.1||idr||Initial draft MESAX version.||
|
||||
||2005/12/07||0.2||idr||Added framebuffer object interactions.||
|
||||
||2005/12/12||0.3||idr||Updated fragment program interactions.||
|
||||
||2007/05/16||0.4||idr||Converted to MESA_texture_array. Brought in line with EXT_texture_array and NV_gpu_program4.||
|
||||
@@ -0,0 +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 superseded by fragment
|
||||
shaders.
|
||||
It is usually possible to get the same functionality
|
||||
using a unsigned format by doing scale and bias in a shader, but this
|
||||
is undesirable since modern hardware has direct support for this.
|
||||
This extension adds a signed 4-channel texture format by backporting
|
||||
the relevant features from OpenGL 3.1, as a means to support this in
|
||||
OpenGL implementations only supporting older versions.
|
||||
|
||||
Issues
|
||||
|
||||
1) What should this extension be called?
|
||||
|
||||
RESOLVED: MESA_texture_signed_rgba seems reasonable.
|
||||
The rgba part is there because only 4 channel format is supported.
|
||||
|
||||
|
||||
2) Should the full set of signed formats (alpha, luminance, rgb, etc.)
|
||||
be supported?
|
||||
|
||||
RESOLVED: NO. To keep this extension simple, only add the most
|
||||
universal format, rgba. alpha/luminance can't be trivially supported
|
||||
since OpenGL 3.1 does not support them any longer, and there is some
|
||||
implied dependency on ARB_texture_rg for red/red_green formats so
|
||||
avoid all this. Likewise, only 8 bits per channel is supported.
|
||||
|
||||
|
||||
3) Should this extension use new enums for the texture formats?
|
||||
|
||||
RESOLVED: NO. Same enums as those used in OpenGL 3.1.
|
||||
|
||||
|
||||
4) How are signed integer values mapped to floating-point values?
|
||||
|
||||
RESOLVED: Same as described in issue 5) of
|
||||
ARB_texture_compression_rgtc (quote):
|
||||
A signed 8-bit two's complement value X is computed to
|
||||
a floating-point value Xf with the formula:
|
||||
|
||||
{ X / 127.0, X > -128
|
||||
Xf = {
|
||||
{ -1.0, X == -128
|
||||
|
||||
This conversion means -1, 0, and +1 are all exactly representable,
|
||||
however -128 and -127 both map to -1.0. Mapping -128 to -1.0
|
||||
avoids the numerical awkwardness of have a representable value
|
||||
slightly more negative than -1.0.
|
||||
|
||||
This conversion is intentionally NOT the "byte" conversion listed
|
||||
in Table 2.9 for component conversions. That conversion says:
|
||||
|
||||
Xf = (2*X + 1) / 255.0
|
||||
|
||||
The Table 2.9 conversion is incapable of exactly representing
|
||||
zero.
|
||||
|
||||
(Difference to ARB_texture_compression_rgtc):
|
||||
This is the same mapping as OpenGL 3.1 uses.
|
||||
This is also different to what NV_texture_shader used.
|
||||
The above mapping should be considered the reference, but there
|
||||
is some leeway so other mappings are allowed for implementations which
|
||||
cannot do this. Particularly the mapping given in NV_texture_shader or
|
||||
the standard OpenGL byte/float mapping is considered acceptable too, as
|
||||
might be a mapping which represents -1.0 by -128, 0.0 by 0 and 1.0 by
|
||||
127 (that is, uses different scale factors for negative and positive
|
||||
numbers).
|
||||
Also, it is ok to store incoming GL_BYTE user data as-is, without
|
||||
converting to GL_FLOAT (using the standard OpenGL float/byte mapping)
|
||||
and converting back (using the mapping described here).
|
||||
Other than those subtle issues there are no other non-standard
|
||||
conversions used, so when using for instance CopyTexImage2D with
|
||||
a framebuffer clamped to [0,1] all converted numbers will be in the range
|
||||
[0, 127] (and not scaled and biased).
|
||||
|
||||
|
||||
5) How will signed components resulting from RGBA8_SNORM texture
|
||||
fetches interact with fragment coloring?
|
||||
|
||||
RESOLVED: Same as described in issue 6) of
|
||||
ARB_texture_compression_rgtc (quote):
|
||||
The specification language for this extension is silent
|
||||
about clamping behavior leaving this to the core specification
|
||||
and other extensions. The clamping or lack of clamping is left
|
||||
to the core specification and other extensions.
|
||||
|
||||
For assembly program extensions supporting texture fetches
|
||||
(ARB_fragment_program, NV_fragment_program, NV_vertex_program3,
|
||||
etc.) or the OpenGL Shading Language, these signed formats will
|
||||
appear as expected with unclamped signed components as a result
|
||||
of a texture fetch instruction.
|
||||
|
||||
If ARB_color_buffer_float is supported, its clamping controls
|
||||
will apply.
|
||||
|
||||
NV_texture_shader extension, if supported, adds support for
|
||||
fixed-point textures with signed components and relaxed the
|
||||
fixed-function texture environment clamping appropriately. If the
|
||||
NV_texture_shader extension is supported, its specified behavior
|
||||
for the texture environment applies where intermediate values
|
||||
are clamped to [-1,1] unless stated otherwise as in the case
|
||||
of explicitly clamped to [0,1] for GL_COMBINE. or clamping the
|
||||
linear interpolation weight to [0,1] for GL_DECAL and GL_BLEND.
|
||||
|
||||
Otherwise, the conventional core texture environment clamps
|
||||
incoming, intermediate, and output color components to [0,1].
|
||||
|
||||
This implies that the conventional texture environment
|
||||
functionality of unextended OpenGL 1.5 or OpenGL 2.0 without
|
||||
using GLSL (and with none of the extensions referred to above)
|
||||
is unable to make proper use of the signed texture formats added
|
||||
by this extension because the conventional texture environment
|
||||
requires texture source colors to be clamped to [0,1]. Texture
|
||||
filtering of these signed formats would be still signed, but
|
||||
negative values generated post-filtering would be clamped to
|
||||
zero by the core texture environment functionality. The
|
||||
expectation is clearly that this extension would be co-implemented
|
||||
with one of the previously referred to extensions or used with
|
||||
GLSL for the new signed formats to be useful.
|
||||
|
||||
|
||||
6) Should the RGBA_SNORM tokens also be accepted by CopyTexImage
|
||||
functions?
|
||||
|
||||
RESOLVED: YES.
|
||||
|
||||
|
||||
7) What to do with GetTexParameter if ARB_texture_float is supported,
|
||||
in particular what datatype should this return for TEXTURE_RED_TYPE_ARB,
|
||||
TEXTURE_GREEN_TYPE_ARB, TEXTURE_BLUE_TYPE_ARB, TEXTURE_ALPHA_TYPE_ARB?
|
||||
|
||||
RESOLVED: ARB_texture_float states type is either NONE,
|
||||
UNSIGNED_NORMALIZED_ARB, or FLOAT. This extension adds a new enum,
|
||||
SIGNED_NORMALIZED, which will be returned accordingly. This is the
|
||||
same behaviour as in OpenGL 3.1.
|
||||
|
||||
|
||||
New Tokens
|
||||
|
||||
|
||||
Accepted by the <internalformat> parameter of
|
||||
TexImage1D, TexImage2D, TexImage3D, CopyTexImage1D, and CopyTexImage2D:
|
||||
|
||||
RGBA_SNORM 0x8F93
|
||||
RGBA8_SNORM 0x8F97
|
||||
|
||||
Returned by the <params> parameter of GetTexLevelParameter:
|
||||
|
||||
SIGNED_NORMALIZED 0x8F9C
|
||||
|
||||
|
||||
Additions to Chapter 3 of the OpenGL 2.0 Specification (Rasterization):
|
||||
|
||||
-- Section 3.8.1, Texture Image Specification
|
||||
|
||||
Add to Table 3.16 (page 154): Sized internal formats
|
||||
|
||||
Sized Base R G B A L I D
|
||||
Internal Format Internal Format bits bits bits bits bits bits bits
|
||||
--------------- --------------- ---- ---- ---- ---- ---- ---- ----
|
||||
RGBA8_SNORM RGBA 8 8 8 8 0 0 0
|
||||
|
||||
|
||||
Dependencies on ARB_texture_float extension:
|
||||
|
||||
If ARB_texture_float is supported, GetTexParameter queries with <value>
|
||||
of TEXTURE_RED_TYPE_ARB, TEXTURE_GREEN_TYPE_ARB, TEXTURE_BLUE_TYPE_ARB or
|
||||
TEXTURE_ALPHA_TYPE_ARB return SIGNED_NORMALIZED if
|
||||
the base internal format is RGBA_SNORM.
|
||||
@@ -0,0 +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
|
||||
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)
|
||||
|
||||
@@ -0,0 +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 extension is written against the OpenGL 1.4 Specification.
|
||||
NV_texture_rectangle effects the definition of this extension.
|
||||
|
||||
Overview
|
||||
|
||||
This extension supports texture images stored in the YCbCr format.
|
||||
There is no support for converting YCbCr images to RGB or vice versa
|
||||
during pixel transfer. The texture's YCbCr colors are converted to
|
||||
RGB during texture sampling, after-which, all the usual per-fragment
|
||||
operations take place. Only 2D texture images are supported (not
|
||||
glDrawPixels, glReadPixels, etc).
|
||||
|
||||
A YCbCr pixel (texel) is a 16-bit unsigned short with two components.
|
||||
The first component is luminance (Y). For pixels in even-numbered
|
||||
image columns, the second component is Cb. For pixels in odd-numbered
|
||||
image columns, the second component is Cr. If one were to convert the
|
||||
data to RGB one would need to examine two pixels from columns N and N+1
|
||||
(where N is even) to deduce the RGB color.
|
||||
|
||||
IP Status
|
||||
|
||||
None
|
||||
|
||||
Issues
|
||||
|
||||
None
|
||||
|
||||
New Procedures and Functions
|
||||
|
||||
None
|
||||
|
||||
New Tokens
|
||||
|
||||
Accepted by the <internalFormat> and <format> parameters of
|
||||
TexImage2D and TexSubImage2D:
|
||||
|
||||
YCBCR_MESA 0x8757
|
||||
|
||||
Accepted by the <type> parameter of TexImage2D and TexSubImage2D:
|
||||
|
||||
UNSIGNED_SHORT_8_8_MESA 0x85BA /* same as Apple's */
|
||||
UNSIGNED_SHORT_8_8_REV_MESA 0x85BB /* same as Apple's */
|
||||
|
||||
Additions to Chapter 2 of the OpenGL 1.4 Specification (OpenGL Operation)
|
||||
|
||||
None
|
||||
|
||||
Additions to Chapter 3 of the OpenGL 1.4 Specification (Rasterization)
|
||||
|
||||
In section 3.6.4, Rasterization of Pixel Rectangles, on page 101,
|
||||
add the following to Table 3.8 (Packed pixel formats):
|
||||
|
||||
type Parameter GL Data Number of Matching
|
||||
Token Name Type Components Pixel Formats
|
||||
-------------- ------- ---------- -------------
|
||||
UNSIGNED_SHORT_8_8_MESA ushort 2 YCBCR_MESA
|
||||
UNSIGNED_SHORT_8_8_REV_MESA ushort 2 YCBCR_MESA
|
||||
|
||||
|
||||
In section 3.6.4, Rasterization of Pixel Rectangles, on page 102,
|
||||
add the following to Table 3.10 (UNSIGNED_SHORT formats):
|
||||
|
||||
UNSIGNED_SHORT_8_8_MESA:
|
||||
|
||||
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
|
||||
+-------------------------------+-------------------------------+
|
||||
| 1st | 2nd |
|
||||
+-------------------------------+-------------------------------+
|
||||
|
||||
UNSIGNED_SHORT_8_8_REV_MESA:
|
||||
|
||||
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
|
||||
+-------------------------------+-------------------------------+
|
||||
| 2nd | 1st |
|
||||
+-------------------------------+-------------------------------+
|
||||
|
||||
|
||||
In section 3.6.4, Rasterization of Pixel Rectangles, on page 104,
|
||||
add the following to Table 3.12 (Packed pixel field assignments):
|
||||
|
||||
First Second Third Fourth
|
||||
Format Element Element Element Element
|
||||
------ ------- ------- ------- -------
|
||||
YCBCR_MESA luminance chroma
|
||||
|
||||
|
||||
In section 3.8.1, Texture Image Specification, on page 125, add
|
||||
another item to the list of TexImage2D and TexImage3D equivalence
|
||||
exceptions:
|
||||
|
||||
* The value of internalformat and format may be YCBCR_MESA to
|
||||
indicate that the image data is in YCbCr format. type must
|
||||
be either UNSIGNED_SHORT_8_8_MESA or UNSIGNED_SHORT_8_8_REV_MESA
|
||||
as seen in tables 3.8 and 3.10. Table 3.12 describes the mapping
|
||||
between Y and Cb/Cr to the components.
|
||||
If NV_texture_rectangle is supported target may also be
|
||||
TEXTURE_RECTANGLE_NV or PROXY_TEXTURE_RECTANGLE_NV.
|
||||
All pixel transfer operations are bypassed. The texture is stored as
|
||||
YCbCr, not RGB. Queries of the texture's red, green and blue component
|
||||
sizes will return zero. The YCbCr colors are converted to RGB during
|
||||
texture sampling using an implementation dependent conversion.
|
||||
|
||||
|
||||
In section 3.8.1, Texture Image Specification, on page 126, add
|
||||
another item to the list of TexImage1D and TexImage2D equivalence
|
||||
exceptions:
|
||||
|
||||
* The value of internalformat and format can not be YCBCR_MESA.
|
||||
|
||||
|
||||
In section 3.8.2, Alternate Texture Image Specification Commands, on
|
||||
page 129, insert this paragraph after the first full paragraph on the
|
||||
page:
|
||||
|
||||
"If the internal storage format of the image being updated by
|
||||
TexSubImage2D is YCBCR_MESA then format must be YCBCR_MESA.
|
||||
The error INVALID_OPERATION will be generated otherwise."
|
||||
|
||||
|
||||
Additions to Chapter 4 of the OpenGL 1.4 Specification (Per-Fragment
|
||||
Operations and the Frame Buffer)
|
||||
|
||||
None
|
||||
|
||||
Additions to Chapter 5 of the OpenGL 1.4 Specification (Special Functions)
|
||||
|
||||
None
|
||||
|
||||
Additions to Chapter 6 of the OpenGL 1.4 Specification (State and
|
||||
State Requests)
|
||||
|
||||
None
|
||||
|
||||
Additions to Appendix A of the OpenGL 1.4 Specification (Invariance)
|
||||
|
||||
None
|
||||
|
||||
Additions to the AGL/GLX/WGL Specifications
|
||||
|
||||
None
|
||||
|
||||
GLX Protocol
|
||||
|
||||
None
|
||||
|
||||
Errors
|
||||
|
||||
INVALID_ENUM is generated by TexImage2D if <internalFormat> is
|
||||
MESA_YCBCR but <format> is not MESA_YCBCR.
|
||||
|
||||
INVALID_ENUM is generated by TexImage2D if <format> is MESA_YCBCR but
|
||||
<internalFormat> is not MESA_YCBCR.
|
||||
|
||||
INVALID_VALUE is generated by TexImage2D if <format> is MESA_YCBCR and
|
||||
<internalFormat> is MESA_YCBCR and <border> is not zero.
|
||||
|
||||
INVALID_OPERATION is generated by TexSubImage2D if the internal image
|
||||
format is YCBCR_MESA and <format> is not YCBCR_MESA.
|
||||
|
||||
INVALID_OPERATION is generated by CopyTexSubImage2D if the internal
|
||||
image is YCBCR_MESA.
|
||||
|
||||
New State
|
||||
|
||||
Edit table 6.16 on page 231: change the type of TEXTURE_INTERNAL_FORMAT
|
||||
from n x Z42 to n x Z43 to indicate that internal format may also be
|
||||
YCBCR_MESA.
|
||||
|
||||
Revision History
|
||||
|
||||
20 September 2002 - Initial draft
|
||||
29 April 2003 - minor updates
|
||||
3 September 2003 - further clarify when YCbCr->RGB conversion takes place
|
||||
19 September 2003 - a few more updates prior to submitting to extension
|
||||
registry.
|
||||
3 April 2004 - fix assorted inaccuracies
|
||||
@@ -0,0 +1,230 @@
|
||||
Name
|
||||
|
||||
MESA_packed_depth_stencil
|
||||
|
||||
Name Strings
|
||||
|
||||
GL_MESA_packed_depth_stencil
|
||||
|
||||
Contact
|
||||
|
||||
Keith Whitwell, VA Linux Systems Inc. (keithw 'at' valinux.com)
|
||||
Brian Paul, VA Linux Systems Inc. (brianp 'at' valinux.com)
|
||||
|
||||
Status
|
||||
|
||||
Obsolete.
|
||||
|
||||
Version
|
||||
|
||||
|
||||
Number
|
||||
|
||||
???
|
||||
|
||||
Dependencies
|
||||
|
||||
EXT_abgr affects the definition of this extension
|
||||
SGIS_texture4D affects the definition of this extension
|
||||
EXT_cmyka affects the definition of this extension
|
||||
ARB_packed_pixels affects the definition of this extension
|
||||
|
||||
Overview
|
||||
|
||||
Provides a mechanism for DrawPixels and ReadPixels to efficiently
|
||||
transfer depth and stencil image data. Specifically, we defined new
|
||||
packed pixel formats and types which pack both stencil and depth
|
||||
into one value.
|
||||
|
||||
Issues:
|
||||
|
||||
1. Is this the right way to distinguish between 24/8 and 8/24
|
||||
pixel formats? Should we instead provide both:
|
||||
|
||||
GL_DEPTH_STENCIL_MESA
|
||||
GL_STENCIL_DEPTH_MESA
|
||||
|
||||
And perhaps just use GL_UNSIGNED_INT, GL_UNSIGNED_SHORT ?
|
||||
|
||||
2. If not, is it correct to use _REV to indicate that stencil
|
||||
preceeds depth in the 1_15 and 8_24 formats?
|
||||
|
||||
3. Do we really want the GL_UNSIGNED_SHORT formats?
|
||||
|
||||
|
||||
New Procedures and Functions
|
||||
|
||||
None.
|
||||
|
||||
New Tokens
|
||||
|
||||
Accepted by the <format> parameter of ReadPixels and DrawPixels:
|
||||
|
||||
GL_DEPTH_STENCIL_MESA 0x8750
|
||||
|
||||
Accepted by the <type> parameter of ReadPixels and DrawPixels:
|
||||
|
||||
GL_UNSIGNED_INT_24_8_MESA 0x8751
|
||||
GL_UNSIGNED_INT_8_24_REV_MESA 0x8752
|
||||
GL_UNSIGNED_SHORT_15_1_MESA 0x8753
|
||||
GL_UNSIGNED_SHORT_1_15_REV_MESA 0x8754
|
||||
|
||||
Additions to Chapter 2 of the 1.1 Specification (OpenGL Operation)
|
||||
|
||||
None
|
||||
|
||||
Additions to Chapter 3 of the 1.1 Specification (Rasterization)
|
||||
|
||||
One entry is added to table 3.5 (DrawPixels and ReadPixels formats).
|
||||
The new table is:
|
||||
|
||||
Target
|
||||
Format Name Buffer Element Meaning and Order
|
||||
----------- ------ -------------------------
|
||||
COLOR_INDEX Color Color index
|
||||
STENCIL_INDEX Stencil Stencil index
|
||||
DEPTH_COMPONENT Depth Depth component
|
||||
RED Color R component
|
||||
GREEN Color G component
|
||||
BLUE Color B component
|
||||
ALPHA Color A component
|
||||
RGB Color R, G, B components
|
||||
RGBA Color R, G, B, A components
|
||||
BGRA Color B, G, R, A components
|
||||
ABGR_EXT Color A, B, G, R components
|
||||
CMYK_EXT Color Cyan, Magenta, Yellow, Black components
|
||||
CMYKA_EXT Color Cyan, Magenta, Yellow, Black, A components
|
||||
LUMINANCE Color Luminance component
|
||||
LUMINANCE_ALPHA Color Luminance, A components
|
||||
DEPTH_STENCIL Depth, Depth component, stencil index.
|
||||
Stencil
|
||||
|
||||
Table 3.5: DrawPixels and ReadPixels formats. The third column
|
||||
gives a description of and the number and order of elements in a
|
||||
group.
|
||||
|
||||
Add to the description of packed pixel formats:
|
||||
|
||||
<type> Parameter Data of Matching
|
||||
Token Name Type Elements Pixel Formats
|
||||
---------------- ---- -------- -------------
|
||||
|
||||
UNSIGNED_BYTE_3_3_2 ubyte 3 RGB
|
||||
UNSIGNED_BYTE_2_3_3_REV ubyte 3 RGB
|
||||
UNSIGNED_SHORT_5_6_5 ushort 3 RGB
|
||||
UNSIGNED_SHORT_5_6_5_REV ushort 3 RGB
|
||||
UNSIGNED_SHORT_4_4_4_4 ushort 4 RGBA,BGRA,ABGR_EXT,CMYK_EXT
|
||||
UNSIGNED_SHORT_4_4_4_4_REV ushort 4 RGBA,BGRA
|
||||
UNSIGNED_SHORT_5_5_5_1 ushort 4 RGBA,BGRA,ABGR_EXT,CMYK_EXT
|
||||
UNSIGNED_SHORT_1_5_5_5_REV ushort 4 RGBA,BGRA
|
||||
UNSIGNED_INT_8_8_8_8 uint 4 RGBA,BGRA,ABGR_EXT,CMYK_EXT
|
||||
UNSIGNED_INT_8_8_8_8_REV uint 4 RGBA,BGRA
|
||||
UNSIGNED_INT_10_10_10_2 uint 4 RGBA,BGRA,ABGR_EXT,CMYK_EXT
|
||||
UNSIGNED_INT_2_10_10_10_REV uint 4 RGBA,BGRA
|
||||
UNSIGNED_SHORT_15_1_MESA ushort 2 DEPTH_STENCIL_MESA
|
||||
UNSIGNED_SHORT_1_15_REV_MESA ushort 2 DEPTH_STENCIL_MESA
|
||||
UNSIGNED_SHORT_24_8_MESA ushort 2 DEPTH_STENCIL_MESA
|
||||
UNSIGNED_SHORT_8_24_REV_MESA ushort 2 DEPTH_STENCIL_MESA
|
||||
|
||||
UNSIGNED_INT_8_24:
|
||||
|
||||
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
|
||||
+-----------------------+-----------------------------------------------------------------------+
|
||||
| | |
|
||||
+-----------------------+-----------------------------------------------------------------------+
|
||||
|
||||
first second
|
||||
element element
|
||||
|
||||
|
||||
UNSIGNED_INT_24_8:
|
||||
|
||||
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
|
||||
+----------------------------------------------------------------------+------------------------+
|
||||
| | |
|
||||
+----------------------------------------------------------------------+------------------------+
|
||||
|
||||
first second
|
||||
element element
|
||||
|
||||
UNSIGNED_SHORT_15_1:
|
||||
|
||||
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
|
||||
+-----------------------------------------------------------+---+
|
||||
| | |
|
||||
+-----------------------------------------------------------+---+
|
||||
|
||||
first second
|
||||
element element
|
||||
|
||||
|
||||
UNSIGNED_SHORT_1_15_REV:
|
||||
|
||||
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
|
||||
+---+-----------------------------------------------------------+
|
||||
| | |
|
||||
+---+-----------------------------------------------------------+
|
||||
|
||||
second first
|
||||
element element
|
||||
|
||||
The assignment of elements to fields in the packed pixel is as
|
||||
described in the table below:
|
||||
|
||||
First Second Third Fourth
|
||||
Format Element Element Element Element
|
||||
------ ------- ------- ------- -------
|
||||
RGB red green blue
|
||||
RGBA red green blue alpha
|
||||
BGRA blue green red alpha
|
||||
ABGR_EXT alpha blue green red
|
||||
CMYK_EXT cyan magenta yellow black
|
||||
DEPTH_STENCIL_MESA depth stencil
|
||||
|
||||
Additions to Chapter 4 of the 1.1 Specification (Per-Fragment Operations
|
||||
and the Frame Buffer)
|
||||
|
||||
The new format is added to the discussion of Obtaining Pixels from the
|
||||
Framebuffer. It should read " If the <format> is one of RED, GREEN,
|
||||
BLUE, ALPHA, RGB, RGBA, ABGR_EXT, LUMINANCE, or LUMINANCE_ALPHA, and
|
||||
the GL is in color index mode, then the color index is obtained."
|
||||
|
||||
The new format is added to the discussion of Index Lookup. It should
|
||||
read "If <format> is one of RED, GREEN, BLUE, ALPHA, RGB, RGBA,
|
||||
ABGR_EXT, LUMINANCE, or LUMINANCE_ALPHA, then the index is used to
|
||||
reference 4 tables of color components: PIXEL_MAP_I_TO_R,
|
||||
PIXEL_MAP_I_TO_G, PIXEL_MAP_I_TO_B, and PIXEL_MAP_I_TO_A."
|
||||
|
||||
|
||||
Additions to Chapter 5 of the 1.1 Specification (Special Functions)
|
||||
|
||||
None
|
||||
|
||||
Additions to Chapter 6 of the 1.1 Specification (State and State Requests)
|
||||
|
||||
None
|
||||
|
||||
Additions to the GLX Specification
|
||||
|
||||
None
|
||||
|
||||
GLX Protocol
|
||||
|
||||
TBD
|
||||
|
||||
Errors
|
||||
|
||||
None
|
||||
|
||||
New State
|
||||
|
||||
None
|
||||
|
||||
Revision History
|
||||
|
||||
Version 1.0 - 23 Sep 2000
|
||||
Keith's original version.
|
||||
|
||||
Version 1.1 - 3 Nov 2000
|
||||
Brian's edits, assigned values to new enums.
|
||||
|
||||
@@ -0,0 +1,356 @@
|
||||
Name
|
||||
|
||||
MESA_program_debug
|
||||
|
||||
Name Strings
|
||||
|
||||
GL_MESA_program_debug
|
||||
|
||||
Contact
|
||||
|
||||
Brian Paul (brian.paul 'at' tungstengraphics.com)
|
||||
|
||||
Status
|
||||
|
||||
XXX - Not complete yet!!!
|
||||
|
||||
Version
|
||||
|
||||
Last Modified Date: July 20, 2003
|
||||
Author Revision: 1.0
|
||||
|
||||
Number
|
||||
|
||||
TBD
|
||||
|
||||
Dependencies
|
||||
|
||||
OpenGL 1.4 is required
|
||||
The extension is written against the OpenGL 1.4 specification.
|
||||
ARB_vertex_program or ARB_fragment_program or NV_vertex_program
|
||||
or NV_fragment_program is required.
|
||||
|
||||
Overview
|
||||
|
||||
The extension provides facilities for implementing debuggers for
|
||||
vertex and fragment programs.
|
||||
|
||||
The concept is that vertex and fragment program debuggers will be
|
||||
implemented outside of the GL as a utility package. This extension
|
||||
only provides the minimal hooks required to implement a debugger.
|
||||
|
||||
There are facilities to do the following:
|
||||
1. Have the GL call a user-specified function prior to executing
|
||||
each vertex or fragment instruction.
|
||||
2. Query the current program string's execution position.
|
||||
3. Query the current values of intermediate program values.
|
||||
|
||||
The main feature is the ProgramCallbackMESA function. It allows the
|
||||
user to register a callback function with the GL. The callback will
|
||||
be called prior to executing each vertex or fragment program instruction.
|
||||
|
||||
From within the callback, the user may issue Get* commands to
|
||||
query current GL state. The GetProgramRegisterfvMESA function allows
|
||||
current program values to be queried (such as temporaries, input
|
||||
attributes, and result registers).
|
||||
|
||||
There are flags for enabling/disabling the program callbacks.
|
||||
|
||||
The current execution position (as an offset from the start of the
|
||||
program string) can be queried with
|
||||
GetIntegerv(GL_FRAGMENT_PROGRAM_POSITION_MESA, &pos) or
|
||||
GetIntegerv(GL_VERTEX_PROGRAM_POSITION_MESA, &pos).
|
||||
|
||||
|
||||
IP Status
|
||||
|
||||
None
|
||||
|
||||
Issues
|
||||
|
||||
1. Is this the right model for a debugger?
|
||||
|
||||
It seems prudent to minimize the scope of this extension and leave
|
||||
it up to the developer (or developer community) to write debuggers
|
||||
that layer on top of this extension.
|
||||
|
||||
If the debugger were fully implemented within the GL it's not
|
||||
clear how terminal and GUI-based interfaces would work, for
|
||||
example.
|
||||
|
||||
2. There aren't any other extensions that register callbacks with
|
||||
the GL. Isn't there another solution?
|
||||
|
||||
If we want to be able to single-step through vertex/fragment
|
||||
programs I don't see another way to do it.
|
||||
|
||||
3. How do we prevent the user from doing something crazy in the
|
||||
callback function, like trying to call glBegin (leading to
|
||||
recursion)?
|
||||
|
||||
The rule is that the callback function can only issue glGet*()
|
||||
functions and no other GL commands. It could be difficult to
|
||||
enforce this, however. Therefore, calling any non-get GL
|
||||
command from within the callback will result in undefined
|
||||
results.
|
||||
|
||||
4. Is this extension amenable to hardware implementation?
|
||||
|
||||
Hopefully, but if not, the GL implementation will have to fall
|
||||
back to a software path when debugging. This may be acceptable
|
||||
for debugging.
|
||||
|
||||
5. What's the <data> parameter to ProgramCallbackMESA for?
|
||||
|
||||
It's a common programming practice to associate a user-supplied
|
||||
value with callback functions.
|
||||
|
||||
6. Debuggers often allow one to modify intermediate program values,
|
||||
then continue. Does this extension support that?
|
||||
|
||||
No.
|
||||
|
||||
|
||||
New Procedures and Functions (and datatypes)
|
||||
|
||||
typedef void (*programcallbackMESA)(enum target, void *data)
|
||||
|
||||
void ProgramCallbackMESA(enum target, programcallbackMESA callback,
|
||||
void *data)
|
||||
|
||||
void GetProgramRegisterfvMESA(enum target, sizei len,
|
||||
const ubyte *registerName, float *v)
|
||||
|
||||
New Tokens
|
||||
|
||||
Accepted by the <cap> parameter of Enable, Disable, IsEnabled,
|
||||
GetBooleanv, GetDoublev, GetFloatv and GetIntegerv:
|
||||
|
||||
FRAGMENT_PROGRAM_CALLBACK_MESA 0x8bb1
|
||||
VERTEX_PROGRAM_CALLBACK_MESA 0x8bb4
|
||||
|
||||
Accepted by the <pname> parameter GetBooleanv, GetDoublev,
|
||||
GetFloatv and GetIntegerv:
|
||||
|
||||
FRAGMENT_PROGRAM_POSITION_MESA 0x8bb0
|
||||
VERTEX_PROGRAM_POSITION_MESA 0x8bb4
|
||||
|
||||
Accepted by the <pname> parameter of GetPointerv:
|
||||
|
||||
FRAGMENT_PROGRAM_CALLBACK_FUNC_MESA 0x8bb2
|
||||
FRAGMENT_PROGRAM_CALLBACK_DATA_MESA 0x8bb3
|
||||
VERTEX_PROGRAM_CALLBACK_FUNC_MESA 0x8bb6
|
||||
VERTEX_PROGRAM_CALLBACK_DATA_MESA 0x8bb7
|
||||
|
||||
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)
|
||||
|
||||
None.
|
||||
|
||||
Additions to Chapter 5 of the OpenGL 1.4 Specification (Special Functions)
|
||||
|
||||
In section 5.4 "Display Lists", page 202, add the following command
|
||||
to the list of those that are not compiled into display lists:
|
||||
|
||||
ProgramCallbackMESA.
|
||||
|
||||
|
||||
Add a new section 5.7 "Callback Functions"
|
||||
|
||||
The function
|
||||
|
||||
void ProgramCallbackMESA(enum target, programcallbackMESA callback,
|
||||
void *data)
|
||||
|
||||
registers a user-defined callback function with the GL. <target>
|
||||
may be FRAGMENT_PROGRAM_ARB or VERTEX_PROGRAM_ARB. The enabled
|
||||
callback functions registered with these targets will be called
|
||||
prior to executing each instruction in the current fragment or
|
||||
vertex program, respectively. The callbacks are enabled and
|
||||
disabled by calling Enable or Disable with <cap>
|
||||
FRAGMENT_PROGRAM_ARB or VERTEX_PROGRAM_ARB.
|
||||
|
||||
The callback function's signature must match the typedef
|
||||
|
||||
typedef void (*programcallbackMESA)(enum target, void *data)
|
||||
|
||||
When the callback function is called, <target> will either be
|
||||
FRAGMENT_PROGRAM_ARB or VERTEX_PROGRAM_ARB to indicate which
|
||||
program is currently executing and <data> will be the value
|
||||
specified when ProgramCallbackMESA was called.
|
||||
|
||||
From within the callback function, only the following GL commands
|
||||
may be called:
|
||||
|
||||
GetBooleanv
|
||||
GetDoublev
|
||||
GetFloatv
|
||||
GetIntegerv
|
||||
GetProgramLocalParameter
|
||||
GetProgramEnvParameter
|
||||
GetProgramRegisterfvMESA
|
||||
GetProgramivARB
|
||||
GetProgramStringARB
|
||||
GetError
|
||||
|
||||
Calling any other command from within the callback results in
|
||||
undefined behaviour.
|
||||
|
||||
|
||||
Additions to Chapter 6 of the OpenGL 1.4 Specification (State and
|
||||
State Requests)
|
||||
|
||||
Add a new section 6.1.3 "Program Value Queries":
|
||||
|
||||
The command
|
||||
|
||||
void GetProgramRegisterfvMESA(enum target, sizei len,
|
||||
const ubyte *registerName,
|
||||
float *v)
|
||||
|
||||
Is used to query the value of program variables and registers
|
||||
during program execution. GetProgramRegisterfvMESA may only be
|
||||
called from within a callback function registered with
|
||||
ProgramCallbackMESA.
|
||||
|
||||
<registerName> and <len> specify the name a variable, input
|
||||
attribute, temporary, or result register in the program string.
|
||||
The current value of the named variable is returned as four
|
||||
values in <v>. If <name> doesn't exist in the program string,
|
||||
the error INVALID_OPERATION is generated.
|
||||
|
||||
Additions to Appendix A of the OpenGL 1.4 Specification (Invariance)
|
||||
|
||||
None.
|
||||
|
||||
Additions to the AGL/GLX/WGL Specifications
|
||||
|
||||
None.
|
||||
|
||||
GLX Protocol
|
||||
|
||||
XXX TBD
|
||||
|
||||
Dependencies on NV_vertex_program and NV_fragment_program
|
||||
|
||||
If NV_vertex_program and/or NV_fragment_program are supported,
|
||||
vertex and/or fragment programs defined by those extensions may
|
||||
be debugged as well. Register queries will use the syntax used
|
||||
by those extensions (i.e. "v[X]" to query vertex attributes,
|
||||
"o[X]" for vertex outputs, etc.)
|
||||
|
||||
Errors
|
||||
|
||||
INVALID_OPERATION is generated if ProgramCallbackMESA is called
|
||||
between Begin and End.
|
||||
|
||||
INVALID_ENUM is generated by ProgramCallbackMESA if <target> is not
|
||||
a supported vertex or fragment program type.
|
||||
|
||||
Note: INVALID_OPERAION IS NOT generated by GetProgramRegisterfvMESA,
|
||||
GetBooleanv, GetDoublev, GetFloatv, or GetIntegerv if called between
|
||||
Begin and End when a vertex or fragment program is currently executing.
|
||||
|
||||
INVALID_ENUM is generated by ProgramCallbackMESA,
|
||||
GetProgramRegisterfvMESA if <target> is not a program target supported
|
||||
by ARB_vertex_program, ARB_fragment_program (or NV_vertex_program or
|
||||
NV_fragment_program).
|
||||
|
||||
INVALID_VALUE is generated by GetProgramRegisterfvMESA if <registerName>
|
||||
does not name a known program register or variable.
|
||||
|
||||
INVALID_OPERATION is generated by GetProgramRegisterfvMESA when a
|
||||
register query is attempted for a program target that's not currently
|
||||
being executed.
|
||||
|
||||
|
||||
New State
|
||||
|
||||
XXX finish
|
||||
|
||||
(table 6.N, p. ###)
|
||||
Initial
|
||||
Get Value Type Get Command Value Description Sec. Attribute
|
||||
--------- ---- ----------- ----- ----------- ---- ---------
|
||||
FRAGMENT_PROGRAM_CALLBACK_MESA B IsEnabled FALSE XXX XXX enable
|
||||
VERTEX_PROGRAM_CALLBACK_MESA B IsEnabled FALSE XXX XXX enable
|
||||
FRAGMENT_PROGRAM_POSITION_MESA Z+ GetIntegerv -1 XXX XXX -
|
||||
VERTEX_PROGRAM_POSITION_MESA Z+ GetIntegerv -1 XXX XXX -
|
||||
FRAGMENT_PROGRAM_CALLBACK_FUNC_MESA P GetPointerv NULL XXX XXX -
|
||||
VERTEX_PROGRAM_CALLBACK_FUNC_MESA P GetPointerv NULL XXX XXX -
|
||||
FRAGMENT_PROGRAM_CALLBACK_DATA_MESA P GetPointerv NULL XXX XXX -
|
||||
VERTEX_PROGRAM_CALLBACK_DATA_MESA P GetPointerv NULL XXX XXX -
|
||||
|
||||
XXX more?
|
||||
|
||||
New Implementation Dependent State
|
||||
|
||||
None.
|
||||
|
||||
Revision History
|
||||
|
||||
8 July 2003
|
||||
Initial draft. (Brian Paul)
|
||||
11 July 2003
|
||||
Second draft. (Brian Paul)
|
||||
20 July 2003
|
||||
Third draft. Lots of fundamental changes. (Brian Paul)
|
||||
23 July 2003
|
||||
Added chapter 5 and 6 spec language. (Brian Paul)
|
||||
|
||||
Example Usage
|
||||
|
||||
The following is a very simple example of how this extension may
|
||||
be used to print the values of R0, R1, R2 and R3 while executing
|
||||
vertex programs.
|
||||
|
||||
|
||||
/* This is called by the GL when the vertex program is executing.
|
||||
* We can only make glGet* calls from within this function!
|
||||
*/
|
||||
void DebugCallback(GLenum target, GLvoid *data)
|
||||
{
|
||||
GLint pos;
|
||||
GLuint i;
|
||||
|
||||
/* Get PC and current instruction string */
|
||||
glGetIntegerv(GL_VERTEX_PROGRAM_POSITION_ARB, &pos);
|
||||
|
||||
printf("Current position: %d\n", pos);
|
||||
|
||||
printf("Current temporary registers:\n");
|
||||
for (i = 0; i < 4; i++) {
|
||||
GLfloat v[4];
|
||||
char s[10];
|
||||
sprintf(s, "R%d", i);
|
||||
glGetProgramRegisterfvMESA(GL_VERTEX_PROGRAM_ARB, strlen(s), s, v);
|
||||
printf("R%d = %g, %g, %g, %g\n", i, v[0], v[1], v[2], v[3]);
|
||||
}
|
||||
}
|
||||
|
||||
|
||||
/*
|
||||
* elsewhere...
|
||||
*/
|
||||
|
||||
/* Register our debugger callback function */
|
||||
glProgramCallbackMESA(GL_VERTEX_PROGRAM_ARB, DebugCallback, NULL);
|
||||
glEnable(GL_VERTEX_PROGRAM_CALLBACK_MESA);
|
||||
|
||||
/* define/bind a vertex program */
|
||||
|
||||
glEnable(GL_VERTEX_PROGRAM);
|
||||
|
||||
/* render something */
|
||||
glBegin(GL_POINTS);
|
||||
glVertex2f(0, 0);
|
||||
glEnd();
|
||||
|
||||
@@ -0,0 +1,190 @@
|
||||
Name
|
||||
|
||||
MESA_sprite_point
|
||||
|
||||
Name Strings
|
||||
|
||||
GL_MESA_sprite_point
|
||||
|
||||
Contact
|
||||
|
||||
Brian Paul, VA Linux Systems Inc. (brianp 'at' valinux.com)
|
||||
|
||||
Status
|
||||
|
||||
Obsolete - see GL_ARB_point_sprite.
|
||||
|
||||
Version
|
||||
|
||||
|
||||
Number
|
||||
|
||||
???
|
||||
|
||||
Dependencies
|
||||
|
||||
GL_EXT_point_parameters effects the definition of this extension
|
||||
GL_ARB_multitexture effects the definition of this extension
|
||||
|
||||
Overview
|
||||
|
||||
This extension modifies the way in which points are rendered,
|
||||
specifically when they're textured. When SPRITE_POINT_MESA is enabled
|
||||
a point is rendered as if it were a quadrilateral with unique texture
|
||||
coordinates at each vertex. This extension effectively turns points
|
||||
into sprites which may be rendered more easily and quickly than using
|
||||
conventional textured quadrilaterals.
|
||||
|
||||
When using point size > 1 or attenuated points this extension is an
|
||||
effective way to render many small sprite images for particle systems
|
||||
or other effects.
|
||||
|
||||
Issues:
|
||||
|
||||
1. How are the texture coordinates computed?
|
||||
|
||||
The lower-left corner has texture coordinate (0,0,r,q).
|
||||
The lower-right, (1,0,r,q). The upper-right, (1,1,r,q).
|
||||
The upper-left, (0,1,r,q).
|
||||
|
||||
2. What about texgen and texture matrices?
|
||||
|
||||
Texgen and the texture matrix have no effect on the point's s and t
|
||||
texture coordinates. The r and q coordinates may have been computed
|
||||
by texgen or the texture matrix. Note that with a 3D texture and/or
|
||||
texgen that the r coordinate could be used to select a slice in the
|
||||
3D texture.
|
||||
|
||||
3. What about point smoothing?
|
||||
|
||||
When point smoothing is enabled, a triangle fan could be rendered
|
||||
to approximate a circular point. This could be problematic to
|
||||
define and implement so POINT_SMOOTH is ignored when drawing sprite
|
||||
points.
|
||||
|
||||
Smoothed points can be approximated by using an appropriate texture
|
||||
images, alpha testing and blending.
|
||||
|
||||
POLYGON_SMOOTH does effect the rendering of the quadrilateral, however.
|
||||
|
||||
4. What about sprite rotation?
|
||||
|
||||
There is none. Sprite points are always rendered as window-aligned
|
||||
squares. One could define rotated texture images if desired. A 3D
|
||||
texture and appropriate texture r coordinates could be used to
|
||||
effectively specify image rotation per point.
|
||||
|
||||
5. What about POLYGON_MODE?
|
||||
|
||||
POLYGON_MODE does not effect the rasterization of the quadrilateral.
|
||||
|
||||
6. What about POLYGON_CULL?
|
||||
|
||||
TBD. Polygon culling is normally specified and implemented in the
|
||||
transformation stage of OpenGL. However, some rasterization hardware
|
||||
implements it later during triangle setup.
|
||||
|
||||
Polygon culling wouldn't be useful for sprite points since the
|
||||
quadrilaterals are always defined in counter-clockwise order in
|
||||
window space. For that reason, polygon culling should probably be
|
||||
ignored.
|
||||
|
||||
7. Should sprite points be alpha-attenuated if their size is below the
|
||||
point parameter's threshold size?
|
||||
|
||||
8. Should there be an advertisized maximum sprite point size?
|
||||
|
||||
No. Since we're rendering the point as a quadrilateral there's no
|
||||
need to limit the size.
|
||||
|
||||
|
||||
New Procedures and Functions
|
||||
|
||||
None.
|
||||
|
||||
New Tokens
|
||||
|
||||
Accepted by the <pname> parameter of Enable, Disable, IsEnabled,
|
||||
GetIntegerv, GetBooleanv, GetFloatv and GetDoublev:
|
||||
|
||||
SPRITE_POINT_MESA 0x????
|
||||
MAX_SPRITE_POINT_SIZE_MESA 0x???? (need this?)
|
||||
|
||||
Additions to Chapter 2 of the 1.1 Specification (OpenGL Operation)
|
||||
|
||||
None
|
||||
|
||||
Additions to Chapter 3 of the 1.1 Specification (Rasterization)
|
||||
|
||||
Section ???.
|
||||
|
||||
When SPRITE_POINT_MESA is enabled points are rasterized as screen-
|
||||
aligned quadrilaterals. If the four vertices of the quadrilateral
|
||||
are labeled A, B, C, and D, starting at the lower-left corner and moving
|
||||
counter-clockwise around the quadrilateral, then the vertex and
|
||||
texture coordinates are computed as follows:
|
||||
|
||||
vertex window coordinate texture coordinate
|
||||
A (x-r, y-r, z, w) (0, 0, r, q)
|
||||
B (x+r, y-r, z, w) (1, 0, r, q)
|
||||
C (x+r, y+r, z, w) (1, 1, r, q)
|
||||
D (x-r, y+r, z, w) (0, 1, r, q)
|
||||
|
||||
where x, y, z, w are the point's window coordinates, r and q are the
|
||||
point's 3rd and 4th texture coordinates and r is half the point's
|
||||
size. The other vertex attributes (such as the color and fog coordinate)
|
||||
are simply duplicated from the original point vertex.
|
||||
|
||||
Point size may either be specified with PointSize or computed
|
||||
according to the EXT_point_parameters extension.
|
||||
|
||||
The new texture coordinates are not effected by texgen or the texture
|
||||
matrix. Note, however, that the texture r and q coordinates are passed
|
||||
unchanged and may have been computed with texgen and/or the texture
|
||||
matrix.
|
||||
|
||||
If multiple texture units are present the same texture coordinate is
|
||||
used for all texture units.
|
||||
|
||||
The point is then rendered as if it were a quadrilateral using the
|
||||
normal point sampling rules. POLYGON_MODE does not effect the
|
||||
rasterization of the quadrilateral but POLYGON_SMOOTH does.
|
||||
|
||||
POINT_SMOOTH has no effect when SPRITE_POINT_MESA is enabled.
|
||||
|
||||
Additions to Chapter 4 of the 1.1 Specification (Per-Fragment Operations
|
||||
and the Frame Buffer)
|
||||
|
||||
None.
|
||||
|
||||
Additions to Chapter 5 of the 1.1 Specification (Special Functions)
|
||||
|
||||
None
|
||||
|
||||
Additions to Chapter 6 of the 1.1 Specification (State and State Requests)
|
||||
|
||||
None
|
||||
|
||||
Additions to the GLX Specification
|
||||
|
||||
None
|
||||
|
||||
GLX Protocol
|
||||
|
||||
TBD
|
||||
|
||||
Errors
|
||||
|
||||
None
|
||||
|
||||
New State
|
||||
|
||||
Add boolean variable SPRITE_POINT_MESA to the point attribute group.
|
||||
|
||||
Revision History
|
||||
|
||||
Version 1.0 - 4 Dec 2000
|
||||
Original draft.
|
||||
|
||||
|
||||
|
||||
@@ -0,0 +1,359 @@
|
||||
Name
|
||||
|
||||
MESA_trace
|
||||
|
||||
Name Strings
|
||||
|
||||
GL_MESA_trace
|
||||
|
||||
Contact
|
||||
|
||||
Bernd Kreimeier, Loki Entertainment, bk 'at' lokigames.com
|
||||
Brian Paul, VA Linux Systems, Inc., brianp 'at' valinux.com
|
||||
|
||||
Status
|
||||
|
||||
Obsolete.
|
||||
|
||||
Version
|
||||
|
||||
|
||||
Number
|
||||
|
||||
none yet
|
||||
|
||||
Dependencies
|
||||
|
||||
OpenGL 1.2 is required.
|
||||
The extension is written against the OpenGL 1.2 Specification
|
||||
|
||||
Overview
|
||||
|
||||
Provides the application with means to enable and disable logging
|
||||
of GL calls including parameters as readable text. The verbosity
|
||||
of the generated log can be controlled. The resulting logs are
|
||||
valid (but possibly incomplete) C code and can be compiled and
|
||||
linked for standalone test programs. The set of calls and the
|
||||
amount of static data that is logged can be controlled at runtime.
|
||||
The application can add comments and enable or disable tracing of GL
|
||||
operations at any time. The data flow from the application to GL
|
||||
and back is unaffected except for timing.
|
||||
|
||||
Application-side implementation of these features raises namespace
|
||||
and linkage issues. In the driver dispatch table a simple
|
||||
"chain of responsibility" pattern (aka "composable piepline")
|
||||
can be added.
|
||||
|
||||
IP Status
|
||||
|
||||
The extension spec is in the public domain. The current implementation
|
||||
in Mesa is covered by Mesa's XFree86-style copyright by the authors above.
|
||||
This extension is partially inspired by the Quake2 QGL wrapper.
|
||||
|
||||
Issues
|
||||
|
||||
|
||||
(1) Is this Extension obsolete because it can
|
||||
be implemented as a wrapper DLL?
|
||||
|
||||
RESOLVED: No. While certain operating systems (Win32) provide linkers
|
||||
that facilitate this kind of solution, other operating systems
|
||||
(Linux) do not support hierarchical linking, so a wrapper solution
|
||||
would result in symbol collisions.
|
||||
Further, IHV's might have builtin support for tracing GL execution
|
||||
that enjoys privileged access, or that they do not wish to separate
|
||||
the tracing code from their driver code base.
|
||||
|
||||
(2) Should the Trace API explicitely support the notion of "frames?
|
||||
This would require hooking into glXSwapBuffers calls as well.
|
||||
|
||||
RESOLVED: No. The application can use NewTraceMESA/EndTraceMESA
|
||||
and TraceComment along with external parsing tools to split the
|
||||
trace into frames, in whatever way considered adequate.
|
||||
|
||||
(2a) Should GLX calls be traced?
|
||||
|
||||
PBuffers and other render-to-texture solutions demonstrate that
|
||||
context level commands beyond SwapBuffers might have to be
|
||||
traced. The GL DLL exports the entry points, so this would not
|
||||
be out of the question.
|
||||
|
||||
(3) Should the specification mandate the actual output format?
|
||||
|
||||
RESOLVED: No. It is sufficient to guarantee that all data and commands
|
||||
will be traced as requested by Enable/DisableTraceMESA, in the order
|
||||
encountered. Whether the resulting trace is available as a readable
|
||||
text file, binary metafile, compilable source code, much less which
|
||||
indentation and formatting has been used, is up to the implementation.
|
||||
For the same reason this specification does not enforce or prohibit
|
||||
additional information added to the trace (statistics, profiling/timing,
|
||||
warnings on possible error conditions).
|
||||
|
||||
(4) Should the comment strings associated with names and pointer (ranges)
|
||||
be considered persistent state?
|
||||
|
||||
RESOLVED: No. The implementation is not forced to use this information
|
||||
on subsequent occurences of name/pointer, and is free to consider it
|
||||
transient state.
|
||||
|
||||
(5) Should comment commands be prohibited between Begin/End?
|
||||
|
||||
RESOLVED: Yes, with the exception of TraceCommentMESA. TraceCommentMESA
|
||||
is transient, the other commands might cause storage of persistent
|
||||
data in the context. There is no need to have the ability mark names
|
||||
or pointers between Begin and End.
|
||||
|
||||
|
||||
New Procedures and Functions
|
||||
|
||||
void NewTraceMESA( bitfield mask, const ubyte * traceName )
|
||||
|
||||
void EndTraceMESA( void )
|
||||
|
||||
void EnableTraceMESA( bitfield mask )
|
||||
|
||||
void DisableTraceMESA( bitfield mask )
|
||||
|
||||
void TraceAssertAttribMESA( bitfield attribMask )
|
||||
|
||||
void TraceCommentMESA( const ubyte* comment )
|
||||
|
||||
void TraceTextureMESA( uint name, const ubyte* comment )
|
||||
|
||||
void TraceListMESA( uint name, const ubyte* comment )
|
||||
|
||||
void TracePointerMESA( void* pointer, const ubyte* comment )
|
||||
|
||||
void TracePointerRangeMESA( const void* first,
|
||||
const void* last,
|
||||
const ubyte* comment )
|
||||
|
||||
New Tokens
|
||||
|
||||
Accepted by the <mask> parameter of EnableTrace and DisableTrace:
|
||||
|
||||
TRACE_ALL_BITS_MESA 0xFFFF
|
||||
TRACE_OPERATIONS_BIT_MESA 0x0001
|
||||
TRACE_PRIMITIVES_BIT_MESA 0x0002
|
||||
TRACE_ARRAYS_BIT_MESA 0x0004
|
||||
TRACE_TEXTURES_BIT_MESA 0x0008
|
||||
TRACE_PIXELS_BIT_MESA 0x0010
|
||||
TRACE_ERRORS_BIT_MESA 0x0020
|
||||
|
||||
Accepted by the <pname> parameter of GetIntegerv, GetBooleanv,
|
||||
GetFloatv, and GetDoublev:
|
||||
|
||||
TRACE_MASK_MESA 0x8755
|
||||
|
||||
Accepted by the <pname> parameter to GetString:
|
||||
|
||||
TRACE_NAME_MESA 0x8756
|
||||
|
||||
|
||||
Additions to Chapter 2 of the OpenGL 1.2.1 Specification (OpenGL Operation)
|
||||
|
||||
None.
|
||||
|
||||
Additions to Chapter 3 of the OpenGL 1.2.1 Specification (OpenGL Operation)
|
||||
|
||||
None.
|
||||
|
||||
Additions to Chapter 4 of the OpenGL 1.2.1 Specification (OpenGL Operation)
|
||||
|
||||
None.
|
||||
|
||||
Additions to Chapter 5 of the OpenGL 1.2.1 Specification (Special Functions)
|
||||
|
||||
Add a new section:
|
||||
|
||||
5.7 Tracing
|
||||
|
||||
The tracing facility is used to record the execution of a GL program
|
||||
to a human-readable log. The log appears as a sequence of GL commands
|
||||
using C syntax. The primary intention of tracing is to aid in program
|
||||
debugging.
|
||||
|
||||
A trace is started with the command
|
||||
|
||||
void NewTraceMESA( bitfield mask, const GLubyte * traceName )
|
||||
|
||||
<mask> may be any value accepted by PushAttrib and specifies a set of
|
||||
attribute groups. The state values included in those attribute groups
|
||||
is written to the trace as a sequence of GL commands.
|
||||
|
||||
<traceName> specifies a name or label for the trace. It is expected
|
||||
that <traceName> will be interpreted as a filename in most implementations.
|
||||
|
||||
A trace is ended by calling the command
|
||||
|
||||
void EndTraceMESA( void )
|
||||
|
||||
It is illegal to call NewTraceMESA or EndTraceMESA between Begin and End.
|
||||
|
||||
The commands
|
||||
|
||||
void EnableTraceMESA( bitfield mask )
|
||||
void DisableTraceMESA( bitfield mask )
|
||||
|
||||
enable or disable tracing of different classes of GL commands.
|
||||
<mask> may be the union of any of TRACE_OPERATIONS_BIT_MESA,
|
||||
TRACE_PRIMITIVES_BIT_MESA, TRACE_ARRAYS_BIT_MESA, TRACE_TEXTURES_BIT_MESA,
|
||||
and TRACE_PIXELS_BIT_MESA. The special token TRACE_ALL_BITS_MESA
|
||||
indicates all classes of commands are to be logged.
|
||||
|
||||
TRACE_OPERATIONS_BIT_MESA controls logging of all commands outside of
|
||||
Begin/End, including Begin/End.
|
||||
|
||||
TRACE_PRIMITIVES_BIT_MESA controls logging of all commands inside of
|
||||
Begin/End, including Begin/End.
|
||||
|
||||
TRACE_ARRAYS_BIT_MESA controls logging of VertexPointer, NormalPointer,
|
||||
ColorPointer, IndexPointer, TexCoordPointer and EdgeFlagPointer commands.
|
||||
|
||||
TRACE_TEXTURES_BIT_MESA controls logging of texture data dereferenced by
|
||||
TexImage1D, TexImage2D, TexImage3D, TexSubImage1D, TexSubImage2D, and
|
||||
TexSubImage3D commands.
|
||||
|
||||
TRACE_PIXELS_BIT_MESA controls logging of image data dereferenced by
|
||||
Bitmap and DrawPixels commands.
|
||||
|
||||
TRACE_ERRORS_BIT_MESA controls logging of all errors. If this bit is
|
||||
set, GetError will be executed whereever applicable, and the result will
|
||||
be added to the trace as a comment. The error returns are cached and
|
||||
returned to the application on its GetError calls. If the user does not
|
||||
wish the additional GetError calls to be performed, this bit should not
|
||||
be set.
|
||||
|
||||
The command
|
||||
|
||||
void TraceCommentMESA( const ubyte* comment )
|
||||
|
||||
immediately adds the <comment> string to the trace output, surrounded
|
||||
by C-style comment delimiters.
|
||||
|
||||
The commands
|
||||
|
||||
void TraceTextureMESA( uint name, const ubyte* comment )
|
||||
void TraceListMESA( uint name, const ubyte* comment )
|
||||
|
||||
associates <comment> with the texture object or display list specified
|
||||
by <name>. Logged commands which reference the named texture object or
|
||||
display list will be annotated with <comment>. If IsTexture(name) or
|
||||
IsList(name) fail (respectively) the command is quietly ignored.
|
||||
|
||||
The commands
|
||||
|
||||
void TracePointerMESA( void* pointer, const ubyte* comment )
|
||||
|
||||
void TracePointerRangeMESA( const void* first,
|
||||
const void* last,
|
||||
const ubyte* comment )
|
||||
|
||||
associate <comment> with the address specified by <pointer> or with
|
||||
a range of addresses specified by <first> through <last>.
|
||||
Any logged commands which reference <pointer> or an address between
|
||||
<first> and <last> will be annotated with <comment>.
|
||||
|
||||
The command
|
||||
|
||||
void TraceAssertAttribMESA( bitfield attribMask )
|
||||
|
||||
will add GL state queries and assertion statements to the log to
|
||||
confirm that the current state at the time TraceAssertAttrib is
|
||||
executed matches the current state when the trace log is executed
|
||||
in the future.
|
||||
|
||||
<attribMask> is any value accepted by PushAttrib and specifies
|
||||
the groups of state variables which are to be asserted.
|
||||
|
||||
The commands NewTraceMESA, EndTraceMESA, EnableTraceMESA, DisableTraceMESA,
|
||||
TraceAssertAttribMESA, TraceCommentMESA, TraceTextureMESA, TraceListMESA,
|
||||
TracePointerMESA and TracePointerRangeMESA are not compiled into display lists.
|
||||
|
||||
|
||||
Examples:
|
||||
|
||||
The command NewTraceMESA(DEPTH_BUFFER_BIT, "log") will query the state
|
||||
variables DEPTH_TEST, DEPTH_FUNC, DEPTH_WRITEMASK, and DEPTH_CLEAR_VALUE
|
||||
to get the values <test>, <func>, <mask>, and <clear> respectively.
|
||||
Statements equivalent to the following will then be logged:
|
||||
|
||||
glEnable(GL_DEPTH_TEST); (if <test> is true)
|
||||
glDisable(GL_DEPTH_TEST); (if <test> is false)
|
||||
glDepthFunc(<func>);
|
||||
glDepthMask(<mask>);
|
||||
glClearDepth(<clear>);
|
||||
|
||||
|
||||
The command TraceAssertAttribMESA(DEPTH_BUFFER_BIT) will query the state
|
||||
variables DEPTH_TEST, DEPTH_FUNC, DEPTH_WRITEMASK, and DEPTH_CLEAR_VALUE
|
||||
to get the values <test>, <func>, <mask>, and <clear> respectively.
|
||||
The resulting trace might then look will like this:
|
||||
|
||||
{
|
||||
GLboolean b;
|
||||
GLint i;
|
||||
GLfloat f;
|
||||
b = glIsEnabled(GL_DEPTH_TEST);
|
||||
assert(b == <test>);
|
||||
glGetIntegerv(GL_DEPTH_FUNC, &i);
|
||||
assert(i == <func>);
|
||||
glGetIntegerv(GL_DEPTH_MASK, &i);
|
||||
assert(i == <mask>);
|
||||
glGetFloatv(GL_DEPTH_CLEAR_VALUE, &f);
|
||||
assert(f == <clear>);
|
||||
}
|
||||
|
||||
|
||||
Additions to Chapter 6 of the OpenGL 1.2.1 Specification
|
||||
(State and State Requests)
|
||||
|
||||
Querying TRACE_MASK_MESA with GetIntegerv, GetFloatv, GetBooleanv or
|
||||
GetDoublev returns the current command class trace mask.
|
||||
|
||||
Querying TRACE_NAME_MESA with GetString returns the current trace name.
|
||||
|
||||
|
||||
Additions to Appendix A of the OpenGL 1.2.1 Specification (Invariance)
|
||||
|
||||
The MESA_trace extension can be used in a way that does not affect data
|
||||
flow from application to OpenGL, as well as data flow from OpenGL to
|
||||
application, except for timing, possible print I/O. TRACE_ERRORS_BIT_MESA
|
||||
will add additional GetError queries. Setting a trace mask with NewTraceMESA
|
||||
as well as use of TraceAssertAttribMESA might cause additional state queries.
|
||||
With the possible exception of performance, OpenGL rendering should not be
|
||||
affected at all by a properly chosen logging operation.
|
||||
|
||||
Additions to the AGL/GLX/WGL Specifications
|
||||
|
||||
None.
|
||||
|
||||
GLX Protocol
|
||||
|
||||
None. The logging operation is carried out client-side, by exporting
|
||||
entry points to the wrapper functions that execute the logging operation.
|
||||
|
||||
Errors
|
||||
|
||||
INVALID_OPERATION is generated if any trace command except TraceCommentMESA
|
||||
is called between Begin and End.
|
||||
|
||||
New State
|
||||
|
||||
The current trace name and current command class mask are stored
|
||||
per-context.
|
||||
|
||||
New Implementation Dependent State
|
||||
|
||||
None.
|
||||
|
||||
Revision History
|
||||
|
||||
* Revision 0.1 - Initial draft from template (bk000415)
|
||||
* Revision 0.2 - Draft (bk000906)
|
||||
* Revision 0.3 - Draft (bk000913)
|
||||
* Revision 0.4 - Reworked text, fixed typos (bp000914)
|
||||
* Revision 0.5 - Assigned final GLenum values (bp001103)
|
||||
* Revision 0.6 - TRACE_ERRORS_BIT_MESA (bk000916)
|
||||
* Revision 0.7 - Added MESA postfix (bk010126)
|
||||
|
||||
@@ -0,0 +1,175 @@
|
||||
Name
|
||||
|
||||
WL_bind_wayland_display
|
||||
|
||||
Name Strings
|
||||
|
||||
EGL_WL_bind_wayland_display
|
||||
|
||||
Contact
|
||||
|
||||
Kristian Høgsberg <krh@bitplanet.net>
|
||||
Benjamin Franzke <benjaminfranzke@googlemail.com>
|
||||
|
||||
Status
|
||||
|
||||
Proposal
|
||||
|
||||
Version
|
||||
|
||||
Version 1, March 1, 2011
|
||||
|
||||
Number
|
||||
|
||||
EGL Extension #not assigned
|
||||
|
||||
Dependencies
|
||||
|
||||
Requires EGL 1.4 or later. This extension is written against the
|
||||
wording of the EGL 1.4 specification.
|
||||
|
||||
EGL_KHR_base_image is required.
|
||||
|
||||
Overview
|
||||
|
||||
This extension provides entry points for binding and unbinding the
|
||||
wl_display of a Wayland compositor to an EGLDisplay. Binding a
|
||||
wl_display means that the EGL implementation should provide one or
|
||||
more interfaces in the Wayland protocol to allow clients to create
|
||||
wl_buffer objects. On the server side, this extension also
|
||||
provides a new target for eglCreateImageKHR, to create an EGLImage
|
||||
from a wl_buffer
|
||||
|
||||
Adding an implementation specific wayland interface, allows the
|
||||
EGL implementation to define specific wayland requests and events,
|
||||
needed for buffer sharing in an EGL wayland platform.
|
||||
|
||||
IP Status
|
||||
|
||||
Open-source; freely implementable.
|
||||
|
||||
New Procedures and Functions
|
||||
|
||||
EGLBoolean eglBindWaylandDisplayWL(EGLDisplay dpy,
|
||||
struct wl_display *display);
|
||||
|
||||
EGLBoolean eglUnbindWaylandDisplayWL(EGLDisplay dpy,
|
||||
struct wl_display *display);
|
||||
|
||||
EGLBoolean eglQueryWaylandBufferWL(EGLDisplay dpy,
|
||||
struct wl_buffer *buffer,
|
||||
EGLint attribute, EGLint *value);
|
||||
|
||||
New Tokens
|
||||
|
||||
Accepted as <target> in eglCreateImageKHR
|
||||
|
||||
EGL_WAYLAND_BUFFER_WL 0x31D5
|
||||
|
||||
Accepted in the <attrib_list> parameter of eglCreateImageKHR:
|
||||
|
||||
EGL_WAYLAND_PLANE_WL 0x31D6
|
||||
|
||||
Possible values for EGL_TEXTURE_FORMAT:
|
||||
|
||||
EGL_TEXTURE_Y_U_V_WL 0x31D7
|
||||
EGL_TEXTURE_Y_UV_WL 0x31D8
|
||||
EGL_TEXTURE_Y_XUXV_WL 0x31D9
|
||||
|
||||
|
||||
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.
|
||||
|
||||
A wl_buffer can have several planes, typically in case of planar
|
||||
YUV formats. Depending on the exact YUV format in use, the
|
||||
compositor will have to create one or more EGLImages for the
|
||||
various planes. The eglQueryWaylandBufferWL function should be
|
||||
used to first query the wl_buffer texture format using
|
||||
EGL_TEXTURE_FORMAT as the attribute. If the wl_buffer object is
|
||||
not an EGL wl_buffer (wl_shm and other wayland extensions can
|
||||
create wl_buffer objects of different types), this query will
|
||||
return EGL_FALSE. In that case the wl_buffer can not be used with
|
||||
EGL and the compositor should have another way to get the buffer
|
||||
contents.
|
||||
|
||||
If eglQueryWaylandBufferWL succeeds, the returned value will be
|
||||
one of EGL_TEXTURE_RGB, EGL_TEXTURE_RGBA, EGL_TEXTURE_Y_U_V_WL,
|
||||
EGL_TEXTURE_Y_UV_WL, EGL_TEXTURE_Y_XUXV_WL. The value returned
|
||||
describes how many EGLImages must be used, which components will
|
||||
be sampled from each EGLImage and how they map to rgba components
|
||||
in the shader. The naming conventions separates planes by _ and
|
||||
within each plane, the order or R, G, B, A, Y, U, and V indicates
|
||||
how those components map to the rgba value returned by the
|
||||
sampler. X indicates that the corresponding component in the rgba
|
||||
value isn't used.
|
||||
|
||||
RGB and RGBA buffer types:
|
||||
|
||||
EGL_TEXTURE_RGB
|
||||
One plane, samples RGB from the texture to rgb in the
|
||||
shader. Alpha channel is not valid.
|
||||
|
||||
EGL_TEXTURE_RGBA
|
||||
One plane, samples RGBA from the texture to rgba in the
|
||||
shader.
|
||||
|
||||
YUV buffer types:
|
||||
|
||||
EGL_TEXTURE_Y_U_V_WL
|
||||
Three planes, samples Y from the first plane to r in
|
||||
the shader, U from the second plane to r, and V from
|
||||
the third plane to r.
|
||||
|
||||
EGL_TEXTURE_Y_UV_WL
|
||||
Two planes, samples Y from the first plane to r in
|
||||
the shader, U and V from the second plane to rg.
|
||||
|
||||
EGL_TEXTURE_Y_XUXV_WL
|
||||
Two planes, samples Y from the first plane to r in
|
||||
the shader, U and V from the second plane to g and a.
|
||||
|
||||
After querying the wl_buffer layout, create EGLImages for the
|
||||
planes by calling eglCreateImageKHR with wl_buffer as
|
||||
EGLClientBuffer, EGL_WAYLAND_BUFFER_WL as the target, NULL
|
||||
context. If no attributes are given, an EGLImage will be created
|
||||
for the first plane. For multi-planar buffers, specify the plane
|
||||
to create the EGLImage for by using the EGL_WAYLAND_PLANE_WL
|
||||
attribute. The value of the attribute is the index of the plane,
|
||||
as defined by the buffer format. Writing to an EGLImage created
|
||||
from a wl_buffer in any way (such as glTexImage2D, binding the
|
||||
EGLImage as a renderbuffer etc) will result in undefined behavior.
|
||||
|
||||
Further, eglQueryWaylandBufferWL accepts attributes EGL_WIDTH and
|
||||
EGL_HEIGHT to query the width and height of the wl_buffer.
|
||||
|
||||
Issues
|
||||
|
||||
Revision History
|
||||
|
||||
Version 1, March 1, 2011
|
||||
Initial draft (Benjamin Franzke)
|
||||
Version 2, July 5, 2012
|
||||
Add EGL_WAYLAND_PLANE_WL attribute to allow creating an EGLImage
|
||||
for different planes of planar buffer. (Kristian Høgsberg)
|
||||
Version 3, July 10, 2012
|
||||
Add eglQueryWaylandBufferWL and the various buffer
|
||||
formats. (Kristian Høgsberg)
|
||||
Version 4, July 19, 2012
|
||||
Use EGL_TEXTURE_FORMAT, EGL_TEXTURE_RGB, and EGL_TEXTURE_RGBA,
|
||||
and just define the new YUV texture formats. Add support for
|
||||
EGL_WIDTH and EGL_HEIGHT in the query attributes (Kristian Høgsberg)
|
||||
@@ -0,0 +1,57 @@
|
||||
|
||||
See the OpenGL ARB enum registry at http://www.opengl.org/registry/api/enum.spec
|
||||
|
||||
Blocks allocated to Mesa:
|
||||
0x8750-0x875F
|
||||
0x8BB0-0x8BBF
|
||||
|
||||
|
||||
GL_MESA_packed_depth_stencil
|
||||
GL_DEPTH_STENCIL_MESA 0x8750
|
||||
GL_UNSIGNED_INT_24_8_MESA 0x8751
|
||||
GL_UNSIGNED_INT_8_24_REV_MESA 0x8752
|
||||
GL_UNSIGNED_SHORT_15_1_MESA 0x8753
|
||||
GL_UNSIGNED_SHORT_1_15_REV_MESA 0x8754
|
||||
|
||||
GL_MESA_trace.spec:
|
||||
GL_TRACE_ALL_BITS_MESA 0xFFFF
|
||||
GL_TRACE_OPERATIONS_BIT_MESA 0x0001
|
||||
GL_TRACE_PRIMITIVES_BIT_MESA 0x0002
|
||||
GL_TRACE_ARRAYS_BIT_MESA 0x0004
|
||||
GL_TRACE_TEXTURES_BIT_MESA 0x0008
|
||||
GL_TRACE_PIXELS_BIT_MESA 0x0010
|
||||
GL_TRACE_ERRORS_BIT_MESA 0x0020
|
||||
GL_TRACE_MASK_MESA 0x8755
|
||||
GL_TRACE_NAME_MESA 0x8756
|
||||
|
||||
MESA_ycbcr_texture.spec:
|
||||
GL_YCBCR_MESA 0x8757
|
||||
GL_UNSIGNED_SHORT_8_8_MESA 0x85BA /* same as Apple's */
|
||||
GL_UNSIGNED_SHORT_8_8_REV_MESA 0x85BB /* same as Apple's */
|
||||
|
||||
GL_MESA_pack_invert.spec
|
||||
GL_PACK_INVERT_MESA 0x8758
|
||||
|
||||
GL_MESA_shader_debug.spec: (obsolete)
|
||||
GL_DEBUG_OBJECT_MESA 0x8759
|
||||
GL_DEBUG_PRINT_MESA 0x875A
|
||||
GL_DEBUG_ASSERT_MESA 0x875B
|
||||
|
||||
GL_MESA_program_debug.spec: (obsolete)
|
||||
GL_FRAGMENT_PROGRAM_CALLBACK_MESA 0x????
|
||||
GL_VERTEX_PROGRAM_CALLBACK_MESA 0x????
|
||||
GL_FRAGMENT_PROGRAM_POSITION_MESA 0x????
|
||||
GL_VERTEX_PROGRAM_POSITION_MESA 0x????
|
||||
GL_FRAGMENT_PROGRAM_CALLBACK_FUNC_MESA 0x????
|
||||
GL_FRAGMENT_PROGRAM_CALLBACK_DATA_MESA 0x????
|
||||
GL_VERTEX_PROGRAM_CALLBACK_FUNC_MESA 0x????
|
||||
GL_VERTEX_PROGRAM_CALLBACK_DATA_MESA 0x????
|
||||
|
||||
GL_MESAX_texture_stack:
|
||||
GL_TEXTURE_1D_STACK_MESAX 0x8759
|
||||
GL_TEXTURE_2D_STACK_MESAX 0x875A
|
||||
GL_PROXY_TEXTURE_1D_STACK_MESAX 0x875B
|
||||
GL_PROXY_TEXTURE_2D_STACK_MESAX 0x875C
|
||||
GL_TEXTURE_1D_STACK_BINDING_MESAX 0x875D
|
||||
GL_TEXTURE_2D_STACK_BINDING_MESAX 0x875E
|
||||
|
||||
Reference in New Issue
Block a user