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: virtualme <din...@gm...> - 2010-04-23 20:27:46
|
hello this was quite a while ago. hence reposting question. a. today what is being done to virtualize 3d graphics cards b. what are the problems c. any good hardware assist gpu virutalization solutions on the horizon? thanks. Alexey Eremenko wrote: > > hi all ! > > Probably all of you have heard about Virtualization/Emulation > software, such as VMware, Xen, VirtualPC, Qemu, KVM and others... For > those who don't know what it is: Virtualization is a way to run one > operating system on top of another. > > Probably all know that most Virtualizers support only 2D graphics for > their guest operating systems. It turned out to be very difficult to > do virtualization of 3D graphics, in particular because the people > that write virtualization software often don't understand 3D graphics. > > However, I wanted inform you, that a new Open-Source x86 Virtualizer > emerged recently, trying to provide for a 3D graphics OpenGL > virtualization. The product's name is: VirtualBox. > VirtualBox is developed by a commercial company, and has a good > support of both Windows and Linux, plus it has exception speed. I see > it as a competitor to VMware. > > While Windows and Linux are officially supported, no-one is preventing > you from adding some other OSes to "supported" list as well. (BSD and > Solaris) - that's the power of OSS. > > VirtualBox home page: > www.virtualbox.org > > Article about Using VirtualBox on openSUSE Linux. > http://forgeftp.novell.com/lfl/.html/virtualbox.html > > More info about 3D virtualization can be found on: > http://forums.virtualbox.org/viewtopic.php?t=16 > http://www.virtualbox.org/ticket/475 > > I know that Mesa3D guys know 3D graphics perfectly, and so I wanted > you to participate in discussions about 3D graphics virtualization. > After all, my hope is that one day, the Open-Source community will be > able to run 3D software on a Virtual Machine (VM). > > If you want, you're welcome to contribute to VirtualBox project as well. > > Use cases: > 1. Run Linux with compiz 3D desktop on Windows. > 2. Run Windows games on Linux. > 3. [you add here] > > So, are there any people interested in OSS 3D graphics virtualization ? > > -- > -Alexey Eremenko "Technologov" > > ------------------------------------------------------------------------- > This SF.net email is sponsored by DB2 Express > Download DB2 Express C - the FREE version of DB2 express and take > control of your XML. No limits. Just data. Click to get it now. > http://sourceforge.net/powerbar/db2/ > _______________________________________________ > Mesa3d-users mailing list > Mes...@li... > https://lists.sourceforge.net/lists/listinfo/mesa3d-users > > -- View this message in context: http://old.nabble.com/3D-Graphics---and-Virtualization-tp11471769p28287952.html Sent from the mesa3d-users mailing list archive at Nabble.com. |
From: Saad M. <msa...@gm...> - 2010-04-21 08:08:26
|
Hello Everyone, Its my first time on the list so firstly, Hi to everyone :). Now my question is, I am required to develop an OpenGL application on Cell BE. I will be using QT for GUI purposes and my idea is to link it with Gallium driver to perform Graphics work. Now my question is can I compile mesa drivers as 64-bit? The linux-cell file in configs directory uses 32-bit flags, so I was wondering if is it some kind of restriction? or just a choice? Thanks Saad |
From: Brian P. <br...@vm...> - 2010-04-19 14:20:19
|
This list is now shut down. |
From: Brian P. <br...@vm...> - 2010-04-16 14:29:46
|
The new mesa-users list at fd.o is set up now. Everyone who was subscribed to the old list on SourceForge should now be subscribed to the new list. I'll shut down the old mesa3d-users list in a day or two. -Brian |
From: Brian P. <br...@vm...> - 2010-04-14 20:54:25
|
Joe Miller wrote: > Hi, > > I just downloaded Mesa 7.8.1 and built it on Solaris 10. After getting the libraries to compile, I attempted to verify the build using the demo apps. In particular I use the offscreen rendering mesa libraries provide. However, when I ran the ostest1 demo, the test program fails on to retrieve the correct size for the GL_RED_BITS. It seems to always be returning 8 even though the context was set to a large data type. > > In particular the lines of code that are failing include > > <snip> > /* Bind the buffer to the context and make it current */ > if (!OSMesaMakeCurrent( ctx, buffer, type, WIDTH, HEIGHT )) { > printf("OSMesaMakeCurrent (%d bits/channel) failed!\n", bits); > free(buffer); > OSMesaDestroyContext(ctx); > return 0; > } > > /* sanity checks */ > glGetIntegerv(GL_RED_BITS, &cBits); > assert(cBits == bits); > <snip> > > where type would be something other than GL_UNSIGNED_BYTE and therefore bits something larger than 8. The assert fails. I have version 7.0.3 running and this test passes. Furthermore, if I remove the sanity check the images come out correct. > > I was wondering if anyone has exprienced the same issue? I've built on Solaris 10 using SunStudio 12 compiler. If you need any more information. Please let me know. > > Thanks for the help. Mesa must be specially compiled to support 16 and 32-bit / channel rendering. Specifically, pass -DCHAN_BITS=16 or -DCHAN_BITS=32 to the compiler. The linux-osmesa16 and linux-osmes32 configs are examples. It should be easy to adapt one of those to Solaris. -Brian |
From: Joe M. <lp...@ya...> - 2010-04-13 19:53:38
|
Hi, I just downloaded Mesa 7.8.1 and built it on Solaris 10. After getting the libraries to compile, I attempted to verify the build using the demo apps. In particular I use the offscreen rendering mesa libraries provide. However, when I ran the ostest1 demo, the test program fails on to retrieve the correct size for the GL_RED_BITS. It seems to always be returning 8 even though the context was set to a large data type. In particular the lines of code that are failing include <snip> /* Bind the buffer to the context and make it current */ if (!OSMesaMakeCurrent( ctx, buffer, type, WIDTH, HEIGHT )) { printf("OSMesaMakeCurrent (%d bits/channel) failed!\n", bits); free(buffer); OSMesaDestroyContext(ctx); return 0; } /* sanity checks */ glGetIntegerv(GL_RED_BITS, &cBits); assert(cBits == bits); <snip> where type would be something other than GL_UNSIGNED_BYTE and therefore bits something larger than 8. The assert fails. I have version 7.0.3 running and this test passes. Furthermore, if I remove the sanity check the images come out correct. I was wondering if anyone has exprienced the same issue? I've built on Solaris 10 using SunStudio 12 compiler. If you need any more information. Please let me know. Thanks for the help. -joe |
From: Pauli N. <su...@gm...> - 2010-04-08 07:36:35
|
On Wed, Apr 7, 2010 at 6:39 PM, Philipp Klaus Krause <pk...@sp...> wrote: > Disclaimer: I know glxgears is not a benchmark, and I'm asking this > question out of curiosity, not out of some attempt to benchmarkusing > glxgears. > > Why do I consistently get higher glxgears framerates with indirect > rendering? Here's some glxgears output: > > 1736 frames in 5.0 seconds = 347.084 FPS > 1676 frames in 5.0 seconds = 335.017 FPS > 1500 frames in 5.0 seconds = 299.872 FPS > 1651 frames in 5.0 seconds = 330.194 FPS > 1741 frames in 5.0 seconds = 347.826 FPS > 1542 frames in 5.0 seconds = 308.269 FPS > 1544 frames in 5.0 seconds = 308.688 FPS > ^C > philipp@notebook3:~$ export LIBGL_ALWAYS_INDIRECT=1 > philipp@notebook3:~$ glxgears > Running synchronized to the vertical refresh. The framerate should be > approximately the same as the monitor refresh rate. > 2241 frames in 5.0 seconds = 446.507 FPS > 2020 frames in 5.0 seconds = 401.752 FPS > 2340 frames in 5.0 seconds = 463.619 FPS > 2120 frames in 5.0 seconds = 420.840 FPS > > System info: > OpenGL vendor string: Tungsten Graphics, Inc > OpenGL renderer string: Mesa DRI Intel(R) 965GM GEM 20091221 2009Q4 > OpenGL version string: 1.4 (2.1 Mesa 7.7.1) > > Philipp Direct rendering requires roundtrips between xserver and mesa for every frame while indirect rendering is just pushing data to xserver. That makes huge difference when most of the time is spent in buffer swap code. |
From: Philipp K. K. <pk...@sp...> - 2010-04-07 15:39:46
|
Disclaimer: I know glxgears is not a benchmark, and I'm asking this question out of curiosity, not out of some attempt to benchmarkusing glxgears. Why do I consistently get higher glxgears framerates with indirect rendering? Here's some glxgears output: 1736 frames in 5.0 seconds = 347.084 FPS 1676 frames in 5.0 seconds = 335.017 FPS 1500 frames in 5.0 seconds = 299.872 FPS 1651 frames in 5.0 seconds = 330.194 FPS 1741 frames in 5.0 seconds = 347.826 FPS 1542 frames in 5.0 seconds = 308.269 FPS 1544 frames in 5.0 seconds = 308.688 FPS ^C philipp@notebook3:~$ export LIBGL_ALWAYS_INDIRECT=1 philipp@notebook3:~$ glxgears Running synchronized to the vertical refresh. The framerate should be approximately the same as the monitor refresh rate. 2241 frames in 5.0 seconds = 446.507 FPS 2020 frames in 5.0 seconds = 401.752 FPS 2340 frames in 5.0 seconds = 463.619 FPS 2120 frames in 5.0 seconds = 420.840 FPS System info: OpenGL vendor string: Tungsten Graphics, Inc OpenGL renderer string: Mesa DRI Intel(R) 965GM GEM 20091221 2009Q4 OpenGL version string: 1.4 (2.1 Mesa 7.7.1) Philipp |
From: Chia-I Wu <ol...@gm...> - 2010-04-06 04:45:31
|
On Mon, Apr 05, 2010 at 11:39:46AM +0200, Andreas Pokorny wrote: > 2010/4/5 Chia-I Wu <ol...@gm...>: > > On Wed, Mar 31, 2010 at 05:59:16PM +0200, Andreas Pokorny wrote: > >> According to git bisect the fix of chaning RTLD_LOCAL to RTLD_GLOBAL > >> causes a crash in a different es2/egl implementation. > >> What is bad about explicitly linking to libEGL.so in the egl driver? > >> From my limited point of view it work without breaking anything. > > Sorry for the late response. > > Could the crash happen to be a version mismatch between libEGL and the > > driver? There is no version checking done right now.. > The crash happens on an imx51 board equipped with a z430 of amd. The > mesa stack is not involved. I am in contact with the vendor about this > issue (more or less it is vacation time here). Even though I have a > stack trace about the issue, I have no idea why it depends on the ld > flags. Its just that at the moment a component that is rather > unrelated to the actual rendering needs a build switch to either > support loading a renderer module that either runs with this or the > other implementation of libEGL. > > As for linking back to libEGL, I was worried about cyclic linking. > > Currently, EGL drivers require back-linking to libEGL > > http://sourceware.org/autobook/autobook/autobook_172.html > > It is assumed to be a bad design. I hope to fix this intead of linking > > back to libEGL. > So to make the graph directional again, one would have to strip libEGL > from the support symbols, and provide then in a seperate library. Are > these symbols provided by libEGL and used by the loaded modules > required by all moduels, or is this only needed by swrast? They are needed by all EGL drivers. It might be as well to see how other projects with dynamic plugins deal with the back-linking. -- olv@LunarG.com |
From: Andreas P. <and...@gm...> - 2010-04-05 09:39:55
|
Hi, 2010/4/5 Chia-I Wu <ol...@gm...>: > On Wed, Mar 31, 2010 at 05:59:16PM +0200, Andreas Pokorny wrote: >> According to git bisect the fix of chaning RTLD_LOCAL to RTLD_GLOBAL >> causes a crash in a different es2/egl implementation. >> What is bad about explicitly linking to libEGL.so in the egl driver? >> From my limited point of view it work without breaking anything. > > Sorry for the late response. > > Could the crash happen to be a version mismatch between libEGL and the > driver? There is no version checking done right now.. The crash happens on an imx51 board equipped with a z430 of amd. The mesa stack is not involved. I am in contact with the vendor about this issue (more or less it is vacation time here). Even though I have a stack trace about the issue, I have no idea why it depends on the ld flags. Its just that at the moment a component that is rather unrelated to the actual rendering needs a build switch to either support loading a renderer module that either runs with this or the other implementation of libEGL. > As for linking back to libEGL, I was worried about cyclic linking. > Currently, EGL drivers require back-linking to libEGL > > http://sourceware.org/autobook/autobook/autobook_172.html > > It is assumed to be a bad design. I hope to fix this intead of linking > back to libEGL. So to make the graph directional again, one would have to strip libEGL from the support symbols, and provide then in a seperate library. Are these symbols provided by libEGL and used by the loaded modules required by all moduels, or is this only needed by swrast? regards Andreas |
From: Chia-I Wu <ol...@gm...> - 2010-04-05 03:30:52
|
On Wed, Mar 31, 2010 at 05:59:16PM +0200, Andreas Pokorny wrote: > Its me again, > 2010/3/12 Chia-I Wu <ol...@gm...>: > > On Fri, Mar 12, 2010 at 6:02 AM, Andreas Pokorny > > <and...@gm...> wrote: > >> 2010/3/11 Chia-I Wu <ol...@gm...>: > >>> On Thu, Mar 11, 2010 at 10:06 PM, Andreas Pokorny > >>> <and...@gm...> wrote: > >>>> I work on: b8656c4825b9e054f05258773ba012e41d4fcdee > >>>> I have two rather strange problems using egl. I have implemented a > >>>> egl/es2/libX11 based renderer shared object file. The shared object > >>>> file gets loaded and initialized using dlopen/dlsym. Then when the > >>>> renderer is supposed to initialize EGL, and to create a window I run > >>>> into runtime symbol lookup errors. > >>>> ./Startup: symbol lookup error: /usr/local/lib/egl/egl_x11_swrast.so: > >>>> undefined symbol: _eglInitDriverFallbacks > >>> It seems _eglInitDriverFallbacks in libEGL.so is not resolved when > >>> egl_x11_swrast.so is loaded. I am not quite sure about your setup (who dlopen > >>> who?). Do you have a sample code that reproduces your setup or the issue? > >> My applicatin dlopens a shared object files that links against EGL and > >> ES2. I was just writing a sample code that turns progs/es2/xegl/tri.c > >> into a shared library. Then I dlopen the lib with > >> dlopen(RTLD_LAZY|RTLD_LOCAL); - and then i try to execute an exported > >> function of tri.c (turned main into a function with visibility > >> default) as it seems RTLD_LOCAL causes the issue. I have to use > >> RTLD_GLOBAL instead. So now it works. > >> I have no idea why i used RTLD_LOCAL in the first place. > > Glad you solved your problem. dlopen()ing is one of the part in EGL that I > > haven't looked at. I don't have enough experiences on various setups or Unixes > > to say that EGL is doing the right thing. > According to git bisect the fix of chaning RTLD_LOCAL to RTLD_GLOBAL > causes a crash in a different es2/egl implementation. > What is bad about explicitly linking to libEGL.so in the egl driver? > From my limited point of view it work without breaking anything. Sorry for the late response. Could the crash happen to be a version mismatch between libEGL and the driver? There is no version checking done right now.. As for linking back to libEGL, I was worried about cyclic linking. Currently, EGL drivers require back-linking to libEGL http://sourceware.org/autobook/autobook/autobook_172.html It is assumed to be a bad design. I hope to fix this intead of linking back to libEGL. -- olv@LunarG.com |
From: Andreas P. <and...@gm...> - 2010-03-31 15:59:23
|
Hi, Its me again, 2010/3/12 Chia-I Wu <ol...@gm...>: > On Fri, Mar 12, 2010 at 6:02 AM, Andreas Pokorny > <and...@gm...> wrote: >> 2010/3/11 Chia-I Wu <ol...@gm...>: >>> On Thu, Mar 11, 2010 at 10:06 PM, Andreas Pokorny >>> <and...@gm...> wrote: >>>> I work on: b8656c4825b9e054f05258773ba012e41d4fcdee >>>> I have two rather strange problems using egl. I have implemented a >>>> egl/es2/libX11 based renderer shared object file. The shared object >>>> file gets loaded and initialized using dlopen/dlsym. Then when the >>>> renderer is supposed to initialize EGL, and to create a window I run >>>> into runtime symbol lookup errors. >>>> ./Startup: symbol lookup error: /usr/local/lib/egl/egl_x11_swrast.so: >>>> undefined symbol: _eglInitDriverFallbacks >>> It seems _eglInitDriverFallbacks in libEGL.so is not resolved when >>> egl_x11_swrast.so is loaded. I am not quite sure about your setup (who dlopen >>> who?). Do you have a sample code that reproduces your setup or the issue? >> My applicatin dlopens a shared object files that links against EGL and >> ES2. I was just writing a sample code that turns progs/es2/xegl/tri.c >> into a shared library. Then I dlopen the lib with >> dlopen(RTLD_LAZY|RTLD_LOCAL); - and then i try to execute an exported >> function of tri.c (turned main into a function with visibility >> default) as it seems RTLD_LOCAL causes the issue. I have to use >> RTLD_GLOBAL instead. So now it works. >> I have no idea why i used RTLD_LOCAL in the first place. > > Glad you solved your problem. dlopen()ing is one of the part in EGL that I > haven't looked at. I don't have enough experiences on various setups or Unixes > to say that EGL is doing the right thing. According to git bisect the fix of chaning RTLD_LOCAL to RTLD_GLOBAL causes a crash in a different es2/egl implementation. What is bad about explicitly linking to libEGL.so in the egl driver? >From my limited point of view it work without breaking anything. kind regards Andreas |
From: Carlos P. <jos...@is...> - 2010-03-28 03:40:51
|
Thanks Tom, I will folow your suggestion to ask for help at Xorg (and CC you), I mentioned sintax because I have seen this attributes lists written in the internet in slightly different ways, with and without True after GLX_DOUBLEBUFFER, (perhaps older versions did not explicitly require True?) You are right 1, 1, 1 color bits are not common these days... :-) I red somewhere these were absolute minimum requirements for a OpenGL visual (like 12 for depth), anyway, better to replace by 8, 8, 8... Thanks, Carlos > Hi, > > Carlos Pereira <jos...@is...> writes: > > >> I apologize, these are essentialy GLX and X questions, not Mesa, I >> just don't know where else to ask this... I am trying to use only >> <GL/glx.h> to write a GTK/OpenGL app. It is working fine, though I >> still have some few questions, mainly regarding memory leaks: >> > > I admit I don't know all the answers here, and as you say, I'm not sure > this the best forum. The Xorg list is probably a good place for this > though: > > http://lists.freedesktop.org/mailman/listinfo/xorg > > >> 1) The sintax for this list of attributes is correct? Shall I improve it >> somehow? it works for me... >> >> int attributes[] = { GLX_RGBA, GLX_RED_SIZE, 1, GLX_GREEN_SIZE, 1, >> GLX_BLUE_SIZE, 1, GLX_DOUBLEBUFFER, True, GLX_DEPTH_SIZE, 12, None }; >> XVisualInfo *visual_info; >> visual_info = glXChooseVisual (display, screen, attributes); >> > > well, if it compiles, the syntax is correct ;P > > I'm not sure the semantics are correct, but I'm not sure what your > application actually wants. I'll note that glXChooseVisual is allowed > to give you 3 bits for all color given the above specification, and I'd > bet you design your app to use more color. > > >> 2) free visual_info immediately after creating the context, [. . .] >> 3) free context and colormap when the GL window is removed? it works >> for me... >> 3) Shall I free visual_info->visual in the end, when closing the app? >> [. . .] >> > > This is where my knowledge ends. Please CC me if you start an Xorg > thread :) > > -tom > > ------------------------------------------------------------------------------ > 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: tom f. <tf...@al...> - 2010-03-26 20:05:24
|
Hi, Carlos Pereira <jos...@is...> writes: > I apologize, these are essentialy GLX and X questions, not Mesa, I > just don't know where else to ask this... I am trying to use only > <GL/glx.h> to write a GTK/OpenGL app. It is working fine, though I > still have some few questions, mainly regarding memory leaks: I admit I don't know all the answers here, and as you say, I'm not sure this the best forum. The Xorg list is probably a good place for this though: http://lists.freedesktop.org/mailman/listinfo/xorg > 1) The sintax for this list of attributes is correct? Shall I improve it > somehow? it works for me... > > int attributes[] = { GLX_RGBA, GLX_RED_SIZE, 1, GLX_GREEN_SIZE, 1, > GLX_BLUE_SIZE, 1, GLX_DOUBLEBUFFER, True, GLX_DEPTH_SIZE, 12, None }; > XVisualInfo *visual_info; > visual_info = glXChooseVisual (display, screen, attributes); well, if it compiles, the syntax is correct ;P I'm not sure the semantics are correct, but I'm not sure what your application actually wants. I'll note that glXChooseVisual is allowed to give you 3 bits for all color given the above specification, and I'd bet you design your app to use more color. > 2) free visual_info immediately after creating the context, [. . .] > 3) free context and colormap when the GL window is removed? it works > for me... > 3) Shall I free visual_info->visual in the end, when closing the app? > [. . .] This is where my knowledge ends. Please CC me if you start an Xorg thread :) -tom |
From: Carlos P. <jos...@is...> - 2010-03-24 19:50:35
|
Hi, I apologize, these are essentialy GLX and X questions, not Mesa, I just don't know where else to ask this... I am trying to use only <GL/glx.h> to write a GTK/OpenGL app. It is working fine, though I still have some few questions, mainly regarding memory leaks: 1) The sintax for this list of attributes is correct? Shall I improve it somehow? it works for me... int attributes[] = { GLX_RGBA, GLX_RED_SIZE, 1, GLX_GREEN_SIZE, 1, GLX_BLUE_SIZE, 1, GLX_DOUBLEBUFFER, True, GLX_DEPTH_SIZE, 12, None }; XVisualInfo *visual_info; visual_info = glXChooseVisual (display, screen, attributes); 2) free visual_info immediately after creating the context, when it is no longer needed? it works for me... XVisualInfo *visual_info; visual_info = glXChooseVisual (display, screen, attributes); ... context = glXCreateContext (display, visual_info, NULL, TRUE); XFree (visual_info); <<<<<<<<<< 3) free context and colormap when the GL window is removed? it works for me... colormap = XCreateColormap (display, root, visual_info->visual, AllocNone); context = glXCreateContext (display, visual_info, NULL, TRUE); ... glXDestroyContext (display, context); <<<<<<<< XFreeColormap (display, colormap); <<<<<<<<<< 3) Shall I free visual_info->visual in the end, when closing the app? I am not sure... I suppose the answer is no? XVisualInfo *visual_info; Thank you very much for your help... (I posted two fully working examples, one using GLX, the other GTKGLExt, at: http://www.gamgi.org/gtk_opengl.tar.gz). Carlos |
From: Denat H. <Denat@Denat.me> - 2010-03-22 00:55:17
|
Oh, great, after I get a file ready to be made, I'll add it to: PROGS = \ addhere \ And if that doesn't work, I'll study the makefile format a little more. You guys made me feel a lot more confident that GL can get working on this machine, its cool that these steps are done. Denat |
From: Sergio M. B. <se...@se...> - 2010-03-21 23:14:41
|
On Sun, 2010-03-21 at 23:02 +0000, Sergio Monteiro Basto wrote: > you you delete the executables or update sources , make will do it > again . I mean " if you " -- Sérgio M. B. |
From: Sergio M. B. <se...@se...> - 2010-03-21 23:04:42
|
On Sun, 2010-03-21 at 12:16 -0400, Denat Hulaiichun wrote: > Oh, the demos have executables already in the demos folder. I tried > doing make again, it said nothing to be done for 'default'. If the make you you delete the executables or update sources , make will do it again . > i did before made those, how do I compile new gl applications, do I need > to create a similar makefile every time? "Make" just make executables if they are not update, if modify time of the source if newer that executable , make will do it again . > or is there a way to do the > includes easier with gcc? you can copy what make produces and change for yours application or you can change make to make also your application. > > It looks like mesa's almost working for me.., > Denat > Regards, -- Sérgio M. B. |
From: Denat H. <Denat@Denat.me> - 2010-03-21 22:13:19
|
Oh, great, make clean and make worked. When you get a chance, how would I include and link for future applications, instead of demos? For instance, I tried " gcc -l GL -l GLU -l GLUT -l OSMesa -o progname " and then arbfplight.c or an openglut example: fractals.c . I see that certain gl progs have their own headers, but let's say I don't make a header for a new one, if a makefile is always needed instead of terminal commands, anyone have a sample general one? Now I know Mesa is working the right way, K, Denat |
From: Pauli N. <su...@gm...> - 2010-03-21 17:43:10
|
On Sun, Mar 21, 2010 at 6:16 PM, Denat Hulaiichun <De...@de...> wrote: > Oh, the demos have executables already in the demos folder. I tried > doing make again, it said nothing to be done for 'default'. If the make > i did before made those, how do I compile new gl applications, do I need > to create a similar makefile every time? or is there a way to do the > includes easier with gcc? > make clean && make will recompile everything there. Minimum rrequirement to build gl stuff is to have the path to gl headers in include path. Also you need to link against libraries that you use (gl & glut most likely) > It looks like mesa's almost working for me.., > Denat > |
From: Sergio M. B. <se...@se...> - 2010-03-21 17:39:57
|
On Sun, 2010-03-21 at 11:58 -0400, Denat Hulaiichun wrote: > That makes sense. I did make linux-x86-64 for libgl1-mesa-dev (7.0.3) > and it looks like it worked well. Demos came with it, and they all > run, > but how do I compile the .c file demos? make in demos dir ? with write permissions . -- Sérgio M. B. |
From: Denat H. <Denat@Denat.me> - 2010-03-21 17:16:24
|
Oh, the demos have executables already in the demos folder. I tried doing make again, it said nothing to be done for 'default'. If the make i did before made those, how do I compile new gl applications, do I need to create a similar makefile every time? or is there a way to do the includes easier with gcc? It looks like mesa's almost working for me.., Denat |
From: Pauli N. <su...@gm...> - 2010-03-21 17:04:09
|
On Sun, Mar 21, 2010 at 5:58 PM, Denat Hulaiichun <De...@de...> wrote: > That makes sense. I did make linux-x86-64 for libgl1-mesa-dev (7.0.3) > and it looks like it worked well. Demos came with it, and they all run, > but how do I compile the .c file demos? If I can't using gcc -o > execname .c-name, because i get those errors again, will I be able to > compile my own files I create? I just tried compiling in the same way an > openglut example of a website, got the same errors: undefined reference > to 'glTranslated or glScaled etc'. Am I not compiling right or is it > still not installed right? > There is makefile in mesa source. It appends quite a lot include paths to compile operation. Try running make in demo directory and they should compile without problems. > Anyone know? K, this is helping, > Denat |
From: Denat H. <Denat@Denat.me> - 2010-03-21 16:58:08
|
That makes sense. I did make linux-x86-64 for libgl1-mesa-dev (7.0.3) and it looks like it worked well. Demos came with it, and they all run, but how do I compile the .c file demos? If I can't using gcc -o execname .c-name, because i get those errors again, will I be able to compile my own files I create? I just tried compiling in the same way an openglut example of a website, got the same errors: undefined reference to 'glTranslated or glScaled etc'. Am I not compiling right or is it still not installed right? Anyone know? K, this is helping, Denat |
From: Sergio M. B. <se...@se...> - 2010-03-21 16:26:08
|
Hi, On Sat, 2010-03-20 at 23:17 -0400, Denat Hulaiichun wrote: > Hi, > > I have Debian Squeeze and tried ./configuring, making and make > installing the Mesa download folder, when I tried to gcc the demos in > the Mesa folder, I got some errors. Something isn't installed right with > the Mesa on this machine. You need install mesa-devel packages . Debian should came with mesa-demos packages , try find them . Mesa 7.7 is for devel and test new advance features , normally stable version on distros , are good enough . Regards, > > Here's terminal output of compiling a demo: > > username/libs/Demos/MesaDemos-7.7/progs/demos# gcc -o arbfplight > arbfplight.c > /tmp/cc6JMPpU.o: In function `normalize': > arbfplight.c:(.text+0x7b): undefined reference to `sqrt' > /tmp/cc6JMPpU.o: In function `Redisplay': > arbfplight.c:(.text+0xeb): undefined reference to `glClear' > arbfplight.c:(.text+0x134): undefined reference to `glEnable' > arbfplight.c:(.text+0x13e): undefined reference to `glEnable' > arbfplight.c:(.text+0x148): undefined reference to `glDisable' > arbfplight.c:(.text+0x15e): undefined reference to `glLightfv' > arbfplight.c:(.text+0x168): undefined reference to `glDisable' > arbfplight.c:(.text+0x172): undefined reference to `glDisable' > arbfplight.c:(.text+0x17c): undefined reference to `glEnable' > arbfplight.c:(.text+0x181): undefined reference to `glPushMatrix' > arbfplight.c:(.text+0x19c): undefined reference to `glRotatef' > arbfplight.c:(.text+0x1b7): undefined reference to `glRotatef' > arbfplight.c:(.text+0x1ce): undefined reference to `glutSolidSphere' > arbfplight.c:(.text+0x1d3): undefined reference to `glPopMatrix' > arbfplight.c:(.text+0x1d8): undefined reference to `glutSwapBuffers' > arbfplight.c:(.text+0x200): undefined reference to `glutGet' > /tmp/cc6JMPpU.o: In function `Idle': > arbfplight.c:(.text+0x318): undefined reference to `glutPostRedisplay' > /tmp/cc6JMPpU.o: In function `Reshape': > arbfplight.c:(.text+0x341): undefined reference to `glViewport' > arbfplight.c:(.text+0x34b): undefined reference to `glMatrixMode' > arbfplight.c:(.text+0x350): undefined reference to `glLoadIdentity' > arbfplight.c:(.text+0x38d): undefined reference to `glFrustum' > arbfplight.c:(.text+0x397): undefined reference to `glMatrixMode' > arbfplight.c:(.text+0x39c): undefined reference to `glLoadIdentity' > arbfplight.c:(.text+0x3af): undefined reference to `glTranslatef' > /tmp/cc6JMPpU.o: In function `Key': > arbfplight.c:(.text+0x431): undefined reference to `glutIdleFunc' > arbfplight.c:(.text+0x440): undefined reference to `glutIdleFunc' > arbfplight.c:(.text+0x4b3): undefined reference to `glPolygonMode' > arbfplight.c:(.text+0x4c7): undefined reference to `glPolygonMode' > arbfplight.c:(.text+0x531): undefined reference to `glutDestroyWindow' > arbfplight.c:(.text+0x540): undefined reference to `glutPostRedisplay' > /tmp/cc6JMPpU.o: In function `SpecialKey': > arbfplight.c:(.text+0x5da): undefined reference to `glutPostRedisplay' > /tmp/cc6JMPpU.o: In function `Init': > arbfplight.c:(.text+0x631): undefined reference to > `glutExtensionSupported' > arbfplight.c:(.text+0x653): undefined reference to > `glutExtensionSupported' > arbfplight.c:(.text+0x675): undefined reference to `glutGetProcAddress' > arbfplight.c:(.text+0x6ab): undefined reference to `glutGetProcAddress' > arbfplight.c:(.text+0x6e1): undefined reference to `glutGetProcAddress' > arbfplight.c:(.text+0x717): undefined reference to `glutGetProcAddress' > arbfplight.c:(.text+0x74d): undefined reference to `glutGetProcAddress' > /tmp/cc6JMPpU.o:arbfplight.c:(.text+0x783): more undefined references to > `glutGetProcAddress' follow > /tmp/cc6JMPpU.o: In function `Init': > arbfplight.c:(.text+0x8a7): undefined reference to `glGetIntegerv' > arbfplight.c:(.text+0x8ac): undefined reference to `glGetError' > arbfplight.c:(.text+0x8d9): undefined reference to `glGetString' > arbfplight.c:(.text+0xab7): undefined reference to `glGetIntegerv' > arbfplight.c:(.text+0xabc): undefined reference to `glGetError' > arbfplight.c:(.text+0xae9): undefined reference to `glGetString' > arbfplight.c:(.text+0xb5e): undefined reference to `glClearColor' > arbfplight.c:(.text+0xb68): undefined reference to `glEnable' > arbfplight.c:(.text+0xb72): undefined reference to `glEnable' > arbfplight.c:(.text+0xb7c): undefined reference to `glEnable' > arbfplight.c:(.text+0xb90): undefined reference to `glMaterialfv' > arbfplight.c:(.text+0xba4): undefined reference to `glMaterialfv' > arbfplight.c:(.text+0xbbb): undefined reference to `glMaterialf' > arbfplight.c:(.text+0xbc5): undefined reference to `glGetString' > /tmp/cc6JMPpU.o: In function `main': > arbfplight.c:(.text+0xc12): undefined reference to `glutInit' > arbfplight.c:(.text+0xc21): undefined reference to > `glutInitWindowPosition' > arbfplight.c:(.text+0xc30): undefined reference to `glutInitWindowSize' > arbfplight.c:(.text+0xc3a): undefined reference to `glutInitDisplayMode' > arbfplight.c:(.text+0xc49): undefined reference to `glutCreateWindow' > arbfplight.c:(.text+0xc59): undefined reference to `glutReshapeFunc' > arbfplight.c:(.text+0xc63): undefined reference to `glutKeyboardFunc' > arbfplight.c:(.text+0xc6d): undefined reference to `glutSpecialFunc' > arbfplight.c:(.text+0xc77): undefined reference to `glutDisplayFunc' > arbfplight.c:(.text+0xc8c): undefined reference to `glutIdleFunc' > arbfplight.c:(.text+0xc96): undefined reference to `glutMainLoop' > collect2: ld returned 1 exit status > > > K, I can tell you any other info about my machine/situation, > Denat > > > ------------------------------------------------------------------------------ > 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 -- Sérgio M. B. |