Support for changeable manual custom Shader cache size on arc control centre

[Dhruvajyoti]

From what I can find it was mentioned once 2 years ago in this post https://community.intel.com/t5/Intel-Arc-Discrete-Graphics/Performance-Issues-and-Shader-Cache-Size-Limit-on-Horizon/m-p/1594740/highlight/true . However there still isn't a way to increase the cache size while Nvidia and AMD have it right in their global settings.

[BuenoS_Intel]

Hello Dhruvajyoti,

Thank you for sharing the information and the community thread. I understand your concern regarding shader cache size configuration and the lack of a visible option compared to other vendors.

To better understand your request and assist you more effectively, could you please provide the following details:

1. Please run the Intel® System Support Utility (SSU), save the scan results, and share the report with us. This will help us review your system configuration.
2. Are you reporting this behavior for a specific game or application? If so, please let us know which one(s) and describe the scenario in more detail.
3. Could you provide more information about the equivalent settings available in NVIDIA and AMD software (e.g., the exact setting names or screenshots)? This will help us better understand the feature you’re referring to and evaluate it accordingly.

Once I have this information, I will be in a better position to assess your request and provide appropriate guidance or feedback.

Thank you, and I look forward to your response.

Best regards,

Bueno S.

Intel Customer Support Technician

[Dhruvajyoti]

