On 12/03/2009 09:18 PM, Ian Romanick 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.
>
>
I'm a bit confused here, but it must be because of *has to* *can be*
etc. English is not my mother language either. Lets try to clarfy and
please correct me if I'm wrong:
1. You get the valid context
2. You call glXGetProcedureAddress to get the valid existing entry
points to the openGL procedures for the context you obtained in p.1
That's the way it must be done, otherwise you'll get a non-NULL pointer
to "I like ham sandwiches" which will serve you one :)
This way it makes sense to me and this is the way it's implemented
(well, using glew actually). If you have a look even at the glewinfo
report in bugzilla - it says at the top precisely to which context the
report is related.
>> 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.
>
>
Thanks for the tips. I was trying to avoid this kind of things as much
as possible in my code - that's why I'm using glew. It is serving me
well, although it looks like you have a point. It might still need an
additional wrappers for possible ARB function calls. As they confirmed -
they are not wrapping ARB functions as I initially though. I'll
certainly ask them what would be the best way to abstract them out.
My initial point was that having a report that both glGenBuffers and
glGenBufferARB are defined, you might be confused which one to call. Are
they the same thing? As it appears - they are, but that's different
story. On top of this - the fact that the call to one of them is
crashing your application doesn't make the problem smaller actually :)
>> 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.
>
I posted your suggestion to the user.
Thanks!
Svilen
------------------------------------------------------------------------------
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
