• We’re currently investigating an issue related to the forum theme and styling that is impacting page layout and visual formatting. The problem has been identified, and we are actively working on a resolution. There is no impact to user data or functionality, this is strictly a front-end display issue. We’ll post an update once the fix has been deployed. Thanks for your patience while we get this sorted.

Question Zen 6 Speculation Thread

Page 259 - Seeking answers? Join the AnandTech community: where nearly half-a-million members share solutions and discuss the latest tech.
511 said:
L3<-> L3 transfer perhaps?
Click to expand...

I wonder if that ever gets solved that would fit satisfactorily into how AMD handles L3...

It would be a "nice to have" in a desktop, but on server, it would only make sense if the entire CPU worked as unit, rather than various virtualized subsets. So probably too few big use cases in the overall picture.
 
Joe NYC said:
I wonder if that ever gets solved that would fit satisfactorily into how AMD handles L3...

It would be a "nice to have" in a desktop, but on server, it would only make sense if the entire CPU worked as unit, rather than various virtualized subsets. So probably too few big use cases in the overall picture.
Click to expand...
NUCA is nice and elegant.
Forget about that.
 
itsmydamnation said:
yeah i dont get the obsession with making your L3 crappy and making coherency a nightmare.
Click to expand...

Also, it is becoming a moot point after AMD moved :
- from 16MB pool of L3 in Bergamo
- to 32 MB pool of L3 in Turin
- to 128MB pool of L3 in Venice
- to maybe > 200 MB pool of L3 in Florence
 
More bumps = more connections. Either wider data pathways for existing payouts(edit: layouts), or payouts(edit: layouts) are changing and they need more wires to connect more chiplets. Maybe there will be a 4 chiplet package on desktop with a separate iGPU chiplet?
 
Last edited:
LightningZ71 said:
More bumps = more connections. Either wider data pathways for existing payouts, or payouts are changing and they need more wires to connect more chiplets. Maybe there will be a 4 chiplet package on desktop with a separate iGPU chiplet?
Click to expand...

Or a separate NPU chiplet.
 
Or daisy-chaining of CCDs </s>

But yes, they tripled RAM bandwidth to around 1.6 TByte/s for the Top-End. With 8 CCD you'd need an interconnect to be at least as wide as 200 GByte/s in order to saturate this. And that is with each CCD demanding an equal share. Current GMI-Wide delivers 128 GByte/s (read) IIRC.
So 256 GByte/s/CCD or even more don't seem like overkill to me.
 
basix said:
Afaik NPUs are also better regarding time to first token or in other words execution latency. They work better with small batch sizes. For many applications and single customer use cases this is helpful. But for big number crunching it should be better to move towards the GPU in the longterm. The GPU does also have massive support from a big and wide memory system. Replicate that for an NPU is a waste of sand.

But funnily enough, doesn't Qualcomm add a better link between GPU and NPU to move matrix computations to the NPU (the GPU does not support such acceleration)

Regarding software:
HW differences could be abstracted away by HALs and APIs.
Click to expand...
I have been thinking about getting a Copilot+ laptop but frankly are there any "real" uses/programs for NPU yet? So far I have not spotted anything useful. For example I would like Copilot app on windows actually use NPU. Or Copilot addons in office.
 
mmaenpaa said:
I have been thinking about getting a Copilot+ laptop but frankly are there any "real" uses/programs for NPU yet? So far I have not spotted anything useful. For example I would like Copilot app on windows actually use NPU. Or Copilot addons in office.
Click to expand...
Spellcheck
 
511 said:
L3<-> L3 transfer perhaps?
Click to expand...
Compared to IFOP, you can do that now through a wider, faster and lower latency interface to the IOD 😉

BorisTheBlade82 said:
Or daisy-chaining of CCDs </s>

But yes, they tripled RAM bandwidth to around 1.6 TByte/s for the Top-End. With 8 CCD you'd need an interconnect to be at least as wide as 200 GByte/s in order to saturate this. And that is with each CCD demanding an equal share. Current GMI-Wide delivers 128 GByte/s (read) IIRC.
So 256 GByte/s/CCD or even more don't seem like overkill to me.
Click to expand...
That is a very interesting idea, indeed. For Zen 6 I do not expect something like that to happen. For Zen 7 I think not as well (16/33C CCDs, bigger L3$ and simply faster cores are already a decent enough update). But Zen 7 could still introduce it (core count mania). Would be sick to see a 512C Zen 7 SKU 😉

As the beachfront of the IOD is limited, daisy-chaining makes very much sense in the mid- to longterm. It are just a few hundred of GByte/s if putting 2x CCDs in series. Such a concept opens up the door to very huge core count scalings without adding too much cost (much bigger CCDs, much more IOD area, ...).
  • Even with 512 GByte/s it is not an issue, the power draw is still much lower than 128 GByte/s of an existing IFOP interface (~10x less power required)
  • RDNA3 MCDs already delivered ~900 GByte/s per chiplet
  • Zen 7 will probably introduce an outsourced L3$ on a bottom 3D-Stacked Die. Adding 2x IF-PHY on two sides of this base Die (for daisy-chaining), which gets manufactured in an older node like N4, would not hurt regarding costs.
 
basix said:
That is a very interesting idea, indeed. For Zen 6 I do not expect something like that to happen. For Zen 7 I think not as well (16/33C CCDs, bigger L3$ and simply faster cores are already a decent enough update). But Zen 7 could still introduce it (core count mania). Would be sick to see a 512C Zen 7 SKU 😉
Click to expand...
512C totally doubt this with the meager density gains they have to make the package significantly larger 384C seems possible
 
mmaenpaa said:
I have been thinking about getting a Copilot+ laptop but frankly are there any "real" uses/programs for NPU yet?
Click to expand...

You have AMD's GAIA and Intel's OpenVINO that can integrate Ollama. Both can get you to use an NPU for running LLMs on Windows, with which you can also make agents.

If you're willing to dedicate a couple of hours to set this up, you can get a NPU to run LLMs for you locally with a lower power consumption compared to running it on the iGPU.


EDIT: even easier than using OpenVINO, Intel has the AI Playground app that also makes use of its NPUs:
game.intel.com

Introducing AI Playground | Intel Gaming Access

Updated 02/13/2026 AI Playground, an easy-to-use Generative AI app suite for Intel AI PCs, powered by Intel Arc GPUs, either built-in Intel® Core™ Ultra Processors or via Intel® Arc™ discrete GPUs. AI Playground is available as an open-source project and packaged Windows desktop installer. NEW...
game.intel.com game.intel.com

Check out a demo of the app here, at the timestamp:



mmaenpaa said:
For example I would like Copilot app on windows actually use NPU. Or Copilot addons in office.
Click to expand...
You could try to implement a local running LLM to work on Outlook and Word, it's supposedly possible.. but IIRC it's not easy. Microsoft isn't super interested in letting people off the hook on paying $30/month for the full Copilot M365 experience.
 
Last edited:
You must log in or register to reply here.

TRENDING THREADS

Back
Top