AMD Zambezi news, info, fans !

[Apokalipse]

Then feel free to prove it.

Are you deliberately ignoring the rest of my explanations?

A BD module is functionally the same as two cores, with the added ability to process specific 256b instructions using both 128b FP pipelines of each core simultaneously.

You seem to be trying to artificially narrow the definition of a core.

you obviously don't know what you are talking about. One instruction does not equal one cycle, for example.

One macro-op doesn't, no. And I never said it did.
In fact I even said that a 256b AVX instruction can take two cycles (2 x 128b micro-ops in one pipeline) - and that's not counting the decode, retire, etc.

[Solus Corvus]

Are you deliberately ignoring the rest of my explanations?

No, I'm dismissing them because they are an obvious attempt to rationalize your position. That a shared scheduler can operate on independent threads, for example, is irrelevant to the point of what actually constitutes a core.

The definition of what is part of the core varies by who you are talking to (intel, amd, my CS professors, etc) and over time. Early patents related to BD had the core and module terms reversed, so clearly it isn't as cut and dry as you suggest. Traditionally everything that wasn't part of IO, memory controller, and cache hierarchy was part of the core. Integration changes all of that and makes the existing terms ambiguous. If future versions of the bulldozer arch allow separate int cores to work on the same thread or eager execution allows two cores to work on one thread then are we to consider a module only one core?

A BD module is functionally the same as two cores, with the added ability to process specific 256b instructions using both 128b FP pipelines of each core simultaneously.

So each half of the FP unit can work on only half of an AVX instruction while the other half can process something separate? No, I don't think so. To process a 256-bit instruction both halves are obligatory from John's description. They can't process half of an AVX instruction and leave the other half for later.

You seem to be trying to artificially narrow the definition of a core.

It is quite the opposite. You are saying that you have the only proper definition of core. I am saying the term is ambiguous because there are multiple definitions being used by various people.

In fact I even said that a 256b AVX instruction can take two cycles (2 x 128b micro-ops in one pipeline) - and that's not counting the decode, retire, etc.

Except that one pipeline can't do both halves of an AVX instruction. That would mean that the circuitry for computing all parts of an AVX instruction are present in both halves of the FP unit. That would be counterproductive and defeat the purpose of sharing it in the first place.

Like I said, you have set yourself on one definition when, frankly, it is a really ridiculous thing to argue over. I don't see the point of discussing it further. Does a 4870 have 1 core, 160 cores, or 800 cores? What would we call a cpu if it had a hundred INT units, 20 FP units, and one frontend/backend? Who cares. What matters is how a particular architecture works with how we use our computers.

[Apokalipse]

No, I'm dismissing them because they are an obvious attempt to rationalize your position.

And rationalisation is bad how?
I'm not simply defining something for the sake of defining it like you are.

That a shared scheduler can operate on independent threads, for example, is irrelevant to the point of what actually constitutes a core.

That doesn't even make sense. How could it not be relevant in the context of Bulldozer?

The definition of what is part of the core varies by who you are talking to (intel, amd, my CS professors, etc) and over time.

Early patents related to BD had the core and module terms reversed, so clearly it isn't as cut and dry as you suggest. Traditionally everything that wasn't part of IO, memory controller, and cache hierarchy was part of the core. Integration changes all of that and makes the existing terms ambiguous. If future versions of the bulldozer arch allow separate int cores to work on the same thread or eager execution allows two cores to work on one thread then are we to consider a module only one core?

All you're doing is arguing definitions.

If you're going down that route, you COULD technically define 1+1=3 as being true.

A BD module functions the same as two cores, with the added ability to schedule two 128-bit micro-ops from one AVX instruction on the two 128-bit FP pipelines.

So each half of the FP unit can work on only half of an AVX instruction while the other half can process something separate?

Yes.
EVERY 256b AVX instruction is decoded into two 128-bit micro-ops, then sent to the FP scheduler.
The FP scheduler can send both 128b micro-ops for that AVX instruction to one FP pipeline or both, depending on what's available.

It is not possible to process one 256b micro-op on 128-bit pipelines even if there are two of them. They have to be decoded into two 128-bit micro-ops.

