What Unity Shader Build Settings Changed for Indie Build Times - 2026

If you searched unity shader build settings after the Graphics team’s November note, you do not need another generic “strip variants” sermon. You need a map of what the Editor can now set on a build profile, which editor line those controls belong to, and which speed claims are a sample project rather than a promise.

Unity staff posted Shader Build Settings and fast compilation on the Graphics product-updates forum. The short version: SRP feature growth compiled more shader variants, build times climbed, and the Editor now exposes Shader Build Settings. In Unity 6.6 you can pick the Windows shader compiler per build profile, including DirectX 12 Shader Compiler (DXC), and you can exclude keywords. In Unity 6.7 you can turn on Fast Build, which converts compatible keywords to dynamic branching. On the URP 3D Sample, Unity says that conversion cut a clean project build by around 75%. That sentence is a lab result. It is not your CI badge.

This page is the capability map. It is not the Stop that refuses leaving DXC unset on a DX12-only Windows profile. It is not a jam submission worksheet. It is not a Steam review calendar. Runtime frame time still belongs in the Unity performance guide. This URL owns what changed in the shader build UI and how an indie should read the clocks.

Why this matters now

A clean player build is where indie schedules die. You change a lit shader, you cook overnight, you miss a playtest. The historical cause is combinatorial: shader_feature and multi_compile keywords each add variants, and URP’s feature set keeps adding keywords. Unity’s answer in this drop is not “write fewer shaders.” It is a settings block that can change the compiler, drop keywords you swear you never need, define constants without new variants, and — on 6.7 — flip compatible keywords to dynamic branches.

Direct answer: On a Windows build profile in Unity 6.6 or newer, open File → Build Profiles, add Graphics Settings, and use Shader Build Settings. Set DirectX 12 Compiler (DXC) only when that profile is DX12-only. Keeping a DX11 player compiles a second set with FXC and can make the build slower. Turn Fast Build on only in Unity 6.7 or newer, then measure a clean build of your project. Treat the 75% figure as Unity’s URP 3D Sample result. Exclude keywords only when you know they never run. Hit Apply and expect a shader reimport.

Who this map is for

Time: 25 minutes to read. First profile experiment on a copy of the project: one clean build before and one after, which is hours if your variant count is already large.
Honest limit: The staff post and the manuals win if this page drifts. DXC in Unity is for Windows DX12. The DXC manual says Vulkan and Metal DXC support is experimental and not production-ready, and DXC is not compatible with DX11. Fast Build’s keyword list “might not be complete.” Keyword exclusion can ship a missing variant. Disabling optimizations speeds the compiler and slows the GPU.

Non-repetition

What changed, by editor line

The 6000.6.8f1 release notes fix several shader crashes. They are not the announcement of this UI. Do not cite a patch-note bullet you cannot find. Cite the Graphics post, then confirm the controls exist on the editor you actually have open.

Default compiler behavior is still easy to miss. The graphics settings reference says that for Direct3D12 the Default compiler is FXC, and that you should pick DXC when you build for Direct3D12 only. “We are on Unity 6.6” does not mean DXC is already selected.

Capability 1 — DXC on a Windows build profile

Job: Compile compatible shaders with the DirectX 12 compiler instead of leaving DX12 on FXC.

Staff steps, matched to the DXC manual:

1. File → Build Profiles.
2. Select a Windows profile or add one.
3. Add Graphics Settings.
4. Under Shader Build Settings, open Shader Compiler Backend Selection.
5. Add a row. Set Graphics API to Direct3D12. Set Compiler to DirectX 12 Compiler (DXC).
6. Apply. Unity reimports the shaders those settings affect.

The manual’s advantages over FXC, when DXC is actually used: shader model 6 features such as 16-bit types and wave operations, faster compilation, smaller compiled shaders, and better behavior in PIX and RenderDoc. Those are compiler properties. They are not a frame-time budget.

Beginner check: If the Build Profiles window has no Graphics Settings block, you are not in the flow yet. Add settings on the profile. Project-wide Graphics still matters for other fields, but the compiler list for this feature is set on the build profile. The reference says you cannot change Shader Compiler Backend Selection from the ordinary Graphics window.

Dev check: After Apply, the next player build should log compiler choices. The staff post says to read the build log for compatibility issues. A green Apply button with a red shader import is not “DXC is on.”

Capability 2 — A DX11 fallback can erase the win

Job: Stop counting a dual-API Windows player as a DXC speedup.

