CPU-GPU Cooperation

The architecture of OpenGL is based on a client-server model. An application program written to use the OpenGL API is the "client" and runs on the CPU. The implementation of the OpenGL graphics engine (including the GLSL shader programs you will write) is the "server" and runs on the GPU. Geometry and many other types of attributes are stored in buffers called Vertx Buffer Objects (or VBOs). These buffers are allocated on the GPU and filled by your CPU program. We will get our first glimpse into this process (inlcuding how these buffers are allocated, used, and deleted) in the first sample program we will study.

Modeling, rendering, and interaction is very much a cooperative process between the CPU client program and the GPU server programs written in GLSL. An important part of the design process is to decide how best to divide the work and how best to package and communicate required information from the CPU to the GPU. There is no standard "best way" to do this that is applicable to all programs, but we will study a few very common approaches.

Window Manager Interfaces

OpenGL is a pure output-oriented modeling and rendering API. It has no facilities for creating and managing windows, obtaining runtime events, or any other such window system dependent operation. OpenGL implicitly assumes a window-system interface that fills these needs and invokes user-written event handlers as appropriate.

It is beyond the scope of these notes to list, let alone compare and contrast, all window manager interfaces that can be used with OpenGL. (If you are interested in learning about alternatives, begin your search at opengl.org.) Two very common window system interfaces are:

GLFW: Runs on Linux, Macintosh, and Windows. For Macintosh developers wishing to use the shader-based OpenGL programs on this site, you must be running OSX 10.9 (Mavericks) or a later OS. You must also be using a window manager interface that – like GLFW – actually supports the latest OpenGL releases.

Software and complete documentation are available on the GLFW web site.

While the Makefiles in the sample program and project directories are designed to be easily tweaked for Macintosh versus linux, most of the utility directories on this web site have a separate Makefile for the Macintosh called MakefileMac. See this README file for general notes on compiling and running on the Mac.

GLUT (actually freeglut): A window interface that used to be the most common one used when teaching OpenGL. It, too, runs on Linux, Macintosh, and Windows. However (as of late May 2014), it does not allow Macintosh programmers (regardless of OS version) to create an OpenGL Rendering Context greater than 2.1.

Software and complete documentation are available on the GLUT web site. Included in the documentation are several groups of functions that require deprecated OpenGL functions, hence will not work in our framework:

  • Anything in section 10 "Menu Functions"
  • Anything in section 14 "Font Rendering Functions"
  • Anything in section 15 "Geometric Object Rendering Functions"

Putting it Together

High-level overview of an OpenGL program: This diagram shows the high-level structure of a typical OpenGL program.

What's Next?

On the next page (Course Goals), you will read about the Model-View-Controller design pattern we will use in this course. The window manager interface is wrapped by the abstract base class Controller. The sample programs on this web site are all configured to use the concrete Controller subclass called GLFWController.

We will simply use the term Controller in the pages on this site, unless it is important for some reason to specify an exact concrete Controller subclass.