AMD Zambezi news, info, fans !

Quote:

---

Originally Posted by 2good4you

It quite early info, but still official and very confusing and:

<snip>

Or does each one of those cores count as two? I think it's the former but I just wanted to confirm.

---

Quote:

---

Originally Posted by muziqaz

Hm, I remember John saying that they will not use modules for marketing, it will be cores.

---

*cough* I see we skipped my above post, albeit a long one, quoting John on it being 1 Module = 2 Cores (and by default, 2 threads):up:

In the interest of getting to the heart of it:

"John Fruehe September 13, 2010
A module will have 2 cores in it. It will be seen by the hardware and software as 2 cores. The module will essentially be invisible to the system."

Quote:

---

Originally Posted by Lightman

Yes, correct.

We already know FX8, FX6 and FX4 monikers, what else do we need as a proof?

---

A bolt of lightning from the AMD Gods of Thunder? Which, defying belief, burns into their skin:
"Henceforth let it be known: a Bulldozer module will have TWO cores! Thee Interlagos will provide ye with up to 16 cores; Valencia with up to 8; Zambezi as well with up to 8. We have spoken, and it was good!" :D

Good one Formula :rofl:

Quote:

---

"Henceforth let it be known: a Bulldozer module will have TWO cores! Thee Interlagos will provide ye with up to 16 cores; Valencia with up to 8; Zambezi as well with up to 8. We have spoken, and it was good!"

---

Will the 4 core/ 2 module cpu be a handicapped 8c/ 4 module or only 4c/2m on die?

Quote:

---

Originally Posted by xsuperbgx

Will the 4 core/ 2 module cpu be a handicapped 8c/ 4 module or only 4c/2m on die?

---

Pretty sure there is at least going to be a native 4, 6, and 8 core dies.

AMD started paying for working dies rather than wafers so I guess the chance you are gonna see locked/faulty cores just dropped massively.

http://www.theinquirer.net/inquirer/...ies-32nm-chips

Quote:

---

Originally Posted by El Gappo

AMD started paying for working dies rather than wafers so I guess the chance you are gonna see locked/faulty cores just dropped massively.

http://www.theinquirer.net/inquirer/...ies-32nm-chips

---

Global foundries will need to drop faulty ones on amd one way or another, im sure theyre gonna be out there.
Bulldozer for example has 4-6-8 cores based on the same chip die.

Dunno, I think that's quite a good question... At first I wanted to say "they are based on a modular setup, so you'll have true 4/6/8 chips", but then it clicked: These aren't like CPUs where you can just socket in a module after it's been fabed lol So you'll have to start our with a chip being 4/6/8, and if it ends up having bad modules, one can only assume it would have them turned off. Though there might be a means to laser cut the "power line" to essentially turn off that module completely, so then it wouldn't be a 4C 120W chip because the other 2 modules are still being powered.

I don't think, though this is a total barely-educated guess, that AMD is going to be having just 8C dies fabed and disable the cores (by whatever means) to have them meet their respected CPU model. It'd be easier to do I guess, but I feel as though they went with this module design for some reason similar to the whole "modular" thought. *shrug* I'm not going to pretend to know how things are going to work, due to the limited amount of info we have (and that seems to be AMD's plan heh), but that is just how it makes sense to me :)

(Off topic: XLR8, you're not by chance "bOingball" are you? I only ask due to your forum avatar heh)

Quote:

---

Originally Posted by Formula350

In the interest of getting to the heart of it:

"John Fruehe September 13, 2010
A module will have 2 cores in it. It will be seen by the hardware and software as 2 cores. The module will essentially be invisible to the system."

---

but hes wrong. hes saying that 1 int core = one cpu core, but thats not true. if hed say: "1 module has 2 int cores and these 2 int cores will be seen by the system as 2 cpu cores" it would be right.

Each module has two integer cores and two 128-bit FPU's.
the two 128-bit FPU's belong to two cores. They just have a single FP scheduler.

It means fewer transistors used, as well as allowing one 256-bit AVX instruction (decoded into two 128-bit micro-ops) to run on both 128-bit FP pipelines simultaneously.
Thus 256-bit AVX can complete in one cycle while at the same time keeping each core's FP pipeline 128-bit

Having a 256b FP pipeline per core would be faster than using modules if therere enough 256b instructions in enough threads. However, it would be a massive increase in die area for a tiny performance gain.

One thing Bulldozer also has is a combined multiply-add instruction, which takes half the time of separate multiply and add instructions (and also has higher precision).
SB has 256-bit FP pipelines per core, but lacks a combined multiply-add instruction.

Quote:

---

Originally Posted by w0mbat

but hes wrong. hes saying that 1 int core = one cpu core, but thats not true.

---

No you're wrong, he never mentions int.

Mats, John mentioned Int cores couple of times, but when trying to postulate what IS a core :)
I think we are digging to deep, we have two cores in module, end of discussion ;)

