Designing a safety-certifiable OpenGL software GPU

GPUs are used to provide video and graphics processing capabilities that aid in processing pixel-intensive graphical operations, such as anti-aliased symbology, generation or 3D data visualization, video decode and overlay, and so forth. Most modern GPUs are dedicated ASICs, often reused from the desktops of the mobile computing world. But the concept of a software GPU is attractive, especially for safety-critical embedded systems.

Safety certification for GPUs is problematic for a number of reasons, including the difficulty of obtaining suitable design assurance and the hardships of obsolescence and varying standards for the GPU’s software and driver interface. Hardware GPUs are often not flexible enough to meet custom embedded design challenges. Even though GPU hardware employed in an embedded system often has impressive raw performance, this performance is also surprisingly difficult to realize when the GPU is deployed in an embedded application. However, a software GPU implementation is proving itself a viable remedy in addressing these challenging areas.

Safety certification: A top priority

Commercial hardware GPUs are not developed with the intention to have rigorous hardware verification performed on them as is required by certification standards for various industries, such as DO-254 for avionics. Instead, they are developed to handle a multitude of desktop or mobile computing needs, many of which are not necessary in an embedded environment.

A standard such as DO-254 provides a design assurance level for a system component, typically achieved via requirements decomposition, rigorous demands, and structural testing of logic elements. This level of design assurance is never available for a commercial GPU chip comprising millions of gates. Therefore, system designers rely on other means to assure safety, such as fault-tolerant architectures, service life history analysis, and black box testing. Many of these methods involve extra system expense, both during development and recurring throughout the deployment phase of the system. Safety certification authorities might also take a dim view of safety evidence that does not incorporate proper design assurance.

By contrast, the software GPU has a simple design, and one key factor to this simplification is to limit the API support to an essential subset. Accordingly, the subset OpenGL standards developed by the Khronos industry consortium are implemented in the software GPU (www.khronos.org). The resultant OpenGL SC Safety Critical Profile defines the subset of OpenGL designed specifically for safety-critical embedded systems.

By focusing on this subset, the underlying implementation is kept simple and can undergo standard design assurance using the DO-178B software guidelines used for safety-critical software. The software GPU’s code base is under 15,000 Source Lines of Code (SLOC), and complete design assurance to the DO-178B standard has been developed with the software GPU implementation.

Thwarting obsolescence

Obsolescence is also a key concern with hardware GPUs. Once a traditional hardware GPU component has been selected and designed into the embedded system, any change or technology insertion typically involves much redesign. Unfortunately, commercial (hardware) GPU chips have a short service life, due to their primary usage in a fast-moving commodity PC marketplace. Therefore, lifetime buys are often necessary for these components when they are used in an embedded program with life cycles that can span decades. This problem is mitigated substantially by using a software GPU, which can be easily instantiated on any processor.

Flexibility and interfacing

Hardware GPUs are powerful, but they are often not flexible enough to address special-purpose needs found in embedded systems. Consider, for example, an ISR application accepting video data from a camera interface into a processor card, adding computer-generated symbology, and sending the output to an embedded sensor multifunction display in an aircraft. If the sensor input comes from a source not commonly found in a desktop computing environment (such as a DSP sensor processor, for instance), the GPU will not have a built-in path to handle it. Or, the computer symbology for blending may come from a separate processor, and an output transparency (or alpha) channel might be required to properly merge the two sources. In both cases, the GPU’s lack of flexibility will constrain system design.

Similarly, modern GPUs are built to operate in a classic processor configuration, whereby the GPU receives graphics data from an AGP, PCI, or PCI-X bus and processes it in a parallel manner. This can cause issues when rendering must be segregated via time- or space-partitioned boundaries, such as those required for processing highly safety-critical data alongside noncritical data, or highly secure data with unclassified information. Hardware GPUs are designed as hardware components composed of ASICs and are not designed to be interrupted as is required in a time-partitioned system. Also, drivers almost always utilize DMA transfers, which are nondeterministic in a memory-partitioned environment.

