AMD Zen Microarchitecture: Dual Schedulers, Micro-Op Cache and Memory Hierarchy Revealed
by Ian Cutress on August 18, 2016 9:00 AM EST
In their own side event this week, AMD invited select members of the press and analysts to come and discuss the next layer of Zen details. In this piece, we’re discussing the microarchitecture announcements that were made, as well as a look to see how this compares to previous generations of AMD core designs.
AMD Zen
Prediction, Decode, Queues and Execution
First up, let’s dive right into the block diagram as shown:
If we focus purely on the left to start, we can see most of the high-level microarchitecture details including basic caches, the new inclusion of an op-cache, some details about decoders and dispatch, scheduler arrangements, execution ports and load/store arrangements. A number of slides later in the presentation talk about cache bandwidth.
Firstly, one of the bigger deviations from previous AMD microarchitecture designs is the presence of a micro-op cache (it might be worth noting that these slides sometimes say op when it means micro-op, creating a little confusion). AMD’s Bulldozer design did not have an operation cache, requiring it to fetch details from other caches to implement frequently used micro-ops. Intel has been implementing a similar arrangement for several generations to great effect (some put it as a major stepping stone for Conroe), so to see one here is quite promising for AMD. We weren’t told the scale or extent of this buffer, and AMD will perhaps give that information in due course.
Aside from the as-expected ‘branch predictor enhancements’, which are as vague as they sound, AMD has not disclosed the decoder arrangements in Zen at this time, but has listed that they can decode four instructions per cycle to feed into the operations queue. This queue, with the help of the op-cache, can deliver 6 ops/cycle to the schedulers. The reasons behind the queue being able to dispatch more per cycle is if the decoder can supply an instruction which then falls into two micro-ops (which makes the instruction vs micro-op definitions even muddier). Nevertheless, this micro-op queue helps feed the separate integer and floating point segments of the CPU. Unlike Intel who uses a combined scheduler for INT/FP, AMD’s diagram suggests that they will remain separate with their own schedulers at this time.
The INT side of the core will funnel the ALU operations as well as the AGU/load and store ops. The load/store units can perform 2 16-Byte loads and one 16-Byte store per cycle, making use of the 32 KB 8-way set associative write-back L1 Data cache. AMD has explicitly made this a write back cache rather than the write through cache we saw in Bulldozer that was a source of a lot of idle time in particular code paths. AMD is also stating that the load/stores will have lower latency within the caches, but has not explained to what extent they have improved.
The FP side of the core will afford two multiply ports and two ADD ports, which should allow for two joined FMAC operations or one 256-bit AVX per cycle. The combination of the INT and FP segments means that AMD is going for a wide core and looking to exploit a significant amount of instruction level parallelism. How much it will be able to depends on the caches and the reorder buffers – no real data on the buffers has been given at this time, except that the cores will have a +75% bigger instruction scheduler window for ordering operations and a +50% wider issue width for potential throughput. The wider cores, all other things being sufficient, will also allow AMD’s implementation of simultaneous multithreading to potentially take advantage of multiple threads with a linear and naturally low IPC.
Facebook
Twitter
RSS
216 Comments
View All Comments
Kevin G - Saturday, August 20, 2016 - link
Google is porting their internal software but they're not moving production system unless there is a clear reason. (And for some specific applications, there are some clear reasons.)Google doesn't want to be married to any particular architecture.
BillBear - Saturday, August 20, 2016 - link
As of April, they seem to have already ported their software stack to POWER and to be in the process of designing server hardware with Rackspace with the intention of making those designs public under the Open Compute Project.http://www.pcworld.com/article/3053092/ibms-power-...
BillBear - Saturday, August 20, 2016 - link
I should be clear that I'm not saying Google intends to abandon x86. They are simply talking about POWER based servers becoming a first class citizen in their infrastructure.TheinsanegamerN - Saturday, August 20, 2016 - link
Crossing fingers for a great 35 watt APU. The iGPU space in laptops has been stagnant since trinity. and it is abundantly clear that intel cant supply iris pro parts in any meaningful capacity.Now that AMD supports linux properly with polaris, all we need is a polaris+zen APU for laptops, and I can finally move off of windows altogether.
Michael Bay - Sunday, August 21, 2016 - link
Why would you even need a gpu in a laptop running specialized OS in the first place? Games aren`t being ported outside of token cases and rendering/drawing/general office applications are a sad joke.Networking is where it`s good at, and you don`t need anything over perfunctory graphics there.
Gigaplex - Monday, August 22, 2016 - link
Linux is quite the opposite of a specialized OS. It's probably the most versatile platform out there.Michael Bay - Monday, August 22, 2016 - link
I see it being said a lot, but what`s the point if software is so bad with no hope of improvement? You can`t reasonably compete with Adobe if there are three people on your team doing this in their spare time, same goes for Zbrush and any other professional content creation tool. Much better to focus where you actually can lead.asoltesz - Sunday, August 28, 2016 - link
"with no hope of improvement" is nonsense for one tracking the Linux world even if only casually.First of all the open source applications have matured a lot. E.g. I could do everything I wanted with Kdenlive as good as the built in movie editor of OSX. (Consumer level, bit still)
For certain niches, oss is now as good as the commercial competition (eg Krita for digital painting)
A lot of newer applications now have proper Linux support (E.g. Slack) because they were created with platform independent toolkits.
As for the base OS and desktop, I find desktop Linux way more powerful and sophisticated than either Windows or OSX. My ws runs KDE Plasma 5 on an Ubuntu base and it is better looking , faster and more stable than my OSX ElCap laptop.
BrokenCrayons - Monday, August 22, 2016 - link
Check Steam. The last time I looked, about 2,700 games of the 11,000 were supported under Linux. Then there's quite a few that play nicely under WINE + PlayOnLinux. Native gaming on Linux has dramatically improved in the last 4 years. It seems as though momentum is building still rather than declining. Office applications have come a long way as well thanks to the folks behind LibreOffice. I've been using it as a personal office suite since the fork from OpenOffice and it's made impressive progress. Formatting MS Office documents is still a minor sticking point, but the number of differences I see when moving files between office suites now are very small with most cases being oddball outliers that require obscure capabilities of Microsoft's suites. Rendering has never been a problem on Linux platforms. Drawing though, in my opinion is still a shortcoming. GIMP is a miserable piece of software to work with and remains one of the only image editing options for Linux users.However, I doubt my comment will change your mind. Much like the people who use a $ when they talk about Microsoft, you insist on using the word "loonix" in many of your posts. It shows a very strong bias supported by a framework of childish emotional investment in something as meaningless as software on a computer someone else owns.
Michael Bay - Monday, August 22, 2016 - link
>2700 indie nongamesUh-uh. Wake me up when AAA comes in any significant number.
>WINE
Are you joking.
>Libre
Okay, now I know you are.
>GIMP
At least here we can agree.