AMD - Zen chitchat

[CAT-THE-FIFTH]

Don't know if you've seen it yet CAT, but there's also a performance-centric review of the two laptops: https://www.laptopmag.com/articles/a...l-8th-gen-core

Ryzen comes out of it pretty damn well

Yeah,it really does!!

I can't wait for the Ryzen 7 laptops!!

Edit!!

Its why I was whining so much about equalising the test systems - it shows you with everything else equal Ryzen is very good in laptops.

Hmm,on a side note I wonder if AMD will push the Ryzen 3 with a RX560 class card - might be a way to eat into those GT1050 laptop sales??

[CAT-THE-FIFTH]

This has been spotted on Reddit:

https://www.reddit.com/r/Amd/comment..._hbm2_onboard/

"AMD Fenghuang Raven".

Its under "integrated graphics". Some on Reddit think it could be pointing to the Ryzen Gaming leak on that slide.

At the very least it probably is what the Intel dGPU is,a 1792 shader part with 2GB of HBM2.

[scaryjim]

... At the very least it probably is what the Intel dGPU is,a 1792 shader part with 2GB of HBM2.

That looks most likely to me, although I wouldn't rule out this having some part to play in Ryzen Gaming. Details for the memory are very odd though, 2.4GHz/32bit? Could just be a result of unsupported/unrecognised configuration I guess, but it doesn't "fit" with the other results, particularly not the Vega HBM2 results (which show 945MHz/4092-bit)...

[DanceswithUnix]

@DanceswithUnix: WRT power efficiency, IIRC there are certain workloads where SMT makes zero to negative impact on performance but may increase power draw anyway e.g. through cache thrashing. I'm not certain how much of the responsibility for managing such things lies with hardware, kernel and software?

Responsibility? That's a system effect, so all of the above. Hardware configuration of N in the N set associativity of the cache, kernel in thread migration and scheduling, software for how many threads are used and how tightly coupled they are. Of those, the software devs have the best visibility of what is going on, but chances are they will only be developing with a very narrow range of hardware in mind or available to test, and IME a lot of programmers aren't any good at threaded programming and tend to be the weakest link despite having in many ways the easiest job.

But on Jim's point, I don't see how SMT on or off will impact the lower frequency limit of the CPU and hence don't see how it will change how the voltages are set. Leakage can set the bias in a transistor which can alter the upper switching frequency, or at least it used to and I assume that still holds for FinFETs, I just don't see a mechanism where it influences lower clock speed. In a low wattage rated part you will hit the thermal limit long before the transistor max switching speed becomes an issue.

It is interesting though that Intel gave up on HT on the Atom range and AMD never bothered in any form with the cat CPU range on the grounds that it was more energy efficient at the lower end to just add more cores if you want more threads.

[scaryjim]

... Leakage can set the bias in a transistor which can alter the upper switching frequency, or at least it used to and I assume that still holds for FinFETs ...

That was kind of the point I was working on ... although most of what I've picked up was reading around nvidia's problems with early Fermi! iirc you increase voltage to compensate for high leakage silicon and hit higher clock speeds, but that increases heat generation, and hotter silicon leaks more, so you end up with a positive feedback loop.

Anyway, applying that principle, my hypothesis is that turning off SMT reduces power draw, which reduces the heat generated in the chip, which helps avoid leakage runaway, allowing the chip to run at a slightly lower voltage than might be required if SMT was turned on.

But I could be getting completely the wrong end of the stick!

[CAT-THE-FIFTH]

That looks most likely to me, although I wouldn't rule out this having some part to play in Ryzen Gaming. Details for the memory are very odd though, 2.4GHz/32bit? Could just be a result of unsupported/unrecognised configuration I guess, but it doesn't "fit" with the other results, particularly not the Vega HBM2 results (which show 945MHz/4092-bit)...

Wouldn't that be the CPU part,ie,32 bit memory controller and 2400MHZ DDR4??

[scaryjim]

Wouldn't that be the CPU part,ie,32 bit memory controller and 2400MHZ DDR4??

