EVE drives the GPU and the display itself. It does not sit on an operating system’s graphics stack or a GPU vendor’s driver, so the code between an application and the hardware, and the evidence for it, are EVE’s own. That is what a program needs when the display is the product: a cockpit upgrade, a crew’s 360-degree view from inside a vehicle, a product line built to last decades.
Certifiable by design
- C++17 with no heap, no exceptions, no RTTI and no run-time shader compilation: every shader is compiled ahead of time by the EagleFledge™ Compiler, HESolar’s own compiler for every GPU EVE drives, which records a review package for each one.
- EagleWatch™, EVE’s own health monitoring, watches the GPU, the displays and EVE’s resources while a product runs.
- Every memory footprint is reserved at build time; the configuration selects how much of it a product uses.
- Each application has its own GPU context and address space.
- A deterministic submission mode keeps every batch in the order the application issued it; performance products can opt into dependency-aware scheduling.
- Configuration is data, not code: set through EVE’s advanced, easy to use, and automated EagleFledge™ configuration tools, part of the certified baseline in a certified product.
Interference, measured and bounded
Bounded, statically reserved memory per context; frame-buffer compression on both GPU families (CCS on Intel, AFBC on Arm Mali) to cut DRAM traffic on the shared bus; and submission order as a configured property. Each window declares its frame rate, and EVE enforces it. Measured on an Intel PC with a memory-bound program running beside it, EVE’s GPU path paced to the display at 60 Hz costs that program nothing measurable, adding about 0.1 GB/s of memory traffic.
The whole display path, owned and configured
EagleView™, EVE’s display engine, drives the display hardware itself, with no windowing system or compositor between an application and the screen. A product declares its displays, windows and applications in configuration, and EagleView™ sets each display’s mode, places and isolates each application’s window, and presents its frames, the same way on Linux and on an RTOS.
- Several displays, several applications: designed for several displays and for several applications and contexts on each, every application in its own GPU context and its own driver-locked region of the screen, so one cannot draw over another.
- Presentation chosen per product, from zero-copy direct scanout, where each window renders straight into the displayed buffer, to hardware plane composition and a compositor where overlapping windows need one.
- Frame pacing to suit the product: locked to the display for steady motion, or free-running for maximum throughput.
- One configuration model across boards: displays and windows are declared the same way on every Intel and Arm Mali board EVE supports.
Each API a driver of its own
EVE’s OpenGL® SC 2.0 and Vulkan® SC 1.0 are separate, distinct drivers. Each implements its own API directly over EVE’s hardware layers, Eagle and Vision, with its shaders compiled ahead of time by the EagleFledge™ Compiler. Neither is built as a translation layer over the other: an OpenGL SC application runs on a driver designed for OpenGL SC, with no Vulkan SC underneath it, and a Vulkan SC application carries no OpenGL SC state. Each API is tested against its own Khronos conformance suite, and each keeps its own performance and its own certification evidence.
CPU and GPU, together
EVE is adding a certifiable multicore CPU renderer behind the same GL front end and program store, so a program can put each layer, or each operation, on the engine that suits it.
- In development: the CPU renderer runs the full OpenGL SC 2.0 conformance suite with 0 failed of 14,484 cases both on an Intel PC and on the Arm cores of an NXP i.MX 95, where it draws frames byte-identical to the PC’s.
- Paced at 30 Hz on four cores, it holds every frame and costs a neighbouring application nothing measurable, the property a multicore safety argument needs.
- Deterministic: a frame is the same, byte for byte, whatever the number of cores it is drawn on.
- Its shaders are compiled ahead of time by the EagleFledge™ Compiler, as a GPU’s are, and it needs no GPU and no kernel driver.
- OpenCL kernels run on the same CPU path with the same results as on the GPU.
Why both engines, not a CPU-only driver
Rendering on the CPU does not by itself remove interference; it moves it. A CPU renderer shares the processor’s caches and memory with every other application. Measured on the same Intel PC, with a memory-bound program running beside each of EVE’s paths:
| EVE’s path | The program beside it |
|---|---|
| GPU, paced to the display at 60 Hz | No measurable cost; about 0.1 GB/s of added memory traffic |
| CPU renderer, paced at 30 Hz | No measurable cost |
| CPU renderer, flat out | 5 to 11 percent of its memory bandwidth lost, and its memory latency 12 times more variable |
| GPU, flat out (about 18,000 frames a second) | 31 to 38 percent of its memory bandwidth lost |
Run flat out, a CPU renderer interferes as a GPU does. What bounds interference is the rate each path is declared to run at, and EVE enforces it on either engine. So EVE gives a program both, under one front end, one configuration and one set of compiled programs:
- The GPU where a display needs headroom: osgEarth 3D terrain with a city’s buildings at 3840 x 2160 with 4x multisampling runs at 61 frames a second under DDC-I Deos, a far heavier load than flight symbology at 1080p.
- The CPU where a board has no GPU to spare, or a layer is best kept off it, with its conformance published: the full OpenGL SC 2.0 suite, on x86 and on Arm.
- Not tied to one processor or one RTOS: the same application on Intel and Arm processors, on the GPU under Linux and DDC-I Deos, and on the CPU under Linux today.
- Several applications on one display, each drawing directly into its own driver-locked region of the screen, with no compositing copy.
- Independent checking, on the roadmap: the CPU re-renders a critical layer and compares it with the GPU’s output, a monitor no single rendering path can offer.
Status at a glance
| Capability | Status |
|---|---|
| OpenGL ES 3.2 and OpenGL SC 2.0 on Intel Xe and Arm Mali GPUs | Available |
| DDC-I Deos and Linux | Available |
| Static footprints, ahead-of-time shaders, run-time YAML configuration | Available |
| Deterministic in-order submission; dependency-aware scheduling | Available; dependency-aware opt-in per product |
| Frame-buffer compression (CCS, AFBC) | Available |
| Several applications on one display, Mode 1 | Available |
| Mode 2 layered planes | Designed |
| Several displays per board | Designed |
| Declared, measured interference budget | Available: a declared frame rate per window, enforced, with the measured results above; a declared core set and memory budget in development |
| Certifiable CPU renderer | In development: OpenGL SC 2.0 suite, 0 failed of 14,484 on Intel and on Arm |
| Hybrid divisions: by layer, by operation, dissimilar monitoring | Roadmap |
| OpenCL 3.0 (embedded profile) | Available on Intel Gen12, Arm Mali and the CPU; on Intel, all 34 Khronos conformance test programs for the features EVE offers passing every test, subgroups and work-group functions included |
| Vulkan SC 1.0 | In development: compute on Intel Gen12, the Khronos conformance tests’ compute groups passing with 0 failures; graphics on Intel Gen12 and Arm Mali, the vkmark benchmark’s 13 scenes and VulkanSceneGraph’s scenes rendering on both, and presenting to a display |
| EagleStream™: live video with overlays, camera, network and avionics video in, hardware decode, zero-copy import | In development |
| NPU / AI acceleration | Roadmap |
| Other RTOSes | On request |