Stop Ignoring DXC Shader Build Settings on Unity 6.6 Windows Builds - 2026

If a Windows player build got slower after you moved to Unity 6.6, the first sentence in the incident is usually wrong. People write “CI is sick” or “URP variants exploded again.” Sometimes both are true. Often the profile that just cooked still has Direct3D12 on the Default compiler, and Default on that API is still FXC. A unity dxc shader build setting exists on the Windows build profile. Ignoring it, then timing the farm, measures a choice you never made.

Unity’s Graphics team posted Shader Build Settings and fast compilation in November 2026. The capability map — which editor line owns DXC, keyword exclusion, and the Unity 6.7 Fast Build switch — lives in What Unity Shader Build Settings Changed for Indie Build Times - 2026. This page is the refusal. Do not open a build-time incident, a “Unity is too slow” thread, or a publisher excuse until the Windows profile card says which compiler ran.

Direct answer: On Unity 6.6 or newer, open File → Build Profiles, select the Windows profile you actually ship, add Graphics Settings if it is missing, and read Shader Compiler Backend Selection. For a DX12-only player, set DirectX 12 Compiler (DXC) and Apply. If the row is still Default, you are compiling DX12 with FXC. If the player also lists DX11, Unity compiles a second FXC set and the cook can get slower, not faster. Search shaders for #pragma never_use_dxc before you tell the team “DXC is on.” Then clean-build once and attach the log. Only that packet may blame the build machine.

Why this matters now

Shader cook time is a schedule bug dressed up as an infrastructure bug. A lit-shader edit that used to finish before lunch now finishes after the playtest. The farm looks guilty because the farm is where the clock is visible. The November staff note is the reason this refusal is due this month, not next quarter: the Editor can now choose the Windows compiler per build profile, and the graphics settings reference still says the Default compiler for Direct3D12 is FXC. Upgrading the editor does not flip that default for you.

The DXC manual is the other half of the same fact. DXC is the DirectX 12 compiler. It is not a DX11 compiler. Vulkan and Metal DXC support is experimental and not something you turn on because a Windows number looked bad. A team that “enabled DXC” in a slide, while the shipping profile still lists two graphics APIs, did not enable the case the manual describes.

The 6000.6.8f1 release notes are the wrong citation when someone asks where the checkbox was announced. Those notes fix shader crashes. They are not the Shader Build Settings post. Stop pasting a patch-note URL you did not read. Paste the Graphics thread, then paste the profile card from the editor you have open.

Time and prerequisites

Plan 45 to 90 minutes for one Windows profile, not a studio-wide shader rewrite.

Beginners can do the profile read in the first half hour. A programmer owns the pragma search and any shader that fails to import. A producer owns the rule that no CI ticket opens without the card.

Who this refusal is for

Runtime frame time is a different clock. After the cook is honest, profile the player with the Unity performance guide. Editor lessons that are not this refusal sit on the Unity guide. If the first import after a 6.6 upgrade hangs before you can even open Build Profiles, use the asset import worker hang fix first. That hang is not a compiler-row decision.

Non-repetition

The habit this Stop refuses

Three sentences keep showing up in build channels. Each one skips the profile.

1. “CI got slower.” The agent runs the profile you gave it. If that profile never selected DXC, the agent is faithfully slow.
2. “We are on 6.6, so DXC is on.” The editor version is not the compiler row. Default for Direct3D12 remains FXC until someone sets DXC and Applies.
3. “Variants are the whole story.” Variant count still matters. It is not an alibi for leaving the compiler on the default while you rewrite stripping rules. Keyword exclusion and Fast Build are separate levers, mapped on the other URL. This URL refuses the leap that skips the compiler row.

A fourth habit is quieter. Someone sets DXC on a local profile named My PC, times a warm incremental build, and pastes the delta into the ticket for the CI profile, which is still Default and still lists DX11. Those are different players. The refusal treats them as different until the cards match.

Refuse ladder

Use one code on the ticket. Do not invent a fifth code to sound busy.

BLAME_REFUSED is the default when the card is empty. It is not an insult. It is the order of work. Infrastructure questions start after DXC_SET or after an explicit DOUBLE_API decision that the product still ships DX11.

What each code must attach

When leaving FXC is the correct call

Ignoring the row is the habit to stop. Choosing FXC on purpose is allowed. Write the choice down so the next person does not “fix” it in a hurry.

