Graphics on Linux is almost exclusively implemented using the X windows system. Supporting OpenGL on Linux involves using GLX extensions to the X Server. There is a standard Application Binary Interface defined for OpenGL on Linux that gives application compatability for OpenGL for a range of drivers. In addition the Direct Rendering Infrastucture (DRI) is a driver framework that allows drivers to be written and interoperate within a standard framework to easily support hardware acceleration, the DRI is included in of XFree86 4.0 but may need a card specific driver to be configured after installation.

+

Graphics on Linux is almost exclusively implemented using the X windows system. Supporting OpenGL on Linux involves using GLX extensions to the X Server. There is a standard Application Binary Interface defined for OpenGL on Linux that gives application compatibility for OpenGL for a range of drivers. In addition the Direct Rendering Infrastructure (DRI) is a driver framework that allows drivers to be written and interoperate within a standard framework to easily support hardware acceleration, the DRI is included in of XFree86 4.0 but may need a card specific driver to be configured after installation.

These days, XFree86 has been rejected in favor of XOrg due to the change in the license of XFree86, so many developers left Xfree86 and joined the XOrg group. Popular Linux distros come with XOrg now. Developers

These days, XFree86 has been rejected in favor of XOrg due to the change in the license of XFree86, so many developers left Xfree86 and joined the XOrg group. Popular Linux distros come with XOrg now. Developers

Line 58:

Line 58:

The first step is to pick your language. Bindings for OpenGL exist in many languages, from C# and Java to Python and Lua. Some languages have multiple sets of OpenGL bindings, none of them being official. All of them are ultimately based on the C/C++ bindings.

The first step is to pick your language. Bindings for OpenGL exist in many languages, from C# and Java to Python and Lua. Some languages have multiple sets of OpenGL bindings, none of them being official. All of them are ultimately based on the C/C++ bindings.

−

If you are not using C/C++, you must download and install a package or library for your choosen language that includes the OpenGL bindings. Some come pre-installed, but others have separate downloads.

+

If you are not using C/C++, you must download and install a package or library for your chosen language that includes the OpenGL bindings. Some come pre-installed, but others have separate downloads.