No, I don't think so. To process a 256-bit instruction both halves are obligatory from John's description. They can't process half of an AVX instruction and leave the other half for later.

You clearly don't understand how x86 decoding works.
An AVX instruction IS NOT processed as one 256b micro-op. It is processed as two separate 128b micro-ops.

It is quite the opposite. You are saying that you have the only proper definition of core.

I'm not even arguing definitions. I'm actually arguing functionality.

Except that one pipeline can't do both halves of an AVX instruction.

It can do both of them. It can't do both of them at the same time, but one ofter the other.

That would mean that the circuitry for computing all parts of an AVX instruction are present in both halves of the FP unit. That would be counterproductive and defeat the purpose of sharing it in the first place.

You won't always have both FP pipelines available. And it does save transistors.

If both 128b micro-ops get simultaneously processed on both 128b pipelines 50% of the time, you will still have better performance than if it happened 0% of the time (like with separate schedulers).

Like I said, you have set yourself on one definition when, frankly, it is a really ridiculous thing to argue over. I don't see the point of discussing it further. Does a 4870 have 1 core, 160 cores, or 800 cores?

irrelevant since we are talking about x86 cores and BD.

What would we call a cpu if it had a hundred INT units, 20 FP units, and one frontend/backend?

That would be completely different, and not analogous to BD.

[BeepBeep2]

Dont feed the troll.

[Manicdan]

i like this argument, you wouldnt believe how much im learning, keep it up apok!

[Solus Corvus]

[snip]

You literally have no idea what you are talking about. I was going to bow out of this pointless discussion, but I don't want your misinformation poisoning good minds like poor Manicdan. That is how the game of internet-telephone starts. I haven't programed in assembly in a REALLY long time, but I figure anything is better then letting such obvious misinformation to spread.

Firstly, there are no 256-bit instructions. x86 instructions can be up to 15 bytes in length. Though the size of the instruction can vary because of the various prefixes, registers, etc - so most are smaller, sometimes significantly so.

If you don't believe me feel free to reference the AMD64 Architecture Programmer's Manual, Volume 3

On page 1:

An instruction can be between one and 15 bytes in length. Figure 1-1 shows the byte order of the
instruction format.

The AMD64 Architecture Programmer's Manual, Volume 4: 128-Bit and 256-Bit
Media Instructions includes the same diagram and references the previous volumes.

So if instructions aren't 32, 64, 128, or 256 bits in length then what does it mean to have a 256-bit instruction?

They both say the following in the definitions section:

256-bit media instructions
Instructions that use the 256-bit YMM registers.

Essentially 64-bit/128-bit/256-bit instructions are instructions that add support for larger registers, new memory addressing modes, new capabilities, etc. When the processor breaks those down into one or two macro-ops it isn't because the instruction is actually too big for a single unit to handle. It does this because macro-ops have a simpler fixed length encoding that the processor can operate on more efficiently, among other things. A single x86 instruction might become two macro-ops because the instruction is actually telling the processor to do several steps that can be handled by different execution units.

Speaking of being handled by different execution units, some instructions can be handled by one of many units and some instructions have to be handled by a specific unit. This is just as true for bulldozer as it is for past processors.

Please reference the Software Optimization Guide for AMD Family 15h [ie, bulldozer] Processors.

In the integer core there are 4 pipelines, 2 INT and 2 AGU. But the units are not identical. Some instructions have to be processed by a particular unit. Examine the diagram on page 36 to see why. Refer to table 10 and you will find lots of instructions that can be done by either INT unit such as ADD or PUSH. While other instructions are done by a specific pipe, such as DIV on pipe 0 and MUL on pipe 1.

This brings us to your claim that either half of the FPU can do it's own AVX instruction simultaneously. This is wrong. On the optimization guide page 38:

Only 1 256-bit operation can issue per cycle, however an extra cycle can be incurred as in the case
of a FastPath Double if both micro ops cannot issue together.

In other words, the entire FPU can only operate on 1 AVX instruction in any given cycle. And that instruction can be delayed if the AVX instruction decodes into 2 macro-ops and one of them requires a pipe currently in use by another instruction. Examine figure 3 on the same page and table 8 on page 232 and you will see why this is the case.

