YakoGL

Inside the stack

From your application
to the GPU.

Standard graphics APIs above. GPU bring-up, command submission and shader compilation below.

Build the Slint demo →

The driver’s work,
in the library.

A GPU normally sits behind a large driver stack in a full operating system. YakoGL puts that work in the library. The GPU and display drivers it needs live in the same repository.

  1. 01

    Boot

    It brings up the GPU itself.

    Power, clocks, GPU memory and, on the PowerVR, the firmware; then command streams and completion. No kernel driver in between.

  2. 02

    Compile

    Its own GLSL ES compiler, on the board.

    A no_std, allocation-free compiler with one back end per GPU, or a precompiled table, or both. How to choose.

  3. 03

    Link

    One source, three GPUs.

    The GL core and the supported GPU back ends are one no_std Rust crate with a C ABI (libyakogl.a). C, C++ and Rust applications link it alike: glmark2, the Khronos conformance tests and the Slint UI toolkit run on it.

Five
layers

From the application down. Only the shader back end and the OS abstraction are pluggable; everything above the OS abstraction is portable Rust.

YakoGL layers An application calls the GL and EGL core. The core resolves GL state into one draw for the single GPU back end of the build: PowerVR, Vivante GC7000 or Broadcom V3D. The shader compiler turns GLSL into the GPU's code, on the board or precompiled. Below, the C OS abstraction for Zephyr, bare metal or a Linux host build, then the GPU and display drivers, then the GPU. Application an ordinary GL ES 2.0 + EGL client: Slint, FemtoVG, glmark2, dEQP, your code GL / EGL core src/gl, Rust, no_std: entry points, errors, objects and state; draw.rs resolves the GL state into one draw for the back end Shader compiler src/shaderc: GLSL ES to the GPU's code, on the board, or precompiled, or both one back end per build PowerVR src/pvr: VDM / PPP / PDS streams, firmware kicks Vivante GC7000 src/vivante: LOAD_STATE command streams Broadcom V3D src/v3d: control lists, binner and renderer jobs OS abstraction (C) src/osal, the only OS-facing layer: Zephyr; bare metal; Linux host build without a GPU GPU and display drivers driver/: GPU bring-up, firmware boot, memory, command generators, panels GPU: PowerVR BXS-4-64 · Vivante GC7000UL · Broadcom V3D 4.2
After DESIGN.md, "Layering". The PowerVR back end also calls the driver's OS-free C command generators directly. C/Rust struct layouts are pinned on both sides, so drift fails the build.

Shaders

Compiled on the board, before it, or both.

A GL application hands the library GLSL source at run time, so an ES 2.0 stack needs a shader compiler. YakoGL has its own: lexer, preprocessor, parser, semantic checks, an IR, and one back end per GPU. Where a shader's machine code comes from is chosen when the image is built.

  1. A

    The compiler only

    The default in Zephyr and CMake: GLSL ES source, compiled when the application asks.

  2. B

    Precompiled in front of the compiler

    The application's known shaders are compiled by the same compiler while the image is built; a hit runs no compile, a miss compiles.

  3. C

    Precompiled only

    No compiler and no scratch memory in the image; a shader the table lacks is refused by name.

The trade-off is measured, not assumed. On the AM62P the compiler costs bytes of flash plus about 5.2 MB of RAM for its working memory; a precompiled table for one test application costs bytes of flash and grows with the application's shader set. So precompiled shaders are an option for an image that wants no compiler, not the default.

Compiler:
Table:

The online compiler and precompiled application shaders use YakoGL’s compiler. The bare-metal make build defaults to a Mesa reference table for measurements; choose the shader mode explicitly for your image. Some of the PowerVR driver’s own programs still use Mesa’s pco output. The README records the current boundary and build options.

Integration details

Use the build and linking guide for C, C++ and Rust applications, and DESIGN.md for the full architecture. The status page separates measured board support from work in progress.