If you are using C/C++, then you must first set up a build environment (Visual Studio project, GNU makefile, CMake file, etc) that can link to OpenGL. Under Windows, you need to statically link to a library called OpenGL32.lib (note that you still link to OpenGL32.lib if you're building a 64-bit executable. The "32" part is meaningless). Visual Studio, and most Windows compilers, come with this library.

If you are using C/C++, then you must first set up a build environment (Visual Studio project, GNU makefile, CMake file, etc) that can link to OpenGL. Under Windows, you need to statically link to a library called OpenGL32.lib (note that you still link to OpenGL32.lib if you're building a 64-bit executable. The "32" part is meaningless). Visual Studio, and most Windows compilers, come with this library.

Line 84:

Line 84:

In order to use OpenGL, you must get OpenGL API functions. For most libraries you are familiar with, you simply #include a header file, make sure a library is linked into your project or makefile, and it all works. OpenGL doesn't work that way.

In order to use OpenGL, you must get OpenGL API functions. For most libraries you are familiar with, you simply #include a header file, make sure a library is linked into your project or makefile, and it all works. OpenGL doesn't work that way.

−

For reasons that are ultimately irrelevant to this discussion, you must manually load functions via a platform-specific API call. This boilerplate work is done with various [[Extension Loading Library|extension loading libraries]]; these make this process smooth. You are ''strongly'' advised to use one.

+

For reasons that are ultimately irrelevant to this discussion, you must manually load functions via a platform-specific API call. This boilerplate work is done with various [[OpenGL Loading Library|OpenGL loading libraries]]; these make this process smooth. You are ''strongly'' advised to use one.

If you want to do it manually however, there is a [[Load OpenGL Functions|guide as to how to load functions manually]]. You still should use an extension loader.

If you want to do it manually however, there is a [[Load OpenGL Functions|guide as to how to load functions manually]]. You still should use an extension loader.

* [http://www.realtech-vr.com/glview/index.html OpenGL Extension Viewer (Windows, Windows x64 and MacOS X)]: This one comes with a database containing information about what extensions are implemented by hardware other than your own.

* [http://www.realtech-vr.com/glview/index.html OpenGL Extension Viewer (Windows, Windows x64 and MacOS X)]: This one comes with a database containing information about what extensions are implemented by hardware other than your own.

* [http://developer.amd.com/tools/hc/gDEBugger/Pages/default.aspx AMD gDEBugger] - After Graphic Remedy became a subsidiary of AMD in 2011, the new line of gDEBugger was released as a Visual Studio plugin and has since been re-released as a stand-alone application for Windows and Linux.

+

+

{{warning|AMD's version of gDEBugger will not do any OpenCL kernel debugging without AMD hardware installed!}}

== See Also ==

== See Also ==

+

* [[OpenGL Reference]]: All of the OpenGL {{current version}} functions and what they do.

* [[Related toolkits and APIs]]: For utilities that make using OpenGL easier.

* [[Related toolkits and APIs]]: For utilities that make using OpenGL easier.

** [http://gpwiki.org http://gpwiki.org] A Wiki about Game Programming, also has GL code snippets and other APIs

** [http://gpwiki.org http://gpwiki.org] A Wiki about Game Programming, also has GL code snippets and other APIs

[[Category:General OpenGL]]

[[Category:General OpenGL]]

Revision as of 17:25, 15 February 2013

So you want to take advantage of the power of the OpenGL API? If you are visiting this page because a game or software uses the OpenGL API, you need to install the appropriate graphic driver which enables usage of the functionality provided.

To program using the OpenGL API, you need the driver and the development package (depends on platform and programming language). More platform-specific details are described in the sections below.

FAQ

This Wiki maintains a FAQ page for OpenGL. There is an older FAQ available, but information in it is more likely to be out of date.

Downloading OpenGL

In all three major desktop platforms (Linux, MacOS X, and Windows), OpenGL more or less comes with the system. However, you will need to ensure that you have downloaded and installed a recent driver for your graphics hardware.

Without drivers, you will default to a software version of OpenGL 1.1 (on Win98, ME, and 2000), a Direct3D wrapper that supports OpenGL 1.1 (WinXP), or a Direct3D wrapper that supports OpenGL 1.1 (Windows Vista and Windows 7). None of these options are particularly fast, so installing drivers is always a good idea.

Linux

Graphics on Linux is almost exclusively implemented using the X windows system. Supporting OpenGL on Linux involves using GLX extensions to the X Server. There is a standard Application Binary Interface defined for OpenGL on Linux that gives application compatibility for OpenGL for a range of drivers. In addition the Direct Rendering Infrastructure (DRI) is a driver framework that allows drivers to be written and interoperate within a standard framework to easily support hardware acceleration, the DRI is included in of XFree86 4.0 but may need a card specific driver to be configured after installation.
These days, XFree86 has been rejected in favor of XOrg due to the change in the license of XFree86, so many developers left Xfree86 and joined the XOrg group. Popular Linux distros come with XOrg now. Developers

Vendors have different approaches to drivers on Linux, some support Open Source efforts using the DRI, and others support closed source frameworks but all methods support the standard ABI that will allow correctly written OpenGL applications to run on Linux.

Linux comes with Mesa libraries, which implements the OpenGL API as a software rasterizer. Most Linux distros don't come with hardware acceleration. Some Linux distributions may include support for hardware acceleration. Also, some GPUs have Open Source drivers developed by the community even though a close source driver may be available from the manufacturer.

Mac OS X

Unlike other platforms, where the Operating System and OpenGL implementations are often updated separately, OpenGL updates are included as part of Mac OS X system updates. To obtain the latest OpenGL on Mac OS X, users should upgrade to the latest OS release, which can be found at Apple.com.

For developers, a default installation of Mac OS X does not include any OpenGL headers, nor does it include other necessary development tools. These are installed by a separate developer tools package called Xcode. This installer includes the OpenGL headers, compilers (gcc), debuggers (gdb), Apple's Xcode IDE, and a number of performance tools useful for OpenGL application development.

Writing an OpenGL Application

The first step is to pick your language. Bindings for OpenGL exist in many languages, from C# and Java to Python and Lua. Some languages have multiple sets of OpenGL bindings, none of them being official. All of them are ultimately based on the C/C++ bindings.

If you are not using C/C++, you must download and install a package or library for your chosen language that includes the OpenGL bindings. Some come pre-installed, but others have separate downloads.

If you are using C/C++, then you must first set up a build environment (Visual Studio project, GNU makefile, CMake file, etc) that can link to OpenGL. Under Windows, you need to statically link to a library called OpenGL32.lib (note that you still link to OpenGL32.lib if you're building a 64-bit executable. The "32" part is meaningless). Visual Studio, and most Windows compilers, come with this library.

On Linux, you need to link to libGL. This is done with a command-line parameter of "-lGL".

Initialization

Before you can actually use OpenGL in a program, you must first initialize it. Because OpenGL is platform-independent, there is not a standard way to initialize OpenGL; each platform handles it differently. Non-C/C++ language bindings can also handle these differently.

There are two phases of OpenGL initialization. The first phase is the creation of an OpenGL context; the second phase is to load all of the necessary functions to use OpenGL. Some non-C/C++ language bindings merge these into one.

OpenGL Context Creation

An OpenGL context represents all of OpenGL. Creating one is very platform-specific, as well as language-binding specific.

If you are using the C/C++ language binding for OpenGL, then you are strongly advised to use a window toolkit for managing this task. These libraries create a window, attach an OpenGL context to this window, and manage basic input for that window. Once you are comfortable with OpenGL, you can then start learning how to do this manually.

Most non-C/C++ language bindings will provide you with a language-specific mechanism for creating a context.

Getting Functions

If you are using a non-C/C++ language binding, then the maintainer of that binding will already handle this as part of context creation. If you are using C/C++, read on.

In order to use OpenGL, you must get OpenGL API functions. For most libraries you are familiar with, you simply #include a header file, make sure a library is linked into your project or makefile, and it all works. OpenGL doesn't work that way.

For reasons that are ultimately irrelevant to this discussion, you must manually load functions via a platform-specific API call. This boilerplate work is done with various OpenGL loading libraries; these make this process smooth. You are strongly advised to use one.

Using OpenGL

OpenGL is a rendering library. What OpenGL does not do is retain information about an "object". All OpenGL sees is a ball of triangles and a bag of state with which to render them. It does not remember that you drew a line in one location and a sphere in another.

Because of that, the general way to use OpenGL is to draw everything you need to draw, then show this image with a platform-dependent buffer swapping command. If you need to update the image, you draw everything again, even if you only need to update part of the image. If you want to animate objects moving on the screen, you need a loop that constantly clears and redraws the screen.

There are techniques for only updating a portion of the screen. And you can use OpenGL with these techniques. But OpenGL itself doesn't do it internally; you must remember where you drew everything. You must figure out what needs updating and clear only that part of the screen. And so forth.

OpenGL Viewers

These are programs that you install and run, and they give you information specific to the OpenGL API your system implements, like the version offered by your system, the vendor, the renderer, the extension list, supported viewport size, line size, point size, plus many other details. Some might include a benchmark. Some are standalone benchmarks.

Development Tools

AMD gDEBugger - After Graphic Remedy became a subsidiary of AMD in 2011, the new line of gDEBugger was released as a Visual Studio plugin and has since been re-released as a stand-alone application for Windows and Linux.

Warning: AMD's version of gDEBugger will not do any OpenCL kernel debugging without AMD hardware installed!