Skybox: Open-Source Graphic Rendering on Programmable RISC-V GPUs

Blaise Tine, Varun Saxena, Santosh Srivatsan, Joshua R. Simpson, Fadi Alzammar, Liam Cooper and 1 other

Graphics chips still devote a large slice of their silicon to FIXED-FUNCTION units — circuits hard-wired for one job, such as turning triangles into pixels — and that silicon cannot be used for anything else, which is a genuine cost on a phone or a small device where every square millimetre matters; the sensible question is which of those units still earn their area now that the programmable cores beside them have become so capable, and the awkward answer is that nobody could find out, because commercial designs are secret and the open alternatives were simulators that cannot tell you what real hardware would actually cost; this paper (Georgia Tech) supplies the missing instrument rather than an answer — a complete open graphics processor built on the RISC-V instruction set, with the driver software, the compiler, the hardware description that can be loaded onto a reconfigurable chip, and a simulator, all released together and supporting the modern Vulkan graphics interface for the first time; with it they can simply switch each hard-wired unit off and measure, finding that removing the pixel-blending unit costs more than removing the triangle-to-pixel unit, and that a cache with an excellent hit rate contributes almost nothing.

The argument in one glance

Problem

Nobody could measure whether graphics silicon still earns its area

A graphics processor devotes a substantial part of its silicon to FIXED-FUNCTION units — circuits wired to do exactly one job, such as turning triangles into screen pixels, testing which surface is nearest, and blending colours. They exist because those operations happen constantly and a dedicated circuit performs them far more efficiently than general instructions. But that area is permanently unavailable for anything else, and the programmable cores beside them have grown enormously more capable, while graphics processors are now used for scientific computing, machine learning and graph analysis, and are squeezed into phones where every square millimetre counts. So the natural question is which of those units still justify their cost. Answering it requires building both versions and measuring them, and that was not possible — commercial designs are proprietary, and the open alternatives could not supply the numbers.
What people did

Study graphics hardware with simulators

The established research route is simulation. Several open graphics simulators model a rendering pipeline and estimate how many cycles a workload would take, which is enough to compare scheduling policies, cache configurations and similar architectural choices. They are the standard tool of the field, they run real workloads, and they let researchers explore designs without fabricating anything.
Why it fell short

A simulator cannot price silicon it does not describe

A cycle-approximate simulator models behaviour, not circuits. It can tell you roughly how long something takes but it has no hardware description, so it cannot tell you how much area a fixed-function unit consumes, nor what timing a real implementation would achieve — which are exactly the quantities the question turns on. The paper states the gap plainly: prior simulation work is not equipped to study the trade-off between fixed-function units and programmable cores. The one open project with real synthesizable hardware was a general-purpose RISC-V graphics processor that had no rendering pipeline at all, and what open graphics support existed targeted the older OpenGL interface, while modern applications increasingly require Vulkan and new techniques such as ray tracing exist only there. So the community had simulators that could not price hardware, and hardware that could not render.
This paper's idea

Build the whole stack, then switch each unit off and measure

This paper (Georgia Tech — Tine, Saxena, Srivatsan, Simpson, Alzammar, Cooper, Kim) contributes the instrument rather than the answer. Skybox is a complete open graphics processor built on the RISC-V instruction set, released as four layers together — driver software adapted from a CPU-based Vulkan implementation, a modified compiler, a real hardware description that can be loaded onto a reconfigurable chip, and both cycle-level and hardware simulators. It is the first open full-stack design supporting Vulkan. Because the hardware is real, the design question becomes answerable by the simplest possible method: build the fixed-function units, then selectively DISABLE each one and measure what it cost to lose it. The answers are not all what convention would predict — removing the pixel-blending unit costs more than removing the triangle-to-pixel unit, and a cache with a hit rate above 80 percent turns out to contribute almost nothing because the system is limited elsewhere. Getting there also required real compiler work, because a plain RISC-V core lacks the branch-divergence machinery graphics shaders assume.

Why this problem is worth solving

The question here is about where silicon should go, so it is worth understanding what these dedicated circuits actually do.

