[Mesa-dev] GLX extension for vendor name lookup in libglvnd
Kyle Brenneman
kbrenneman at nvidia.com
Thu Mar 10 17:53:35 UTC 2016
On 03/10/2016 10:47 AM, Martin Peres wrote:
> On 09/03/16 20:15, Kyle Brenneman wrote:
>> The current implementation of libglvnd uses a new X extension called
>> x11glvnd to look up a vendor name for each screen and to find a screen
>> number for a GLXDrawable.
>>
>> But, Adam Jackson pointed out that a GLX extension could do the same job
>> more cleanly: Looking up a vendor name is just querying a per-screen
>> string, which GLXQueryServerString does. Looking up a screen number for
>> a drawable could work by adding a GLX_SCREEN attribute to the
>> GLXGetDrawableAttributes reply.
>>
>> Based on that idea, I've written up a rough draft of a GLX extension
>> spec. Any comments, questions, or suggestions are welcome, of course.
>>
>> -Kyle
>>
>>
>> Name
>>
>> EXT_libglvnd
>>
>> Name Strings
>>
>> GLX_EXT_libglvnd
>>
>> Contact
>>
>> Kyle Brenneman, NVIDIA, kbrenneman at nvidia.com
>>
>> Contributors
>>
>> Kyle Brenneman
>> Adam Jackson
>>
>> Status
>>
>> XXX - Not complete yet
>>
>> Version
>>
>> Last Modified Date: March 8, 2016
>> Revision: 1
>>
>> Number
>>
>> ???
>>
>> Dependencies
>>
>> GLX version 1.3 is required.
>>
>> This specification is written against the wording of the GLX 1.4
>> Specification.
>>
>> Overview
>>
>> This extension allows the vendor-neutral GLX client library,
>> libglvnd, to
>> determine which vendor-specific driver is needed to support a given
>> GLX
>> drawable or X11 screen.
>>
>> This GLX extension is not intended to be used directly by
>> applications.
>> Instead, it is intended to be used by the GLX client library.
>>
>> IP Status
>>
>> No known IP claims.
>>
>> New Procedures and Functions
>>
>> None
>>
>> New Types
>>
>> None
>>
>> New Tokens
>>
>> Accepted by the <name> parameter of glXQueryServerString:
>>
>> GLX_VENDOR_NAMES_EXT 0x????
>>
>> Additions to Chapter 3 of the GLX 1.4 Specification
>> (Functions and Errors)
>>
>> [Modify Section 3.3.2, GLX Versioning]
>>
>> [Replace the 2nd sentence of the 5th paragraph with the following]
>>
>> "The possible values for <name> and the format of the strings is
>> the same
>> as for glXGetClientString. <name> may also be
>> GLX_VENDOR_NAMES_EXT."
>>
>> [Add the following paragraph to the end of the section]
>>
>> "If <name> is GLX_VENDOR_NAMES_EXT, then the returned string is a
>> space-separated sequence of vendor names. The names are in order of
>> preference, with the most preferred vendor first."
>>
>>
>> [Modify Section 3.3.6, Querying Attributes]
>>
>> [Replace the 2nd sentence of the 1st paragraph with the following]
>>
>> "<attribute> must be set to one of GLX_WIDTH, GLX_HEIGHT,
>> GLX_PRESERVED_CONTENTS, GLX_LARGEST_PBUFFER, GLX_FBCONFIG_ID, or
>> GLX_SCREEN"
>>
>> [Add the following paragraph just before the last of the section]
>>
>> "If <attribute> is GLX_SCREEN, then <value> will be the screen
>> number that
>> the drawable was created on."
>>
>> GLX Protocol
>>
>> This extension does not add any new requests. The
>> GLX_VENDOR_NAMES_EXT enum
>> is used with the existing glXQueryServerString request, and
>> GLX_SCREEN is
>> added to the attributes in the glXGetDrawableAttributes reply.
>>
>> Errors
>>
>> None
>>
>> Issues
>> 1) Should GLX_VENDOR_NAMES_EXT contain a single vendor name or a
>> list of
>> names?
>>
>> Allowing multiple names would allow for multiple client-side
>> drivers
>> that work with a single server-side driver. With only a single
>> name,
>> selecting between multiple client drivers would require some
>> form of
>> additional configuration.
>>
>> 2) How are vendor names defined and interpreted?
>>
>> The vendor names for a screen are defined based on the server's
>> GLX
>> implementation. Typically, a server will simply send the name
>> of the
>> driver that controls the screen.
>>
>> The GLX client library is responsible for translating the
>> vendor name
>> to a vendor library name. The details of the translation are
>> part of
>> the interface between the vendor library and the GLX client
>> library,
>> and so is not defined in this specification.
>>
>> 3) What order should the vendor names be returned in?
>>
>> The GLX client library will try to load and use each vendor
>> name, in
>> the order that the server lists them. It will stop when it
>> finds the
>> first vendor that works.
>
> That could be a hacky way of handling the case where multiple 3D
> drivers could be used to drive the same GPU. This may be necessary in
> the future if two mesa drivers support the same GPU but one is
> considered better than the other. We can also imagine a case where a
> proprietary driver would need to be co-installable with an open source
> one and would still use the same DDX. Isn't that what AMD is going to
> do soon? Did anyone think about this case?
That case is the reason for allowing multiple vendor names. For a case
like AMD's driver, it would hand back two names. The order would be up
to the driver implementation, but I would guess that it would list the
proprietary driver first and the open source driver second. If the
proprietary one is installed, then the client would use it, and if not,
the client would use the open source one.
More information about the mesa-dev
mailing list