KhronosGroup / KSCAF_DocGuidelines

Khronos Safety Critical Advisory Forum’s guidelines for developing a safety critical technology specification.
1 stars 2 forks source link

EGL #35

Open bnaodovic opened 6 years ago

bnaodovic commented 6 years ago

Even one of the simplest of standards, EGL, is too complex for feasible implementation in the safety environment, where complexity refers to: number of API functions, types of their parameters, state-machine model and object-management model. This complexity only increases when even some of the extensions are added to the core-standard specification.

This issue is general. Titles of specific instances of this issue will be prefixed with the title of this issue.

gsikkens commented 6 years ago

While I agree in principle that simple is best for a safety environment, standards such as EGL have been successfully certified up to the highest DO-178B/C level, DAL A by a few safety critical graphics companies. To achieve this, the certified API is subset, not dissimilar to how OpenGL SC 2.0 is a subset of OpenGL ES 2.0 (well more to that...), however a safety critical EGL is not a Khronos standard so different vendors may define the subsets differently and not be compatible with each other affecting customer implementation and porting experiences. The same thing has occurred with OpenGL extensions. I believe there is also an exception that the EGL_EXT_compositor extension can be implemented in a safety environment,