You at ALT or are there other players in that? In discussions about regulation, I often tell people one of the biggest ways of showing its value is that DO-178B caused a company to attempt a high-quality driver for Radeon that they wouldn't build themselves. ;)
I'm very curious about your experience in that market. Especially whether the GPU vendors give you enough information under NDA to make them reliable, if you mostly black-box it using a subset of their features, and so on. Also, the QA techniques you use in such scenarios. I think some of tricks on your end might be applicable to other types of hardware.
I'm at CoreAVI. As far as I know, ALT had some financial troubles that ruined the company (this was all before my time, I'm too young to have been involved in that :P ). Like half the senior employees are ex ALT employees who jumped ship once ALT started hemorrhaging money. We have a great relationship with AMD, we don't just do certified drivers for their chips, but we also temperture screen some of their GPUs and sell them in the industrial market. They give us a lot of documentation and will answer our questions directly. Although nowadays with all the stuff they release to the open source community I'm not sure if we are getting that much more information compared to everyone else. We do work with other GPUs such as the Verisilicon GC series, Intel HD, and most recently we started working with ARM. For Verisilicon & Intel, we don't really get as much support and we mostly work off the documentation they have released and reverse engineering on our part. The ARM partnership is fairly new so I can't speak too much about it, but from the outset they are looking to be a great partner like AMD.
For graphics APIs we implement a subset of OpenGL or Vulkan listed under their safety critical standards. We are part of Khronos and worked with them to define the OpenGL SC 2 standard and are currently working on defining the Vulkan SC standard. The saftery critical version of the APIs are a reduce subset that eliminate anything that would be more difficult to implement in certifiable code.
As for our QA process, its really split into two distinct things. There is just normal QA side with all the run of the mill testing and verification, and then there is the actual certification team who is responsible for meeting all the DO-178 requirements as defined by our process. Like a lot of other companies who do cert work, we don't create all the artifacts from the get go. There are a lot of defense contracts where they want "certifiable" but don't want to pay for the actual evidence, so we won't go out of the way to make it, if no one is buying it. We do have a strict coding standard and code reviews to ensure that any code checked in will actual be able to be certified, but certification is way more work than just writing the code. Once we have a paying customer for cert we will go through and write all the test cases, fill out all the requirements, and make sure every i is dotted and t are crossed.
