[Mesa-dev] Understanding GLX_INDIRECT_RENDERING (libOSMesa fails to link due to gl_dispatch_stub*)

Jeremy Huddleston jeremyhu at apple.com
Tue Jun 7 23:16:09 PDT 2011


Hi Chia,

Thanks for your help untangling the web.

--Jeremy

On Jun 7, 2011, at 2:51 PM, Chia-I Wu wrote:

> On Wed, Jun 8, 2011 at 3:08 AM, Jeremy Huddleston <jeremyhu at apple.com> wrote:
>> 
>> On Jun 7, 2011, at 2:13 PM, Brian Paul wrote:
>> 
>>>> Ok, I see what is happening.  configs/darwin bitrotted and included the -lGL, but other configs have since removed that.  It looks like I should just remove -lGL from OSMESA_LIB_DEPS in addition to the other changes that I've already sent for osmesa.c
>>>> 
>>>> It looks like -lGL is still done in default, beos, and aix ... so someone might want to update those as well...
>>> 
>>> At one time, I had things set up so that one libGL.so contained both the GLX and OSMesa interfaces.  An app could create a context of each time and freely switch between them with glX/OSMesa-MakeCurrent().  A while back this got changed so the OSMesa stuff lives in its own libOSMesa.so library.
>>> 
>>> At first glance, I'd suggest just omitting all the OSMesa stuff on Darwin for now.
>> 
>> Ok, well after omitting -lGL from OSMESA_LIB_DEPS and including the stubs in osmesa.c (patch on mesa-dev for review), things seem to be working well.
>> 
>> Is that patch the correct fix?  Has libOSMesa been failing to build correctly on other architectures as well?  If not, how is it resolving those symbols (or do architectures usually build libOSMesa without GLX_INDIRECT_RENDERING)?
> The patch looks good to me.
>> I'm confused about how to interpret the matrix of GLX_INDIRECT_RENDERING and GLX_DIRECT_RENDERING:
> GLX_DIRECT_RENDERING: src/glx supports direct rendering
> GLX_INDIRECT_RENDERING: adapt libglapi for src/glx
> 
> src/glx always supports indirect rendering.  When
> GLX_INDIRECT_RENDERING is not defined, it either won't build or will
> use wrong opcodes for certain functions (glGenTexturesEXT and etc).
> Because GLX_INDIRECT_RENDERING adapts libglapi, you are not supposed
> to build other libraries that use libglapi when the macro is
> defined... unless changes similar the patch you posted are applied to
> them.
> 
>> -DGLX_INDIRECT_RENDERING -DGLX_DIRECT_RENDERING
>> 
>> ^^ libGL supports both direct and indirect rendering
> src/glx/ supports both direct and indirect rendering
>> -DGLX_INDIRECT_RENDERING -UGLX_DIRECT_RENDERING
>> ^^ libGL supports only indirect rendering (?)
> src/glx supports only indirect rendering
>> -UGLX_INDIRECT_RENDERING -DGLX_DIRECT_RENDERING
>> ^^ libGL supports only direct rendering (?)  ... This doesn't seem to be the case since the indirect-foo is always included in src/glx/*.[hc]
> src/glx won't build; if it does, it supports both direct and indirect
> rendering.  Indirect rendering will send wrong opcodes for certain
> functions.
>> -UGLX_INDIRECT_RENDERING -UGLX_DIRECT_RENDERING
>> ^^ not supported?
> src/glx won't build; if it does, it supports only indirect rendering,
> with the same issue above
> 
>> 
>> 
>> _______________________________________________
>> mesa-dev mailing list
>> mesa-dev at lists.freedesktop.org
>> http://lists.freedesktop.org/mailman/listinfo/mesa-dev
>> 
> 
> 
> 
> -- 
> olv at LunarG.com
> 



More information about the mesa-dev mailing list