Just as with the integer units, the FPU units have different capabilities. Some instructions can be done on one of many available pipes while other instructions need a specific pipe because it is the only one with that capability. Shuffles on pipe 1, AVX FPMAL on pipe 2 or 3, AVX FPFMA on pipe 0 only, and so on. Refer to table 12 for further examples.

The FP unit needs all of these execution units to execute the whole instruction set. It is an entire unit with it's own scheduler, retire, etc. To take out "half" of that would require a redesign of the unit. So no, the FPU unit isn't like two independent units connected by "reverse hyperthreading". It is a full floating point unit in its own right that can do work for either of the threads from either integer core.

[Dresdenboy]

A quote from the BD article in IEEE micro:

The FPU is a coprocessor model shared
between two integer cores via two-way multithreading.
The FPU has its own out-of-order
engine along with the execution units and register
file, and interfaces with the DE to receive
Cops, the load/store unit to receive and send
load/store data, and the integer cores’ retire
unit to handshake on completion and retire.

http://www.computer.org/portal/web/c...109/MM.2011.23

[Formula350]

i like this argument, you wouldnt believe how much im learning, keep it up apok!

but I don't want your misinformation poisoning good minds like poor Manicdan.

I was about to say the same thing Manicdan... While arguing does generally suck, I don't mind this kind because I learn from it haha I've been into computers for coming up on 2 decades (come 2014), but never been into the architectural details like this

So to Solus, regardless of whether or not who is right or wrong, I'm learning from the back-and-forthness of this debate. It's not so much the info being given about Bulldozer, wrong or right, that I'm learning from, but the specifics on how certain segments of the CPU function are a core level. Indeed, there still is the issue of incorrect info which can mean I'm (or Manic) not getting the right specifics... but in the end it'll be sorted and means I still come out ahead I've been reading all of the posts, so it's not like I intend on stopping heh



So anyways... I was doing some painstaking translation over at zol.com.cn (where a fair bit of leak images stem from), and the one topic talked about the potential drawbacks of running a 'Dozer on an AM3 pseudo+ board. I can't remember but did we discuss the fact that the AM3 would only default to a CPU-NB speed of 2000MHz, where as the 'Dozer's is 2600MHz default? Meaning that unless a person was to overclock/change multipliers, it would be taking a performance hit from that...

20 pages in the thread, it's a little hard to keep track of what all exactly we've discussed lol (basically what I've read here and what I've read elsewhere)

[Solus Corvus]

I was about to say the same thing Manicdan... While arguing does generally suck, I don't mind this kind because I learn from it haha I've been into computers for coming up on 2 decades (come 2014), but never been into the architectural details like this

So to Solus, regardless of whether or not who is right or wrong, I'm learning from the back-and-forthness of this debate. It's not so much the info being given about Bulldozer, wrong or right, that I'm learning from, but the specifics on how certain segments of the CPU function are a core level. Indeed, there still is the issue of incorrect info which can mean I'm (or Manic) not getting the right specifics... but in the end it'll be sorted and means I still come out ahead I've been reading all of the posts, so it's not like I intend on stopping heh

Frankly, you shouldn't be using an argument to learn arch details. When it comes to arguments people tend to reject factual information that disagrees with their view and/or mold the rest around whatever preconceived notion they already had. Everyone does it to a degree no matter how hard we try. This article titled The Science of Why We Don't Believe Science is a good read on that topic.

I think Apokalipse is wrong and just making stuff up. Dresdenboy's link and John Fruehe's article on FlexFP back up my position. But I haven't programmed in assembly in a long time and I could easily have gotten specific details wrong. Our I could be unconsciously rationalizing a false position. That's why I posted the links to the official AMD documents. You don't have to take my word or Apokalipse's, you can go read them and decide for yourself. Not to mention that they are packed with lots of great information that I didn't remotely touch on in my post.

[Manicdan]

Dresdenboy's link and John Fruehe's article on FlexFP back up my position.

you do know that in the JF article, he shows 2 cores each running 128bit FP

[Solus Corvus]

you do know that in the JF article, he shows 2 cores each running 128bit FP

Correct, but he does not show two cores running 256-bit commands.

[Manicdan]

basically BD witll be equal to SB in AVX if all things are equal, due to having 4 pipelines of 256bit
but since not everything is on avx yet, what happens when theres only 128bit commands? then BD has 8 pipelines, and SB has only 4.

