This essay has been submitted by a student. This is not an example of the work written by our professional essay writers.
Mobile phones, instrument clusters, car navigation systems, multi-function displays, games consoles and avionics displays are all enjoying the benefit of high quality and high performance graphics display controllers. It is imperative that these graphics processing units being manufactured are met by high function tools for developers to help with optimising and bringing the best out of the GPUs in the form of highly defined images, applications, user interfaces etc. With continual interest in3D gaming, films and computer graphics applications both for computers and handheld devices and as graphics hardware are becoming more programmable. It is important to understand how the tools and APIs available work and which might be suitable for a chosen application. For a cross platform rendering OpenGL is the most efficient while Direct3D excels on Microsoft Windows operating systems and 3D gaming applications.
Rendering can be defined as the process of generating an image from a model by means of computer programs. The model is usually a description of three-dimensional objects in a strictly defined language or data structure. The description would contain geometry, viewpoint, texture, lighting and shading information amongst other constraints. The resulting image is a digital image or raster graphics image.
In graphics rendering images are rendered using two techniques. The first is the hardware accelerated rendering which is rendering performed using a dedicated graphics accelerator (Graphics Processing Unit GPU) and the other is the software rendering which is performed using the device's main processor (Central Processing or Unit CPU). It is however possible, though not advisable to use both techniques in the same program as it would require pixel data transfer between the two processors which could affect the performance because the processors do not share the same memory.
As objects are rendered on desktops and supercomputers, the same can also be done on an embedded system. An embedded system is a computer system that is designed to perform one, and in some cases, a few dedicated functions often with real time computing constraints. Embedded systems range in market variety from consumer electronics and telecommunications to transportation systems. A few examples from some of the aforementioned markets include mobile phones, digital cameras, instrument clusters, video game consoles etc. To render graphical images on an embedded system there are some constraints such as power consumption of the device that have to be taken into consideration, which is why separate APIs (Application Programming Interface) are created for embedded devices which take all the restrictions into consideration.
Application Programming Interface (API) is an interface which enables interaction between itself and other software. It can be in the form of software applications, libraries and operating systems which define their vocabularies and calling conventions to access their services. It may include specifications for routines, data structures, object classes, and protocols used to communicate between the consumer and the implementer of the API.
Graphically rendered applications can be created using various APIs. OpenGL and Direct3D are the most commercial APIs used in the industry and are direct competitors when it comes to graphics rendering. The following text will have an in depth view into how each is used to render graphical images using their programming pipelines, the differences between each of the APIs and how they benefit both their customers and respective software developers. The embedded version of each API will also be discussed and finally comparing the result from benchmarking carried out on their performances and the operating systems best suited for rendering with each API.
Introduction to OpenGL
OpenGL is an open specification defining a cross platform API for writing 2D and 3D computer graphics applications. This API has over 250 function calls defined for the purpose of drawing from standard to complex 3D scenes. It has developed steadily since its conception in the early 1990s going from OpenGL 1.0 to 4.0. It has a branch specifically targeted at embedded devices with OpenGL ES. Silicon Graphics Inc. (SGI) founded OpenGL in 1992 but it is now managed by the Khronos group, which is an organisation founded by a large number of media centric companies that help in shaping and defining various API specifications. Even though there are several APIs for graphics rendering, OpenGL's main competitor is Direct3D of Microsoft.
OpenGL has been gradually developed from version 1.0, adding new features into the pipeline as further releases were made. OpenGL 2.0 had major changes which improved the basis as further releases are developed. OpenGL 2.0 included support for the GPU based assembly language ARB (designed by the Architecture Review Board), which is now the standard for fragment and vertex shaders. It also brought about the introduction of c-style shading language in the form of GLSL (the OpenGL Shading Language). GLSL removed limitation from previous releases in terms of compatibility with GPUs where ambitious targets for 3D accelerators are set and considered for the OpenGL specification rather than tracking the state of currently available hardware. At the time of writing the latest release is OpenGL 4.0 while 4.1 has been announced and is distinctive in that it will be fully compatible with OpenGL ES 2.0 API. OpenGL releases are backward compatible i.e. graphics card released after OpenGL 2.0 will be compatible with all the features released for OpenGL 2.0 as well as all earlier versions.
Some of the widely used OpenGL libraries include
The OpenGL Extension to the X Window System - GLX is used on Unix OpenGL implementation to provide a way of creating an OpenGL context. It manages interaction with the Window System and enhances OpenGL for remote rendering.
The OpenGL Utility Library (GLU) - is a set of functions with several routines that make use low level OpenGL commands to generate texture mipmaps, map coordinates, and the drawing of quadric and rendering surfaces.
The OpenGL Programming Guide Auxiliary Library - is responsible for procedures to initialize and open windows, handling of X events creating common shapes of varying complexity, from cubes to spheres.
These libraries make use of the OpenGL specifications but bring added features and flexibility to help the developer design and build an application that suits their need. It also bridges the gap across all the different platforms and their respective window system. Some of the common libraries are suited for game developers others might be more suited for beginners. There are a lot more libraries and toolkits available for OpenGL, not all of them are officially supported by the Khronos group. The programming pipeline remains constant from library to library with the varying component being the actual function of the library.
OpenGL Programming Pipeline
The OpenGL programming pipeline has a few stages that get processed in a logical order as can be seen in figure 1 below. In summary graphical data, vertex and pixel data are combined with the output transferred into the frame buffer. Each stage of the pipeline processes will be briefly explained after the diagram on the next page.
Figure 1: OpenGL Programming Pipeline
Display List - A set of OpenGL commands that have been compiled and may be executed instantly or processed at a later stage in the pipeline is known as the display list. All the vertex and pixel data can be stored in a display list as a result the performance of the program may be improved as the data are cached in a display list. It is also there to enable reuse of commands although some commands cannot be inserted in the display lists.
Vertex Operation - This stage is the process whereby transformation of each of the vertex and normal coordinates takes place from object coordinates to eye coordinates.
Primitive Assembly - Following the vertex operation, the primitives known as points, lines, and polygons are transformed using OpenGL projection matrix (perspective and orthographic projection methods). The output is then converted from eye coordinates to clip coordinates, which are then transformed into normalised device coordinate; this is a perspective division by w component of the clip coordinates. Viewport transformation is also applied to merge the 3D object to the target window coordinate space and finally a culling test is carried out if enabled. Culling, when enabled, is used to prepare the ordered list of nodes to render for the later stage of the pipeline.
Pixel Operation - This is the process whereby data received from memory or display list stage are processed with functions like mapping, scaling, clamping etc and resulting data are transferred into the rasterizing stage or stored in the texture memory.
Texture Memory - This is the area in memory allocated for the storage of texture images for use in the rasterizing stage.
Raterization - This is the stage of the pipeline where the pixel and geometric data passed from the previous stages are combined and converted into fragments. Fragments is an array containing data needed to generate pixels to be drawn in the frame buffer; some of the data included in a fragment are depth, colour, raster position, point size, width etc. A fragment produced at this stage will correspond to a pixel generated in the frame buffer. In the shading code if shading mode has been enabled to be filled, this is the stage where that action will be carried out.
Fragment Operation - This is the final operation in the pipeline the converts fragment data into pixels before they are written into the frame buffer. The initial task carried out at this stage is the generation of texels; these are texture elements extracted from the texture memory and attached to each fragment. After this fog, calculations and various fragment tests are carried out. The following fragment tests are carried out in the outlined sequence: Scissor, Alpha, Stencil and depth tests. The final set of operations (z buffering, logical operations, masking, blending etc.) are carried out and the resulting pixel data are then stored in the frame buffer.
Benefits of OpenGL
Reliable and portable
All its applications are known to produce high visual display results on compatible hardware irrespective of the operating system or windowing system which also goes to show its wide availability from UNIX, MAC and windows Operating System (OS) to being written using C, Fortran, Python, and pearl languages amongst others.
The API has been widely available for nearly twenty years on a wide variety of platforms.
The API specifications are well controlled, and its requirement for compatibility with previous versions ensures that applications do not become out-dated. This has helped in making OpenGL the most widely adopted graphics API standard for developing 2D and 3D graphics applications.
Easy to use and very well documented.
It is well structured and make use of logical commands also has a wide range of books readily available which makes obtaining information about OpenGL very easy and inexpensive. The API is still known to be scalable and constantly evolving with new releases.
Overview of OPENGL ES
OpenGL ES is a cross platform API for rendering sophisticated 2D and 3D graphics on embedded systems with programmable 3D hardware including consoles, phones, appliances, vehicles and avionics. It is a precise subset of desktop OpenGL which enables a flexible and effective low level interface between software and hardware acceleration. OpenGL ES however has features that were only included to accommodate basic handheld/embedded system limitations such as limited memory bandwidth, low processing capabilities and memory availability, power consumption and limited support for floating point arithmetic. Some features that were added to assist with the handheld limitations involve allowing programmers to specify vertex coordinates using bytes, int, short and float along with support for fixed points.
A major criterion used when designing the API's specification included eliminating redundancy by ensuring that there are no multiple methods of performing a single task while maintaining compatibility with OpenGL. Conformance tests were agreed upon by the OpenGL ES working group (Khronos) to ensure that any OpenGL ES implementation would meet an acceptable and agreed on standard for image quality, correctness, and robustness.
OpenGL ES has several profiles defined in its specification. The three commonly used profiles (which share a similar processing pipeline) include:
The Common Profile
This is intended for use in devices like mobile phones, PDAs, set-top boxes, game consoles, etc. It targets an expansive range of the markets and includes support for platforms with varying capability. It is enabled for full function 3D rending.
The Common-lite Profile
This is very similar to the common profile with the major difference being the common-lite does not support floating point data type to compensate for devices with such constraints, it is instead limited to fixed points while common is able to support both.
The Safety Critical Profile
This is targeted for use in consumer and industrial applications, where reliability and verifiability are of uttermost importance. Its applications are required to be testable and demonstrably robust as their use will be in safety critical embedded applications such as automotive and glass cockpit avionics displays. It has absolute minimum 3D to ease safety certifications.
To date, there have only been three OpenGL ES releases and a fourth version 2.1 has been announced. The first two specifications implement a fixed function pipeline and were structured from OpenGL 1.3 and 1.5 specifications while the more recent version 2.0 implements a programmable pipeline derived from OpenGL 2.0 specification. As most of the fixed function rendering pipeline has been eliminated and replaced with a programmable one in the latest version 2.0, it is not backward compatible with previous version 1.1 and 1.0.
Benefits of OpenGL ES
Broadly accepted and supported
It is an Open Source specification therefore is broadly accepted and supported in the embedded industry by several vendors and developers from the automotive market to handheld PDAs and mobile devices. It is easy to use and very well documented just like OpenGL which it is based on. Its resources such as libraries, manual and specifications are widely available and can be get hold of with ease. These make developing applications with OpenGL ES inexpensive and with the ability to use the same code for embedded devices on its desktop equivalent ensure that testing and distributing on several devices is also easier.
Ability to bridge the gap between desktop computer and embedded device applications
OpenGL ES is able to bridge the gap between desktop computer and embedded device applications in terms of requirements needed to make and run the application on an embedded system. It requires minimal storage allocation and low power consumption enabled to use integers and floating points, which are all the ingredients required to integrate desktop applications to portable devices. Applications can be software and/or hardware rendered without much difficulties.
Direct3D is another API used for 3D graphics rendering but unlike OpenGL is only available for use in Microsoft's various operating systems from Windows 95 to currently used windows 7 and Wine. Wine is open source software written to enable Microsoft windows programs run on UNIX like operating systems. It is currently used API in various Microsoft based embedded platform such as the game console Xbox and several windows PPC devices in the form of Direct3D Mobile. In the embedded devices mentioned Direct3D is used for games where performances are important and when relevant GPU available the programs are hardware accelerated.
Direct3D Programming Pipeline
Figure 2: Direct3D Programming Pipeline
Input Assembler - This is the first stage of the pipeline. Its primary objective is to read primitive data inserted into the buffers by the user and assemble the data into primitives that will be used by other stages of the pipeline. The secondary objective of this stage is to combine system generated values to the user input as an output to the vertex shader stage to make the shaders more efficient.
Vertex Shader - This stage receives its input from the input assembler as vertices, processing the data by performing per vertex operations i.e. transformations. It operates on a single input vertex to produce a single output vertex. This must be carried out for the rest of the pipeline to execute. When there is no vertex operation required, a pass through vertex shader must be created to enable progression of the other stages in the pipeline.
Geometry Shader Stage - This stage is very similar to that of the vertex shader but in place of being restricted to receiving a single input vertex, geometry shader is able to receive vertices for full primitives. For example, two vertices for a line, three for a triangle and one vertex for a point. It generates vertices as an output based on the input received. The output from the geometry shader can be fed into the rasterizer stage and or the stream output stage in the vertex buffer memory.
Stream Output Stage - The main aim or objective of this stage is to constantly stream input data received from any of the two shader stages to the buffers in the memory. As this processing stage is located in between the geometry shader and the rasterizing stage, its output can be passed into the memory and returned to previous stages of the pipeline (input assembler or the programmable shaders) or to be made available for the CPU. The output data can also be passed as an input into the rasterizing stage.
Rasterizer Stage - This stage transforms vector data made up of shapes and primitives received from the previous stages into a raster image. All the primitives are transformed into pixels while incorporating per vertex values across all of the primitives preparing them for the pixel shader stage.
Pixel Shader Stage - This is the stage where a pixel shader is used to combine inputs texture data and interpolated data amongst other set of data to create per pixel data output. The previous stage invokes a pixel shader once for each pixel, although a NULL shader value can be defined to avoid running a shader.
Output-Merger Stage - This is the final stage of the pipeline where the final pipeline result is generated. The objective is to combine all the output data generated by the shaders and merge them with the data from the render target and buffers. The final object is displayed after visible pixels are determined from depth/stencil tests and blending of pixels.
Benefits of Direct 3D
It is device independent and portable as it has been designed to protect its application from the differences in features and capabilities of the hardware platforms they are executed. When a target GPU does not have a specific feature required to execute a program, Direct3D is able to provide a fast equivalent implementation in software rendering as the pipeline can partly or fully support 3D hardware or software based rendering.
Flexible access to hardware acceleration
At runtime the application is able to detect target hardware capabilities to fully use its features if present this enable flexible access to hardware acceleration.
Executable on a variety of hardware platforms
There is a minimal set of capabilities and features outlined for hardware drivers supporting Direct3D hence its hardware having common driver model making its application executable on a variety of hardware platforms. Direct3D specifications provided to hardware vendors/developers are unified and also a standard mechanism and set of algorithms are defined which enables development of applications to be less time consuming.
Direct3D mobile is an API used to render 3D graphic applications on windows embedded compact (WinCE) devices. It is a subset of the Direct3D API used on Microsoft's operating systems, and is optimized for use on embedded systems. Similarly to the OpenGL ES, it is also optimised to eliminate the limitations presented by embedded devices in terms of hardware capabilities and requirements. In comparison to its desktop version, its solutions can also be hardware or software rendered with the possibility of a combination of both. It also supports fixed points, floating points and integer data types. It is primarily designed for games, satellite navigators and other standalone applications. Some of its advanced features like alpha blending and 3D transformation enable it to be used for highly sophisticated user interfaces.
Difference between OpenGL & Direct3D
The two APIs make use of the same programming pipeline that has been in use in the early stages of computer graphics rendering although both have made changes to suit features and capabilities of each API and to adapt with the growth of the graphics hardware industry. Both use the same concept of using vertices, shaders and primitives. The major difference lies in the way each API handles the combination of the vertices and how they are turned into primitives. OpenGL as an API is designed to manage its hardware resources while Direct3D expects its applications to do so. This reduces the difficulty in developing for OpenGL, although the complexity of developing a high performing application or driver for the API increases. This is not the case for Direct3D as developers independently manage hardware resources. As a result developers are able to manage resources in the most efficient way possible.
OpenGL can be used across various operating system platforms, unlike Direct3D, which is only limited to Windows. There are some flaws in OpenGL portability, like the inability to have hardware accelerated solutions on Windows OS unless additional client drivers are installed. These have not stopped its use on recent mobile platforms like Apple's iPhone, Nokia's Symbian and Google's Android mobiles. Direct3D Mobile has been used in the past on Xbox and Dreamcast game consoles. Both are available for use on PlayStation 3. Both APIs can be portable and have their limitations. Direct3D is an API designed with an aim for use in high performance game development while OpenGL is more of a general purpose 3D API which does not only target the gaming industry but other professional graphic markets.
The tests were carried out on Unigine engine using two benchmarking demos provided by Unigine Corp. Unigine Corp is a software development company who developed Unigine engine as software used to enhance development of games or used for virtual reality simulations. They also produced technical Demos for benchmarking purposes. Being partners with the likes of NVidia and AMD leaves the possibility of their demos being favourable to their hardware or the preference of the developers might have caused bias towards a particular API. Notwithstanding, there are not a lot of programs offering benchmark demos for comparison of both OpenGL and Direct3D. The fact that the demos are run on the same device eliminates any bias towards a particular hardware and gives a general overview of the rendering performance of each API.
The first demo is the tropics demo, which shows an overview of a tropical paradise with the camera travelling across the paradise containing the waves of the ocean, crabs crawling on sand among the boat and mild wind blowing the palm leaves. Some of the rendering features in the demo include HDR (High Dynamic Range rendering), interactive experience with fly through mode, dynamic sky with light scattering, 3D vision etc. Three stills are shown below:
The second demo is the sanctuary demo showing a gothic chapel lit by light of torches with some sun rays going through stained glass windows. Some of the features in this demo also include 5 dynamic lights, translucence, light and fog, post processing, particle systems etc. Three stills are shown below:
The tests were carried out on a computer with the following specifications:
Intel Core2 Duo P9700 processor at 2.8GHz, 4GB of DDR3 RAM, an NVidia GeForce GTX 260M graphics card with 1GB DDR dedicated memory using NVidia version 195.62 driver. The software used is the Unigine engine Benchmarks provided by Unigine Corp as previously mentioned on the Windows 7 Ultimate 64 bit version operating system.
The tests were carried out running each of the demos using OpenGL, DirectX 9.1 and DirectX 10.0. The results are displayed below where the rendering rate was measured in frames per second.
Another benchmark was carried out using the same demos and hardware but comparing the OpenGL performance on the Windows 7 and Ubuntu 9.10 Operating systems. The same hardware specification as above was used with the only difference being that the driver version used for the NVidia graphics card is the Linux version 190.42. The tests were carried out on both operating systems varying the resolution only with OpenGL as Direct3D is only available on windows platform. The results are shown below.
The results of the benchmark provided some interesting insights into the performance of the different APIs. The first benchmark utilised 3D demos from Unigine as explained above, where the rendering rate was measured. As expected, DirectX proved to be the superior API in the Windows environment. OpenGL was however rather impressive with a respectable showing of rendering rate in both demos. DirectX 10.0 performed better than DirectX9.1, having the obvious advantages of being a later model of the same API. Also, each API performed better in the Sanctuary demo than in the Tropics demo. This could be due to the fact that the light intensity was fairly consistent in Tropics, so even though there was a lot of detail in the images the actual image did not change very much meaning that once it was fully rendered there were less frames per second required. In Sanctuary however, the light intensity varied frequently and drastically requiring more frames per second in order to show a fully detailed sequence.
The second benchmark used the same demos and hardware but this time using OpenGL and comparing its performance on the Windows 7 and Ubuntu 9.10 operating systems. The resolution was varied on each system. The benchmark showed that even though OpenGL is inferior to DirectX on Windows operating systems, it performs much better on Windows than it does on the Linux based Ubuntu. This could be due to the fact that the drivers used on the windows platform improved the performance of OpenGL by enabling features like hardware acceleration whereas Ubuntu only requires certain files to be loaded into the appropriate library for OpenGL to function.
Finally, as evidenced from the previous discussion, Direct3D is a member of the DirectX family which has other APIs specifically supporting features that might be useful in developing gaming applications. For instance, Direct3D combined with DirectPlay will enhance the application or game for network support compared to when OpenGL library manages all these features itself. Both OpenGL and Direct3D have the same features but in terms of hardware rendering, OpenGL is leading the market as it has more graphics hardware supported than Direct3D. OpenGL, from its early version, has been hardware accelerated and its specification is written by a group containing a lot of GPU vendors. Direct3D was originally written for the gaming industry and to be software rendered until its 7th version where hardware rending was included in its development. When Direct3D developer uses both hardware and software rendering it is expected to have performance and output quality reduced due to the effect of having data transfer between the CPU and GPU.