AMD: Speculation, Rumors, and Discussion (Archive)

[Deleted member 13524]

I'm still curious how this happened in the first place. Shouldn't it have been caught in QA or further back in the engineering chain? It kind of shakes my faith in AMD's engineering team.

That curiosity isn't relevant for the architecture forum, at least not anymore now that it's been solved.
You can create a thread about that in the industry section and leave this one alone.
Enough powergate solution, we have other stuff to discuss now.

The RX470 seems to have close to 75% the performance of the RX 480, at least in AotS:
http://www.ashesofthesingularity.co...-details/c4f20d31-5c68-4047-973c-d67c3b8fec7c
Same CPU model but it seems to be clocked a bit higher.

 

[DavidGraham]

It's definitely a huge victory for them as it moves games rendering away from Dx11 and OpenGL which weren't well suited to their hardware. Dx12 and Vulcan in particular, as it is Mantle with a different name, have successfully moved things such that the rendering APIs of the future are far more suited to their hardware.

I just stated that games that promised Mantle support have dropped it for the good old DX11 support. They didn't even bother with DX12 or Vulkan. So no it didn't move things along that path. Games support DX12 now because that's what happens with the introduction of any new APIs, same thing happened with DX11 and DX10 before it.

It was inevitable that Mantle became an API that was controlled by committee if was ever to fulfill it's promise of being open to all hardware as AMD has always stated was their goal for Mantle. Keeping it away from the being open would have resulted in nothing more than a closed API similar to CUDA, which was not what they stated they wanted for Mantle.

The inevitability was AMD's fault, The API had problems since it's introduction: memory compatibility issues, architecture compatibility, didn't work well with GPU limited scenarios which resulted in small fps boost. late arrival to games. It wasn't even the default API for running it's supported games.

It is now an industry standard. They are no longer the only group developing it and hence aren't the only group bearing the cost of developing it. They've successfully gotten Nvidia and other industry players to be involved in it.

Exactly, which did nothing to improve their image or market share. NV was first to support Vulkan with drivers. and According to DOTA 2/Talos Principle benchmarks, NV holds the performance advantage in both Vulkan and OpenGL.

Just the fact that the new Doom is using Vulcan (Mantle) rather than OpenGL is a huge win for AMD. The fact that Nvidia are forced to support Vulcan (Mantle) is a huge win.

Not a huge win, late to the party, With AMD having far worse OpenGL performance compared to NV in that game. Expect Vulkan to improve the situation, but not by much.

 

[Dave Baumann]

My guess would be last minute voltage bump to achieve higher boost speeds.

1) Why would there be an additional voltage to go to?

2) With power mechanisms such as they are this is going to have a negative affect on performance (see results with people undervolting).

 

[sonen]

1) Why would there be an additional voltage to go to?

Because had it been possible to achieve higher boost speeds in a safe and comprehensive manner without additional voltage, would mean that there was too much voltage to begin with that can be removed in a safe and comprehensive manner
Not saying that is what happened..

 

[Dave Baumann]

Process VMAX is one of the first things that is characterised and it is already utilised within the peak clock/voltage state available with ASIC distribution, it just a question of what clock can be achieved for the voltage and the residency in that power state for a given target design.

 

[CarstenS]

The zeroth rule of measurement: your measurement technique will affect the results.

The first proof for that rule: If no measurements had been taken, all would be in perfect order?

Process VMAX is one of the first things that is characterised and it is already utilised within the peak clock/voltage state available with ASIC distribution, it just a question of what clock can be achieved for the voltage and the residency in that power state for a given target design.

So, 14nm GloFo is ~27% less than 16nm TSMC? As in 1700-ish vs. 1200-ish. Certainly, that cannot be what it is you're implying?

 

[Dave Baumann]

You can't necessarily tell what VMAX is for an process based on a single sample as the voltages per state will alter per-chip. Additionally VMAX for a product will have the companies reliability model applied to it as well.

 

[Jawed]

The first proof for that rule: If no measurements had been taken, all would be in perfect order?

Hell, no.

 

[Razor1]

So, 14nm GloFo is ~27% less than 16nm TSMC? As in 1700-ish vs. 1200-ish. Certainly, that cannot be what it is you're implying?

A bit confusing what he stated, but to me it sounds like voltage is based on the node, and frequency is based on design based on that voltage.

