Opengl SC Sean Harmer – Managing Director UK March 2017

OpenGL SC Sean Harmer – Managing Director UK March 2017

The need for safety-critical systems with user-friendly interfaces is on the rise. To respond to this need, the Khronos Group (responsible for OpenGL, etc) has introduced OpenGL SC, a new standard that enables graphics in safety critical applications.

OpenGL SC certifes a subset of OpenGL ES OpenGL SC. What techniques won’t carry over? software and accelerated hardware under Are there functions you can no longer use? DO178-B (for aviation cockpits), ISO26262 (for What are the gotchas? automotive instrument panels), and ISO 61508 (for industrial automation controls). It primarily This whitepaper reviews the basic diferences in focuses on features needed to render aviation moving from OpenGL ES to OpenGL SC, to help cockpit displays: digital instrument panels, you quickly determine what’s needed in skills 2D maps, 3D terrain, and augmented reality and software to make the change. Specifcally, displays. we will compare the latest released version of both standards: OpenGL ES version 3.2 and As an embedded graphics programmer you’re OpenGL SC 2.0. It’s important to note that already familiar with OpenGL ES, but your OpenGL SC 2.0 is not backward compatible company or your customers may begin asking with OpenGL SC 1.0; as the 2.0 release of the for OpenGL SC support in your products. You standard is still relatively recent, it may not yet may be wondering how much time and efort be available from your OpenGL vendor. is needed to port your applications over to

KDAB | the Qt, OpenGL and C++ experts 1 OpenGL SC can’t support creating shaders on the fy so you’ll need to remove any inline shader compilation/ testing/validation code and switch to shaders created at compile-time.

No Runtime Shaders No glDrawElements

Change(s) Change(s) • The following functions are removed: • The glDrawElements function is glCompileShader, removed. Programs must use glCreateShader, glDrawRangeElements instead (added glAttachShader, in OpenGL ES 3.0) glValidateProgram, glShaderBinary, glShaderSource, Rationale • Ensuring that the indicies passed to glLinkProgram, the OpenGL function will not exceed glGetShaderiv, a predefned range helps limit the glGetShaderInfoLog, extent of validation testing glGetShaderPrecisionFormat, glGetShaderSource, glGetAttachedShaders Feature(s) Possibly • All functions doing rendering Impacted Rationale • Safety critical code doesn’t need to create shaders on the fy. This moves Workarounds all shader compilation to compile- • Create a wrapper for time and removes the need to include glDrawRangeElements that omits start/ complex (and difcult to validate) GLSL end parameters for non-safety critical compilers in the OpenGL SC drivers builds and calls glDrawElements instead

Feature(s) Possibly • Code that compiles shaders at run-time Impacted for cross-platform compatibility or toolchain simplicity No Object Deletion

Workarounds • Remove any C/C++ shader compilation/ Change(s) testing/validation code and switch to • The following functions are removed: compile-time shader compilation glDeleteBuffers, glDeleteFramebuffers, glDeleteProgram, glDeleteRenderbuffers, glDeleteShader, glDeleteTextures

No Frame Bufer to Texture Transfers Rationale • Safety critical programs do not dynamically allocate memory, as Change(s) • The following functions are removed: memory exhaustion would cause glCopyTexImage2D, failure. Routines that dynamically glCopyTexSubImage2D release resources are not needed because the program will not stop executing or return to the operating Rationale system • Reading frame bufer into texture is used in games for special visual efects, mirrors, etc. There is no need Feature(s) to read screen pixels into a texture for Possibly • Libraries containing functions safety critical apps Impacted using exception-safe or Resource Acquisition Is Initialization (RAII) resource management techniques Feature(s) Possibly • Special post-processing visual flters Impacted applied to screen data (for example, Workarounds contrast enhancement) • Create a safety-critical branch that • Debug routines that grab screen shots omits resource deletion for shared for testing/validation purposes sources • Use #ifdefs to wrap or remove resource deletion for safety critical Workarounds builds • Use glReadnPixels instead

KDAB | the Qt, OpenGL and C++ experts 2 Safety critical programs do not dynamically allocate memory, as memory exhaustion would cause failure. And memory cleanup isn’t needed as the program shouldn’t stop executing or return to the operating system.

No glCompressedTexImage2D No Cube Maps

Change(s) Change(s) • The glCompressedTexImage2D function • The function glTexImage2D is is removed. Programs must use removed glCompressedTexSubImage2D instead • The functions glTexParameteri and glBindTexture will not accept a GL_ TEXTURE_CUBE_MAP parameter Rationale • The following constants are removed: • glCompressedTexImage2D re-allocates GL_TEXTURE_CUBE_MAP_NEGATIVE_X memory for a given texture, and GL_TEXTURE_CUBE_MAP_NEGATIVE_Y reallocating is forbidden. One must GL_TEXTURE_CUBE_MAP_NEGATIVE_Z use glTexStorage2D to allocate storage GL_TEXTURE_CUBE_MAP_POSITIVE_X (only once), then upload data into the GL_TEXTURE_CUBE_MAP_POSITIVE_Y texture via glTexSubImage GL_TEXTURE_CUBE_MAP_POSITIVE_Z