A correct FXC choice is still a filled card. An empty card is the thing this page refuses.

Profile card (paste this before any ticket)

Copy this block into the incident. Empty fields mean BLAME_REFUSED.

EDITOR:
PROFILE_NAME:
CI_USES_THIS_PROFILE: yes | no
GRAPHICS_APIS:
D3D12_COMPILER: Default | FXC | DXC
APPLY_DONE: yes | no
NEVER_USE_DXC_COUNT:
CLEAN_BUILD: yes | no
BUILD_MINUTES:
AGENT_OR_MACHINE:
CODE: COMPILER_UNSET | DOUBLE_API | PRAGMA_WALL | IMPORT_RED | DXC_SET | BLAME_REFUSED

Beginner path. You can fill EDITOR, PROFILE_NAME, GRAPHICS_APIS, and D3D12_COMPILER without reading HLSL. In the Editor: File → Build Profiles, select the profile CI uses, Graphics Settings, Shader Build Settings, Shader Compiler Backend Selection. If you cannot find that block, you have not added Graphics Settings on the profile yet. The ordinary Project Settings Graphics window is not a substitute for the compiler list. The reference says Shader Compiler Backend Selection is not edited from that window.

Dev path. After the four fields exist, Apply if you change the row. Expect a shader reimport. Then run one clean player build. Incremental times are how warm caches impersonate a compiler win. Record BUILD_MINUTES from that clean run only.

Worked card (fill-in, not a measured studio)

This is a blank example of the shape, not a claim that a project hit these minutes. Replace every value.

EDITOR: 6000.6.x
PROFILE_NAME: WIN_SHIP
CI_USES_THIS_PROFILE: yes
GRAPHICS_APIS: Direct3D12
D3D12_COMPILER: Default
APPLY_DONE: no
NEVER_USE_DXC_COUNT: unknown
CLEAN_BUILD: no
BUILD_MINUTES: (empty)
AGENT_OR_MACHINE: (empty)
CODE: BLAME_REFUSED

That card is a refused incident. The next edit is the compiler row, not a larger agent. After a DX12-only profile is set to DXC, Apply has finished, and a clean build has a number, the code can move to DXC_SET. If the API list is Direct3D11, Direct3D12, the code stays DOUBLE_API until someone decides the product still needs the DX11 player. The capability map explains why that second API adds an FXC compile. This page only refuses to call that outcome a CI regression.

Wrong ticket versus refused ticket

Pragma sweep before you brief the team

A profile set to DXC does not win a fight with a pragma. The DXC manual defines:

• #pragma use_dxc forces DXC on that pass.
• #pragma never_use_dxc keeps that pass on FXC.
• A suffix can limit the pragma, for example to d3d12.

From the project root, search the shader sources you actually compile. Package cache copies count. A hit inside Library/ that you do not own is still a pass that will ignore the profile.

# Windows, from the Unity project root
findstr /S /I /N /C:"never_use_dxc" *.shader *.hlsl *.cginc
findstr /S /I /N /C:"use_dxc" *.shader *.hlsl *.cginc

If your tree is large, point the search at Assets and at the package folders you vendor, then at Library/PackageCache only when an import error names a package shader. Record hits in a ledger:

A ledger with no owner is how “temporary” becomes the next year’s PRAGMA_WALL. Built-in Unity shaders are already DXC-compatible, per the manual. Custom shaders and older Asset Store includes are the pile. The upgrade list — constant buffers, SV_Target, SV_Position, SV_IsFrontFace, explicit truncation, Texture2DMS sample counts, UAV registers, no StructuredBuffer in method arguments — stays on the manual and on the capability map. This page does not re-teach that list. It refuses to call the project “on DXC” while the ledger is blank and the log is red.

One authoring bug is worth naming so you do not “fix” it by flipping random checkboxes. On the same Graphics thread, a shader_feature limited to the fragment stage can fail under DXC because the keyword 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 onto older LTS lines is a request, not a note you can cite as shipped. If the import error matches that shape, write IMPORT_RED, link the shader, and use the workaround or never_use_dxc with an owner. Do not turn Fast Build on and off hoping the identifier appears.

What the CI gate is allowed to check

The gate is a human or a script that rejects the incident, not a script that edits Unity’s compiler. Do not pretend a log scraper knows more than the profile card.

