GPU Architecture Roadmap

The Chromium graphics stack is complicated, and has been evolving rapidly for the last several years. As a result of this rapid evolution, plus the pressure to try to ship performance-improving features as fast as possible, we’ve developed a large matrix of feature configurations on different platforms. This document lays out what’s enabled where, as well as our long-term plans for the architectural evolution of the stack.

A software backend for the compositor, used when we don’t have a viable GPU (blacklisted or the GPU process crashes repeatedly). This is the only configuration variable we intend to support indefinitely. (covered in the ubercomp design doc)

Orphaned compositing (self-drawing cc in the renderer or browser (i.e. drawing without ubercomp and a browser compositor))

Conceptually, the architecture has various features, some of which depend on each other. These features can be enabled or not on every platform (i.e. all five operating systems), plus based on whether or not we have a trusted GPU device (non-blacklisted card, drivers, and OS version). We’re trying hard to get all of these features enabled on all platform configurations, and then delete a significant amount of legacy code that we no longer need (i.e. everything above).

The current status of these features on all platform configs is captured in the below spreadsheet. Platform configs are the cross product of OS, have GPU / don’t have GPU, and Aura / non-Aura. Note that Aura is included in the platform configuration, rather than as a feature column, because it has such a large impact on everything else. We end up with quite a few configurations. Each column represents a “feature” and each row represents a platform configuration. Current work is marked, as well as what’s finished and what’s yet to be attempted.

GPU Feature Dashboard

Google Spreadsheet

We want to get all the columns green for rows with good viability, and delete code that supports the rows with red viability.

Keep this goal in mind when working on features. Contributions to the codebase that add dependencies to cells in rows with bad viability are problematic because we’re trying to delete these codepaths -- we’re actively working to remove dependencies on them. Furthermore, keep in mind that we need to eventually make the whole column green, not a single cell. If we don’t, we incur technical debt and add complexity by moving our architecture further out of sync across platforms.