Bug 10215

I don't quite see what's wrong, but this is not radeon specific. It seems glew completely fails to get the function pointers for those opengl functions (it should use something like glGenBuffers = glXGetProcAddress("glGenBuffers") internally), thus you're calling a function at location 0.

It appears that the proper call is made only when a driver claims to support gl version 1.5 or greater, and radeon claims to support 1.3.

Setting glewExperimental=GL_TRUE solves that part of the problem, but we seem to get more problems than we fixed.  A bunch of

Mesa 6.5.1 implementation error: User called no-op dispatch function (an unsupported extension function?)

errors, followed by a segfault :/.

<...>
Mesa 6.5.1 implementation error: User called no-op dispatch function (an unsupported extension function?)
Please report at bugzilla.freedesktop.org

Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread -1213884736 (LWP 3855)]
0xb79bb8f3 in _tnl_DrawElements () from /usr/lib/dri/radeon_dri.so
(gdb) bt
#0  0xb79bb8f3 in _tnl_DrawElements () from /usr/lib/dri/radeon_dri.so
#1  0xb78e8550 in ?? () from /usr/lib/dri/radeon_dri.so
#2  0x00000004 in ?? ()
#3  0x00000006 in ?? ()
#4  0x00001405 in ?? ()
#5  0x00000000 in ?? ()
(gdb) 

Patch to the example code, in case anyone is interested:

diff -Naur VBODemo/VBODemo.cpp VBODemo_new/VBODemo.cpp
--- VBODemo/VBODemo.cpp 2007-03-05 19:21:37.000000000 -0700
+++ VBODemo_new/VBODemo.cpp     2007-03-07 20:35:06.000000000 -0700
@@ -17,6 +17,9 @@
 
        //
        // Prolly need some error check to see if initialization happened
+
+       glewExperimental = GL_TRUE;
+
        GLenum initStatus = glewInit();
 
        if( initStatus != GLEW_OK )

(In reply to comment #2)
> It appears that the proper call is made only when a driver claims to support gl
> version 1.5 or greater, and radeon claims to support 1.3.
> 
> Setting glewExperimental=GL_TRUE solves that part of the problem, but we seem
> to get more problems than we fixed.  A bunch of
This looks like a major bug of glew to me then. According to the documentation, setting glewExperimental to true will then expose all extensions for which entry points are found - well the standard libGL will expose entry points for any and all possible extensions if you ask it to provide them, so that's probably not what you want to do... And anyway that's certainly not something which should be needed, this extension is supported, so glew just has to get the entry point no matter what the core version reported is.

> Mesa 6.5.1 implementation error: User called no-op dispatch function (an
> unsupported extension function?)
> 
> errors, followed by a segfault :/.
> 
> <...>
> Mesa 6.5.1 implementation error: User called no-op dispatch function (an
> unsupported extension function?)
> Please report at bugzilla.freedesktop.org
Not sure, but this can happen if you have non-matched libGL and dri drivers, there were some incompatible changes some time back.

(In reply to comment #3)
> > Mesa 6.5.1 implementation error: User called no-op dispatch function (an
> > unsupported extension function?)
> 
> Not sure, but this can happen if you have non-matched libGL and dri drivers,
> there were some incompatible changes some time back.

I think this can also happen when calling entrypoints of unsupported extensions.

In summary, there only seem to be bugs in glew here, closing.

(In reply to comment #4)
> (In reply to comment #3)
> > > Mesa 6.5.1 implementation error: User called no-op dispatch function (an
> > > unsupported extension function?)
> > 
> > Not sure, but this can happen if you have non-matched libGL and dri drivers,
> > there were some incompatible changes some time back.
> 
> I think this can also happen when calling entrypoints of unsupported
> extensions.
> 
> In summary, there only seem to be bugs in glew here, closing.
True, but no matter how buggy glew is I don't think it would call entry points on its own. And the test app doesn't seem to neither (though I don't know why that stuff for color index rendering is there).

Actually, a closer looks shows the radeon driver does not claim to support GL_ARB_vertex_buffer_object, which would be exactly the reason you'd get those errors. Or does this really show up in glxinfo, this would be a bug.
(That said, it should be dead easy to add VBO support to the driver, not optimal in terms of performance but working, same as for r200.)

Looking at glxinfo. it seems that the driver does not claim to support VBOs. :(

Glew has a similar program that claimed it was at least partially there; maybe they are expecting to get a NULL pointer back if the function isn't supported.

Sorry for wasting your time.

Where can I find out which cards the driver has GL_ARB_vertex_buffer_object support for?

Created attachment 9041 [details] [review]
patch to enable ARB_vbo

(In reply to comment #6)
> Looking at glxinfo. it seems that the driver does not claim to support VBOs. :(
> 
> Glew has a similar program that claimed it was at least partially there; maybe
> they are expecting to get a NULL pointer back if the function isn't supported.
Yes, that's possible. I think glewinfo will just report it as somewhere between OK and MISSING if it gets entry points for the functions (though I wonder why it fails to get entry points for some of the extensions, it should in fact get entry points for _anything_, I guess that's a glewinfo bug). Do not rely on that. If the extension is not in the extension string, it is not supported.

> Where can I find out which cards the driver has GL_ARB_vertex_buffer_object
> support for?
I'd guess this page 
http://dri.freedesktop.org/wiki/FeatureMatrix would be useful, except it's too old and doesn't list any newer extensions. Anyway, if you really need it for radeon, try the small patch, unless I'm missing something VBOs should just work with radeon if enabled (don't expect any performance miracles, as they won't get buffered on-card or anything, but should be good enough to work). Patch against mesa git, should apply to somewhat older versions too I guess.

Thank you very much.  The patch worked against the debian sources, so I should be able to get my homework done (even if it does turn out to be slow).