How to setup OpenGL under Linux?

What do I need, when I have to do a simple OpenGL application under Ubuntu? g++ is already installed. I guess I need 2 things:

  1. Headers
  2. Runtime libraries to link the executable against

The headers should come with X11. Perhaps you have to install the X11-devel or the mesa-devel package, I don’t know if Ubuntu has the headers in seperate packages.

The runtime libraries should also come with the X11 installation. To get best performance, you should install the driver for your graphic card. If it’s a nvidia card, just go to their homepage, download the driver and run the installer. I don’t know about ati, but I guess it’s not much harder.

If you want to use extensions, you should get the newest glext.h from the extension registry (linked somewhere on this site).

In addition to that, while not strictly needed, SDL or glut (or freeglut) will make development of a simple OpenGL application a lot easier. Again, make sure you install both the normal and the devel package so you get libraries and headers.

To determine if you have everything you need, try the following:

  • run “glxgears” to check for the runtime libraries
  • run “glxinfo” to check the driver installation, opengl version, extension support, …
  • search for “gl.h” (should be in /usr/include/GL or /usr/X11R6/include/GL or something similar)

Overmind, without installing anything I just type glxgear and a window with some machinery appeared. The weels were rotating too slowly - perhaps I need some driver for my videocard?
When I run glxinfo I got:

name of display: :0.0
display: :0 screen: 0
direct rendering: No
server glx vendor string: SGI
server glx version string: 1.2
server glx extensions:
GLX_ARB_multisample, GLX_EXT_visual_info, GLX_EXT_visual_rating,
GLX_EXT_import_context, GLX_OML_swap_method, GLX_SGI_make_current_read,
GLX_SGIS_multisample, GLX_SGIX_fbconfig
client glx vendor string: SGI
client glx version string: 1.4
client glx extensions:
GLX_ARB_get_proc_address, GLX_ARB_multisample, GLX_EXT_import_context,
GLX_EXT_visual_info, GLX_EXT_visual_rating, GLX_MESA_allocate_memory,
GLX_MESA_swap_control, GLX_MESA_swap_frame_usage, GLX_OML_swap_method,
GLX_OML_sync_control, GLX_SGI_make_current_read, GLX_SGI_swap_control,
GLX_SGI_video_sync, GLX_SGIS_multisample, GLX_SGIX_fbconfig,
GLX_SGIX_pbuffer, GLX_SGIX_visual_select_group
GLX version: 1.2
GLX extensions:
GLX_ARB_get_proc_address, GLX_ARB_multisample, GLX_EXT_import_context,
GLX_EXT_visual_info, GLX_EXT_visual_rating, GLX_OML_swap_method,
GLX_SGI_make_current_read, GLX_SGIS_multisample, GLX_SGIX_fbconfig,
OpenGL vendor string: Mesa project:
OpenGL renderer string: Mesa GLX Indirect
OpenGL version string: 1.2 (1.5 Mesa 6.2.1)
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_shadow_ambient, GL_ARB_texture_border_clamp,
GL_ARB_texture_cube_map, GL_ARB_texture_env_add,
GL_ARB_texture_env_combine, GL_ARB_texture_env_crossbar,
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_logic_op, GL_EXT_blend_minmax, GL_EXT_blend_subtract,
GL_EXT_clip_volume_hint, GL_EXT_copy_texture, GL_EXT_draw_range_elements,
GL_EXT_fog_coord, GL_EXT_multi_draw_arrays, GL_EXT_packed_pixels,
GL_EXT_point_parameters, GL_EXT_polygon_offset, 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_subtexture, GL_EXT_texture, 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_bias, GL_EXT_texture_object, GL_EXT_texture_rectangle,
GL_EXT_vertex_array, GL_APPLE_packed_pixels, GL_ATI_texture_env_combine3,
GL_ATI_texture_mirror_once, GL_ATIX_texture_env_combine3,
GL_IBM_texture_mirrored_repeat, GL_INGR_blend_func_separate,
GL_MESA_pack_invert, GL_MESA_ycbcr_texture, 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_SGIX_shadow_ambient, GL_SUN_multi_draw_arrays
glu version: 1.3
glu extensions:
GLU_EXT_nurbs_tessellator, GLU_EXT_object_space_tess

visual x bf lv rg d st colorbuffer ax dp st accumbuffer ms cav
id dep cl sp sz l ci b ro r g b a bf th cl r g b a ns b eat

