I am really curious, what do vendors like Garmin, Dynon use ?
Vulkan / Vulkan SC are barely making their way in the automotive industry and I haven’t heard anything related to the aerospace industry.
The rest of the graphics API are irrelevant for anything related to embedded systems and real time.
Do they make and maintain their own API for their drivers? That sounds incredibly expensive and adds another layer as to why avionics are so expensive.
I looked this up. Vulkan / Vulkan SC is a driver for Nvidia graphics hardware, so the context would be a “Windows PC in a box”, no? Not sure how much GA stuff uses a Windows PC in a box. Under this thread, one of the four links is this but that product line is now dead.
I am fairly sure that Garmin or Dynon don’t use Windows. The hardware is also a hostage to fortune – see above thread.
If you use a PC in a box, development is actually really easy. Get M$ VC++ and off you do. No need to mess with graphics drivers; it’s all done for you. But it is problematic for a long product life.
If you check the Avionics Internals thread you will see all kinds of funny old processors being used. It’s pretty obvious that a lot of these must be painful now, on the availability front. But most avionics can use a frame buffer and with a fast CPU that makes graphics pretty easy. I am currently doing embedded graphics like this and that is done via unidirectional SPI at 10-20MHz, which would be fine for an instrument like an HSI but not for a large display like a G1000 displaying terrain and such.
Peter wrote:
Vulkan / Vulkan SC is a driver for Nvidia graphics hardware
Vulkan is a general graphics API that is intended to serve as a successor to OpenGL, without complete backwards compatibility. So no, it is not Nvidia-specific, nor Microsoft Windows specific. As far as I understand, it does require quite some features from the GPU, so maybe the ones in avionics are not featureful/powerful enough for Vulkan, if they even have one? For simple stuff they could theoretically use a pure CPU implementation of Vulkan I assume…
@Peter Vulkan is platform agnostic.
Vulkan / Vulkan SC (safety critical) are specifications developed by a company called Khronos Group in cooperation with different vendors, such as Nvidia, Amd, Arm…etc.
Nvidia aren’t the only vendors that implement Vulkan drivers for their hardware, there are many others, such as Raspberry Pi and the OS is irrelevant since Vulkan doesn’t have any windowing and window surface capabilities, you have to use the OS’s / Firmware windowing API to display stuff.
OK; thanks.
I am going to drop in a bit of sacrilege 
The basic thing here is that avionics products don’t need fancy graphics. This isn’t gaming where you have super slick 3D rendering, and especially overlapping moving objects which need sophisticated storage of the “damaged” background areas, resulting in potentially non-deterministic memory management issues. I don’t know how games are done today (except, obviously, when you have 32GB RAM then nobody will care about 100MB of heap frag) but in the embedded sphere you can read up on e.g. LVGL and how that does it; I avoided LVGL since I don’t need it, and anyway it is a lot of code, plus I don’t have video memory readback, nor do I have enough RAM for a frame buffer, but a lot of people use it.
Most of the stuff I’ve seen is clearly done with filled polygons. In fact most of it is is not even polygons; it is filled rotated rectangles and filled circles. These are usually drawn using scanline algorithms – just as I used in that clock display. Then you have basic fonts. If you have enough CPU power you tidy it up with anti aliasing. The bits done with polygons would be synthetic vision (SV) terrain depiction, where the data would be stored like that anyway.
Also the avionics manufacturers re-use existing technology as far as they possibly can. And this tech is many years old. To adopt new stuff if the old stuff works is just a bad business risk decision. I know that doing that is bad news for the CVs of their coders (and that runs to the core of problems we see e.g. practically all engineering expertise of HBK leaving en-masse c. 2003, with similar seen at Sandel and probably Avidyne) but the coders don’t own the company and aren’t personally responsible for problems in the field.
And what is “safety critical” about graphics? I know there is a long history of crash bugs in graphics drivers but that is because a lot of those drivers were written by “kids”, as is traditional in a fast moving retail market. It’s often said that the worst code comes from coding communities which have sofas at the office and which can go surfing after work. The only real assurance of bug-free code is proven operation in the field.
Software certification means practically nothing; it tends to drive silly compliance practices like one function per file (e.g. the KFC225; I spoke to one of the devs) which produces almost unreadable code. In automotive coding there are good guidelines e.g. no heap usage and no recursion (always a great idea!) and in some cases only static variables (which is a bit extreme), then you have MISRA which was big fashion some years ago but is really just good coding practice. You get into great debates like “int” versus “int16_t” but that matters only if changing the hardware or the compiler. I would drive C coders crazy by saying I avoid pointers (I use defined size arrays) but you can’t deny that pointers have been responsible for the vast majority of bugs ever since the PC came along I also never change the GCC tool version on a given product, after release.
Peter wrote:
I am going to drop in a bit of sacrilege
It’s not sacrilege, it’s a scripture
There’s one more reason to keep the graphics simple: ergonomics. There is no need to reinvent the wheel, the amount of research that went into user interface ergonomics in the aerospace industry is probably greater than in all other industries together. For a user working under pressure, excessive UI features only offer distraction. A flat UI is better than fake 3D, brief text labels are better than graphic icons, etc.
https://careers.garmin.com/jobs/15471?lang=en-us&previousLocale=en-US
While most of the job ad is fluff, this might give some insight
Experience developing 2D/3D user applications
Experience with 2D/3D graphics APIs (OpenGL, Vulkan, Metal), rendering technologies, and a strong expertise in math
Experience in writing efficient GPU shader algorithms
Knowledge of GPU architectures.
Experience in low-level, kernel, and embedded programming.
Experience with profiling and debugging tools for GPUs and embedded systems.
I did a google on Garmin hardware etc a few days ago, and they are putting a lot of work into airliner systems now. Apparently they use custom multicore processors too.
I dont think this is GA.