1. I have attached SSU report as requested(At the time of attachement I haven't updated the driver to version 32.0.101.8724).

2. I'm reporting this as I couldn't find a setting to manually set shader cache size and came upon the mentioned thread from 2 years ago.

3. Nvidia [Image 1].

[Resolutions404]

Hey @Dhruvajyoti ! I totally feel your frustration on this one. As someone who’s been tinkering with Arc since the early Alchemist days, I know exactly what you’re talking about. Seeing those "Shader Cache" toggles on the Green and Red teams while we're left with an "Auto" setting feels like being locked out of your own BIOS.

Here is a little breakdown of where things stand for me and how I handled it.

---

The Reality Check: Intel Control Panel

First off, let’s be real: Intel Arc Control currently does not have a manual slider for Shader Cache size. Intel’s driver philosophy right now is heavily focused on an "AI-managed" approach. They want the driver to dynamically allocate space based on your SSD capacity and the game’s needs. While that sounds great on paper, it doesn't help when a game like Horizon or Starfield starts stuttering because the cache is being purged too aggressively.

---

My Recommended Workaround (The Registry Hack)

Since the UI won't let us do it, I suggest going under the hood. You can sometimes force a larger limit through the Windows Registry, though keep in mind this is a "use at your own risk" situation.

1. Open Regedit: Press Win + R, type regedit.

2. Navigate to: HKEY_LOCAL_MACHINE\Software\Intel\GMM (If GMM doesn't exist, you'll need to create the Key).

3. The Entry: I'd recommend creating a DWORD (32-bit) value named ShaderCacheSize.

   • The Logic: Setting this to a higher hex value (like 0x400 for 1GB or 0x800 for 2GB) can sometimes stop the driver from being so "aggressive" with its cleanup.

⚠️ A Word of Caution

Be careful playing with the Registry. If you set a manual limit that exceeds your available system memory or confuses the driver's garbage collection, you can actually cause more stutters or even driver hangs (TDRs). Always back up your registry key before you start poking around!

---

Why "Auto" behaves the way it does

Intel’s drivers use a global cache located in %LocalAppData%\Intel\ShaderCache. Unlike older DX11 implementations, Intel’s DX12 and Vulkan drivers are designed to be quite "chatty" with the CPU.

If you're hitting performance issues, I suggest:

• Manual Purge: Don't just increase size; clear the old stuff. Sometimes the cache gets "stale" after a driver update. Delete the contents of that folder and let the game rebuild it fresh.

• The Waiting Game: We Arc users have to be patient. If a game has a pre-compilation step in the main menu, let it hit 100% before you jump in.

---

Final Thoughts

I'm right there with you on the community boards. We need that toggle in Arc Control for better user agency. Until then, keep those drivers updated to the latest WHQL, they’ve been significantly improving how the driver handles memory pressure with every release.

Hang in there! We’re early adopters, but the hardware is solid; the software just needs to catch up to our expectations. 👊

Stay Geeky,

Your Friendly Neighbourhood User

[Dhruvajyoti]

Thanks a bunch, also are the hex keys in exponential increments such as:
0x400 - 1GB

0x800 - 2GB

0x1600 - 4GB...

[Resolutions404]

Hey @Dhruvajyoti,

I hope that I pointed you in the right direction.

Regarding your question about the hex values: you are spot on with the logic of scaling by powers of two, but let’s adjust the math slightly for that 4GB step to ensure you are setting the registry values correctly.

In hexadecimal, we are working in base-16. When you double a value, you are shifting the bits. Here is the correct mapping for those sizes:

Size	Decimal (MB)	Hexadecimal Value
1 GB	1024 MB	0x400
2 GB	2048 MB	0x800
4 GB	4096 MB	0x1000

A quick note on the math: In your example, 0x1600 is actually equivalent to 5,632 (decimal). If you use 0x1600, you would be allocating 5.5 GB rather than 4 GB. To hit exactly 4 GB, you use 0x1000.

Technical Considerations:

• The Power of 16: Since each hex digit represents 4 bits, when you reach the capacity of one digit (9, A, B, C, D, E, F), the next value rolls over to the next place value. This is why 1GB (0x400) doubling to 2GB is 0x800, but doubling 2GB (0x800) results in 0x1000 (which is 16^3, or 4096).

• Driver Interpretation: Keep in mind that while the registry entry can define a preference, the Intel driver’s GMM (Graphics Memory Management) module may have hard-coded caps or safety bounds depending on the specific GPU VRAM and system RAM detected. If the driver ignores the entry, it is likely hitting an internal hard limit designed to prevent memory fragmentation.

Always double-check your value before hitting "OK" in the Registry Editor, as an extra zero in a hex string can turn a 4GB request into a 64GB request, which the driver will almost certainly reject (or worse, cause a crash).

Also, if you decide to proceed, always create a System Restore point before editing the registry. It takes 30 seconds and is the ultimate "get out of jail free" card if the system becomes unstable.

Let me know if you see any noticeable changes in your performance after applying these settings!

[Sjatar]

Hello, does this method work on Alchemy or only more recent GPU/iGPUs? Tested it with my A770 on driver version 32.0.101.8735, but did not seem to do anything ^^

[Resolutions404]

Hey there! Always good to see a fellow A770 owner in the trenches. That’s a beast of a card, but I totally hear you—it can be a bit of a "finicky" beast when it comes to the software side of things.

To answer your question: The registry logic is technically universal for the Intel Graphics driver stack (covering both Alchemist and the newer architectures), but there’s a big "if" involved regarding why you might not be seeing a change.

Here’s the breakdown of why it might feel like it’s not doing anything on your current setup:

1. The "Driver Overrule"

With the newer driver branches (like your .8735), Intel has been hardening the GMM (Graphics Memory Management). Even if we put a value in the registry, the driver is programmed to prioritize system stability. If the driver detects that manual cache sizing might lead to memory fragmentation or a TDR (driver hang), it will silently ignore the registry key and stick to its internal "Auto" logic. It’s like suggesting a route to a GPS—sometimes the GPS just decides its own way is safer!

2. The Battlemage/Lunar Lake Gap

Intel recently rolled out a massive feature called "Precompiled Shaders" (around driver .8626). This is likely what you're seeing people talk about in recent news.

• The Catch: Intel has officially limited that specific "Precompiled Shaders" toggle to Xe2 architecture and newer (Battlemage and Core Ultra 200V).

• Alchemist Reality: For us A-Series users, the driver still relies on the older local compilation method. The registry hack is our only way to influence it, but it's much less "official" than the new toggle the newer chips get.

3. Verification is Tricky

It’s super hard to tell if it’s working just by looking at the UI because, sadly, Arc Control won't update to show your new limit. The only way to truly verify is to:

1. Navigate to %LocalAppData%\Intel\ShaderCache.

2. Note the folder size.

3. Play a heavy game (like Starfield or Horizon) for an hour.

4. See if the folder size actually exceeds the old "Auto" limits (usually capped around 1GB-2GB) or if it stays stuck.

My Advice for your A770

Since you're on a very recent driver, Intel has actually baked in some significant "behind-the-scenes" improvements for how Alchemist handles memory pressure. If you aren't seeing a performance gain, it might actually be because the driver is already doing a decent job of managing the cache for your specific 16GB config!

One little tip: If you really want to "reset" the logic, try deleting the contents of that ShaderCache folder. Sometimes giving the driver a clean slate allows it to actually "see" the new registry parameters you've set.

Keep tinkering! We're all basically "pioneer" engineers with these Arc cards, but that's half the fun, right?

Stay Geeky!

[Sjatar]

I have verified this registry change does not work by seeing the shader cache be limited to 512MB size. Before and After. I tried to increase it to 1GB, which should def be within some kind of safe limit. I have 32GB of ram and the A770 is a 16GB vram card. Not sure where it would cache the shaders as I hope it's not directly loading it from the drive.

In the game I play the most, Path of exile, this is filled extremely quickly. I can verify this by seeing that one file in the shader cache takes up 99% of the limit and it's used when PoE is opened.

I have multiple times cleared my cache but Path of exile is a game that has a extreme variance in the content displayed and probably a worse case scenario when it comes to shader caching. Every single area you interact with is essentially random when it comes to enemies and content loaded. This causes some side effects. Only the most common assets seems to be cached. So when more uncommon content such as bosses are faced, they can be unloaded and attacks/mechanics can be completely invisible. 

Is there a known driver version I could downgrade to which would allow a non auto shader cache limit?
Also I'm guessing this is a AI responses, it would be nice to know if a human has actually verified this method works and it's not hallucinations.

[SesanN_Intel]

Hello Resolutions404,

We appreciate your response and sharing these information here on this thread.

Hello Dhruvajyoti,

Please carefully review the caution notice in the shared instructions by @Resolutions404. We highly recommend performing a registry backup before proceeding, this may cause issue on your end in the future. Rest assured that this concern about Global Shader Cache will be checked internally.

Best regards,

Sesan N.

Intel Customer Support Technician

[Dhruvajyoti]

Yes, I did notice the warning that issues might occur and have created a system restore savepoint. Regarding the internal inquiry for Global Shader Cache, I hope there will be news soon as this has been far drawn out for a simple fix of allowing user to choose their desired Cache size.

[SesanN_Intel]

Hi Dhruvajyoti,

We truly appreciate you bringing this recommendation regarding our Arc Control Centre to our attention. While we may not have this specific feature available at the moment, rest assured that your suggestion will be submitted to our development team for future consideration.

Your feedback is valuable to us and helps us understand what features would be most beneficial for our users.

Thank you for taking the time to share your insights - it helps us continue improving our products and services.

Best regards,

Sesan N.

Intel Customer Support Technician