-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Svilen wrote:
> 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.
It is entirely possible. That probably won't happen with
GL_ARB_vertex_buffer_object, but it may with other extensions
(especially ones that changed a lot when they went into core).
> 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.
That's totally different. GL versions, up to version 3.1, are backwards
compatible. If it's in version N, it's in version N+1.
> 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 should be able to look at it this weekend. I'll see if I can
reproduce it here.
> 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?
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iEYEARECAAYFAksZ658ACgkQX1gOwKyEAw/xJwCfVMsYP8w/4Tz7fzQlTNUPpJWQ
8c0AnAxLznRUDcHr5npGEb9AKxOLDEQ0
=KpPO
-----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
