Re: [Mesa-dev] [RFC] GLX_MESA_query_renderer
On 12 March 2013 17:46, Ian Romanick i...@freedesktop.org wrote: Right... the extension also adds an attribute that can only be used with glXCreateContextAttribsARB. Yeah, all I was saying is that it probably wouldn't be too hard to word things along the lines of If glXCreateContextAttribsARB() isn't available GLX_RENDERER_ID_MESA goes away, and only one renderer is available / visible.. Perhaps it's not worth it though. My thinking was that it will be very rare for multiple renderers to support the same GL versions and different extension strings... at least in a way that would cause apps to make different context creation decisions. I guess that makes sense in the very coarse I need at least GL3 way. Part of the thinking is that it would force regularity in how the version is advertised. Otherwise everyone will have a different kind of string, and the currently annoying situation of parsing implementation dependent strings continues. Maybe GLX_RENDERER_VERSION_MESA should also be allowed with glXQueryRendererStringMESA? Yeah, I think that makes sense. I also based this on ISV feedback. Some just wanted to know what the hardware was, and others wanted to know that and who made the driver. I was really trying to get away from just parse this random string for as much of the API as possible. It seems like this should only make things easier for apps... should. In theory you could add a GL vendor ID similar to the PCI vendor ID, but then you'd have to allocate those globally, which would probably be annoying. So, yeah. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [RFC] GLX_MESA_query_renderer
On 03/05/2013 06:58 AM, Henri Verbeet wrote: On 2 March 2013 00:14, Ian Romanick i...@freedesktop.org wrote: I added some comments, but I think the extension is pretty much fine for at least Wine's purposes. GLX_ARB_create_context and GLX_ARB_create_context_profile are required. It's probably not a big deal since just about everyone implements these, but I think most of the extension could be implemented without these. Right... the extension also adds an attribute that can only be used with glXCreateContextAttribsARB. 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. I think that makes sense in some cases (although the more common case may turn out to be setups like PRIME where you actually have two different hardware renderers and want to switch between them), but wouldn't you also want to look at the (GL) extension string before creating a context in such a case? I realize issue 9 resolves this as basically not worth the effort, but doesn't that then contradict the text above? (For Wine creating the GLX context is no big deal at this point since we already have that code anyway, but it seems like useful information for (new) applications that want to avoid that.) My thinking was that it will be very rare for multiple renderers to support the same GL versions and different extension strings... at least in a way that would cause apps to make different context creation decisions. Additions to the OpenGL / WGL Specifications None. This specification is written for GLX. I think we'd like a WGL spec for wined3d, since it's written on top of Wine's WGL implementation instead of directly on top of GLX. If needed we could also solve that with a Wine internal extension, but we'd like to avoid those where possible. Well... I don't do Windows. :) 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); This returned a Bool above. I don't see the glXQueryCurrent*() functions specified at all, but I assume that will be added before the final version of the spec. Yes... it seems I neglected to propagate those changes into the body of the spec. I'll fix that. GLX_RENDERER_VERSION_MESA 3 Major, minor, and patch level of the renderer implementation I guess the trade-of here is that it avoids having to parse version strings in the application, but on the other hand it leaves no room for things like the git sha1 or e.g. beta or rc that you sometimes see in version strings. That probably isn't a big deal for applications themselves, but it may be relevant when a version string is included in a bug report. Part of the thinking is that it would force regularity in how the version is advertised. Otherwise everyone will have a different kind of string, and the currently annoying situation of parsing implementation dependent strings continues. Maybe GLX_RENDERER_VERSION_MESA should also be allowed with glXQueryRendererStringMESA? 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. But the GL_VENDOR and GL_RENDERER formats are implementation defined, so I'm not sure that wording it like this really adds much over just saying the format for these are implementation defined. Fair. :) 1) How should the difference between on-card and GART memory be exposed? UNRESOLVED. Somewhat related, dxgi / d3d10 distinguishes between DedicatedVideoMemory and SharedSystemMemory (and DedicatedSystemMemory). I'm not sure how much we really care, but I figured I'd at least mention it. The feedback that I have received so far is that apps want to know how much memory they can use without falling off a performance cliff. As far as I can tell, that means on-card memory. I'm still soliciting feedback. :) If there is a use for advertising SharedSystemMemory, I'll gladly add it. 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
Re: [Mesa-dev] [RFC] GLX_MESA_query_renderer
On Saturday 02 March 2013, Ian Romanick wrote: 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 I wonder if it would make sense to also have a minimum version in case we ever see implementations that don't support 1.x and 2.x contexts. Or should that case be handled by COMPATIBILITY_PROFILE_VERSION queries returning 0.0.0? Fredrik ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [RFC] GLX_MESA_query_renderer
On 2 March 2013 00:14, Ian Romanick i...@freedesktop.org wrote: I added some comments, but I think the extension is pretty much fine for at least Wine's purposes. GLX_ARB_create_context and GLX_ARB_create_context_profile are required. It's probably not a big deal since just about everyone implements these, but I think most of the extension could be implemented without these. 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. I think that makes sense in some cases (although the more common case may turn out to be setups like PRIME where you actually have two different hardware renderers and want to switch between them), but wouldn't you also want to look at the (GL) extension string before creating a context in such a case? I realize issue 9 resolves this as basically not worth the effort, but doesn't that then contradict the text above? (For Wine creating the GLX context is no big deal at this point since we already have that code anyway, but it seems like useful information for (new) applications that want to avoid that.) Additions to the OpenGL / WGL Specifications None. This specification is written for GLX. I think we'd like a WGL spec for wined3d, since it's written on top of Wine's WGL implementation instead of directly on top of GLX. If needed we could also solve that with a Wine internal extension, but we'd like to avoid those where possible. 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); This returned a Bool above. I don't see the glXQueryCurrent*() functions specified at all, but I assume that will be added before the final version of the spec. GLX_RENDERER_VERSION_MESA 3 Major, minor, and patch level of the renderer implementation I guess the trade-of here is that it avoids having to parse version strings in the application, but on the other hand it leaves no room for things like the git sha1 or e.g. beta or rc that you sometimes see in version strings. That probably isn't a big deal for applications themselves, but it may be relevant when a version string is included in a bug report. 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. But the GL_VENDOR and GL_RENDERER formats are implementation defined, so I'm not sure that wording it like this really adds much over just saying the format for these are implementation defined. 1) How should the difference between on-card and GART memory be exposed? UNRESOLVED. Somewhat related, dxgi / d3d10 distinguishes between DedicatedVideoMemory and SharedSystemMemory (and DedicatedSystemMemory). I'm not sure how much we really care, but I figured I'd at least mention it. 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. For what it's worth, internally in wined3d we distinguish between the GL vendor and the hardware vendor. So you can have e.g. Mesa / AMD, fglrx / AMD or Apple / AMD for the same hardware. That's all derived from the VENDOR and RENDERER strings, so that approach is certainly possible, but on the other hand perhaps it also makes sense to explicitly make that distinction in the API itself. 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. Related to that, are e.g. GLX_RENDERER_VENDOR_ID_MESA, GLX_RENDERER_DEVICE_ID_MESA (integer versions for both) or GLX_RENDERER_VIDEO_MEMORY_MESA really meaningful for software renderers? ___ mesa-dev
Re: [Mesa-dev] [RFC] GLX_MESA_query_renderer
On 03/02/2013 07:00 AM, Christoph Bumiller wrote: On 02.03.2013 00:14, Ian Romanick 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 I'm mostly looking for input on the specification itself. Once this is good, I will also add EGL support. ... 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 ... 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. Why would the PCI ID of the device vendor change with the driver ? Hopefully the PCI ID wouldn't change, but the resolution of this issue only applies to the string version of the query. GLX renderer attributedescription ----- 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). ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [RFC] GLX_MESA_query_renderer
On 03/01/2013 09:30 PM, Nicholas Miell wrote: On 03/01/2013 03:14 PM, Ian Romanick wrote: New Procedures and Functions Bool glXQueryRendererIntegerMESA(Display *dpy, int screen, int renderer, int attribute, unsigned int *value); Bool glXQueryCurrentRendererIntegerMESA(int attribute, unsigned int *value); Should these have ARB_robustness-style buffer size parameters? Hmm... many queries don't have size parameters, even with ARB_robustness, because the amount of data returned is always knowable in advance. See issue #6 in that spec. In the (as yet unposted) piglit tests, I have a couple tests that make sure the queries don't return too much data. Adding a size parameter might make it more future proof, but I'm having trouble even imagining a query that would be appropriate for this extension and have a variable payload. Either way, I can add it as an issue. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [RFC] GLX_MESA_query_renderer
On 03/01/2013 05:05 PM, Paul Berry wrote: On 1 March 2013 15:14, Ian Romanick i...@freedesktop.org mailto:i...@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.roman...@intel.com mailto:ian.d.roman...@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 0x GLX_RENDERER_DEVICE_ID_MESA 0x GLX_RENDERER_VERSION_MESA0x GLX_RENDERER_ACCELERATED_MESA0x GLX_RENDERER_VIDEO_MEMORY_MESA 0x GLX_RENDERER_UNIFIED_MEMORY___ARCHITECTURE_MESA0x GLX_RENDERER_PREFERRED___PROFILE_MESA 0x GLX_RENDERER_OPENGL_CORE___PROFILE_VERSION_MESA0x GLX_RENDERER_OPENGL___COMPATIBILITY_PROFILE_VERSION___MESA 0x
[Mesa-dev] [RFC] GLX_MESA_query_renderer
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 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.roman...@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 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: GLX_RENDERER_VENDOR_ID_MESA 0x GLX_RENDERER_DEVICE_ID_MESA 0x GLX_RENDERER_VERSION_MESA0x GLX_RENDERER_ACCELERATED_MESA0x GLX_RENDERER_VIDEO_MEMORY_MESA 0x GLX_RENDERER_UNIFIED_MEMORY_ARCHITECTURE_MESA0x GLX_RENDERER_PREFERRED_PROFILE_MESA 0x GLX_RENDERER_OPENGL_CORE_PROFILE_VERSION_MESA0x GLX_RENDERER_OPENGL_COMPATIBILITY_PROFILE_VERSION_MESA0x GLX_RENDERER_OPENGL_ES_PROFILE_VERSION_MESA 0x GLX_RENDERER_OPENGL_ES2_PROFILE_VERSION_MESA 0x 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 0x 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
Re: [Mesa-dev] [RFC] GLX_MESA_query_renderer
On 1 March 2013 15:14, Ian Romanick i...@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-rendererhttp://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.roman...@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 0x GLX_RENDERER_DEVICE_ID_MESA 0x GLX_RENDERER_VERSION_MESA0x GLX_RENDERER_ACCELERATED_MESA0x GLX_RENDERER_VIDEO_MEMORY_MESA 0x GLX_RENDERER_UNIFIED_MEMORY_**ARCHITECTURE_MESA0x GLX_RENDERER_PREFERRED_**PROFILE_MESA 0x GLX_RENDERER_OPENGL_CORE_**PROFILE_VERSION_MESA0x GLX_RENDERER_OPENGL_**COMPATIBILITY_PROFILE_VERSION_**MESA 0x GLX_RENDERER_OPENGL_ES_**PROFILE_VERSION_MESA 0x GLX_RENDERER_OPENGL_ES2_**PROFILE_VERSION_MESA 0x 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 0x Additions to the OpenGL / WGL Specifications None. This specification is written for GLX.
Re: [Mesa-dev] [RFC] GLX_MESA_query_renderer
On 03/01/2013 03:14 PM, Ian Romanick wrote: New Procedures and Functions Bool glXQueryRendererIntegerMESA(Display *dpy, int screen, int renderer, int attribute, unsigned int *value); Bool glXQueryCurrentRendererIntegerMESA(int attribute, unsigned int *value); Should these have ARB_robustness-style buffer size parameters? ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
