Difference between revisions of "Getting Started"

From OpenGL Wiki
Jump to: navigation, search
(Linux)
(Linux)
Line 103: Line 103:
  
 
https://packages.debian.org/sid/amd64/libgl1-mesa-dri/filelist
 
https://packages.debian.org/sid/amd64/libgl1-mesa-dri/filelist
 +
 +
 +
====OpenGL ABI (Headers, Datatypes, Libraries)====
 +
 +
* ABI (Application Binary Interface) and runtime environment for applications using OpenGL under X11 on Linux enable applications using the OpenGL API for rendering to run on a variety of underlying implementations transparently. The intent is to address all of open source, commercial closed binary, OpenGL SI-based, and Mesa-based implementations.
 +
 +
* SDK for developing apps using OpenGL. This includes header file locations, conventions for use of extensions, etc.
 +
 +
https://www.opengl.org/registry/ABI/
 +
  
  

Revision as of 17:25, 15 July 2015

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.

Windows

Appropriate Windows driver websites:

Some sites also distribute beta versions of graphics drivers, which may give you access to bug fixes or new functionality before an official driver release from the manufacturer:

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.

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.

For more information on developing OpenGL applications on Linux, see Platform specifics: Linux


Mesa3D & GLX

  • OpenGL application on X Windows must use GLX, a standardized API, to set up a rendering context;
  • GLX API is closely coupled with Xlib;
  • OpenGL library also provides the GLX API implementation;
  • GLX system has two roles, it communicates with the X server and initializes client-side and hardware state. The GLX client-server communication takes place using a standardized GLX wire protocol, which is an extension to the X network protocol;
  • GLX library abstracts all client-side and hardware initialization and the internals of the process are hidden in the OpenGL implementation library;
  • GLX API is specified in terms of Xlib, the glX functions use Xlib Displays, Windows, Visuals, etc. The GLX implementations are also built using Xlib;

http://xcb.freedesktop.org/opengl/

glxinfo is a command-line tool that can help you diagnose problems with your 3D acceleration setup

http://dri.freedesktop.org/wiki/glxinfo/ https://packages.debian.org/sid/amd64/mesa-utils/filelist

  • GLX libgl1-mesa-glx
    • /usr/lib/x86_64-linux-gnu/libGL.so.1
    • /usr/lib/x86_64-linux-gnu/libGL.so.1.2.0
    • /usr/share/bug/libgl1-mesa-glx/control
    • /usr/share/bug/libgl1-mesa-glx/script
    • /usr/share/doc/libgl1-mesa-glx/changelog.Debian.gz
    • /usr/share/doc/libgl1-mesa-glx/copyright
    • /usr/share/lintian/overrides/libgl1-mesa-glx

https://packages.debian.org/sid/amd64/libgl1-mesa-glx/filelist


Mesa3D & DRI

Direct Rendering Infrastructure, also known as the DRI, is a framework for allowing direct access to graphics hardware under the X Window System in a safe and efficient manner. It includes changes to the X server, to several client libraries, and to the kernel (DRM, Direct Rendering Manager). The most important use for the DRI is to create fast OpenGL implementations providing hardware acceleration for Mesa. Several 3D accelerated drivers have been written to the DRI specification

http://dri.freedesktop.org/wiki/

DRIconf is a configuration applet for the Direct Rendering Infrastructure. It allows customizing performance and visual quality settings of OpenGL drivers on a per-driver, per-screen and/or per-application level. The settings are stored in system wide and per-user XML configuration files

http://dri.freedesktop.org/wiki/DriConf/ https://packages.debian.org/sid/all/driconf/filelist

  • DRI libgl1-mesa-dri
    • /etc/drirc
    • /usr/lib/x86_64-linux-gnu/dri/i915_dri.so
    • /usr/lib/x86_64-linux-gnu/dri/i965_dri.so
    • /usr/lib/x86_64-linux-gnu/dri/kms_swrast_dri.so
    • /usr/lib/x86_64-linux-gnu/dri/nouveau_dri.so
    • /usr/lib/x86_64-linux-gnu/dri/nouveau_vieux_dri.so
    • /usr/lib/x86_64-linux-gnu/dri/r200_dri.so
    • /usr/lib/x86_64-linux-gnu/dri/r300_dri.so
    • /usr/lib/x86_64-linux-gnu/dri/r600_dri.so
    • /usr/lib/x86_64-linux-gnu/dri/radeon_dri.so
    • /usr/lib/x86_64-linux-gnu/dri/radeonsi_dri.so
    • /usr/lib/x86_64-linux-gnu/dri/swrast_dri.so
    • /usr/lib/x86_64-linux-gnu/dri/vmwgfx_dri.so
    • /usr/share/bug/libgl1-mesa-dri/control
    • /usr/share/bug/libgl1-mesa-dri/script
    • /usr/share/doc/libgl1-mesa-dri/changelog.Debian.gz
    • /usr/share/doc/libgl1-mesa-dri/copyright
    • /usr/share/lintian/overrides/libgl1-mesa-dri

https://packages.debian.org/sid/amd64/libgl1-mesa-dri/filelist


OpenGL ABI (Headers, Datatypes, Libraries)

  • ABI (Application Binary Interface) and runtime environment for applications using OpenGL under X11 on Linux enable applications using the OpenGL API for rendering to run on a variety of underlying implementations transparently. The intent is to address all of open source, commercial closed binary, OpenGL SI-based, and Mesa-based implementations.
  • SDK for developing apps using OpenGL. This includes header file locations, conventions for use of extensions, etc.

https://www.opengl.org/registry/ABI/



Some Linux distributions may include support for hardware acceleration. Also, some GPUs have Open Source drivers developed by the community even though a closed 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.

For more information on developing OpenGL applications on Mac OS X, see Platform specifics: Mac OS X.

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.

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

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.

There are many tutorials and other materials available for learning how to use OpenGL, both on this wiki and online.

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.

Tutorials and How To Guides

User contributed tutorials and getting started guides


By Topic

Development Tools

  • AMD CodeXL - 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. It has since reached its end-of-life and is superseded by AMD CodeXL.
  • gDEBugger - OpenGL, OpenGL ES and OpenCL Debugger, Profiler and Memory Analyzer For Windows, Linux, Mac OS X and iPhone
Warning: AMD's version of gDEBugger will not do any OpenCL kernel debugging without AMD hardware installed!
  • Nsight Visual Studio Edition - Nsight 3.0 support OpenGL 4.2 Debugging and Profiling, along with Shader Debugging and Pixel History
  • Deleaker - Deleaker for Visual Studio finds OpenGL leaks

See Also

External Links