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 mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