Rendering a three-dimensional scene runs through a PIPELINE of stages. GEOMETRY PROCESSING transforms the scene’s triangles and projects them onto the two-dimensional screen. RASTERIZATION converts each projected triangle into the set of screen pixels it covers. FRAGMENT PROCESSING then computes a colour for each of those pixels, and finally the RENDER OUTPUT stage decides whether each pixel is actually visible — testing its depth against whatever has already been drawn — and blends it into the image. Historically all of this was FIXED-FUNCTION, meaning built as dedicated circuits that do one job and cannot be reprogrammed. Over time the stages that benefit from flexibility became PROGRAMMABLE, run as small programs called shaders on general cores, which is what made graphics processors useful for non-graphics work. But the rasterizer, the texture sampler and the render output stage largely remained dedicated hardware, because they perform simple operations enormously often, and a dedicated circuit does that far more efficiently than a sequence of general instructions. Many designs also use TILE-BASED rendering, splitting the screen into tiles and drawing one tile at a time to reduce memory traffic and energy

. The cost of keeping those units is area that could otherwise hold more programmable cores, which matters most exactly where graphics processors are most constrained.

Deciding the trade-off requires more than a model of behaviour.

To compare a fixed-function unit against a software equivalent you need two quantities — how much silicon AREA the unit occupies and what TIMING a real implementation achieves — and neither can come from a simulator that only models behaviour. What is needed is a hardware description, expressible in a register-transfer-level language and synthesizable onto a real chip, so that area and clock frequency are measured rather than assumed. That is why this work is delivered as a FULL STACK: driver software, a compiler, a synthesizable hardware description, and simulators, all released together, because a change at any layer affects the others and a partial release cannot be used to answer the question. The choice of graphics interface matters too. VULKAN is the modern standard, and it differs from the older OpenGL by moving synchronization and performance-critical decisions out of the driver and into the application, which gives applications more control and suits both desktop and mobile hardware. New techniques such as ray tracing are implemented only in Vulkan, and modern applications increasingly no longer support the older interface — so research infrastructure that cannot run Vulkan cannot run what matters

What people did before, and where it broke

Proprietary commercial designs. The graphics processors that actually answer these questions internally are secret. Their published details are marketing-level, so the community cannot inspect where area goes or experiment with removing a unit.
Cycle-approximate graphics simulators. Several open simulators model a rendering pipeline and estimate cycle counts, which suffices for comparing scheduling or caching choices. But they contain no hardware description, so they can price nothing — and the paper says directly that they are not equipped to study the fixed-function versus programmable trade-off.
Open synthesizable RISC-V graphics processors. One prior open project provides a genuine hardware description of a general-purpose graphics processor that runs on reconfigurable chips. Real hardware, but it has no rendering pipeline, so it cannot render a scene at all.
Open graphics support for the older interface. What open graphics work existed targeted OpenGL and included texture units, but not the rasterizer or render output stages, and modern applications increasingly require Vulkan while new techniques exist only there.
The gap. The field had simulators that could not price hardware and hardware that could not render, and nothing at all that ran the modern graphics interface. Since the question is precisely about hardware cost versus software capability, it could not be asked, let alone answered. That is the gap Skybox fills — by building the instrument.

How a complete open graphics processor is assembled

Four layers released together, so a hardware question becomes measurable

The trade-off cannot be measured

Deciding whether a fixed-function unit earns its silicon needs its area and its real timing, which a behavioural simulator cannot supply. Commercial designs are secret, open simulators have no hardware description, and the one open synthesizable graphics processor has no rendering pipeline.
↓ →
Start from an open programmable RISC-V processor new

The baseline is an existing open general-purpose graphics processor built on the RISC-V instruction set with a real synthesizable hardware description. It can run general programs on many threads but has no graphics-specific units, so it cannot render.
↓ →
Add the two fixed-function units worth testing new

A rasterizer converts tile-based triangles into groups of pixels, avoiding recomputation of the edge equations that decide coverage. A render output unit performs depth and stencil testing and colour blending. One of each is placed per cluster of cores, and both can be switched off so the software path can be measured against them.
↓ →
Keep the rest programmable, deliberately new