The staff post is explicit: DXC compiles shaders for DX12. If you also set a DX11 fallback, Unity compiles another set with FXC, and build time can go up. The DirectX manual says the same thing in player settings language: two graphics APIs in the list, plus DXC enabled for DX12, means two shader sets.

If your store page promises a DX11 player, keep the second set and pay for it. If you dropped DX11 last year and the list still contains it, the shader cook is doing work no customer runs. That cleanup is a player-settings edit, then a clean build. It is not a shader rewrite.

Capability 3 — A pragma can override the profile

Job: Know when one pass ignores the checkbox.

The DXC manual documents:

• #pragma use_dxc — this pass uses DXC.
• #pragma never_use_dxc — this pass stays on FXC.
• You can suffix a platform or API, for example #pragma use_dxc d3d12.

The staff post tells you to fall back with #pragma never_use_dxc when an older shader cannot move. Pragmas win over the build profile. A profile set to DXC plus a third-party shader full of never_use_dxc will not match the “all compatible shaders” story. Search the package before you brief the team.

Built-in Unity shaders are already DXC-compatible, per the manual. Custom shaders and older Asset Store includes are the upgrade pile.

Capability 4 — What “upgrade the shader” actually means

Job: Give a programmer a list, not a mood.

The DXC manual’s Windows upgrade list:

1. Do not write a constant-buffer value in place. Copy it to a local first.
2. Replace COLOR with SV_Target.
3. Replace POSITION with SV_Position.
4. Replace the VFACE float with the SV_IsFrontFace boolean.
5. Make vector truncation explicit (uv.x, not an implicit uv.xy squeeze into a float).
6. Give Texture2DMS a sample count, such as Texture2DMS<float4, 4>.
7. Declare UAVs like RWBuffer with : register(uN) matching Graphics.SetRandomWriteTarget.
8. Do not declare resources such as StructuredBuffer in a shader method’s argument list. Declare them outside the method.

That list is the compatibility work. It is not optional flavor if the import error names DXC. If you cannot change the shader this week, #pragma never_use_dxc keeps that pass on FXC while the rest of the profile moves. Write the pragma down. A silent forever-exception becomes the next person’s “DXC is broken.”

Capability 5 — Keyword exclusion is a scalpel

Job: Remove variants you have proved you do not run.

From Unity 6.6, Shader Build Settings can exclude keywords and keyword combinations. The variant manual shows the gesture: add a keyword set, separate names with spaces, include _ when the set has an empty keyword, then clear the checkbox for a keyword you want gone. A build profile’s Shader Build Settings override the project Graphics window for that player.

Staff warning, which should be on the ticket: unlike dynamic branching, exclusion can omit a variant the game still needs. Exclude only keywords you know are never used at runtime. Their own example scanned a player with the Graphics State Collection API, then excluded what that trace never hit. A menu scene that never enables a fog keyword is not proof the ending cinematic never enables it.

You can also watch what the running player uploads. The staff post points at VariantsUploadedToGpuLastFrame on UnityEngine.Shaders in the 7000.0 scripting docs. Use a trace from a playthrough that hits your real features. A thirty-second boot in the editor is a weak trace.

Company question: Who signed the exclusion list, and which playthrough produced it? “The build got smaller” is not a sign-off.

Capability 6 — Fast Build is 6.7, and 75% is one sample

Job: Turn compatible keywords into dynamic branches without hand-editing every shader.

The graphics settings reference defines Fast Build:

• Off (default): each keyword keeps the type in shader code, or your Keyword Declaration Overrides.
• On: compatible built-in and custom shaders compile with dynamic branching. Unity shows a read-only list of affected keywords. The list might be incomplete.
• Fast Build overrides type overrides. Turn it off and Apply if you need those rows again.
• While it is on, you cannot add, remove, reorder, or edit keyword-declaration rows.

The staff measurement: URP 3D Sample, clean project build, keyword-to-dynamic-branch conversion, around 75% lower build time. Read the nouns. It is not an incremental build. It is not HDRP. It is not “your 40 custom Shader Graphs.” It is not a runtime FPS number. Dynamic branching moves work to the GPU. The same manual says to use dynamic_branch when the GPU is fast and the branches are not wildly asymmetric. A faster cook can still be a slower frame. Profile that on the performance guide path, not in the build log.

Monday measurement that is allowed:

