mirror of
https://gitee.com/openharmony/third_party_mesa3d
synced 2024-11-27 09:31:03 +00:00
381fc0eca5
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>
386 lines
18 KiB
Python
386 lines
18 KiB
Python
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.
|