Debug Output Features for OpenGL SC 2.0 Safety Critical Profile

Abstract

With the modern 3D graphics libraries, the support for the error reports and other debugging features are much important. For the famous OpenGL (Open Graphics Library) family, they introduce the KHR debug extension. In this paper, we present the details of adding full features of KHR debug extension to the OpenGL SC (Safety Critical profile) 2.0. This enhancement to the OpenGL SC 2.0 engine shows more up-to-date debugging features with traditional graphics drivers.

1 Introduction

Currently, OpenGL family is one of the most widely used three-dimensional graphics library [1, 2]. This library is used on various platforms including personal computers, workstations, mainframes, tablets, smartphones, and others. Many commercial and non-commercial implementations are available. For three-dimensional graphics output, the single board computing devices typically use OpenGL ES (Open Graphics Library for Embedded Systems) [2]. Khronos Group, the de facto standard organization, consistently manages all the standard specifications and various extensions.

From the programming point of view, the emphasis on the debugging supports are one of the most important trends. In contrast, OpenGL graphics library was originally designed in 1990s, when there is no sufficient requirements on the debugging functionalities [3]. Thus, many existing drivers and implementations of OpenGL provides only the classical error checking feature: When an error occurred, OpenGL system set the internal error flag, and it is the duty of application programmers to periodically check the error flag and process its error handling.

OpenGL SC (OpenGL for Safety Critical) is conceptually a safety critical variation of the famous OpenGL standard. This graphics API library is designed to meet the needs of safety critical markets for avionics, industrial, military, medical and automotive applications. In the case of safety-critical markets, OpenGL SC plays the major role for the graphical interfaces. The need for this 3D graphics API is rapidly increasing with the growth of the safety-critical market [4, 5]. For the medical and automotive applications, consumer electronics markets start to strongly need this standard [6].

In the year of 2015, the Khronos Group, the fundamental standard management body of the OpenGL family, established the new OpenGL SC 2.0 specification [7]. It originally aims to a safety critical subset of OpenGL ES 2.0 [8]. The Khronos Group is also developing cross-API guidelines to aid in the development of open technology standards for safety critical systems.

For the safety critical profiles, they also emphasize the security-critical features. To fully support these safety and security features, the debug output extensions are highly recommended. In this paper, we show our design and implementation of the debug output extension for OpenGL SC 2.0 library. Our implementation shows that it works well and helpful for the safety-critical supports. Details are followed in the following sections.

2 Design Analysis

For more convenient error processing and debugging features, the new KHR debug extension [9] to the OpenGL is introduced in 2012. With this debugging extension, the OpenGL system generates more detailed internal error messages and automatically calls the pre-registered callback function when an error occurred. This new extension is actually a big improvement to the debugging of the OpenGL application programs. From OpenGL version 4.3 [10], this debugging extension is now the core feature of the OpenGL standard specification.

With KHR_debug extension, the OpenGL system automatically calls the pre-registered callback function, for every internal errors. We can use the function to pre-register the user-specifiable callback function. Additionally, application programmers can generate his/her own messages to the error stream, even without any OpenGL errors. We can use function for this purpose. The followings are the details of those functions.

specifies a callback function to receive debugging messages from the OpenGL. Each time a debug message is generated the debug callback function will be invoked with source, type, id, and severity associated with the message.

injects an application-supplied message into the debug message queue.

When the OpenGL system works in the server-client model, the OpenGL functions may be called with remote calls. In this case, since the physical memory regions are isolated to each side, the OpenGL system cannot call the pre-registered callback function. For those situations, the OpenGL system generates the debugging message to its internal message log area. Application programmers can access the internal message log area and get the log messages using the following function:

retrieves messages from the debug message log.

We applied the KHR debug extension to the new OpenGL SC 2.0 standard specification. To support the debug extension, we first need API function implementation. To support full features, actually we need internal engine modifications, to support debug features. In our case, we succeeded to add all the features to the OpenGL SC 2.0 engine internals.

3 Implementation Results

To test the KHR debug extension features, we make a set of example programs. As a typical example, one of our example source code contains the following code segment:

Since our shader programs do not contain any variable of the name “unspecified”, these code segments generate a warning and an error, according to the OpenGL SC 2.0 standard specification.

In our OpenGL SC 2.0 engine implementation, each API function will check any warning conditions and error conditions. For the warning case of function, our engine contains the following code segment:

where is the internal debug output function. This will generate the corresponding OpenGL SC warning debug message.

Additionally, our OpenGL SC 2.0 engine also contains error check as follows:

Finally, these warning and error checks generate the debug output messages on the screen as follows:

As shown here, these debug output messages contain the API kind, severity level, and identification numbers, as the details of the debug messages. All these details are not required for the basic-level OpenGL SC engines, while those should be implemented for the KHR debug extension support.

4 Conclusion

In these days, the debugging features become more important to the development process. In this paper, we aimed to add the KHR debug extension to the newly released OpenGL SC 2.0 graphics library. We designed to support all the debug output features in the existing OpenGL SC 2.0 engine. The final check programs show that our OpenGL SC 2.0 engine now fully support KHR debug extensions. This is the first literature report of the debug extension to the OpenGL Security Critical profile, at least to the best of our knowledge.