X11 forwarding and OpenGL extensions

I’ve got an 8-core Linux server that I’d like to run an OpenGL program on. The trouble is, it uses some advanced extensions like EXT_framebuffer_object.

I have the DISPLAY variable set to my local Windows machine, which has two GPUs and definitely supports all required extensions. When I print out glGetString(GL_EXTENSIONS) on a locally run program, I get lots.

But when I print out glGetString(GL_EXTENSIONS) on a program run on the server, I get a more limited list. This is despite the fact that if I change my DISPLAY variable, then I get nothing from the server----it’s clearly getting something from my local graphics card.

I don’t have a good enough grasps of X11 forwarding (I’m running Xwin32 9.1 on my Windows machine) and that sort of thing to know exactly what the problem is…any help?

When I print out glGetString(GL_VERSION) on a locally-run program, I get “2.1.2”.

If I print it out on the server, I get “1.2 (2.1.2)”.

Does this mean that the server’s OpenGL driver isn’t as advanced as my local one, and it simply doesn’t know how to forward the extension functions?

A server is unlikely to have a good hardware acceleration, unless it is specifically build for it.
And trying to use your local video card from a remote program running on the server… seem unlikely to provide performance. Maybe Chromium may help :
http://en.wikipedia.org/wiki/Chromium_%28computer_graphics%29

And my knowledge, the only way to have remote display + hardware acceleration is to use VirtualGL :
http://www.virtualgl.org/

What does the following command say, when run on the remote server ?
glxinfo | grep OpenGL

It actually doesn’t have a GPU at all.

And trying to use your local video card from a remote program running on the server… seem unlikely to provide performance.

I don’t care about performance right now, I just want it to work.

Maybe Chromium may help :
http://en.wikipedia.org/wiki/Chromium_%28computer_graphics%29

Looks interesting, but too much of a dependency to add to my current project. I’m using OpenGL as a drawing crutch in this case----performance isn’t the point. I’d be fine with a software implementation, even, so long as it did the right thing.

What does the following command say, when run on the remote server ?
glxinfo | grep OpenGL

OpenGL vendor string: NVIDIA Corporation
OpenGL renderer string: Quadro FX 4500/PCI/SSE2
OpenGL version string: 1.2 (2.1.2)
OpenGL extensions:
GL_ARB_depth_texture, GL_ARB_imaging, GL_ARB_multitexture,
GL_ARB_point_parameters, GL_ARB_point_sprite, GL_ARB_shadow,
GL_ARB_texture_border_clamp, GL_ARB_texture_cube_map,
GL_ARB_texture_env_add, GL_ARB_texture_env_combine,
GL_ARB_texture_env_dot3, GL_ARB_texture_mirrored_repeat,
GL_ARB_texture_rectangle, GL_ARB_transpose_matrix, GL_ARB_window_pos,
GL_EXT_abgr, GL_EXT_bgra, GL_EXT_blend_color, GL_EXT_blend_func_separate,
GL_EXT_blend_minmax, GL_EXT_blend_subtract, GL_EXT_draw_range_elements,
GL_EXT_fog_coord, GL_EXT_multi_draw_arrays, GL_EXT_packed_pixels,
GL_EXT_point_parameters, GL_EXT_rescale_normal, GL_EXT_secondary_color,
GL_EXT_separate_specular_color, GL_EXT_shadow_funcs,
GL_EXT_stencil_two_side, GL_EXT_stencil_wrap, GL_EXT_texture3D,
GL_EXT_texture_edge_clamp, GL_EXT_texture_env_add,
GL_EXT_texture_env_combine, GL_EXT_texture_env_dot3, GL_EXT_texture_lod,
GL_EXT_texture_lod_bias, GL_EXT_texture_object, GL_EXT_texture_rectangle,
GL_EXT_vertex_array, GL_ATI_texture_mirror_once,
GL_IBM_texture_mirrored_repeat, GL_INGR_blend_func_separate,
GL_NV_blend_square, GL_NV_point_sprite, GL_NV_texgen_reflection,
GL_NV_texture_rectangle, GL_SGIS_generate_mipmap,
GL_SGIS_texture_border_clamp, GL_SGIS_texture_edge_clamp,
GL_SGIS_texture_lod, GL_SGIX_depth_texture, GL_SGIX_shadow,
GL_SUN_multi_draw_arrays

That’s one of the two GPUs from my host Windows machine. Some extensions are getting through, but not all of the ones I get when I print out glGetString(GL_EXTENSIONS) locally. And not the one I need.

After reading up it seems that the libGL I have on the server comes from Mesa 6.5.1. Apparently EXT_framebuffer_object was introduced in Mesa 6.5.2, so maybe I just have to upgrade that and it’ll start working…

“OpenGL extensions:” seem to be empty because of the single line grep, try glxinfo directly for the full list.

The mesa upgrade is the best thing to do now.

When X forwarding is enabled, all OpenGL commands are sent to the client machine and rendered locally. VirtualGL seems to solve this problem.

VirtualGL is nice to know about, but it does the opposite of what I need in this case.