Geometry, vertex and triangle setup work run as shader programs merged onto the cores rather than as dedicated circuits, and attribute interpolation is moved into the fragment stage to avoid holding large per-pixel attribute state. Even the early depth test runs as a shader, removing the need for special interpolation hardware.
↓ →
Extend the instruction set and teach the compiler new

Three instructions are added — one to ask the rasterizer for pixels, one to hand results to the render output unit, and one fixed-point multiply-add for interpolation. Because a plain RISC-V core has no predicated execution, the compiler must insert explicit split and join instructions wherever threads take different branches, and manage the register pressure that follows.
↓ →
Adapt the software stack and measure new

A CPU-based Vulkan implementation is modified to rasterize by tiles, compile shaders for RISC-V on the fly, and marshal data between the wider host and the 32-bit processor. With all layers present, each fixed-function unit can be disabled in turn and the cost measured directly.

Synthesized to 32 cores in two clusters, 512 threads total, running at 230 megahertz on an Intel Stratix 10 reconfigurable chip and delivering a peak fill rate of 3.7 billion pixels per second, evaluated on eight demonstration scenes at full high definition.

The idea

Build the instrument, and let it answer questions you did not choose in advance. The most useful thing here is not a result but a capability. The question of which fixed-function units deserve silicon had no empirical answer because nobody could construct both alternatives and measure them, and the paper is explicit that prior simulation is not equipped for it. So the contribution is a complete, real, open system — software, compiler, hardware description and simulators together — precisely because a partial release cannot answer a question that spans all four layers. Once it exists, the experiment becomes almost trivially simple: switch a unit off and see what happens. Investing in infrastructure that makes a previously unanswerable question routine, rather than in a single result, is the same build-the-thing-that-enables-measurement move covered elsewhere on this site, where a paper contributes the framework for navigating a trade-off space and says openly that it is not claiming which way the trade-off goes.

Measure which silicon earns its area rather than inheriting the convention. With the instrument in hand the answers are usefully surprising. Disabling the render output unit costs more than disabling the rasterizer — 139 percent more cycles against 129 percent — meaning the per-pixel depth-and-blend work justifies dedicated hardware even more than the triangle-to-pixel conversion that is more commonly held up as the canonical fixed-function stage. Meanwhile several stages the design deliberately left programmable cost nothing to leave that way, and even a small custom fixed-point instruction earns its keep at 33 percent. Establishing empirically which parts of a long-standing design still pay, instead of reproducing the split because that is how it has always been done, is the same question-the-inherited-design instinct covered elsewhere on this site in the graphics-processor page that abandons equal bandwidth because the reason for it no longer holds.

A general-purpose baseline makes the compiler part of the architecture. Choosing an ordinary RISC-V core as the foundation is what makes the design open and reusable, but RISC-V was never meant to run graphics shaders. It has no predicated execution, so when threads in a group take different branches something must track which are active — here explicit split and join instructions the compiler inserts automatically, using postdominator analysis to find where control reconverges, plus extra machinery for loops where threads exit at different iterations. It has few registers, so shader register pressure had to be handled with a hybrid stack that lives in fast shared memory and overflows to main memory, worth up to 22 percent on texture-heavy scenes. And its instruction format allows only three source operands, forcing awkward workarounds that stall the pipeline. When the substrate lacks what your workload assumes, the compiler becomes the place the gap is closed — the same compiler-and-hardware-co-design division of labour covered elsewhere on this site, where static analysis supplies what the hardware cannot see for itself.

Asking whether a hard-wired unit earns its silicon

Switching off the graphics hardware to find out what it was worth

How a full-stack open design turns an architectural argument into a measurement. Numbers from the paper's evaluation.

Step 1 of 5

The question

Graphics processors dedicate silicon to circuits that do one job — converting triangles to pixels, testing depth, blending colours. That area cannot hold programmable cores instead. Which of those units still justify the trade, especially on small devices where area is scarce?

the programmable cores beside them have become far more capable, and graphics processors now serve machine learning and scientific computing too
the two quantities needed to decide are the unit's silicon area and the real timing it achieves

Why it works