What a ridiculous thing to argue over. The term "core" doesn't have a solid definition. Not one person here has given a definition of core that would be universally accepted within computer science.

I think this eternal arguing about if it's a core or not exists just because people have nothing better to talk about (like benchmarks?).

I agree that some of it is fueled by boredom and anxiety. But I don't expect it to stop once they are out. IMO, the ambiguity of the terms virtually guarantees it.

It's not ambiguous. One module is two cores.
Yes they share resources. But it's still two cores.

Quote:

---

Originally Posted by Solus Corvus

What a ridiculous thing to argue over. The term "core" doesn't have a solid definition. Not one person here has given a definition of core that would be universally accepted within computer science.

---

ok, ill leave it alone. if AMD says 1 module = 2 core im trying to be ok with it :)

Quote:

---

Originally Posted by Apokalipse

It's not ambiguous. One module is two cores.
Yes they share resources. But it's still two cores.

---

Core 2 duo L2 cache is a share resource.
it's still two cores.

Quote:

---

Originally Posted by Apokalipse

It's not ambiguous. One module is two cores.
Yes they share resources. But it's still two cores.

---

It is ambiguous. 1 module equals two cores because that's how AMD is defining cores. There is no universally agreed upon definition of the term core.

One x86 core consists of an integer unit and floating point unit.
One bulldozer module contains two of each.

The FPU's just share a single scheduler, allowing them to ALSO process 1 x 256-bit instruction (decoded into 2 x 128-bit micro-ops) on top of being able to process their own threads separately.
micro-ops belonging to two threads can be issued by the FP scheduler simultaneously.

Or another way of looking at it:
a set of hardware capable of processing its own thread independently, without sharing execution pipelines with another thread (HyperThreading). A module can process two independent threads simultaneously (it has the hardware to do it, with both integer and FP instructions)

The way it can use two 128-bit FP pipelines to process one 256-bit AVX instruction could be considered a kind of "reverse hyperthreading"
It only works on instructions wide enough to be able to span across multiple cores

Quote:

---

Originally Posted by Apokalipse

One x86 core consists of an integer unit and floating point unit.
One bulldozer module contains two of each.

The FPU's just share a single scheduler, allowing them to ALSO process 1 x 256-bit instruction (decoded into 2 x 128-bit micro-ops) on top of being able to process their own threads separately.
micro-ops belonging to two threads can be issued by the FP scheduler simultaneously.

Or another way of looking at it:
a set of hardware capable of processing its own thread independently, without sharing execution pipelines with another thread (HyperThreading). A module can process two independent threads simultaneously (it has the hardware to do it, with both integer and FP instructions)

---

That's just your definition however. One could just as easily say that a core is everything from instruction fetch through instruction retire.

Even by your definition it wouldn't be two full cores because it isn't two full floating point units. It is one FP that can do work for either "core". Take away one half of that and the CPU couldn't compute the full instruction set.

IMO, "core" is a bad term.

Quote:

---

Originally Posted by Solus Corvus

That's just your definition however. One could just as easily say that a core is everything from instruction fetch through instruction retire.

---

It's not just my definition.
Also, each core in a BD module can and does do its own fetch and retire with its own thread.
Yes, it uses shared hardware to do it. But it still works that way.

Quote:

---

Originally Posted by Solus Corvus

Even by your definition it wouldn't be two full cores because it isn't two full floating point units.

---

Yes it is.
Sharing the FP scheduler (capable of handling two threads of FP micro-ops simultaneously) is just more flexible than two independent schedulers, AND uses less transistors.

Quote:

---

Originally Posted by Solus Corvus

It is one FP that can do work for either "core". Take away one half of that and the CPU couldn't compute the full instruction set.

---

Yes it can.
It just means it has to take two cycles to process each 128-bit micro-op of a 256b AVX instruction.
Actually, BD still can do it that way even with the shared FP scheduler - if one FP pipeline is busy, it can send both 128-bit micro-ops of the 256-bit AVX instruction through one 128-bit pipeline. It just takes two cycles instead of one.

In short, it is not really "1.5 cores". It is 2 cores with a kind of "reverse hyperthreading" for specific 256b FP instructions that can span across two cores, implemented by sharing some hardware, which also saves transistors.

RE: Disabled Units
AMD Never did native "triple core", therefore i doubt they will do native "triple module" (6 core cpu)
It will be a native "4 module" with one disabled.

As for their quad core (two module) that is another story...it is more likely to have a native version down the road, but it wouldnt be zambezi

Quote:

---

Originally Posted by Apokalipse

It's not just my definition.
Also, each core in BD can do its own fetch and retire with its own thread.
Yes, it uses shared hardware to do it. But it still works that way.

---

It's AMD's definition, you have simply accepted it. Try and find me a computer science source that agrees with that definition. You won't, because before now because instruction fetch and retire were traditionally considered part of the core.

Quote:

---

Yes it is.
Sharing the FP scheduler (capable of handling two threads of FP micro-ops simultaneously) is just more flexible than two independent schedulers, AND uses less transistors.
Yes it can.
It just means it has to take two cycles to process each 128-bit micro-op.

---

I agree that it is more flexible and I like that design. But being flexible doesn't mean that it is really two separate FP units. Take away one half and it wouldn't be able to process 256-bit instructions. It is designed to be ganged together to process them. One half can't do half a 256-bit instruction in two steps, that would require a redesign of the FP unit.

From John Fruehe's FlexFP article:

Quote:

---

The beauty of the Flex FP is that it is a single 256-bit FPU that is shared by two integer cores.

---

Quote:

---

Originally Posted by Solus Corvus

It's AMD's definition, you have simply accepted it.

---

Not just AMD's.

Quote:

---

Originally Posted by Solus Corvus

Try and find me a computer science source that agrees with that definition. You won't, because before now because instruction fetch and retire were traditionally considered part of the core.

---

They still are with BD modules.
You do have two sets of fetch, retire operations occurring in the one module simultaneously.
Yes it does it with shared hardware. But it still functions the same way as two cores, with the only exception being that specific 256b instructions can span two cores (by being decoded into 2 x 128b micro-ops).
Which is NOT like hyperthreading. It's exactly the opposite ("reverse hyperthreading")

Quote:

---

I agree that it is more flexible and I like that design. But being flexible doesn't mean that it is really two separate FP units.

---

Being able to process two threads simultaneously without sharing pipelines does.

Quote:

---

Take away one half and it wouldn't be able to process 256-bit instructions.

---

Yes it CAN process 256-bit instructions even with one 128-bit pipeline.
256-bit AVX instructions are decoded into 2 x 128-bit micro-ops anyway. That's how it's able to span across two 128-bit FP pipelines (and they are separate pipelines). They don't process a single 256b micro-op.

With separate schedulers, it would just mean always taking two cycles to process each 128-bit micro-op (one half of the 256b AVX instruction) in the one pipeline.

With a shared scheduler. it means that not only is it possible to process both 128-bit micro-ops in one pipeline (in two cycles), it's also possible to process them in two 128-bit pipelines (in one cycle).
Hence "reverse hyperthreading"

Quote:

---

It is designed to be ganged together to process them. One half can't do half a 256-bit instruction in two steps, that would require a redesign of the FP unit.

---

Yes it can. And does even with the shared scheduler if one FP pipeline is busy.

Quote:

---

Originally Posted by Apokalipse

Not just AMD's.

---

Then feel free to prove it. Find a source outside AMD in the computer science field that agrees with this definition and we will talk. Otherwise it is pointless.

I'm not going to take your word for it. Firstly because reputable individuals in the computer science industry don't necessarily agree with your definition. Secondly because you obviously don't know what you are talking about. One instruction does not equal one cycle, for example.