Pass the gate only when all of these are true:

1. EDITOR is 6.6 or newer for a DXC conversation. Older editors skip to “this Stop does not apply.”
2. CI_USES_THIS_PROFILE is yes, and the profile name matches the build script, not a developer’s local profile.
3. GRAPHICS_APIS is copied from that profile.
4. D3D12_COMPILER is an explicit value. “Default” is a legal value. It is also COMPILER_UNSET when the API is Direct3D12, because Default means FXC.
5. If the value is DXC, APPLY_DONE is yes.
6. NEVER_USE_DXC_COUNT is a number, including zero, from the sweep. “Unknown” fails the gate.
7. Any timing claim uses CLEAN_BUILD: yes.

The gate must refuse these sentences:

A script may check that the card file in the repo is present and that D3D12_COMPILER is not the word unknown. It should not fail the build because a log line you invented does not exist. Unity’s log wording moves. The staff post tells you to read the log for compatibility errors. Reading is the gate. A regex you copied from a blog is not.

Where the gate sits in the pipeline

Debug symbols and disabled optimization change compile time on purpose. The graphics reference says symbols slow the compile and enlarge the shader, and that disabled optimization is faster to compile and worse on the GPU. Shipping the “CI felt better” profile because optimization was off is a frame-time decision smuggled into a build incident. Split profiles if programmers need a fast cook. Do not point the store upload at that split.

Fast Build is not an excuse to skip this Stop

Unity 6.7’s Fast Build converts compatible keywords to dynamic branching. The staff measurement, about 75% off a clean build, is the URP 3D Sample, not an indie average and not a frame-rate number. The capability map owns that switch, the incomplete keyword list, and the fact that Fast Build overrides keyword type overrides.

This Stop only adds one rule: do not turn the 6.7 discussion on until the 6.6 compiler row is filled. A team on 6.6 that cannot find Fast Build does not have a broken install. A team on 6.7 that enables Fast Build while Direct3D12 is still Default has mixed two levers and cannot say which one moved the clock. Measure DXC on a clean pair first. Measure Fast Build on a second pair. Paste both numbers or paste neither.

Dynamic branching can move cost to the GPU. A faster cook with a slower scene is not a win. That measurement belongs in the performance guide, after DXC_SET, not in the incident that still says BLAME_REFUSED.

Monday path

1. Write the editor version from Help → About. If it is not 6.6 or newer, stop. This refusal is the wrong page.
2. Open the build script or the CI config and copy the profile name it passes to the Editor.
3. Open that profile. Fill the card. If D3D12_COMPILER is Default and the API list is DX12-only, set DXC, Apply, and set the code to COMPILER_UNSET until the clean build exists.
4. If DX11 is also listed, stop and get a product answer the same day. Do not time DXC until that answer is DOUBLE_API with eyes open, or the extra API is gone.
5. Run the never_use_dxc search. Put a number on the card. Assign owners for any hit you will keep.
6. Clean-build once. Attach the log. If shaders fail, the code is IMPORT_RED. Fix or pragma those passes using the manual’s upgrade list.
7. Only if the code is DXC_SET and the minutes are still unacceptable do you file a farm ticket. The first line of that ticket is the card, not a hunch.
8. Tell the channel the code and the editor version. Do not paste 75%.

Mistakes that reopen the refusal

• Timing a local incremental build and filing it against CI.
• Editing Project Settings Graphics and assuming the build profile followed.
• Calling Default “basically DXC” because the editor is new.
• Deleting DX11 from the player because a blog said so, when the store page still promises DX11.
• Treating a jam branch and a shipping branch as the same profile.
• Upgrading the editor in the middle of the measurement. Pin the version. The 6.6 migration list is for that pin, not for this compiler row.

Company sign-off

Ask for the card, not for a screenshot of the forum thread.

A publisher build that still cooks DX11 and DX12 pays for two shader sets. That sentence is allowed. “The new editor made CI worse, so we need more agents” is not allowed until the card is DXC_SET or an intentional DOUBLE_API.

Creator paste

Stop blaming the build machine for Unity 6.6 shader times until the Windows build profile says DXC or an explicit FXC choice. Default on Direct3D12 is still FXC. A DX11 fallback cooks a second set. I will paste the profile card before I ask for a bigger agent.

