-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Svilen wrote:
> I was also a bit confused by the glewinfo report that the driver
> supports both glGenBuffers and glGenBuffersARB. It seems logical those
> two entry points to end-up with the same function. Besides (again from
> the glewinfo report) it seems strange that all openGL 1.5 functions are
> supported yet the driver is declared to support openGL 1.4 only.
In GLX using Mesa's libGL, *ALL* functions "exist". If you call
'glXGetProcAddress("I like ham sandwiches");' it will gladly return a
non-NULL function pointer. Seriously. The dispatch table will have
NULL for that function, so calling the returned function will crash your
application.
It *has to* be implemented this way. glXGetProcAddress can be called
before there's a context bound. Until there's a context bound libGL has
no way to know what functions the driver may export. Since libGL can
load arbitrary drivers, the driver could export anything.
In Mesa-based drivers, if you call glXGetProcAddress on any function
that is supported by at least one Mesa driver, including the software
rasterizer, it will probably even have something in the dispatch table.
> In an attempt to come up with the fix I've knocked on a couple of doors
> including GLEW. Here is the link
>
> http://sourceforge.net/mailarchive/forum.php?thread_name=4B1736EF.2080504%40nvidia.com&forum_name=glew-users
>
> The trouble is that I can't figure-out a clear diagnostic strategy that
> will work on this particular platform (with 945GM) also, because GLEW
> reports that the function exists i.e. it looks safe to be called.
Follow the OpenGL spec! If your driver does not say that it supports
OpenGL 1.5, do not call functions that only exist in OpenGL 1.5.
The usual way to handle this for functions that get promoted to the core
is via a wrapper. In your context init function, do something like:
glewInit();
if (GLEW_VERSION_1_5) {
real_GenBuffers = GLEW_GET_FUN(__glewGenBuffers);
} else if (GLEW_ARB_vertex_buffer_object) {
real_GenBuffers = (PFNGLGENBUFFERSPROC)
GLEW_GET_FUN(__glewGenBuffers);
}
Then make a wrapper around glew.h that does:
#include <GL/glew.h>
extern PFNGLGENBUFFERSPROC real_GenBuffers;
/* Could also #undef glGenBuffers and define this as glGenBuffers
*/
#define GenBuffers(n, bufs) (*real_GenBuffers)(n, bufs)
It's a big hassle, but it's the only way to support both the extension
version and the core version in a portable manner.
Since GLEW actually provides these as wrappers, you may be able to do
the following instead:
glewInit();
if (!GLEW_VERSION_1_5 && GLEW_ARB_vertex_buffer_object) {
GLEW_GET_FUN(__glewGenBuffers) = (PFNGLGENBUFFERSPROC)
GLEW_GET_FUN(__glewGenBuffersARB);
}
I'd ping the GLEW maintainers before trying that, though.
Also note that all of these tricks need to be done for all of the
extension functions, not just for glGenBuffers.
> It was another suggestion in the GLEW thread - that the graphic context
> might be invalid. The application does have checks for this, but I'll
> try to reconfirm with the user that this is not the case.
This is easy enough to test. Run the app in a debugger. When it
faults, call glXGetCurrentContext. If it returns NULL, there's no
context bound in the current thread.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iEYEARECAAYFAksYKz4ACgkQX1gOwKyEAw/cpQCgk1/Y6OEedAoK/vpWC0nNSjWO
XCUAn3tTJlyZrkPxx62Pl+lgu99SZaET
=fweu
-----END PGP SIGNATURE-----
------------------------------------------------------------------------------
Join us December 9, 2009 for the Red Hat Virtual Experience,
a free event focused on virtualization and cloud computing.
Attend in-depth sessions from your desk. Your couch. Anywhere.
http://p.sf.net/sfu/redhat-sfdev2dev
--
_______________________________________________
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel
