Ian,
Thanks again. It seems that we agree on the initialization sequence, but
there are still some details - see below.
On 12/04/2009 10:07 PM, Ian Romanick wrote:
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.
Are you saying that if I didn't check explicitly for
****GL_ARB_vertex_buffer_object**** i.e. (in glew)
**glewIsSupported("GL_ARB_vertex_buffer_object")**
then calling glGenBuffersARB is likely to crash provided that it is
there? I'm not arguing that this is a good coding practice - it's just a
question.
or - the other possibility - I definitely have to call
**glewIsSupported("GL_VERSION_1_5")
**
before using glGenBuffers() ? Even if driver supports GL version (say) 2.0?
Again - I'm not arguing that this is the way it should be coded. I'm
just trying to clarify why in this particular case it is crashing and
does it have something to do with the driver.
My impression was that all this stuff is done during glewInit() and
glewIsSupported is there to help you making you code portable.
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.
Well - the invalid context is ruled out. See my previous post. The
context is certainly valid.
The question then remains - why the call to glGenBuffers is dereferenced
as a NULL pointer?
I'm working on a fix and will take into account your tips and
suggestions, but the impression is that in spite of all that and with
perfect diagnostic code (using glew) - it will crash again on this
particular platform. And it will be certainly embarrassing.
I think the best thing to do is to run the application on your platform
(whoever maintains the driver). I believe the hardware is available
provided that you're maintaining its driver. Then the crash can be
recreated. It's easy to install Toped - it is in Fedora repositories, so
yum install toped
should be enough.
Is that possible?
Regards
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
