# CyberEther: a GPU signal processing framework that picks your graphics API for you > CyberEther is a C++ framework for real-time signal processing and visualisation that abstracts over Vulkan, Metal and WebGPU, ships a browser build powered by WebAssembly, exposes a Python API called Superluminal, and comes with a flowgraph editor for building pipelines. Its compute backends are the unfinished part. **luigifcruz/CyberEther** — High-performance GPU-accelerated signal processing and visualization framework that runs anywhere. - Repository: https://github.com/luigifcruz/CyberEther - Website: https://cyberether.org - Stars: 863 · Forks: 58 - Language: C++ - License: MIT - Published: 2026-10-20 · Updated: 2026-10-20 · Language: en - Canonical page: https://hysenlabs.com/projects/luigifcruz-cyberether ## One framework over three graphics APIs CyberEther is described as a high-performance GPU-accelerated framework for real-time signal visualisation and data processing, and the repository description calls it a signal processing and visualisation framework that runs anywhere. The mechanism it uses to run anywhere is stated plainly in the compatibility section: the build system automatically chooses between the three graphical backends available, Metal, Vulkan or WebGPU, depending on the target device. That is the central abstraction. Rather than requiring you to write a Metal path for Apple hardware, a Vulkan path for Linux and Windows and a WebGPU path for the browser, the framework picks one at build time, and the README frames the choice as low-level graphics APIs used to reach native performance on any platform. The languages are mixed in a deliberate way. The core is C++, with a Meson build, a main.cc at the root, headers under include/ and sources under src/. On top of that sits a Python package called Superluminal, distributed through meson-python, and the README lists a Python API for custom signal visualisation via Superluminal as one of the headline features. The project is MIT licensed, was created in 2021 by Luigi Cruz as a personal project, and the README notes that talks about it were given at previous GNU Radio Conference editions. The repository topics cover cuda, gpu, metal, vulkan, webgpu, sdr and signal-processing, which is a fair summary of where this sits between a radio tool and a graphics framework. The release pace is fast. v1.13.1 was published on 2026-10-07, v1.14.0 on 2026-10-15 and v1.15.0 on 2026-10-17, and the last push was on 2026-10-20, so the code is moving daily. ## The browser build needs no installation at all The second headline feature is an installation-free, fully featured web application powered by WASM and WebGPU, and the README links a try-online page on the project site for it. That is a genuinely unusual thing for a signal processing framework to offer. The usual pattern for a native DSP tool is a Python wheel, a container, or a system package, each of which needs a local runtime. A WebAssembly build of the same engine means a browser tab has the same pipeline editor and the same visualisation code, which is exactly what you want for sharing a receiver configuration with a colleague, for a demo on a machine you do not control, or for a read-only viewer in front of a customer. It also means the web build is not a separate product. The framework is the same code, compiled through WebGPU instead of Vulkan or Metal, and the browser path gets a WebGPU implementation where a native path gets Metal or Vulkan. That is why the backend selection is a build time decision rather than a runtime one, and it is why the compatibility table matters: the same source has different capabilities depending on which path it was compiled for. The third feature in the list completes the triangle. Alongside the local graphics support and the web build, there is a low-latency remote interface for headless servers and edge devices. A headless machine has no display and may not have a usable graphics stack, so the framework pushes its interface out over the network instead, which is what lets a server at the edge of a network run a receiver and still be monitored and controlled. Together those three are the answer to the question of where the visualisation happens: on your machine, in a browser, or on a remote box. ## Superluminal is the Python surface, and it is built with meson-python The Python package is called Superluminal, and its description in the project file is a good summary of the intent: a multi-platform GPU-accelerated interface for compute-intensive pipelines, followed by the phrase radio, the final frontier. The build configuration is unusual for a Python package and worth looking at, because it explains a lot about how the project is organised. The build backend is meson-python, and the build requirements are numpy, meson at 1.0.0 or newer, and meson-python itself. So the Python package is not a wrapper around a prebuilt binary that is downloaded at install time. It is compiled from the same C++ sources as the framework, with Meson driving the build, and the Python side is the binding layer over it. That is why the install options in the project file include skipping subprojects and installing only the tags marked for Python. The native dependencies of the framework, the shader compilers and the graphics stacks, do not all belong in a pip install, so the Python packaging deliberately narrows what it takes. The package requires Python 3.9 or newer and the classifiers list 3.9 through 3.12, and the development status is marked as alpha. The intended audience is declared as science and research and as developers, and the topics are libraries and scientific and engineering software. The operating system classifiers cover Linux, POSIX and Unix. The repository layout backs this up. There is a python/ directory, an examples/superluminal/ directory, and the examples folder also holds flowgraphs, plugins and a jetstream directory, so the Python API is exercised by examples rather than only documented. The one thing to keep in mind is the project's own warning, which appears in the contributing section: the project is still in its early stages, the API is not stable and it is subject to change. For a research tool that is a fair trade, and for anything with a support commitment it is not. ## The flowgraph editor is the working surface The README describes a modern flowgraph editor for building and running real-time pipelines, and that is the part of CyberEther that most directly affects how you work. A flowgraph is a visual arrangement of processing blocks and their connections, and it is the model that GNU Radio made standard, which is consistent with the project's origins and with the SDR topic. The difference CyberEther adds is that the blocks run on the GPU, and that the same graph can be edited in the native application or in the browser build, since the editor ships with the web version too. The examples directory shows the shape of the work. There is an examples/flowgraphs/ directory for the graphs themselves, an examples/plugins/ directory for custom blocks, an examples/jetstream/ directory whose name points at the JetStream data format, and the examples/superluminal/ directory for the Python side. So the intended workflow is to build a graph, drop in a plugin when the built-in blocks are not enough, and drive the result from Python. The remote interface ties into this. On a headless server or an edge device there is no screen for the editor, so the graph is configured and monitored from elsewhere over the low-latency remote interface, which is the difference between a signal processing library and a system you can deploy on a Raspberry Pi in a cabinet. The native plugins are what make the graph extensible beyond the built-in blocks, and the plugin examples directory is where you would look to see what that interface looks like before writing your own. ## Compute backends are the part that is still in progress The compatibility section is the part of the README to read carefully, and it contains the project's most important limitation in a single sentence: the development of compute for CUDA, Vulkan and WebGPU is currently in progress. It is worth separating the two halves of the framework. The graphics side, the visualisation and the display of results, is what the three backends currently cover, and the build system picks one for you. The compute side, running the signal processing itself on the GPU, is the part still under development across all three compute backends. The distinction decides who this project is for right now. If your work is a pipeline that produces a visualisation, the framework is in a usable state. If your work is a pipeline that depends on GPU compute, you are adopting something whose compute story is in progress, and the compatibility table in the documentation overview is the place to find out how far along each backend is. The compatibility section also frames the reach: CyberEther can run in virtually any modern device with a graphics card. The installation list is broader still, covering macOS, Linux, Windows, iOS and iPadOS, Android, the Raspberry Pi and the browser. So the honest summary for an evaluator is a framework whose portability story is its strongest feature and whose compute story is its weakest, and the two are separable only by reading the compatibility table carefully rather than trusting the marketing line. ## The container shows the real dependency surface The Dockerfile in the repository root is the most honest inventory of what the framework needs, and it is long. The build stage installs the usual toolchain plus a set of shader and graphics compilers: build-essential and pkg-config, then bison, flex and nasm, then spirv-cross and glslang-tools, which are the tools that compile and cross-compile shaders for the different backends. The graphics stack for Linux is covered by libwayland-dev with wayland-protocols, libxkbcommon-dev, libglvnd-dev, libx11-xcb-dev and the X extensions, libdrm-dev, libudev-dev, and the Mesa Vulkan drivers with the Vulkan validation layers. On top of that sit Python 3 with pip, and a pip install of meson, ninja, numpy and mapbox_earcut. The last entry is worth noting. Earcut is a polygon triangulation library, and it appears here because a framework that draws complex shapes has to triangulate them, which is exactly the kind of unglamorous dependency that tells you the graphics side is doing real work rather than only blitting textures. Then there is ONNX Runtime. The Dockerfile takes the ONNX Runtime version and the CUDA major version as build arguments, and it selects the matching GPU package for the architecture. The comment explains the special case: upstream ONNX Runtime publishes Linux CUDA binaries for x86_64 but not for arm64, so the arm64 image uses an NVIDIA archive and layout instead, with the version, the URL and a SHA256 checksum given as arguments. That arm64 handling is a small sign of how seriously the embedded targets are taken, and it also shows the cost of the platform breadth, since supporting a device means carrying a second binary source for it. The licence is MIT, and the README adds two conditions worth reading: all contributions are considered to be licensed under the same terms, and the use of the CyberEther name requires prior authorisation. The acknowledgements page lists the third-party software and their licences. ## Conclusion Adopt CyberEther if you are building real-time signal processing or visualisation pipelines and want one codebase that runs on a workstation, an embedded board, a headless server or a browser tab, since the backend selection is automatic and the web build needs no installation. Do not adopt it if your work depends on GPU compute today, because the README says compute for CUDA, Vulkan and WebGPU is still in progress, and do not build a product on its API without pinning a version, because the project says explicitly that the API is not stable. Before you commit, check the compatibility table in the documentation for your specific device and backend, and read the acknowledgements page, since the framework links a substantial set of third-party components and the name itself requires prior authorisation. ## FAQ ### What is CyberEther and which graphics APIs does it support? CyberEther is a C++ framework for GPU-accelerated real-time signal processing and visualisation. The build system automatically chooses between the three graphical backends available, Metal, Vulkan and WebGPU, depending on the target device, and the compatibility table in the documentation overview lists the current support. ### Can I run CyberEther in a browser without installing anything? Yes. The README lists an installation-free, fully featured web application powered by WASM and WebGPU, with a try-online page on the project site. The same framework is also available as pre-built binaries, an AppImage and tar.gz for Linux, an MSI for Windows and a PKG for macOS, and it runs on macOS, Linux, Windows, iOS, Android and the Raspberry Pi. ### What is the Superluminal Python package? Superluminal is the Python API of CyberEther, a multi-platform GPU-accelerated interface for compute-intensive pipelines. It is built with meson-python, so the Python package is compiled from the same C++ sources rather than wrapping a downloaded binary, and it requires Python 3.9 or newer and is marked as alpha. ### Is the GPU compute support in CyberEther finished? No. The README states that the development of compute for CUDA, Vulkan and WebGPU is currently in progress. The graphics side, which produces the visualisation, is covered by the three backends, and the compatibility table in the documentation overview is the place to check how far each compute backend has progressed. ### Is the CyberEther API stable? Not yet. The contributing section says the project is still in its early stages, that the API is not stable and that it is subject to change. The licence is MIT, all contributions are accepted under the same terms, and the use of the CyberEther name requires prior authorisation. ## Sources - [License: MIT](https://github.com/luigifcruz/CyberEther/blob/main/LICENSE) - [luigifcruz/CyberEther on GitHub](https://github.com/luigifcruz/CyberEther) - [Project website](https://cyberether.org) - [README](https://github.com/luigifcruz/CyberEther/blob/main/README.md) - [Releases](https://github.com/luigifcruz/CyberEther/releases) --- Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/luigifcruz-cyberether