I still fail to see the point of pairing a super slow 11CU GPU with HBM2, and adding 1 CCX to the mix to make a super expensive thing that will be outperformed by a $400(or less) cpu+gpu combination on the market. And im not talking about games here.
And adding more CU will just make things worse, (cost).
A single HBM 4-Hi stack was $12 and a 1000 mm^2 interposer was $25.Volume production for HBM2 is bigger, so the cost will be lower. APU/NPU die will cost 20-30$, at best, and interposer will cost at best 10-15$.
So in worst case scenario we are looking at 80$ manufacturing cost, for something that can be sold at 349-399$ price tag.
RX 460 has 112 Gb/s memory bandwidth.HBM2 stack - 8$.
The die: 20-30$. If we account for 30$, Die+ HBM2 stacks - 46$.
Interposer - 15$. Total = 51$.
Substrate and packaging cost = 30$ max, including 1$ TSV's.
Total in worst case scenario - 83$.
AMD have bought in Q3 and Q4 2016 a volume of supplies for 80 000 000 $, which was pointed in one of previous conference calls. It is HBM2 supply. You have to bare in mind that HBM1 stack cost was so high because of limited production. HBM2 production was bigger: both AMD and Nvidia was/will be using it.
Sure RX460 can have/need 112 GB/s of bandwidth. But I do not believe people understand why is Vega going to use such massive bandwidth for.RX 460 has 112 Gb/s memory bandwidth.
A single stack 2 Hi-HBM2 2GB module @ 1 (Gb/s) per pin [slowest one] has 128 Gb/s.
You don't need 2 stacks for 16CU graphics. I am assuming only one needed. This drops HBM2 costs and interposer costs [smaller area].
I estimate around $60-65. In any case even assuming you are accurate, this can be a compelling product for many users.
I'm not so sure you'll see HBM2 APU's this year. The cost is still up there. As just another wild guess here, I can see a server APU though. 24 cores/48 threads and some Vega GPU with HBM2 in lieu of AVX. Arguably that would perform better than AVX.
There is a server APU planned with HBM2. I expect that we will see such a product in 2018.
http://www.fudzilla.com/news/processors/37494-amd-x86-16-core-zen-apu-detailed
The rumoured specs were 16C/32T with Vega GPU (formerly called Greenland) .
If AMD is going to make an APU with a HBM2 stack, why have a monolithic APU?
If the interposer will be there anyway, the cost isn't increased, at least for HBM2 skus.The interposer adds a cost they frankly can't afford. They need something closer to Intel's EMIB.
If the interposer will be there anyway, the cost isn't increased, at least for HBM2 skus.
Let me give you an example. Over 50 GB/s of BWdth you get with 3200 MHz RAM memory. And that will be enough to feed 11 Vega CU's .
You've often mentioned high interposer costs.The interposer adds a cost they frankly can't afford. They need something closer to Intel's EMIB.
I agree. It's extremely difficult to imagine any 11 CU APU being fed with 2 channel DDR4.I would love to know how you came up with this conclusion.
For example the iGPU found in Steamroller APUs (8 CUs @ 866MHz) is bandwidth starved until > 80GB/s (~90MB/s per GFlop) and the performance scales well up to 96GB/s (~108MB/s per GFlop).
Raven is expected to have > 1.8TFlops of throughput which at 51.2GB/s (DDR-3200) would mean < 28.5MB/s of bandwidth per GFlop, which naturally is also shared between the CPU and the GPU.
Even RX 480 cards are bandwidth starved and they have < 44MB/s of dedicated bandwidth available per GFlop.
So essentially the DCC in Vega should reduce the bandwidth requirement by < 3.2x compared to scenario where DCC is not used at all (Steamroller, GCN 1.1), so that the 11 CU Vega GPU in Raven wouldn't be bandwidth starved at DDR-3200MHz.
AMD stated -40% reduced bandwidth requirement from DCC for GCN 1.2, IIRC.
Raven Ridge APUs will use Vega architecture.I would love to know how you came up with this conclusion.
For example the iGPU found in Steamroller APUs (8 CUs @ 866MHz) is bandwidth starved until > 80GB/s (~90MB/s per GFlop) and the performance scales well up to 96GB/s (~108MB/s per GFlop).
Raven is expected to have > 1.8TFlops of throughput which at 51.2GB/s (DDR-3200) would mean < 28.5MB/s of bandwidth per GFlop, which naturally is also shared between the CPU and the GPU.
Even RX 480 cards are bandwidth starved and they have < 44MB/s of dedicated bandwidth available per GFlop.
So essentially the DCC in Vega should reduce the bandwidth requirement by < 3.2x compared to scenario where DCC is not used at all (Steamroller, GCN 1.1), so that the 11 CU Vega GPU in Raven wouldn't be bandwidth starved at DDR-3200MHz.
AMD stated -40% reduced bandwidth requirement from DCC for GCN 1.2, IIRC.
Raven Ridge APUs will use Vega architecture.
Draw Stream Binning Rasterizer. In this technology there is a key to how it will work. Even its name should tell you a lot. Everything in the execution pipeline is being "streamed" to the cores. Because each part of the rasterization process is tiled, there is much less requirement for massive amount of memory bandwidth. Cores are much more capable, and at the same time resource prone. The thing is that every Vega architecture GPU will have High Bandwidth Cache Controller, regardless if they have HBC(!), or not. It allows the framebuffer to locate particular data in the memory that is needed, and deliver it to the cores, when it is needed.
Thirdly, pixel engine is detached from Memory Controller, and it is a client of L2 cache. As a result of all of this the requirements for bandwidth in small GPUs will be... smaller. I am not saying that HBM2 will not help. The difference will be huge.
Lets just say that 11 CU chip, with 704 GCN cores from Vega arch, and without HBM can have performance of RX 550.
P.S. where did you got the 1.8 TFLOPs number for Raven Ridge APU?
AFAIK, a HBCC GPU will need a higher bandwidth than one without the HBCC. At the most basic, it interleaves between the GPU and external memory. The memory bandwidth requirement is thus in excess of an existing GPU. A HBCC will not be able to work without high bandwidth low latency memory. It needs HBM as the cache, DDR4 need not apply. In return it saves the amount of video memory needed.Raven Ridge APUs will use Vega architecture.
Draw Stream Binning Rasterizer. In this technology there is a key to how it will work. Even its name should tell you a lot. Everything in the execution pipeline is being "streamed" to the cores. Because each part of the rasterization process is tiled, there is much less requirement for massive amount of memory bandwidth. Cores are much more capable, and at the same time resource prone. The thing is that every Vega architecture GPU will have High Bandwidth Cache Controller, regardless if they have HBC(!), or not. It allows the framebuffer to locate particular data in the memory that is needed, and deliver it to the cores, when it is needed.
Thirdly, pixel engine is detached from Memory Controller, and it is a client of L2 cache. As a result of all of this the requirements for bandwidth in small GPUs will be... smaller. I am not saying that HBM2 will not help. The difference will be huge.
Its the other way around. HBCC is there to limit the requirements for bandwidth, and control the streaming of data from any type of memory(Volatile, and non-volatile) to the GPU.AFAIK, a HBCC GPU will need a higher bandwidth than one without the HBCC. At the most basic, it interleaves between the GPU and external memory. The memory bandwidth requirement is thus in excess of an existing GPU. A HBCC will not be able to work without high bandwidth low latency memory. It needs HBM as the cache, DDR4 need not apply. In return it saves the amount of video memory needed.
Draw Stream Binning Rasterizer and other architectural changes are a separate issue. If a GPU with those improvements needs X bandwidth, then one with those improvements + a HBCC will need X+ bandwidth.
Its there to increase the performance of the GPU. HBCC is not only about memory bandwidth, its about also controlling the data streaming from any source to the GPU.If Vega can cope with such a low bandwidth, what's the point in using HBM2 in the first place?
Especially when HBM2 is extremely expensive and is expected to have extremely limited availability initially.
GDDR5/X would allow higher and generally much more flexible memory capacity, at lower cost. Also in case the bandwidth requirements are modest, it is possible to use low(er) power GDDR5/X variants too.
I expect the iGPU in Raven to be clocked anything between 1.1 - 1.3GHz, hence > 1.8TFlops.
But the cache itself has high bandwidth requirements. So how does HBCC limit the need for bandwidth in the absence of the fast cache?Its the other way around. HBCC is there to limit the requirements for bandwidth, and control the streaming of data from any type of memory(Volatile, and non-volatile) to the GPU.
AFAIK, a HBCC GPU will need a higher bandwidth than one without the HBCC. At the most basic, it interleaves between the GPU and external memory. The memory bandwidth requirement is thus in excess of an existing GPU. A HBCC will not be able to work without high bandwidth low latency memory. It needs HBM as the cache, DDR4 need not apply. In return it saves the amount of video memory needed.
Exactly, HBCC just "knows" where the data is, and it can draw them at the correct time, when it is needed.I think you're on the wrong track here. AFAIK the HBCC reduces the significant software overhead from communications over any bus. This is it's major advantage. For example in the event of a VRAM buffer overflow a GPU with HBCC should have a significant latency advantage accessing system RAM over one which addresses system RAM with drivers.
Cache is just HBM2...But the cache itself has high bandwidth requirements. So how does HBCC limit the need for bandwidth in the absence of the fast cache?
The interposer adds a cost they frankly can't afford. They need something closer to Intel's EMIB.