The information contained in this document is subject to change without
notice.
Hewlett-Packard assumes no responsibility for the use or reliability of its
software on equipment that is not furnished by Hewlett-Packard.
This document contains proprietary information that is protected by
copyright. All rights reserved. No part of this document may be
photocopied, reproduced or translated to another language without the
prior written consent of Hewlett-Packard Company.
Restricted Rights Legend
Use, duplication, or disclosure by the U.S. Government Department of
Defense is subject to restrictions as set forth in paragraph (b)(3)(ii) of the
Rights in Technical Data and Software clause in DFARS
252.227.7013.
This document contains proprietary information that is protected by
copyright. All rights are reserved. No part of this document may be
photocopied, reproduced or translated to another language without the
prior written consent of Hewlett-Packard Company.
UNIX is a registered trademark in the United States of America and
other countries, licensed exclusively through X/Open Company Limited.
This software and documentation is based in part on the F ourth Berkeley
Software Distribution under license from the Regents of the University
of California.
OpenGL is a hardware-independent Application Programming Interface
(API) that provides an interface to graphics operations. HP’s
implementation of OpenGL converts API commands to graphical images
via hardware and/or software functionality.
Chapter 15
overview of OpenGL
introduction
introduction
The OpenGL interface consists of a set of commands that allow
applications to define and manipulate three-dimensional objects. The
commands include:
•Geometric primitive definitions
•Viewing operations
•Lighting specifications
•Primitive attributes
•Pipeline control
•Rasterization control
OpenGL has been implemented on a large number of vendor platforms
where the graphics hardware supports a wide range of capabilities (for
example, frame buffer only devices, fully accelerated devices, devices
without frame buffer, etc.).
For more information on OpenGL, refer to these documents , published by
Addison-Wesley and shipped with HP’s implementation of OpenGL:
•OpenGL Programming Guide
Instruction on programming in OpenGL, offered in a tutorial format.
•OpenGL Reference Manual
A reference that contains details on all standard OpenGL functions,
as well as utility (GLU) functions and X-windows (GLX) functions.
•OpenGL Programming for the X Window System
Instructions on interfacing OpenGL with the X Window system.
Chapter 16
overview of OpenGL
the OpenGL product
the OpenGL product
This section provides information about HP’s implementation of the
OpenGL product, as well as information about the standard OpenGL
product.
hp’s implementation of OpenGL
Topics covered in this section are:
•HP’s implementation of the OpenGL libraries
•Supported graphics devices
•Supported visuals
•Visual support for other graphics devices
•Buffer sharing between multiple processes
hp’s implementation of the OpenGL libraries
The OpenGL product does not support archived libraries.
HP’s implementation of OpenGL provides the following libraries:
•libGL.sl
OpenGL shared library
•libGLU.sl
OpenGL utilities library
There are two sets of libraries, one for 32-bit and one for 64-bit. The
32-bit path is:
/opt/graphics/OpenGL/lib
The 64-bit libraries are in a subdirectory:
/opt/graphics/OpenGL/lib/pa20_64
The following graphic depicts the organization of these libraries, which
follows the HP-UX standard for 64-bit libraries.
Chapter 17
overview of OpenGL
the OpenGL product
The arrows in the graphic represent symbolic links.
/opt/graphics/OpenGL/lib
libGL.1 libGL.2
In the library directory, you will see various versions. For example:
•libGL.1 is a 10.20 compatible library for applications which were
built on 10.20.
•libGL.2 is the library which is for applications built on 11.x (this is
why libGL.sl is a symbolic link to libGL.2).
There is only one set of libraries in 11.x for 64-bit. These libraries are
version number 2.
The other libraries you will see in these directories are all drivers for
specific graphics devices. Device drivers, which have names of the form
libdd* are loaded automatically at execution time, contingent upon
device type. The user program does not specifically link in a device
driver.
supported graphics devices
These are the graphics devices that support OpenGL:
libGL.s1
pa20_64
libGL.2libGL.s1
•HP Visualize fxe
•HP Visualize fx-5
•HP Visualize fx-10
•HP Fire GL-UX
•ATI FireGL X1
•ATI FireGL T2
•ATI FireGL X3
supported operating systems
OpenGL is supported on PA-RISC 2.0 systems running the 64-bit version
of HP-UX 11.0 and 11i v1 (11.11).
Chapter 18
overview of OpenGL
the OpenGL product
supported visuals
In this section, each visual table will have a graphics device associated
with it. For information on visual support for graphics devices not in the
above list, read the subsequent section “Visual Support for Other
stereo visual support for Visualize fx-5, fx-10, and Fire GL-UX
When a monitor is configured in a stereo capable mode, HP Visualize
fx-5, fx-10 and Fire GL-UX will have the following additional stereo
visuals available. For more information on OpenGL stereo, read the
section “Running HP’s Implementation of the OpenGL Stereo
Application,” found in Chapter 3 of this document.
Table 1-5Stereo Visual Support for HP Visualize fx-5 and fx-10
X Visual InformationOpenGL GLX Information
ClassDepth
PseudoColor 8255800
TrueColor242562401
TrueColor242562401
a. Depth- and stencil buffers are only allocated for image-plane visuals.
The OpenGL product can be used with devices that have no hardware
OpenGL support using the Virtual Memory Driver (VMD) in Virtual
GLX mode (VGL). In addition, VMD allows you to use many X11
drawables (local or remote) as “virtual devices” for three-dimensional
graphics with OpenGL. This includes rendering to X terminals and other
non-GLX extended X servers.
Table 1-8Visuals Table for VMD
X Visual InformationOpenGL GLX Information
ClassDepth
PseudoColor 8256800
PseudoColor 8256800
TrueColor242562401
DirectColor242562401
Color
Map
Size
Buffer
Size
Overlay=1
or
Image=0
RGBA=1
or
Index=0
Double
Buffer
b
b
b
b
# Aux.
Buffers
000002440 0 0 0
00000000 0 0 0
0888c24 416 16 16 16
0888c24 416 16 16 16
Color BufferStencil
RGBA
a
Z
Accumulation
Buffer
RGBA
Chapter 111
overview of OpenGL
the OpenGL product
a. Depth- and stencil buffers are only allocated for image-plane visuals.
b. Double buffering is set to True (1) if the X visual supports the X double-buffering extension (DBE).
c. Alpha will only work correctly on 12- and 24-bit TrueColor and DirectColor visuals when the X server does not use
the high-order nibble/byte in the X visual. Also, note that when alpha is present, Buffer Size will be 16 for the 12-bit
visuals and 32 for the 24-bit visuals.
buffer sharing between multiple processes and threads
In the OpenGL implementation, all drawable buffers that are allocated
in virtual memory are not sharable among multiple processes. As an
example, on a HP Visualize fx-5 configuration, the accumulation buffer
for a drawable resides in virtual memory (VM) and therefore, each
OpenGL process rendering to the same drawable through a direct
rendering context, will have its own separate copy of the accumulation
buffer. For more information on hardware and software buffer
configurations for OpenGL devices, see Tables 1-1 through 1-8 in the
Supported Visuals section of this chapter.
True buffer sharing between multiple processes can be accomplished by
utilizing indirect rendering contexts. In this case, rendering on behalf of
all GLX clients is performed by the X server OpenGL daemon process,
and there is only one set of virtual memory buffers per drawable.
Within a single process, multiple threads will share virtual memory
buffers (both rendering and accumulation buffers) by default.
GLX-compliant concurrent rendering into these buffers is supported. It
is the responsibility of the application to synchronize buffer access or
partition the rendering buffer amongst individual threads, if desired.
SIGCHLD and the GRM daemon
The Graphics Resource Manager daemon (grmd) is started when the X11
server is started. In normal operation, an OpenGL application will not
start the daemon, and as a result grmd will not be affected by the
SIGCHLD manipulation that occurs as part of that start-up. However, if
grmd dies for some reason, the graphics libraries will restart grmd
whenever they need shared memory. An example of where this can occur
is during calls to glXCreateContext or glXMakeCurrent.
threads support
threads support in November, 1999 11. ACE release Starting with the
release, HP OpenGL will support Level 1b threads. This means HP
OpenGL can be used in a threaded application, but OpenGL graphics
Chapter 112
overview of OpenGL
the OpenGL product
calls must be restricted to a single thread, which remains the same
thread for the duration of the process. This is not the same as OpenGL
calls being made in one thread at a time. Other threads can be used for
computations, etc.
Using OpenGL graphics in a Kernel threaded application requires that
the application link with libpthread.sl (not the archived version,
libpthread.a).
OpenGL libraries are not cancel safe or fork safe.
A context can only be made current in the dedicated graphics thread.
multiple graphics threads support in June, 2000 11. ACE OpenGL
Starting with the June, 2000 11.ACE OpenGL release, OpenGL will
Support Level 2 threads. This means HP OpenGL can be used in
threaded applications, and more than one thread can use OpenGL.
Using OpenGL graphics in a Kernel threaded application requires that
the application link with libpthread.sl (not the archived version,
libpthread.a).
OpenGL libraries are not cancel safe or fork safe.
A given context can only be current in one thread at a time.
additional documentation For more information on using threads , see
the following documentation:
•The devresource.hp.com web site (search for “Threads and
Multiprocessing” )
•The OpenGL Programming Guide
•The OpenGL Reference Manual
•Threadtime by S. Norton and M. Dipasquale
64-bit programming
Starting with the HP-UX 11.0 Additional Core Enhancements (ACE)
(November, 1999) release, HP OpenGL will support 64-bit programming.
Applications using 64-bit computing are supported on SPUs with 64-bit
capabilities only; they are not supported on 32-bit SPUs.
For information on porting your application to take advantage of 64-bit
capabilities, see the devresource.hp.com web site. Search for “64-bit
Computing.”
Chapter 113
overview of OpenGL
the OpenGL product
64-bit OpenGL allows “large data space” because the pointers are now
64-bit. But, the OpenGL data types themselves are the same as the
32-bit library. For example, GLint is a 32-bit integer, not a 64-bit long.
All 64-bit OpenGL libraries are located in
/opt/graphics/OpenGL/lib/pa20_64. The following sample compile
and link lines may help you to build your application once it has been
ported to take advantage of 64-bit capabilities:
Sample 32-bit compile and link:
cc -g -Aa -D_HPUX_SOURCE -z -I/opt/graphics/OpenGL/include\
using libGL in 64-bit together with the +compat linker option Because
of a limitation in the 64-bit linker, if the +compat linker option is used,
-lc must appear in the link order before -lGL. Otherwise, a segmentation
violation will occur when running the linked program.
The following partial compile line shows the relevant order:
cc +DA2.OW prog.c -Wl,+compat
-L/opt/graphics/OpenGL/lib/pa20_64 -lc -lGL
When not using -Wl,+compat, the link order should have -lGL before -lc.
By default, cc implicitly links in -lc as the last library in a link. Without
Wl,+compat, a partial compile line is:
cc +DA2.OW prog.c -L/opt/graphics/OpenGL/lib/pa20_64 -lGL -lc
or
cc +DA2.OW prog.c -L/opt/graphics/OpenGL/lib/pa20_64 -lGL
SLS support
When the display is in a multi-display configuration using the XServer
Single Logical Screen (SLS) extension, OpenGL can and will render to
windows on or spanning any of the SLS displays. This rendering is done
Chapter 114
overview of OpenGL
the OpenGL product
at some loss of performance. For full single display performance, define
the HPOGL_SLS_LOCK_WINDOW environment variable before
executing the program. The define value should be the display number
where the window will reside. When the window is on this display, full
performance can be had; when it is on other displays, the window will be
blank. For more information see the XServer documentation of SLS.
the standard OpenGL product
This section covers the following topics:
•The OpenGL Utilities Library (GLU)
•Input and Output Routines
•The OpenGL Extensions for the X Window System (GLX)
the OpenGL Utilities Library (GLU)
The OpenGL Utilities Library (GLU) provides a useful set of drawing
routines that perform such tasks as:
•Generating texture coordinates
•Transforming coordinates
•Tessellating polygons
•Rendering surfaces
•Providing descriptions of curves and surfaces (NURBS)
•Handling errors
For a detailed description of these routines , refer to the Reference section
or the OpenGL Reference Manual.
input and output routines
OpenGL was designed to be independent of operating systems and
window systems, therefore, it does not have commands that perform such
tasks as reading events from a keyboard or mouse, or opening windows.
To obtain these capabilities, you will need to use X Windows routines
(those whose names start with “glX”).
the OpenGL extensions for the X Window system (GLX)
The OpenGL Extensions to the X Window System (GLX) provide
routines for:
•Choosing a visual
•Managing the OpenGL rendering context
Chapter 115
overview of OpenGL
the OpenGL product
•Off-screen rendering
•Double-buffering
•Using X fonts
For a detailed description of these routines , refer to the Reference section
or the OpenGL Reference Manual.
Chapter 116
overview of OpenGL
mixing of OpenGL and Xlib
mixing of OpenGL and Xlib
The OpenGL implementation conforms to the specification definition for
mixing of Xlib and OpenGL rendering to the same drawable. The
following points should be considered when mixing Xlib and OpenGL:
•OpenGL and Xlib renderers are implemented through separate
pipelines and control streams, thus, rendering synchronization must
be performed as necessary by the user’s application via the GLX
glXWaitX() and glXWaitGL() function calls.
•Xlib rendering does not affect the Z-buffer, so rendering in X and
then OpenGL would result in the OpenGL rendering replacing the
Xlib rendering. This is true if the last OpenGL rendering to the
Z-buffer at that location resulted in the depth test passing.
Note that mixing Xlib rendering with OpenGL rendering as well as with
VMD, when using alpha buffers, can produce unexpected side effects and
should be avoided.
Chapter 117
Loading...
+ 43 hidden pages
You need points to download manuals.
1 point = 1 manual.
You can buy points or you can get point for every manual you upload.