32bit controller on CPU memory would be weird-ass: a standard DIMM/SODIMM is 64-bit!

I know Intel have done some of their Atom chips with just a 32bit controller (presumably intended to be used only with soldered-on memory chips) but you wouldn't pair one of those with a 28CU GPU, surely?

I wondered if it might be reading the infinity fabric width/clockspeed....?

[CAT-THE-FIFTH]

32bit controller on CPU memory would be weird-ass: a standard DIMM/SODIMM is 64-bit!

I know Intel have done some of their Atom chips with just a 32bit controller (presumably intended to be used only with soldered-on memory chips) but you wouldn't pair one of those with a 28CU GPU, surely?

I wondered if it might be reading the infinity fabric width/clockspeed....?

Unless AMD has managed to implement some sort of Hypermemory type arrangement,although I don't know how that would work.

[Bagnaj97]

Unless AMD has managed to implement some sort of Hypermemory type arrangement,although I don't know how that would work.

Well Hypermemory was an ATI technology, so it's not impossible...

[DanceswithUnix]

But I could be getting completely the wrong end of the stick!

I think so. Voltage does not compensate for leaky silicon, but if you are extreme overclocking (LN2 type stuff) it can improve your chances of higher clocks.

If you turn off SMT then the part runs cooler, that gets you the thermal headroom to *increase* voltage which gives you faster transistors so you can up the frequency. That is a basic engineering compromise, do you want the throughput of the threads or higher clock speeds?

Fermi (or the 480 at least) just plain missed its clock targets, so to increase the clocks they needed to increase the voltage which is usually a problem but in the case of the GTX480 the devices were generally quite poor so all the shader blocks were tested and the leakiest of them were disabled to get the overall power consumption down.

[DanceswithUnix]

Unless AMD has managed to implement some sort of Hypermemory type arrangement,although I don't know how that would work.

Hmm, can anyone remember how wide was the memory on Iris?

[scaryjim]

Hmm, can anyone remember how wide was the memory on Iris?

I can't, but since it was implemented as a single DRAM chip 32bits would not be a ridiculous suggestion...

Implications? Intel's MCM Kaby-G processors have an eDRAM chip too? Wouldn't that be kind of redundant with an AMD dGPU on the same substrate?

[DanceswithUnix]

I can't, but since it was implemented as a single DRAM chip 32bits would not be a ridiculous suggestion...

Going back and reading the source "leak", I suspect it was benchmarked on 32 bit Windows. Nothing more.

[scaryjim]

Going back and reading the source "leak", I suspect it was benchmarked on 32 bit Windows. Nothing more.

The SiSoftSandra result pages - http://ranker.sisoftware.net/show_ru...0b6c5f8c8&l=en - states OS was "Windows x64 10.0.6"

That said, there's some other oddities in the result descriptions if you look down the video memory bandwidth benchmarks, like a Vega Frontier Edition with 24GB of RAM... so probably just a hardware misread.

[CAT-THE-FIFTH]

Hmm, can anyone remember how wide was the memory on Iris?

Sadly,I can't remember!

I can't, but since it was implemented as a single DRAM chip 32bits would not be a ridiculous suggestion...

Implications? Intel's MCM Kaby-G processors have an eDRAM chip too? Wouldn't that be kind of redundant with an AMD dGPU on the same substrate?

Well unless Intel have simply taken one of their exisiting eDRAM parts and used it as the basis of the SKU??

AFAIK,the eDRAM also helps CPU performance too,but the big question is whether its still a separate chip or have Intel manage to integrate it into the CPU itself now??

[scaryjim]

... Well unless Intel have simply taken one of their exisiting eDRAM parts and used it as the basis of the SKU?? ...

I've realised that doesn't make sense. We've seen the pictures of the package, and it doesn't have an eDRAM chip on it. So it can't be an eDRAM SKU.

The whole point of the eDRAM was that it was too expensive to fab that much cache (64MB/128MB) as part of the CPU. But yeah, no DRAM chip on the package kind of knocks that thought on the head...