1. Note editor version. If it is not 6.7 or newer, Fast Build is not your lever. Stop.
2. Clean build, DX12-only profile, record player time and shader time if the log splits them.
3. Enable Fast Build, Apply, clean build again. Same machine, same profile.
4. Write both numbers on the ticket. If you are not near 75%, you did not fail. You are not the URP 3D Sample.
5. Play the scenes that toggle keywords from code. A missing branch is a bug even when the build was fast.

Overrides still exist for teams who want one set, not the master switch. Type override can force shader_feature, multi_compile, or dynamic_branch on a keyword set you name. shader_feature keeps variants materials use. multi_compile keeps variants even when no material in the build enables them, which you need if C# toggles the keyword. dynamic_branch skips the variant. Fast Build is the blunt form of that third choice.

Capability 7 — Constant defines are not keywords

Job: Branch at build time without a variant explosion.

Shader Constant Defines, in the same settings block, inject preprocessor constants into all shaders. Staff describe them as a way to statically branch for a platform or a build flavor without adding variants. A PC profile can define a quality constant. A demo profile can define another. That is a different tool from keyword exclusion. Exclusion deletes combinations. A define selects a path inside one compile.

Do not invent a define name and assume URP reads it. Defines you add are yours. Unity’s own examples in the graphics reference are engine defines such as shadow toggles elsewhere in Graphics settings. If your shader never tests the symbol, the row does nothing but reimport.

Apply still reimports affected shaders. Budget that reimport. It is part of the change, not a surprise hang. If the first import after a 6.6 upgrade wedges, use the asset import worker hang fix for that failure mode. It is not a Shader Build Settings tutorial.

Capability 8 — Debug symbols and optimization level pull the other way

Job: Know which checkbox makes compiles slower on purpose.

From the graphics settings reference:

Turning optimization off to “make CI green” and then shipping that profile is a frame-time decision disguised as a build decision. Split profiles: a cook-fast profile for programmers, a release profile with optimization high, symbols off, and the API list you actually sell. Build Profiles exist so those do not share one checkbox.

What did not change

A reply on the thread also shows a real authoring bug: a shader_feature limited to the fragment stage does not line up with an if on that keyword in a way DXC accepts, and the identifier looks undeclared in the vertex pass. Unity’s Juho Oravainen said they filed a bug and that the interim workaround is to define the keyword as 0 on the other stage. A request to backport that fix to 6.0 and 6.3 LTS is a request, not a shipped LTS note. If your Shader Graph or Amplify stack hits that error, you are in workaround territory until your editor’s release notes say otherwise. Do not “fix” it by turning Fast Build on and off at random.

Monday path (one profile, two clean builds)

Prerequisites: a Windows player you are willing to experiment on, a copy or a branch, and an editor that shows Shader Build Settings. Pair general editor questions with the Unity guide. Pair “which 6.6 bug is this” with the migration resource list.

1. Write the editor version and the profile name at the top of the ticket.
2. Record the graphics API list. If DX11 and DX12 are both present, decide whether that is a product requirement before you time DXC.
3. Clean build. Save the log. This is the baseline even if it hurts.
4. On 6.6+: add DXC for Direct3D12 if the profile is DX12-only. Apply. Fix or pragma any shader the log rejects. Clean build again.
5. On 6.7+: if the DXC build is healthy, try Fast Build on a second pair of clean builds so you know which lever moved the number.
6. Play a scene that uses your rare keywords. If something pinks, the exclusion list or Fast Build coverage is wrong. Revert that lever.
7. Put optimization level and debug symbols back to release values before you call the profile shippable.
8. Tell the channel the measured delta and the editor version. Do not paste “75%” unless your log says that.

Common mistakes

• Timing an incremental build and calling it the Fast Build result.
• Enabling DXC on a profile that still compiles DX11.
• Excluding a keyword from the boot scene only.
• Leaving optimization disabled because the cook felt nice.
• Editing Graphics settings and forgetting the build profile overrides them.
• Upgrading the editor in the middle of a live festival branch. Pin the editor. The performance guide assumes you can profile a stable player, not a moving editor.

Company diligence

Ask for four lines in the build review, not a screenshot of a forum post:

• Editor version (6.6.x versus 6.7 or newer).
• Windows graphics APIs on the shipping profile.
• Compiler selected for Direct3D12, and whether any pass uses never_use_dxc.
• Fast Build on or off, plus the two clean-build times if it is on.

A deck that says “Unity 6.7 builds are 75% faster” without the URP 3D Sample clause is a false claim. Unity’s sentence is allowed. Your sentence has to be your measurement. If a publisher build farm still runs DX11 and DX12 together, the honest line is “we pay for two shader sets.”