0x23 24 tc 0 24 0 r y . 8 8 8 0 0 16 0 0 0 0 0 0 0 None
0x24 24 tc 0 24 0 r y . 8 8 8 0 0 16 8 16 16 16 0 0 0 None
0x25 24 tc 0 32 0 r y . 8 8 8 8 0 16 8 16 16 16 16 0 0 None
0x26 24 tc 0 32 0 r . . 8 8 8 8 0 16 8 16 16 16 16 0 0 None
0x27 24 dc 0 24 0 r y . 8 8 8 0 0 16 0 0 0 0 0 0 0 None
0x28 24 dc 0 24 0 r y . 8 8 8 0 0 16 8 16 16 16 0 0 0 None
0x29 24 dc 0 32 0 r y . 8 8 8 8 0 16 8 16 16 16 16 0 0 None
0x2a 24 dc 0 32 0 r . . 8 8 8 8 0 16 8 16 16 16 16 0 0 None

I am thinking of using MESA. Is it easy to program with it?

Mesa is generally not hardware accelerating (glxgears just proves it here).

If you have an Nvidia card, then download and install the proprietary drivers, read carefuly all the ‘long’ readme text before.

If you have an ATI card, it depends, but generally using the proprietary drivers could help (try to see the other posts here).

If you have an old voodooo card, the drivers are free and are called glide and are providen on all distributions generally.

For other cards, I don’t know.

Programming using Mesa is just like programming with GL, that turns out. Also, if you don’t plan to install drivers, then check to enable direct rendering (check other posts for more information about this).

Hope that helps.

Thanks, I think GLUT is OK for me, at least it works! :slight_smile:
But I noticed that the main glut loop-function blocks every other part of my program - the i/o and the programming logic. Is there a way to separate the (re)drawing from the man part of the programm?

When programming for graphic systems, you have to structure your program differently than for a simple console application.

The main event loop is always the “main part” of your program. In case of glut, that’s the glutMainLoop function. With other systems like SDL can write the main loop yourself, but the principle is the same.

If you need additional pragramming logic, you have to write it in some event handler function. There is also glutIdleFunc that gets called on every iteration of the event loop when no other event is there…

An alternative is to use a background thread for your programming logic, but that doesn’t really make things easier, because then you have to worry about thread synchronisation.

Just end your main loop function (the one pointed by glutDisplayFunc) with a glutPostRedisplay() call and after glutSwapBuffers().

I feel truly sorry, but I cannot get the idea. What is my purpose:

  1. The user enters a command in the console
  2. A window appears and some stuff depending on the arguments from the input are drawn
  3. After the drawing is finished the user is able to input another command and so on.
    As you can see, it is a simple task. Of course I would also like to “pause” the drawing process, I mean, there must be a way to separate and control the graphic?

Originally posted by Zdravko:
Of course I would also like to “pause” the drawing process, I mean, there must be a way to separate and control the graphic?
This way is not using GLUT as GLUT forces you to use its main loop.
For creating your own rendering context look at, there are lots of tutorials.

And btw if you have an NVIDIA card the package to install is called nvidia-glx and I think it is in the universe repository.

Ok, I see. I am thinking of using a simpler graphic API. OpenGL is a bit too much complex and C-like. Perhaps grx is better?
And yes - I managed the videocard problem. Everything is working fine now.

  1. The user enters a command in the console
  2. A window appears and some stuff depending on the arguments from the input are drawn
  3. After the drawing is finished the user is able to input another command and so on.

In general, you can’t write a GUI application that way, because you have to listen for redraw events at all times. Otherwise your window would not be correctly redrawn if some region if it is exposed while your program reads from the console.

This problem can either be solved with threads, by having a seperate thread for drawing and for input. Or you could use some GUI element for input instead of the console.

I don’t know the grx library, from the documentation it looks like programming with it is simpler than with OpenGL, but it will only draw to the framebuffer, so it won’t work with X11, you have no window management, no hardware acceleration, …

I think you should really have a look at general GUI programming, before attempting graphics programming. The event driven architecture is quite different from the linear program flow of command line programs.

EDIT: Looks like actually it can be used on X11, so I guess it automatically makes a background thread for you. But you still have no 3D, and no hardware acceleration.

To setup nvidia driver on ubuntu you have to do two things. First: sudo apt-get install nvidia-glx Second: sudo nvidia-glx-config enable it change your xorg.conf to use nvidia driver.

I used Xlib+OpenGL programming, it’s in the lowest level and it is good. But it has a dirty start and assumes you know something about Xlib. So if you don’t want to get your hands dirty, try GLUT or SDL.

If you want to start using opengl and sdl you can go to this page that I’ve setup for a class.

I also have how to setup GLSL and get handles to the extensions.

This topic was automatically closed 183 days after the last reply. New replies are no longer allowed.