Re: [Mesa-dev] GLX extension for vendor name lookup in libglvnd
On 14/03/16 19:59, Kyle Brenneman wrote: On 03/14/2016 11:43 AM, Martin Peres wrote: On 14/03/16 19:16, Kyle Brenneman wrote: On 03/11/2016 05:25 PM, Martin Peres wrote: On 10/03/16 20:07, Adam Jackson wrote: On Thu, 2016-03-10 at 10:53 -0700, Kyle Brenneman wrote: On 03/10/2016 10:47 AM, Martin Peres wrote: 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. Very good! That could be worth mentioning in the spec. To make it clear that it is the intended goal and to help implementers understand the logic behind this proposal. That's what I meant to convey with the description of multiple client-side drivers that work with the same server-side driver. But if that wasn't clear I can add a more specific example. Would something like this help? For example, some vendors may have both a proprietary client-side vendor library and an open source vendor library that work with the same server-side driver. In that case, the server would return the names for both of the vendor libraries. The client would then be able to select one of those vendor libraries, depending on which of them is installed. This is definitely a nice addition, however, I propose to reword it to add information about priorities: For example, some vendors may have both a proprietary client-side vendor library and an open source vendor library that work with the same server-side driver. In that case, the server would return the names for both of the vendor libraries, in the order of preference. The client would then try to open them sequentially and select the first one that is present and got loaded successfully. How does this sound? Issue #3 addresses the question of how the vendor names are ordered. Instead of duplicating the description, maybe change the last sentence to reference that issue: "The client would then try loading each vendor library as described below in Issue 3." Sounds great! ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] GLX extension for vendor name lookup in libglvnd
On 03/14/2016 11:43 AM, Martin Peres wrote: On 14/03/16 19:16, Kyle Brenneman wrote: On 03/11/2016 05:25 PM, Martin Peres wrote: On 10/03/16 20:07, Adam Jackson wrote: On Thu, 2016-03-10 at 10:53 -0700, Kyle Brenneman wrote: On 03/10/2016 10:47 AM, Martin Peres wrote: 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. Very good! That could be worth mentioning in the spec. To make it clear that it is the intended goal and to help implementers understand the logic behind this proposal. That's what I meant to convey with the description of multiple client-side drivers that work with the same server-side driver. But if that wasn't clear I can add a more specific example. Would something like this help? For example, some vendors may have both a proprietary client-side vendor library and an open source vendor library that work with the same server-side driver. In that case, the server would return the names for both of the vendor libraries. The client would then be able to select one of those vendor libraries, depending on which of them is installed. This is definitely a nice addition, however, I propose to reword it to add information about priorities: For example, some vendors may have both a proprietary client-side vendor library and an open source vendor library that work with the same server-side driver. In that case, the server would return the names for both of the vendor libraries, in the order of preference. The client would then try to open them sequentially and select the first one that is present and got loaded successfully. How does this sound? Issue #3 addresses the question of how the vendor names are ordered. Instead of duplicating the description, maybe change the last sentence to reference that issue: "The client would then try loading each vendor library as described below in Issue 3." ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] GLX extension for vendor name lookup in libglvnd
On 14/03/16 19:16, Kyle Brenneman wrote: On 03/11/2016 05:25 PM, Martin Peres wrote: On 10/03/16 20:07, Adam Jackson wrote: On Thu, 2016-03-10 at 10:53 -0700, Kyle Brenneman wrote: On 03/10/2016 10:47 AM, Martin Peres wrote: 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. Very good! That could be worth mentioning in the spec. To make it clear that it is the intended goal and to help implementers understand the logic behind this proposal. That's what I meant to convey with the description of multiple client-side drivers that work with the same server-side driver. But if that wasn't clear I can add a more specific example. Would something like this help? For example, some vendors may have both a proprietary client-side vendor library and an open source vendor library that work with the same server-side driver. In that case, the server would return the names for both of the vendor libraries. The client would then be able to select one of those vendor libraries, depending on which of them is installed. This is definitely a nice addition, however, I propose to reword it to add information about priorities: For example, some vendors may have both a proprietary client-side vendor library and an open source vendor library that work with the same server-side driver. In that case, the server would return the names for both of the vendor libraries, in the order of preference. The client would then try to open them sequentially and select the first one that is present and got loaded successfully. How does this sound? ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] GLX extension for vendor name lookup in libglvnd
On 03/11/2016 05:25 PM, Martin Peres wrote: On 10/03/16 20:07, Adam Jackson wrote: On Thu, 2016-03-10 at 10:53 -0700, Kyle Brenneman wrote: On 03/10/2016 10:47 AM, Martin Peres wrote: 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. Very good! That could be worth mentioning in the spec. To make it clear that it is the intended goal and to help implementers understand the logic behind this proposal. That's what I meant to convey with the description of multiple client-side drivers that work with the same server-side driver. But if that wasn't clear I can add a more specific example. Would something like this help? For example, some vendors may have both a proprietary client-side vendor library and an open source vendor library that work with the same server-side driver. In that case, the server would return the names for both of the vendor libraries. The client would then be able to select one of those vendor libraries, depending on which of them is installed. Right. It's pretty straightforward (and I plan) to wire this logic through to xorg.conf, so the admin can control the list at server startup time. Historically it's been somewhat pointless to do so, since all the proprietary drivers have also replaced the server's GLX module, but this gives us a path towards not doing that anymore at least. I'd also considered using this mechanism as a starting path towards both implementing GLX+Xinerama at all for the open drivers, and eventually to do that with heterogeneous open/closed GLX on the server side. Those are both fairly long term prospects, but I imagine it'll be easier to do if we can opt into different client-side logic. Sounds indeed like a good thing to have! Accelerated xinerama using prime and reverse prime on multiple drivers :) ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] GLX extension for vendor name lookup in libglvnd
On 10/03/16 20:07, Adam Jackson wrote: On Thu, 2016-03-10 at 10:53 -0700, Kyle Brenneman wrote: On 03/10/2016 10:47 AM, Martin Peres wrote: 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. Very good! That could be worth mentioning in the spec. To make it clear that it is the intended goal and to help implementers understand the logic behind this proposal. Right. It's pretty straightforward (and I plan) to wire this logic through to xorg.conf, so the admin can control the list at server startup time. Historically it's been somewhat pointless to do so, since all the proprietary drivers have also replaced the server's GLX module, but this gives us a path towards not doing that anymore at least. I'd also considered using this mechanism as a starting path towards both implementing GLX+Xinerama at all for the open drivers, and eventually to do that with heterogeneous open/closed GLX on the server side. Those are both fairly long term prospects, but I imagine it'll be easier to do if we can opt into different client-side logic. Sounds indeed like a good thing to have! Accelerated xinerama using prime and reverse prime on multiple drivers :) ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] GLX extension for vendor name lookup in libglvnd
On Fri, 2016-03-11 at 11:12 -0700, Kyle Brenneman wrote: > All right, here's an updated draft of the Issues section. How does it look? > > Issues > 1) Should GLX_VENDOR_NAMES_EXT contain a single vendor name or a list of > names? > > UNRESOLVED: Allow 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? > > UNRESOLVED: 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 are not defined in this specification. > > 3) What order should the vendor names be returned in? > > UNRESOLVED: If there are multiple vendor names, then the client > should > use the names earlier in the list in preference to names later in the > list. > > Specifically, 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. > > 4) Does the vendor name list need a new enum? Could it be appended to > the > GLX_VENDOR string instead? > > UNRESOLVED: Use a new enum. The vendor-specific part of the > GLX_VENDOR > string is by definition arbitrary, even if in practice every most if > not all GLX implementatinos leave it blank. > > In addition, using a new enum also makes parsing the string much > easier. The client can simply pass the unmodified string to strtok or > strtok_r. > > 5) Do we need to define the interaction with GLX_SGIX_pbuffer? > > UNRESOLVED. No. Any client or server that implements this extension > will already support GLX 1.3, so using glXQueryDrawable to look up a > screen number is sufficient. > > There's no harm if a server includes a GLX_SCREEN attribute in its > GetDrawableAttributesSGIX reply, so a server is still free to use the > same codepath for GetDrawableAttributesSGIX and > glXGetDrawableAttributes. > > 6) Do we want to add GLX_SCREEN to the list of fbconfig attributes as > well? > > UNRESOLVED: No. Adding GLX_SCREEN to glXGetDrawableAttributes would > be Should be glXGetFBConfigAttrib. > redundant, because a client can already find the screen number for a > GLXFBConfig using glXGetVisualFromFBConfig and indirectly using > glXGetFBConfigs. Other than that I think we can say these are all RESOLVED. - ajax ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] GLX extension for vendor name lookup in libglvnd
All right, here's an updated draft of the Issues section. How does it look? Issues 1) Should GLX_VENDOR_NAMES_EXT contain a single vendor name or a list of names? UNRESOLVED: Allow 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? UNRESOLVED: 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 are not defined in this specification. 3) What order should the vendor names be returned in? UNRESOLVED: If there are multiple vendor names, then the client should use the names earlier in the list in preference to names later in the list. Specifically, 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. 4) Does the vendor name list need a new enum? Could it be appended to the GLX_VENDOR string instead? UNRESOLVED: Use a new enum. The vendor-specific part of the GLX_VENDOR string is by definition arbitrary, even if in practice every most if not all GLX implementatinos leave it blank. In addition, using a new enum also makes parsing the string much easier. The client can simply pass the unmodified string to strtok or strtok_r. 5) Do we need to define the interaction with GLX_SGIX_pbuffer? UNRESOLVED. No. Any client or server that implements this extension will already support GLX 1.3, so using glXQueryDrawable to look up a screen number is sufficient. There's no harm if a server includes a GLX_SCREEN attribute in its GetDrawableAttributesSGIX reply, so a server is still free to use the same codepath for GetDrawableAttributesSGIX and glXGetDrawableAttributes. 6) Do we want to add GLX_SCREEN to the list of fbconfig attributes as well? UNRESOLVED: No. Adding GLX_SCREEN to glXGetDrawableAttributes would be redundant, because a client can already find the screen number for a GLXFBConfig using glXGetVisualFromFBConfig and indirectly using glXGetFBConfigs. Revision History 1. 8 March 2016 - Initial draft. On 03/09/2016 12:53 PM, Kyle Brenneman wrote: On 03/09/2016 12:21 PM, Adam Jackson wrote: On Wed, 2016-03-09 at 11:15 -0700, 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. Argh, you beat me to it, I'd written almost exactly the same thing. I just an update to my serverstring branch on github implementing what I'd spec'd, details below... Ah, sorry about that. I should have mentioned that I was working on it. New Tokens Accepted by the parameter of glXQueryServerString: GLX_VENDOR_NAMES_EXT0x Perhaps easier than getting an enum allocated here, I'd appended this string to the end of the response for GLX_VERSION, in the form glvnd: where list is comma-separated, since that part of the string is already "vendor-specific info". That could work, although I would expect "vendor-specific info" to mean "random, arbitrary, and probably not machine-parsable". I'd be hesitant to try to impose a structure on something that's never had any structure before. Agreed with your rationale in the Issues section. I'd also had: 1) Do we need to define the interaction with GLX_SGIX_pbuffer? UNRESOLVED. Xorg uses the same code paths for the 1.3 and pbuffer versions of GetDrawableAttributes, but extra attributes are probably harmless. We probably don't need to -- as you say, extra attributes are likely harmless. I'd guess that any system that supports libglvnd is going to support at least GLX 1.3, so using glXQueryDra
Re: [Mesa-dev] GLX extension for vendor name lookup in libglvnd
On Thu, 2016-03-10 at 10:53 -0700, Kyle Brenneman wrote: > On 03/10/2016 10:47 AM, Martin Peres wrote: > > > > 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. Right. It's pretty straightforward (and I plan) to wire this logic through to xorg.conf, so the admin can control the list at server startup time. Historically it's been somewhat pointless to do so, since all the proprietary drivers have also replaced the server's GLX module, but this gives us a path towards not doing that anymore at least. I'd also considered using this mechanism as a starting path towards both implementing GLX+Xinerama at all for the open drivers, and eventually to do that with heterogeneous open/closed GLX on the server side. Those are both fairly long term prospects, but I imagine it'll be easier to do if we can opt into different client-side logic. - ajax ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] GLX extension for vendor name lookup in libglvnd
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 parameter of glXQueryServerString: GLX_VENDOR_NAMES_EXT0x 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 and the format of the strings is the same as for glXGetClientString. may also be GLX_VENDOR_NAMES_EXT." [Add the following paragraph to the end of the section] "If 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] " 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 is GLX_SCREEN, then 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 us
Re: [Mesa-dev] GLX extension for vendor name lookup in libglvnd
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 parameter of glXQueryServerString: GLX_VENDOR_NAMES_EXT0x 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 and the format of the strings is the same as for glXGetClientString. may also be GLX_VENDOR_NAMES_EXT." [Add the following paragraph to the end of the section] "If 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] " 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 is GLX_SCREEN, then 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? ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] GLX extension for vendor name lookup in libglvnd
On Thu, 2016-03-10 at 08:32 -0700, Kyle Brenneman wrote: > > That could work, although I would expect "vendor-specific info" to > > mean "random, arbitrary, and probably not machine-parsable". I'd be > > hesitant to try to impose a structure on something that's never had > > any structure before. As far as I'm aware, there are zero servers that supply anything more than the bare version number in this string. But a new token is certainly the more conservative approach. I'll switch my branch back to using that. > > > 2) Do we want to add GLX_SCREEN to the list of fbconfig attributes > > > as well? > > > > > > UNRESOLVED. glvnd does not need that information, but it would > > > be a natural orthogonality, and GLX_SGIX_fbconfig mentions it > > > though GLX 1.3 does not. > > Possibly, but that wouldn't change the protocol at all. The screen > > number is included in the glXGetFBConfigs request, so it wouldn't make > > sense to add it to the reply as well. It would be up to the client to > > keep track of it instead. > Oh, wait. Now that I think about it, GLX already provides a GLXFBConfig > to screen mapping in glXGetVisualFromFBConfig, and indirectly from > glXGetFBConfigs. > > So, unless someone feels strongly otherwise, I think it would make the > most sense to leave glXGetFBConfigAttrib as it is. Sounds fine to me. - ajax ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] GLX extension for vendor name lookup in libglvnd
On 03/09/2016 12:53 PM, Kyle Brenneman wrote: On 03/09/2016 12:21 PM, Adam Jackson wrote: On Wed, 2016-03-09 at 11:15 -0700, 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. Argh, you beat me to it, I'd written almost exactly the same thing. I just an update to my serverstring branch on github implementing what I'd spec'd, details below... Ah, sorry about that. I should have mentioned that I was working on it. New Tokens Accepted by the parameter of glXQueryServerString: GLX_VENDOR_NAMES_EXT0x Perhaps easier than getting an enum allocated here, I'd appended this string to the end of the response for GLX_VERSION, in the form glvnd: where list is comma-separated, since that part of the string is already "vendor-specific info". That could work, although I would expect "vendor-specific info" to mean "random, arbitrary, and probably not machine-parsable". I'd be hesitant to try to impose a structure on something that's never had any structure before. Agreed with your rationale in the Issues section. I'd also had: 1) Do we need to define the interaction with GLX_SGIX_pbuffer? UNRESOLVED. Xorg uses the same code paths for the 1.3 and pbuffer versions of GetDrawableAttributes, but extra attributes are probably harmless. We probably don't need to -- as you say, extra attributes are likely harmless. I'd guess that any system that supports libglvnd is going to support at least GLX 1.3, so using glXQueryDrawable to look up the screen number seems reasonable. 2) Do we want to add GLX_SCREEN to the list of fbconfig attributes as well? UNRESOLVED. glvnd does not need that information, but it would be a natural orthogonality, and GLX_SGIX_fbconfig mentions it though GLX 1.3 does not. Possibly, but that wouldn't change the protocol at all. The screen number is included in the glXGetFBConfigs request, so it wouldn't make sense to add it to the reply as well. It would be up to the client to keep track of it instead. Oh, wait. Now that I think about it, GLX already provides a GLXFBConfig to screen mapping in glXGetVisualFromFBConfig, and indirectly from glXGetFBConfigs. So, unless someone feels strongly otherwise, I think it would make the most sense to leave glXGetFBConfigAttrib as it is. - ajax ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] GLX extension for vendor name lookup in libglvnd
On 03/09/2016 12:21 PM, Adam Jackson wrote: On Wed, 2016-03-09 at 11:15 -0700, 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. Argh, you beat me to it, I'd written almost exactly the same thing. I just an update to my serverstring branch on github implementing what I'd spec'd, details below... Ah, sorry about that. I should have mentioned that I was working on it. New Tokens Accepted by the parameter of glXQueryServerString: GLX_VENDOR_NAMES_EXT0x Perhaps easier than getting an enum allocated here, I'd appended this string to the end of the response for GLX_VERSION, in the form glvnd: where list is comma-separated, since that part of the string is already "vendor-specific info". That could work, although I would expect "vendor-specific info" to mean "random, arbitrary, and probably not machine-parsable". I'd be hesitant to try to impose a structure on something that's never had any structure before. Agreed with your rationale in the Issues section. I'd also had: 1) Do we need to define the interaction with GLX_SGIX_pbuffer? UNRESOLVED. Xorg uses the same code paths for the 1.3 and pbuffer versions of GetDrawableAttributes, but extra attributes are probably harmless. We probably don't need to -- as you say, extra attributes are likely harmless. I'd guess that any system that supports libglvnd is going to support at least GLX 1.3, so using glXQueryDrawable to look up the screen number seems reasonable. 2) Do we want to add GLX_SCREEN to the list of fbconfig attributes as well? UNRESOLVED. glvnd does not need that information, but it would be a natural orthogonality, and GLX_SGIX_fbconfig mentions it though GLX 1.3 does not. Possibly, but that wouldn't change the protocol at all. The screen number is included in the glXGetFBConfigs request, so it wouldn't make sense to add it to the reply as well. It would be up to the client to keep track of it instead. - ajax ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] GLX extension for vendor name lookup in libglvnd
On Wed, 2016-03-09 at 11:15 -0700, 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. Argh, you beat me to it, I'd written almost exactly the same thing. I just an update to my serverstring branch on github implementing what I'd spec'd, details below... > New Tokens > > Accepted by the parameter of glXQueryServerString: > > GLX_VENDOR_NAMES_EXT0x Perhaps easier than getting an enum allocated here, I'd appended this string to the end of the response for GLX_VERSION, in the form glvnd: where list is comma-separated, since that part of the string is already "vendor-specific info". Agreed with your rationale in the Issues section. I'd also had: 1) Do we need to define the interaction with GLX_SGIX_pbuffer? UNRESOLVED. Xorg uses the same code paths for the 1.3 and pbuffer versions of GetDrawableAttributes, but extra attributes are probably harmless. 2) Do we want to add GLX_SCREEN to the list of fbconfig attributes as well? UNRESOLVED. glvnd does not need that information, but it would be a natural orthogonality, and GLX_SGIX_fbconfig mentions it though GLX 1.3 does not. - ajax ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] GLX extension for vendor name lookup in libglvnd
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 parameter of glXQueryServerString: GLX_VENDOR_NAMES_EXT0x 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 and the format of the strings is the same as for glXGetClientString. may also be GLX_VENDOR_NAMES_EXT." [Add the following paragraph to the end of the section] "If 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] " 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 is GLX_SCREEN, then 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. Revision History 1. 8 March 2016 - Initial draft. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
