-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Svilen wrote:
> 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
You set a valid context by calling glXMakeCurrent,
glXMakeCurrentReadSGIS, or glXMakeContextCurrent.
> 2. You call glXGetProcedureAddress to get the valid existing entry
> points to the openGL procedures for the context you obtained in p.1
glXGetProcAddress is called to get entry points. The entry points may
not be valid. Calling 'glXGetProcAddress("Hello, world!")' will return
an entry point, but it will not be valid. To know which entry points
are valid, you have to check the GL version (by calling
glGetString(GL_VERSION)) and / or the GL extension string (by calling
glGetString(GL_EXTENSIONS)). GLEW does the glXGetProcAddress for you.
GLEW also checks the version and the extension string and uses these to
set variables (i.e., GLEW_ARB_vertex_buffer_object) that can be tested.
> 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 :)
That glGenBuffersARB and glGenBuffers are the same is an artifact of how
Mesa (and many GL implementations) implement them. To be clear: I
don't think this application should crash when calling glGenBuffers on
this driver. I think something else (possibly an invalid context) is
happening.
>>> 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.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iEYEARECAAYFAksZiA4ACgkQX1gOwKyEAw8KrQCgngFGInFm3tYmCfgnbDsGTzmK
/N0AmwVWa4QdshZ3P3YwfAUMFq2JXKeL
=An5y
-----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