so in your opinion the ONLY thing thats missing from calling all 8 BD cores, actual cores, is that its missing 4 avx pipes?

[informal]

Correct, but he does not show two cores running 256-bit commands.

I think Dresdenboy already discussed this on his blog and IIRC one FMAC can process 256bit AVX fp instruction as 2 consecutive 128bit micro ops with variable latency.
Maybe Dresdenboy can join in the discussion and share his view again?

[Solus Corvus]

basically BD witll be equal to SB in AVX if all things are equal, due to having 4 pipelines of 256bit
but since not everything is on avx yet, what happens when theres only 128bit commands? then BD has 8 pipelines, and SB has only 4.

so in your opinion the ONLY thing thats missing from calling all 8 BD cores, actual cores, is that its missing 4 avx pipes?

In my opinion BD is 8 cores because that is how AMD defines their cores. Not because the traditional definition of core necessarily agrees or disagrees with their usage. We aren't in the multiprocessor era where one die is one core and the memory controller, some cache, etc lives outside the core. The definition of the term core was already getting less clear by the time AMD made the first dual-core.

How BD performs will likely depend highly on the application. I am rooting for AMD to have monster multithreaded performance because that is exactly what I need. I do heavy multitasking, deconvolution of 3d image stacks, scientific volume rendering, video/audio encoding, multiple VMs, etc and all are dependent on MT performance, int and fp. Single threaded performance isn't going to matter much at all as far as my web browsing or word processing are concerned.

[Formula350]

Here is everything I got (see: understood) from the 20 Questions John answered on his AMD blog.

-BD modules = 2 cores. Call them what you want, they are two cores and will always be treated, by the OS, as two cores.
-Each core's FPU can be looked at one of two ways, but the end result is essentially the same. Either A) It's two individual 128bit FPUs per core that can only work in parallel to process 256bit AVX extensions/threads/processes (whatever is the correct term lol) or B) Each core shares 1/2 (128bits) of a 256bit FPU, but is only 256bit for AVX ext/thr/proc.

So I'm able to conclude:

a. Each core's FPU can process it's own information on a single cycle, but still only has a single scheduler. So I assume a core will receive it's orders ever so slightly delayed after the other core.

b. A BD has one FPU capable of 256bit (for AVX), per module. Thus, an FX 4000 series will have 2 modules, for 4 cores, with 2 256bit FPUs; an FX 6000 series will have 3 modules (working, disregarding any potential 'disabled' ones), for 6 cores, with 3 256bit FPUs; an FX 8000 series will have 4 modules, for 8 cores, with 4 256bit FPUs.

That about the gist of it?

[Solus Corvus]

So I'm able to conclude:

a. Each core's FPU can process it's own information on a single cycle, but still only has a single scheduler. So I assume a core will receive it's orders ever so slightly delayed after the other core.

The FPU is it's own unit. Neither core really owns it or owns a half of it. The threads from either INT core can send FP commands to the FPU, but only one thread at a time. The commands are decoded, renamed, scheduled, and buffered to wait for execution on the appropriate pipe.

From page 37 of the bulldozer optimization guide I posted a link to above:

FPU Features Summary and Specifications:
•The FPU can receive up to four ops per cycle. These ops can only be from one thread, but the
thread may change every cycle. Likewise the FPU is four wide, capable of issue, execution and
completion of four ops each cycle. Once received by the FPU, ops from multiple threads can be
executed.
•Within the FPU, up to two loads per cycle can be accepted, possibly from different threads.
•There are four logical pipes: two FMAC and two packed integer. For example, two 128-bit
FMAC and two 128-bit integer ALU ops can be issued and executed per cycle.
•Two 128-bit FMAC units. Each FMAC supports four single precision or two double-precision
ops.

Skipping over a few points to page 38:

•Only 1 256-bit operation can issue per cycle, however an extra cycle can be incurred as in the case
of a FastPath Double if both micro ops cannot issue together.

Please examine Figure 3 on page 38 to help understand the first and last bullet point. I'll BRB if you want further clarification.

[Formula350]

Please examine Figure 3 on page 38 to help understand the first and last bullet point. I'll BRB if you want further clarification.