Creator paste

Unity 6.6 can compile Windows DX12 shaders with DXC from the build profile. Unity 6.7 can Fast Build by turning compatible keywords into dynamic branches. Unity saw about 75% off a clean URP sample build. We will time our own clean build before we repeat that number.

That paste is safe. “Our build is now 75% faster” is not, until the log says so.

Key takeaways

• Unity shader build settings now live on build profiles, and Apply reimports shaders.
• Unity 6.6 adds per-profile DXC for Windows Direct3D12 and keyword exclusion. Default for D3D12 is still FXC until you change it.
• DXC is not a DX11 compiler. A DX11 fallback compiles a second FXC set and can lengthen the build.
• #pragma use_dxc and #pragma never_use_dxc override the profile.
• Custom shaders may need the semantic and constant-buffer upgrades in the DXC manual. Built-in shaders are already compatible.
• Keyword exclusion can delete a variant you still run. Trace a real playthrough first.
• Fast Build starts in Unity 6.7. It forces compatible keywords to dynamic branching and overrides your type overrides.
• The around 75% clean-build cut is Unity’s URP 3D Sample test, not a universal indie result.
• Debug symbols and low optimization make compiles slower or faster for reasons that are not Fast Build. Do not ship the debug profile.
• Dynamic branching can move cost to the GPU. Time the player, not only the cooker.
• Meshlet and DXR 2.0 demos on the same thread are not this feature.
• The DXC manual and the staff post are the sources to re-read when a checkbox moves.

FAQ

What are Unity Shader Build Settings?

They are the Graphics block, on a build profile or in Project Settings, that controls how Unity compiles shaders: compiler backend on Windows, keyword types and exclusions, constant defines, debug symbols, optimization level, and — in Unity 6.7 — Fast Build. You must Apply. Applying reimports affected shaders. The map is the graphics settings reference plus the November staff post.

Does Unity 6.6 already include Fast Build?

The staff post places Fast Build in Unity 6.7. Unity 6.6 is the line they name for per-profile DXC on Windows and for keyword exclusion. If your About box is 6.6, do not hunt for a Fast Build toggle and then decide the install is broken.

Will DXC make every Windows build faster?

Only as a DX12 compile of compatible shaders. If the player also includes DX11, Unity still compiles an FXC set and the staff post says that can increase build time. If the profile never selects DXC, D3D12 stays on FXC by default.

Where do we set the compiler?

File → Build Profiles, Windows profile, Add Settings → Graphics Settings, Shader Compiler Backend Selection, add Direct3D12, choose DirectX 12 Compiler (DXC), Apply. The ordinary Graphics window does not own that compiler list.

Is the 75% build-time cut guaranteed?

No. Unity reported about 75% off the clean build of the URP 3D Sample when keywords were converted to dynamic branching. Measure a clean build of your project on your machine. Incremental builds and other pipelines are a different experiment.

Can Fast Build break a shader that toggles from code?

It can change how a keyword is compiled. The manual wants dynamic branching when branches are not extremely uneven and the GPU can take the cost. Keyword exclusion is the lever that deletes variants outright. If a feature pinks or vanishes only in the player, turn the lever off and retest before you rewrite the game.

What if a custom shader fails to compile under DXC?

Follow the upgrade list in the DXC manual, or pin that pass with #pragma never_use_dxc and record why. Stage-specific keyword pragmas that fight dynamic branches have a known interim workaround on the staff thread (define the keyword as 0 on the other stage) while Unity tracks a bug. That workaround is not a style guide.

Do we need a new render pipeline for this?

No. The settings act on the shaders you already compile, especially URP lit and lit Shader Graphs in Unity’s own telling. They do not install meshlet geometry, and they do not replace profiling a slow frame.

Conclusion

Shader Build Settings are a build-profile control panel for a problem indies already feel in the cooker: too many variants, and a default Windows compiler that is still FXC until someone selects DXC. Unity 6.6 makes the compiler and the exclusion list explicit. Unity 6.7 adds Fast Build and a sample number that is impressive and narrow.

Set the profile, read the log, time a clean build, and play the scenes that actually toggle keywords. Put the 75% sentence back in Unity’s mouth unless your log earned it. Then profile the frame. A faster cook that misses a variant is not a ship.

Re-read the staff post when you open the dropdown, and the DXC manual when a shader goes red. The checkboxes are only as honest as those pages.