By contrast, the flexibility of a software GPU allows many different software and parallel hardware architectures to be used, including multicore processors, software-partitioned processors, and combination processor/FPGA designs. Multiple instances of the software GPU can also be hosted within an ARINC 653 partitioned operating system such as Sysgo’s PikeOS to achieve a partitioned display environment that can support such multilevel secure and multicritical applications (Figure 1).

In another configuration, the software GPU can be hosted on a PrPMC platform, allowing the PrPMC to work as a dedicated GPU in a VME SBC-based system. In this kind of implementation, the OpenGL client side driver communicates across a traditional bus, such as a PCI or PCI Express, and the PrPMC is indistinguishable from a traditional GPU in the system, except that it offers far more flexibility.

The rise of multicore processing in embedded systems similarly provides an additional opportunity to leverage a software GPU design. To accomplish this, one core can be assigned as a graphics processor while the HMI or ISR application can run on another core. Thus, the software enables a multicore system to eliminate a dedicated GPU.

Performance and features

Performance is a critical issue in embedded GPU design. It always seems performance falls short of what is needed. However, the factors that affect embedded GPU performance can be difficult to identify.

Software that makes inefficient use of a GPU (such as inefficient graphics state changes) can perform badly even when rendering geometry well short of theoretical GPU performance. Performance is sensitive to such factors as processor concurrency, operating system throughput, bus contention, and other factors.

Clearly a software GPU cannot achieve the same performance as a hardware-accelerated dedicated ASIC – especially one designed for high performance. And a software GPU cannot obviate the need for hardware acceleration in very demanding graphics applications such as geospatial data visualization or synthetic vision. However, due to design simplicity, it is often easier to identify and address performance bottlenecks in a software GPU graphics system. Using a software GPU, performance bottlenecks can be addressed through such means as leveraging specialized processor instructions, partial acceleration of GPU processing through FPGAs, parallel processing, or just plain old-fashioned profiling and optimization.

In addition, the software GPU design allows graphics applications to take advantage of performance-enhancing techniques that are difficult to accomplish in traditional GPUs, such as one-time rendering of static backgrounds, rendering of differing screen regions at different refresh rates, and so forth.

The feature set of the software GPU is also an important consideration. Image quality, for instance, is a key area for safety-critical displays. Commercial hardware GPUs often do not achieve adequate image quality, resulting in time-consuming workarounds or quality trade-offs in the resultant emdedded HMIs. In a safety-critical GPU intended for use in a system where a human operator must use a system to make life-critical decisions or monitor the system for long periods of time, such qualities as smoothly moving lines, fonts, and texture-mapped images that do not distract an operator are needed. Figure 2 illustrates an example of a safety-critical HMI display generated with the software GPU. This display comprises 2 to 3,000 antialiased line segments, antialiased texture-mapped test strings, a bilinear filtered texture map, and several additional symbology elements. It renders all the symbology of each frame at 60 frames per second into an 800 x 600 frame buffer. On the same computer using a hardware-accelerated GPU, the display renders at twice the frame rate.

A clear future for software GPUs

Utilizing GPUs in safety-critical applications poses significant challenges in the areas of safety certification design assurance, obsolescence, flexibility in interfacing, and performance. Software GPUs, such as Quantum3D’s IGL 178, are designed to address a powerful API such as OpenGL SC and can help resolve the aforementioned safety-critical GPU needs.

Mark Snyder is a senior engineering manager with Quantum3D, Inc. Prior to joining Quantum3D, he was an engineer at Honeywell International. He also spent nine years as an Air Force officer, where he was involved in 3D virtual simulation and visualization research at the Air Force Research Lab and engineered C4ISR systems at Air Force Space Command. He holds a BS in Computer Science from Arizona State University and an MS in Computer Science from the Air Force Institute of Technology, and is inventor on several patents in the avionics flight deck display arena. He can be contacted at [email protected].

Quantum3D, Inc.
623-486-9939
www.quantum3d.com