That paste is enough for a devlog or a Discord note. It does not require anyone to know the gate codes. The codes are for the ticket. The sentence is for everyone else.

What this Stop will not do

• It will not make a DX11 game DX12-only. That is a player-support decision.
• It will not upgrade your HLSL for you. Red imports still need the manual’s list or a scoped never_use_dxc.
• It will not move Fast Build onto 6.6.
• It will not turn Unity’s sample percentage into your percentage.
• It will not diagnose a pink shader at runtime. That can be a stripped keyword, a missing variant, or a GPU cost. Start from the variant manual and the performance guide after the compiler row is honest.
• It will not replace a broken first import. Use the worker-hang help page when the Editor never reaches Build Profiles.

Key takeaways

• Unity DXC shader build settings live on the Windows build profile. The editor version does not select the compiler for you.
• Default for Direct3D12 is still FXC until you choose DXC and Apply.
• Apply reimports shaders. Budget that. A green checkbox with a red import is IMPORT_RED, not “DXC is on.”
• A DX11 fallback compiles another set with FXC and can make the cook slower. Decide that on purpose (DOUBLE_API) or remove the API.
• #pragma never_use_dxc beats the profile. Count those pragmas before you brief the team.
• Do not open a CI-capacity ticket while the profile card is empty. That incident is BLAME_REFUSED.
• Fast Build is a Unity 6.7 switch. The around 75% figure is one clean URP 3D Sample, not your nightly.
• 6000.6.8f1 release notes are not the announcement. The staff post is.
• Split a cook-fast profile from the shipping profile. Do not ship disabled optimization because the farm felt nicer.
• The capability map stays on What Unity Shader Build Settings Changed. This URL only refuses the skipped row.

FAQ

What is a Unity DXC shader build?

It is a Windows player build whose Shader Build Settings compile Direct3D12-compatible shaders with the DirectX 12 compiler (DXC) instead of leaving that API on FXC. You set it on a build profile in Unity 6.6 or newer: File → Build Profiles → Graphics Settings → Shader Compiler Backend Selection. The DXC manual describes the compiler. The staff post describes the settings block.

Why is my Unity 6.6 build still using FXC?

Because Default for Direct3D12 is FXC until you select DXC and Apply. “We installed 6.6” does not change the row. A #pragma never_use_dxc also keeps that pass on FXC even when the profile says DXC.

Does DXC make every Unity build faster?

No. The manual’s speed comments apply when DXC is actually used on compatible Windows DX12 shaders. A second graphics API still compiles with FXC. Some shaders will not import until you upgrade them or exempt them. Unity’s large percentage is a 6.7 Fast Build result on the URP 3D Sample, which is a different switch.

Can I ignore Shader Build Settings if I strip variants?

No. Stripping and keyword exclusion change how many variants exist. They do not choose DXC versus FXC. You can do both later. You cannot skip the compiler row and then blame the agent for the compiler you left on Default.

What if we still need DirectX 11?

Keep DX11 and pay for the extra FXC set. Write DOUBLE_API on the card so nobody “fixes” the build by deleting a player your store page still sells. The DirectX manual is the source for that double compile.

Where do I click so this is not a Project Settings myth?

File → Build Profiles, then the Windows profile CI uses, then add Graphics Settings, then Shader Build Settings. Changing the global Graphics window and walking away is how the profile stays on the old compiler. Confirm the profile name against the build script.

Should I turn on Fast Build in Unity 6.6 to finish this?

No. Fast Build is the 6.7 control. On 6.6, finish the compiler row, the API list, and the pragma count. On 6.7, measure Fast Build only after that row is already explicit, on a separate clean build.

What do I attach when I still want a bigger build machine?

The filled profile card, the code (DXC_SET or an intentional DOUBLE_API), one clean-build log, the editor version, and the agent image id. Without those, the request is BLAME_REFUSED and the next edit is the profile, not the farm.

Conclusion

Stop ignoring DXC Shader Build Settings on Unity 6.6 Windows builds. The row is small, the default is still FXC, and a CI chart cannot see a checkbox you never set. Fill the profile card, decide DX11 with your eyes open, count the pragmas that refuse DXC, and clean-build once. Then, and only then, talk about the machine.

The staff post and the DXC manual remain the sources when a label moves. The capability map remains the page for what each control does. This page remains the page that sends an empty incident back.