mirror of
https://github.com/elwrcl/intel-hard-graphics.git
synced 2026-11-01 03:18:02 +03:00
init
This commit is contained in:
12511 files changed
+6156641
No files matched your search
@@ -0,0 +1,564 @@
|
||||
Name
|
||||
|
||||
MESA_screen_surface
|
||||
|
||||
Name Strings
|
||||
|
||||
EGL_MESA_screen_surface
|
||||
|
||||
Contact
|
||||
|
||||
Brian Paul
|
||||
|
||||
To discuss, join the [email protected] list.
|
||||
|
||||
Status
|
||||
|
||||
Obsolete.
|
||||
|
||||
Version
|
||||
|
||||
11 (27 January 2006)
|
||||
|
||||
Number
|
||||
|
||||
TBD
|
||||
|
||||
Dependencies
|
||||
|
||||
EGL 1.0 or later.
|
||||
|
||||
Overview
|
||||
|
||||
EGL 1.1 supports three types of drawing surfaces:
|
||||
* Window surfaces
|
||||
* Pixmap surfaces
|
||||
* Pbuffer surfaces
|
||||
This extension defines a fourth type of drawing surface:
|
||||
* Screen surface
|
||||
|
||||
A screen surface is a surface for which the (front) color buffer can
|
||||
be directly displayed (i.e. scanned out) on a monitor (such as a flat
|
||||
panel or CRT). In particular the color buffer memory will be allocated
|
||||
at a location in VRAM (and in a suitable format) which can be displayed
|
||||
by the graphics hardware.
|
||||
|
||||
Note that the width and height of the screen surface need not exactly
|
||||
match the monitor's current resolution. For example, while the monitor
|
||||
may be configured to to show 1024x768 pixels, the associated screen
|
||||
surface may be larger, such as 1200x1000. The "screen origin" attribute
|
||||
will specify which region of the screen surface which is visible on the
|
||||
monitor. The screen surface can be scrolled by changing this origin.
|
||||
|
||||
This extension also defines functions for controlling the monitor's
|
||||
display mode (width, height, refresh rate, etc), and specifying which
|
||||
screen surface is to be displayed on a monitor.
|
||||
|
||||
The new EGLModeMESA type and related functions are very similar to the
|
||||
EGLConfig type and related functions. The user may get a list of
|
||||
supported modes for a screen and specify the mode to be used when
|
||||
displaying a screen surface.
|
||||
|
||||
|
||||
Issues
|
||||
|
||||
1. Should EGL_INTERLACE be a supported mode attribute?
|
||||
|
||||
Arguments against:
|
||||
|
||||
No, this should be provided by another extension which would
|
||||
also provide the mechanisms needed to play back interlaced video
|
||||
material correctly on hardware that supports it.
|
||||
This extension should prefer non-interlaced modes. [M. Danzer]
|
||||
|
||||
Arguments for:
|
||||
|
||||
An interlaced display can be of use without considering video
|
||||
material. Being able to query whether a screen is operating in
|
||||
interlaced mode can be used by applications to control their
|
||||
drawing. For example: avoid drawing 1-pixel-wide horizontal lines
|
||||
if screen is interlaced. [B. Paul]
|
||||
|
||||
Resolution: Defer for future extension?
|
||||
|
||||
|
||||
2. Should EGL_REFRESH_RATE be a supported mode attribute?
|
||||
|
||||
Arguments for:
|
||||
|
||||
Yes, it's been shown that applications and/or users need to select
|
||||
modes by this. [M. Danzer]
|
||||
|
||||
Many examples have been given in which it's desirable to let the
|
||||
user choose from a variety of refresh rates without having to
|
||||
restart/reconfigure. [B. Paul]
|
||||
|
||||
Arguments against:
|
||||
|
||||
TBD.
|
||||
|
||||
Resolution: Yes.
|
||||
|
||||
|
||||
3. Exactly how should the list of modes returned by eglChooseConfigMESA
|
||||
be sorted?
|
||||
|
||||
Current method is described in the text below. Subject to change.
|
||||
|
||||
Alternately, leave the sorting order undefined so that each
|
||||
implementation can return the modes in order of "most desirable"
|
||||
to "least desirable" which may depend on the display technology
|
||||
(CRT vs LCD, etc) or other factors.
|
||||
|
||||
|
||||
4. How should screen blanking be supported? Note that a screen can be
|
||||
disabled or turned off by calling eglShowSurface(dpy, scrn,
|
||||
EGL_NO_SURFACE, EGL_NO_MODE_MESA). But what about power-save mode?
|
||||
|
||||
I would defer this to other extensions that depend on this one.
|
||||
I can imagine people wanting different semantics not just in
|
||||
relation to the power management API being exposed (DPMS or whatever)
|
||||
but also relating to what events can trigger EGL_CONTEXT_LOST. Also
|
||||
I'm not sure whether power management commands are properly operations
|
||||
on the Display or on a screen surface. [A. Jackson]
|
||||
|
||||
|
||||
5. Should the EGL_PHYSICAL_SIZE_EGL query be kept? The size information
|
||||
isn't always reliable (consider video projectors) but can still be
|
||||
used to determine the pixel aspect ratio.
|
||||
|
||||
Resolution: Omit. The EGL 1.2 specification includes queries for
|
||||
the display resolution and pixel aspect ratio.
|
||||
|
||||
|
||||
6. Should detailed mode timing information be exposed by this API?
|
||||
|
||||
Probably not. Instead, offer that information in a layered extension.
|
||||
|
||||
|
||||
7. How should the notion of a screen's "native" mode be expressed?
|
||||
For example, LCD panels have a native resolution and refresh rate
|
||||
that looks best but other sub-optimal resolutions may be supported.
|
||||
|
||||
The mode attribute EGL_OPTIMAL_MESA will be set for modes which
|
||||
best match the screen. [M. Danzer]
|
||||
|
||||
|
||||
8. Should eglQueryModeStringMESA() be included? This function returns
|
||||
a human-readable string which corresponds to an EGLMode.
|
||||
|
||||
Arguments for:
|
||||
|
||||
A mode name such as "HDTV-720P" might mean more to users than
|
||||
"1280x720@60Hz" if the later were generated via code.
|
||||
|
||||
Arguments against:
|
||||
|
||||
There's no standard syntax for the strings. May cause more
|
||||
trouble than it's worth.
|
||||
|
||||
Postpone for future extension. [A. Jackson]
|
||||
|
||||
Latest discussion leaning toward omitting this function.
|
||||
|
||||
|
||||
9. Should we use "Get" or "Query" for functions which return state?
|
||||
The EGL 1.x specification doesn't seem to be totally consistent
|
||||
in this regard, but "Query" is used more often.
|
||||
|
||||
Use "Get" for mode-related queries (as for EGLConfigs) but "Query"
|
||||
for everything else.
|
||||
|
||||
|
||||
10. What should be the default size for screen surfaces?
|
||||
|
||||
For Pbuffer surfaces the default width and height are zero.
|
||||
We'll do the same for screen surfaces. Since there's no function
|
||||
to resize surfaces it's useless to have a 0x0 screen, but this isn't
|
||||
a situation that'll normally be encountered.
|
||||
|
||||
|
||||
11. Should there be a function for resizing a screen surface?
|
||||
|
||||
Suppose one wants to change the screen's size in the EGL application.
|
||||
Also suppose there's a hardware restriction such that only one screen
|
||||
surface can exist at a time (either for lack of memory or because of
|
||||
memory layout restrictions).
|
||||
|
||||
The basic idea is that the currently displayed screen surface must
|
||||
be deallocated before a new one can be created. Perhaps a resize
|
||||
function would work better?
|
||||
|
||||
|
||||
12. How should sub-pixel LCD color information be made available?
|
||||
What about the display's gamma value?
|
||||
|
||||
Perhaps expose as additional read-only mode attributes.
|
||||
|
||||
Perhaps postpone for a layered extension.
|
||||
|
||||
|
||||
13. What happens if the user attempts to delete a screen surface that
|
||||
is currently being shown?
|
||||
|
||||
Spec currently says that's illegal and that an error (TBD) will be
|
||||
generated.
|
||||
|
||||
|
||||
14. What if the physical screen size can't be determined? Should
|
||||
a query of EGL_PHYSICAL_SIZE_MESA return [0,0]?
|
||||
|
||||
Obsolete: EGL_PHYSICAL_SIZE_MESA not used.
|
||||
|
||||
|
||||
15. Suppose the device's number of RAMDACs is different from the
|
||||
number of output ports. For example, a graphics card with
|
||||
two RAMDACs but three ports (VGA, DVI, TV).
|
||||
|
||||
Address this in a follow-on extension. [Matthias Hopf]
|
||||
|
||||
|
||||
16. How should we deal with on-the-fly device changes? For example,
|
||||
the monitor being unplugged and replaced by another with different
|
||||
characteristics?
|
||||
|
||||
A HAL event could be received via DBUS in the application [J. Smirl,
|
||||
A. Jackson].
|
||||
|
||||
Should there be an EGL mechanism for detecting this? Maybe an
|
||||
EGL_SCREEN_LOST error (similar to EGL_CONTEXT_LOST) can be recorded
|
||||
when there's a screen change. At least then the application can
|
||||
poll to detect this situation.
|
||||
|
||||
Maybe leave that to a future extension.
|
||||
|
||||
See also the EGL_SCREEN_COUNT_MESA query.
|
||||
|
||||
|
||||
17. What if pixel-accurate panning is not supported (see
|
||||
eglScreenPositionMESA)? [M. Danzer]
|
||||
|
||||
Is this a common problem? Can we ignore it for now?
|
||||
|
||||
|
||||
18. Should eglShowSurfaceMESA be renamed to eglShowScreenSurfaceMESA?
|
||||
|
||||
Probably.
|
||||
|
||||
|
||||
|
||||
New Procedures and Functions
|
||||
|
||||
EGLBoolean eglChooseModeMESA(EGLDisplay dpy, EGLScreenMESA screen,
|
||||
const EGLint *attrib_list,
|
||||
EGLModeMESA *modes, EGLint modes_size,
|
||||
EGLint *num_modes)
|
||||
|
||||
EGLBoolean eglGetModesMESA(EGLDisplay dpy, EGLScreenMESA screen,
|
||||
EGLModeMESA *modes, EGLint modes_size,
|
||||
EGLint *num_modes)
|
||||
|
||||
EGLBoolean eglGetModeAttribMESA(EGLDisplay dpy, EGLModeMESA mode,
|
||||
EGLint attrib, EGLint *value)
|
||||
|
||||
|
||||
EGLBoolean eglGetScreensMESA(EGLDisplay dpy, EGLScreenMESA *screens,
|
||||
EGLint screens_size, EGLint *num_screens)
|
||||
|
||||
EGLSurface eglCreateScreenSurfaceMESA(EGLDisplay dpy, EGLConfig config,
|
||||
const EGLint *attrib_list)
|
||||
|
||||
EGLBoolean eglShowSurfaceMESA(EGLDisplay dpy, EGLScreenMESA screen,
|
||||
EGLSurface surface, EGLModeMESA mode)
|
||||
|
||||
EGLBoolean eglScreenPositionMESA(EGLDisplay dpy, EGLScreenMESA screen,
|
||||
EGLint x, EGLint y)
|
||||
|
||||
|
||||
EGLBoolean eglQueryScreenMESA(EGLDisplay dpy, EGLScreenMESA screen,
|
||||
EGLint attrib, EGLint *value);
|
||||
|
||||
EGLBoolean eglQueryScreenSurfaceMESA(EGLDisplay dpy, EGLScreenMESA screen,
|
||||
EGLSurface *surface)
|
||||
|
||||
EGLBoolean eglQueryScreenModeMESA(EGLDisplay dpy, EGLScreenMESA screen,
|
||||
EGLModeMESA *mode)
|
||||
|
||||
const char *eglQueryModeStringMESA(EGLDisplay dpy, EGLMode mode);
|
||||
|
||||
|
||||
New Types
|
||||
|
||||
EGLModeMESA
|
||||
EGLScreenMESA
|
||||
|
||||
New Tokens
|
||||
|
||||
New error codes:
|
||||
|
||||
EGL_BAD_SCREEN_MESA
|
||||
EGL_BAD_MODE_MESA
|
||||
|
||||
Screen-related tokens:
|
||||
|
||||
EGL_SCREEN_COUNT_MESA
|
||||
EGL_SCREEN_POSITION_MESA
|
||||
EGL_SCREEN_BIT_MESA
|
||||
EGL_SCREEN_POSITION_GRANULARITY_MESA
|
||||
|
||||
Mode-related tokens:
|
||||
|
||||
EGL_MODE_ID_MESA
|
||||
EGL_REFRESH_RATE_MESA
|
||||
EGL_INTERLACED_MESA
|
||||
EGL_OPTIMAL_MESA
|
||||
EGL_NO_MODE_MESA
|
||||
|
||||
|
||||
Additions to Chapter X of the EGL 1.1 Specification
|
||||
|
||||
[XXX this all has to be rewritten to fit into the EGL specification
|
||||
and match the conventions of an EGL extension. For now, just list
|
||||
all the functions with brief descriptions.]
|
||||
|
||||
|
||||
EGLBoolean eglChooseModeMESA(EGLDisplay dpy, const EGLScreenMESA screen,
|
||||
EGLint *attrib_list, EGLModeMESA *modes,
|
||||
EGLint modes_size, EGLint *num_modes)
|
||||
|
||||
Like eglChooseConfig, returns a list of EGLModes which match the given
|
||||
attribute list. This does not set the screen's current display mode.
|
||||
The attribute list is a list of token/value pairs terminated with
|
||||
EGL_NONE. Supported attributes include:
|
||||
|
||||
Name Description
|
||||
--------------------- ---------------------------------------------
|
||||
EGL_WIDTH Mode width (resolution)
|
||||
EGL_HEIGHT Mode height (resolution)
|
||||
EGL_REFRESH_RATE_MESA The mode's refresh rate, multiplied by 1000
|
||||
EGL_INTERLACED_MESA 1 indicates an interlaced mode, 0 otherwise
|
||||
EGL_OPTIMAL_MESA Set if the most is especially optimal for the
|
||||
screen (ex. for particular LCD resolutions)
|
||||
|
||||
Any other token will generate the error EGL_BAD_ATTRIBUTE.
|
||||
|
||||
The list of modes returned by eglChooseModeMESA will be sorted
|
||||
according to the following criteria. See the discussion of table 3.3
|
||||
in the EGL specification for more information.
|
||||
|
||||
Selection Sort Sort
|
||||
Attribute Default Criteria Order Priority
|
||||
-------------------- -------------- ----------- ------ --------
|
||||
EGL_OPTIMAL_MESA EGL_DONT_CARE Exact 1,0 1
|
||||
EGL_INTERLACED_MESA EGL_DONT_CARE Exact 0,1 2
|
||||
EGL_REFRESH_RATE EGL_DONT_CARE AtLeast Larger 3
|
||||
EGL_WIDTH EGL_DONT_CARE AtLeast Larger 4
|
||||
EGL_HEIGHT EGL_DONT_CARE AtLeast Larger 5
|
||||
EGL_MODE_ID_MESA EGL_DONT_CARE Exact Smaller 6
|
||||
|
||||
|
||||
EGLBoolean eglGetModesMESA(EGLDisplay dpy, EGLScreenMESA screen,
|
||||
EGLModeMESA *modes, EGLint modes_size,
|
||||
EGLint *num_modes)
|
||||
|
||||
Like eglGetConfigs, returns a list of all modes supported by the
|
||||
given screen. The returned modes will be sorted in the same manner
|
||||
as for eglChooseModeMESA().
|
||||
|
||||
|
||||
|
||||
EGLBoolean eglGetModeAttribMESA(EGLDisplay dpy, EGLModeMESA mode,
|
||||
EGLint attrib, EGLint *value)
|
||||
|
||||
Used to query mode attributes. The following attributes are supported:
|
||||
|
||||
Name Return value description
|
||||
--------------------- ----------------------------------------------
|
||||
EGL_OPTIMAL_MESA 1 indicates an optimal mode, 0 otherwise
|
||||
EGL_INTERLACED_MESA 1 indicates an interlaced mode, 0 otherwise
|
||||
EGL_REFRESH_RATE_MESA The mode's refresh rate, multiplied by 1000
|
||||
EGL_WIDTH Mode width (resolution)
|
||||
EGL_HEIGHT Mode height (resolution)
|
||||
EGL_MODE_ID_MESA A unique small integer identifier for the mode
|
||||
|
||||
Any other token will generate the error EGL_BAD_ATTRIBUTE.
|
||||
|
||||
|
||||
|
||||
EGLBoolean eglGetScreensMESA(EGLDisplay dpy, EGLScreenMESA *screens,
|
||||
EGLint screens_size, EGLint *num_screens)
|
||||
|
||||
This function returns an array of all available screen handles.
|
||||
<screens_size> is the maximum number of screens to return in the
|
||||
<screens> array. <num_screens> will return the number of screen handles
|
||||
placed in the array, even if <screens> is NULL.
|
||||
|
||||
The number of screens and the availability of each may change over
|
||||
time (hot-plugging). Screen handles will not be reused. When a
|
||||
screen handle becomes invalid, function calls which reference an
|
||||
invalid handle will generate EGL_BAD_SCREEN_MESA.
|
||||
|
||||
The first screen handle returned will be considered to be the primary
|
||||
one.
|
||||
|
||||
|
||||
|
||||
EGLSurface eglCreateScreenSurfaceMESA(EGLDisplay dpy, EGLConfig config,
|
||||
const EGLint *attrib_list)
|
||||
|
||||
Create a surface that can be displayed on a screen. <attrib_list> is
|
||||
an array of token/value pairs terminated with EGL_NONE. Valid tokens
|
||||
include:
|
||||
|
||||
Name Description
|
||||
---------------- --------------------------------
|
||||
EGL_WIDTH desired surface width in pixels
|
||||
EGL_HEIGHT desired surface height in pixels
|
||||
|
||||
Any other token will generate the error EGL_BAD_ATTRIBUTE.
|
||||
The default width and height are zero.
|
||||
|
||||
|
||||
|
||||
EGLBoolean eglShowSurfaceMESA(EGLDisplay dpy, EGLScreenMESA screen,
|
||||
EGLSurface surface, EGLModeMESA mode)
|
||||
|
||||
This function causes a screen to show the given surface (or more
|
||||
precisely, the surface's front color buffer) with the given mode.
|
||||
|
||||
If the surface is in any way incompatible with the mode, the error
|
||||
EGL_BAD_MATCH will be generated, EGL_FALSE will be returned, and the
|
||||
previous screen state will remain in effect. This might occur when
|
||||
the bandwidth of the video-out subsystem is exceeded, or if the mode
|
||||
specifies a width or height that's greater than the width or height
|
||||
of the surface.
|
||||
|
||||
To disable a screen, the values EGL_NO_SURFACE and EGL_NO_MODE_MESA
|
||||
be passed as the <surface> and <mode> parameters.
|
||||
|
||||
The values of EGL_SCREEN_POSITION_MESA are clamped to the new valid
|
||||
range computed from the screen size and surface size. If the new
|
||||
surface is EGL_NO_SURFACE, EGL_SCREEN_POSITION_MESA is set to [0, 0].
|
||||
|
||||
|
||||
Attempting to delete a screen surface which is currently being
|
||||
displayed will result in the error EGL_BAD_ACCESS being generated.
|
||||
|
||||
|
||||
|
||||
EGLBoolean eglScreenPositionMESA(EGLDisplay dpy, EGLScreenMESA screen,
|
||||
EGLint x, EGLint y)
|
||||
|
||||
Specifies the origin of the screen's view into the surface, if the
|
||||
surface is larger than the screen. Valid values for x and y are
|
||||
[0, surfaceWidth - screenWidth] and [0, surfaceHeight - screenHeight],
|
||||
respectively.
|
||||
|
||||
The x and y values are also constrained to be integer multiples of the
|
||||
EGL_SCREEN_POSITION_GRANULARITY_MESA values.
|
||||
|
||||
|
||||
|
||||
|
||||
EGLBoolean eglQueryScreenMESA(EGLDisplay dpy, EGLScreenMESA screen,
|
||||
EGLint attrib, EGLint *value);
|
||||
|
||||
Used to query screen attributes. <attrib> may be one of the following:
|
||||
|
||||
Name Return value description
|
||||
------------------------ ---------------------------------------------
|
||||
EGL_SCREEN_POSITION_MESA x, y position of the screen's origin with
|
||||
respect to the surface. If no surface is
|
||||
attached to the screen, [0, 0] is returned.
|
||||
EGL_SCREEN_POSITION_GRANULARITY_MESA
|
||||
Returns the granularity, in pixels, for
|
||||
which the screen position is constrained.
|
||||
|
||||
Any other token will generate the error EGL_BAD_ATTRIBUTE.
|
||||
|
||||
|
||||
|
||||
|
||||
EGLBoolean eglQueryScreenSurfaceMESA(EGLDisplay dpy, EGLScreenMESA screen,
|
||||
EGLSurface *surface)
|
||||
|
||||
Returns the surface currently displayed on the given screen. <surface>
|
||||
may be EGL_NO_SURFACE if the screen isn't currently showing any surface.
|
||||
|
||||
|
||||
|
||||
|
||||
EGLBoolean eglQueryScreenModeMESA(EGLDisplay dpy, EGLScreenMESA screen,
|
||||
EGLModeMESA *mode)
|
||||
|
||||
Returns the given screen's current display mode. The mode may be
|
||||
EGL_NO_MODE_MESA if the screen is currently disabled.
|
||||
|
||||
|
||||
|
||||
const char *eglQueryModeStringMESA(EGLDisplay dpy, EGLModeMESA mode);
|
||||
|
||||
Returns a human-readable string for the given mode. The string is a
|
||||
zero-terminated C string which the user should not attempt to free.
|
||||
There is no standard syntax for mode strings. Applications should
|
||||
not directly rely on mode strings.
|
||||
|
||||
|
||||
|
||||
Version History
|
||||
|
||||
1. 15 March 2005 - BrianP
|
||||
Initial version
|
||||
|
||||
2. 16 March 2005 - BrianP
|
||||
Removed EGL_DEPTH_MESA
|
||||
Added EGL_PHYSICAL_WIDTH_MESA, EGL_PHYSICAL_HEIGHT_MESA queries
|
||||
Added EGL_OPTIMAL_MESA for width/height/refresh rate selection
|
||||
Added possible eglQueryModeStringMESA() function
|
||||
More details of the new functions explained.
|
||||
|
||||
3. 18 March 2005 - BrianP
|
||||
Added screen_number to eglChooseModeMESA().
|
||||
Fix off by one mistake in value range for ORIGIN attributes
|
||||
Added Issues section
|
||||
|
||||
4. 21 March 2005 - BrianP
|
||||
Removed eglScreenAttribsMESA().
|
||||
Added eglScreenPositionMESA() to set screen origin.
|
||||
Replaced EGL_SCREEN_X/Y_OFFSET_MESA with EGL_SCREEN_POSITION_MESA.
|
||||
Replaced EGL_PHYSICAL_WIDTH/HEIGHT_MESA with EGL_PHYSICAL_SIZE_MESA.
|
||||
Use EGL_OPTIMAL_MESA as a new mode attribute. (Michel Danzer)
|
||||
Added a few more issues.
|
||||
|
||||
5. 6 April 2005 - BrianP
|
||||
More language for eglGetModeStringMESA().
|
||||
Added issues 10, 11, 12, 13, 14.
|
||||
Updated issue 3 discussion about mode sorting.
|
||||
|
||||
6. 22 April 2005 - BrianP
|
||||
Fixed "LDC" typo.
|
||||
Added issues 15, 16.
|
||||
Changed dependency on EGL 1.1 to EGL 1.0
|
||||
s/EGL_NUM_SCREENS_MESA/EGL_SCREEN_COUNT_MESA/
|
||||
Added eglQueryDisplayMESA() to New Functions section.
|
||||
Clarified language for the EGL_SCREEN_COUNT_MESA query.
|
||||
|
||||
7. 29 April 2005 - BrianP
|
||||
Added EGLScreenMESA type and eglGetScreensMESA() function. [J. Smirl].
|
||||
Replaced EGLint screen_number parameters with EGLScreenMESA screen.
|
||||
Added issue 17 (pixel-accurate panning)
|
||||
|
||||
8. 2 May 2005 - BrianP
|
||||
Removed eglQueryDisplayMESA.
|
||||
Fixed a few more EGLint -> EGLScreenMESA changes.
|
||||
|
||||
9. 20 May 2005 - BrianP
|
||||
Fixed a few typos.
|
||||
Updated some open issues text.
|
||||
|
||||
10. 10 August 2005 - BrianP
|
||||
Added EGL_SCREEN_POSITION_GRANULARITY_MESA.
|
||||
|
||||
11. 27 January 2006 - BrianP
|
||||
EGL_PHYSICAL_SIZE_MESA removed since EGL 1.2 has a similar feature.
|
||||
|
||||
@@ -0,0 +1,94 @@
|
||||
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
|
||||
|
||||
Obsolete. Effectively superseded by ARB_vertex_buffer_object.
|
||||
|
||||
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,158 @@
|
||||
Name
|
||||
|
||||
MESA_multithread_makecurrent
|
||||
|
||||
Name Strings
|
||||
|
||||
GLX_MESA_multithread_makecurrent
|
||||
|
||||
Contact
|
||||
|
||||
Eric Anholt ([email protected])
|
||||
|
||||
Status
|
||||
|
||||
Obsolete.
|
||||
|
||||
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 through 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,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
|
||||
|
||||
Obsolete.
|
||||
|
||||
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 0x8bb5
|
||||
|
||||
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,81 @@
|
||||
Name
|
||||
|
||||
MESA_resize_buffers
|
||||
|
||||
Name Strings
|
||||
|
||||
GL_MESA_resize_buffers
|
||||
|
||||
Contact
|
||||
|
||||
Brian Paul (brian.paul 'at' tungstengraphics.com)
|
||||
|
||||
Status
|
||||
|
||||
Obsolete.
|
||||
|
||||
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
|
||||
|
||||
Obsolete.
|
||||
|
||||
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,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,201 @@
|
||||
Name
|
||||
|
||||
MESA_swap_frame_usage
|
||||
|
||||
Name Strings
|
||||
|
||||
GLX_MESA_swap_frame_usage
|
||||
|
||||
Contact
|
||||
|
||||
Ian Romanick, IBM, idr at us.ibm.com
|
||||
|
||||
Status
|
||||
|
||||
Obsolete.
|
||||
|
||||
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
|
||||
|
||||
DEPRECATED - Support removed in Mesa 10.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:
|
||||
|
||||
https://www.opengl.org/discussion_boards/cgi_directory/ultimatebb.cgi?ubb=get_topic;f=3;t=011557
|
||||
https://www.opengl.org/discussion_boards/cgi_directory/ultimatebb.cgi?ubb=get_topic;f=3;t=000516
|
||||
https://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,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 explicitly 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 occurrences 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 wherever 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)
|
||||
|
||||
Reference in new issue
Block a user