On a Linux machine, I can see the ARB_color_buffer_float extension in the list of supported extensions if I open the NVIDIA X Server Settings program. However, if I run glxinfo from a console (or any program creating an OpenGL context), this extension and several others are missing.
:0, :0.0, unix:0 (or select others if you know what you’re doing)
In other words, verify your shell is local, is pointing at the local machine’s X server, and the connection supports direct rendering. That should be as good as you can get.
Alternatively, if you’re doing remote X/GL via GLX protocol (ssh -X, pointing $DISPLAY at another desktop, etc.), then it’s possible that the local or remote X/GLX implementation doesn’t support this extension, either directly, or it just doesn’t know how to serialize/deserialize the calls to/from GLX protocol on one side or the other (driver too old).
Here on my local box (GTX285), I get:
direct rendering: Yes
OpenGL version string: 3.3.0 NVIDIA 260.19.29
GL_ARB_compatibility, GL_ARB_copy_buffer, GL_ARB_depth_buffer_float,
though if I ssh -X into a remote box with older NVidia drivers (173.14.18), I get:
direct rendering: No
OpenGL version string: 2.1.2 NVIDIA 260.19.29
GL_ARB_color_buffer_float, GL_ARB_depth_texture, GL_ARB_fragment_program,
So while it appears color_buffer_float is still supported over GLX protocol with this client/server combination, there are a number of extensions that were supported locally that are now not supported remotely.
Also, I’m frankly not sure whether the GLX line protocol serialization code being used is in the NVidia driver or in an Xorg library being used. I really haven’t done any serious remote GL work in years. My guess is in the NVidia driver, but I don’t know for sure. Language in the NVidia README seems to support this assertion.
Further developments: Turns out that glxinfo reports the correct extensions in csh, but not in bash (nor in csh run within bash)! Any idea what could cause bash to block a particular set of extensions?