Gigi: authoring a rendering technique as a graph, then compiling it to C++, WebGPU or Unreal

Four components, one loop from graph to shipped code

Gigi is described as software designed for rapid prototyping and development of real time rendering techniques, meant for professionals, researchers, students and hobbyists. The workflow it proposes is the interesting part, and the README states it in one sentence: work at the speed of thought in the Editor, then debug, profile and iterate in the Viewer, and finally use the Compiler to generate code for C++ DX12, WebGPU, or the Unreal Engine. The four components map onto that sentence. The Editor is where you author a rendering technique. The Viewer is where you debug and profile it. The Compiler is a command line interface that generates code for the technique, in the words of the README, like a human would write. The Browser lets you view a library of Gigi techniques and submit your own, so the technique format is a shareable artifact rather than a private file format. The claim that the generated code looks like what a person would write is the load bearing one, because it is the difference between a prototype that stops at the prototype stage and one that can graduate into a shipping renderer.

Windows and DX12 are the floor, not a preference

The minimum requirements are short and blunt: Windows 11 and a GPU capable of DX12. The README says Gigi is currently Windows only and runs DX12, and that if a system does not support something used in a Gigi graph, such as ray tracing or variable rate shading, Gigi is supposed to put an error in the error log but otherwise run normally. That degradation is a deliberate design decision and it is a good one for a prototyping tool, since the point is to see the technique rather than to block on a hardware capability check, but it means the Viewer is a DX12 application even when the eventual target is WebGPU or Unreal. The compilation side is more varied than the preview side, and the README points to a platform support document for details, because different platforms have different levels of feature support both due to platform limitations and due to functionality still needing to be implemented. The repository layout backs that up. Separate unit test generation scripts exist for DX12, WebGPU, Unreal Engine 5.3 and a support markdown variant, which is a rough measure of how many backends are in flight at once.

Building it, and the four executables you end up with

Building from source is described in one line: clone the repository and build `gigi.sln`, which is a Visual Studio solution. Prebuilt binaries are also published on the releases tab, either as a zip file you extract where you want or as an installer executable, and the README gives the option rather than pushing one. Either way you end up with four executables in the root folder, and their names describe the workflow. `GigiEdit` is the editor, `GigiViewerDX12` is the viewer, `GigiCompiler` is the command line interface compiler, and `GigiBrowser` is the component that lets you browse, download and open techniques from the technique library. The viewer name carrying DX12 is the reminder that this is the Windows only component. A gallery of WebGPU code generated Gigi techniques is published as a separate site, which is a useful way to judge what the compiler output looks like before you install anything, and there are text and video tutorials, a Discord for support, and two recorded talks linked from the README, one on lightning talks and one technical overview.

The Viewer is a debugger with a Python interface and a unit test suite

The Viewer is where a technique stops being a picture and becomes measurable, and the repository has two things that make that credible. The first is the `Techniques/UnitTests/` folder, which the README says contains the unit tests and aims to exercise every possible piece of functionality. That is an ambitious goal for a rendering framework, and it is the kind of thing that makes a prototyping tool trustworthy, because a technique that renders correctly on your machine may still hit a path nobody exercised. The second is the `UserDocumentation/` folder, which explains the viewer Python interface and Gigi shader tokens among other things, so the viewer is scriptable rather than purely interactive. The README describes the unit test workflow in enough detail to be reproduced. For the viewer tests you select File, then Run Python Script, and choose `Techniques/UnitTests/RunTests.py`, and it should report zero errors. For the DX12 tests you first run the `MakeCode_UnitTests_DX12.bat` file to generate the code, and if that produces no diffs you can consider it a success, and then you open and run `_GeneratedCode/UnitTests/DX12/UnitTests.sln`, which should also report zero errors.

Contributing means signing an EA Contributor License Agreement

The contributing section has a requirement that surprises people the first time they read it: before you can contribute, EA must have a Contributor License Agreement on file, signed by each contributor, with a link to sign it. Any contribution, large or small, earns a spot on the contributors list, and the README asks you to add your name to that list as part of the pull request. On standards, the README is candid that they need to write them up and automate them as much as possible, but for now asks that your code look like the other code. The testing expectation is specific: with each pull request, besides testing the functionality you are touching, verify that both the viewer and DX12 unit tests still pass, and consider adding unit tests where appropriate. The release process is documented too, in a file named `HowToMakeAPublicRelease.md`, and the repository carries a `.gitlab-ci.yml` along with a `CLAUDE.md` and a `.mcp.json`, the latter pointing at a `GigiMCP/` directory, which is a machine facing interface to the same tooling.

The Browser turns techniques into a shareable library

The fourth component deserves a second look, because it changes what a technique file is. The Browser lets you explore examples to help you get started, browse, download and open techniques from the technique library, and submit your own, with the process documented in a file called `readme/BrowserSharing.md`. The consequence is that a Gigi technique becomes a unit of exchange rather than a one off asset: a researcher can download a technique that demonstrates an effect, and a graphics programmer can look at how someone else structured the graph before writing their own. There is a gallery of generated WebGPU code linked from the README, which doubles as a way to see what a technique looks like once compiled. The repository also contains a `browserservers.txt` file at the root, next to the rest of the tool configuration, so the browser side has its own service configuration. For a team that works on shading, the browser is arguably the most transferable part of Gigi, because it carries techniques between people rather than between stages of one project.

Versioning, licence and the shape of the tree

The release line is dense and small-stepped: v1.01.9 on 2026-03-11, v1.01.10 on 2026-04-17 and v1.01.11 on 2026-05-12, with the last push on 2026-05-21, so the project is shipping patch versions roughly monthly. The README's own status sentence is the fairest summary available, that Gigi is being actively used and developed, but is young software and you may hit bugs or missing features, with a request to report them and a note that pull requests are appreciated. The licence is a custom one that GitHub cannot classify, with a `LICENSE.txt` and a separate `NOTICE.txt` in the tree, so there is no standard identifier to check against, and the repository also ships third party binaries, among them `dxcompiler.dll`, `WinPixEventRuntime.dll` and the AMD FidelityFX frame generation, loader and upscaler DLLs for DX12. The tree itself shows the architecture in the open: `Nodes/` and `NodesStatic/` for the graph node types, `RenderGraph/` and `FlattenRenderGraph.cpp` for the graph handling, `Schemas/` for the file formats, `ShaderDebugInfo/`, `Shared/`, `Tools/`, `Techniques/`, and a `_GeneratedCode/` directory that holds the output the compiler produces.

Editorial conclusion

Adopt Gigi if you are prototyping a real time rendering technique and want to iterate in an editor, profile it in a viewer, and finish with readable C++, WebGPU or Unreal Engine code rather than a bespoke pipeline. Do not adopt it if you need Linux or macOS support, or a stable production toolchain, because the minimum requirements are Windows 11 and a DX12 capable GPU, the project calls itself young software, and the licence is a custom EA one. Before you commit, read the platform support document, because feature support differs per target and the Viewer is DX12 only, and expect a rough edge around Unreal Engine generation if that is your target, since the repository carries separate unit test generation scripts for DX12, WebGPU, Unreal Engine 5.3 and the support markdown. The last push was on 2026-05-21 and the latest tagged release is v1.01.11 from 2026-05-12.

Frequently asked questions

Official sources

1. electronicarts/gigi on GitHub
2. Issues
3. README
4. Releases