From: Alex F. <ale...@gm...> - 2010-02-17 12:50:50
|
Hi there, My program is happily linking to the nvidia OpenGL implementation for its normal onscreen rendering. I would like within a small part of this program to use the offscreen rendering capabilities of OSMesa. If I link to both /usr/lib/libGL.so and /usr/lib/libOSMesa.so then I get strange results: either my offscreen-rendered images are blank or GL crashes, depending on which order I do the linking. My first question is: is this even supposed to work? If so I will investigate further and post much more detailed info about what's going wrong. If not, is there any other way that I can get both 3D acceleration for onscreen rendering and (un-accelerated) offscreen rendering working in the same binary? Thanks in advance, Alex |
From: Viral P. <Vir...@an...> - 2010-02-17 14:25:01
|
Hi Alex, You can link in both Mesa and Non-Mesa gl implementations, the key is to use mesa in mangled mode, such that, when calling into mesa all gl calls are: mgl* but calling into non-mesa the calls are, gl* This either means you need to write all your code twice or preferably use function pointers/virtual interfaces to reference each implementation. You will also need to be careful to use mgl calls only when using with an OSMesa gl context. What you are currently doing is linking in 2 different libraries with the conflicting symbols, simplistically the linker is using some functions from mesa and some from nvogl. I would look at the mangled_* headers in mesa, and the mesa doc has a section on mangling the api entry points. Hope this helps. Viral Patel Ansys Inc, -----Original Message----- From: Alex Flint [mailto:ale...@gm...] Sent: 17 February 2010 12:27 To: mes...@li... Subject: [Mesa3d-users] using osmesa together with nvidia GL implementation Hi there, My program is happily linking to the nvidia OpenGL implementation for its normal onscreen rendering. I would like within a small part of this program to use the offscreen rendering capabilities of OSMesa. If I link to both /usr/lib/libGL.so and /usr/lib/libOSMesa.so then I get strange results: either my offscreen-rendered images are blank or GL crashes, depending on which order I do the linking. My first question is: is this even supposed to work? If so I will investigate further and post much more detailed info about what's going wrong. If not, is there any other way that I can get both 3D acceleration for onscreen rendering and (un-accelerated) offscreen rendering working in the same binary? Thanks in advance, Alex ------------------------------------------------------------------------ ------ SOLARIS 10 is the OS for Data Centers - provides features such as DTrace, Predictive Self Healing and Award Winning ZFS. Get Solaris 10 NOW http://p.sf.net/sfu/solaris-dev2dev _______________________________________________ Mesa3d-users mailing list Mes...@li... https://lists.sourceforge.net/lists/listinfo/mesa3d-users |
From: Alex F. <ale...@gm...> - 2010-02-17 15:54:18
|
Thanks for your help Viral. I am now having difficulty compiling with USE_MGL_NAMESPACE $ env CFLAGS=-DUSE_MGL_NAMESPACE ./configure $ make ... glxcmds.c:1577: error: ‘glXGetCurrentDisplayEXT’ aliased to undefined symbol ‘glXGetCurrentDisplay’ glxcmds.c:1728: error: ‘glXQueryContextInfoEXT’ aliased to undefined symbol ‘glXQueryContext’ glxcmds.c:2174: error: ‘glXGetFBConfigAttribSGIX’ aliased to undefined symbol ‘glXGetFBConfigAttrib’ glxcmds.c:2178: error: ‘glXChooseFBConfigSGIX’ aliased to undefined symbol ‘glXChooseFBConfig’ glxcmds.c:2183: error: ‘glXGetVisualFromFBConfigSGIX’ aliased to undefined symbol ‘glXGetVisualFromFBConfig’ glxcmds.c:3087: error: ‘mglXGetProcAddress’ aliased to undefined symbol ‘glXGetProcAddressARB’ The docs say that I should add "CFLAGS += -DUSE_MGL_NAMESPACE" to the relevant config. It seems that configure has added this to configs/autoconf: $ grep USE_MGL_NAMESPACE configs/* configs/autoconf:CFLAGS = -DUSE_MGL_NAMESPACE -Wall -Wmissing-prototypes -std=c99 -ffast-math -fno-strict-aliasing \ configs/current:CFLAGS = -DUSE_MGL_NAMESPACE -Wall -Wmissing-prototypes -std=c99 -ffast-math -fno-strict-aliasing \ Is this sufficient or should I add it manually to other configs? Thanks again in advance, Alex On Wed, Feb 17, 2010 at 1:24 PM, Viral Patel <Vir...@an...> wrote: > Hi Alex, > > You can link in both Mesa and Non-Mesa gl implementations, the key is to > use > mesa in mangled mode, such that, when calling into mesa all gl calls > are: > > mgl* > > but calling into non-mesa the calls are, > > gl* > > This either means you need to write all your code twice or preferably > use function > pointers/virtual interfaces to reference each implementation. > > You will also need to be careful to use mgl calls only when using with > an OSMesa gl > context. > > What you are currently doing is linking in 2 different libraries with > the conflicting > symbols, simplistically the linker is using some functions from mesa and > some from > nvogl. > > I would look at the mangled_* headers in mesa, and the mesa doc has a > section on > mangling the api entry points. > > Hope this helps. > > Viral Patel > > Ansys Inc, > > > -----Original Message----- > From: Alex Flint [mailto:ale...@gm...] > Sent: 17 February 2010 12:27 > To: mes...@li... > Subject: [Mesa3d-users] using osmesa together with nvidia GL > implementation > > Hi there, > > My program is happily linking to the nvidia OpenGL implementation for > its normal onscreen rendering. I would like within a small part of > this program to use the offscreen rendering capabilities of OSMesa. If > I link to both /usr/lib/libGL.so and /usr/lib/libOSMesa.so then I get > strange results: either my offscreen-rendered images are blank or GL > crashes, depending on which order I do the linking. > > My first question is: is this even supposed to work? If so I will > investigate further and post much more detailed info about what's > going wrong. > > If not, is there any other way that I can get both 3D acceleration for > onscreen rendering and (un-accelerated) offscreen rendering working in > the same binary? > > Thanks in advance, > Alex > > ------------------------------------------------------------------------ > ------ > SOLARIS 10 is the OS for Data Centers - provides features such as > DTrace, > Predictive Self Healing and Award Winning ZFS. Get Solaris 10 NOW > http://p.sf.net/sfu/solaris-dev2dev > _______________________________________________ > Mesa3d-users mailing list > Mes...@li... > https://lists.sourceforge.net/lists/listinfo/mesa3d-users > |
From: Viral P. <Vir...@an...> - 2010-02-17 17:13:52
|
It was a while ago that I built Mesa for this purpose, here are some hints based on my notes and what I recall, there are several ways to skin a cat so you may be able to do the same in other ways. This is what I did to build things: .................... make distclean Edit configs/autoconf.in change "GL_LIB = GL" to "GL_LIB = MyMesaGL" change "GLU_LIB = GLU" to "GLU_LIB = MyMesaGLU" change "GLUT_LIB = GLUT" to "GLUT_LIB = MyMesaGLUT" change "OSMESA_LIB = @OSMESA_LIB@" to "OSMESA_LIB = My@OSMESA_LIB@" Add "CFLAGS += -DUSE_MGL_NAMESPACE" under the existing CFLAGS def. Add "CXXFLAGS += -DUSE_MGL_NAMESPACE" under the existing CXXFLAGS def. ./configure --prefix=<SOME DIRECTORY> --disable-driglx-direct --enable-gl-osmesa=yes --disable-glw --with-driver=xlib --with-osmesa-bits=32 gmake .................... This will give you a set of libraries such that MyMesaGLU will be linked against MyMesaGL and the same for GLUT. Typically Mesa didn't seem particularly setup to be used as an alternate linkable gl implementation and the default configurations are meant to build a replacements for the system gl implementation. So you may need to go through the headers and check that all symbols are being mangled. Good luck. Viral -----Original Message----- From: Alex Flint [mailto:ale...@gm...] Sent: 17 February 2010 15:54 To: Viral Patel Cc: mes...@li... Subject: Re: [Mesa3d-users] using osmesa together with nvidia GL implementation Thanks for your help Viral. I am now having difficulty compiling with USE_MGL_NAMESPACE $ env CFLAGS=-DUSE_MGL_NAMESPACE ./configure $ make ... glxcmds.c:1577: error: 'glXGetCurrentDisplayEXT' aliased to undefined symbol 'glXGetCurrentDisplay' glxcmds.c:1728: error: 'glXQueryContextInfoEXT' aliased to undefined symbol 'glXQueryContext' glxcmds.c:2174: error: 'glXGetFBConfigAttribSGIX' aliased to undefined symbol 'glXGetFBConfigAttrib' glxcmds.c:2178: error: 'glXChooseFBConfigSGIX' aliased to undefined symbol 'glXChooseFBConfig' glxcmds.c:2183: error: 'glXGetVisualFromFBConfigSGIX' aliased to undefined symbol 'glXGetVisualFromFBConfig' glxcmds.c:3087: error: 'mglXGetProcAddress' aliased to undefined symbol 'glXGetProcAddressARB' The docs say that I should add "CFLAGS += -DUSE_MGL_NAMESPACE" to the relevant config. It seems that configure has added this to configs/autoconf: $ grep USE_MGL_NAMESPACE configs/* configs/autoconf:CFLAGS = -DUSE_MGL_NAMESPACE -Wall -Wmissing-prototypes -std=c99 -ffast-math -fno-strict-aliasing \ configs/current:CFLAGS = -DUSE_MGL_NAMESPACE -Wall -Wmissing-prototypes -std=c99 -ffast-math -fno-strict-aliasing \ Is this sufficient or should I add it manually to other configs? Thanks again in advance, Alex On Wed, Feb 17, 2010 at 1:24 PM, Viral Patel <Vir...@an...> wrote: > Hi Alex, > > You can link in both Mesa and Non-Mesa gl implementations, the key is to > use > mesa in mangled mode, such that, when calling into mesa all gl calls > are: > > mgl* > > but calling into non-mesa the calls are, > > gl* > > This either means you need to write all your code twice or preferably > use function > pointers/virtual interfaces to reference each implementation. > > You will also need to be careful to use mgl calls only when using with > an OSMesa gl > context. > > What you are currently doing is linking in 2 different libraries with > the conflicting > symbols, simplistically the linker is using some functions from mesa and > some from > nvogl. > > I would look at the mangled_* headers in mesa, and the mesa doc has a > section on > mangling the api entry points. > > Hope this helps. > > Viral Patel > > Ansys Inc, > > > -----Original Message----- > From: Alex Flint [mailto:ale...@gm...] > Sent: 17 February 2010 12:27 > To: mes...@li... > Subject: [Mesa3d-users] using osmesa together with nvidia GL > implementation > > Hi there, > > My program is happily linking to the nvidia OpenGL implementation for > its normal onscreen rendering. I would like within a small part of > this program to use the offscreen rendering capabilities of OSMesa. If > I link to both /usr/lib/libGL.so and /usr/lib/libOSMesa.so then I get > strange results: either my offscreen-rendered images are blank or GL > crashes, depending on which order I do the linking. > > My first question is: is this even supposed to work? If so I will > investigate further and post much more detailed info about what's > going wrong. > > If not, is there any other way that I can get both 3D acceleration for > onscreen rendering and (un-accelerated) offscreen rendering working in > the same binary? > > Thanks in advance, > Alex > > ------------------------------------------------------------------------ > ------ > SOLARIS 10 is the OS for Data Centers - provides features such as > DTrace, > Predictive Self Healing and Award Winning ZFS. Get Solaris 10 NOW > http://p.sf.net/sfu/solaris-dev2dev > _______________________________________________ > Mesa3d-users mailing list > Mes...@li... > https://lists.sourceforge.net/lists/listinfo/mesa3d-users > |
From: Alex F. <ale...@gm...> - 2010-02-17 17:02:41
|
Thanks Viral, I will look into this and I'm sure your comments will be most helpful. Very much appreciate your time. Cheers, Alex On Wed, Feb 17, 2010 at 4:47 PM, Viral Patel <Vir...@an...> wrote: > It was a while ago that I built Mesa for this purpose, here are some > hints based > on my notes and what I recall, there are several ways to skin a cat so > you may be > able to do the same in other ways. > > This is what I did to build things: > > .................... > make distclean > > Edit configs/autoconf.in > change "GL_LIB = GL" to "GL_LIB = MyMesaGL" > change "GLU_LIB = GLU" to "GLU_LIB = MyMesaGLU" > change "GLUT_LIB = GLUT" to "GLUT_LIB = MyMesaGLUT" > change "OSMESA_LIB = @OSMESA_LIB@" to "OSMESA_LIB = My@OSMESA_LIB@" > Add "CFLAGS += -DUSE_MGL_NAMESPACE" under the existing CFLAGS def. > Add "CXXFLAGS += -DUSE_MGL_NAMESPACE" under the existing CXXFLAGS > def. > > ./configure --prefix=<SOME DIRECTORY> --disable-driglx-direct > --enable-gl-osmesa=yes --disable-glw --with-driver=xlib > --with-osmesa-bits=32 > gmake > .................... > > This will give you a set of libraries such that MyMesaGLU will be linked > > against MyMesaGL and the same for GLUT. > > Typically Mesa didn't seem particularly setup to be used as an alternate > > linkable gl implementation and the default configurations are meant to > build > a replacements for the system gl implementation. So you may need to go > through the headers and check that all symbols are being mangled. > > Good luck. > > Viral > > -----Original Message----- > From: Alex Flint [mailto:ale...@gm...] > Sent: 17 February 2010 15:54 > To: Viral Patel > Cc: mes...@li... > Subject: Re: [Mesa3d-users] using osmesa together with nvidia GL > implementation > > Thanks for your help Viral. > > I am now having difficulty compiling with USE_MGL_NAMESPACE > > $ env CFLAGS=-DUSE_MGL_NAMESPACE ./configure > $ make > ... > glxcmds.c:1577: error: 'glXGetCurrentDisplayEXT' aliased to undefined > symbol 'glXGetCurrentDisplay' > glxcmds.c:1728: error: 'glXQueryContextInfoEXT' aliased to undefined > symbol 'glXQueryContext' > glxcmds.c:2174: error: 'glXGetFBConfigAttribSGIX' aliased to undefined > symbol 'glXGetFBConfigAttrib' > glxcmds.c:2178: error: 'glXChooseFBConfigSGIX' aliased to undefined > symbol 'glXChooseFBConfig' > glxcmds.c:2183: error: 'glXGetVisualFromFBConfigSGIX' aliased to > undefined symbol 'glXGetVisualFromFBConfig' > glxcmds.c:3087: error: 'mglXGetProcAddress' aliased to undefined > symbol 'glXGetProcAddressARB' > > The docs say that I should add "CFLAGS += -DUSE_MGL_NAMESPACE" to the > relevant config. It seems that configure has added this to > configs/autoconf: > $ grep USE_MGL_NAMESPACE configs/* > configs/autoconf:CFLAGS = -DUSE_MGL_NAMESPACE -Wall > -Wmissing-prototypes -std=c99 -ffast-math -fno-strict-aliasing \ > configs/current:CFLAGS = -DUSE_MGL_NAMESPACE -Wall > -Wmissing-prototypes -std=c99 -ffast-math -fno-strict-aliasing \ > > Is this sufficient or should I add it manually to other configs? > > Thanks again in advance, > Alex > > > On Wed, Feb 17, 2010 at 1:24 PM, Viral Patel <Vir...@an...> > wrote: >> Hi Alex, >> >> You can link in both Mesa and Non-Mesa gl implementations, the key is > to >> use >> mesa in mangled mode, such that, when calling into mesa all gl calls >> are: >> >> mgl* >> >> but calling into non-mesa the calls are, >> >> gl* >> >> This either means you need to write all your code twice or preferably >> use function >> pointers/virtual interfaces to reference each implementation. >> >> You will also need to be careful to use mgl calls only when using with >> an OSMesa gl >> context. >> >> What you are currently doing is linking in 2 different libraries with >> the conflicting >> symbols, simplistically the linker is using some functions from mesa > and >> some from >> nvogl. >> >> I would look at the mangled_* headers in mesa, and the mesa doc has a >> section on >> mangling the api entry points. >> >> Hope this helps. >> >> Viral Patel >> >> Ansys Inc, >> >> >> -----Original Message----- >> From: Alex Flint [mailto:ale...@gm...] >> Sent: 17 February 2010 12:27 >> To: mes...@li... >> Subject: [Mesa3d-users] using osmesa together with nvidia GL >> implementation >> >> Hi there, >> >> My program is happily linking to the nvidia OpenGL implementation for >> its normal onscreen rendering. I would like within a small part of >> this program to use the offscreen rendering capabilities of OSMesa. If >> I link to both /usr/lib/libGL.so and /usr/lib/libOSMesa.so then I get >> strange results: either my offscreen-rendered images are blank or GL >> crashes, depending on which order I do the linking. >> >> My first question is: is this even supposed to work? If so I will >> investigate further and post much more detailed info about what's >> going wrong. >> >> If not, is there any other way that I can get both 3D acceleration for >> onscreen rendering and (un-accelerated) offscreen rendering working in >> the same binary? >> >> Thanks in advance, >> Alex >> >> > ------------------------------------------------------------------------ >> ------ >> SOLARIS 10 is the OS for Data Centers - provides features such as >> DTrace, >> Predictive Self Healing and Award Winning ZFS. Get Solaris 10 NOW >> http://p.sf.net/sfu/solaris-dev2dev >> _______________________________________________ >> Mesa3d-users mailing list >> Mes...@li... >> https://lists.sourceforge.net/lists/listinfo/mesa3d-users >> > |
From: tom f. <tf...@al...> - 2010-02-17 21:02:01
|
"Viral Patel" <Vir...@an...> writes: > You can link in both Mesa and Non-Mesa gl implementations, the key is > to use mesa in mangled mode, such that, when calling into mesa all gl > calls are: > > mgl* > > but calling into non-mesa the calls are, > > gl* > > This either means you need to write all your code twice or preferably > use function pointers/virtual interfaces to reference each > implementation. A better way to do this (transparently) is to just use GLEW, my GLEW in particular: git://shigeru.sci.utah.edu/glew.git make sure to use the 'sci' branch. You want to use GLEW (or something similar) anyway, because otherwise extension management is a custom-hacked nightmare. The only caveat as compared to regular GLEW is that you must call glewInitLibrary() before calling any glX or OSMesa functions (i.e. including ones to set up your context). When you want to switch which library is in use, just call glewInitLibrary again. Don't do so in an inner loop. At some point I will get not-lazy and most of that work should make it upstream. You'll also need a recent version of Mesa -- git on Windows, 7.4 IIRC on Mac, and 7.3 IIRC on Linux or AIX (assuming 7.3 builds on AIX). I don't test with other systems. One very nice thing about this setup is that you don't need to link your app with any OpenGL implementation. This is particular nice when you're using nvidia's OpenGL (as you say you are), because it is incredibly difficult to run through valgrind -- it triggers errors of its own, as almost all libs do, but it also messes up client code. HTH, -tom |
From: tom f. <tf...@al...> - 2010-02-17 21:04:59
|
"Viral Patel" <Vir...@an...> writes: > Typically Mesa didn't seem particularly setup to be used > as an alternate linkable gl implementation and the default > configurations are meant to build a replacements for the system gl > implementation. So you may need to go through the headers and check > that all symbols are being mangled. (Mangled) Mesa works fine in this configuration; I test it regularly (though, currently, I admit it has been a few weeks). If you are finding symbols which aren't mangled and should be, you probably just need to regenerate include/GL/gl_mangle.h. Run it like a shell script to do so. Patches to update mangling are accepted quite rapidly. -tom |