[Mesa-dev] [RFC] GLX_MESA_query_renderer
Ian Romanick
idr at freedesktop.org
Sun Mar 3 17:31:05 PST 2013
On 03/01/2013 05:05 PM, Paul Berry wrote:
> On 1 March 2013 15:14, Ian Romanick <idr at freedesktop.org
> <mailto:idr at freedesktop.org>> wrote:
>
> Since last September I've been gradually working on an extension to
> let applications query information about the renderer before (and
> after) creating a context. I've talked it over with a few ISVs and
> with various other folks. I also gathered some input from folks at
> FOSDEM after my talk there. After going through several iterations
> of review and modification, I think it's finally ready for wider input.
>
> Some of the earliest feedback that I got was that many ISVs really
> like the interface that fills this niche on Mac OS. It's a pretty
> nice API, and this API is modeled after it. There are, however,
> some differences.
>
> I've pasted the spec below so that people can provide in-line
> comments. I've also pushed a branch with the spec and the initial
> implementation. There are a few things potentially provided by the
> spec that are not included in the initial implementation. I've
> implemented a couple unit tests, and I have some piglit tests
> in-progress.
>
> http://cgit.freedesktop.org/~__idr/mesa/log/?h=query-renderer
> <http://cgit.freedesktop.org/~idr/mesa/log/?h=query-renderer>
>
> I'm mostly looking for input on the specification itself. Once this
> is good, I will also add EGL support.
>
>
> Name
>
> MESA_query_renderer
>
> Name Strings
>
> GLX_MESA_query_renderer
>
> Contact
>
> Ian Romanick <ian.d.romanick at intel.com
> <mailto:ian.d.romanick at intel.com>>
>
> IP Status
>
> No known IP claims.
>
> Status
>
> Incomplete. DO NOT SHIP.
>
> Version
>
> Version 5, 14-February-2013
>
> Number
>
> TBD.
>
> Dependencies
>
> GLX 1.4 is required.
>
> GLX_ARB_create_context and GLX_ARB_create_context_profile are
> required.
>
> This extension interacts with
> GLX_EXT_create_context_es2___profile and
> GLX_EXT_create_context_es___profile.
>
> 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 glXQueryCurrentRendererInteger__MESA(int attribute,
> unsigned int *value);
>
> const char *glXQueryRendererStringMESA(__Display *dpy, int screen,
> int renderer, int
> attribute);
>
> const char *__glXQueryCurrentRendererStringM__ESA(int attribute);
>
> New Tokens
>
> Accepted as an <attribute> in glXQueryRendererIntegerMESA:
>
> GLX_RENDERER_VENDOR_ID_MESA 0xXXXX
> GLX_RENDERER_DEVICE_ID_MESA 0xXXXX
> GLX_RENDERER_VERSION_MESA 0xXXXX
> GLX_RENDERER_ACCELERATED_MESA 0xXXXX
> GLX_RENDERER_VIDEO_MEMORY_MESA 0xXXXX
> GLX_RENDERER_UNIFIED_MEMORY___ARCHITECTURE_MESA 0xXXXX
> GLX_RENDERER_PREFERRED___PROFILE_MESA 0xXXXX
> GLX_RENDERER_OPENGL_CORE___PROFILE_VERSION_MESA 0xXXXX
> GLX_RENDERER_OPENGL___COMPATIBILITY_PROFILE_VERSION___MESA
> 0xXXXX
> GLX_RENDERER_OPENGL_ES___PROFILE_VERSION_MESA 0xXXXX
> GLX_RENDERER_OPENGL_ES2___PROFILE_VERSION_MESA 0xXXXX
>
> Accepted as an <attribute> in glXQueryRendererStringMESA:
>
> GLX_RENDERER_VENDOR_ID_MESA
> GLX_RENDERER_DEVICE_ID_MESA
>
> Accepted as an attribute name in <*attrib_list> in
> glXCreateContextAttribsARB:
>
> GLX_RENDERER_ID_MESA 0xXXXX
>
> Additions to the OpenGL / WGL Specifications
>
> None. This specification is written for GLX.
>
> Additions to the GLX 1.4 Specification
>
> [Add the following to Section X.Y.Z of the GLX Specification]
>
> To obtain information about the available renderers for a
> particular
> display and screen,
>
> void 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___COMAPTIBILITY_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.
>
> If <attribute> is not a recognized value, False is returned,
> but no GLX
> error is generated. Otherwise, True is returned.
>
>
> It would be nice to clarify (a) what happens to <value> if <attribute>
> is unrecognized, and (b) that no error is generated if <attribute> is
> recognized. Here's a possibility that clarifies these things and I
> suspect matches your intent: "If <attribute> is not a recognized value,
> False is returned and no data is written to <value>. Otherwise, True is
> returned. Regardless of whether <attribute> is a recognized value, no
> GLX error is generated.
That's a good suggestion.
>
> 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.
>
>
> It's not obvious to me why these two queries might return different
> values than the corresponding glGetString calls. It might be nice to
> have a "for example".
>
> (Issue #15 looks like it's trying to address this question, but I'm
> afraid I don't understand.)
It isn't so much that I thought they would be different. It's more that
I didn't see utility in requiring them to be the same. I could imagine
cases where the GL_RENDERER string might be constructed from data that
isn't known until after creating a context, for example.
> [Add to section section 3.3.7 "Rendering Contexts"]
>
> The attribute name GLX_RENDERER_ID_MESA specified the index of
> the render
>
>
> I think you mean "specifies".
>
> against which the context should be created. The default value of
> GLX_RENDER_ID_MESA is 0.
>
>
> [Add to list of errors for glXCreateContextAttribsARB in
> section section
> 3.3.7 "Rendering Contexts"]
>
> * If the value of GLX_RENDERER_ID_MESA specifies a non-existent
> renderer, BadMatch is generated.
>
> Dependencies on GLX_EXT_create_context_es___profile and
> GLX_EXT_create_context_es2___profile
>
> If neither extension is supported, remove all mention of
> GLX_RENDERER_OPENGL_ES2___PROFILE_VERSION_MESA from the spec.
>
> If GLX_EXT_create_context_es___profile is not supported, remove
> all mention of
> GLX_RENDERER_OPENGL_ES___PROFILE_VERSION_MESA from the spec.
>
> 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 #14 GL functions
> (instead of GLX)?
>
>
> I'm assuming this is a typo and issue #14 isn't trying to refer to itself :)
Good catch. :)
> 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 glXQueryCurrentRendererInteger__MESA 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.
>
> 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.
> _________________________________________________
> mesa-dev mailing list
> mesa-dev at lists.freedesktop.org <mailto:mesa-dev at lists.freedesktop.org>
> http://lists.freedesktop.org/__mailman/listinfo/mesa-dev
> <http://lists.freedesktop.org/mailman/listinfo/mesa-dev>
More information about the mesa-dev
mailing list