Deciding whether dedicated silicon pays needs its area and its real timing → only a synthesizable hardware description supplies both → so building real hardware rather than a behavioural model is what makes the question answerable at all.
The fixed-function units are built as optional → they can be disabled and the software path measured in their place → turning an architectural argument into a direct experiment costing 129 and 139 percent respectively.
The stack is released complete → a change in the hardware can be followed through the compiler and driver → so configurations that span layers, like adding an instruction, can actually be evaluated.
A plain RISC-V core has no predicated execution → the compiler inserts split and join instructions using postdominator analysis to find reconvergence points → letting shaders with divergent branches run on a processor never designed for them.
Shader register pressure exceeds what a small register file holds → a hybrid stack keeps the fast path in shared memory and overflows to main memory → gaining up to 22 percent on texture-heavy scenes without recompiling for each workload.

What it costs (trade-offs and scope)

The baseline instruction set fights the workload. RISC-V allows at most three source operands, so graphics instructions needing more must route through control registers, and the paper notes this forces a pipeline stall on every invocation.
The cores are scalar, so pixel-quad work multiplies instructions. Graphics shaders naturally operate on groups of pixels at once, but the baseline executes one value at a time, inflating instruction counts substantially. The authors identify adopting the RISC-V vector extension as future work.
Compiler support for divergence is not free. Automatically inserting the divergence instructions costs 9 percent more code and 13 percent slowdown; analysis that avoids unnecessary instrumentation reduces this to 7 percent and 5 percent, but it does not vanish.
Reconfigurable-chip results are not silicon results. Everything is measured at 230 megahertz on a reconfigurable chip, which does not indicate what a fabricated design would achieve in frequency or area, and the evaluation uses eight demonstration scenes.
Several design points are fixed rather than derived. The chosen tile and block sizes emerged from a sweep on this configuration and workloads, and the conclusion that one rasterizer and one render output unit per 16-core cluster suffices is specific to that scale.

The evaluation

Skybox was synthesized as a 32-core, 512-thread graphics processor running at 230 megahertz on an Intel Stratix 10 reconfigurable chip, with results also reported on Xilinx hardware, delivering a peak fill rate of 3.7 billion pixels per second and rendering eight demonstration scenes from a mobile graphics software development kit at full high definition. The design space was explored by selectively disabling each fixed-function unit and each added instruction, and by sweeping tile size, cache sizes and the number of parallel units, while measuring instructions, cycles and stalls.

Studying the fixed-function versus programmable trade-off

Property	Commercial GPUs	Open graphics simulators	Skybox
Can render modern workloads
Reveals silicon area
Units can be disabled to compare
Full stack available
What it yields

Disabling the render output unit costs 139 percent more cycles and disabling the rasterizer 129 percent, so both earn their area — with per-pixel work justifying dedicated hardware even more than triangle conversion. Together those units occupy more than a third of the chip's logic, memory and arithmetic resources. The rasterizer cache hits above 80 percent of the time yet barely affects performance, because the shader cores downstream are the limit.Underlined values explain themselves when clicked.

Where this stops working

What to keep in mind

Read this as infrastructure first and results second — the contribution is a complete open system that makes a previously unanswerable question routine, and the measurements are what that system immediately yields rather than the point of the paper. The results are also specific to the configuration measured. The choice of tile and block size came from a sweep on these workloads, and the conclusion that one rasterizer and one render output unit per 16-core cluster suffices holds at that scale. Everything is measured at 230 megahertz on a reconfigurable chip, which does not tell you what a fabricated design would achieve in frequency or area, and the workloads are eight demonstration scenes. The general-purpose baseline also imposes real costs the authors report honestly: the RISC-V instruction format allows only three source operands, so graphics instructions needing more must route through control registers and stall the pipeline on each use; the cores are scalar while shaders naturally work on groups of pixels, inflating instruction counts until the vector extension is adopted; and automatic handling of branch divergence costs 9 percent code size and 13 percent slowdown before optimization, 7 and 5 percent after. Within that scope the lessons travel: when a question spans several layers, the honest answer may be to build the instrument rather than argue; verify empirically which parts of an inherited design still pay; and be wary of a metric that looks excellent while the thing it was supposed to improve does not move.

Background

Build the instrument, then check which inherited choices still pay

