[Mesa-dev] how "client glx extensions" and "GLX extensions" are determined (and how best to limit them)
axel.davy at ens.fr
Sun Jun 1 18:29:19 PDT 2014
On 01/06/2014 20:49, Jeremy Huddleston Sequoia wrote :
> I'm trying to take a stab at adding core profile support to XQuartz. As a first step, I'm trying to add GLX_ARB_create_context and GLX_ARB_create_context_profile.
> For now, I want to make sure that GLX_ARB_create_context and GLX_ARB_create_context_profile are only advertised as being available when in a testing mode (so as to not enable breakage by default while working on these changes). To this end, I'm the following to applegl_create_screen:
> Unfortunately, it seems that GLX_ARB_create_context and GLX_ARB_create_context_profile are always advertised on current mesa.
It looks like __glXCalculateUsableExtensions is always called with
"display_is_direct_capable = False" for GLX_USE_APPLEGL.
Thus the following applies:
" If the display is not capable of direct rendering, then the extension
* is enabled if and only if the client-side library and the server
* support it. "
This seems conformant to the spec:
Direct rendering is requested if <direct> is True, and indirect
rendering if <direct> is False. If <direct> is True, the
implementation may nonetheless create an indirect rendering context
if any of the following conditions hold:
* The implementation does not support direct rendering.
* <display> is not a local X server.
* Implementation-dependent limits on the number of direct
rendering contexts that can be supported simultaneously are
In other words: you server advertises the extension and direct rendering
is not supported. The extension must be advertised, and create an
indirect context in all cases.
Your glxinfo says that direct rendering is supported. I don't know
XQuartz, but perhaps __glXCalculateUsableExtensions should not get
called anymore with "display_is_direct_capable = False" for
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the mesa-dev