No, that's a good tid-bit of info, thanks


Came across some pics of MSI's 990FXA-GD80, posted by MSI's Sales Manager heh While unlikely they'll get pulled, just in case I yoinked em and tossed them online.

Specs:


More here: http://pro-clockers.com/images/revie...gd80%20teaser/

Source: MyGarage.ro

[muziqaz]

nah this time I will skip MSI FXA board. Had 790FX and 890FXA, good boards, but cannot hold voltages straight Will be trying ASUS chrosshair I suppose.

[Formula350]

nah this time I will skip MSI FXA board. Had 790FX and 890FXA, good boards, but cannot hold voltages straight Will be trying ASUS chrosshair I suppose.

I'm partial to Gigabyte, yet if their AMD offerings don't jump on the black PCB bandwagon, I'll be rather displeased lol The price I didn't pay for this ASRock was too good to pass up No, I did want it and am quite happy with it for the most part. Sure, there are things I'd like to be changed/different (BIOS options mainly), but it's an older board and that's unlikely :P I haven't been able to stress it any though since my 555BE is an epic POS, confirmed first by my 890GX and solidified by this FX. Don't know how cdawall got it to over 4GHz, but I can't even get it over 3.6 stable

But that's off topic! I'd love to get a CVF, but most of what budget I have will be spent on an FX 8000 series So the MSI 890FXA-UD65 will have to suffice if/when something new comes along.

[tbone8ty]

gigabyte hopefully will have a tonka bulldozer version heatsink on there boards called the G1 Tonka

[AKM]

Ouch, this doesn't look very good, BD 8C being positioned slightly lower than 4C Core i7, though I guess that makes sense, most desktop workloads use 4 cores at most, and isn't one SNB core as big as 2 BD cores? So it'd be a miracle if per core perf. would be close, turbo can mitigate that somewhat but not enough. I hope they do better in server, that's hugely more important for AMD.

[Olivon]

Bulldozer will be late ... Expect more august ...

[Warwian]

w0mbat posted this ASUS-slide in the "Preliminary Bulldozer and Llano Pricing Revealed"-thread (http://www.xtremesystems.org/forums/...0&postcount=32) which I thought was interesting.



Now as I said in that thread (http://www.xtremesystems.org/forums/...6&postcount=37) I tried to figure out the frequencies that he had censored.

And as no one in that thread seemed interested I thought I'd try to post it here. Anyone have any idea what the slide says?
When I zoomed in and studied the pixels it looks like the FX-8110 has a stock frequency of 3.6 GHz and a maximum frequency of 4.0 GHz through AMD's Turbo CORE. The FX-8130P is harder to make out but it looks to have a stock frequency of 3.8 GHz and a maximum frequency of 4.2 GHz through AMD's Turbo CORE.

Anyone have any other ideas? Or is this old news? I haven't seen the slide anywhere else and I thought it'd be interesting to try and figure out the actual frequencies.

[FlanK3r]

Bulldozer will be late ... Expect more august ...

I dont think so....It is not reason.

[undone]

w0mbat posted this ASUS-slide in the "Preliminary Bulldozer and Llano Pricing Revealed"-thread (http://www.xtremesystems.org/forums/...0&postcount=32) which I thought was interesting.



Now as I said in that thread (http://www.xtremesystems.org/forums/...6&postcount=37) I tried to figure out the frequencies that he had censored.

And as no one in that thread seemed interested I thought I'd try to post it here. Anyone have any idea what the slide says?
When I zoomed in and studied the pixels it looks like the FX-8110 has a stock frequency of 3.6 GHz and a maximum frequency of 4.0 GHz through AMD's Turbo CORE. The FX-8130P is harder to make out but it looks to have a stock frequency of 3.8 GHz and a maximum frequency of 4.2 GHz through AMD's Turbo CORE.

Anyone have any other ideas? Or is this old news? I haven't seen the slide anywhere else and I thought it'd be interesting to try and figure out the actual frequencies.

Good analysing. If it's true it will be a good sign for amd. Even if the Zambezi single core abillity can only reach Westmere, the higher frequency will be more than enough to fill the gap. 95w with 8 core @3.6-4.0ghz is awesome.