This paper sits in the site’s computer-architecture and open-hardware cluster and rhymes with several ideas covered elsewhere on this site. Its primary move is to contribute a capability rather than a claim — recognising that a question spanning software, compiler and hardware cannot be settled without all three, and so building and releasing the whole stack. That is the same supply-the-missing-instrument discipline the kernel-machine-learning page shows when it contributes the framework for navigating a trade-off space while declining to assert which way the trade-off goes, and both papers are stronger for being explicit that the infrastructure is the point. Its second move, testing empirically whether long-standing fixed-function units still deserve their silicon rather than reproducing the split by inheritance, is the question-the-inherited-design instinct the non-uniform-bandwidth page shows when it abandons equal bandwidth between all cores and all cache because the reason that arrangement existed no longer holds — and both find that a convention survives partly out of habit. Its reliance on the compiler to supply what a general-purpose instruction set lacks, inserting divergence handling and managing register pressure the hardware cannot manage itself, is the same division of labour the non-uniform-bandwidth page uses when a compiler proves a property so hardware can exploit it, and the same substrate-dictates-the-design lesson the firmware-debloating page draws from what one instruction set happens to guarantee. Most quietly instructive is its finding that a cache achieving a hit rate above 80 percent contributes almost nothing because the bottleneck lies downstream — a textbook case of the measure-the-thing-that-actually-binds lesson the performance-analysis page teaches, where a proxy metric can look excellent while the outcome it was chosen to represent does not move at all.

If you remember only three things

1. Graphics processors dedicate substantial silicon to FIXED-FUNCTION units — circuits wired for one job such as converting triangles into pixels, testing depth and blending colours — because those operations happen constantly and dedicated circuits do them far more efficiently than general instructions. But that area cannot hold programmable cores instead, which matters increasingly as those cores grow more capable, as graphics processors serve machine learning and scientific computing, and as they are squeezed into phones. Deciding which units still earn their area needs both their silicon cost and their real timing, and neither was obtainable: commercial designs are proprietary, open graphics simulators model behaviour without any hardware description, and the one open synthesizable graphics processor could not render at all.
2. Skybox supplies the missing instrument. It is a complete open graphics processor on the RISC-V instruction set, released as four layers together — driver software adapted from a CPU-based Vulkan implementation, a modified compiler, a synthesizable hardware description, and both cycle-level and hardware simulators — and it is the first open full-stack design supporting the modern Vulkan interface. Building it required real compiler work, because a plain RISC-V core has no predicated execution, so the compiler must insert explicit split and join instructions using postdominator analysis wherever threads diverge, and must manage shader register pressure with a hybrid stack that lives in fast shared memory and overflows to main memory, worth up to 22 percent on texture-heavy scenes.
3. With real hardware the architectural argument becomes a direct experiment: disable a unit and measure. Removing the render output unit costs 139 percent more cycles and removing the rasterizer 129 percent, so both earn their area — with per-pixel work justifying dedicated hardware even more than the triangle conversion usually held up as the canonical case. The synthesized design reaches 3.7 billion pixels per second at 230 megahertz with 32 cores and 512 threads. Most instructive is a negative result: the rasterizer cache achieves a hit rate above 80 percent yet contributes almost nothing, because the shader cores downstream are the real limit. The transferable lessons: when a question spans several layers, build the instrument rather than argue; check empirically which inherited design choices still pay; and distrust a metric that looks excellent while the outcome does not move.

Check yourself

Check your understanding

1. The authors say prior open graphics simulators could not answer their question. Predict what a simulator specifically cannot supply.
2. The rasterizer cache achieves a hit rate above 80 percent yet barely improves performance. Predict what that reveals.
3. Skybox releases driver software, a compiler, a hardware description and simulators together. Predict why a partial release would not do.
4. Removing the render output unit costs more than removing the rasterizer, 139 percent against 129 percent. Predict what makes this worth reporting.

Sources

Skybox: Open-Source Graphic Rendering on Programmable RISC-V GPUs (ACM DL, DOI 10.1145/3582016.3582024) — ASPLOS 2023; full text read for this explainer.
HPArch publications, Georgia Tech — the authors’ research group listing.
Vortex RISC-V GPU project — the open general-purpose RISC-V graphics processor Skybox extends.