# Unity-Technologies/Graphics: the public mirror of Unity's Scriptable Render Pipeline

> Unity's Graphics repository holds the source for URP, HDRP, Shader Graph and the SRP Core, but development happens elsewhere and reaches this mirror every few weeks. Here is what the repository actually contains, how to check it out as a local package, and when it is the wrong thing to clone.

**Unity-Technologies/Graphics** — Unity Graphics - Including Scriptable Render Pipeline

- Repository: https://github.com/Unity-Technologies/Graphics
- Stars: 3,004 · Forks: 882
- Language: C#
- License: NOASSERTION
- Published: 2026-09-24 · Updated: 2026-09-24 · Language: en
- Canonical page: https://hysenlabs.com/projects/unity-technologies-graphics

## What the Graphics repository is, and who needs it

This repository is the source for the Scriptable Render Pipeline, the Unity feature the README describes as giving artists and developers the tools to create modern, high-fidelity graphics. It ships two pre-built pipelines: the Universal Render Pipeline for all platforms and the High Definition Render Pipeline for compute shader compatible platforms. Shader Graph, Visual Effect Graph and the SRP Core package live here too.

The audience is narrow. If you build a Unity project with the stock URP or HDRP package from the Package Manager, you never need this repository. You need it when you want to read how a rendering pass is implemented, patch package source to test a fix, or run the sample scenes that the README says are kept in the repository and can be added by cloning it into a project's Assets folder. Graphics programmers evaluating whether a pipeline's implementation matches its documentation are the core readership.

## The mirror model: public code, private development

Two notes at the top of the README set expectations. The first says issue reporting has moved to FogBugz and that issues can only be logged through the Unity bug tracker. The second states that development by Unity developers happens in a private repository, and that changes are mirrored from there to this public repository every few weeks. A forum thread linked from the README is the place for discussion about the mirroring itself.

That is the central trade-off of the project. You get readable source, and you get it late. A fix that lands internally will not appear here immediately, and the commit history you browse is a copy rather than the working history. The repository is not archived and the last push was on 2026-09-09, so the mirror is current, but current here means within the mirroring interval the README describes.

Branch names encode the release model. The README states that master maps to the latest Unity Alpha release, that {unity-version}/staging maps to beta and released Unity versions (its example is 2021.1/staging), and that {package-major-version}.x.x/release covers Unity 2020.x and below, for example 10.x.x/release for Unity 2020.3 LTS. A tag is generated on the changeset used to vendor a specific Unity release, which is how you trace whether a given changeset shipped in a given editor version.

## Installing the packages as local source

The README gives two ways to consume the packages: clone the repository somewhere on your machine and install them as local packages into your project, or clone the repository inside a Packages folder in the Unity project. It also says Git LFS is required, so install that before cloning or the checkout will be incomplete.

The console route is the one the README spells out. Run these from a console in your project, substituting your own path and the tag that matches your Unity version:

```bash
cd <Path to your Unity project>
git clone https://github.com/Unity-Technologies/Graphics
cd Graphics
git checkout 2021.1.16f1.2801
```

The README uses 2021.1.16f1.2801 as its example tag and notes that you should use the latest tag instead. After the checkout, the repository contents are in your project, and the packages can be installed as local packages through the Package Manager window (Window > Package Manager).

The GitHub Desktop path is documented as an alternative: File > Clone repository, the URL tab, the repository URL, then Choose to point at the Unity project's base folder before clicking Clone. The same Git LFS requirement applies. If you only want the sample scenes, the README says to clone the repository into the project's Assets folder rather than a Packages folder.

## Matching a package version to a Unity version

The README's compatibility list is the part to read before cloning anything. Unity 2023.3 pairs with SRP 17.x.x, 2023.2 with 16.x.x, 2023.1 with 15.x.x, 2022.2/3 with 14.x.x, 2022.1 with 13.x.x, 2021.2/3 with 12.x.x, 2021.1 with 11.x.x, 2020.2 with 10.x.x, 2020.1 with 8.x.x, 2019.3 with 7.x.x, 2019.2 with 6.x.x, and 2019.1 with 5.x.x. The README calls this a guideline for major versions and warns that multiple minor versions often apply to one Unity version.

For a precise answer the README points at the editor: open Package Manager, find Core RP Library, expand the entry, click See all versions, and read the list of package versions compatible with that editor. On older Unity versions you may need to click Advanced and then Show preview packages before the entry appears. Once you know the version, go to the repository, open the Branch drop-down, switch to the Tags tab, and find the matching tag. That tag is what you check out.

