Every comparison, nothing hand-picked. Each row runs the same application on the same board, once on EVE and once on the GPU vendor’s own production graphics driver: the highly optimized consumer-grade driver the vendor ships for Linux (Mesa iris on Intel, Arm’s and NXP’s libmali on Mali). Those drivers do not run on DDC-I Deos, so a Deos row compares EVE under Deos with the vendor’s driver under Linux on the same board. The ratio is EVE’s result divided by the vendor driver’s; above 1.0, EVE is faster.
| Board | OS | Workload | Vendor driver | EVE ÷ vendor |
|---|---|---|---|---|
| COTS Raptor Lake board (Intel) | Deos (vs vendor under Linux) | osgEarth Boston, 3840 x 2160, 4x MSAA | Mesa iris | 0.90 |
| COTS Raptor Lake board (Intel) | Linux | osgEarth Boston, 3840 x 2160, 4x MSAA, presented | Mesa iris | 0.99 |
| COTS Raptor Lake board (Intel) | Linux | osgEarth Boston, 3840 x 2160, 4x MSAA, not presented | Mesa iris | 1.10 |
| Intel NUC 13 Pro (Core i7-1360P) | Linux | glmark2, all 33 scenes | Mesa iris | 1.36 |
| Intel Alder Lake-P PC (Core i7-1260P) | Linux | glmark2, all 33 scenes | Mesa iris | 1.39 |
| AMD Versal VEK385 (Arm Mali) | Linux | osgEarth Boston, 1920 x 1080, 4x MSAA | Arm libmali | 1.09 |
| AMD Versal VEK385 (Arm Mali) | Linux | the same, EVE’s toolchain baking the buildings | Arm libmali | 2.49 |
| AMD Versal VEK385 (Arm Mali) | Linux | glmark2, all 33 scenes | Arm libmali | 1.49 |
| AMD Versal VEK385 (Arm Mali) | Deos (vs vendor under Linux) | glmark2, all 33 scenes | Arm libmali | 1.62 |
| NXP i.MX 95 (Arm Mali) | Linux | osgEarth Boston, 1920 x 1080, 4x MSAA | NXP libmali | 1.30 |
| NXP i.MX 95 (Arm Mali) | Linux | the same, EVE’s toolchain baking the buildings | NXP libmali | 2.59 |
| NXP i.MX 95 (Arm Mali) | Linux | glmark2, all 33 scenes | NXP libmali | 0.92 |
| NXP i.MX 95 (Arm Mali) | Deos (vs vendor under Linux) | glmark2, all 33 scenes | NXP libmali | 0.91 |
glmark2 ratios are the geometric mean of 33 per-scene ratios; osgEarth ratios compare frames per second over the same flight.
Every glmark2 row runs off screen on both drivers, so neither result includes putting frames on a display. On a Linux desktop the vendor driver’s frames also pass through the desktop compositor, while EVE drives the display itself with no compositor in the path. That is a real advantage for EVE in a product, like the toolchain gains below, but it belongs to the system rather than to the driver, so these rows leave it out.
Where EVE is behind, and why it is shown
Four comparisons sit below 1.0: osgEarth on the COTS Raptor Lake board under Deos (0.90), the same flight presented on Linux (0.99, level within run-to-run noise), and glmark2 on the i.MX 95 (0.92 on Linux, 0.91 under Deos). They stay on this page until they move.
Toolchain gains are marked separately
The two lighter bars (2.49 and 2.59) come from EVE’s toolchain preparing a scene’s buildings ahead of time, not from the driver alone. They show what the driver cannot do by itself: on the VEK385 the same osgEarth flight goes from 1.09 times Arm’s driver to 2.49, and on the i.MX 95 from 1.30 to 2.59, when EagleFledge™ prepares the scene before the product ships.
EVE is a driver. EagleFledge™ is everything around it.
Those two bars come from one part of EagleFledge™, EVE’s SDK. EagleFledge™ is delivered as Feathers: tools, services and APIs, each licensed on its own, that a team developing a product uses, and that carry the product line after it ships.
For the developer: the same tools EVE is built with
EagleFledge™ Compiler
Every shader compiled ahead of time for the GPU it runs on, with a review package for certification. Nothing is compiled while the product flies, and the toolchain gains above start here.
EagleDesigner™
A product’s displays, applications and graphics contexts set up in one configuration view, or by the eagle command, from Visual Studio Code, Eclipse-based IDEs including DDC-I OpenArbor, or Qt Creator.
EagleFlight™
The tools a program already uses, running on EVE: Pace VAPS XT, ENSCO IData, OpenSceneGraph and osgEarth, with product templates and configurations verified by measurement.
For the product line: one application, many boards, no lock-in
EVE Open BSP
Applications are written against EagleSystems™ and the EVE C API, not against an RTOS or a board. Threads, events, memory, time, files and logging behave the same on Linux and on DDC-I Deos, so the operating system becomes a choice, not a dependency.
EagleTransform™
Carries an application to another board, operating system or both by configuration. It writes the new configuration beside the original, shares the source, and lists every remaining call to an operating system’s own API, so a port is a checklist rather than a rewrite.
EagleFlightTest™
Runs the same product on several candidate boards, our Perches, and records every result with the exact configuration it came from: board, memory, operating system, EVE release and compiler. Compare the boards side by side before committing a product line to one.
Evaluate, then plan. EagleFlightTest™ is the regimen every Perch on this page was brought up under, and it runs on every change to EVE. The same measurements that produced this page can be run on the boards a program is considering, so board selection, frame-rate margin and the cost of the next product in the line are decided from numbers measured on that hardware, not from a datasheet.
For the years after: EagleCare™
A knowledge base built on real boards
Troubleshooting by Perch: every fault met and resolved while bringing EVE up on each board and operating system, listed by what the board actually prints and what to do about it.
Analysis that finds the cause
EagleFlightTest™ analyses the commands EVE sends the GPU, checked against HESolar’s Reference Analysis of each GPU’s reference software, to show where time goes and what to tune.
Updates and support
New releases and fixes arrive as EagleMolt™ updates for the program’s own Feathers and boards, with support through EagleCare™ Aerie for the term of the agreement.