Re: [Mesa3d-dev] mesa 7.8 GIT: Broken by glapi: Correctly generate static disatches for X86.
On Sat, 2010-03-20 at 14:51 +0100, Sedat Dilek wrote: Hi, while upgrading my mesa from 7.8 GIT branch, I saw with commit 41a87a43e11c664935349f938022d58d3e22da4e glapi: Correctly generate static disatches for X86. the build breaking (especially with xdemos). - Sedat - [build.log] ccache gcc -I../../include -g -O2 -Wall -Wmissing-prototypes -std=c99 -ffast-math -fvisibility=hidden -fno-strict-aliasing -g -fPIC -DUSE_X86_ASM -DUSE_MMX_ASM -DUSE_3DNOW_ASM -DUSE_SSE_ASM -D_GNU_SOURCE -DPTHREADS -DDEBUG -DHAVE_POSIX_MEMALIGN -DGLX_USE_TLS -DPTHREADS -DUSE_EXTERNAL_DXTN_LIB=1 -DIN_DRI_DRIVER -DGLX_DIRECT_RENDERING -DGLX_INDIRECT_RENDERING -DHAVE_ALIAS glxdemo.c -L../../lib -lGL -L/usr/lib -lm -lX11 -lpthread -o glxdemo ../../lib/libGL.so: undefined reference to `glBlitFramebufferEXT' ../../lib/libGL.so: undefined reference to `glDeleteVertexArraysAPPLE' ../../lib/libGL.so: undefined reference to `glIsVertexArrayAPPLE' ../../lib/libGL.so: undefined reference to `glBlendEquationSeparateEXT' collect2: ld returned 1 exit status make[2]: *** [glsync] Error 1 make[2]: *** Waiting for unfinished jobs ../../lib/libGL.so: undefined reference to `glBlitFramebufferEXT' ../../lib/libGL.so: undefined reference to `glDeleteVertexArraysAPPLE' ../../lib/libGL.so: undefined reference to `glIsVertexArrayAPPLE' ../../lib/libGL.so: undefined reference to `glBlendEquationSeparateEXT' collect2: ld returned 1 exit status make[2]: *** [glxdemo] Error 1 ../../lib/libGL.so: undefined reference to `glBlitFramebufferEXT' ../../lib/libGL.so: undefined reference to `glDeleteVertexArraysAPPLE' ../../lib/libGL.so: undefined reference to `glIsVertexArrayAPPLE' ../../lib/libGL.so: undefined reference to `glBlendEquationSeparateEXT' collect2: ld returned 1 exit status make[2]: *** [glthreads] Error 1 These demos are broken: Those GL API calls aren't part of the Linux OpenGL ABI, so their addresses need to be retrieved with glXGetProcAddress(). -- Earthling Michel Dänzer |http://www.vmware.com Libre software enthusiast | Debian, X and DRI developer -- Download Intel#174; 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-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
[Mesa3d-dev] [Bug 27250] New: glEnable(GL_VERTEX PROGRAM POINT SIZE) doesn't work
http://bugs.freedesktop.org/show_bug.cgi?id=27250 Summary: glEnable(GL_VERTEX PROGRAM POINT SIZE) doesn't work Product: Mesa Version: git Platform: Other OS/Version: All Status: NEW Severity: normal Priority: medium Component: Mesa core AssignedTo: mesa3d-dev@lists.sourceforge.net ReportedBy: n...@linux.intel.com Created an attachment (id=34328) -- (http://bugs.freedesktop.org/attachment.cgi?id=34328) Test case Under GL 2.0 you are meant to be able to write to the gl_PointSize output from the vertex shader to change the point size per-vertex. This doesn't appear to work in Mesa. The attachment is a simple program that draws a single point in the center of the screen. It uses a vertex shader to change the size of the point to 32 pixels. Under Mesa git master this ends up being a single pixel but on an NVIDIA machine it correctly ends up as 32 pixels. -- Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. -- Download Intel#174; 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-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
Re: [Mesa3d-dev] DRI SDK and modularized drivers.
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Luc Verhaegen wrote: On Fri, Mar 19, 2010 at 11:33:02AM -0700, Ian Romanick wrote: I've been busy trying to get a release out the door, so I haven't looked at these patches yet. I won't have a chance to look at the patches until at least late next week. I also wasn't at FOSDEM, so I don't have any of the background info. I've grouped the slides and the recordings at the top of my blog entry about this. The patches themselves are actually copies of eachother, with minor differences to adjust for changes of the tree around it (there are 16 or so versions of the sdk done from 7.0 through 7.8). Any actual patch is small, and it is build system only. If these patches try to enforce a stable interface between core Mesa and the classic DRI drivers, we're not interested. At all. This has been discussed and rejected many, many times before. Ah, prepossession. Ask yourself, did the fact that xf86 video drivers were out of tree, ever stop anyone from _really_ bad api breakage stunts? The difference, and I think this is significant, is that the functionality provided by the xf86 video drivers through the X server hasn't changed much in quite some time. The amount of functionality added in every single major release of Mesa which requires driver changes is significant. We're far enough behind the state of the GL spec and the closed-source drivers that I don't really want anything that will slow us down. You can't aim a stable interface at a moving target. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkunq7sACgkQX1gOwKyEAw8dqwCfR9/JjfCecV0Q4Po4AdnJaTOE QrQAoJu1+zMz5shOHrhmOSL+L2um190q =+eep -END PGP SIGNATURE- -- Download Intel#174; 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-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
Re: [Mesa3d-dev] mesa 7.8 GIT: Broken by glapi: Correctly generate static disatches for X86.
2010/3/22 Michel Dänzer mic...@daenzer.net: On Sat, 2010-03-20 at 14:51 +0100, Sedat Dilek wrote: while upgrading my mesa from 7.8 GIT branch, I saw with commit 41a87a43e11c664935349f938022d58d3e22da4e glapi: Correctly generate static disatches for X86. the build breaking (especially with xdemos). - Sedat - [build.log] ccache gcc -I../../include -g -O2 -Wall -Wmissing-prototypes -std=c99 -ffast-math -fvisibility=hidden -fno-strict-aliasing -g -fPIC -DUSE_X86_ASM -DUSE_MMX_ASM -DUSE_3DNOW_ASM -DUSE_SSE_ASM -D_GNU_SOURCE -DPTHREADS -DDEBUG -DHAVE_POSIX_MEMALIGN -DGLX_USE_TLS -DPTHREADS -DUSE_EXTERNAL_DXTN_LIB=1 -DIN_DRI_DRIVER -DGLX_DIRECT_RENDERING -DGLX_INDIRECT_RENDERING -DHAVE_ALIAS glxdemo.c -L../../lib -lGL -L/usr/lib -lm -lX11 -lpthread -o glxdemo ../../lib/libGL.so: undefined reference to `glBlitFramebufferEXT' ../../lib/libGL.so: undefined reference to `glDeleteVertexArraysAPPLE' ../../lib/libGL.so: undefined reference to `glIsVertexArrayAPPLE' ../../lib/libGL.so: undefined reference to `glBlendEquationSeparateEXT' collect2: ld returned 1 exit status make[2]: *** [glsync] Error 1 make[2]: *** Waiting for unfinished jobs ../../lib/libGL.so: undefined reference to `glBlitFramebufferEXT' ../../lib/libGL.so: undefined reference to `glDeleteVertexArraysAPPLE' ../../lib/libGL.so: undefined reference to `glIsVertexArrayAPPLE' ../../lib/libGL.so: undefined reference to `glBlendEquationSeparateEXT' collect2: ld returned 1 exit status make[2]: *** [glxdemo] Error 1 ../../lib/libGL.so: undefined reference to `glBlitFramebufferEXT' ../../lib/libGL.so: undefined reference to `glDeleteVertexArraysAPPLE' ../../lib/libGL.so: undefined reference to `glIsVertexArrayAPPLE' ../../lib/libGL.so: undefined reference to `glBlendEquationSeparateEXT' collect2: ld returned 1 exit status make[2]: *** [glthreads] Error 1 These demos are broken: Those GL API calls aren't part of the Linux OpenGL ABI, so their addresses need to be retrieved with glXGetProcAddress(). The errors were due to missing symbols in libGL.so. The demos did not call them. The bug was triggered by me in 41a87a43e11c664935349f938022d58d3e22da4e and was fixed in 6fed3a9fa0a87ae797f995de5b51eb9be3493fe0. -- o...@lunarg.com -- Download Intel#174; 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-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
Re: [Mesa3d-dev] [xserver patch v5 3/5] glx: Enforce a 1:1 correspondence between GLX and X11 windows.
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Kristian Høgsberg wrote:
2010/2/8 Francisco Jerez curroje...@riseup.net:
The spec says (regarding glXCreateWindow): If there is already a
GLXFBConfig associated with win (as a result of a previous
glXCreateWindow call), then a BadAlloc error is generated.. It will
also come useful to implement DRI2InvalidateBuffers for the indirect
case.
Signed-off-by: Francisco Jerez curroje...@riseup.net
I've put this version of this patch (with krh's R-b) in my GLX-fixes
tree. Are the all the rest in Kristian's dri2-invalidate tree?
Looks good,
Reviewed-by: Kristian Høgsberg k...@bitplanet.net
---
v5: Simplification as suggested by Kristian.
glx/glxcmds.c | 24 +++-
glx/glxserver.h |1 +
2 files changed, 24 insertions(+), 1 deletions(-)
diff --git a/glx/glxcmds.c b/glx/glxcmds.c
index 77afbf4..cac30e6 100644
--- a/glx/glxcmds.c
+++ b/glx/glxcmds.c
@@ -51,6 +51,15 @@
#include indirect_table.h
#include indirect_util.h
+static int glxWindowPrivateKeyIndex;
+static DevPrivateKey glxWindowPrivateKey = glxWindowPrivateKeyIndex;
+
+__GLXdrawable *
+glxGetDrawableFromWindow(WindowPtr pWin)
+{
+ return dixLookupPrivate(pWin-devPrivates, glxWindowPrivateKey);
+}
+
static int
validGlxScreen(ClientPtr client, int screen, __GLXscreen **pGlxScreen, int
*err)
{
@@ -519,6 +528,9 @@ __glXGetDrawable(__GLXcontext *glxc, GLXDrawable drawId,
ClientPtr client,
return NULL;
}
+dixSetPrivate(((WindowPtr)pDraw)-devPrivates, glxWindowPrivateKey,
+ pGlxDraw);
+
return pGlxDraw;
}
@@ -1107,7 +1119,7 @@ __glXDrawableRelease(__GLXdrawable *drawable)
}
}
-static int
+static int
DoCreateGLXDrawable(ClientPtr client, __GLXscreen *pGlxScreen, __GLXconfig
*config,
DrawablePtr pDraw, XID glxDrawableId, int type)
{
@@ -1128,6 +1140,10 @@ DoCreateGLXDrawable(ClientPtr client, __GLXscreen
*pGlxScreen, __GLXconfig *conf
return BadAlloc;
}
+if (type == GLX_DRAWABLE_WINDOW)
+ dixSetPrivate(((WindowPtr)pDraw)-devPrivates,
+ glxWindowPrivateKey, pGlxDraw);
+
return Success;
}
@@ -1422,6 +1438,12 @@ int __glXDisp_CreateWindow(__GLXclientState *cl,
GLbyte *pc)
return BadWindow;
}
+/* Make sure there're no already associated GLX drawables. */
+if (glxGetDrawableFromWindow((WindowPtr)pDraw)) {
+ client-errorValue = req-window;
+ return BadAlloc;
+}
+
if (!validGlxFBConfigForWindow(client, config, pDraw, err))
return err;
diff --git a/glx/glxserver.h b/glx/glxserver.h
index 1daf977..3c49b5e 100644
--- a/glx/glxserver.h
+++ b/glx/glxserver.h
@@ -80,6 +80,7 @@ typedef struct __GLXcontext __GLXcontext;
extern __GLXscreen *glxGetScreen(ScreenPtr pScreen);
extern __GLXclientState *glxGetClient(ClientPtr pClient);
+extern __GLXdrawable *glxGetDrawableFromWindow(WindowPtr pWin);
//
--
1.6.4.4
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iEYEARECAAYFAkuny3IACgkQX1gOwKyEAw8s7wCdHFT2LwWBMvANCHW3vAfCbRLv
S/4An3U/kZH+Q4OxUJD3q6YlrFiG2RW4
=g9WK
-END PGP SIGNATURE-
--
Download Intel#174; 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-dev mailing list
Mesa3d-dev@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
Re: [Mesa3d-dev] A tiny problem regarding with the mesa source layout and DRI driver development
On Mon, Mar 22, 2010 at 1:29 PM, LiYe omni.l...@gmail.com wrote: I'm interested in openGL implementation and the DRI driver development. Specifically, I want to learn how an OpenGL command was implemented and how it was converted into direct rendering context and transferred to the hardware. I know this is a quite complicated and time-consuming task, but it would be great if I can start the learning cruve with my newbie background. So I'm trying to look into the mesa codes. However, it seems quite large and monolithic and I cannot find a suitable breaking point. So I wrote this to ask for some experienced advice. For an overview of how DRI works in codes(not in theory as explained in documents), where should I start with? I would suggest getting an IDE that has decent code browsing capabilities (I personally like to play with the KDevelop4 beta even though it's still a bit flaky) and just start stepping through your favourite driver in a debugger. Note that your life will be less painful if you have a second machine from which you can SSH in, so that your gdb session doesn't live on the same X server as the OpenGL application that you're debugging. cu, Nicolai -- Download Intel#174; 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-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
[Mesa3d-dev] [Bug 27254] New: glBlitFramebuffer is defined while glBlitFramebufferEXT is hidden as described by the XMLs
http://bugs.freedesktop.org/show_bug.cgi?id=27254 Summary: glBlitFramebuffer is defined while glBlitFramebufferEXT is hidden as described by the XMLs Product: Mesa Version: unspecified Platform: Other OS/Version: All Status: NEW Severity: normal Priority: medium Component: Mesa core AssignedTo: mesa3d-dev@lists.sourceforge.net ReportedBy: alan...@auckland.ac.nz CC: alan...@auckland.ac.nz Hi all, EXT_framebuffer_object.xml specifies that BlitFramebufferEXT to be hidden while BlitFramebuffer is exposed as described in ARB_framebuffer_object.xml, is that intentional? As GL_EXT_framebuffer_blit is supported since 6.5, I would have thought that BlitFramebufferEXT should be defined in the library. It is unfortunately that when I test some of the functions using MESA, I need to get a pointer to glBlitFramebuffer and when I test it on an older piece of hardware then I need to get a pointer to glBlitFramebufferEXT. Anyway, thanks so much for reading, I just want to know rather this is a bug or the actual implementation so that I can do the appropriate thing in my program. -- Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. -- Download Intel#174; 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-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
Re: [Mesa3d-dev] DRI SDK and modularized drivers.
On Mon, Mar 22, 2010 at 10:46:37PM +0100, Nicolai Haehnle wrote: On Mon, Mar 22, 2010 at 2:24 AM, Luc Verhaegen l...@skynet.be wrote: In particular, the Mesa core - classic driver split only makes sense if there are enough people who are actually working on those drivers who would support the split. Otherwise, this is bound to lead straight into hell. In a way, the kernel people got it right: put all the drivers in one repository, and make building the whole package and having parallel put all the drivers in one repository? So, all of: * drm * firmware * libdrm * xorg * mesa/dri * mesa/gallium * libxvmc * libvdpau (add more here) of the same driver stack, in one repository? Why not? Mind you, I'm not advocating for any change at all, but as long as you feel the need to move stuff around, why not try finding a goal that people actually find useful? Of course, my suggestion is probably crap, too. Great, seems we agree on something here. [snip] The real question is: where is the most pain, and how can we reduce it. And the most pain is between the driver specific parts. Nobody has ever had to feel the pain of a separation between Mesa core and drivers. And since a git log I've just done tells me that you have committed only twice to the Mesa repository within the last year or so, maybe you should listen to the opinion of people who *have* been active in the Mesa tree when it comes to that subject, and are working on drivers that are probably significantly more involved than whatever Unichrome does. Heh. 2) it wouldn't actually solve the DRM problems, because we want to have the DRM in our codebase, and the kernel people want to have it in theirs. The kernel people can have theirs. What stops anyone from getting the drm code of a released driver stack into the next kernel version? But when anyone decides they need a new driver stack which requires a new drm module, it should be easy to replace the stock kernel module. And that has worked so well in the past. Yes, it did. And people for more than a year still pulled the mesa/drm tree and built and installed it, as doing this often solved their driver stack internal problems for them. Luc Verhaegen. -- Download Intel#174; 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-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
[Mesa3d-dev] [Bug 27254] glBlitFramebuffer is defined while glBlitFramebufferEXT is hidden as described by the XMLs
http://bugs.freedesktop.org/show_bug.cgi?id=27254 --- Comment #1 from Tom Fogal tfo...@alumni.unh.edu 2010-03-22 17:41:58 PST --- EXT_framebuffer_object.xml specifies that BlitFramebufferEXT to be hidden while BlitFramebuffer is exposed as described in ARB_framebuffer_object.xml, is that intentional? This is reasonable, at least. The Linux OpenGL ABI only requires that OpenGL 1.2, GLU 1.3, GLX 1.3, and ARB_multitexture symbols be available. I refer you to the ABI, particularly section 3: http://www.opengl.org/registry/ABI/#3 See especially 3.4, 3.5, and 3.6. As GL_EXT_framebuffer_blit is supported since 6.5, I would have thought that BlitFramebufferEXT should be defined in the library. It is unfortunately that when I test some of the functions using MESA, I need to get a pointer to glBlitFramebuffer and when I test it on an older piece of hardware then I need to get a pointer to glBlitFramebufferEXT. Sorry; this is how OpenGL is specified. As you can read above, exposing glBlitFramebuffer is an implementation courtesy. An argument could be made that nothing above GL 1.2 should be exported, so that developers like you and I would more quickly ascertain that we are writing invalid code! That'd probably be a bad idea though, because a lot of `in the wild' code is likely to break if we remove all those entry points. Anyway, the only valid way to get glBlitFramebuffer, or any extension really, is to load it dynamically. This is why I recommend GLEW :) -- Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. -- Download Intel#174; 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-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
Re: [Mesa3d-dev] [xserver patch v5 3/5] glx: Enforce a 1:1 correspondence between GLX and X11 windows.
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Kristian Høgsberg wrote: 2010/3/22 Ian Romanick i...@freedesktop.org: Kristian Høgsberg wrote: 2010/2/8 Francisco Jerez curroje...@riseup.net: The spec says (regarding glXCreateWindow): If there is already a GLXFBConfig associated with win (as a result of a previous glXCreateWindow call), then a BadAlloc error is generated.. It will also come useful to implement DRI2InvalidateBuffers for the indirect case. Signed-off-by: Francisco Jerez curroje...@riseup.net I've put this version of this patch (with krh's R-b) in my GLX-fixes tree. Are the all the rest in Kristian's dri2-invalidate tree? We dropped this one, and the rest is in my dri2-invalidate tree. Why was it dropped? I believe that it enforced correct behavior. If this really does need to be removed, any suggestions how to fix my tree? :( git-revert seems the only way, but that makes for ugly history in a tree like this. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkuoEBcACgkQX1gOwKyEAw+iWgCePAg8e40Lj+kYXt3xT+ZiQG+g r6sAnRf0ez7NGhXarxYEw3oPk5E0xBi7 =CVLf -END PGP SIGNATURE- -- Download Intel#174; 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-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
[Mesa3d-dev] [Bug 27254] glBlitFramebuffer is defined while glBlitFramebufferEXT is hidden as described by the XMLs
http://bugs.freedesktop.org/show_bug.cgi?id=27254 --- Comment #2 from Alan alan...@auckland.ac.nz 2010-03-22 18:49:55 PST --- (In reply to comment #1) EXT_framebuffer_object.xml specifies that BlitFramebufferEXT to be hidden while BlitFramebuffer is exposed as described in ARB_framebuffer_object.xml, is that intentional? This is reasonable, at least. The Linux OpenGL ABI only requires that OpenGL 1.2, GLU 1.3, GLX 1.3, and ARB_multitexture symbols be available. I refer you to the ABI, particularly section 3: http://www.opengl.org/registry/ABI/#3 See especially 3.4, 3.5, and 3.6. As GL_EXT_framebuffer_blit is supported since 6.5, I would have thought that BlitFramebufferEXT should be defined in the library. It is unfortunately that when I test some of the functions using MESA, I need to get a pointer to glBlitFramebuffer and when I test it on an older piece of hardware then I need to get a pointer to glBlitFramebufferEXT. Sorry; this is how OpenGL is specified. As you can read above, exposing glBlitFramebuffer is an implementation courtesy. An argument could be made that nothing above GL 1.2 should be exported, so that developers like you and I would more quickly ascertain that we are writing invalid code! That'd probably be a bad idea though, because a lot of `in the wild' code is likely to break if we remove all those entry points. Anyway, the only valid way to get glBlitFramebuffer, or any extension really, is to load it dynamically. This is why I recommend GLEW :) I agree with what you said and have planned to use GLEW, this gives me extra motivation to use it ^_^ I guess I am just curious why this one is left out as all the other GL calls we use in our software are included in Mesa's libGL, especially when BlitFramebuffer is just an alias to it. Anyway, thanks a lot. Once we get GLEW going here then I probably won't care much about it. -- Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. -- Download Intel#174; 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-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