Feature(s) Rationale Possibly • Any graphics using compressed • Texture cubes are typically used for Impacted textures like background images or providing background to virtual reality dial/gauge texturing gaming environments and are not necessary for instrument clusters

Workarounds • Create wrapper for Feature(s) glCompressedTexImage2D that calls Possibly • Artifcial horizon indicator (or “8-ball”) glCompressedTexSubImage2D and grabs Impacted for aircraft/spacecraft full image • Sky texture above a 2.5D navigation • Use standard compression formats map

Workarounds • Use individual texture for each cube face • Use single tall texture with attribute- No Object Verifcation specifying faces; use special logic in fragment shader to grab attribute and Change(s) translate into texture y-ofset • The following functions are removed: glIsBuffer, glIsFramebuffer, glIsRenderbuffer, glIsShader, glIsTexture

Rationale • Typically functions that are used to test for valid objects before freeing resources are not needed if no resources can be freed

Feature(s) Possibly • Verifcation checks to ensure APIs Impacted being used correctly • Unit test frameworks

Workarounds • Remove validation • Use #ifdefs to wrap or remove resource deletion for safety critical builds

KDAB | the Qt, OpenGL and C++ experts 3 In Open GL SC, APIs that don’t pass bufer size or length are replaced with an equivalent “n” routine that does (for example, glReadnPixels instead of glReadPixels).

No glReadPixels No Uniform or Attribute Inspection

Change(s) Change(s) • The glReadPixels function is • The following functions are removed removed. Programs must use without replacements: glReadnPixels instead (added in glGetActiveAttrib, OpenGL ES 3.2) glGetActiveUniform • The functions glGetUniformfv, glGetUniformiv and glGetUniformuiv Rationale are removed. Programs must use • Passing size of the bufer allows glGetnUniformfv, glGetnUniformiv, checks that prevent bufer overruns or glGetnUniformuiv instead (added in OpenGL ES 3.2)

Feature(s) • Special post-processing visual flters Possibly Rationale Impacted applied to screen data (for example, • This family of functions are used contrast enhancement) to inspect the Open GL state. • Debug routines that grab screen shots The glGetActive* functions are for testing/validation purposes susceptible to bufer overrun unless they use dynamic memory allocation, neither of which is allowable Workarounds for safety critical applications. • If sharing source with code The glGetUniform* functions are earlier than OpenGL ES 3.2, wrap substituted for versions that pass the glReadPixels calls with macro bufer’s size, allowing prevention of that tests against bufer size or bufer overruns discards bufSize parameter and calls glReadnPixels • Otherwise convert all glReadPixels Feature(s) calls to use glReadnPixels and add Possibly • Debugging functions bufSize parameter Impacted • Unit tests and test scafolding • If using for debugging only, remove • GL state inspection calls

Workarounds • If sharing source with code earlier than OpenGL ES 3.2, wrap glGetUniform* calls with macro that tests against bufer size or discards bufSize parameter and calls glGetnUniform* • Convert all glGetUniform* calls to use glGetnUniform* and add bufSize parameter • Remove calls to glGetActiveAttrib and glGetActiveUniform

KDAB | the Qt, OpenGL and C++ experts 4 The family of functions that inspect the Open GL state are susceptible to bufer overrun unless they use dynamic memory allocation, neither of which is allowable for safety critical applications.

Conclusion

The future will dramatically increase the concern may be making safety-critical code number of embedded systems that we without using memory frees or reallocation – consider to be safety-critical and as we become avoiding C++ delete – which may require a bit more dependent on those systems, the more restructuring than just a handful of API consequences of their failure become more alterations. The diferences between OpenGL serious. Hence the need for standards like ES and OpenGL SC are limited to a handful of OpenGL SC. functions, many of which aren’t in common use. This breakdown shows that adopting OpenGL While implementing a functional safety process SC requires minimal changes to your existing may signifcantly impact your development, OpenGL ES source code and habits, which it won’t be due to OpenGL SC. A greater should be somewhat of a relief.

About the KDAB Group

The KDAB Group is the world’s leading software many among the Fortune 500. KDAB’s tools and consultancy for architecture, development and extensive experience in creating, debugging, design of Qt, C++ and OpenGL applications profling and porting complex applications across desktop, embedded and mobile help developers worldwide to deliver platforms. KDAB is the biggest independent successful projects. KDAB’s trainers, all full-time contributor to Qt. Our experts build run- developers, provide market leading, hands-on, times, mix native and web technologies, solve training for Qt, OpenGL and modern C++ in hardware stack performance issues and multiple languages. Founded in 1999, KDAB has porting problems for hundreds of customers, ofces throughout North America and Europe.

KDAB | the Qt, OpenGL and C++ experts 5