docs: include specs into the generated docs
Unfortunately, it doesn't seem like there's a way to have sphinx copy this without moving the files, becasue html_extra_path doesn't copy the directory itself when given a directory, only files inside and subdirectories. Reviewed-by: Eric Engestrom <eric@engestrom.ch> Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/4630>
This commit is contained in:
Erik Faye-Lund
committed by
Marge Bot
Marge Bot
parent
dd3add1b19
commit
381fc0eca5
@@ -0,0 +1,82 @@
|
||||
Name
|
||||
|
||||
MESA_device_software
|
||||
|
||||
Name Strings
|
||||
|
||||
EGL_MESA_device_software
|
||||
|
||||
Contributors
|
||||
|
||||
Adam Jackson <ajax@redhat.com>
|
||||
Emil Velikov <emil.velikov@collabora.com>
|
||||
|
||||
Contacts
|
||||
|
||||
Adam Jackson <ajax@redhat.com>
|
||||
|
||||
Status
|
||||
|
||||
DRAFT
|
||||
|
||||
Version
|
||||
|
||||
Version 2, 2018-10-03
|
||||
|
||||
Number
|
||||
|
||||
EGL Extension #TODO
|
||||
|
||||
Extension Type
|
||||
|
||||
EGL device extension
|
||||
|
||||
Dependencies
|
||||
|
||||
Requires EGL_EXT_device_query.
|
||||
|
||||
This extension is written against the EGL 1.5 Specification.
|
||||
|
||||
Overview
|
||||
|
||||
This extension defines a software EGL "device". The device is not backed by
|
||||
any actual device node and simply renders into client memory.
|
||||
|
||||
By defining this as an extension, EGL_EXT_device_enumeration is able to
|
||||
sanely enumerate a software device.
|
||||
|
||||
New Types
|
||||
|
||||
None
|
||||
|
||||
New Procedures and Functions
|
||||
|
||||
None
|
||||
|
||||
New Tokens
|
||||
|
||||
None
|
||||
|
||||
Additions to the EGL Specification
|
||||
|
||||
None
|
||||
|
||||
New Behavior
|
||||
|
||||
The device list produced by eglQueryDevicesEXT will include a software
|
||||
device. This can be distinguished from other device classes in the usual
|
||||
way by calling eglQueryDeviceStringEXT(EGL_EXTENSIONS) and matching this
|
||||
extension's string in the result.
|
||||
|
||||
Issues
|
||||
|
||||
None
|
||||
|
||||
Revision History
|
||||
|
||||
Version 2, 2018-10-03 (Emil Velikov)
|
||||
- Drop "fallback" from "software fallback device"
|
||||
- Add Emil Velikov as contributor
|
||||
|
||||
Version 1, 2017-07-06 (Adam Jackson)
|
||||
- Initial version
|
||||
@@ -0,0 +1,98 @@
|
||||
Name
|
||||
|
||||
MESA_drm_image_formats
|
||||
|
||||
Name Strings
|
||||
|
||||
EGL_MESA_drm_image_formats
|
||||
|
||||
Contributors
|
||||
|
||||
Nicolai Hähnle <Nicolai.Haehnle@amd.com>
|
||||
Qiang Yu <Qiang.Yu@amd.com>
|
||||
|
||||
Contact
|
||||
|
||||
Nicolai Hähnle <Nicolai.Haehnle@amd.com>
|
||||
|
||||
Status
|
||||
|
||||
Proposal
|
||||
|
||||
Version
|
||||
|
||||
Version 1, January 26, 2017
|
||||
|
||||
Number
|
||||
|
||||
EGL Extension #??
|
||||
|
||||
Dependencies
|
||||
|
||||
This extension requires the EGL_MESA_drm_image extension.
|
||||
|
||||
This extension is written against the wording of EGL_MESA_drm_image
|
||||
specification.
|
||||
|
||||
Overview
|
||||
|
||||
This extension extends the functionality of EGL_MESA_drm_image by adding
|
||||
additional formats required by Glamor for use with DRM buffers.
|
||||
|
||||
IP Status
|
||||
|
||||
Open-source; freely implementable.
|
||||
|
||||
New Procedures and Functions
|
||||
|
||||
None
|
||||
|
||||
New Tokens
|
||||
|
||||
Accepted as values for the EGL_IMAGE_FORMAT_MESA attribute:
|
||||
|
||||
EGL_DRM_BUFFER_FORMAT_ARGB2101010_MESA 0x3290
|
||||
EGL_DRM_BUFFER_FORMAT_ARGB1555_MESA 0x3291
|
||||
EGL_DRM_BUFFER_FORMAT_RGB565_MESA 0x3292
|
||||
|
||||
Additions to the EGL_MESA_drm_image Specification:
|
||||
|
||||
Remove the sentence "The only format specified ..." from the paragraph
|
||||
describing eglCreateDRMImageMESA and add the following paragraph:
|
||||
|
||||
The formats specified for use with EGL_DRM_BUFFER_FORMAT_MESA are:
|
||||
|
||||
* EGL_DRM_BUFFER_FORMAT_ARGB32_MESA, where each pixel is a CPU-endian
|
||||
32-bit quantity, with alpha in the upper 8 bits, then red, then green,
|
||||
then blue,
|
||||
|
||||
* EGL_DRM_BUFFER_FORMAT_ARGB2101010_MESA, where each pixel is a CPU-
|
||||
endian, 32-bit quantity, with alpha in the most significant 2 bits,
|
||||
followed by 10 bits each for red, green, and blue,
|
||||
|
||||
* EGL_DRM_BUFFER_FORMAT_ARGB1555_MESA, where each pixel is a CPU-endian
|
||||
16-bit quantity, with alpha in the most significant bit, followed by
|
||||
5 bits each for red, green, and blue, and
|
||||
|
||||
* EGL_DRM_BUFFER_FORMAT_RGB565_MESA, where each pixel is a CPU-endian
|
||||
16-bit quantity, with red in the 5 most significant bits, followed by
|
||||
6 bits of green and 5 bits of blue.
|
||||
|
||||
Issues
|
||||
|
||||
1. Should we expose the full set of channel permutations for the formats,
|
||||
e.g. ABGR2101010, RGBA1010102, and BGRA1010102 in addition to
|
||||
ARGB2101010?
|
||||
|
||||
RESOLVED: No.
|
||||
|
||||
DISCUSSION: The original extension sets a precedent of only exposing one
|
||||
of the possible permutations of 8-bit channel formats. It is also not
|
||||
clear where the additional permutations would be used. For example,
|
||||
Glamor has a fixed mapping from pixmap/screen depth to format that
|
||||
doesn't allow for the other permutations.
|
||||
|
||||
Revision History
|
||||
|
||||
Version 1, January, 2017
|
||||
Initial draft (Nicolai Hähnle)
|
||||
@@ -0,0 +1,120 @@
|
||||
Name
|
||||
|
||||
MESA_platform_surfaceless
|
||||
|
||||
Name Strings
|
||||
|
||||
EGL_MESA_platform_surfaceless
|
||||
|
||||
Contributors
|
||||
|
||||
Chad Versace <chadversary@google.com>
|
||||
Haixia Shi <hshi@google.com>
|
||||
Stéphane Marchesin <marcheu@google.com>
|
||||
Zach Reizner <zachr@chromium.org>
|
||||
Gurchetan Singh <gurchetansingh@google.com>
|
||||
|
||||
Contacts
|
||||
|
||||
Chad Versace <chadversary@google.com>
|
||||
|
||||
Status
|
||||
|
||||
DRAFT
|
||||
|
||||
Version
|
||||
|
||||
Version 2, 2016-10-13
|
||||
|
||||
Number
|
||||
|
||||
EGL Extension #TODO
|
||||
|
||||
Extension Type
|
||||
|
||||
EGL client extension
|
||||
|
||||
Dependencies
|
||||
|
||||
Requires EGL 1.5 or later; or EGL 1.4 with EGL_EXT_platform_base.
|
||||
|
||||
This extension is written against the EGL 1.5 Specification (draft
|
||||
20140122).
|
||||
|
||||
This extension interacts with EGL_EXT_platform_base as follows. If the
|
||||
implementation supports EGL_EXT_platform_base, then text regarding
|
||||
eglGetPlatformDisplay applies also to eglGetPlatformDisplayEXT;
|
||||
eglCreatePlatformWindowSurface to eglCreatePlatformWindowSurfaceEXT; and
|
||||
eglCreatePlatformPixmapSurface to eglCreatePlatformPixmapSurfaceEXT.
|
||||
|
||||
Overview
|
||||
|
||||
This extension defines a new EGL platform, the "surfaceless" platform. This
|
||||
platfom's defining property is that it has no native surfaces, and hence
|
||||
neither eglCreatePlatformWindowSurface nor eglCreatePlatformPixmapSurface
|
||||
can be used. The platform is independent of any native window system.
|
||||
|
||||
The platform's intended use case is for enabling OpenGL and OpenGL ES
|
||||
applications on systems where no window system exists. However, the
|
||||
platform's permitted usage is not restricted to this case. Since the
|
||||
platform is independent of any native window system, it may also be used on
|
||||
systems where a window system is present.
|
||||
|
||||
New Types
|
||||
|
||||
None
|
||||
|
||||
New Procedures and Functions
|
||||
|
||||
None
|
||||
|
||||
New Tokens
|
||||
|
||||
Accepted as the <platform> argument of eglGetPlatformDisplay:
|
||||
|
||||
EGL_PLATFORM_SURFACELESS_MESA 0x31DD
|
||||
|
||||
Additions to the EGL Specification
|
||||
|
||||
None.
|
||||
|
||||
New Behavior
|
||||
|
||||
To determine if the EGL implementation supports this extension, clients
|
||||
should query the EGL_EXTENSIONS string of EGL_NO_DISPLAY.
|
||||
|
||||
To obtain an EGLDisplay on the surfaceless platform, call
|
||||
eglGetPlatformDisplay with <platform> set to EGL_PLATFORM_SURFACELESS_MESA.
|
||||
The <native_display> parameter must be EGL_DEFAULT_DISPLAY.
|
||||
|
||||
eglCreatePlatformWindowSurface fails when called with a <display> that
|
||||
belongs to the surfaceless platform. It returns EGL_NO_SURFACE and
|
||||
generates EGL_BAD_NATIVE_WINDOW. The justification for this unconditional
|
||||
failure is that the surfaceless platform has no native windows, and
|
||||
therefore the <native_window> parameter is always invalid.
|
||||
|
||||
Likewise, eglCreatePlatformPixmapSurface also fails when called with a
|
||||
<display> that belongs to the surfaceless platform. It returns
|
||||
EGL_NO_SURFACE and generates EGL_BAD_NATIVE_PIXMAP.
|
||||
|
||||
The surfaceless platform imposes no platform-specific restrictions on the
|
||||
creation of pbuffers, as eglCreatePbufferSurface has no native surface
|
||||
parameter. Specifically, if the EGLDisplay advertises an EGLConfig whose
|
||||
EGL_SURFACE_TYPE attribute contains EGL_PBUFFER_BIT, then the EGLDisplay
|
||||
permits the creation of pbuffers with that config.
|
||||
|
||||
Issues
|
||||
|
||||
None.
|
||||
|
||||
Revision History
|
||||
|
||||
Version 2, 2016-10-13 (Chad Versace)
|
||||
- Assign enum values
|
||||
- Define interfactions with EGL 1.4 and EGL_EXT_platform_base.
|
||||
- Add Gurchetan as contributor, as he implemented the pbuffer support.
|
||||
|
||||
Version 1, 2016-09-23 (Chad Versace)
|
||||
- Initial version
|
||||
- Posted for review at
|
||||
https://lists.freedesktop.org/archives/mesa-dev/2016-September/129549.html
|
||||
@@ -0,0 +1,95 @@
|
||||
Name
|
||||
|
||||
MESA_query_driver
|
||||
|
||||
Name Strings
|
||||
|
||||
EGL_MESA_query_driver
|
||||
|
||||
Contact
|
||||
|
||||
Rob Clark <robdclark 'at' gmail.com>
|
||||
Nicolai Hähnle <Nicolai.Haehnle 'at' amd.com>
|
||||
|
||||
Contibutors
|
||||
|
||||
Veluri Mithun <velurimithun38 'at' gmail.com>
|
||||
|
||||
Status
|
||||
|
||||
Complete
|
||||
|
||||
Version
|
||||
|
||||
Version 3, 2019-01-24
|
||||
|
||||
Number
|
||||
|
||||
EGL Extension 131
|
||||
|
||||
Dependencies
|
||||
|
||||
EGL 1.0 is required.
|
||||
|
||||
Overview
|
||||
|
||||
When an application has to query the name of a driver and for
|
||||
obtaining driver's option list (UTF-8 encoded XML) of a driver
|
||||
the below functions are useful.
|
||||
|
||||
XML file formally describes all available options and also
|
||||
includes verbal descriptions in multiple languages. Its main purpose
|
||||
is to be automatically processed by configuration GUIs.
|
||||
The XML shall respect the following DTD:
|
||||
|
||||
<!ELEMENT driinfo (section*)>
|
||||
<!ELEMENT section (description+, option+)>
|
||||
<!ELEMENT description (enum*)>
|
||||
<!ATTLIST description lang CDATA #REQUIRED
|
||||
text CDATA #REQUIRED>
|
||||
<!ELEMENT option (description+)>
|
||||
<!ATTLIST option name CDATA #REQUIRED
|
||||
type (bool|enum|int|float) #REQUIRED
|
||||
default CDATA #REQUIRED
|
||||
valid CDATA #IMPLIED>
|
||||
<!ELEMENT enum EMPTY>
|
||||
<!ATTLIST enum value CDATA #REQUIRED
|
||||
text CDATA #REQUIRED>
|
||||
|
||||
New Procedures and Functions
|
||||
|
||||
char* eglGetDisplayDriverConfig(EGLDisplay dpy);
|
||||
const char* eglGetDisplayDriverName(EGLDisplay dpy);
|
||||
|
||||
Description
|
||||
|
||||
By passing EGLDisplay as parameter to `eglGetDisplayDriverName` one can retrieve
|
||||
driverName. Similarly passing EGLDisplay to `eglGetDisplayDriverConfig` we can retrieve
|
||||
driverConfig options of the driver in XML format.
|
||||
|
||||
The string returned by `eglGetDisplayDriverConfig` is heap-allocated and caller
|
||||
is responsible for freeing it.
|
||||
|
||||
EGL_BAD_DISPLAY is generated if `disp` is not an EGL display connection.
|
||||
|
||||
EGL_NOT_INITIALIZED is generated if `disp` has not been initialized.
|
||||
|
||||
If the implementation does not have enough resources to allocate the XML then an
|
||||
EGL_BAD_ALLOC error is generated.
|
||||
|
||||
New Tokens
|
||||
|
||||
No new tokens
|
||||
|
||||
Issues
|
||||
|
||||
None
|
||||
|
||||
|
||||
Revision History
|
||||
|
||||
Version 1, 2018-11-05 - First draft (Veluri Mithun)
|
||||
Version 2, 2019-01-23 - Final version (Veluri Mithun)
|
||||
Version 3, 2019-01-24 - Mark as complete, add Khronos extension
|
||||
number, fix parameter name in prototypes,
|
||||
write revision history (Eric Engestrom)
|
||||
@@ -0,0 +1,138 @@
|
||||
Name
|
||||
|
||||
EXT_shader_integer_mix
|
||||
|
||||
Name Strings
|
||||
|
||||
GL_EXT_shader_integer_mix
|
||||
|
||||
Contact
|
||||
|
||||
Matt Turner (matt.turner 'at' intel.com)
|
||||
|
||||
Contributors
|
||||
|
||||
Matt Turner, Intel
|
||||
Ian Romanick, Intel
|
||||
|
||||
Status
|
||||
|
||||
Shipping
|
||||
|
||||
Version
|
||||
|
||||
Last Modified Date: 09/12/2013
|
||||
Author Revision: 6
|
||||
|
||||
Number
|
||||
|
||||
TBD
|
||||
|
||||
Dependencies
|
||||
|
||||
OpenGL 3.0 or OpenGL ES 3.0 is required. This extension interacts with
|
||||
GL_ARB_ES3_compatibility.
|
||||
|
||||
This extension is written against the OpenGL 4.4 (core) specification
|
||||
and the GLSL 4.40 specification.
|
||||
|
||||
Overview
|
||||
|
||||
GLSL 1.30 (and GLSL ES 3.00) expanded the mix() built-in function to
|
||||
operate on a boolean third argument that does not interpolate but
|
||||
selects. This extension extends mix() to select between int, uint,
|
||||
and bool components.
|
||||
|
||||
New Procedures and Functions
|
||||
|
||||
None.
|
||||
|
||||
New Tokens
|
||||
|
||||
None.
|
||||
|
||||
Additions to Chapter 8 of the GLSL 4.40 Specification (Built-in Functions)
|
||||
|
||||
Modify Section 8.3, Common Functions
|
||||
|
||||
Additions to the table listing common built-in functions:
|
||||
|
||||
Syntax Description
|
||||
--------------------------- --------------------------------------------------
|
||||
genIType mix(genIType x, Selects which vector each returned component comes
|
||||
genIType y, from. For a component of a that is false, the
|
||||
genBType a) corresponding component of x is returned. For a
|
||||
genUType mix(genUType x, component of a that is true, the corresponding
|
||||
genUType y, component of y is returned.
|
||||
genBType a)
|
||||
genBType mix(genBType x,
|
||||
genBType y,
|
||||
genBType a)
|
||||
|
||||
Additions to the AGL/GLX/WGL Specifications
|
||||
|
||||
None.
|
||||
|
||||
Modifications to The OpenGL Shading Language Specification, Version 4.40
|
||||
|
||||
Including the following line in a shader can be used to control the
|
||||
language features described in this extension:
|
||||
|
||||
#extension GL_EXT_shader_integer_mix : <behavior>
|
||||
|
||||
where <behavior> is as specified in section 3.3.
|
||||
|
||||
New preprocessor #defines are added to the OpenGL Shading Language:
|
||||
|
||||
#define GL_EXT_shader_integer_mix 1
|
||||
|
||||
Interactions with ARB_ES3_compatibility
|
||||
|
||||
On desktop implementations that support ARB_ES3_compatibility,
|
||||
GL_EXT_shader_integer_mix can be enabled (and the new functions
|
||||
used) in shaders declared with '#version 300 es'.
|
||||
|
||||
GLX Protocol
|
||||
|
||||
None.
|
||||
|
||||
Errors
|
||||
|
||||
None.
|
||||
|
||||
New State
|
||||
|
||||
None.
|
||||
|
||||
New Implementation Dependent State
|
||||
|
||||
None.
|
||||
|
||||
Issues
|
||||
|
||||
1) Should we allow linear interpolation of integers via a non-boolean
|
||||
third component?
|
||||
|
||||
RESOLVED: No.
|
||||
|
||||
2) Should we allow mix() to select between boolean components?
|
||||
|
||||
RESOLVED: Yes. Implementing the same functionality using casts would be
|
||||
possible but ugly.
|
||||
|
||||
Revision History
|
||||
|
||||
Rev. Date Author Changes
|
||||
---- -------- -------- ---------------------------------------------
|
||||
6 09/12/2013 idr After discussions in Khronos, change vendor
|
||||
prefix to EXT.
|
||||
|
||||
5 09/09/2013 idr Add ARB_ES3_compatibility interaction.
|
||||
|
||||
4 09/06/2013 mattst88 Allow extension on OpenGL ES 3.0.
|
||||
|
||||
3 08/28/2013 mattst88 Add #extension/#define changes.
|
||||
|
||||
2 08/26/2013 mattst88 Change vendor prefix to MESA. Add mix() that
|
||||
selects between boolean components.
|
||||
1 08/26/2013 mattst88 Initial revision
|
||||
@@ -0,0 +1,176 @@
|
||||
Name
|
||||
|
||||
EXT_shader_samples_identical
|
||||
|
||||
Name Strings
|
||||
|
||||
GL_EXT_shader_samples_identical
|
||||
|
||||
Contact
|
||||
|
||||
Ian Romanick, Intel (ian.d.romanick 'at' intel.com)
|
||||
|
||||
Contributors
|
||||
|
||||
Chris Forbes, Mesa
|
||||
Magnus Wendt, Intel
|
||||
Neil S. Roberts, Intel
|
||||
Graham Sellers, AMD
|
||||
|
||||
Status
|
||||
|
||||
XXX - Not complete yet.
|
||||
|
||||
Version
|
||||
|
||||
Last Modified Date: November 19, 2015
|
||||
Revision: 6
|
||||
|
||||
Number
|
||||
|
||||
TBD
|
||||
|
||||
Dependencies
|
||||
|
||||
OpenGL 3.2, or OpenGL ES 3.1, or ARB_texture_multisample is required.
|
||||
|
||||
This extension is written against the OpenGL 4.5 (Core Profile)
|
||||
Specification
|
||||
|
||||
Overview
|
||||
|
||||
Multisampled antialiasing has become a common method for improving the
|
||||
quality of rendered images. Multisampling differs from supersampling in
|
||||
that the color of a primitive that covers all or part of a pixel is
|
||||
resolved once, regardless of the number of samples covered. If a large
|
||||
polygon is rendered, the colors of all samples in each interior pixel will
|
||||
be the same. This suggests a simple compression scheme that can reduce
|
||||
the necessary memory bandwidth requirements. In one such scheme, each
|
||||
sample is stored in a separate slice of the multisample surface. An
|
||||
additional multisample control surface (MCS) contains a mapping from pixel
|
||||
samples to slices.
|
||||
|
||||
If all the values stored in the MCS for a particular pixel are the same,
|
||||
then all the samples have the same value. Applications can take advantage
|
||||
of this information to reduce the bandwidth of reading multisample
|
||||
textures. A custom multisample resolve filter could optimize resolving
|
||||
pixels where every sample is identical by reading the color once.
|
||||
|
||||
color = texelFetch(sampler, coordinate, 0);
|
||||
if (!textureSamplesIdenticalEXT(sampler, coordinate)) {
|
||||
for (int i = 1; i < MAX_SAMPLES; i++) {
|
||||
vec4 c = texelFetch(sampler, coordinate, i);
|
||||
|
||||
//... accumulate c into color
|
||||
|
||||
}
|
||||
}
|
||||
|
||||
New Procedures and Functions
|
||||
|
||||
None.
|
||||
|
||||
New Tokens
|
||||
|
||||
None.
|
||||
|
||||
Additions to the OpenGL 4.5 (Core Profile) Specification
|
||||
|
||||
None.
|
||||
|
||||
Modifications to The OpenGL Shading Language Specification, Version 4.50.5
|
||||
|
||||
Including the following line in a shader can be used to control the
|
||||
language features described in this extension:
|
||||
|
||||
#extension GL_EXT_shader_samples_identical
|
||||
|
||||
A new preprocessor #define is added to the OpenGL Shading Language:
|
||||
|
||||
#define GL_EXT_shader_samples_identical
|
||||
|
||||
Add to the table in section 8.7 "Texture Lookup Functions"
|
||||
|
||||
Syntax:
|
||||
|
||||
bool textureSamplesIdenticalEXT(gsampler2DMS sampler, ivec2 coord)
|
||||
|
||||
bool textureSamplesIdenticalEXT(gsampler2DMSArray sampler,
|
||||
ivec3 coord)
|
||||
|
||||
Description:
|
||||
|
||||
Returns true if it can be determined that all samples within the texel
|
||||
of the multisample texture bound to <sampler> at <coord> contain the
|
||||
same values or false if this cannot be determined."
|
||||
|
||||
Additions to the AGL/EGL/GLX/WGL Specifications
|
||||
|
||||
None
|
||||
|
||||
Errors
|
||||
|
||||
None
|
||||
|
||||
New State
|
||||
|
||||
None
|
||||
|
||||
New Implementation Dependent State
|
||||
|
||||
None
|
||||
|
||||
Issues
|
||||
|
||||
1) What should the new functions be called?
|
||||
|
||||
RESOLVED: textureSamplesIdenticalEXT. Initially
|
||||
textureAllSamplesIdenticalEXT was considered, but
|
||||
textureSamplesIdenticalEXT is more similar to the existing textureSamples
|
||||
function.
|
||||
|
||||
2) It seems like applications could implement additional optimization if
|
||||
they were provided with raw MCS data. Should this extension also
|
||||
provide that data?
|
||||
|
||||
There are a number of challenges in providing raw MCS data. The biggest
|
||||
problem being that the amount of MCS data depends on the number of
|
||||
samples, and that is not known at compile time. Additionally, without new
|
||||
texelFetch functions, applications would have difficulty utilizing the
|
||||
information.
|
||||
|
||||
Another option is to have a function that returns an array of tuples of
|
||||
sample number and count. This also has difficulties with the maximum
|
||||
array size not being known at compile time.
|
||||
|
||||
RESOLVED: Do not expose raw MCS data in this extension.
|
||||
|
||||
3) Should this extension also extend SPIR-V?
|
||||
|
||||
RESOLVED: Yes, but this has not yet been written.
|
||||
|
||||
4) Is it possible for textureSamplesIdenticalEXT to report false negatives?
|
||||
|
||||
RESOLVED: Yes. It is possible that the underlying hardware may not detect
|
||||
that separate writes of the same color to different samples of a pixel are
|
||||
the same. The shader function is at the whim of the underlying hardware
|
||||
implementation. It is also possible that a compressed multisample surface
|
||||
is not used. In that case the function will likely always return false.
|
||||
|
||||
Revision History
|
||||
|
||||
Rev Date Author Changes
|
||||
--- ---------- -------- ---------------------------------------------
|
||||
1 2014/08/20 cforbes Initial version
|
||||
2 2015/10/23 idr Change from MESA to EXT. Rebase on OpenGL 4.5,
|
||||
and add dependency on OpenGL ES 3.1. Initial
|
||||
draft of overview section and issues 1 through
|
||||
3.
|
||||
3 2015/10/27 idr Typo fixes.
|
||||
4 2015/11/10 idr Rename extension from EXT_shader_multisample_compression
|
||||
to EXT_shader_samples_identical.
|
||||
Add issue #4.
|
||||
5 2015/11/18 idr Fix some typos spotted by gsellers. Change the
|
||||
name of the name of the function to
|
||||
textureSamplesIdenticalEXT.
|
||||
6 2015/11/19 idr Fix more typos spotted by Nicolai Hähnle.
|
||||
@@ -0,0 +1,200 @@
|
||||
Name
|
||||
|
||||
INTEL_shader_atomic_float_minmax
|
||||
|
||||
Name Strings
|
||||
|
||||
GL_INTEL_shader_atomic_float_minmax
|
||||
|
||||
Contact
|
||||
|
||||
Ian Romanick (ian . d . romanick 'at' intel . com)
|
||||
|
||||
Contributors
|
||||
|
||||
|
||||
Status
|
||||
|
||||
In progress
|
||||
|
||||
Version
|
||||
|
||||
Last Modified Date: 06/22/2018
|
||||
Revision: 4
|
||||
|
||||
Number
|
||||
|
||||
TBD
|
||||
|
||||
Dependencies
|
||||
|
||||
OpenGL 4.2, OpenGL ES 3.1, ARB_shader_storage_buffer_object, or
|
||||
ARB_compute_shader is required.
|
||||
|
||||
This extension is written against version 4.60 of the OpenGL Shading
|
||||
Language Specification.
|
||||
|
||||
Overview
|
||||
|
||||
This extension provides GLSL built-in functions allowing shaders to
|
||||
perform atomic read-modify-write operations to floating-point buffer
|
||||
variables and shared variables. Minimum, maximum, exchange, and
|
||||
compare-and-swap are enabled.
|
||||
|
||||
|
||||
New Procedures and Functions
|
||||
|
||||
None.
|
||||
|
||||
New Tokens
|
||||
|
||||
None.
|
||||
|
||||
IP Status
|
||||
|
||||
None.
|
||||
|
||||
Modifications to the OpenGL Shading Language Specification, Version 4.60
|
||||
|
||||
Including the following line in a shader can be used to control the
|
||||
language features described in this extension:
|
||||
|
||||
#extension GL_INTEL_shader_atomic_float_minmax : <behavior>
|
||||
|
||||
where <behavior> is as specified in section 3.3.
|
||||
|
||||
New preprocessor #defines are added to the OpenGL Shading Language:
|
||||
|
||||
#define GL_INTEL_shader_atomic_float_minmax 1
|
||||
|
||||
Additions to Chapter 8 of the OpenGL Shading Language Specification
|
||||
(Built-in Functions)
|
||||
|
||||
Modify Section 8.11, "Atomic Memory Functions"
|
||||
|
||||
(add a new row after the existing "atomicMin" table row, p. 179)
|
||||
|
||||
float atomicMin(inout float mem, float data)
|
||||
|
||||
|
||||
Computes a new value by taking the minimum of the value of data and
|
||||
the contents of mem. If one of these is an IEEE signaling NaN (i.e.,
|
||||
a NaN with the most-significant bit of the mantissa cleared), it is
|
||||
always considered smaller. If one of these is an IEEE quiet NaN
|
||||
(i.e., a NaN with the most-significant bit of the mantissa set), it is
|
||||
always considered larger. If both are IEEE quiet NaNs or both are
|
||||
IEEE signaling NaNs, the result of the comparison is undefined.
|
||||
|
||||
(add a new row after the exiting "atomicMax" table row, p. 179)
|
||||
|
||||
float atomicMax(inout float mem, float data)
|
||||
|
||||
Computes a new value by taking the maximum of the value of data and
|
||||
the contents of mem. If one of these is an IEEE signaling NaN (i.e.,
|
||||
a NaN with the most-significant bit of the mantissa cleared), it is
|
||||
always considered larger. If one of these is an IEEE quiet NaN (i.e.,
|
||||
a NaN with the most-significant bit of the mantissa set), it is always
|
||||
considered smaller. If both are IEEE quiet NaNs or both are IEEE
|
||||
signaling NaNs, the result of the comparison is undefined.
|
||||
|
||||
(add to "atomicExchange" table cell, p. 180)
|
||||
|
||||
float atomicExchange(inout float mem, float data)
|
||||
|
||||
(add to "atomicCompSwap" table cell, p. 180)
|
||||
|
||||
float atomicCompSwap(inout float mem, float compare, float data)
|
||||
|
||||
Interactions with OpenGL 4.6 and ARB_gl_spirv
|
||||
|
||||
If OpenGL 4.6 or ARB_gl_spirv is supported, then
|
||||
SPV_INTEL_shader_atomic_float_minmax must also be supported.
|
||||
|
||||
The AtomicFloatMinmaxINTEL capability is available whenever the OpenGL or
|
||||
OpenGL ES implementation supports INTEL_shader_atomic_float_minmax.
|
||||
|
||||
Issues
|
||||
|
||||
1) Why call this extension INTEL_shader_atomic_float_minmax?
|
||||
|
||||
RESOLVED: Several other extensions already set the precedent of
|
||||
VENDOR_shader_atomic_float and VENDOR_shader_atomic_float64 for extensions
|
||||
that enable floating-point atomic operations. Using that as a base for
|
||||
the name seems logical.
|
||||
|
||||
There already exists NV_shader_atomic_float, but the two extensions have
|
||||
nearly zero overlap in functionality. NV_shader_atomic_float adds
|
||||
atomicAdd and image atomic operations that currently shipping Intel GPUs
|
||||
do not support. Calling this extension INTEL_shader_atomic_float would
|
||||
likely have been confusing.
|
||||
|
||||
Adding something to describe the actual functions added by this extension
|
||||
seemed reasonable. INTEL_shader_atomic_float_compare was considered, but
|
||||
that name was deemed to be not properly descriptive. Calling this
|
||||
extension INTEL_shader_atomic_float_min_max_exchange_compswap is right
|
||||
out.
|
||||
|
||||
2) What atomic operations should we support for floating-point targets?
|
||||
|
||||
RESOLVED. Exchange, min, max, and compare-swap make sense, and these are
|
||||
all supported by the hardware. Future extensions may add other functions.
|
||||
|
||||
For buffer variables and shared variables it is not possible to bit-cast
|
||||
the memory location in GLSL, so existing integer operations, such as
|
||||
atomicOr, cannot be used. However, the underlying hardware implementation
|
||||
can do this by treating the memory as an integer. It would be possible to
|
||||
implement atomicNegate using this technique with atomicXor. It is unclear
|
||||
whether this provides any actual utility.
|
||||
|
||||
3) What should be said about the NaN behavior?
|
||||
|
||||
RESOLVED. There are several aspects of NaN behavior that should be
|
||||
documented in this extension. However, some of this behavior varies based
|
||||
on NaN concepts that do not exist in the GLSL specification.
|
||||
|
||||
* atomicCompSwap performs the comparison as the floating-point equality
|
||||
operator (==). That is, if either 'mem' or 'compare' is NaN, the
|
||||
comparison result is always false.
|
||||
|
||||
* atomicMin and atomicMax implement the IEEE specification with respect to
|
||||
NaN. IEEE considers two different kinds of NaN: signaling NaN and quiet
|
||||
NaN. A quiet NaN has the most significant bit of the mantissa set, and
|
||||
a signaling NaN does not. This concept does not exist in SPIR-V,
|
||||
Vulkan, or OpenGL. Let qNaN denote a quiet NaN and sNaN denote a
|
||||
signaling NaN. atomicMin and atomicMax specifically implement
|
||||
|
||||
- fmin(qNaN, x) = fmin(x, qNaN) = fmax(qNaN, x) = fmax(x, qNaN) = x
|
||||
- fmin(sNaN, x) = fmin(x, sNaN) = fmax(sNaN, x) = fmax(x, sNaN) = sNaN
|
||||
- fmin(sNaN, qNaN) = fmin(qNaN, sNaN) = fmax(sNaN, qNaN) =
|
||||
fmax(qNaN, sNaN) = sNaN
|
||||
- fmin(sNaN, sNaN) = sNaN. This specification does not define which of
|
||||
the two arguments is stored.
|
||||
- fmax(sNaN, sNaN) = sNaN. This specification does not define which of
|
||||
the two arguments is stored.
|
||||
- fmin(qNaN, qNaN) = qNaN. This specification does not define which of
|
||||
the two arguments is stored.
|
||||
- fmax(qNaN, qNaN) = qNaN. This specification does not define which of
|
||||
the two arguments is stored.
|
||||
|
||||
Further details are available in the Skylake Programmer's Reference
|
||||
Manuals available at
|
||||
https://01.org/linuxgraphics/documentation/hardware-specification-prms.
|
||||
|
||||
4) What about atomicMin and atomicMax with (+0.0, -0.0) or (-0.0, +0.0)
|
||||
arguments?
|
||||
|
||||
RESOLVED. atomicMin should store -0.0, and atomicMax should store +0.0.
|
||||
Due to a known issue in shipping Skylake GPUs, the incorrectly signed 0 is
|
||||
stored. This behavior may change in later GPUs.
|
||||
|
||||
Revision History
|
||||
|
||||
Rev Date Author Changes
|
||||
--- ---------- -------- ---------------------------------------------
|
||||
1 04/19/2018 idr Initial version
|
||||
2 05/05/2018 idr Describe interactions with the capabilities
|
||||
added by SPV_INTEL_shader_atomic_float_minmax.
|
||||
3 05/29/2018 idr Remove mention of 64-bit float support.
|
||||
4 06/22/2018 idr Resolve issue #2.
|
||||
Add issue #3 (regarding NaN behavior).
|
||||
Add issue #4 (regarding atomicMin(-0, +0).
|
||||
@@ -0,0 +1,129 @@
|
||||
Name
|
||||
|
||||
MESA_configless_context
|
||||
|
||||
Name Strings
|
||||
|
||||
EGL_MESA_configless_context
|
||||
|
||||
Contact
|
||||
|
||||
Neil Roberts <neil.s.roberts@intel.com>
|
||||
|
||||
Status
|
||||
|
||||
Superseded by the functionally identical EGL_KHR_no_config_context
|
||||
extension.
|
||||
|
||||
Version
|
||||
|
||||
Version 2, September 9, 2016
|
||||
|
||||
Number
|
||||
|
||||
EGL Extension #not assigned
|
||||
|
||||
Dependencies
|
||||
|
||||
Requires EGL 1.4 or later. This extension is written against the
|
||||
wording of the EGL 1.4 specification.
|
||||
|
||||
Overview
|
||||
|
||||
This extension provides a means to use a single context to render to
|
||||
multiple surfaces which have different EGLConfigs. Without this extension
|
||||
the EGLConfig for every surface used by the context must be compatible
|
||||
with the one used by the context. The only way to render to surfaces with
|
||||
different formats would be to create multiple contexts but this is
|
||||
inefficient with modern GPUs where this restriction is unnecessary.
|
||||
|
||||
IP Status
|
||||
|
||||
Open-source; freely implementable.
|
||||
|
||||
New Procedures and Functions
|
||||
|
||||
None.
|
||||
|
||||
New Tokens
|
||||
|
||||
Accepted as <config> in eglCreateContext
|
||||
|
||||
EGL_NO_CONFIG_MESA ((EGLConfig)0)
|
||||
|
||||
Additions to the EGL Specification section "2.2 Rendering Contexts and Drawing
|
||||
Surfaces"
|
||||
|
||||
Add the following to the 3rd paragraph:
|
||||
|
||||
"EGLContexts can also optionally be created with respect to an EGLConfig
|
||||
depending on the parameters used at creation time. If a config is provided
|
||||
then additional restrictions apply on what surfaces can be used with the
|
||||
context."
|
||||
|
||||
Replace the last sentence of the 6th paragraph with:
|
||||
|
||||
"In order for a context to be compatible with a surface they both must have
|
||||
been created with respect to the same EGLDisplay. If the context was
|
||||
created without respect to an EGLConfig then there are no further
|
||||
constraints. Otherwise they are only compatible if:"
|
||||
|
||||
Remove the last bullet point in the list of constraints.
|
||||
|
||||
Additions to the EGL Specification section "3.7.1 Creating Rendering Contexts"
|
||||
|
||||
Replace the paragraph starting "If config is not a valid EGLConfig..."
|
||||
with
|
||||
|
||||
"The config argument can either be a valid EGLConfig or EGL_NO_CONFIG_MESA.
|
||||
If it is neither of these then an EGL_BAD_CONFIG error is generated. If a
|
||||
valid config is passed then the error will also be generated if the config
|
||||
does not support the requested client API (this includes requesting
|
||||
creation of an OpenGL ES 1.x context when the EGL_RENDERABLE_TYPE
|
||||
attribute of config does not contain EGL_OPENGL_ES_BIT, or creation of an
|
||||
OpenGL ES 2.x context when the attribute does not contain
|
||||
EGL_OPENGL_ES2_BIT).
|
||||
|
||||
Passing EGL_NO_CONFIG_MESA will create a configless context. When a
|
||||
configless context is used with the OpenGL API it can be assumed that the
|
||||
initial values of the context's state will be decided when the context is
|
||||
first made current. In particular this means that the decision of whether
|
||||
to use GL_BACK or GL_FRONT for the initial value of the first output in
|
||||
glDrawBuffers will be decided based on the config of the draw surface when
|
||||
it is first bound."
|
||||
|
||||
Additions to the EGL Specification section "3.7.3 Binding Contexts and
|
||||
Drawables"
|
||||
|
||||
Replace the first bullet point with the following:
|
||||
|
||||
"* If draw or read are not compatible with ctx as described in section 2.2,
|
||||
then an EGL_BAD_MATCH error is generated."
|
||||
|
||||
Add a second bullet point after that:
|
||||
|
||||
"* If draw and read are not compatible with each other as described in
|
||||
section 2.2, then an EGL_BAD_MATCH error is generated."
|
||||
|
||||
Issues
|
||||
|
||||
1. What happens when an OpenGL context with a double-buffered surface and
|
||||
draw buffer set to GL_BACK is made current with a single-buffered
|
||||
surface?
|
||||
|
||||
NOT RESOLVED: There are a few options here. An implementation can
|
||||
raise an error, change the drawbuffer state to GL_FRONT or just do
|
||||
nothing, expecting the application to set GL_FRONT drawbuffer before
|
||||
drawing. However, this extension deliberately does not specify any
|
||||
required behavior in this corner case and applications should avoid
|
||||
mixing single- and double-buffered surfaces with configless contexts.
|
||||
|
||||
Future extensions may specify required behavior in this case.
|
||||
|
||||
Revision History
|
||||
|
||||
Version 2, September 9, 2016
|
||||
Defer to EGL_KHR_no_config_context (Adam Jackson)
|
||||
|
||||
Version 1, February 28, 2014
|
||||
Initial draft (Neil Roberts)
|
||||
@@ -0,0 +1,96 @@
|
||||
Name
|
||||
|
||||
MESA_copy_sub_buffer
|
||||
|
||||
Name Strings
|
||||
|
||||
GLX_MESA_copy_sub_buffer
|
||||
|
||||
Contact
|
||||
|
||||
Brian Paul (brian.paul 'at' tungstengraphics.com)
|
||||
|
||||
Status
|
||||
|
||||
Shipping since Mesa 2.6 in February, 1998.
|
||||
|
||||
Version
|
||||
|
||||
Last Modified Date: 12 January 2009
|
||||
|
||||
Number
|
||||
|
||||
215
|
||||
|
||||
Dependencies
|
||||
|
||||
OpenGL 1.0 or later is required.
|
||||
GLX 1.0 or later is required.
|
||||
|
||||
Overview
|
||||
|
||||
The glxCopySubBufferMESA() function copies a rectangular region
|
||||
of the back color buffer to the front color buffer. This can be
|
||||
used to quickly repaint 3D windows in response to expose events
|
||||
when the back color buffer cannot be damaged by other windows.
|
||||
|
||||
IP Status
|
||||
|
||||
Open-source; freely implementable.
|
||||
|
||||
Issues
|
||||
|
||||
None.
|
||||
|
||||
New Procedures and Functions
|
||||
|
||||
void glXCopySubBufferMESA( Display *dpy, GLXDrawable drawable,
|
||||
int x, int y, int width, int height );
|
||||
|
||||
New Tokens
|
||||
|
||||
None.
|
||||
|
||||
Additions to Chapter 3 of the GLX 1.3 Specification (Functions and Errors)
|
||||
|
||||
Add to section 3.3.10 Double Buffering:
|
||||
|
||||
The function
|
||||
|
||||
void glXCopySubBufferMESA( Display *dpy, GLXDrawable drawable,
|
||||
int x, int y, int width, int height );
|
||||
|
||||
may be used to copy a rectangular region of the back color buffer to
|
||||
the front color buffer. This can be used to quickly repaint 3D windows
|
||||
in response to expose events when the back color buffer cannot be
|
||||
damaged by other windows.
|
||||
|
||||
<x> and <y> indicates the lower-left corner of the region to copy and
|
||||
<width> and <height> indicate the size in pixels. Coordinate (0,0)
|
||||
corresponds to the lower-left pixel of the window, like glReadPixels.
|
||||
|
||||
If dpy and drawable are the display and drawable for the calling
|
||||
thread's current context, glXCopySubBufferMESA performs an
|
||||
implicit glFlush before it returns. Subsequent OpenGL commands
|
||||
may be issued immediately after calling glXCopySubBufferMESA, but
|
||||
are not executed until the copy is completed.
|
||||
|
||||
GLX Protocol
|
||||
|
||||
None at this time. The extension is implemented in terms of ordinary
|
||||
Xlib protocol inside of Mesa.
|
||||
|
||||
Errors
|
||||
|
||||
None.
|
||||
|
||||
New State
|
||||
|
||||
None.
|
||||
|
||||
Revision History
|
||||
|
||||
12 January 2009 Ian Romanick - Added language about implicit flush
|
||||
and command completion.
|
||||
8 June 2000 Brian Paul - initial specification
|
||||
|
||||
@@ -0,0 +1,153 @@
|
||||
Name
|
||||
|
||||
MESA_drm_image
|
||||
|
||||
Name Strings
|
||||
|
||||
EGL_MESA_drm_image
|
||||
|
||||
Contact
|
||||
|
||||
Kristian Høgsberg <krh@bitplanet.net>
|
||||
|
||||
Status
|
||||
|
||||
Proposal
|
||||
|
||||
Version
|
||||
|
||||
Version 2, August 25, 2010
|
||||
|
||||
Number
|
||||
|
||||
EGL Extension #not assigned
|
||||
|
||||
Dependencies
|
||||
|
||||
Requires EGL 1.4 or later. This extension is written against the
|
||||
wording of the EGL 1.4 specification.
|
||||
|
||||
EGL_KHR_base_image is required.
|
||||
|
||||
Overview
|
||||
|
||||
This extension provides entry points for integrating EGLImage with the
|
||||
Linux DRM mode setting and memory management drivers. The extension
|
||||
lets applications create EGLImages without a client API resource and
|
||||
lets the application get the DRM buffer handles.
|
||||
|
||||
IP Status
|
||||
|
||||
Open-source; freely implementable.
|
||||
|
||||
New Procedures and Functions
|
||||
|
||||
EGLImageKHR eglCreateDRMImageMESA(EGLDisplay dpy,
|
||||
const EGLint *attrib_list);
|
||||
|
||||
EGLBoolean eglExportDRMImageMESA(EGLDisplay dpy,
|
||||
EGLImageKHR image,
|
||||
EGLint *name,
|
||||
EGLint *handle,
|
||||
EGLint *stride);
|
||||
|
||||
New Tokens
|
||||
|
||||
Accepted in the <attrib_list> parameter of eglCreateDRMImageMESA:
|
||||
|
||||
EGL_DRM_BUFFER_FORMAT_MESA 0x31D0
|
||||
EGL_DRM_BUFFER_USE_MESA 0x31D1
|
||||
|
||||
Accepted as values for the EGL_IMAGE_FORMAT_MESA attribute:
|
||||
|
||||
EGL_DRM_BUFFER_FORMAT_ARGB32_MESA 0x31D2
|
||||
|
||||
Bits accepted in EGL_DRM_BUFFER_USE_MESA:
|
||||
|
||||
EGL_DRM_BUFFER_USE_SCANOUT_MESA 0x0001
|
||||
EGL_DRM_BUFFER_USE_SHARE_MESA 0x0002
|
||||
EGL_DRM_BUFFER_USE_CURSOR_MESA 0x0004
|
||||
|
||||
Accepted in the <target> parameter of eglCreateImageKHR:
|
||||
|
||||
EGL_DRM_BUFFER_MESA 0x31D3
|
||||
|
||||
Use when importing drm buffer:
|
||||
|
||||
EGL_DRM_BUFFER_STRIDE_MESA 0x31D4
|
||||
EGL_DRM_BUFFER_FORMAT_MESA 0x31D0
|
||||
|
||||
Additions to the EGL 1.4 Specification:
|
||||
|
||||
To create a DRM EGLImage, call
|
||||
|
||||
EGLImageKHR eglCreateDRMImageMESA(EGLDisplay dpy,
|
||||
const EGLint *attrib_list);
|
||||
|
||||
In the attribute list, pass EGL_WIDTH, EGL_HEIGHT and format and
|
||||
use in the attrib list using EGL_DRM_BUFFER_FORMAT_MESA and
|
||||
EGL_DRM_BUFFER_USE_MESA. The only format specified by this
|
||||
extension is EGL_DRM_BUFFER_FORMAT_ARGB32_MESA, where each pixel
|
||||
is a CPU-endian, 32-bit quantity, with alpha in the upper 8 bits,
|
||||
then red, then green, then blue. The bit values accepted by
|
||||
EGL_DRM_BUFFER_USE_MESA are EGL_DRM_BUFFER_USE_SCANOUT_MESA,
|
||||
EGL_DRM_BUFFER_USE_SHARE_MESA and EGL_DRM_BUFFER_USE_CURSOR_MESA.
|
||||
EGL_DRM_BUFFER_USE_SCANOUT_MESA requests that the created EGLImage
|
||||
should be usable as a scanout buffer with the DRM kernel
|
||||
modesetting API. EGL_DRM_BUFFER_USE_SHARE_MESA requests that the
|
||||
EGLImage can be shared with other processes by passing the
|
||||
underlying DRM buffer name. EGL_DRM_BUFFER_USE_CURSOR_MESA
|
||||
requests that the image must be usable as a cursor with KMS. When
|
||||
EGL_DRM_BUFFER_USE_CURSOR_MESA is set, width and height must both
|
||||
be 64.
|
||||
|
||||
To create a process local handle or a global DRM name for a
|
||||
buffer, call
|
||||
|
||||
EGLBoolean eglExportDRMImageMESA(EGLDisplay dpy,
|
||||
EGLImageKHR image,
|
||||
EGLint *name,
|
||||
EGLint *handle,
|
||||
EGLint *stride);
|
||||
|
||||
If <name> is non-NULL, a global name is assigned to the image and
|
||||
written to <name>, the handle (local to the DRM file descriptor,
|
||||
for use with DRM kernel modesetting API) is written to <handle> if
|
||||
non-NULL and the stride (in bytes) is written to <stride>, if
|
||||
non-NULL.
|
||||
|
||||
Import a shared buffer by calling eglCreateImageKHR with
|
||||
EGL_DRM_BUFFER_MESA as the target, using EGL_WIDTH, EGL_HEIGHT,
|
||||
EGL_DRM_BUFFER_FORMAT_MESA, EGL_DRM_BUFFER_STRIDE_MESA
|
||||
in the attrib list.
|
||||
|
||||
Issues
|
||||
|
||||
1. Why don't we use eglCreateImageKHR with a target that
|
||||
indicates that we want to create an EGLImage from scratch?
|
||||
|
||||
RESOLVED: The eglCreateImageKHR entry point is reserved for
|
||||
creating an EGLImage from an already existing client API
|
||||
resource. This is fine when we're creating the EGLImage from
|
||||
an existing DRM buffer name, it doesn't seem right to overload
|
||||
the function to also allocate the underlying resource.
|
||||
|
||||
2. Why don't we use an eglQueryImageMESA type functions for
|
||||
querying the DRM EGLImage attributes (name, handle, and stride)?
|
||||
|
||||
RESOLVED: The eglQueryImage function has been proposed often,
|
||||
but it goes against the EGLImage design. EGLImages are opaque
|
||||
handles to a 2D array of pixels, which can be passed between
|
||||
client APIs. By referencing an EGLImage in a client API, the
|
||||
EGLImage target (a texture, a renderbuffer or such) can be
|
||||
used to query the attributes of the EGLImage. We don't have a
|
||||
full client API for creating and querying DRM buffers, though,
|
||||
so we use a new EGL extension entry point instead.
|
||||
|
||||
Revision History
|
||||
|
||||
Version 1, June 3, 2010
|
||||
Initial draft (Kristian Høgsberg)
|
||||
Version 2, August 25, 2010
|
||||
Flesh out the extension a bit, add final EGL tokens, capture
|
||||
some of the original discussion in the issues section.
|
||||
@@ -0,0 +1,106 @@
|
||||
Name
|
||||
|
||||
MESA_framebuffer_flip_y
|
||||
|
||||
Name Strings
|
||||
|
||||
GL_MESA_framebuffer_flip_y
|
||||
|
||||
Contact
|
||||
|
||||
Fritz Koenig <frkoenig@google.com>
|
||||
|
||||
Contributors
|
||||
|
||||
Fritz Koenig, Google
|
||||
Kristian Høgsberg, Google
|
||||
Chad Versace, Google
|
||||
Heinrich Fink, DAQRI
|
||||
|
||||
Status
|
||||
|
||||
Proposal
|
||||
|
||||
Version
|
||||
|
||||
Version 3, August, 2019
|
||||
|
||||
Number
|
||||
|
||||
OpenGL Extension #540
|
||||
OpenGL ES Extension #302
|
||||
|
||||
Dependencies
|
||||
|
||||
Requires OpenGL ES 3.0, OpenGL 4.3, or ARB_framebuffer_no_attachments.
|
||||
|
||||
Overview
|
||||
|
||||
This extension defines a new framebuffer parameter,
|
||||
GL_FRAMEBUFFER_FLIP_Y_MESA, that changes the behavior of the reads and
|
||||
writes to the framebuffer attachment points. When GL_FRAMEBUFFER_FLIP_Y_MESA
|
||||
is GL_TRUE, render commands and pixel transfer operations access the
|
||||
backing store of each attachment point with an y-inverted coordinate
|
||||
system. This y-inversion is relative to the coordinate system set when
|
||||
GL_FRAMEBUFFER_FLIP_Y_MESA is GL_FALSE.
|
||||
|
||||
Access through TexSubImage2D and similar calls will notice the effect of
|
||||
the flip when they are not attached to framebuffer objects because
|
||||
GL_FRAMEBUFFER_FLIP_Y_MESA is associated with the framebuffer object and
|
||||
not the attachment points.
|
||||
|
||||
IP Status
|
||||
|
||||
None
|
||||
|
||||
Issues
|
||||
|
||||
None
|
||||
|
||||
New Procedures and Functions
|
||||
|
||||
OpenGL ES must provide the following functions:
|
||||
|
||||
void FramebufferParameteriMESA(enum target, enum pname, int param);
|
||||
void GetFramebufferParameterivMESA(enum target, enum pname, int *params);
|
||||
|
||||
New Types
|
||||
|
||||
None
|
||||
|
||||
New Tokens
|
||||
|
||||
Accepted by the <pname> argument of FramebufferParameteriMESA and
|
||||
GetFramebufferParameterivMESA:
|
||||
|
||||
GL_FRAMEBUFFER_FLIP_Y_MESA 0x8BBB
|
||||
|
||||
Interactions with OpenGL 4.3, OpenGL ES 3.1, ARB_framebuffer_no_attachments
|
||||
and any other versions and extensions that provide the entry points
|
||||
FramebufferParameteri and GetFramebufferParameteriv
|
||||
|
||||
Token GL_FRAMEBUFFER_FLIP_Y_MESA is accepted as the <pname> argument of
|
||||
FramebufferParameteri and GetFramebufferParameteriv.
|
||||
|
||||
Errors
|
||||
|
||||
An INVALID_OPERATION error is generated by GetFramebufferParameteriv or
|
||||
GetFramebufferParameterivMESA if the default framebuffer is bound
|
||||
to <target> and <pname> is GL_FRAMEBUFFER_FLIP_Y_MESA.
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
Revision History
|
||||
|
||||
Version 3, August, 2019
|
||||
Allow OpenGL ES 3.0 to implement by adding functions
|
||||
FramebufferParameteriMESA and GetFramebufferParameterivMESA which were
|
||||
previously only available in OpenGL ES 3.1.
|
||||
|
||||
Version 2, June, 2019
|
||||
Enable extension for OpenGL 4.3 and beyond
|
||||
|
||||
Version 1, June, 2018
|
||||
Initial draft (Fritz Koenig)
|
||||
@@ -0,0 +1,147 @@
|
||||
Name
|
||||
|
||||
MESA_image_dma_buf_export
|
||||
|
||||
Name Strings
|
||||
|
||||
EGL_MESA_image_dma_buf_export
|
||||
|
||||
Contributors
|
||||
|
||||
Dave Airlie
|
||||
|
||||
Contact
|
||||
|
||||
Dave Airlie (airlied 'at' redhat 'dot' com)
|
||||
|
||||
Status
|
||||
|
||||
Complete, shipping.
|
||||
|
||||
Version
|
||||
|
||||
Version 3, May 5, 2015
|
||||
|
||||
Number
|
||||
|
||||
EGL Extension #87
|
||||
|
||||
Dependencies
|
||||
|
||||
Requires EGL 1.4 or later. This extension is written against the
|
||||
wording of the EGL 1.4 specification.
|
||||
|
||||
EGL_KHR_base_image is required.
|
||||
|
||||
The EGL implementation must be running on a Linux kernel supporting the
|
||||
dma_buf buffer sharing mechanism.
|
||||
|
||||
Overview
|
||||
|
||||
This extension provides entry points for integrating EGLImage with the
|
||||
dma-buf infrastructure. The extension allows creating a Linux dma_buf
|
||||
file descriptor or multiple file descriptors, in the case of multi-plane
|
||||
YUV image, from an EGLImage.
|
||||
|
||||
It is designed to provide the complementary functionality to
|
||||
EGL_EXT_image_dma_buf_import.
|
||||
|
||||
IP Status
|
||||
|
||||
Open-source; freely implementable.
|
||||
|
||||
New Types
|
||||
|
||||
This extension uses the 64-bit unsigned integer type EGLuint64KHR
|
||||
first introduced by the EGL_KHR_stream extension, but does not
|
||||
depend on that extension. The typedef may be reproduced separately
|
||||
for this extension, if not already present in eglext.h.
|
||||
|
||||
typedef khronos_uint64_t EGLuint64KHR;
|
||||
|
||||
New Procedures and Functions
|
||||
|
||||
EGLBoolean eglExportDMABUFImageQueryMESA(EGLDisplay dpy,
|
||||
EGLImageKHR image,
|
||||
int *fourcc,
|
||||
int *num_planes,
|
||||
EGLuint64KHR *modifiers);
|
||||
|
||||
EGLBoolean eglExportDMABUFImageMESA(EGLDisplay dpy,
|
||||
EGLImageKHR image,
|
||||
int *fds,
|
||||
EGLint *strides,
|
||||
EGLint *offsets);
|
||||
|
||||
New Tokens
|
||||
|
||||
None
|
||||
|
||||
|
||||
Additions to the EGL 1.4 Specification:
|
||||
|
||||
To mirror the import extension, this extension attempts to return
|
||||
enough information to enable an exported dma-buf to be imported
|
||||
via eglCreateImageKHR and EGL_LINUX_DMA_BUF_EXT token.
|
||||
|
||||
Retrieving the information is a two step process, so two APIs
|
||||
are required.
|
||||
|
||||
The first entrypoint
|
||||
EGLBoolean eglExportDMABUFImageQueryMESA(EGLDisplay dpy,
|
||||
EGLImageKHR image,
|
||||
int *fourcc,
|
||||
int *num_planes,
|
||||
EGLuint64KHR *modifiers);
|
||||
|
||||
is used to retrieve the pixel format of the buffer, as specified by
|
||||
drm_fourcc.h, the number of planes in the image and the Linux
|
||||
drm modifiers. <fourcc>, <num_planes> and <modifiers> may be NULL,
|
||||
in which case no value is retrieved.
|
||||
|
||||
The second entrypoint retrieves the dma_buf file descriptors,
|
||||
strides and offsets for the image. The caller should pass
|
||||
arrays sized according to the num_planes values retrieved previously.
|
||||
Passing arrays of the wrong size will have undefined results.
|
||||
If the number of fds is less than the number of planes, then
|
||||
subsequent fd slots should contain -1.
|
||||
|
||||
EGLBoolean eglExportDMABUFImageMESA(EGLDisplay dpy,
|
||||
EGLImageKHR image,
|
||||
int *fds,
|
||||
EGLint *strides,
|
||||
EGLint *offsets);
|
||||
|
||||
<fds>, <strides>, <offsets> can be NULL if the infomatation isn't
|
||||
required by the caller.
|
||||
|
||||
Issues
|
||||
|
||||
1. Should the API look more like an attribute getting API?
|
||||
|
||||
ANSWER: No, from a user interface pov, having to iterate across calling
|
||||
the API up to 12 times using attribs seems like the wrong solution.
|
||||
|
||||
2. Should the API take a plane and just get the fd/stride/offset for that
|
||||
plane?
|
||||
|
||||
ANSWER: UNKNOWN,this might be just as valid an API.
|
||||
|
||||
3. Does ownership of the file descriptor remain with the app?
|
||||
|
||||
ANSWER: Yes, the app is responsible for closing any fds retrieved.
|
||||
|
||||
4. If number of planes and number of fds differ what should we do?
|
||||
|
||||
ANSWER: Return -1 for the secondary slots, as this avoids having
|
||||
to dup the fd extra times to make the interface sane.
|
||||
|
||||
Revision History
|
||||
|
||||
Version 3, May, 2015
|
||||
Just use the KHR 64-bit type.
|
||||
Version 2, March, 2015
|
||||
Add a query interface (Dave Airlie)
|
||||
Version 1, June 3, 2014
|
||||
Initial draft (Dave Airlie)
|
||||
|
||||
@@ -0,0 +1,158 @@
|
||||
Name
|
||||
|
||||
MESA_multithread_makecurrent
|
||||
|
||||
Name Strings
|
||||
|
||||
GLX_MESA_multithread_makecurrent
|
||||
|
||||
Contact
|
||||
|
||||
Eric Anholt (eric@anholt.net)
|
||||
|
||||
Status
|
||||
|
||||
Not shipping.
|
||||
|
||||
Version
|
||||
|
||||
Last Modified Date: 21 February 2011
|
||||
|
||||
Number
|
||||
|
||||
TBD
|
||||
|
||||
Dependencies
|
||||
|
||||
OpenGL 1.0 or later is required.
|
||||
GLX 1.3 or later is required.
|
||||
|
||||
Overview
|
||||
|
||||
The GLX context setup encourages multithreaded applications to
|
||||
create a context per thread which each operate on their own
|
||||
objects in parallel, and leaves synchronization for write access
|
||||
to shared objects up to the application.
|
||||
|
||||
For some applications, maintaining per-thread contexts and
|
||||
ensuring that the glFlush happens in one thread before another
|
||||
thread starts working on that object is difficult. For them,
|
||||
using the same context across multiple threads and protecting its
|
||||
usage with a mutex is both higher performance and easier to
|
||||
implement. This extension gives those applications that option by
|
||||
relaxing the context binding requirements.
|
||||
|
||||
This new behavior matches the requirements of AGL, while providing
|
||||
a feature not specified in WGL.
|
||||
|
||||
IP Status
|
||||
|
||||
Open-source; freely implementable.
|
||||
|
||||
Issues
|
||||
|
||||
None.
|
||||
|
||||
New Procedures and Functions
|
||||
|
||||
None.
|
||||
|
||||
New Tokens
|
||||
|
||||
None.
|
||||
|
||||
Changes to Chapter 2 of the GLX 1.3 Specification (Functions and Errors)
|
||||
|
||||
Replace the following sentence from section 2.2 Rendering Contexts:
|
||||
In addition, a rendering context can be current for only one
|
||||
thread at a time.
|
||||
with:
|
||||
In addition, an indirect rendering context can be current for
|
||||
only one thread at a time. A direct rendering context may be
|
||||
current to multiple threads, with synchronization of access to
|
||||
the context thruogh the GL managed by the application through
|
||||
mutexes.
|
||||
|
||||
Changes to Chapter 3 of the GLX 1.3 Specification (Functions and Errors)
|
||||
|
||||
Replace the following sentence from section 3.3.7 Rendering Contexts:
|
||||
If ctx is current to some other thread, then
|
||||
glXMakeContextCurrent will generate a BadAccess error.
|
||||
with:
|
||||
If ctx is an indirect context current to some other thread,
|
||||
then glXMakeContextCurrent will generate a BadAccess error.
|
||||
|
||||
Replace the following sentence from section 3.5 Rendering Contexts:
|
||||
If ctx is current to some other thread, then
|
||||
glXMakeCurrent will generate a BadAccess error.
|
||||
with:
|
||||
If ctx is an indirect context current to some other thread,
|
||||
then glXMakeCurrent will generate a BadAccess error.
|
||||
|
||||
GLX Protocol
|
||||
|
||||
None. The GLX extension only extends to direct rendering contexts.
|
||||
|
||||
Errors
|
||||
|
||||
None.
|
||||
|
||||
New State
|
||||
|
||||
None.
|
||||
|
||||
Issues
|
||||
|
||||
(1) What happens if the app binds a context/drawable in multiple
|
||||
threads, then binds a different context/thread in one of them?
|
||||
|
||||
As with binding a new context from the current thread, the old
|
||||
context's refcount is reduced and the new context's refcount is
|
||||
increased.
|
||||
|
||||
(2) What happens if the app binds a context/drawable in multiple
|
||||
threads, then binds None/None in one of them?
|
||||
|
||||
The GLX context is unreferenced from that thread, and the other
|
||||
threads retain their GLX context binding.
|
||||
|
||||
(3) What happens if the app binds a context/drawable in 7 threads,
|
||||
then destroys the context in one of them?
|
||||
|
||||
As with GLX context destruction previously, the XID is destroyed
|
||||
but the context remains usable by threads that have the context
|
||||
current.
|
||||
|
||||
(4) What happens if the app binds a new drawable/readable with
|
||||
glXMakeCurrent() when it is already bound to another thread?
|
||||
|
||||
The context becomes bound to the new drawable/readable, and
|
||||
further rendering in either thread will use the new
|
||||
drawable/readable.
|
||||
|
||||
(5) What requirements should be placed on the user managing contexts
|
||||
from multiple threads?
|
||||
|
||||
The intention is to allow multithreaded access to the GL at the
|
||||
minimal performance cost, so requiring that the GL do general
|
||||
synchronization (beyond that already required by context sharing)
|
||||
is not an option, and synchronizing of GL's access to the GL
|
||||
context between multiple threads is left to the application to do
|
||||
across GL calls. However, it would be unfortunate for a library
|
||||
doing multithread_makecurrent to require that other libraries
|
||||
share in synchronization for binding of their own contexts, so the
|
||||
refcounting of the contexts is required to be threadsafe.
|
||||
|
||||
(6) Does this apply to indirect contexts?
|
||||
|
||||
This was ignored in the initial revision of the spec. Behavior
|
||||
for indirect contexts is left as-is.
|
||||
|
||||
Revision History
|
||||
|
||||
20 November 2009 Eric Anholt - initial specification
|
||||
22 November 2009 Eric Anholt - added issues from Ian Romanick.
|
||||
3 February 2011 Eric Anholt - updated with resolution to issues 1-3
|
||||
3 February 2011 Eric Anholt - added issue 4, 5
|
||||
21 February 2011 Eric Anholt - Include glXMakeCurrent() sentence
|
||||
along with glXMakeContextCurrent() for removal.
|
||||
@@ -0,0 +1,138 @@
|
||||
Name
|
||||
|
||||
MESA_pack_invert
|
||||
|
||||
Name Strings
|
||||
|
||||
GL_MESA_pack_invert
|
||||
|
||||
Contact
|
||||
|
||||
Brian Paul, Tungsten Graphics, Inc. (brian.paul 'at' tungstengraphics.com)
|
||||
Keith Whitwell, Tungsten Graphics, Inc. (keith 'at' tungstengraphics.com)
|
||||
|
||||
Status
|
||||
|
||||
Shipping (Mesa 4.0.4 and later)
|
||||
|
||||
Version
|
||||
|
||||
1.0
|
||||
|
||||
Number
|
||||
|
||||
TBD
|
||||
|
||||
Dependencies
|
||||
|
||||
OpenGL 1.0 or later is required
|
||||
This extensions is written against the OpenGL 1.4 Specification.
|
||||
|
||||
Overview
|
||||
|
||||
This extension adds a new pixel storage parameter to indicate that
|
||||
images are to be packed in top-to-bottom order instead of OpenGL's
|
||||
conventional bottom-to-top order. Only pixel packing can be
|
||||
inverted (i.e. for glReadPixels, glGetTexImage, glGetConvolutionFilter,
|
||||
etc).
|
||||
|
||||
Almost all known image file formats store images in top-to-bottom
|
||||
order. As it is, OpenGL reads images from the frame buffer in
|
||||
bottom-to-top order. Thus, images usually have to be inverted before
|
||||
writing them to a file with image I/O libraries. This extension
|
||||
allows images to be read such that inverting isn't needed.
|
||||
|
||||
IP Status
|
||||
|
||||
None
|
||||
|
||||
Issues
|
||||
|
||||
1. Should we also define UNPACK_INVERT_MESA for glDrawPixels, etc?
|
||||
|
||||
Resolved: No, we're only concerned with pixel packing. There are other
|
||||
solutions for inverting images when using glDrawPixels (negative Y pixel
|
||||
zoom) or glTexImage (invert the vertex T coordinates). It would be easy
|
||||
enough to define a complementary extension for pixel packing in the
|
||||
future if needed.
|
||||
|
||||
New Procedures and Functions
|
||||
|
||||
None
|
||||
|
||||
New Tokens
|
||||
|
||||
Accepted by the <pname> parameter of PixelStorei and PixelStoref
|
||||
and the <pname> parameter of GetIntegerv, GetFloatv, GetDoublev
|
||||
and GetBooleanv:
|
||||
|
||||
PACK_INVERT_MESA 0x8758
|
||||
|
||||
Additions to Chapter 2 of the OpenGL 1.4 Specification (OpenGL Operation)
|
||||
|
||||
None
|
||||
|
||||
Additions to Chapter 3 of the OpenGL 1.4 Specification (Rasterization)
|
||||
|
||||
None
|
||||
|
||||
Additions to Chapter 4 of the OpenGL 1.4 Specification (Per-Fragment
|
||||
Operations and the Frame Buffer)
|
||||
|
||||
Add the following entry to table 4.4 (PixelStore parameters) on page 182:
|
||||
|
||||
Parameter Name Type Initial Value Valid Range
|
||||
---------------------------------------------------------
|
||||
PACK_INVERT_MESA boolean FALSE TRUE/FALSE
|
||||
|
||||
In the section labeled "Placement in Client Memory" on page 184
|
||||
insert the following text into the paragraph before the sentence
|
||||
that starts with "If the format is RED, GREEN, BLUE...":
|
||||
|
||||
"The parameter PACK_INVERT_MESA controls whether the image is packed
|
||||
in bottom-to-top order (the default) or top-to-bottom order. Equation
|
||||
3.8 is modified as follows:
|
||||
|
||||
... the first element of the Nth row is indicated by
|
||||
|
||||
p + Nk, if PACK_INVERT_MESA is false
|
||||
p + k * (H - 1) - Nk, if PACK_INVERT_MESA is true, where H is the
|
||||
image height
|
||||
"
|
||||
|
||||
Additions to Chapter 5 of the OpenGL 1.4 Specification (Special Functions)
|
||||
|
||||
None
|
||||
|
||||
Additions to Chapter 6 of the OpenGL 1.4 Specification (State and
|
||||
State Requests)
|
||||
|
||||
None
|
||||
|
||||
Additions to Appendix A of the OpenGL 1.4 Specification (Invariance)
|
||||
|
||||
None
|
||||
|
||||
Additions to the AGL/GLX/WGL Specifications
|
||||
|
||||
None
|
||||
|
||||
GLX Protocol
|
||||
|
||||
None
|
||||
|
||||
Errors
|
||||
|
||||
None
|
||||
|
||||
New State
|
||||
|
||||
Add the following entry to table 6.20 (Pixels) on page 235:
|
||||
|
||||
Get Value Type Get Cmd Initial Value Description Sec Attribute
|
||||
--------------------------------------------------------------------------------------------------
|
||||
PACK_INVERT_MESA boolean GetBoolean FALSE Value of PACK_INVERT_MESA 4.3.2 pixel-store
|
||||
|
||||
Revision History
|
||||
|
||||
21 September 2002 - Initial draft
|
||||
@@ -0,0 +1,90 @@
|
||||
Name
|
||||
|
||||
MESA_pixmap_colormap
|
||||
|
||||
Name Strings
|
||||
|
||||
GLX_MESA_pixmap_colormap
|
||||
|
||||
Contact
|
||||
|
||||
Brian Paul (brian.paul 'at' tungstengraphics.com)
|
||||
|
||||
Status
|
||||
|
||||
Shipping since Mesa 1.2.8 in May, 1996.
|
||||
|
||||
Version
|
||||
|
||||
Last Modified Date: 8 June 2000
|
||||
|
||||
Number
|
||||
|
||||
216
|
||||
|
||||
Dependencies
|
||||
|
||||
OpenGL 1.0 or later is required.
|
||||
GLX 1.0 or later is required.
|
||||
|
||||
Overview
|
||||
|
||||
Since Mesa allows RGB rendering into drawables with PseudoColor,
|
||||
StaticColor, GrayScale and StaticGray visuals, Mesa needs a colormap
|
||||
in order to compute pixel values during rendering.
|
||||
|
||||
The colormap associated with a window can be queried with normal
|
||||
Xlib functions but there is no colormap associated with pixmaps.
|
||||
|
||||
The glXCreateGLXPixmapMESA function is an alternative to glXCreateGLXPixmap
|
||||
which allows specification of a colormap.
|
||||
|
||||
IP Status
|
||||
|
||||
Open-source; freely implementable.
|
||||
|
||||
Issues
|
||||
|
||||
None.
|
||||
|
||||
New Procedures and Functions
|
||||
|
||||
GLXPixmap glXCreateGLXPixmapMESA( Display *dpy, XVisualInfo *visual,
|
||||
Pixmap pixmap, Colormap cmap );
|
||||
|
||||
New Tokens
|
||||
|
||||
None.
|
||||
|
||||
Additions to Chapter 3 of the GLX 1.3 Specification (Functions and Errors)
|
||||
|
||||
Add to section 3.4.2 Off Screen Rendering
|
||||
|
||||
The Mesa implementation of GLX allows RGB rendering into X windows and
|
||||
pixmaps of any visual class, not just TrueColor or DirectColor. In order
|
||||
to compute pixel values from RGB values Mesa requires a colormap.
|
||||
|
||||
The function
|
||||
|
||||
GLXPixmap glXCreateGLXPixmapMESA( Display *dpy, XVisualInfo *visual,
|
||||
Pixmap pixmap, Colormap cmap );
|
||||
|
||||
allows one to create a GLXPixmap with a specific colormap. The image
|
||||
rendered into the pixmap may then be copied to a window (which uses the
|
||||
same colormap and visual) with the expected results.
|
||||
|
||||
GLX Protocol
|
||||
|
||||
None since this is a client-side extension.
|
||||
|
||||
Errors
|
||||
|
||||
None.
|
||||
|
||||
New State
|
||||
|
||||
None.
|
||||
|
||||
Revision History
|
||||
|
||||
8 June 2000 - initial specification
|
||||
@@ -0,0 +1,385 @@
|
||||
Name
|
||||
|
||||
MESA_query_renderer
|
||||
|
||||
Name Strings
|
||||
|
||||
GLX_MESA_query_renderer
|
||||
|
||||
Contact
|
||||
|
||||
Ian Romanick <ian.d.romanick@intel.com>
|
||||
|
||||
IP Status
|
||||
|
||||
No known IP claims.
|
||||
|
||||
Status
|
||||
|
||||
Shipping as of Mesa 10.0
|
||||
|
||||
Version
|
||||
|
||||
Version 9, 09 November 2018
|
||||
|
||||
Number
|
||||
|
||||
OpenGL Extension #446
|
||||
|
||||
Dependencies
|
||||
|
||||
GLX 1.4 is required.
|
||||
|
||||
GLX_ARB_create_context and GLX_ARB_create_context_profile are required.
|
||||
|
||||
Overview
|
||||
|
||||
In many situations, applications want to detect characteristics of a
|
||||
rendering device before creating a context for that device. Information
|
||||
gathered at this stage may guide choices the application makes about
|
||||
color depth, number of samples per-pixel, texture quality, and so on.
|
||||
In addition, versions of supported APIs and implementation API
|
||||
preference may also guide start-up decisions made by the application.
|
||||
For example, one implementation may prefer vertex data be supplied using
|
||||
methods only available in a compatibility profile, but another
|
||||
implementation may only support the desired version in a core profile.
|
||||
|
||||
There are also cases where more than one renderer may be available per
|
||||
display. For example, there is typically a hardware implementation and
|
||||
a software based implementation. There are cases where an application
|
||||
may want to pick one over the other. One such situation is when the
|
||||
software implementation supports more features than the hardware
|
||||
implementation. Another situation is when a particular version of the
|
||||
hardware implementation is blacklisted due to known bugs.
|
||||
|
||||
This extension provides a mechanism for the application to query all of
|
||||
the available renderers for a particular display and screen. In
|
||||
addition, this extension provides a mechanism for applications to create
|
||||
contexts with respect to a specific renderer.
|
||||
|
||||
New Procedures and Functions
|
||||
|
||||
Bool glXQueryRendererIntegerMESA(Display *dpy, int screen,
|
||||
int renderer, int attribute,
|
||||
unsigned int *value);
|
||||
Bool glXQueryCurrentRendererIntegerMESA(int attribute, unsigned int *value);
|
||||
|
||||
const char *glXQueryRendererStringMESA(Display *dpy, int screen,
|
||||
int renderer, int attribute);
|
||||
|
||||
const char *glXQueryCurrentRendererStringMESA(int attribute);
|
||||
|
||||
New Tokens
|
||||
|
||||
Accepted as an <attribute> in glXQueryRendererIntegerMESA and
|
||||
glXQueryCurrentRendererIntegerMESA:
|
||||
|
||||
GLX_RENDERER_VENDOR_ID_MESA 0x8183
|
||||
GLX_RENDERER_DEVICE_ID_MESA 0x8184
|
||||
GLX_RENDERER_VERSION_MESA 0x8185
|
||||
GLX_RENDERER_ACCELERATED_MESA 0x8186
|
||||
GLX_RENDERER_VIDEO_MEMORY_MESA 0x8187
|
||||
GLX_RENDERER_UNIFIED_MEMORY_ARCHITECTURE_MESA 0x8188
|
||||
GLX_RENDERER_PREFERRED_PROFILE_MESA 0x8189
|
||||
GLX_RENDERER_OPENGL_CORE_PROFILE_VERSION_MESA 0x818A
|
||||
GLX_RENDERER_OPENGL_COMPATIBILITY_PROFILE_VERSION_MESA 0x818B
|
||||
GLX_RENDERER_OPENGL_ES_PROFILE_VERSION_MESA 0x818C
|
||||
GLX_RENDERER_OPENGL_ES2_PROFILE_VERSION_MESA 0x818D
|
||||
|
||||
Accepted as an <attribute> in glXQueryRendererStringMESA and
|
||||
glXQueryCurrentRendererStringMESA:
|
||||
|
||||
GLX_RENDERER_VENDOR_ID_MESA
|
||||
GLX_RENDERER_DEVICE_ID_MESA
|
||||
|
||||
Additions to the OpenGL / WGL Specifications
|
||||
|
||||
None. This specification is written for GLX.
|
||||
|
||||
Additions to the GLX 1.4 Specification
|
||||
|
||||
[Add to Section 3.3.2 "GLX Versioning" of the GLX Specification]
|
||||
|
||||
To obtain information about the available renderers for a particular
|
||||
display and screen,
|
||||
|
||||
Bool glXQueryRendererIntegerMESA(Display *dpy, int screen, int renderer,
|
||||
int attribute, unsigned int *value);
|
||||
|
||||
can be used. The value for <attribute> will be returned in one or more
|
||||
integers specified by <value>. The values, data sizes, and descriptions
|
||||
of each renderer attribute are listed in the table below.
|
||||
|
||||
GLX renderer attribute number description
|
||||
of values
|
||||
---------------------- --------- -----------
|
||||
GLX_RENDERER_VENDOR_ID_MESA 1 PCI ID of the device vendor
|
||||
GLX_RENDERER_DEVICE_ID_MESA 1 PCI ID of the device
|
||||
GLX_RENDERER_VERSION_MESA 3 Major, minor, and patch level of
|
||||
the renderer implementation
|
||||
GLX_RENDERER_ACCELERATED_MESA 1 Boolean indicating whether or
|
||||
not the renderer is hardware
|
||||
accelerated
|
||||
GLX_RENDERER_VIDEO_MEMORY_MESA 1 Number of megabytes of video
|
||||
memory available to the renderer
|
||||
GLX_RENDERER_UNIFIED_MEMORY_ARCHITECTURE_MESA
|
||||
1 Boolean indicating whether or
|
||||
not the renderer uses a unified
|
||||
memory architecture or has
|
||||
separate "on-card" and GART
|
||||
memory.
|
||||
GLX_RENDERER_PREFERRED_PROFILE_MESA
|
||||
1 Bitmask of the preferred context
|
||||
profile for this renderer. This
|
||||
value is suitable to be supplied
|
||||
with the
|
||||
GLX_CONTEXT_PROFILE_MASK_ARB
|
||||
attribute to
|
||||
glXCreateContextAttribsARB
|
||||
GLX_RENDERER_OPENGL_CORE_PROFILE_VERSION_MESA
|
||||
2 Maximum core profile major and
|
||||
minor version supported by the
|
||||
renderer
|
||||
GLX_RENDERER_OPENGL_COMPATIBILITY_PROFILE_VERSION_MESA
|
||||
2 Maximum compatibility profile
|
||||
major and minor version
|
||||
supported by the renderer
|
||||
GLX_RENDERER_OPENGL_ES_PROFILE_VERSION_MESA
|
||||
2 Maximum OpenGL ES 1.x
|
||||
major and minor version
|
||||
supported by the renderer
|
||||
GLX_RENDERER_OPENGL_ES2_PROFILE_VERSION_MESA
|
||||
2 Maximum OpenGL ES 2.x or 3.x
|
||||
major and minor version
|
||||
supported by the renderer
|
||||
|
||||
In the table, boolean attributes will have either the value 0 or 1.
|
||||
|
||||
GLX_RENDERER_OPENGL_CORE_PROFILE_VERSION_MESA,
|
||||
GLX_RENDERER_OPENGL_COMPATIBILITY_PROFILE_VERSION_MESA,
|
||||
GLX_RENDERER_OPENGL_ES_PROFILE_VERSION_MESA, and
|
||||
GLX_RENDERER_OPENGL_ES2_PROFILE_VERSION_MESA each return <0, 0> in
|
||||
*value if no version of that profile is supported.
|
||||
|
||||
GLX_RENDERER_VENDOR_ID_MESA and GLX_RENDERER_DEVICE_ID_MESA may return
|
||||
0xFFFFFFFF if the device does not have a PCI ID (because it is not a PCI
|
||||
device) or if the PCI ID is not available. In this case the application
|
||||
should rely on the string query instead.
|
||||
|
||||
If <attribute> is not a recognized value, False is returned, but no GLX
|
||||
error is generated. Otherwise, True is returned.
|
||||
|
||||
String versions of some attributes may also be queried using
|
||||
|
||||
const char *glXQueryRendererStringMESA(Display *dpy, int screen,
|
||||
int renderer, int attribute);
|
||||
|
||||
The value for <attribute> will be returned in one or more
|
||||
integers specified by <value>. The values, data sizes, and descriptions
|
||||
of each renderer attribute are listed in the table below.
|
||||
|
||||
GLX renderer attribute description
|
||||
---------------------- -----------
|
||||
GLX_RENDERER_VENDOR_ID_MESA Name of the renderer provider. This may
|
||||
differ from the vendor name of the
|
||||
underlying hardware.
|
||||
GLX_RENDERER_DEVICE_ID_MESA Name of the renderer. This may differ from
|
||||
the name of the underlying hardware (e.g.,
|
||||
for a software renderer).
|
||||
|
||||
If <attribute> is not a recognized value, NULL is returned, but no GLX
|
||||
error is generated.
|
||||
|
||||
The string returned for GLX_RENDERER_VENDOR_ID_MESA will have the same
|
||||
format as the string that would be returned by glGetString of GL_VENDOR.
|
||||
It may, however, have a different value.
|
||||
|
||||
The string returned for GLX_RENDERER_DEVICE_ID_MESA will have the same
|
||||
format as the string that would be returned by glGetString of GL_RENDERER.
|
||||
It may, however, have a different value.
|
||||
|
||||
Issues
|
||||
|
||||
1) How should the difference between on-card and GART memory be exposed?
|
||||
|
||||
UNRESOLVED.
|
||||
|
||||
2) How should memory limitations of unified memory architecture (UMA)
|
||||
systems be exposed?
|
||||
|
||||
UNRESOLVED. Some hardware has different per-process and global
|
||||
limits for memory that can be accessed within a single draw call.
|
||||
|
||||
3) How should the renderer's API preference be advertised?
|
||||
|
||||
UNRESOLVED. The common case for desktop renderers is to prefer
|
||||
either core or compatibility. However, some renderers may actually
|
||||
prefer an ES context. This leaves the application in a tough spot
|
||||
if it can only support core or compatibility and the renderer says it
|
||||
wants ES.
|
||||
|
||||
4) Should OpenGL ES 2.0 and OpenGL ES 3.0 be treated separately?
|
||||
|
||||
RESOLVED. No. OpenGL ES 3.0 is backwards compatible with OpenGL ES
|
||||
2.0. Applications can detect OpenGL ES 3.0 support by querying
|
||||
GLX_RENDERER_OPENGL_ES2_PROFILE_VERSION_MESA.
|
||||
|
||||
5) How can applications tell the difference between different hardware
|
||||
renderers for the same device? For example, whether the renderer is the
|
||||
open-source driver or the closed-source driver.
|
||||
|
||||
RESOLVED. Assuming this extension is ever implemented outside Mesa,
|
||||
applications can query GLX_RENDERER_VENDOR_ID_MESA from
|
||||
glXQueryRendererStringMESA. This will almost certainly return
|
||||
different strings for open-source and closed-source drivers.
|
||||
|
||||
6) What is the value of GLX_RENDERER_UNIFIED_MEMORY_ARCHITECTURE_MESA for
|
||||
software renderers?
|
||||
|
||||
UNRESOLVED. Video (display) memory and texture memory is not unified
|
||||
for software implementations, so it seems reasonable for this to be
|
||||
False.
|
||||
|
||||
7) How does an application determine the number of available renderers?
|
||||
|
||||
UNRESOLVED.
|
||||
|
||||
8) What happens if a fbconfig is used to create context on a renderer
|
||||
that cannot support it? For example, if a multisampled config is used
|
||||
with a software renderer that does not support multisampling.
|
||||
|
||||
RESOLVED. The language for glXCreateContextAttribsARB already covers
|
||||
this case. Context creation will fail, and BadMatch is generated.
|
||||
|
||||
9) In addition to being able to query the supported versions, should
|
||||
applications also be able to query the supported extensions?
|
||||
|
||||
RESOLVED. No. Desktop OpenGL core profiles and OpenGL ES 3.0 have
|
||||
moved away from the monolithic string returned by glGetString of
|
||||
GL_EXTENSIONS. Providing the newer indexed query would require adding
|
||||
a lot of extra infrastructure, and it would probably provide little
|
||||
benefit to applications.
|
||||
|
||||
10) What combination of values for GLX_RENDERER_PREFERRED_PROFILE_MESA,
|
||||
GLX_RENDERER_OPENGL_COMPATIBILITY_PROFILE_VERSION_MESA, and
|
||||
GLX_RENDERER_OPENGL_CORE_PROFILE_VERSION_MESA should be returned
|
||||
for a renderer that only supports OpenGL 3.1 without the
|
||||
GL_ARB_compatibility extension?
|
||||
|
||||
RESOLVED. The renderer will return GLX_CONTEXT_CORE_PROFILE_BIT_ARB
|
||||
for GLX_RENDERER_PREFERRED_PROFILE_MESA.
|
||||
|
||||
Further, the renderer will return <3,0> for
|
||||
GLX_RENDERER_OPENGL_COMPATIBILITY_PROFILE_VERSION_MESA because OpenGL
|
||||
3.1 without GL_ARB_compatibility is not backwards compatible with
|
||||
previous versions of OpenGL. The render will return <3,1> for
|
||||
GLX_RENDERER_OPENGL_CORE_PROFILE_VERSION_MESA indicating that support
|
||||
for OpenGL 3.1 is available.
|
||||
|
||||
Even though there is no OpenGL 3.1 core profile, the values
|
||||
returned for GLX_RENDERER_PREFERRED_PROFILE_MESA and
|
||||
GLX_RENDERER_OPENGL_CORE_PROFILE_VERSION_MESA can be supplied
|
||||
with the GLX_CONTEXT_PROFILE_MASK_ARB and
|
||||
GLX_CONTEXT_{MAJOR,MINOR}_VERSION_ARB attributes of
|
||||
glXCreateContextAttribsARB without error. If the requested
|
||||
OpenGL version is less than 3.2, the
|
||||
GLX_CONTEXT_PROFILE_MASK_ARB attribute is ignored by
|
||||
glXCreateContextAttribsARB.
|
||||
|
||||
11) How can application learn about multi-GPU (e.g., SLI, CrossFireX,
|
||||
etc.) configurations?
|
||||
|
||||
UNRESOLVED. Based on ISV feedback, this is important information to
|
||||
provide to the application. Given the variety of possible hardware
|
||||
configurations (e.g., Hybrid CrossFireX) and different rendering
|
||||
modes (e.g., split-frame rendering vs. alternate-frame rendering),
|
||||
it's not clear how this information can be communicated.
|
||||
|
||||
It is likely that this will be left to a layered extension.
|
||||
|
||||
12) Should capability queries similar to those in
|
||||
GL_ARB_internalformat_query or GL_ARB_internalformat_query2 be added?
|
||||
|
||||
RESOLVED. No. With the possible exception of the texture size
|
||||
queries, it seems unlikely that applications would ever use this
|
||||
information before creating a context.
|
||||
|
||||
13) Existing GL extensions (e.g., GL_ATI_meminfo and
|
||||
GL_NVX_gpu_memory_info) allow easy queries after context creation. With
|
||||
this extension it is a bit of a pain for a portable application to query
|
||||
the information after context creation.
|
||||
|
||||
RESOLVED. Add versions of the queries that implicitly take the
|
||||
display, screen, and renderer from the currently bound context.
|
||||
|
||||
14) Why not make the queries from issue #13 GL functions (instead of GLX)?
|
||||
|
||||
RESOLVED. It is fairly compelling for the post-creation queries to
|
||||
just use glGetInteger and glGetString. However, the GL enums and
|
||||
the GLX enums would have different names and would almost certainly
|
||||
have different values. It seems like this would cause more problems
|
||||
than it would solve.
|
||||
|
||||
15) Should the string queries be required to return the same values as
|
||||
glGetString(GL_VENDOR) and glGetString(GL_RENDERER)?
|
||||
|
||||
UNRESOLVED. This may be useful for applications that already do
|
||||
device detection based on these strings.
|
||||
|
||||
16) What type should the value parameter of glXQueryRendererIntegerMESA
|
||||
and glXQueryCurrentRendererIntegerMESA be?
|
||||
|
||||
UNRESOLVED. Other similar GLX query functions just use int or
|
||||
unsigned int, so that's what this extension uses for now. However,
|
||||
an expeclitly sized value, such as uint32_t or uint64_t, seems
|
||||
preferable.
|
||||
|
||||
17) What about SoCs and other systems that don't have PCI?
|
||||
|
||||
RESOLVED. The GLX_RENDERER_VENDOR_ID_MESA and
|
||||
GLX_RENDERER_DEVICE_ID_MESA integer queries may return 0xFFFFFFFF if a
|
||||
PCI ID either does not exist or is not available. Implementations
|
||||
should make every attempt to return as much information as is
|
||||
possible. For example, if the implementation is running on a non-PCI
|
||||
SoC with a Qualcomm GPU, GLX_RENDERER_VENDOR_ID_MESA should return
|
||||
0x5143, but GLX_RENDERER_DEVICE_ID_MESA will return 0xFFFFFFFF.
|
||||
|
||||
Revision History
|
||||
|
||||
Version 1, 2012/08/27 - Initial version
|
||||
|
||||
Version 2, 2012/09/04 - Specify behavior of implementations that
|
||||
do not support certain profiles.
|
||||
Change wording of issue #8 to be more
|
||||
clear.
|
||||
Make some wording changes to issue #10 to
|
||||
clarify the resolution a bit.
|
||||
|
||||
Version 3, 2012/09/23 - Add issue #11 regarding multi-GPU systems.
|
||||
|
||||
Version 4, 2013/02/01 - Add issue #12 regarding texture / renderbuffer
|
||||
format queries.
|
||||
|
||||
Version 5, 2013/02/14 - Add issues #13 and #14 regarding simpler queires
|
||||
after the context is created and made current.
|
||||
Add issue #15 regarding the string query.
|
||||
Add issue #16 regarding the value type returned
|
||||
by the Integer functions.
|
||||
|
||||
Version 6, 2013/10/25 - Fix a typo. Update the list of functions to
|
||||
which the new enums can be passed. The "Current"
|
||||
versions were previously missing.
|
||||
|
||||
Version 7, 2013/11/07 - Fix a couple more typos. Add issue #17 regarding
|
||||
the PCI queries on systems that don't have PCI.
|
||||
|
||||
Version 8, 2014/02/14 - Fix a couple typos. GLX_RENDER_ID_MESA should
|
||||
read GLX_RENDERER_ID_MESA. The VENDOR/DEVICE_ID
|
||||
example given in issue #17 should be 0x5143 and
|
||||
0xFFFFFFFF respectively.
|
||||
|
||||
Version 9, 2018/11/09 - Remove GLX_RENDERER_ID_MESA, which has never been
|
||||
implemented. Remove the unnecessary interactions
|
||||
with the GLX GLES profile extensions. Note the
|
||||
official GL extension number. Specify the section
|
||||
of the GLX spec to modify.
|
||||
@@ -0,0 +1,85 @@
|
||||
Name
|
||||
|
||||
MESA_release_buffers
|
||||
|
||||
Name Strings
|
||||
|
||||
GLX_MESA_release_buffers
|
||||
|
||||
Contact
|
||||
|
||||
Brian Paul (brian.paul 'at' tungstengraphics.com)
|
||||
|
||||
Status
|
||||
|
||||
Shipping since Mesa 2.0 in October, 1996.
|
||||
|
||||
Version
|
||||
|
||||
Last Modified Date: 8 June 2000
|
||||
|
||||
Number
|
||||
|
||||
217
|
||||
|
||||
Dependencies
|
||||
|
||||
OpenGL 1.0 or later is required.
|
||||
GLX 1.0 or later is required.
|
||||
|
||||
Overview
|
||||
|
||||
Mesa's implementation of GLX is entirely implemented on the client side.
|
||||
Therefore, Mesa cannot immediately detect when an X window or pixmap is
|
||||
destroyed in order to free any ancillary data associated with the window
|
||||
or pixmap.
|
||||
|
||||
The glxMesaReleaseBuffers() function can be used to explicitly indicate
|
||||
when the back color buffer, depth buffer, stencil buffer, and/or accumu-
|
||||
lation buffer associated with a drawable can be freed.
|
||||
|
||||
IP Status
|
||||
|
||||
Open-source; freely implementable.
|
||||
|
||||
Issues
|
||||
|
||||
None.
|
||||
|
||||
New Procedures and Functions
|
||||
|
||||
Bool glXReleaseBuffersMESA( Display *dpy, GLXDrawable d );
|
||||
|
||||
New Tokens
|
||||
|
||||
None.
|
||||
|
||||
Additions to Chapter 3 of the GLX 1.3 Specification (Functions and Errors)
|
||||
|
||||
The function
|
||||
|
||||
Bool glXReleaseBuffersMESA( Display *dpy, GLXDrawable d );
|
||||
|
||||
causes all software ancillary buffers (back buffer, depth, stencil,
|
||||
accum, etc) associated with the named drawable to be immediately
|
||||
deallocated. True is returned if <d> is a valid Mesa GLX drawable,
|
||||
else False is returned. After calling glXReleaseBuffersMESA, the
|
||||
drawable should no longer be used for GL rendering. Results of
|
||||
attempting to do so are undefined.
|
||||
|
||||
|
||||
GLX Protocol
|
||||
|
||||
None, since this is a client-side operation.
|
||||
|
||||
Errors
|
||||
|
||||
None.
|
||||
|
||||
New State
|
||||
|
||||
None.
|
||||
|
||||
Revision History
|
||||
|
||||
8 June 2000 - initial specification
|
||||
@@ -0,0 +1,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,522 @@
|
||||
Name
|
||||
|
||||
MESA_shader_integer_functions
|
||||
|
||||
Name Strings
|
||||
|
||||
GL_MESA_shader_integer_functions
|
||||
|
||||
Contact
|
||||
|
||||
Ian Romanick <ian.d.romanick@intel.com>
|
||||
|
||||
Contributors
|
||||
|
||||
All the contributors of GL_ARB_gpu_shader5
|
||||
|
||||
Status
|
||||
|
||||
Supported by all GLSL 1.30 capable drivers in Mesa 12.1 and later
|
||||
|
||||
Version
|
||||
|
||||
Version 3, March 31, 2017
|
||||
|
||||
Number
|
||||
|
||||
OpenGL Extension #495
|
||||
|
||||
Dependencies
|
||||
|
||||
This extension is written against the OpenGL 3.2 (Compatibility Profile)
|
||||
Specification.
|
||||
|
||||
This extension is written against Version 1.50 (Revision 09) of the OpenGL
|
||||
Shading Language Specification.
|
||||
|
||||
GLSL 1.30 (OpenGL) or GLSL ES 3.00 (OpenGL ES) is required.
|
||||
|
||||
This extension interacts with ARB_gpu_shader5.
|
||||
|
||||
This extension interacts with ARB_gpu_shader_fp64.
|
||||
|
||||
This extension interacts with NV_gpu_shader5.
|
||||
|
||||
Overview
|
||||
|
||||
GL_ARB_gpu_shader5 extends GLSL in a number of useful ways. Much of this
|
||||
added functionality requires significant hardware support. There are many
|
||||
aspects, however, that can be easily implmented on any GPU with "real"
|
||||
integer support (as opposed to simulating integers using floating point
|
||||
calculations).
|
||||
|
||||
This extension provides a set of new features to the OpenGL Shading
|
||||
Language to support capabilities of these GPUs, extending the
|
||||
capabilities of version 1.30 of the OpenGL Shading Language and version
|
||||
3.00 of the OpenGL ES Shading Language. Shaders using the new
|
||||
functionality provided by this extension should enable this
|
||||
functionality via the construct
|
||||
|
||||
#extension GL_MESA_shader_integer_functions : require (or enable)
|
||||
|
||||
This extension provides a variety of new features for all shader types,
|
||||
including:
|
||||
|
||||
* support for implicitly converting signed integer types to unsigned
|
||||
types, as well as more general implicit conversion and function
|
||||
overloading infrastructure to support new data types introduced by
|
||||
other extensions;
|
||||
|
||||
* new built-in functions supporting:
|
||||
|
||||
* splitting a floating-point number into a significand and exponent
|
||||
(frexp), or building a floating-point number from a significand and
|
||||
exponent (ldexp);
|
||||
|
||||
* integer bitfield manipulation, including functions to find the
|
||||
position of the most or least significant set bit, count the number
|
||||
of one bits, and bitfield insertion, extraction, and reversal;
|
||||
|
||||
* extended integer precision math, including add with carry, subtract
|
||||
with borrow, and extenended multiplication;
|
||||
|
||||
The resulting extension is a strict subset of GL_ARB_gpu_shader5.
|
||||
|
||||
IP Status
|
||||
|
||||
No known IP claims.
|
||||
|
||||
New Procedures and Functions
|
||||
|
||||
None
|
||||
|
||||
New Tokens
|
||||
|
||||
None
|
||||
|
||||
Additions to Chapter 2 of the OpenGL 3.2 (Compatibility Profile) Specification
|
||||
(OpenGL Operation)
|
||||
|
||||
None.
|
||||
|
||||
Additions to Chapter 3 of the OpenGL 3.2 (Compatibility Profile) Specification
|
||||
(Rasterization)
|
||||
|
||||
None.
|
||||
|
||||
Additions to Chapter 4 of the OpenGL 3.2 (Compatibility Profile) Specification
|
||||
(Per-Fragment Operations and the Frame Buffer)
|
||||
|
||||
None.
|
||||
|
||||
Additions to Chapter 5 of the OpenGL 3.2 (Compatibility Profile) Specification
|
||||
(Special Functions)
|
||||
|
||||
None.
|
||||
|
||||
Additions to Chapter 6 of the OpenGL 3.2 (Compatibility Profile) Specification
|
||||
(State and State Requests)
|
||||
|
||||
None.
|
||||
|
||||
Additions to Appendix A of the OpenGL 3.2 (Compatibility Profile)
|
||||
Specification (Invariance)
|
||||
|
||||
None.
|
||||
|
||||
Additions to the AGL/GLX/WGL Specifications
|
||||
|
||||
None.
|
||||
|
||||
Modifications to The OpenGL Shading Language Specification, Version 1.50
|
||||
(Revision 09)
|
||||
|
||||
Including the following line in a shader can be used to control the
|
||||
language features described in this extension:
|
||||
|
||||
#extension GL_MESA_shader_integer_functions : <behavior>
|
||||
|
||||
where <behavior> is as specified in section 3.3.
|
||||
|
||||
New preprocessor #defines are added to the OpenGL Shading Language:
|
||||
|
||||
#define GL_MESA_shader_integer_functions 1
|
||||
|
||||
|
||||
Modify Section 4.1.10, Implicit Conversions, p. 27
|
||||
|
||||
(modify table of implicit conversions)
|
||||
|
||||
Can be implicitly
|
||||
Type of expression converted to
|
||||
--------------------- -----------------
|
||||
int uint, float
|
||||
ivec2 uvec2, vec2
|
||||
ivec3 uvec3, vec3
|
||||
ivec4 uvec4, vec4
|
||||
|
||||
uint float
|
||||
uvec2 vec2
|
||||
uvec3 vec3
|
||||
uvec4 vec4
|
||||
|
||||
(modify second paragraph of the section) No implicit conversions are
|
||||
provided to convert from unsigned to signed integer types or from
|
||||
floating-point to integer types. There are no implicit array or structure
|
||||
conversions.
|
||||
|
||||
(insert before the final paragraph of the section) When performing
|
||||
implicit conversion for binary operators, there may be multiple data types
|
||||
to which the two operands can be converted. For example, when adding an
|
||||
int value to a uint value, both values can be implicitly converted to uint
|
||||
and float. In such cases, a floating-point type is chosen if either
|
||||
operand has a floating-point type. Otherwise, an unsigned integer type is
|
||||
chosen if either operand has an unsigned integer type. Otherwise, a
|
||||
signed integer type is chosen.
|
||||
|
||||
|
||||
Modify Section 5.9, Expressions, p. 57
|
||||
|
||||
(modify bulleted list as follows, adding support for implicit conversion
|
||||
between signed and unsigned types)
|
||||
|
||||
Expressions in the shading language are built from the following:
|
||||
|
||||
* Constants of type bool, int, int64_t, uint, uint64_t, float, all vector
|
||||
types, and all matrix types.
|
||||
|
||||
...
|
||||
|
||||
* The operator modulus (%) operates on signed or unsigned integer scalars
|
||||
or vectors. If the fundamental types of the operands do not match, the
|
||||
conversions from Section 4.1.10 "Implicit Conversions" are applied to
|
||||
produce matching types. ...
|
||||
|
||||
|
||||
Modify Section 6.1, Function Definitions, p. 63
|
||||
|
||||
(modify description of overloading, beginning at the top of p. 64)
|
||||
|
||||
Function names can be overloaded. The same function name can be used for
|
||||
multiple functions, as long as the parameter types differ. If a function
|
||||
name is declared twice with the same parameter types, then the return
|
||||
types and all qualifiers must also match, and it is the same function
|
||||
being declared. For example,
|
||||
|
||||
vec4 f(in vec4 x, out vec4 y); // (A)
|
||||
vec4 f(in vec4 x, out uvec4 y); // (B) okay, different argument type
|
||||
vec4 f(in ivec4 x, out uvec4 y); // (C) okay, different argument type
|
||||
|
||||
int f(in vec4 x, out ivec4 y); // error, only return type differs
|
||||
vec4 f(in vec4 x, in vec4 y); // error, only qualifier differs
|
||||
vec4 f(const in vec4 x, out vec4 y); // error, only qualifier differs
|
||||
|
||||
When function calls are resolved, an exact type match for all the
|
||||
arguments is sought. If an exact match is found, all other functions are
|
||||
ignored, and the exact match is used. If no exact match is found, then
|
||||
the implicit conversions in Section 4.1.10 (Implicit Conversions) will be
|
||||
applied to find a match. Mismatched types on input parameters (in or
|
||||
inout or default) must have a conversion from the calling argument type
|
||||
to the formal parameter type. Mismatched types on output parameters (out
|
||||
or inout) must have a conversion from the formal parameter type to the
|
||||
calling argument type.
|
||||
|
||||
If implicit conversions can be used to find more than one matching
|
||||
function, a single best-matching function is sought. To determine a best
|
||||
match, the conversions between calling argument and formal parameter
|
||||
types are compared for each function argument and pair of matching
|
||||
functions. After these comparisons are performed, each pair of matching
|
||||
functions are compared. A function definition A is considered a better
|
||||
match than function definition B if:
|
||||
|
||||
* for at least one function argument, the conversion for that argument
|
||||
in A is better than the corresponding conversion in B; and
|
||||
|
||||
* there is no function argument for which the conversion in B is better
|
||||
than the corresponding conversion in A.
|
||||
|
||||
If a single function definition is considered a better match than every
|
||||
other matching function definition, it will be used. Otherwise, a
|
||||
semantic error occurs and the shader will fail to compile.
|
||||
|
||||
To determine whether the conversion for a single argument in one match is
|
||||
better than that for another match, the following rules are applied, in
|
||||
order:
|
||||
|
||||
1. An exact match is better than a match involving any implicit
|
||||
conversion.
|
||||
|
||||
2. A match involving an implicit conversion from float to double is
|
||||
better than a match involving any other implicit conversion.
|
||||
|
||||
3. A match involving an implicit conversion from either int or uint to
|
||||
float is better than a match involving an implicit conversion from
|
||||
either int or uint to double.
|
||||
|
||||
If none of the rules above apply to a particular pair of conversions,
|
||||
neither conversion is considered better than the other.
|
||||
|
||||
For the function prototypes (A), (B), and (C) above, the following
|
||||
examples show how the rules apply to different sets of calling argument
|
||||
types:
|
||||
|
||||
f(vec4, vec4); // exact match of vec4 f(in vec4 x, out vec4 y)
|
||||
f(vec4, uvec4); // exact match of vec4 f(in vec4 x, out ivec4 y)
|
||||
f(vec4, ivec4); // matched to vec4 f(in vec4 x, out vec4 y)
|
||||
// (C) not relevant, can't convert vec4 to
|
||||
// ivec4. (A) better than (B) for 2nd
|
||||
// argument (rule 2), same on first argument.
|
||||
f(ivec4, vec4); // NOT matched. All three match by implicit
|
||||
// conversion. (C) is better than (A) and (B)
|
||||
// on the first argument. (A) is better than
|
||||
// (B) and (C).
|
||||
|
||||
|
||||
Modify Section 8.3, Common Functions, p. 84
|
||||
|
||||
(add support for single-precision frexp and ldexp functions)
|
||||
|
||||
Syntax:
|
||||
|
||||
genType frexp(genType x, out genIType exp);
|
||||
genType ldexp(genType x, in genIType exp);
|
||||
|
||||
The function frexp() splits each single-precision floating-point number in
|
||||
<x> into a binary significand, a floating-point number in the range [0.5,
|
||||
1.0), and an integral exponent of two, such that:
|
||||
|
||||
x = significand * 2 ^ exponent
|
||||
|
||||
The significand is returned by the function; the exponent is returned in
|
||||
the parameter <exp>. For a floating-point value of zero, the significant
|
||||
and exponent are both zero. For a floating-point value that is an
|
||||
infinity or is not a number, the results of frexp() are undefined.
|
||||
|
||||
If the input <x> is a vector, this operation is performed in a
|
||||
component-wise manner; the value returned by the function and the value
|
||||
written to <exp> are vectors with the same number of components as <x>.
|
||||
|
||||
The function ldexp() builds a single-precision floating-point number from
|
||||
each significand component in <x> and the corresponding integral exponent
|
||||
of two in <exp>, returning:
|
||||
|
||||
significand * 2 ^ exponent
|
||||
|
||||
If this product is too large to be represented as a single-precision
|
||||
floating-point value, the result is considered undefined.
|
||||
|
||||
If the input <x> is a vector, this operation is performed in a
|
||||
component-wise manner; the value passed in <exp> and returned by the
|
||||
function are vectors with the same number of components as <x>.
|
||||
|
||||
|
||||
(add support for new integer built-in functions)
|
||||
|
||||
Syntax:
|
||||
|
||||
genIType bitfieldExtract(genIType value, int offset, int bits);
|
||||
genUType bitfieldExtract(genUType value, int offset, int bits);
|
||||
|
||||
genIType bitfieldInsert(genIType base, genIType insert, int offset,
|
||||
int bits);
|
||||
genUType bitfieldInsert(genUType base, genUType insert, int offset,
|
||||
int bits);
|
||||
|
||||
genIType bitfieldReverse(genIType value);
|
||||
genUType bitfieldReverse(genUType value);
|
||||
|
||||
genIType bitCount(genIType value);
|
||||
genIType bitCount(genUType value);
|
||||
|
||||
genIType findLSB(genIType value);
|
||||
genIType findLSB(genUType value);
|
||||
|
||||
genIType findMSB(genIType value);
|
||||
genIType findMSB(genUType value);
|
||||
|
||||
The function bitfieldExtract() extracts bits <offset> through
|
||||
<offset>+<bits>-1 from each component in <value>, returning them in the
|
||||
least significant bits of corresponding component of the result. For
|
||||
unsigned data types, the most significant bits of the result will be set
|
||||
to zero. For signed data types, the most significant bits will be set to
|
||||
the value of bit <offset>+<base>-1. If <bits> is zero, the result will be
|
||||
zero. The result will be undefined if <offset> or <bits> is negative, or
|
||||
if the sum of <offset> and <bits> is greater than the number of bits used
|
||||
to store the operand. Note that for vector versions of bitfieldExtract(),
|
||||
a single pair of <offset> and <bits> values is shared for all components.
|
||||
|
||||
The function bitfieldInsert() inserts the <bits> least significant bits of
|
||||
each component of <insert> into the corresponding component of <base>.
|
||||
The result will have bits numbered <offset> through <offset>+<bits>-1
|
||||
taken from bits 0 through <bits>-1 of <insert>, and all other bits taken
|
||||
directly from the corresponding bits of <base>. If <bits> is zero, the
|
||||
result will simply be <base>. The result will be undefined if <offset> or
|
||||
<bits> is negative, or if the sum of <offset> and <bits> is greater than
|
||||
the number of bits used to store the operand. Note that for vector
|
||||
versions of bitfieldInsert(), a single pair of <offset> and <bits> values
|
||||
is shared for all components.
|
||||
|
||||
The function bitfieldReverse() reverses the bits of <value>. The bit
|
||||
numbered <n> of the result will be taken from bit (<bits>-1)-<n> of
|
||||
<value>, where <bits> is the total number of bits used to represent
|
||||
<value>.
|
||||
|
||||
The function bitCount() returns the number of one bits in the binary
|
||||
representation of <value>.
|
||||
|
||||
The function findLSB() returns the bit number of the least significant one
|
||||
bit in the binary representation of <value>. If <value> is zero, -1 will
|
||||
be returned.
|
||||
|
||||
The function findMSB() returns the bit number of the most significant bit
|
||||
in the binary representation of <value>. For positive integers, the
|
||||
result will be the bit number of the most significant one bit. For
|
||||
negative integers, the result will be the bit number of the most
|
||||
significant zero bit. For a <value> of zero or negative one, -1 will be
|
||||
returned.
|
||||
|
||||
|
||||
(support for unsigned integer add/subtract with carry-out)
|
||||
|
||||
Syntax:
|
||||
|
||||
genUType uaddCarry(genUType x, genUType y, out genUType carry);
|
||||
genUType usubBorrow(genUType x, genUType y, out genUType borrow);
|
||||
|
||||
The function uaddCarry() adds 32-bit unsigned integers or vectors <x> and
|
||||
<y>, returning the sum modulo 2^32. The value <carry> is set to zero if
|
||||
the sum was less than 2^32, or one otherwise.
|
||||
|
||||
The function usubBorrow() subtracts the 32-bit unsigned integer or vector
|
||||
<y> from <x>, returning the difference if non-negative or 2^32 plus the
|
||||
difference, otherwise. The value <borrow> is set to zero if x >= y, or
|
||||
one otherwise.
|
||||
|
||||
|
||||
(support for signed and unsigned multiplies, with 32-bit inputs and a
|
||||
64-bit result spanning two 32-bit outputs)
|
||||
|
||||
Syntax:
|
||||
|
||||
void umulExtended(genUType x, genUType y, out genUType msb,
|
||||
out genUType lsb);
|
||||
void imulExtended(genIType x, genIType y, out genIType msb,
|
||||
out genIType lsb);
|
||||
|
||||
The functions umulExtended() and imulExtended() multiply 32-bit unsigned
|
||||
or signed integers or vectors <x> and <y>, producing a 64-bit result. The
|
||||
32 least significant bits are returned in <lsb>; the 32 most significant
|
||||
bits are returned in <msb>.
|
||||
|
||||
|
||||
GLX Protocol
|
||||
|
||||
None.
|
||||
|
||||
Dependencies on ARB_gpu_shader_fp64
|
||||
|
||||
This extension, ARB_gpu_shader_fp64, and NV_gpu_shader5 all modify the set
|
||||
of implicit conversions supported in the OpenGL Shading Language. If more
|
||||
than one of these extensions is supported, an expression of one type may
|
||||
be converted to another type if that conversion is allowed by any of these
|
||||
specifications.
|
||||
|
||||
If ARB_gpu_shader_fp64 or a similar extension introducing new data types
|
||||
is not supported, the function overloading rule in the GLSL specification
|
||||
preferring promotion an input parameters to smaller type to a larger type
|
||||
is never applicable, as all data types are of the same size. That rule
|
||||
and the example referring to "double" should be removed.
|
||||
|
||||
|
||||
Dependencies on NV_gpu_shader5
|
||||
|
||||
This extension, ARB_gpu_shader_fp64, and NV_gpu_shader5 all modify the set
|
||||
of implicit conversions supported in the OpenGL Shading Language. If more
|
||||
than one of these extensions is supported, an expression of one type may
|
||||
be converted to another type if that conversion is allowed by any of these
|
||||
specifications.
|
||||
|
||||
If NV_gpu_shader5 is supported, integer data types are supported with four
|
||||
different precisions (8-, 16, 32-, and 64-bit) and floating-point data
|
||||
types are supported with three different precisions (16-, 32-, and
|
||||
64-bit). The extension adds the following rule for output parameters,
|
||||
which is similar to the one present in this extension for input
|
||||
parameters:
|
||||
|
||||
5. If the formal parameters in both matches are output parameters, a
|
||||
conversion from a type with a larger number of bits per component is
|
||||
better than a conversion from a type with a smaller number of bits
|
||||
per component. For example, a conversion from an "int16_t" formal
|
||||
parameter type to "int" is better than one from an "int8_t" formal
|
||||
parameter type to "int".
|
||||
|
||||
Such a rule is not provided in this extension because there is no
|
||||
combination of types in this extension and ARB_gpu_shader_fp64 where this
|
||||
rule has any effect.
|
||||
|
||||
|
||||
Errors
|
||||
|
||||
None
|
||||
|
||||
|
||||
New State
|
||||
|
||||
None
|
||||
|
||||
New Implementation Dependent State
|
||||
|
||||
None
|
||||
|
||||
Issues
|
||||
|
||||
(1) What should this extension be called?
|
||||
|
||||
UNRESOLVED. This extension borrows from GL_ARB_gpu_shader5, so creating
|
||||
some sort of a play on that name would be viable. However, nothing in
|
||||
this extension should require SM5 hardware, so such a name would be a
|
||||
little misleading and weird.
|
||||
|
||||
Since the primary purpose is to add integer related functions from
|
||||
GL_ARB_gpu_shader5, call this extension GL_MESA_shader_integer_functions
|
||||
for now.
|
||||
|
||||
(2) Why is some of the formatting in this extension weird?
|
||||
|
||||
RESOLVED: This extension is formatted to minimize the differences (as
|
||||
reported by 'diff --side-by-side -W180') with the GL_ARB_gpu_shader5
|
||||
specification.
|
||||
|
||||
(3) Should ldexp and frexp be included?
|
||||
|
||||
RESOLVED: Yes. Few GPUs have native instructions to implement these
|
||||
functions. These are generally implemented using existing GLSL built-in
|
||||
functions and the other functions provided by this extension.
|
||||
|
||||
(4) Should umulExtended and imulExtended be included?
|
||||
|
||||
RESOLVED: Yes. These functions should be implementable on any GPU that
|
||||
can support the rest of this extension, but the implementation may be
|
||||
complex. The implementation on a GPU that only supports 32bit x 32bit =
|
||||
32bit multiplication would be quite expensive. However, many GPUs
|
||||
(including OpenGL 4.0 GPUs that already support this function) have a
|
||||
32bit x 16bit = 48bit multiplier. The implementation there is only
|
||||
trivially more expensive than regular 32bit multiplication.
|
||||
|
||||
(5) Should the pack and unpack functions be included?
|
||||
|
||||
RESOLVED: No. These functions are already available via
|
||||
GL_ARB_shading_language_packing.
|
||||
|
||||
(6) Should the "BitsTo" functions be included?
|
||||
|
||||
RESOLVED: No. These functions are already available via
|
||||
GL_ARB_shader_bit_encoding.
|
||||
|
||||
Revision History
|
||||
|
||||
Rev. Date Author Changes
|
||||
---- ----------- -------- -----------------------------------------
|
||||
3 31-Mar-2017 Jon Leech Add ES support (OpenGL-Registry/issues/3)
|
||||
2 7-Jul-2016 idr Fix typo in #extension line
|
||||
1 20-Jun-2016 idr Initial version based on GL_ARB_gpu_shader5.
|
||||
@@ -0,0 +1,129 @@
|
||||
Name
|
||||
|
||||
MESA_swap_control
|
||||
|
||||
Name Strings
|
||||
|
||||
GLX_MESA_swap_control
|
||||
|
||||
Contact
|
||||
|
||||
Ian Romanick, IBM, idr at us.ibm.com
|
||||
|
||||
Status
|
||||
|
||||
Deployed in DRI drivers post-XFree86 4.3.
|
||||
|
||||
Version
|
||||
|
||||
Date: 5/1/2003 Revision: 1.1
|
||||
|
||||
Number
|
||||
|
||||
???
|
||||
|
||||
Dependencies
|
||||
|
||||
None
|
||||
|
||||
Based on GLX_SGI_swap_control version 1.9 and WGL_EXT_swap_control
|
||||
version 1.5.
|
||||
|
||||
Overview
|
||||
|
||||
This extension allows an application to specify a minimum periodicity
|
||||
of color buffer swaps, measured in video frame periods.
|
||||
|
||||
Issues
|
||||
|
||||
* Should implementations that export GLX_MESA_swap_control also export
|
||||
GL_EXT_swap_control for compatibility with WGL_EXT_swap_control?
|
||||
|
||||
UNRESOLVED.
|
||||
|
||||
New Procedures and Functions
|
||||
|
||||
int glXSwapIntervalMESA(unsigned int interval)
|
||||
int glXGetSwapIntervalMESA(void)
|
||||
|
||||
New Tokens
|
||||
|
||||
None
|
||||
|
||||
Additions to Chapter 2 of the 1.4 GL Specification (OpenGL Operation)
|
||||
|
||||
None
|
||||
|
||||
Additions to Chapter 3 of the 1.4 GL Specification (Rasterization)
|
||||
|
||||
None
|
||||
|
||||
Additions to Chapter 4 of the 1.4 GL Specification (Per-Fragment Operations
|
||||
and the Framebuffer)
|
||||
|
||||
None
|
||||
|
||||
Additions to Chapter 5 of the 1.4 GL Specification (Special Functions)
|
||||
|
||||
None
|
||||
|
||||
Additions to Chapter 6 of the 1.4 GL Specification (State and State Requests)
|
||||
|
||||
None
|
||||
|
||||
Additions to the GLX 1.3 Specification
|
||||
|
||||
[Add the following to Section 3.3.10 of the GLX Specification (Double
|
||||
Buffering)]
|
||||
|
||||
glXSwapIntervalMESA specifies the minimum number of video frame periods
|
||||
per buffer swap. (e.g. a value of two means that the color buffers
|
||||
will be swapped at most every other video frame.) A return value
|
||||
of zero indicates success; otherwise an error occurred. The interval
|
||||
takes effect when glXSwapBuffers is first called subsequent to the
|
||||
glXSwapIntervalMESA call.
|
||||
|
||||
A video frame period is the time required by the monitor to display a
|
||||
full frame of video data. In the case of an interlaced monitor,
|
||||
this is typically the time required to display both the even and odd
|
||||
fields of a frame of video data.
|
||||
|
||||
If <interval> is set to a value of 0, buffer swaps are not synchro-
|
||||
nized to a video frame. The <interval> value is silently clamped to
|
||||
the maximum implementation-dependent value supported before being
|
||||
stored.
|
||||
|
||||
The swap interval is not part of the render context state. It cannot
|
||||
be pushed or popped. The current swap interval for the window
|
||||
associated with the current context can be obtained by calling
|
||||
glXGetSwapIntervalMESA. The default swap interval is 0.
|
||||
|
||||
On XFree86, setting the environment variable LIBGL_THROTTLE_REFRESH sets
|
||||
the swap interval to 1.
|
||||
|
||||
Errors
|
||||
|
||||
glXSwapIntervalMESA returns GLX_BAD_CONTEXT if there is no current
|
||||
GLXContext or if the current context is not a direct rendering context.
|
||||
|
||||
GLX Protocol
|
||||
|
||||
None. This extension only extends to direct rendering contexts.
|
||||
|
||||
New State
|
||||
|
||||
Get Value Get Command Type Initial Value
|
||||
--------- ----------- ---- -------------
|
||||
[swap interval] GetSwapInterval Z+ 0
|
||||
|
||||
New Implementation Dependent State
|
||||
|
||||
None
|
||||
|
||||
|
||||
Revision History
|
||||
|
||||
1.1, 5/1/03 Added the issues section and contact information.
|
||||
Changed the default swap interval to 0.
|
||||
1.0, 3/17/03 Initial version based on GLX_SGI_swap_control and
|
||||
WGL_EXT_swap_control.
|
||||
@@ -0,0 +1,201 @@
|
||||
Name
|
||||
|
||||
MESA_swap_frame_usage
|
||||
|
||||
Name Strings
|
||||
|
||||
GLX_MESA_swap_frame_usage
|
||||
|
||||
Contact
|
||||
|
||||
Ian Romanick, IBM, idr at us.ibm.com
|
||||
|
||||
Status
|
||||
|
||||
Deployed in DRI drivers post-XFree86 4.3.
|
||||
|
||||
Version
|
||||
|
||||
Date: 5/1/2003 Revision: 1.1
|
||||
|
||||
Number
|
||||
|
||||
???
|
||||
|
||||
Dependencies
|
||||
|
||||
GLX_SGI_swap_control affects the definition of this extension.
|
||||
GLX_MESA_swap_control affects the definition of this extension.
|
||||
GLX_OML_sync_control affects the definition of this extension.
|
||||
|
||||
Based on WGL_I3D_swap_frame_usage version 1.3.
|
||||
|
||||
Overview
|
||||
|
||||
This extension allows an application to determine what portion of the
|
||||
swap period has elapsed since the last swap operation completed. The
|
||||
"usage" value is a floating point value on the range [0,max] which is
|
||||
calculated as follows:
|
||||
|
||||
td
|
||||
percent = ----
|
||||
tf
|
||||
|
||||
where td is the time measured from the last completed buffer swap (or
|
||||
call to enable the statistic) to when the next buffer swap completes, tf
|
||||
is the entire time for a frame which may be multiple screen refreshes
|
||||
depending on the swap interval as set by the GLX_SGI_swap_control or
|
||||
GLX_OML_sync_control extensions.
|
||||
|
||||
The value, percent, indicates the amount of time spent between the
|
||||
completion of the two swaps. If the value is in the range [0,1], the
|
||||
buffer swap occurred within the time period required to maintain a
|
||||
constant frame rate. If the value is in the range (1,max], a constant
|
||||
frame rate was not achieved. The value indicates the number of frames
|
||||
required to draw.
|
||||
|
||||
This definition of "percent" differs slightly from
|
||||
WGL_I3D_swap_frame_usage. In WGL_I3D_swap_frame_usage, the measurement
|
||||
is taken from the completion of one swap to the issuance of the next.
|
||||
This representation may not be as useful as measuring between
|
||||
completions, as a significant amount of time may pass between the
|
||||
issuance of a swap and the swap actually occurring.
|
||||
|
||||
There is also a mechanism to determine whether a frame swap was
|
||||
missed.
|
||||
|
||||
New Procedures and Functions
|
||||
|
||||
int glXGetFrameUsageMESA(Display *dpy,
|
||||
GLXDrawable drawable,
|
||||
float *usage)
|
||||
|
||||
int glXBeginFrameTrackingMESA(Display *dpy,
|
||||
GLXDrawable drawable)
|
||||
|
||||
int glXEndFrameTrackingMESA(Display *dpy,
|
||||
GLXDrawable drawable)
|
||||
|
||||
int glXQueryFrameTrackingMESA(Display *dpy,
|
||||
GLXDrawable drawable,
|
||||
int64_t *swapCount,
|
||||
int64_t *missedFrames,
|
||||
float *lastMissedUsage)
|
||||
|
||||
New Tokens
|
||||
|
||||
None
|
||||
|
||||
Additions to Chapter 2 of the 1.4 GL Specification (OpenGL Operation)
|
||||
|
||||
None
|
||||
|
||||
Additions to Chapter 3 of the 1.4 GL Specification (Rasterization)
|
||||
|
||||
None
|
||||
|
||||
Additions to Chapter 4 of the 1.4 GL Specification (Per-Fragment Operations
|
||||
and the Framebuffer)
|
||||
|
||||
None
|
||||
|
||||
Additions to Chapter 5 of the 1.4 GL Specification (Special Functions)
|
||||
|
||||
None
|
||||
|
||||
Additions to Chapter 6 of the 1.4 GL Specification (State and State Requests)
|
||||
|
||||
None
|
||||
|
||||
Additions to the GLX 1.3 Specification
|
||||
|
||||
The frame usage is measured as the percentage of the swap period elapsed
|
||||
between two buffer-swap operations being committed. In unextended GLX the
|
||||
swap period is the vertical refresh time. If SGI_swap_control or
|
||||
MESA_swap_control are supported, the swap period is the vertical refresh
|
||||
time multiplied by the swap interval (or one if the swap interval is set
|
||||
to zero).
|
||||
|
||||
If OML_sync_control is supported, the swap period is the vertical
|
||||
refresh time multiplied by the divisor parameter to
|
||||
glXSwapBuffersMscOML. The frame usage in this case is less than 1.0 if
|
||||
the swap is committed before target_msc, and is greater than or equal to
|
||||
1.0 otherwise. The actual usage value is based on the divisor and is
|
||||
never less than 0.0.
|
||||
|
||||
int glXBeginFrameTrackingMESA(Display *dpy,
|
||||
GLXDrawable drawable,
|
||||
float *usage)
|
||||
|
||||
glXGetFrameUsageMESA returns a floating-point value in <usage>
|
||||
that represents the current swap usage, as defined above.
|
||||
|
||||
Missed frame swaps can be tracked by calling the following function:
|
||||
|
||||
int glXBeginFrameTrackingMESA(Display *dpy,
|
||||
GLXDrawable drawable)
|
||||
|
||||
glXBeginFrameTrackingMESA resets a "missed frame" count and
|
||||
synchronizes with the next frame vertical sync before it returns.
|
||||
If a swap is missed based in the rate control specified by the
|
||||
<interval> set by glXSwapIntervalSGI or the default swap of once
|
||||
per frame, the missed frame count is incremented.
|
||||
|
||||
The current missed frame count and total number of swaps since
|
||||
the last call to glXBeginFrameTrackingMESA can be obtained by
|
||||
calling the following function:
|
||||
|
||||
int glXQueryFrameTrackingMESA(Display *dpy,
|
||||
GLXDrawable drawable,
|
||||
int64_t *swapCount,
|
||||
int64_t *missedFrames,
|
||||
float *lastMissedUsage)
|
||||
|
||||
The location pointed to by <swapCount> will be updated with the
|
||||
number of swaps that have been committed. This value may not match the
|
||||
number of swaps that have been requested since swaps may be
|
||||
queued by the implementation. This function can be called at any
|
||||
time and does not synchronize to vertical blank.
|
||||
|
||||
The location pointed to by <missedFrames> will contain the number
|
||||
swaps that missed the specified frame. The frame usage for the
|
||||
last missed frame is returned in the location pointed to by
|
||||
<lastMissedUsage>.
|
||||
|
||||
Frame tracking is disabled by calling the function
|
||||
|
||||
int glXEndFrameTrackingMESA(Display *dpy,
|
||||
GLXDrawable drawable)
|
||||
|
||||
This function will not return until all swaps have occurred. The
|
||||
application can call glXQueryFrameTrackingMESA for a final swap and
|
||||
missed frame count.
|
||||
|
||||
If these functions are successful, zero is returned. If the context
|
||||
associated with dpy and drawable is not a direct context,
|
||||
GLX_BAD_CONTEXT is returned.
|
||||
|
||||
Errors
|
||||
|
||||
If the function succeeds, zero is returned. If the function
|
||||
fails, one of the following error codes is returned:
|
||||
|
||||
GLX_BAD_CONTEXT The current rendering context is not a direct
|
||||
context.
|
||||
|
||||
GLX Protocol
|
||||
|
||||
None. This extension only extends to direct rendering contexts.
|
||||
|
||||
New State
|
||||
|
||||
None
|
||||
|
||||
New Implementation Dependent State
|
||||
|
||||
None
|
||||
|
||||
Revision History
|
||||
|
||||
1.1, 5/1/03 Added contact information.
|
||||
1.0, 3/17/03 Initial version based on WGL_I3D_swap_frame_usage.
|
||||
@@ -0,0 +1,804 @@
|
||||
Name
|
||||
|
||||
MESA_texture_array
|
||||
|
||||
Name Strings
|
||||
|
||||
GL_MESA_texture_array
|
||||
|
||||
Contact
|
||||
|
||||
Ian Romanick, IBM (idr 'at' us.ibm.com)
|
||||
|
||||
IP Status
|
||||
|
||||
No known IP issues.
|
||||
|
||||
Status
|
||||
|
||||
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,214 @@
|
||||
Name
|
||||
|
||||
MESA_texture_signed_rgba
|
||||
|
||||
Name Strings
|
||||
|
||||
GL_MESA_texture_signed_rgba
|
||||
|
||||
Contact
|
||||
|
||||
|
||||
|
||||
Notice
|
||||
|
||||
|
||||
|
||||
IP Status
|
||||
|
||||
No known IP issues
|
||||
|
||||
Status
|
||||
|
||||
|
||||
|
||||
Version
|
||||
|
||||
0.3, 2009-03-24
|
||||
|
||||
Number
|
||||
|
||||
Not assigned ?
|
||||
|
||||
Dependencies
|
||||
|
||||
Written based on the wording of the OpenGL 2.0 specification.
|
||||
|
||||
This extension trivially interacts with ARB_texture_float.
|
||||
This extension shares some language with ARB_texture_compression_rgtc
|
||||
but does not depend on it.
|
||||
|
||||
Overview
|
||||
|
||||
OpenGL prior to 3.1 does not support any signed texture formats.
|
||||
ARB_texture_compression_rgtc introduces some compressed red and
|
||||
red_green signed formats but no uncompressed ones, which might
|
||||
still be useful. NV_texture_shader adds signed texture formats,
|
||||
but also a lot of functionality which has been superseded by fragment
|
||||
shaders.
|
||||
It is usually possible to get the same functionality
|
||||
using a unsigned format by doing scale and bias in a shader, but this
|
||||
is undesirable since modern hardware has direct support for this.
|
||||
This extension adds a signed 4-channel texture format by backporting
|
||||
the relevant features from OpenGL 3.1, as a means to support this in
|
||||
OpenGL implementations only supporting older versions.
|
||||
|
||||
Issues
|
||||
|
||||
1) What should this extension be called?
|
||||
|
||||
RESOLVED: MESA_texture_signed_rgba seems reasonable.
|
||||
The rgba part is there because only 4 channel format is supported.
|
||||
|
||||
|
||||
2) Should the full set of signed formats (alpha, luminance, rgb, etc.)
|
||||
be supported?
|
||||
|
||||
RESOLVED: NO. To keep this extension simple, only add the most
|
||||
universal format, rgba. alpha/luminance can't be trivially supported
|
||||
since OpenGL 3.1 does not support them any longer, and there is some
|
||||
implied dependency on ARB_texture_rg for red/red_green formats so
|
||||
avoid all this. Likewise, only 8 bits per channel is supported.
|
||||
|
||||
|
||||
3) Should this extension use new enums for the texture formats?
|
||||
|
||||
RESOLVED: NO. Same enums as those used in OpenGL 3.1.
|
||||
|
||||
|
||||
4) How are signed integer values mapped to floating-point values?
|
||||
|
||||
RESOLVED: Same as described in issue 5) of
|
||||
ARB_texture_compression_rgtc (quote):
|
||||
A signed 8-bit two's complement value X is computed to
|
||||
a floating-point value Xf with the formula:
|
||||
|
||||
{ X / 127.0, X > -128
|
||||
Xf = {
|
||||
{ -1.0, X == -128
|
||||
|
||||
This conversion means -1, 0, and +1 are all exactly representable,
|
||||
however -128 and -127 both map to -1.0. Mapping -128 to -1.0
|
||||
avoids the numerical awkwardness of have a representable value
|
||||
slightly more negative than -1.0.
|
||||
|
||||
This conversion is intentionally NOT the "byte" conversion listed
|
||||
in Table 2.9 for component conversions. That conversion says:
|
||||
|
||||
Xf = (2*X + 1) / 255.0
|
||||
|
||||
The Table 2.9 conversion is incapable of exactly representing
|
||||
zero.
|
||||
|
||||
(Difference to ARB_texture_compression_rgtc):
|
||||
This is the same mapping as OpenGL 3.1 uses.
|
||||
This is also different to what NV_texture_shader used.
|
||||
The above mapping should be considered the reference, but there
|
||||
is some leeway so other mappings are allowed for implementations which
|
||||
cannot do this. Particularly the mapping given in NV_texture_shader or
|
||||
the standard OpenGL byte/float mapping is considered acceptable too, as
|
||||
might be a mapping which represents -1.0 by -128, 0.0 by 0 and 1.0 by
|
||||
127 (that is, uses different scale factors for negative and positive
|
||||
numbers).
|
||||
Also, it is ok to store incoming GL_BYTE user data as-is, without
|
||||
converting to GL_FLOAT (using the standard OpenGL float/byte mapping)
|
||||
and converting back (using the mapping described here).
|
||||
Other than those subtle issues there are no other non-standard
|
||||
conversions used, so when using for instance CopyTexImage2D with
|
||||
a framebuffer clamped to [0,1] all converted numbers will be in the range
|
||||
[0, 127] (and not scaled and biased).
|
||||
|
||||
|
||||
5) How will signed components resulting from RGBA8_SNORM texture
|
||||
fetches interact with fragment coloring?
|
||||
|
||||
RESOLVED: Same as described in issue 6) of
|
||||
ARB_texture_compression_rgtc (quote):
|
||||
The specification language for this extension is silent
|
||||
about clamping behavior leaving this to the core specification
|
||||
and other extensions. The clamping or lack of clamping is left
|
||||
to the core specification and other extensions.
|
||||
|
||||
For assembly program extensions supporting texture fetches
|
||||
(ARB_fragment_program, NV_fragment_program, NV_vertex_program3,
|
||||
etc.) or the OpenGL Shading Language, these signed formats will
|
||||
appear as expected with unclamped signed components as a result
|
||||
of a texture fetch instruction.
|
||||
|
||||
If ARB_color_buffer_float is supported, its clamping controls
|
||||
will apply.
|
||||
|
||||
NV_texture_shader extension, if supported, adds support for
|
||||
fixed-point textures with signed components and relaxed the
|
||||
fixed-function texture environment clamping appropriately. If the
|
||||
NV_texture_shader extension is supported, its specified behavior
|
||||
for the texture environment applies where intermediate values
|
||||
are clamped to [-1,1] unless stated otherwise as in the case
|
||||
of explicitly clamped to [0,1] for GL_COMBINE. or clamping the
|
||||
linear interpolation weight to [0,1] for GL_DECAL and GL_BLEND.
|
||||
|
||||
Otherwise, the conventional core texture environment clamps
|
||||
incoming, intermediate, and output color components to [0,1].
|
||||
|
||||
This implies that the conventional texture environment
|
||||
functionality of unextended OpenGL 1.5 or OpenGL 2.0 without
|
||||
using GLSL (and with none of the extensions referred to above)
|
||||
is unable to make proper use of the signed texture formats added
|
||||
by this extension because the conventional texture environment
|
||||
requires texture source colors to be clamped to [0,1]. Texture
|
||||
filtering of these signed formats would be still signed, but
|
||||
negative values generated post-filtering would be clamped to
|
||||
zero by the core texture environment functionality. The
|
||||
expectation is clearly that this extension would be co-implemented
|
||||
with one of the previously referred to extensions or used with
|
||||
GLSL for the new signed formats to be useful.
|
||||
|
||||
|
||||
6) Should the RGBA_SNORM tokens also be accepted by CopyTexImage
|
||||
functions?
|
||||
|
||||
RESOLVED: YES.
|
||||
|
||||
|
||||
7) What to do with GetTexParameter if ARB_texture_float is supported,
|
||||
in particular what datatype should this return for TEXTURE_RED_TYPE_ARB,
|
||||
TEXTURE_GREEN_TYPE_ARB, TEXTURE_BLUE_TYPE_ARB, TEXTURE_ALPHA_TYPE_ARB?
|
||||
|
||||
RESOLVED: ARB_texture_float states type is either NONE,
|
||||
UNSIGNED_NORMALIZED_ARB, or FLOAT. This extension adds a new enum,
|
||||
SIGNED_NORMALIZED, which will be returned accordingly. This is the
|
||||
same behaviour as in OpenGL 3.1.
|
||||
|
||||
|
||||
New Tokens
|
||||
|
||||
|
||||
Accepted by the <internalformat> parameter of
|
||||
TexImage1D, TexImage2D, TexImage3D, CopyTexImage1D, and CopyTexImage2D:
|
||||
|
||||
RGBA_SNORM 0x8F93
|
||||
RGBA8_SNORM 0x8F97
|
||||
|
||||
Returned by the <params> parameter of GetTexLevelParameter:
|
||||
|
||||
SIGNED_NORMALIZED 0x8F9C
|
||||
|
||||
|
||||
Additions to Chapter 3 of the OpenGL 2.0 Specification (Rasterization):
|
||||
|
||||
-- Section 3.8.1, Texture Image Specification
|
||||
|
||||
Add to Table 3.16 (page 154): Sized internal formats
|
||||
|
||||
Sized Base R G B A L I D
|
||||
Internal Format Internal Format bits bits bits bits bits bits bits
|
||||
--------------- --------------- ---- ---- ---- ---- ---- ---- ----
|
||||
RGBA8_SNORM RGBA 8 8 8 8 0 0 0
|
||||
|
||||
|
||||
Dependencies on ARB_texture_float extension:
|
||||
|
||||
If ARB_texture_float is supported, GetTexParameter queries with <value>
|
||||
of TEXTURE_RED_TYPE_ARB, TEXTURE_GREEN_TYPE_ARB, TEXTURE_BLUE_TYPE_ARB or
|
||||
TEXTURE_ALPHA_TYPE_ARB return SIGNED_NORMALIZED if
|
||||
the base internal format is RGBA_SNORM.
|
||||
@@ -0,0 +1,126 @@
|
||||
Name
|
||||
|
||||
MESA_window_pos
|
||||
|
||||
Name Strings
|
||||
|
||||
GL_MESA_window_pos
|
||||
|
||||
Contact
|
||||
|
||||
Brian Paul, brian.paul 'at' tungstengraphics.com
|
||||
|
||||
Status
|
||||
|
||||
Shipping (since Mesa version 1.2.8)
|
||||
|
||||
Version
|
||||
|
||||
|
||||
Number
|
||||
|
||||
197
|
||||
|
||||
Dependencies
|
||||
|
||||
OpenGL 1.0 is required.
|
||||
The extension is written against the OpenGL 1.2 Specification
|
||||
|
||||
Overview
|
||||
|
||||
In order to set the current raster position to a specific window
|
||||
coordinate with the RasterPos command, the modelview matrix, projection
|
||||
matrix and viewport must be set very carefully. Furthermore, if the
|
||||
desired window coordinate is outside of the window's bounds one must
|
||||
rely on a subtle side-effect of the Bitmap command in order to circumvent
|
||||
frustum clipping.
|
||||
|
||||
This extension provides a set of functions to directly set the
|
||||
current raster position, bypassing the modelview matrix, the
|
||||
projection matrix and the viewport to window mapping. Furthermore,
|
||||
clip testing is not performed.
|
||||
|
||||
This greatly simplifies the process of setting the current raster
|
||||
position to a specific window coordinate prior to calling DrawPixels,
|
||||
CopyPixels or Bitmap.
|
||||
|
||||
New Procedures and Functions
|
||||
|
||||
void WindowPos2dMESA(double x, double y)
|
||||
void WindowPos2fMESA(float x, float y)
|
||||
void WindowPos2iMESA(int x, int y)
|
||||
void WindowPos2sMESA(short x, short y)
|
||||
void WindowPos2ivMESA(const int *p)
|
||||
void WindowPos2svMESA(const short *p)
|
||||
void WindowPos2fvMESA(const float *p)
|
||||
void WindowPos2dvMESA(const double *p)
|
||||
void WindowPos3iMESA(int x, int y, int z)
|
||||
void WindowPos3sMESA(short x, short y, short z)
|
||||
void WindowPos3fMESA(float x, float y, float z)
|
||||
void WindowPos3dMESA(double x, double y, double z)
|
||||
void WindowPos3ivMESA(const int *p)
|
||||
void WindowPos3svMESA(const short *p)
|
||||
void WindowPos3fvMESA(const float *p)
|
||||
void WindowPos3dvMESA(const double *p)
|
||||
void WindowPos4iMESA(int x, int y, int z, int w)
|
||||
void WindowPos4sMESA(short x, short y, short z, short w)
|
||||
void WindowPos4fMESA(float x, float y, float z, float w)
|
||||
void WindowPos4dMESA(double x, double y, double z, double )
|
||||
void WindowPos4ivMESA(const int *p)
|
||||
void WindowPos4svMESA(const short *p)
|
||||
void WindowPos4fvMESA(const float *p)
|
||||
void WindowPos4dvMESA(const double *p)
|
||||
|
||||
New Tokens
|
||||
|
||||
none
|
||||
|
||||
Additions to Chapter 2 of the OpenGL 1.2 Specification (OpenGL Operation)
|
||||
|
||||
- (2.12, p. 41) Insert after third paragraph:
|
||||
|
||||
Alternately, the current raster position may be set by one of the
|
||||
WindowPosMESA commands:
|
||||
|
||||
void WindowPos{234}{sidf}MESA( T coords );
|
||||
void WindowPos{234}{sidf}vMESA( T coords );
|
||||
|
||||
WindosPos4MESA takes four values indicating x, y, z, and w.
|
||||
WindowPos3MESA (or WindowPos2MESA) is analaguos, but sets only
|
||||
x, y, and z with w implicitly set to 1 (or only x and y with z
|
||||
implicitly set to 0 and w implicitly set to 1).
|
||||
|
||||
WindowPosMESA operates like RasterPos except that the current modelview
|
||||
matrix, projection matrix and viewport parameters are ignored and the
|
||||
clip test operation always passes. The current raster position values
|
||||
are directly set to the parameters passed to WindowPosMESA. The current
|
||||
color, color index and texture coordinate update the current raster
|
||||
position's associated data.
|
||||
|
||||
Additions to the AGL/GLX/WGL Specifications
|
||||
|
||||
None
|
||||
|
||||
GLX Protocol
|
||||
|
||||
Not specified at this time. However, a protocol message very similar
|
||||
to that of RasterPos is expected.
|
||||
|
||||
Errors
|
||||
|
||||
INVALID_OPERATION is generated if WindowPosMESA is called between
|
||||
Begin and End.
|
||||
|
||||
New State
|
||||
|
||||
None.
|
||||
|
||||
New Implementation Dependent State
|
||||
|
||||
None.
|
||||
|
||||
Revision History
|
||||
|
||||
* Revision 1.0 - Initial specification
|
||||
* Revision 1.1 - Minor clean-up (7 Jan 2000, Brian Paul)
|
||||
|
||||
@@ -0,0 +1,204 @@
|
||||
Name
|
||||
|
||||
MESA_ycbcr_texture
|
||||
|
||||
Name Strings
|
||||
|
||||
GL_MESA_ycbcr_texture
|
||||
|
||||
Contact
|
||||
|
||||
Brian Paul, Tungsten Graphics, Inc. (brian.paul 'at' tungstengraphics.com)
|
||||
Keith Whitwell, Tungsten Graphics, Inc. (keith 'at' tungstengraphics.com)
|
||||
|
||||
Status
|
||||
|
||||
Shipping (Mesa 4.0.4 and later)
|
||||
|
||||
Version
|
||||
|
||||
1.0
|
||||
|
||||
Number
|
||||
|
||||
TBD
|
||||
|
||||
Dependencies
|
||||
|
||||
OpenGL 1.0 or later is required
|
||||
This extension is written against the OpenGL 1.4 Specification.
|
||||
NV_texture_rectangle effects the definition of this extension.
|
||||
|
||||
Overview
|
||||
|
||||
This extension supports texture images stored in the YCbCr format.
|
||||
There is no support for converting YCbCr images to RGB or vice versa
|
||||
during pixel transfer. The texture's YCbCr colors are converted to
|
||||
RGB during texture sampling, after-which, all the usual per-fragment
|
||||
operations take place. Only 2D texture images are supported (not
|
||||
glDrawPixels, glReadPixels, etc).
|
||||
|
||||
A YCbCr pixel (texel) is a 16-bit unsigned short with two components.
|
||||
The first component is luminance (Y). For pixels in even-numbered
|
||||
image columns, the second component is Cb. For pixels in odd-numbered
|
||||
image columns, the second component is Cr. If one were to convert the
|
||||
data to RGB one would need to examine two pixels from columns N and N+1
|
||||
(where N is even) to deduce the RGB color.
|
||||
|
||||
IP Status
|
||||
|
||||
None
|
||||
|
||||
Issues
|
||||
|
||||
None
|
||||
|
||||
New Procedures and Functions
|
||||
|
||||
None
|
||||
|
||||
New Tokens
|
||||
|
||||
Accepted by the <internalFormat> and <format> parameters of
|
||||
TexImage2D and TexSubImage2D:
|
||||
|
||||
YCBCR_MESA 0x8757
|
||||
|
||||
Accepted by the <type> parameter of TexImage2D and TexSubImage2D:
|
||||
|
||||
UNSIGNED_SHORT_8_8_MESA 0x85BA /* same as Apple's */
|
||||
UNSIGNED_SHORT_8_8_REV_MESA 0x85BB /* same as Apple's */
|
||||
|
||||
Additions to Chapter 2 of the OpenGL 1.4 Specification (OpenGL Operation)
|
||||
|
||||
None
|
||||
|
||||
Additions to Chapter 3 of the OpenGL 1.4 Specification (Rasterization)
|
||||
|
||||
In section 3.6.4, Rasterization of Pixel Rectangles, on page 101,
|
||||
add the following to Table 3.8 (Packed pixel formats):
|
||||
|
||||
type Parameter GL Data Number of Matching
|
||||
Token Name Type Components Pixel Formats
|
||||
-------------- ------- ---------- -------------
|
||||
UNSIGNED_SHORT_8_8_MESA ushort 2 YCBCR_MESA
|
||||
UNSIGNED_SHORT_8_8_REV_MESA ushort 2 YCBCR_MESA
|
||||
|
||||
|
||||
In section 3.6.4, Rasterization of Pixel Rectangles, on page 102,
|
||||
add the following to Table 3.10 (UNSIGNED_SHORT formats):
|
||||
|
||||
UNSIGNED_SHORT_8_8_MESA:
|
||||
|
||||
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
|
||||
+-------------------------------+-------------------------------+
|
||||
| 1st | 2nd |
|
||||
+-------------------------------+-------------------------------+
|
||||
|
||||
UNSIGNED_SHORT_8_8_REV_MESA:
|
||||
|
||||
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
|
||||
+-------------------------------+-------------------------------+
|
||||
| 2nd | 1st |
|
||||
+-------------------------------+-------------------------------+
|
||||
|
||||
|
||||
In section 3.6.4, Rasterization of Pixel Rectangles, on page 104,
|
||||
add the following to Table 3.12 (Packed pixel field assignments):
|
||||
|
||||
First Second Third Fourth
|
||||
Format Element Element Element Element
|
||||
------ ------- ------- ------- -------
|
||||
YCBCR_MESA luminance chroma
|
||||
|
||||
|
||||
In section 3.8.1, Texture Image Specification, on page 125, add
|
||||
another item to the list of TexImage2D and TexImage3D equivalence
|
||||
exceptions:
|
||||
|
||||
* The value of internalformat and format may be YCBCR_MESA to
|
||||
indicate that the image data is in YCbCr format. type must
|
||||
be either UNSIGNED_SHORT_8_8_MESA or UNSIGNED_SHORT_8_8_REV_MESA
|
||||
as seen in tables 3.8 and 3.10. Table 3.12 describes the mapping
|
||||
between Y and Cb/Cr to the components.
|
||||
If NV_texture_rectangle is supported target may also be
|
||||
TEXTURE_RECTANGLE_NV or PROXY_TEXTURE_RECTANGLE_NV.
|
||||
All pixel transfer operations are bypassed. The texture is stored as
|
||||
YCbCr, not RGB. Queries of the texture's red, green and blue component
|
||||
sizes will return zero. The YCbCr colors are converted to RGB during
|
||||
texture sampling using an implementation dependent conversion.
|
||||
|
||||
|
||||
In section 3.8.1, Texture Image Specification, on page 126, add
|
||||
another item to the list of TexImage1D and TexImage2D equivalence
|
||||
exceptions:
|
||||
|
||||
* The value of internalformat and format can not be YCBCR_MESA.
|
||||
|
||||
|
||||
In section 3.8.2, Alternate Texture Image Specification Commands, on
|
||||
page 129, insert this paragraph after the first full paragraph on the
|
||||
page:
|
||||
|
||||
"If the internal storage format of the image being updated by
|
||||
TexSubImage2D is YCBCR_MESA then format must be YCBCR_MESA.
|
||||
The error INVALID_OPERATION will be generated otherwise."
|
||||
|
||||
|
||||
Additions to Chapter 4 of the OpenGL 1.4 Specification (Per-Fragment
|
||||
Operations and the Frame Buffer)
|
||||
|
||||
None
|
||||
|
||||
Additions to Chapter 5 of the OpenGL 1.4 Specification (Special Functions)
|
||||
|
||||
None
|
||||
|
||||
Additions to Chapter 6 of the OpenGL 1.4 Specification (State and
|
||||
State Requests)
|
||||
|
||||
None
|
||||
|
||||
Additions to Appendix A of the OpenGL 1.4 Specification (Invariance)
|
||||
|
||||
None
|
||||
|
||||
Additions to the AGL/GLX/WGL Specifications
|
||||
|
||||
None
|
||||
|
||||
GLX Protocol
|
||||
|
||||
None
|
||||
|
||||
Errors
|
||||
|
||||
INVALID_ENUM is generated by TexImage2D if <internalFormat> is
|
||||
MESA_YCBCR but <format> is not MESA_YCBCR.
|
||||
|
||||
INVALID_ENUM is generated by TexImage2D if <format> is MESA_YCBCR but
|
||||
<internalFormat> is not MESA_YCBCR.
|
||||
|
||||
INVALID_VALUE is generated by TexImage2D if <format> is MESA_YCBCR and
|
||||
<internalFormat> is MESA_YCBCR and <border> is not zero.
|
||||
|
||||
INVALID_OPERATION is generated by TexSubImage2D if the internal image
|
||||
format is YCBCR_MESA and <format> is not YCBCR_MESA.
|
||||
|
||||
INVALID_OPERATION is generated by CopyTexSubImage2D if the internal
|
||||
image is YCBCR_MESA.
|
||||
|
||||
New State
|
||||
|
||||
Edit table 6.16 on page 231: change the type of TEXTURE_INTERNAL_FORMAT
|
||||
from n x Z42 to n x Z43 to indicate that internal format may also be
|
||||
YCBCR_MESA.
|
||||
|
||||
Revision History
|
||||
|
||||
20 September 2002 - Initial draft
|
||||
29 April 2003 - minor updates
|
||||
3 September 2003 - further clarify when YCbCr->RGB conversion takes place
|
||||
19 September 2003 - a few more updates prior to submitting to extension
|
||||
registry.
|
||||
3 April 2004 - fix assorted inaccuracies
|
||||
@@ -0,0 +1,564 @@
|
||||
Name
|
||||
|
||||
MESA_screen_surface
|
||||
|
||||
Name Strings
|
||||
|
||||
EGL_MESA_screen_surface
|
||||
|
||||
Contact
|
||||
|
||||
Brian Paul
|
||||
|
||||
To discuss, join the dri-egl@lists.freedesktop.org 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 specifing 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,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,190 @@
|
||||
Name
|
||||
|
||||
MESA_sprite_point
|
||||
|
||||
Name Strings
|
||||
|
||||
GL_MESA_sprite_point
|
||||
|
||||
Contact
|
||||
|
||||
Brian Paul, VA Linux Systems Inc. (brianp 'at' valinux.com)
|
||||
|
||||
Status
|
||||
|
||||
Obsolete - see GL_ARB_point_sprite.
|
||||
|
||||
Version
|
||||
|
||||
|
||||
Number
|
||||
|
||||
???
|
||||
|
||||
Dependencies
|
||||
|
||||
GL_EXT_point_parameters effects the definition of this extension
|
||||
GL_ARB_multitexture effects the definition of this extension
|
||||
|
||||
Overview
|
||||
|
||||
This extension modifies the way in which points are rendered,
|
||||
specifically when they're textured. When SPRITE_POINT_MESA is enabled
|
||||
a point is rendered as if it were a quadrilateral with unique texture
|
||||
coordinates at each vertex. This extension effectively turns points
|
||||
into sprites which may be rendered more easily and quickly than using
|
||||
conventional textured quadrilaterals.
|
||||
|
||||
When using point size > 1 or attenuated points this extension is an
|
||||
effective way to render many small sprite images for particle systems
|
||||
or other effects.
|
||||
|
||||
Issues:
|
||||
|
||||
1. How are the texture coordinates computed?
|
||||
|
||||
The lower-left corner has texture coordinate (0,0,r,q).
|
||||
The lower-right, (1,0,r,q). The upper-right, (1,1,r,q).
|
||||
The upper-left, (0,1,r,q).
|
||||
|
||||
2. What about texgen and texture matrices?
|
||||
|
||||
Texgen and the texture matrix have no effect on the point's s and t
|
||||
texture coordinates. The r and q coordinates may have been computed
|
||||
by texgen or the texture matrix. Note that with a 3D texture and/or
|
||||
texgen that the r coordinate could be used to select a slice in the
|
||||
3D texture.
|
||||
|
||||
3. What about point smoothing?
|
||||
|
||||
When point smoothing is enabled, a triangle fan could be rendered
|
||||
to approximate a circular point. This could be problematic to
|
||||
define and implement so POINT_SMOOTH is ignored when drawing sprite
|
||||
points.
|
||||
|
||||
Smoothed points can be approximated by using an appropriate texture
|
||||
images, alpha testing and blending.
|
||||
|
||||
POLYGON_SMOOTH does effect the rendering of the quadrilateral, however.
|
||||
|
||||
4. What about sprite rotation?
|
||||
|
||||
There is none. Sprite points are always rendered as window-aligned
|
||||
squares. One could define rotated texture images if desired. A 3D
|
||||
texture and appropriate texture r coordinates could be used to
|
||||
effectively specify image rotation per point.
|
||||
|
||||
5. What about POLYGON_MODE?
|
||||
|
||||
POLYGON_MODE does not effect the rasterization of the quadrilateral.
|
||||
|
||||
6. What about POLYGON_CULL?
|
||||
|
||||
TBD. Polygon culling is normally specified and implemented in the
|
||||
transformation stage of OpenGL. However, some rasterization hardware
|
||||
implements it later during triangle setup.
|
||||
|
||||
Polygon culling wouldn't be useful for sprite points since the
|
||||
quadrilaterals are always defined in counter-clockwise order in
|
||||
window space. For that reason, polygon culling should probably be
|
||||
ignored.
|
||||
|
||||
7. Should sprite points be alpha-attenuated if their size is below the
|
||||
point parameter's threshold size?
|
||||
|
||||
8. Should there be an advertisized maximum sprite point size?
|
||||
|
||||
No. Since we're rendering the point as a quadrilateral there's no
|
||||
need to limit the size.
|
||||
|
||||
|
||||
New Procedures and Functions
|
||||
|
||||
None.
|
||||
|
||||
New Tokens
|
||||
|
||||
Accepted by the <pname> parameter of Enable, Disable, IsEnabled,
|
||||
GetIntegerv, GetBooleanv, GetFloatv and GetDoublev:
|
||||
|
||||
SPRITE_POINT_MESA 0x????
|
||||
MAX_SPRITE_POINT_SIZE_MESA 0x???? (need this?)
|
||||
|
||||
Additions to Chapter 2 of the 1.1 Specification (OpenGL Operation)
|
||||
|
||||
None
|
||||
|
||||
Additions to Chapter 3 of the 1.1 Specification (Rasterization)
|
||||
|
||||
Section ???.
|
||||
|
||||
When SPRITE_POINT_MESA is enabled points are rasterized as screen-
|
||||
aligned quadrilaterals. If the four vertices of the quadrilateral
|
||||
are labeled A, B, C, and D, starting at the lower-left corner and moving
|
||||
counter-clockwise around the quadrilateral, then the vertex and
|
||||
texture coordinates are computed as follows:
|
||||
|
||||
vertex window coordinate texture coordinate
|
||||
A (x-r, y-r, z, w) (0, 0, r, q)
|
||||
B (x+r, y-r, z, w) (1, 0, r, q)
|
||||
C (x+r, y+r, z, w) (1, 1, r, q)
|
||||
D (x-r, y+r, z, w) (0, 1, r, q)
|
||||
|
||||
where x, y, z, w are the point's window coordinates, r and q are the
|
||||
point's 3rd and 4th texture coordinates and r is half the point's
|
||||
size. The other vertex attributes (such as the color and fog coordinate)
|
||||
are simply duplicated from the original point vertex.
|
||||
|
||||
Point size may either be specified with PointSize or computed
|
||||
according to the EXT_point_parameters extension.
|
||||
|
||||
The new texture coordinates are not effected by texgen or the texture
|
||||
matrix. Note, however, that the texture r and q coordinates are passed
|
||||
unchanged and may have been computed with texgen and/or the texture
|
||||
matrix.
|
||||
|
||||
If multiple texture units are present the same texture coordinate is
|
||||
used for all texture units.
|
||||
|
||||
The point is then rendered as if it were a quadrilateral using the
|
||||
normal point sampling rules. POLYGON_MODE does not effect the
|
||||
rasterization of the quadrilateral but POLYGON_SMOOTH does.
|
||||
|
||||
POINT_SMOOTH has no effect when SPRITE_POINT_MESA is enabled.
|
||||
|
||||
Additions to Chapter 4 of the 1.1 Specification (Per-Fragment Operations
|
||||
and the Frame Buffer)
|
||||
|
||||
None.
|
||||
|
||||
Additions to Chapter 5 of the 1.1 Specification (Special Functions)
|
||||
|
||||
None
|
||||
|
||||
Additions to Chapter 6 of the 1.1 Specification (State and State Requests)
|
||||
|
||||
None
|
||||
|
||||
Additions to the GLX Specification
|
||||
|
||||
None
|
||||
|
||||
GLX Protocol
|
||||
|
||||
TBD
|
||||
|
||||
Errors
|
||||
|
||||
None
|
||||
|
||||
New State
|
||||
|
||||
Add boolean variable SPRITE_POINT_MESA to the point attribute group.
|
||||
|
||||
Revision History
|
||||
|
||||
Version 1.0 - 4 Dec 2000
|
||||
Original draft.
|
||||
|
||||
|
||||
|
||||
@@ -0,0 +1,359 @@
|
||||
Name
|
||||
|
||||
MESA_trace
|
||||
|
||||
Name Strings
|
||||
|
||||
GL_MESA_trace
|
||||
|
||||
Contact
|
||||
|
||||
Bernd Kreimeier, Loki Entertainment, bk 'at' lokigames.com
|
||||
Brian Paul, VA Linux Systems, Inc., brianp 'at' valinux.com
|
||||
|
||||
Status
|
||||
|
||||
Obsolete.
|
||||
|
||||
Version
|
||||
|
||||
|
||||
Number
|
||||
|
||||
none yet
|
||||
|
||||
Dependencies
|
||||
|
||||
OpenGL 1.2 is required.
|
||||
The extension is written against the OpenGL 1.2 Specification
|
||||
|
||||
Overview
|
||||
|
||||
Provides the application with means to enable and disable logging
|
||||
of GL calls including parameters as readable text. The verbosity
|
||||
of the generated log can be controlled. The resulting logs are
|
||||
valid (but possibly incomplete) C code and can be compiled and
|
||||
linked for standalone test programs. The set of calls and the
|
||||
amount of static data that is logged can be controlled at runtime.
|
||||
The application can add comments and enable or disable tracing of GL
|
||||
operations at any time. The data flow from the application to GL
|
||||
and back is unaffected except for timing.
|
||||
|
||||
Application-side implementation of these features raises namespace
|
||||
and linkage issues. In the driver dispatch table a simple
|
||||
"chain of responsibility" pattern (aka "composable piepline")
|
||||
can be added.
|
||||
|
||||
IP Status
|
||||
|
||||
The extension spec is in the public domain. The current implementation
|
||||
in Mesa is covered by Mesa's XFree86-style copyright by the authors above.
|
||||
This extension is partially inspired by the Quake2 QGL wrapper.
|
||||
|
||||
Issues
|
||||
|
||||
|
||||
(1) Is this Extension obsolete because it can
|
||||
be implemented as a wrapper DLL?
|
||||
|
||||
RESOLVED: No. While certain operating systems (Win32) provide linkers
|
||||
that facilitate this kind of solution, other operating systems
|
||||
(Linux) do not support hierarchical linking, so a wrapper solution
|
||||
would result in symbol collisions.
|
||||
Further, IHV's might have builtin support for tracing GL execution
|
||||
that enjoys privileged access, or that they do not wish to separate
|
||||
the tracing code from their driver code base.
|
||||
|
||||
(2) Should the Trace API explicitely support the notion of "frames?
|
||||
This would require hooking into glXSwapBuffers calls as well.
|
||||
|
||||
RESOLVED: No. The application can use NewTraceMESA/EndTraceMESA
|
||||
and TraceComment along with external parsing tools to split the
|
||||
trace into frames, in whatever way considered adequate.
|
||||
|
||||
(2a) Should GLX calls be traced?
|
||||
|
||||
PBuffers and other render-to-texture solutions demonstrate that
|
||||
context level commands beyond SwapBuffers might have to be
|
||||
traced. The GL DLL exports the entry points, so this would not
|
||||
be out of the question.
|
||||
|
||||
(3) Should the specification mandate the actual output format?
|
||||
|
||||
RESOLVED: No. It is sufficient to guarantee that all data and commands
|
||||
will be traced as requested by Enable/DisableTraceMESA, in the order
|
||||
encountered. Whether the resulting trace is available as a readable
|
||||
text file, binary metafile, compilable source code, much less which
|
||||
indentation and formatting has been used, is up to the implementation.
|
||||
For the same reason this specification does not enforce or prohibit
|
||||
additional information added to the trace (statistics, profiling/timing,
|
||||
warnings on possible error conditions).
|
||||
|
||||
(4) Should the comment strings associated with names and pointer (ranges)
|
||||
be considered persistent state?
|
||||
|
||||
RESOLVED: No. The implementation is not forced to use this information
|
||||
on subsequent occurences of name/pointer, and is free to consider it
|
||||
transient state.
|
||||
|
||||
(5) Should comment commands be prohibited between Begin/End?
|
||||
|
||||
RESOLVED: Yes, with the exception of TraceCommentMESA. TraceCommentMESA
|
||||
is transient, the other commands might cause storage of persistent
|
||||
data in the context. There is no need to have the ability mark names
|
||||
or pointers between Begin and End.
|
||||
|
||||
|
||||
New Procedures and Functions
|
||||
|
||||
void NewTraceMESA( bitfield mask, const ubyte * traceName )
|
||||
|
||||
void EndTraceMESA( void )
|
||||
|
||||
void EnableTraceMESA( bitfield mask )
|
||||
|
||||
void DisableTraceMESA( bitfield mask )
|
||||
|
||||
void TraceAssertAttribMESA( bitfield attribMask )
|
||||
|
||||
void TraceCommentMESA( const ubyte* comment )
|
||||
|
||||
void TraceTextureMESA( uint name, const ubyte* comment )
|
||||
|
||||
void TraceListMESA( uint name, const ubyte* comment )
|
||||
|
||||
void TracePointerMESA( void* pointer, const ubyte* comment )
|
||||
|
||||
void TracePointerRangeMESA( const void* first,
|
||||
const void* last,
|
||||
const ubyte* comment )
|
||||
|
||||
New Tokens
|
||||
|
||||
Accepted by the <mask> parameter of EnableTrace and DisableTrace:
|
||||
|
||||
TRACE_ALL_BITS_MESA 0xFFFF
|
||||
TRACE_OPERATIONS_BIT_MESA 0x0001
|
||||
TRACE_PRIMITIVES_BIT_MESA 0x0002
|
||||
TRACE_ARRAYS_BIT_MESA 0x0004
|
||||
TRACE_TEXTURES_BIT_MESA 0x0008
|
||||
TRACE_PIXELS_BIT_MESA 0x0010
|
||||
TRACE_ERRORS_BIT_MESA 0x0020
|
||||
|
||||
Accepted by the <pname> parameter of GetIntegerv, GetBooleanv,
|
||||
GetFloatv, and GetDoublev:
|
||||
|
||||
TRACE_MASK_MESA 0x8755
|
||||
|
||||
Accepted by the <pname> parameter to GetString:
|
||||
|
||||
TRACE_NAME_MESA 0x8756
|
||||
|
||||
|
||||
Additions to Chapter 2 of the OpenGL 1.2.1 Specification (OpenGL Operation)
|
||||
|
||||
None.
|
||||
|
||||
Additions to Chapter 3 of the OpenGL 1.2.1 Specification (OpenGL Operation)
|
||||
|
||||
None.
|
||||
|
||||
Additions to Chapter 4 of the OpenGL 1.2.1 Specification (OpenGL Operation)
|
||||
|
||||
None.
|
||||
|
||||
Additions to Chapter 5 of the OpenGL 1.2.1 Specification (Special Functions)
|
||||
|
||||
Add a new section:
|
||||
|
||||
5.7 Tracing
|
||||
|
||||
The tracing facility is used to record the execution of a GL program
|
||||
to a human-readable log. The log appears as a sequence of GL commands
|
||||
using C syntax. The primary intention of tracing is to aid in program
|
||||
debugging.
|
||||
|
||||
A trace is started with the command
|
||||
|
||||
void NewTraceMESA( bitfield mask, const GLubyte * traceName )
|
||||
|
||||
<mask> may be any value accepted by PushAttrib and specifies a set of
|
||||
attribute groups. The state values included in those attribute groups
|
||||
is written to the trace as a sequence of GL commands.
|
||||
|
||||
<traceName> specifies a name or label for the trace. It is expected
|
||||
that <traceName> will be interpreted as a filename in most implementations.
|
||||
|
||||
A trace is ended by calling the command
|
||||
|
||||
void EndTraceMESA( void )
|
||||
|
||||
It is illegal to call NewTraceMESA or EndTraceMESA between Begin and End.
|
||||
|
||||
The commands
|
||||
|
||||
void EnableTraceMESA( bitfield mask )
|
||||
void DisableTraceMESA( bitfield mask )
|
||||
|
||||
enable or disable tracing of different classes of GL commands.
|
||||
<mask> may be the union of any of TRACE_OPERATIONS_BIT_MESA,
|
||||
TRACE_PRIMITIVES_BIT_MESA, TRACE_ARRAYS_BIT_MESA, TRACE_TEXTURES_BIT_MESA,
|
||||
and TRACE_PIXELS_BIT_MESA. The special token TRACE_ALL_BITS_MESA
|
||||
indicates all classes of commands are to be logged.
|
||||
|
||||
TRACE_OPERATIONS_BIT_MESA controls logging of all commands outside of
|
||||
Begin/End, including Begin/End.
|
||||
|
||||
TRACE_PRIMITIVES_BIT_MESA controls logging of all commands inside of
|
||||
Begin/End, including Begin/End.
|
||||
|
||||
TRACE_ARRAYS_BIT_MESA controls logging of VertexPointer, NormalPointer,
|
||||
ColorPointer, IndexPointer, TexCoordPointer and EdgeFlagPointer commands.
|
||||
|
||||
TRACE_TEXTURES_BIT_MESA controls logging of texture data dereferenced by
|
||||
TexImage1D, TexImage2D, TexImage3D, TexSubImage1D, TexSubImage2D, and
|
||||
TexSubImage3D commands.
|
||||
|
||||
TRACE_PIXELS_BIT_MESA controls logging of image data dereferenced by
|
||||
Bitmap and DrawPixels commands.
|
||||
|
||||
TRACE_ERRORS_BIT_MESA controls logging of all errors. If this bit is
|
||||
set, GetError will be executed whereever applicable, and the result will
|
||||
be added to the trace as a comment. The error returns are cached and
|
||||
returned to the application on its GetError calls. If the user does not
|
||||
wish the additional GetError calls to be performed, this bit should not
|
||||
be set.
|
||||
|
||||
The command
|
||||
|
||||
void TraceCommentMESA( const ubyte* comment )
|
||||
|
||||
immediately adds the <comment> string to the trace output, surrounded
|
||||
by C-style comment delimiters.
|
||||
|
||||
The commands
|
||||
|
||||
void TraceTextureMESA( uint name, const ubyte* comment )
|
||||
void TraceListMESA( uint name, const ubyte* comment )
|
||||
|
||||
associates <comment> with the texture object or display list specified
|
||||
by <name>. Logged commands which reference the named texture object or
|
||||
display list will be annotated with <comment>. If IsTexture(name) or
|
||||
IsList(name) fail (respectively) the command is quietly ignored.
|
||||
|
||||
The commands
|
||||
|
||||
void TracePointerMESA( void* pointer, const ubyte* comment )
|
||||
|
||||
void TracePointerRangeMESA( const void* first,
|
||||
const void* last,
|
||||
const ubyte* comment )
|
||||
|
||||
associate <comment> with the address specified by <pointer> or with
|
||||
a range of addresses specified by <first> through <last>.
|
||||
Any logged commands which reference <pointer> or an address between
|
||||
<first> and <last> will be annotated with <comment>.
|
||||
|
||||
The command
|
||||
|
||||
void TraceAssertAttribMESA( bitfield attribMask )
|
||||
|
||||
will add GL state queries and assertion statements to the log to
|
||||
confirm that the current state at the time TraceAssertAttrib is
|
||||
executed matches the current state when the trace log is executed
|
||||
in the future.
|
||||
|
||||
<attribMask> is any value accepted by PushAttrib and specifies
|
||||
the groups of state variables which are to be asserted.
|
||||
|
||||
The commands NewTraceMESA, EndTraceMESA, EnableTraceMESA, DisableTraceMESA,
|
||||
TraceAssertAttribMESA, TraceCommentMESA, TraceTextureMESA, TraceListMESA,
|
||||
TracePointerMESA and TracePointerRangeMESA are not compiled into display lists.
|
||||
|
||||
|
||||
Examples:
|
||||
|
||||
The command NewTraceMESA(DEPTH_BUFFER_BIT, "log") will query the state
|
||||
variables DEPTH_TEST, DEPTH_FUNC, DEPTH_WRITEMASK, and DEPTH_CLEAR_VALUE
|
||||
to get the values <test>, <func>, <mask>, and <clear> respectively.
|
||||
Statements equivalent to the following will then be logged:
|
||||
|
||||
glEnable(GL_DEPTH_TEST); (if <test> is true)
|
||||
glDisable(GL_DEPTH_TEST); (if <test> is false)
|
||||
glDepthFunc(<func>);
|
||||
glDepthMask(<mask>);
|
||||
glClearDepth(<clear>);
|
||||
|
||||
|
||||
The command TraceAssertAttribMESA(DEPTH_BUFFER_BIT) will query the state
|
||||
variables DEPTH_TEST, DEPTH_FUNC, DEPTH_WRITEMASK, and DEPTH_CLEAR_VALUE
|
||||
to get the values <test>, <func>, <mask>, and <clear> respectively.
|
||||
The resulting trace might then look will like this:
|
||||
|
||||
{
|
||||
GLboolean b;
|
||||
GLint i;
|
||||
GLfloat f;
|
||||
b = glIsEnabled(GL_DEPTH_TEST);
|
||||
assert(b == <test>);
|
||||
glGetIntegerv(GL_DEPTH_FUNC, &i);
|
||||
assert(i == <func>);
|
||||
glGetIntegerv(GL_DEPTH_MASK, &i);
|
||||
assert(i == <mask>);
|
||||
glGetFloatv(GL_DEPTH_CLEAR_VALUE, &f);
|
||||
assert(f == <clear>);
|
||||
}
|
||||
|
||||
|
||||
Additions to Chapter 6 of the OpenGL 1.2.1 Specification
|
||||
(State and State Requests)
|
||||
|
||||
Querying TRACE_MASK_MESA with GetIntegerv, GetFloatv, GetBooleanv or
|
||||
GetDoublev returns the current command class trace mask.
|
||||
|
||||
Querying TRACE_NAME_MESA with GetString returns the current trace name.
|
||||
|
||||
|
||||
Additions to Appendix A of the OpenGL 1.2.1 Specification (Invariance)
|
||||
|
||||
The MESA_trace extension can be used in a way that does not affect data
|
||||
flow from application to OpenGL, as well as data flow from OpenGL to
|
||||
application, except for timing, possible print I/O. TRACE_ERRORS_BIT_MESA
|
||||
will add additional GetError queries. Setting a trace mask with NewTraceMESA
|
||||
as well as use of TraceAssertAttribMESA might cause additional state queries.
|
||||
With the possible exception of performance, OpenGL rendering should not be
|
||||
affected at all by a properly chosen logging operation.
|
||||
|
||||
Additions to the AGL/GLX/WGL Specifications
|
||||
|
||||
None.
|
||||
|
||||
GLX Protocol
|
||||
|
||||
None. The logging operation is carried out client-side, by exporting
|
||||
entry points to the wrapper functions that execute the logging operation.
|
||||
|
||||
Errors
|
||||
|
||||
INVALID_OPERATION is generated if any trace command except TraceCommentMESA
|
||||
is called between Begin and End.
|
||||
|
||||
New State
|
||||
|
||||
The current trace name and current command class mask are stored
|
||||
per-context.
|
||||
|
||||
New Implementation Dependent State
|
||||
|
||||
None.
|
||||
|
||||
Revision History
|
||||
|
||||
* Revision 0.1 - Initial draft from template (bk000415)
|
||||
* Revision 0.2 - Draft (bk000906)
|
||||
* Revision 0.3 - Draft (bk000913)
|
||||
* Revision 0.4 - Reworked text, fixed typos (bp000914)
|
||||
* Revision 0.5 - Assigned final GLenum values (bp001103)
|
||||
* Revision 0.6 - TRACE_ERRORS_BIT_MESA (bk000916)
|
||||
* Revision 0.7 - Added MESA postfix (bk010126)
|
||||
|
||||
@@ -0,0 +1,202 @@
|
||||
Name
|
||||
|
||||
WL_bind_wayland_display
|
||||
|
||||
Name Strings
|
||||
|
||||
EGL_WL_bind_wayland_display
|
||||
|
||||
Contact
|
||||
|
||||
Kristian Høgsberg <krh@bitplanet.net>
|
||||
Benjamin Franzke <benjaminfranzke@googlemail.com>
|
||||
|
||||
Status
|
||||
|
||||
Proposal
|
||||
|
||||
Version
|
||||
|
||||
Version 5, July 16, 2013
|
||||
|
||||
Number
|
||||
|
||||
EGL Extension #not assigned
|
||||
|
||||
Dependencies
|
||||
|
||||
Requires EGL 1.4 or later. This extension is written against the
|
||||
wording of the EGL 1.4 specification.
|
||||
|
||||
EGL_KHR_base_image is required.
|
||||
|
||||
Overview
|
||||
|
||||
This extension provides entry points for binding and unbinding the
|
||||
wl_display of a Wayland compositor to an EGLDisplay. Binding a
|
||||
wl_display means that the EGL implementation should provide one or
|
||||
more interfaces in the Wayland protocol to allow clients to create
|
||||
wl_buffer objects. On the server side, this extension also
|
||||
provides a new target for eglCreateImageKHR, to create an EGLImage
|
||||
from a wl_buffer
|
||||
|
||||
Adding an implementation specific wayland interface, allows the
|
||||
EGL implementation to define specific wayland requests and events,
|
||||
needed for buffer sharing in an EGL wayland platform.
|
||||
|
||||
IP Status
|
||||
|
||||
Open-source; freely implementable.
|
||||
|
||||
New Procedures and Functions
|
||||
|
||||
EGLBoolean eglBindWaylandDisplayWL(EGLDisplay dpy,
|
||||
struct wl_display *display);
|
||||
|
||||
EGLBoolean eglUnbindWaylandDisplayWL(EGLDisplay dpy,
|
||||
struct wl_display *display);
|
||||
|
||||
EGLBoolean eglQueryWaylandBufferWL(EGLDisplay dpy,
|
||||
struct wl_resource *buffer,
|
||||
EGLint attribute, EGLint *value);
|
||||
|
||||
New Tokens
|
||||
|
||||
Accepted as <target> in eglCreateImageKHR
|
||||
|
||||
EGL_WAYLAND_BUFFER_WL 0x31D5
|
||||
|
||||
Accepted in the <attrib_list> parameter of eglCreateImageKHR:
|
||||
|
||||
EGL_WAYLAND_PLANE_WL 0x31D6
|
||||
|
||||
Possible values for EGL_TEXTURE_FORMAT:
|
||||
|
||||
EGL_TEXTURE_Y_U_V_WL 0x31D7
|
||||
EGL_TEXTURE_Y_UV_WL 0x31D8
|
||||
EGL_TEXTURE_Y_XUXV_WL 0x31D9
|
||||
EGL_TEXTURE_EXTERNAL_WL 0x31DA
|
||||
|
||||
Accepted in the <attribute> parameter of eglQueryWaylandBufferWL:
|
||||
|
||||
EGL_TEXTURE_FORMAT 0x3080
|
||||
EGL_WAYLAND_Y_INVERTED_WL 0x31DB
|
||||
|
||||
|
||||
Additions to the EGL 1.4 Specification:
|
||||
|
||||
To bind a server side wl_display to an EGLDisplay, call
|
||||
|
||||
EGLBoolean eglBindWaylandDisplayWL(EGLDisplay dpy,
|
||||
struct wl_display *display);
|
||||
|
||||
To unbind a server side wl_display from an EGLDisplay, call
|
||||
|
||||
EGLBoolean eglUnbindWaylandDisplayWL(EGLDisplay dpy,
|
||||
struct wl_display *display);
|
||||
|
||||
eglBindWaylandDisplayWL returns EGL_FALSE when there is already a
|
||||
wl_display bound to EGLDisplay otherwise EGL_TRUE.
|
||||
|
||||
eglUnbindWaylandDisplayWL returns EGL_FALSE when there is no
|
||||
wl_display bound to the EGLDisplay currently otherwise EGL_TRUE.
|
||||
|
||||
A wl_buffer can have several planes, typically in case of planar
|
||||
YUV formats. Depending on the exact YUV format in use, the
|
||||
compositor will have to create one or more EGLImages for the
|
||||
various planes. The eglQueryWaylandBufferWL function should be
|
||||
used to first query the wl_buffer texture format using
|
||||
EGL_TEXTURE_FORMAT as the attribute. If the wl_buffer object is
|
||||
not an EGL wl_buffer (wl_shm and other wayland extensions can
|
||||
create wl_buffer objects of different types), this query will
|
||||
return EGL_FALSE. In that case the wl_buffer can not be used with
|
||||
EGL and the compositor should have another way to get the buffer
|
||||
contents.
|
||||
|
||||
If eglQueryWaylandBufferWL succeeds, the returned value will be
|
||||
one of EGL_TEXTURE_RGB, EGL_TEXTURE_RGBA, EGL_TEXTURE_Y_U_V_WL,
|
||||
EGL_TEXTURE_Y_UV_WL, EGL_TEXTURE_Y_XUXV_WL. The value returned
|
||||
describes how many EGLImages must be used, which components will
|
||||
be sampled from each EGLImage and how they map to rgba components
|
||||
in the shader. The naming conventions separates planes by _ and
|
||||
within each plane, the order or R, G, B, A, Y, U, and V indicates
|
||||
how those components map to the rgba value returned by the
|
||||
sampler. X indicates that the corresponding component in the rgba
|
||||
value isn't used.
|
||||
|
||||
RGB and RGBA buffer types:
|
||||
|
||||
EGL_TEXTURE_RGB
|
||||
One plane, samples RGB from the texture to rgb in the
|
||||
shader. Alpha channel is not valid.
|
||||
|
||||
EGL_TEXTURE_RGBA
|
||||
One plane, samples RGBA from the texture to rgba in the
|
||||
shader.
|
||||
|
||||
YUV buffer types:
|
||||
|
||||
EGL_TEXTURE_Y_U_V_WL
|
||||
Three planes, samples Y from the first plane to r in
|
||||
the shader, U from the second plane to r, and V from
|
||||
the third plane to r.
|
||||
|
||||
EGL_TEXTURE_Y_UV_WL
|
||||
Two planes, samples Y from the first plane to r in
|
||||
the shader, U and V from the second plane to rg.
|
||||
|
||||
EGL_TEXTURE_Y_XUXV_WL
|
||||
Two planes, samples Y from the first plane to r in
|
||||
the shader, U and V from the second plane to g and a.
|
||||
|
||||
EGL_TEXTURE_EXTERNAL_WL
|
||||
Treated as a single plane texture, but sampled with
|
||||
samplerExternalOES according to OES_EGL_image_external
|
||||
|
||||
After querying the wl_buffer layout, create EGLImages for the
|
||||
planes by calling eglCreateImageKHR with wl_buffer as
|
||||
EGLClientBuffer, EGL_WAYLAND_BUFFER_WL as the target, NULL
|
||||
context. If no attributes are given, an EGLImage will be created
|
||||
for the first plane. For multi-planar buffers, specify the plane
|
||||
to create the EGLImage for by using the EGL_WAYLAND_PLANE_WL
|
||||
attribute. The value of the attribute is the index of the plane,
|
||||
as defined by the buffer format. Writing to an EGLImage created
|
||||
from a wl_buffer in any way (such as glTexImage2D, binding the
|
||||
EGLImage as a renderbuffer etc) will result in undefined behavior.
|
||||
|
||||
Further, eglQueryWaylandBufferWL accepts attributes EGL_WIDTH and
|
||||
EGL_HEIGHT to query the width and height of the wl_buffer.
|
||||
|
||||
Also, eglQueryWaylandBufferWL may accept
|
||||
EGL_WAYLAND_Y_INVERTED_WL attribute to query orientation of
|
||||
wl_buffer. If EGL_WAYLAND_Y_INVERTED_WL is supported
|
||||
eglQueryWaylandBufferWL returns EGL_TRUE and value is a boolean
|
||||
that tells if wl_buffer is y-inverted or not. If
|
||||
EGL_WAYLAND_Y_INVERTED_WL is not supported
|
||||
eglQueryWaylandBufferWL returns EGL_FALSE, in that case
|
||||
wl_buffer should be treated as if value of
|
||||
EGL_WAYLAND_Y_INVERTED_WL was EGL_TRUE.
|
||||
|
||||
Issues
|
||||
|
||||
Revision History
|
||||
|
||||
Version 1, March 1, 2011
|
||||
Initial draft (Benjamin Franzke)
|
||||
Version 2, July 5, 2012
|
||||
Add EGL_WAYLAND_PLANE_WL attribute to allow creating an EGLImage
|
||||
for different planes of planar buffer. (Kristian Høgsberg)
|
||||
Version 3, July 10, 2012
|
||||
Add eglQueryWaylandBufferWL and the various buffer
|
||||
formats. (Kristian Høgsberg)
|
||||
Version 4, July 19, 2012
|
||||
Use EGL_TEXTURE_FORMAT, EGL_TEXTURE_RGB, and EGL_TEXTURE_RGBA,
|
||||
and just define the new YUV texture formats. Add support for
|
||||
EGL_WIDTH and EGL_HEIGHT in the query attributes (Kristian Høgsberg)
|
||||
Version 5, July 16, 2013
|
||||
Change eglQueryWaylandBufferWL to take a resource pointer to the
|
||||
buffer instead of a pointer to a struct wl_buffer, as the latter has
|
||||
been deprecated. (Ander Conselvan de Oliveira)
|
||||
Version 6, September 16, 2013
|
||||
Add EGL_WAYLAND_Y_INVERTED_WL attribute to allow specifying
|
||||
wl_buffer's orientation.
|
||||
@@ -0,0 +1,101 @@
|
||||
Name
|
||||
|
||||
WL_create_wayland_buffer_from_image
|
||||
|
||||
Name Strings
|
||||
|
||||
EGL_WL_create_wayland_buffer_from_image
|
||||
|
||||
Contributors
|
||||
|
||||
Neil Roberts
|
||||
Axel Davy
|
||||
Daniel Stone
|
||||
|
||||
Contact
|
||||
|
||||
Neil Roberts <neil.s.roberts@intel.com>
|
||||
|
||||
Status
|
||||
|
||||
Proposal
|
||||
|
||||
Version
|
||||
|
||||
Version 2, October 25, 2013
|
||||
|
||||
Number
|
||||
|
||||
EGL Extension #not assigned
|
||||
|
||||
Dependencies
|
||||
|
||||
Requires EGL 1.4 or later. This extension is written against the
|
||||
wording of the EGL 1.4 specification.
|
||||
|
||||
EGL_KHR_base_image is required.
|
||||
|
||||
Overview
|
||||
|
||||
This extension provides an entry point to create a wl_buffer which shares
|
||||
its contents with a given EGLImage. The expected use case for this is in a
|
||||
nested Wayland compositor which is using subsurfaces to present buffers
|
||||
from its clients. Using this extension it can attach the client buffers
|
||||
directly to the subsurface without having to blit the contents into an
|
||||
intermediate buffer. The compositing can then be done in the parent
|
||||
compositor.
|
||||
|
||||
The nested compositor can create an EGLImage from a client buffer resource
|
||||
using the existing WL_bind_wayland_display extension. It should also be
|
||||
possible to create buffers using other types of images although there is
|
||||
no expected use case for that.
|
||||
|
||||
IP Status
|
||||
|
||||
Open-source; freely implementable.
|
||||
|
||||
New Procedures and Functions
|
||||
|
||||
struct wl_buffer *eglCreateWaylandBufferFromImageWL(EGLDisplay dpy,
|
||||
EGLImageKHR image);
|
||||
|
||||
New Tokens
|
||||
|
||||
None.
|
||||
|
||||
Additions to the EGL 1.4 Specification:
|
||||
|
||||
To create a client-side wl_buffer from an EGLImage call
|
||||
|
||||
struct wl_buffer *eglCreateWaylandBufferFromImageWL(EGLDisplay dpy,
|
||||
EGLImageKHR image);
|
||||
|
||||
The returned buffer will share the contents with the given EGLImage. Any
|
||||
updates to the image will also be updated in the wl_buffer. Typically the
|
||||
EGLImage will be generated in a nested Wayland compositor using a buffer
|
||||
resource from a client via the EGL_WL_bind_wayland_display extension.
|
||||
|
||||
If there was an error then the function will return NULL. In particular it
|
||||
will generate EGL_BAD_MATCH if the implementation is not able to represent
|
||||
the image as a wl_buffer. The possible reasons for this error are
|
||||
implementation-dependant but may include problems such as an unsupported
|
||||
format or tiling mode or that the buffer is in memory that is inaccessible
|
||||
to the GPU that the given EGLDisplay is using.
|
||||
|
||||
Issues
|
||||
|
||||
1) Under what circumstances can the EGL_BAD_MATCH error be generated? Does
|
||||
this include for example unsupported tiling modes?
|
||||
|
||||
RESOLVED: Yes, the EGL_BAD_MATCH error can be generated for any reason
|
||||
which prevents the implementation from representing the image as a
|
||||
wl_buffer. For example, these problems can be but are not limited to
|
||||
unsupported tiling modes, inaccessible memory or an unsupported pixel
|
||||
format.
|
||||
|
||||
Revision History
|
||||
|
||||
Version 1, September 6, 2013
|
||||
Initial draft (Neil Roberts)
|
||||
Version 2, October 25, 2013
|
||||
Added a note about more possible reasons for returning EGL_BAD_FORMAT.
|
||||
@@ -0,0 +1,104 @@
|
||||
The definitive source for enum values and reserved ranges are the XML files in
|
||||
the Khronos registry:
|
||||
|
||||
https://github.com/KhronosGroup/EGL-Registry/blob/master/api/egl.xml
|
||||
https://github.com/KhronosGroup/OpenGL-Registry/blob/master/xml/gl.xml
|
||||
https://github.com/KhronosGroup/OpenGL-Registry/blob/master/xml/glx.xml
|
||||
https://github.com/KhronosGroup/OpenGL-Registry/blob/master/xml/wgl.xml
|
||||
|
||||
GL blocks allocated to Mesa:
|
||||
0x8750-0x875F
|
||||
0x8BB0-0x8BBF
|
||||
|
||||
Unused EGL blocks allocated to Mesa:
|
||||
0x31DC
|
||||
0x31DE
|
||||
0x31DF
|
||||
0x3290-0x329F
|
||||
|
||||
GL_MESA_packed_depth_stencil
|
||||
GL_DEPTH_STENCIL_MESA 0x8750
|
||||
GL_UNSIGNED_INT_24_8_MESA 0x8751
|
||||
GL_UNSIGNED_INT_8_24_REV_MESA 0x8752
|
||||
GL_UNSIGNED_SHORT_15_1_MESA 0x8753
|
||||
GL_UNSIGNED_SHORT_1_15_REV_MESA 0x8754
|
||||
|
||||
GL_MESA_trace:
|
||||
GL_TRACE_ALL_BITS_MESA 0xFFFF
|
||||
GL_TRACE_OPERATIONS_BIT_MESA 0x0001
|
||||
GL_TRACE_PRIMITIVES_BIT_MESA 0x0002
|
||||
GL_TRACE_ARRAYS_BIT_MESA 0x0004
|
||||
GL_TRACE_TEXTURES_BIT_MESA 0x0008
|
||||
GL_TRACE_PIXELS_BIT_MESA 0x0010
|
||||
GL_TRACE_ERRORS_BIT_MESA 0x0020
|
||||
GL_TRACE_MASK_MESA 0x8755
|
||||
GL_TRACE_NAME_MESA 0x8756
|
||||
|
||||
GL_MESA_ycbcr_texture:
|
||||
GL_YCBCR_MESA 0x8757
|
||||
GL_UNSIGNED_SHORT_8_8_MESA 0x85BA /* same as Apple's */
|
||||
GL_UNSIGNED_SHORT_8_8_REV_MESA 0x85BB /* same as Apple's */
|
||||
|
||||
GL_MESA_pack_invert:
|
||||
GL_PACK_INVERT_MESA 0x8758
|
||||
|
||||
GL_MESA_shader_debug.spec: (obsolete)
|
||||
GL_DEBUG_OBJECT_MESA 0x8759
|
||||
GL_DEBUG_PRINT_MESA 0x875A
|
||||
GL_DEBUG_ASSERT_MESA 0x875B
|
||||
|
||||
GL_MESA_program_debug: (obsolete)
|
||||
GL_FRAGMENT_PROGRAM_POSITION_MESA 0x8BB0
|
||||
GL_FRAGMENT_PROGRAM_CALLBACK_MESA 0x8BB1
|
||||
GL_FRAGMENT_PROGRAM_CALLBACK_FUNC_MESA 0x8BB2
|
||||
GL_FRAGMENT_PROGRAM_CALLBACK_DATA_MESA 0x8BB3
|
||||
GL_VERTEX_PROGRAM_POSITION_MESA 0x8BB4
|
||||
GL_VERTEX_PROGRAM_CALLBACK_MESA 0x8BB5
|
||||
GL_VERTEX_PROGRAM_CALLBACK_FUNC_MESA 0x8BB6
|
||||
GL_VERTEX_PROGRAM_CALLBACK_DATA_MESA 0x8BB7
|
||||
|
||||
GL_MESAX_texture_stack:
|
||||
GL_TEXTURE_1D_STACK_MESAX 0x8759
|
||||
GL_TEXTURE_2D_STACK_MESAX 0x875A
|
||||
GL_PROXY_TEXTURE_1D_STACK_MESAX 0x875B
|
||||
GL_PROXY_TEXTURE_2D_STACK_MESAX 0x875C
|
||||
GL_TEXTURE_1D_STACK_BINDING_MESAX 0x875D
|
||||
GL_TEXTURE_2D_STACK_BINDING_MESAX 0x875E
|
||||
|
||||
GL_MESA_program_binary_formats:
|
||||
GL_PROGRAM_BINARY_FORMAT_MESA 0x875F
|
||||
|
||||
GL_MESA_tile_raster_order
|
||||
GL_TILE_RASTER_ORDER_FIXED_MESA 0x8BB8
|
||||
GL_TILE_RASTER_ORDER_INCREASING_X_MESA 0x8BB9
|
||||
GL_TILE_RASTER_ORDER_INCREASING_Y_MESA 0x8BBA
|
||||
|
||||
GL_MESA_framebuffer_flip_y
|
||||
GL_FRAMEBUFFER_FLIP_Y_MESA 0x8BBB
|
||||
|
||||
EGL_MESA_drm_image
|
||||
EGL_DRM_BUFFER_FORMAT_MESA 0x31D0
|
||||
EGL_DRM_BUFFER_USE_MESA 0x31D1
|
||||
EGL_DRM_BUFFER_FORMAT_ARGB32_MESA 0x31D2
|
||||
EGL_DRM_BUFFER_MESA 0x31D3
|
||||
EGL_DRM_BUFFER_STRIDE_MESA 0x31D4
|
||||
|
||||
EGL_MESA_platform_gbm
|
||||
EGL_PLATFORM_GBM_MESA 0x31D7
|
||||
|
||||
EGL_MESA_platform_surfaceless
|
||||
EGL_PLATFORM_SURFACELESS_MESA 0x31DD
|
||||
|
||||
EGL_MESA_drm_image
|
||||
EGL_DRM_BUFFER_FORMAT_ARGB2101010_MESA 0x3290
|
||||
EGL_DRM_BUFFER_FORMAT_ARGB1555_MESA 0x3291
|
||||
EGL_DRM_BUFFER_FORMAT_RGB565_MESA 0x3292
|
||||
|
||||
EGL_WL_bind_wayland_display
|
||||
EGL_TEXTURE_FORMAT 0x3080
|
||||
EGL_WAYLAND_BUFFER_WL 0x31D5
|
||||
EGL_WAYLAND_PLANE_WL 0x31D6
|
||||
EGL_TEXTURE_Y_U_V_WL 0x31D7
|
||||
EGL_TEXTURE_Y_UV_WL 0x31D8
|
||||
EGL_TEXTURE_Y_XUXV_WL 0x31D9
|
||||
EGL_WAYLAND_Y_INVERTED_WL 0x31DB
|
||||
Reference in New Issue
Block a user