YakoGLTI AM62P
Verdin AM62P
Imagination PowerVR BXS-4-64
eMMC · U-Boot
Requires separately supplied GPU firmware.
Portable OpenGL ES for embedded GPUs
Slint on Zephyr.
Running on the real GPU.
That is the demo. YakoGL is the layer beneath it: a portable OpenGL ES and EGL implementation that drives embedded GPUs without depending on an operating-system GPU driver stack.
Proven today on Zephyr · OS-independent no_std core · C ABI
A conceptual split
Application / UI toolkitSlint UI · FemtoVG
CPU side
Zephyr
scheduling · devices · application runtime
GPU side
YakoGL
OpenGL ES / EGL · shaders · GPU back ends
CPUArm cores
GPU
PowerVRVivanteBroadcom V3DMali-G610 · WIP
SoCAM62P · i.MX8MP · BCM2711 · RK3588 WIP
The demo is concrete. The layer is general.
Not just Slint.
Not just Zephyr.
Slint on Zephyr is the main showcase because it makes the result visible: a modern UI, rendered by the real GPU, without a Linux GPU stack. It exercises the same OpenGL ES and EGL implementation available to other clients and platforms.
YakoGL keeps the graphics core and GPU back ends OS-independent. Platform-specific work sits behind a small OS abstraction.
Applications
OpenGL ES clientsSlint · FemtoVG · glmark2 · your renderer
Platforms
OS-independent coreZephyr — proven · bare metal · other OS integrations
GPUs
Multiple back endsPowerVR · Vivante · V3D · Mali in progress
Three proven targets. One active port.
Try it on Zephyr.
The first three targets are hardware-proven on Zephyr today. NanoPC-T6 / Mali-G610 is the next target and is shown explicitly as work in progress.
Start with AM62P ↗
NXP i.MX 8M Plus
Verdin iMX8M Plus
Vivante GC7000UL
eMMC · U-Boot
No separate GPU firmware needed.
Broadcom BCM2711
Raspberry Pi 4
Broadcom V3D 4.2
SD card · Pi firmware
Tested with a 1920 × 720 HDMI display.
WIP · Rockchip RK3588
FriendlyElec NanoPC-T6
Arm Mali-G610
Linux / panthor path running
YakoGL's Mali back end is active; the Zephyr path is being brought up and validated.
Support gate. NanoPC-T6 remains WIP until the Zephyr path reaches the same board-level validation standard as the three supported targets.
Evidence you can inspect
Measured on
real hardware.
Project-run dEQP-GLES2 tests report zero failures on the three boards. Every result links to its published record, measurement date and build identifier.
These are the project’s own test runs, not Khronos conformance certification. Pass, unsupported and warning counts, test scope and performance limits are explained on the status page.
Inspect tests, benchmarks and known limits →A familiar API. A different stack.
Your application,
all the way
to the GPU.
YakoGL handles GPU bring-up, shader compilation and command submission. Its GPU and display drivers live alongside the graphics library.
Explore the architecture →Keep the graphics API.
Use the standard OpenGL ES 2.0 and EGL headers. C and C++ applications link
libyakogl.a; Rust applications can use the crate directly.Choose when shaders compile.
Compile GLSL on the board, precompile your application’s shaders, or combine both. The shader guide explains the trade-offs.
Inspect the whole path.
A
no_stdRust core, GPU back ends, OS abstraction and drivers in one repository. Zephyr is the tested board path; bare-metal integration is described in the build guide.
Build, evaluate, inspect
Take the
next step.
Run YakoGL on supported hardware, inspect the implementation, or review the measured results.
Run it on hardware →- How it worksThe layers, GPU back ends and shader choices.
- Current statusBoard results, performance and work in progress, including ES 3.0 and Mali.
- Build and integrateBuild options, linking and the application contract.
- Report an issueReport a reproducible defect or other technical issue.
YakoGL
Named after yakogai, the turban shell whose nacre is used in raden inlay. Also: “yet another kernel-optional GL”.
Built by Signal Slot. YakoGL’s own code is Apache-2.0. Third-party code and firmware have their own terms; see NOTICE and the licensing notes.