This version matrix is the most useful page in the repository for anyone supporting multiple Unity versions. It is also the easiest to get wrong, because the mapping is by major version and the fine-grained answer lives in the editor rather than in the README.

## Where this repository is the wrong tool

Three cases stand out. First, if you are shipping a game, pulling package source into your project means you now maintain a fork of code that Unity updates on its own schedule. The README's mirroring note means upstream changes arrive in this public repository every few weeks, and your local copy does not move at all until you pull and re-resolve the checkout. There is no documented upgrade path for a modified local package in the README.

Second, if you want to report a bug or send a patch, this is not the venue. The README states that reported issues have moved to FogBugz and that issues can only be logged through the Unity bug tracker, with a link explaining how. There is a CONTRIBUTING.md in the repository root, but the README does not describe a pull request workflow, and the note about private development explains why: the public repository receives mirrored changes rather than contributions.

Third, if you need a released, versioned artifact, the repository is the wrong source. The README says the packages are distributed as Core packages in the Unity editor, and that vendoring happens multiple times per Unity release from the release branch's latest changeset. The editor's Package Manager is the supported distribution channel; cloning is for reading and modifying.

## How this differs from hand-rolling a render pipeline

The alternative to adopting SRP is writing your own render loop against Unity's lower-level graphics APIs, or staying on the built-in render pipeline that predates SRP. The difference is where the abstraction sits. SRP exposes the pipeline itself as a C# API: you describe render passes and the pipeline executes them, and URP and HDRP are two implementations of that API shipped in this repository. A hand-rolled path gives you total control over every draw call but leaves you responsible for lighting, shadows, post-processing and platform coverage that URP and HDRP already implement.

That makes the comparison less about features than about ownership. Choosing URP or HDRP means accepting Unity's pipeline structure and extending it through the extension points the packages expose. Writing your own means owning the whole stack, including the parts this repository has already solved. For most projects the second option is more work than it is worth, which is why the README frames SRP as the tool for building modern graphics in Unity rather than as a research framework.

## Licence and upgrade cost

The repository's licence is reported as NOASSERTION, meaning no standard licence identifier was detected, and LICENSE.md sits in the repository root. Read that file before you copy package source into a product; this article does not interpret it and is not legal advice. The practical implication is that you cannot assume a familiar open source licence applies just because the source is readable on GitHub.

The upgrade cost follows from the mirroring model. Because changes arrive in batches every few weeks and master tracks the latest Unity Alpha, tracking master means tracking an alpha. Production work should pin to a tag that matches the Unity version in use, which the README's tag search describes. When you later move to a newer Unity version, you re-resolve the checkout against the new tag and reapply any local modifications by hand, since the README documents no patch or rebase workflow for modified packages.

## Conclusion

Clone this repository if you need to read or modify URP, HDRP, Shader Graph or SRP Core source, or to run the sample scenes, and you accept that the public history lags the private one by weeks. Do not clone it expecting an issue tracker or a contribution path, because the README redirects bug reports to Unity's bug tracker and states that development happens in a private repository. Before you start, confirm the tag that matches your Unity version, since the README lists SRP 17.x.x for Unity 2023.3 down to 5.x.x for Unity 2019.1, and install Git LFS as the README requires.

## FAQ

### Is Unity-Technologies/Graphics the same as the URP and HDRP packages in the Unity editor?

It is the source those packages are built from. The README states that the packages in this repository are distributed as Core packages in the Unity editor, and that vendoring happens multiple times per Unity release from the latest changeset of the release branch.

### How do I check out the version of Unity Graphics that matches my Unity editor?

Use the compatibility list in the README, then find the corresponding tag in the repository. The README suggests opening Package Manager, finding Core RP Library and clicking See all versions for the exact list, then using the Branch drop-down and Tags tab on GitHub to locate the tag to check out.

### Can I report a bug or open a pull request against Unity-Technologies/Graphics?

The README states that reported issues have moved to FogBugz and that issues can only be logged through the Unity bug tracker. It also states that development happens in a private repository and changes are mirrored here every few weeks, and it does not describe a pull request workflow.

### Does Unity Graphics require Git LFS?

Yes. The README's GitHub Desktop instructions say to make sure the Git LFS extension is installed, since it is required.

## Sources

- [Issues](https://github.com/Unity-Technologies/Graphics/issues)
- [README](https://github.com/Unity-Technologies/Graphics/blob/master/README.md)
- [Unity-Technologies/Graphics on GitHub](https://github.com/Unity-Technologies/Graphics)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/unity-technologies-graphics