edit sorry didn't see your response Dave!

 

[CarstenS]

Each node has a manufacturer's recommended voltage. Someone mentioned it being 0.8 volts for TSMC 16FF, IIRC. Kind of a baseline.

 

[el etro]

My guess would be last minute voltage bump to achieve higher boost speeds.

My guess is that the TDP target was lower. I think the card was supposed to perform at 390x level, but with this performance the efficiency got out of control.

 

[CSI PC]

Each node has a manufacturer's recommended voltage. Someone mentioned it being 0.8 volts for TSMC 16FF, IIRC. Kind of a baseline.

The Vnom was 0.85V, with Vlow at 0.72V for 16nm.
Vnom was 0.9V for 28nm, with regards to TSMC (context being comparable part used for processors and GPUs).
If the info I have is still correct.
Would be interesting to compare the voltage-frequency scaling and also leakage of both 14 and 16nm.
Cheers

Edit:
Changed value to 28nm rather than showing 20nm.

 

[seahawk]

1) Why would there be an additional voltage to go to?

2) With power mechanisms such as they are this is going to have a negative affect on performance (see results with people undervolting).

It kind of feels wrong to anser this, as you have vastly more knowledge than I do on the topic, but more voltage has often allowed more chips to achieve the desired frequency than low voltage. Considering that AiBs reported some not marginal variations in silicon quality, it might have been a solution to make more dies hit the desired frequencies. If I look at the custom designs from NV I also notice that those having high frequencies and consuming lots of power are cheaper than those having high frequencies and consuming less power. And considering that EVGA already lists the FTW DT (DT de-rated) for chips that did not hit the TW speeds within the power budget, I am thinking this could be the answer.

 

[function]

I think the idea is that AMD had already determined the highest voltage planes that the chip / process was suited to, and that we shouldn't assume there was another voltage level for them to go to late in the day.

Being flexible with TDP and binning might well be later options than adding voltage planes, if AMD were already intending to use up to where they'd determined was suitable for the process.

 

[Grall]

That AMD determined highest operating voltages and whatnot early on does not preclude a late-in-the-day voltage/corresponding clock frequency bump; theoretically the RX 480 could have been intended to run at lower volts than it actually released at. Possibly.

 

[Ext3h]

That AMD determined highest operating voltages and whatnot early on does not preclude a late-in-the-day voltage/corresponding clock frequency bump; theoretically the RX 480 could have been intended to run at lower volts than it actually released at. Possibly.

Much likely. We will see that when P11 is released officially, how efficient Polaris can really be if not pushed to the performance limit, but rather tuned for peak efficiency for use in laptops and alike.

 

[CarstenS]

My hope is, that we will see this with RX 470 already, having a board power of 110 watts (maybe +10 again?). That would put it in GTX 1060 ballbark.

 

[Ext3h]

I have to ask a strange question:
Does anyone know if it is possible to tune the current 14/16nm processes for a trade off between transistor switching speed / power drain, and yields on the other side?
Speaking figuratively, so you have the choice between a higher base line consumption, plus possibly a higher voltage requirement to get even the "bad" transistors to work, versus a broken die all together on the first "bad" transistor?

And what is the chance that AMD went with the safe bet?

 

[homerdog]

Much likely. We will see that when P11 is released officially, how efficient Polaris can really be if not pushed to the performance limit, but rather tuned for peak efficiency for use in laptops and alike.

For real though, reality is setting in and all indicators point to GP107 absolutely clobbering P11 in terms of efficiency. If it doesn't then we can assume P10 is simply broken in some way (which I don't think is the case).

 

[Deleted member 13524]

For real though, reality is setting in and all indicators point to GP107 absolutely clobbering P11 in terms of efficiency.

Based on what exactly?
GP106 still isn't out yet, though for all we know is that its power/performance seems to be wrecked by GP104 (half the performance for 30% less power consumption?). Polaris 10 in its RX480 form seems to be working above its ideal power curves, since the RX470 offers much better performance per watt.

Seems to me that Polaris' efficiency goes up as you lower absolute performance, whereas Pascal's goes down.
I'm not saying P11 will be more efficient that GP107, just that it's too early to draw conclusions. At the very least because those are two completely undisclosed GPUs for the moment.