You can subscribe to this list here.
2000 |
Jan
|
Feb
|
Mar
(11) |
Apr
(46) |
May
(65) |
Jun
(85) |
Jul
(94) |
Aug
(99) |
Sep
(62) |
Oct
(58) |
Nov
(85) |
Dec
(39) |
---|---|---|---|---|---|---|---|---|---|---|---|---|
2001 |
Jan
(90) |
Feb
(29) |
Mar
(90) |
Apr
(96) |
May
(78) |
Jun
(58) |
Jul
(44) |
Aug
(65) |
Sep
(40) |
Oct
(38) |
Nov
(79) |
Dec
(63) |
2002 |
Jan
(53) |
Feb
(61) |
Mar
(43) |
Apr
(53) |
May
(35) |
Jun
(59) |
Jul
(18) |
Aug
(12) |
Sep
(28) |
Oct
(61) |
Nov
(54) |
Dec
(23) |
2003 |
Jan
(16) |
Feb
(42) |
Mar
(38) |
Apr
(35) |
May
(20) |
Jun
(9) |
Jul
(10) |
Aug
(30) |
Sep
(22) |
Oct
(32) |
Nov
(25) |
Dec
(21) |
2004 |
Jan
(39) |
Feb
(36) |
Mar
(59) |
Apr
(32) |
May
(21) |
Jun
(4) |
Jul
(8) |
Aug
(21) |
Sep
(11) |
Oct
(21) |
Nov
(22) |
Dec
(19) |
2005 |
Jan
(62) |
Feb
(24) |
Mar
(17) |
Apr
(16) |
May
(16) |
Jun
(17) |
Jul
(26) |
Aug
(14) |
Sep
(13) |
Oct
(8) |
Nov
(23) |
Dec
(20) |
2006 |
Jan
(41) |
Feb
(18) |
Mar
(21) |
Apr
(47) |
May
(13) |
Jun
(33) |
Jul
(32) |
Aug
(21) |
Sep
(27) |
Oct
(34) |
Nov
(19) |
Dec
(46) |
2007 |
Jan
(21) |
Feb
(26) |
Mar
(13) |
Apr
(22) |
May
(5) |
Jun
(19) |
Jul
(56) |
Aug
(43) |
Sep
(37) |
Oct
(31) |
Nov
(53) |
Dec
(22) |
2008 |
Jan
(74) |
Feb
(31) |
Mar
(15) |
Apr
(35) |
May
(23) |
Jun
(26) |
Jul
(17) |
Aug
(27) |
Sep
(35) |
Oct
(30) |
Nov
(29) |
Dec
(17) |
2009 |
Jan
(35) |
Feb
(39) |
Mar
(44) |
Apr
(28) |
May
(20) |
Jun
(28) |
Jul
(49) |
Aug
(53) |
Sep
(23) |
Oct
(13) |
Nov
(12) |
Dec
(11) |
2010 |
Jan
(45) |
Feb
(28) |
Mar
(41) |
Apr
(11) |
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
From: Nathan K. <nat...@sp...> - 2010-03-01 15:39:54
|
On 10-02-28 07:23 PM, David Doria wrote: > svgadump/svga_shader_dump.c:654:1: internal compiler error: Segmentation fault > > Please submit a full bug report, with preprocessed source if appropriate. > See <http://gcc.gnu.org/bugs.html> for instructions. Your gcc is buggy. You need to update it, and if even the latest trunk source still reproduces the bug then it should be reported to the link the error message says. > Has anyone else had this problem? Likely only if they had the exact same version of gcc as you and possibly the exact same platform and version of the mesa source. But regardless of whether others saw the problem, the right place for you to look is http://gcc.gnu.org/bugs.html Cheers, -Nathan |
From: David D. <dav...@gm...> - 2010-03-01 01:29:59
|
I downloaded osmesa 7.7 from mesa3d.org. Then I ran make linux-x86 It built for a while, then it stopped with: make[5]: Entering directory `/home/doriad/src/Mesa-7.7/src/gallium/drivers/svga' gcc -c -I. -I../../../../src/gallium/include -I../../../../src/gallium/auxiliary -I../../../../src/gallium/drivers -I/src/gallium/include -I/src/gallium/auxiliary -I/src/gallium/drivers -I../../../../src/gallium/drivers/svga/include -Wall -Wmissing-prototypes -Wdeclaration-after-statement -Wpointer-arith -O3 -g -fPIC -m32 -mmmx -msse -msse2 -D_POSIX_SOURCE -D_POSIX_C_SOURCE=199309L -D_SVID_SOURCE -D_BSD_SOURCE -D_GNU_SOURCE -DPTHREADS -DUSE_XSHM -DHAVE_POSIX_MEMALIGN -DUSE_X86_ASM -DUSE_MMX_ASM -DUSE_3DNOW_ASM -DUSE_SSE_ASM -I/usr/X11R6/include -std=c99 -ffast-math -fno-strict-aliasing -std=gnu99 -fvisibility=hidden -DHAVE_STDINT_H -DHAVE_SYS_TYPES_H svgadump/svga_shader_dump.c -o svgadump/svga_shader_dump.o svgadump/svga_shader_dump.c: In function ‘svga_shader_dump’: svgadump/svga_shader_dump.c:654:1: internal compiler error: Segmentation fault Please submit a full bug report, with preprocessed source if appropriate. See <http://gcc.gnu.org/bugs.html> for instructions. make[5]: *** [svgadump/svga_shader_dump.o] Error 1 make[5]: Leaving directory `/home/doriad/src/Mesa-7.7/src/gallium/drivers/svga' make[4]: *** [default] Error 1 make[4]: Leaving directory `/home/doriad/src/Mesa-7.7/src/gallium/drivers' make[3]: *** [default] Error 1 make[3]: Leaving directory `/home/doriad/src/Mesa-7.7/src/gallium' make[2]: *** [subdirs] Error 1 make[2]: Leaving directory `/home/doriad/src/Mesa-7.7/src' make[1]: *** [default] Error 1 make[1]: Leaving directory `/home/doriad/src/Mesa-7.7' make: *** [linux-x86] Error 2 Has anyone else had this problem? Thanks, David |
From: Jamie A. <jam...@gm...> - 2010-02-23 01:00:58
|
I've been trying to get an accelerated linux ubuntu guest working within an ubuntu accelerated host (nvidia accel working there).So far, in the guest, I've removed all the X11/mesa packages and downloaded the latest X11 and mesa git source code. I've got everything compiled and working but I don't seem to have any acceleration at least not for mesa, which is in software mode: Some important bits: glxinfo: glxinfo.txt OpenGL vendor string: Mesa Project OpenGL renderer string: Software Rasterizer OpenGL version string: 2.1 Mesa 7.8-devel OpenGL shading language version string: 1.20 OpenGL extensions: xorg.conf: Section "Device" ### Available Driver options are:- ### Values: <i>: integer, <f>: float, <bool>: "True"/"False", ### <string>: "String", <freq>: "<f> Hz/kHz/MHz" ### [arg]: arg optional #Option "ShadowFB" # [<bool>] #Option "DefaultRefresh" # [<bool>] #Option "ModeSetClearScreen" # [<bool>] Identifier "Card0" Driver "vesa" VendorName "VMware Inc" BoardName "Abstract SVGA II Adapter" BusID "PCI:0:15:0" EndSection Xorg.0.log: (II) Module kbd: vendor="X.Org Foundation" compiled for 1.7.4.902, module version = 1.4.0 Module class: X.Org XInput Driver ABI class: X.Org XInput driver, version 7.0 (II) VESA: driver for VESA chipsets: vesa (II) Primary Device is: PCI 00@00:0f:0 (WW) VGA arbiter: cannot open kernel arbiter, no multi-card support (II) Loading sub module "vbe" (II) LoadModule: "vbe" (II) Loading /usr/local/lib/xorg/modules/libvbe.so (II) Module vbe: vendor="X.Org Foundation" compiled for 1.7.4.902, module version = 1.1.0 ABI class: X.Org Video Driver, version 6.0 (II) Loading sub module "int10" (II) LoadModule: "int10" (II) Loading /usr/local/lib/xorg/modules/libint10.so (II) Module int10: vendor="X.Org Foundation" compiled for 1.7.4.902, module version = 1.0.0 ABI class: X.Org Video Driver, version 6.0 (II) VESA(0): initializing int10 (II) VESA(0): Primary V_BIOS segment is: 0xc000 (II) VESA(0): VESA BIOS detected (II) VESA(0): VESA VBE Version 2.0 (II) VESA(0): VESA VBE Total Mem: 131072 kB (II) VESA(0): VESA VBE OEM: V M ware, Inc. VBE support 2.0 (II) VESA(0): VESA VBE OEM Software Rev: 2.0 (II) VESA(0): VESA VBE OEM Vendor: VMware, Inc (II) VESA(0): VESA VBE OEM Product: VMware virtual machine (II) VESA(0): VESA VBE OEM Product Rev: 2.0 (==) VESA(0): Depth 24, (--) framebuffer bpp 32 (==) VESA(0): RGB weight 888 (==) VESA(0): Default visual is TrueColor (==) VESA(0): Using gamma correction (1.0, 1.0, 1.0) (II) Loading sub module "ddc" (II) LoadModule: "ddc" (II) Module "ddc" already built-in (II) VESA(0): VESA VBE DDC not supported (II) VESA(0): VESA VBE PanelID invalid (II) VESA(0): Searching for matching VESA mode(s): Has anyone else gotten this to work? Should it work? Jamie |
From: Nathan K. <nat...@sp...> - 2010-02-22 16:14:53
|
[just looking at this portion of your mail] On 10-02-21 06:29 AM, Reuti wrote: > *** Behavior of failing programs: > > Starting programs via SSH's X11 forwarding which use OpenGL I get > errors like: > > - glxgears: Error: couldn't get an RGB, Double-buffered visual. > > Even setting LIBGL_ALWAYS_INDIRECT or LIBGL_ALWAYS_SOFWARE doen't > change anything. 1. Keep in mind that newer Mesa libGLs will give the same error message as above if your GLX server doesn't support fbconfigs. 2. You have a typo above "LIBGL_ALWAYS_SOFWARE", did you use the correct (sofTware) variable in your terminal? -Nathan |
From: Reuti <re...@st...> - 2010-02-21 11:32:03
|
One thing I forgot: the /usr/X11R6/lib64 and /usr/X11R6/lib were empty on the server before. -- Reuti Am 21.02.2010 um 12:29 schrieb Reuti: > Hi all, > > I searched the archive for something related to the subject of this > post. But although I found other users also having this problem on > the Internet, there was nothing related in the archive here. Maybe > this is even the wrong list for this issue, then maybe someone can > please point me to the correct one for further investigation. > > > *** Setup: > > I have a powerful server running Linux with several cores (but > without any sophisticated graphics card, just a minimum **) ), to > which users connect from the offices. On their desks they use a > Linux, Mac OS X and Linux. > > > *** Behavior of failing programs: > > Starting programs via SSH's X11 forwarding which use OpenGL I get > errors like: > > - glxgears: Error: couldn't get an RGB, Double-buffered visual. > - glxinfo: Error: couldn't find RGB GLX visual > - others startup up display only a black screen w/o any content > > Even setting LIBGL_ALWAYS_INDIRECT or LIBGL_ALWAYS_SOFWARE doen't > change anything. > > > *** Behavior of working programs: > > Some applications like GaussView 4 from Gaussian or Maestro from > Schrodinger have a switch -soft, respecitvely -sgi, which enables > them to work in this configuration. Unfortunately not all software we > want to use have such an option. > > > *** Obersavtion between workstation: > > When I try to "emulate" the server by a workstation which has an > Nvidia card installed, and connect to this machine from another > workstation, all is working fine. I can see of course, that in this > case other libraries are used. On the server: > > $ ldd /usr/bin/glxgears > ... > libGL.so.1 => /usr/lib64/libGL.so.1 (0x00007f3f8273d000) > ... > libXxf86vm.so.1 => /usr/lib64/libXxf86vm.so.1 > (0x00007f3f8181d000) > libXdamage.so.1 => /usr/lib64/libXdamage.so.1 > (0x00007f3f8161a000) > libXfixes.so.3 => /usr/lib64/libXfixes.so.3 > (0x00007f3f81414000) > libdrm.so.2 => /usr/lib64/libdrm.so.2 (0x00007f3f8120b000) > ... > > But on an "emulated" server on a workstation: > > $ ldd /usr/bin/glxgears > ... > libGL.so.1 => /usr/X11R6/lib64/libGL.so.1 > (0x00007f952cf92000) > ... > libGLcore.so.1 => /usr/X11R6/lib64/libGLcore.so.1 > (0x00007f952b1d6000) > libnvidia-tls.so.1 => /usr/lib64/tls/libnvidia-tls.so.1 > (0x00007f952d286000) > libXext.so.6 => /usr/lib64/libXext.so.6 (0x00007f952afc4000) > .... > > > *** Solution. > > Now I found a hint on the Internet *), to copy the files from the > workstation from /usr/X11R6/lib and lib64 to the server machine. I > chose to copy them to /opt/nvidia not to mess up with the default > installation. When I now set LD_LIBRARY_PATH all applications are > running fine (one still listed the old libGL.so and I had to use > LD_PRELOAD for it). > > > *** Question: > > Why is this working? My assumption would be, that the original > libGL.so supplied by openSUSE 11.1 and openSUSE 11.2 (ubuntu karmic > in the link *) ) checks the local graphics card first, before it can > even decide to honor LIBGL_ALWAYS_INDIRECT/SOFTWARE at all. Hence an > error is given to the application and fails. When this behavior is > the same across three dristributions with different versions of > libGL.so (7.2 and 7.5), I would assume that this behavior is intended > - but why? Was is falling back to software rendering silently in > former versions of libGL.so? > > And why is the libGL.so installed with Nvidia working, although there > is no Nvidia card at all in the server? Or is the problem in the X11- > Client libraries, which run on the server? > > > -- Reuti > > *) http://forum.compiz.org/viewtopic.php?f=86&t=12271 > > **) It's a server from SUN with only the graphics card from the ILOM > (Integrated Lights Out Management for remote administration and KVM). > > ---------------------------------------------------------------------- > -------- > Download Intel® Parallel Studio Eval > Try the new software tools for yourself. Speed compiling, find bugs > proactively, and fine-tune applications for parallel performance. > See why Intel Parallel Studio got high marks during beta. > http://p.sf.net/sfu/intel-sw-dev > _______________________________________________ > Mesa3d-users mailing list > Mes...@li... > https://lists.sourceforge.net/lists/listinfo/mesa3d-users |
From: Reuti <re...@st...> - 2010-02-21 11:28:11
|
Hi all, I searched the archive for something related to the subject of this post. But although I found other users also having this problem on the Internet, there was nothing related in the archive here. Maybe this is even the wrong list for this issue, then maybe someone can please point me to the correct one for further investigation. *** Setup: I have a powerful server running Linux with several cores (but without any sophisticated graphics card, just a minimum **) ), to which users connect from the offices. On their desks they use a Linux, Mac OS X and Linux. *** Behavior of failing programs: Starting programs via SSH's X11 forwarding which use OpenGL I get errors like: - glxgears: Error: couldn't get an RGB, Double-buffered visual. - glxinfo: Error: couldn't find RGB GLX visual - others startup up display only a black screen w/o any content Even setting LIBGL_ALWAYS_INDIRECT or LIBGL_ALWAYS_SOFWARE doen't change anything. *** Behavior of working programs: Some applications like GaussView 4 from Gaussian or Maestro from Schrodinger have a switch -soft, respecitvely -sgi, which enables them to work in this configuration. Unfortunately not all software we want to use have such an option. *** Obersavtion between workstation: When I try to "emulate" the server by a workstation which has an Nvidia card installed, and connect to this machine from another workstation, all is working fine. I can see of course, that in this case other libraries are used. On the server: $ ldd /usr/bin/glxgears ... libGL.so.1 => /usr/lib64/libGL.so.1 (0x00007f3f8273d000) ... libXxf86vm.so.1 => /usr/lib64/libXxf86vm.so.1 (0x00007f3f8181d000) libXdamage.so.1 => /usr/lib64/libXdamage.so.1 (0x00007f3f8161a000) libXfixes.so.3 => /usr/lib64/libXfixes.so.3 (0x00007f3f81414000) libdrm.so.2 => /usr/lib64/libdrm.so.2 (0x00007f3f8120b000) ... But on an "emulated" server on a workstation: $ ldd /usr/bin/glxgears ... libGL.so.1 => /usr/X11R6/lib64/libGL.so.1 (0x00007f952cf92000) ... libGLcore.so.1 => /usr/X11R6/lib64/libGLcore.so.1 (0x00007f952b1d6000) libnvidia-tls.so.1 => /usr/lib64/tls/libnvidia-tls.so.1 (0x00007f952d286000) libXext.so.6 => /usr/lib64/libXext.so.6 (0x00007f952afc4000) .... *** Solution. Now I found a hint on the Internet *), to copy the files from the workstation from /usr/X11R6/lib and lib64 to the server machine. I chose to copy them to /opt/nvidia not to mess up with the default installation. When I now set LD_LIBRARY_PATH all applications are running fine (one still listed the old libGL.so and I had to use LD_PRELOAD for it). *** Question: Why is this working? My assumption would be, that the original libGL.so supplied by openSUSE 11.1 and openSUSE 11.2 (ubuntu karmic in the link *) ) checks the local graphics card first, before it can even decide to honor LIBGL_ALWAYS_INDIRECT/SOFTWARE at all. Hence an error is given to the application and fails. When this behavior is the same across three dristributions with different versions of libGL.so (7.2 and 7.5), I would assume that this behavior is intended - but why? Was is falling back to software rendering silently in former versions of libGL.so? And why is the libGL.so installed with Nvidia working, although there is no Nvidia card at all in the server? Or is the problem in the X11- Client libraries, which run on the server? -- Reuti *) http://forum.compiz.org/viewtopic.php?f=86&t=12271 **) It's a server from SUN with only the graphics card from the ILOM (Integrated Lights Out Management for remote administration and KVM). |
From: Adam K K. <ad...@vo...> - 2010-02-19 10:03:00
|
On 02/18/10 21:37, Daniel Hoggan wrote: > Would it be possible to put the radeonhd driver into the DRM package > that's part of the linux kernel. The reason I'm asking is in order to > use it without X. I'm only using DirectFB as the graphics renderer. radeonhd is a 2D only Xorg driver. There is no DRM component to it. The Mesa3D drivers for all radeon GPUs use the 'radeon' DRM driver, which is in the linux kernel. Adam |
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 |
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: 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: Pauli N. <su...@gm...> - 2010-02-17 16:55:29
|
Setting environment variable LIBGL_ALWAYS_SOFTWARE=1 when running the application tells mesa to load software rasterizer. On Wed, Feb 17, 2010 at 6:25 PM, 정준영 <rh...@hl...> wrote: > Hi, all Mesa users. > > I have heard that the Mesa is the software implementation of OpenGL. So it > acts as OpenGL emulation. > But I found that Mesa also supports DRI and applied DRI to the X Window > System I use. > > However while the X Window system uses DRI, > the version of OpenGL provided by Mesa is restricted to the version of > OpenGL which graphics hardware driver supports. > > glxinfo ouput when DRI is used. > direct rendering: Yes > OpenGL vendor string: Tungsten Graphics, Inc > OpenGL renderer string: Mesa DRI Intel(R) 852GM/855GM 20061017 > x86/MMX/SSE2 > OpenGL version string: 1.3 Mesa 7.0.3 > > glxinfo output when DRI is not used. > direct rendering: No (If you want to find out why, try setting > LIBGL_DEBUG=verbose) > OpenGL vendor string: Mesa project: www.mesa3d.org > OpenGL renderer string: Mesa GLX Indirect > OpenGL version string: 1.4 (2.1 Mesa 7.0.2) > > (I attach the full outputs of both glxinfo executions) > > The OpenGL commands belonging to OpenGL 2.1 is not available when DRI is > used, but it is available when DRI is not used. > > > I wonder that it is possible to use OpenGL emulation in case of the OpenGL > command is beyond the OpenGL version supported by graphics hardware driver. > Whilst the OpenGL commands provided by graphics hardware driver are > processed by DRI. > > Thank you. > > > ------------------------------------------------------------------------------ > 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: 정준영 <rh...@hl...> - 2010-02-17 16:25:26
|
Hi, all Mesa users. I have heard that the Mesa is the software implementation of OpenGL. So it acts as OpenGL emulation. But I found that Mesa also supports DRI and applied DRI to the X Window System I use. However while the X Window system uses DRI, the version of OpenGL provided by Mesa is restricted to the version of OpenGL which graphics hardware driver supports. glxinfo ouput when DRI is used. direct rendering: Yes OpenGL vendor string: Tungsten Graphics, Inc OpenGL renderer string: Mesa DRI Intel(R) 852GM/855GM 20061017 x86/MMX/SSE2 OpenGL version string: 1.3 Mesa 7.0.3 glxinfo output when DRI is not used. direct rendering: No (If you want to find out why, try setting LIBGL_DEBUG=verbose) OpenGL vendor string: Mesa project: www.mesa3d.org OpenGL renderer string: Mesa GLX Indirect OpenGL version string: 1.4 (2.1 Mesa 7.0.2) (I attach the full outputs of both glxinfo executions) The OpenGL commands belonging to OpenGL 2.1 is not available when DRI is used, but it is available when DRI is not used. I wonder that it is possible to use OpenGL emulation in case of the OpenGL command is beyond the OpenGL version supported by graphics hardware driver. Whilst the OpenGL commands provided by graphics hardware driver are processed by DRI. Thank you. |
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 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 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: Jamie A. <jam...@gm...> - 2010-02-16 22:05:37
|
I have created a simple es2 pbuffer example starting from the es1 examples "two_win, render_tex", and the es2 example "tri". Let me know if you would like it. Jamie On Wed, Feb 10, 2010 at 10:36 AM, Jamie Amendolagine < jam...@gm...> wrote: > > > On Wed, Feb 10, 2010 at 10:12 AM, Chia-I Wu <ol...@gm...> wrote: > >> On Thu, Feb 11, 2010 at 1:57 AM, Jamie Amendolagine >> <jam...@gm...> wrote: >> > I am porting an egl/opengl-es2 application to mesa (opengl-es branch -- >> > software rasterizer for now) from the powervr egl/opengl-es2 wrappers on >> a >> > desktop linux. I've just started, and see that my pbuffer code is >> blowing up >> > right here (on the exit): >> > EGLint pbufferConfigAttribs[] = { >> > EGL_CONFIG_CAVEAT, EGL_NONE, >> > EGL_BUFFER_SIZE, bufferSize, >> > EGL_SURFACE_TYPE, EGL_PBUFFER_BIT, >> > EGL_BIND_TO_TEXTURE_RGB, EGL_TRUE, >> > EGL_NONE >> > }; >> > >> > int iConfigs; >> > if (!eglChooseConfig(EGLX11System::eglDisplay, >> > pbufferConfigAttribs, >> > &EGLX11System::eglPbufferConfig, >> > 1, &iConfigs) ){ >> > TestEGLError("eglChooseConfig"); >> > printf("Error: eglChooseConfig() failed. line:%i\n", __LINE__); >> > exit(1); // exits here >> > } >> > Does anyone know if pbuffers are currently working in mesa? >> First of all, opengl-es branch (actually, opengl-es-v2) has been merged to >> > > Ah, yes, I see, actually I am on the master, and do have egl building. I > now see progs/es1/xegl/pbuffer.c. It runs, but I'm not sure if it's working > correctly yet. I'll verify it and make an es2 version to test there. > > > >> master. There have also been many changes to EGL and its drivers. You >> might >> want to try the master branch to see if it works. There is a guide at >> docs/egl.html on how to configure/build EGL. >> >> As for your problem, it is likely that no config has pbuffer bit or >> bind_to_texture_rgb set. You might either define DEBUG (on master branch) >> or >> set a break point at _eglChooseConfig to find out why. >> >> > Thanks I'll try that. > > So based on the above example, it seems that pbuffers should be working > then, at least with some configurations? > > Jamie > > >> -- >> ol...@Lu... >> > > |
From: Brian P. <br...@vm...> - 2010-02-15 15:56:01
|
Bo Jiang wrote: > Dear all, > I tried the sample program "mvarray.c" of OpenGL Programming Guide > (red-book) with Mesa3D 7.6.1 but the result showed only the last line > stripe regardless of how many line stripes to draw. (I copy Mesa's > OPENGL32.DLL to my binary program directory to use Mesa instead of > hardware driver) > The result of my hardware driver is right. I found the mvarray.c program and verified the issue. I'm committing a fix. It'll be in the next Mesa release. I'm attaching the patch in case you want to apply it locally. -Brian |
From: Bo J. <jb...@gm...> - 2010-02-14 06:58:45
|
Dear all, I tried the sample program "mvarray.c" of OpenGL Programming Guide (red-book) with Mesa3D 7.6.1 but the result showed only the last line stripe regardless of how many line stripes to draw. (I copy Mesa's OPENGL32.DLL to my binary program directory to use Mesa instead of hardware driver) The result of my hardware driver is right. Thank you, Bo Jiang |
From: Brian P. <br...@vm...> - 2010-02-11 14:31:16
|
Owen Kaluza wrote: > Hi, > > Is it possible to enable multi-sample anti-aliasing in osmesa? > There isn't an option in OSMesaCreateContextExt, in fact in the source > it appears the number of samples is hard coded to 1 in the call to > _mesa_create_visual but I just thought I'd ask in case there's a way > around it. > Of course I can render larger and downsample manually, but I'd rather not. There's no support for multisampling in Mesa's sw renderer. -Brian |
From: Owen K. <Owe...@sc...> - 2010-02-11 04:25:01
|
Hi, Is it possible to enable multi-sample anti-aliasing in osmesa? There isn't an option in OSMesaCreateContextExt, in fact in the source it appears the number of samples is hard coded to 1 in the call to _mesa_create_visual but I just thought I'd ask in case there's a way around it. Of course I can render larger and downsample manually, but I'd rather not. Cheers, Owen. |
From: Jamie A. <jam...@gm...> - 2010-02-10 18:36:20
|
On Wed, Feb 10, 2010 at 10:12 AM, Chia-I Wu <ol...@gm...> wrote: > On Thu, Feb 11, 2010 at 1:57 AM, Jamie Amendolagine > <jam...@gm...> wrote: > > I am porting an egl/opengl-es2 application to mesa (opengl-es branch -- > > software rasterizer for now) from the powervr egl/opengl-es2 wrappers on > a > > desktop linux. I've just started, and see that my pbuffer code is blowing > up > > right here (on the exit): > > EGLint pbufferConfigAttribs[] = { > > EGL_CONFIG_CAVEAT, EGL_NONE, > > EGL_BUFFER_SIZE, bufferSize, > > EGL_SURFACE_TYPE, EGL_PBUFFER_BIT, > > EGL_BIND_TO_TEXTURE_RGB, EGL_TRUE, > > EGL_NONE > > }; > > > > int iConfigs; > > if (!eglChooseConfig(EGLX11System::eglDisplay, > > pbufferConfigAttribs, > > &EGLX11System::eglPbufferConfig, > > 1, &iConfigs) ){ > > TestEGLError("eglChooseConfig"); > > printf("Error: eglChooseConfig() failed. line:%i\n", __LINE__); > > exit(1); // exits here > > } > > Does anyone know if pbuffers are currently working in mesa? > First of all, opengl-es branch (actually, opengl-es-v2) has been merged to > Ah, yes, I see, actually I am on the master, and do have egl building. I now see progs/es1/xegl/pbuffer.c. It runs, but I'm not sure if it's working correctly yet. I'll verify it and make an es2 version to test there. > master. There have also been many changes to EGL and its drivers. You > might > want to try the master branch to see if it works. There is a guide at > docs/egl.html on how to configure/build EGL. > > As for your problem, it is likely that no config has pbuffer bit or > bind_to_texture_rgb set. You might either define DEBUG (on master branch) > or > set a break point at _eglChooseConfig to find out why. > > Thanks I'll try that. So based on the above example, it seems that pbuffers should be working then, at least with some configurations? Jamie > -- > ol...@Lu... > |
From: Chia-I Wu <ol...@gm...> - 2010-02-10 18:13:03
|
On Thu, Feb 11, 2010 at 1:57 AM, Jamie Amendolagine <jam...@gm...> wrote: > I am porting an egl/opengl-es2 application to mesa (opengl-es branch -- > software rasterizer for now) from the powervr egl/opengl-es2 wrappers on a > desktop linux. I've just started, and see that my pbuffer code is blowing up > right here (on the exit): > EGLint pbufferConfigAttribs[] = { > EGL_CONFIG_CAVEAT, EGL_NONE, > EGL_BUFFER_SIZE, bufferSize, > EGL_SURFACE_TYPE, EGL_PBUFFER_BIT, > EGL_BIND_TO_TEXTURE_RGB, EGL_TRUE, > EGL_NONE > }; > > int iConfigs; > if (!eglChooseConfig(EGLX11System::eglDisplay, > pbufferConfigAttribs, > &EGLX11System::eglPbufferConfig, > 1, &iConfigs) ){ > TestEGLError("eglChooseConfig"); > printf("Error: eglChooseConfig() failed. line:%i\n", __LINE__); > exit(1); // exits here > } > Does anyone know if pbuffers are currently working in mesa? First of all, opengl-es branch (actually, opengl-es-v2) has been merged to master. There have also been many changes to EGL and its drivers. You might want to try the master branch to see if it works. There is a guide at docs/egl.html on how to configure/build EGL. As for your problem, it is likely that no config has pbuffer bit or bind_to_texture_rgb set. You might either define DEBUG (on master branch) or set a break point at _eglChooseConfig to find out why. -- ol...@Lu... |
From: Jamie A. <jam...@gm...> - 2010-02-10 17:57:14
|
Hello, I am porting an egl/opengl-es2 application to mesa (opengl-es branch -- software rasterizer for now) from the powervr egl/opengl-es2 wrappers on a desktop linux. I've just started, and see that my pbuffer code is blowing up right here (on the exit): EGLint pbufferConfigAttribs[] = { EGL_CONFIG_CAVEAT, EGL_NONE, EGL_BUFFER_SIZE, bufferSize, EGL_SURFACE_TYPE, EGL_PBUFFER_BIT, EGL_BIND_TO_TEXTURE_RGB, EGL_TRUE, EGL_NONE }; int iConfigs; if (!eglChooseConfig(EGLX11System::eglDisplay, pbufferConfigAttribs, &EGLX11System::eglPbufferConfig, 1, &iConfigs) ){ TestEGLError("eglChooseConfig"); printf("Error: eglChooseConfig() failed. line:%i\n", __LINE__); exit(1); // exits here } Does anyone know if pbuffers are currently working in mesa? Jamie |
From: Brian P. <br...@vm...> - 2010-02-09 18:13:47
|
Adam Richard wrote: > Hi, > > At this URL: > > http://www.mesa3d.org/osmesa.html > > it says there are examples of OSMesa "in the progs/osdemo/ directory". > I have version 7.6.1 of Mesa, and there is no osdemo directory in the > progs directory. Where can I find examples of how to use the OSMesa API? It progs/osdemos/ and it's in the MesaDemos-7.6.1.tar.gz tarball. I'll fix the typo in the Mesa docs. -Brian |