Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Nvidia Pascal GPU to Feature 17B Transistors and 32GB HBM2 VRAM

wccftech.com

Post reply on HN
Print view View original

31–40 of 97 posts

Re: Nvidia Pascal GPU to Feature 17B Transistors and 32GB HBM2 VRAM

#31

Post by ak217 »

bd wrote: post #29
gwern wrote: post #26

> With 8Gb per DRAM die and 2 Gbps speed per pin, we get approximately 256 GB/s bandwidth per HBM2 stack. With four stacks in total, we will get 1 TB/s bandwidth on NVIDIA’s GP100 flagship Pascal which is twice compared to the 512 GB/s on AMD’s Fiji cards and three times that of the 980 Ti’s 334GB/s. > The Pascal GPU would also introduce NVLINK which is the next generation Unified Virtual Memory link with Gen 2.0 Cac…

Yup, this is exactly the marketing angle Nvidia CEO was using in his GPU Technology Conference presentation (10x speed-up on deep-learning vs their current Maxwell architecture): http://blogs.nvidia.com/blog/2015/03/17/pascal/

This also seems to be the motivation behind the already available Titan X with its 12GB of RAM. Some of the gaming hardware reviewers are scratching their heads as to why anyone would need 12GB attached to one die. I chuckled when I saw those reviews that were totally oblivious to the deep learning applications.

Re: Nvidia Pascal GPU to Feature 17B Transistors and 32GB HBM2 VRAM

#32

Post by zokier »

bearbin wrote: post #10
rwmj wrote: post #8

What are the parts marked "R125" around the edge?

I believe they are inductors, part of a switch-mode power supply to reduce the voltage of incoming power to the level required by the cores (AFAIK ~1V).

The definitely are inductors (being labeled "Lxx" on PCB is a sure tell-tale sign), and the small 48ish pin packages near them are most likely SMPS controllers. Seems bit crazy that there are total of 18 of them, but I suppose that's what you gotta do when you are pushing possibly hundreds of amps of current.

Re: Nvidia Pascal GPU to Feature 17B Transistors and 32GB HBM2 VRAM

#33

Post by jfb »

ak217 wrote: post #31
bd wrote: post #29

Earlier quoted context omitted.

Yup, this is exactly the marketing angle Nvidia CEO was using in his GPU Technology Conference presentation (10x speed-up on deep-learning vs their current Maxwell architecture): http://blogs.nvidia.com/blog/2015/03/17/pascal/

This also seems to be the motivation behind the already available Titan X with its 12GB of RAM. Some of the gaming hardware reviewers are scratching their heads as to why anyone would need 12GB attached to one die. I chuckled when I saw those reviews that were totally oblivious to the deep learning applications.

It's easy to get lost in the noise of the "enthusiast" webring with their semiliterate "benchmarks" and overly paginated "reviews". They punch well above their actual purchasing weight and thus think they're a lot more important then they actually are.

Re: Nvidia Pascal GPU to Feature 17B Transistors and 32GB HBM2 VRAM

#34

Post by foobarge »

onion2k wrote: post #7
hyperpallium wrote: post #6

4096bit memory interface is surely supercomputer territory. My ZX81 only had 8192 bits of memory (1KB).

And it could do 3D graphics. Sort of. 3D Monster Maze: https://www.youtube.com/watch?v=nKvd0zPfBE4

Nice - who needs 8K. 8. K. I haven't even updated to 4K. I don't think I have anything that runs 1080p.

Re: Nvidia Pascal GPU to Feature 17B Transistors and 32GB HBM2 VRAM

#36

Post by steckerbrett »

zokier wrote: post #32
bearbin wrote: post #10

Earlier quoted context omitted.

I believe they are inductors, part of a switch-mode power supply to reduce the voltage of incoming power to the level required by the cores (AFAIK ~1V).

The definitely are inductors (being labeled "Lxx" on PCB is a sure tell-tale sign), and the small 48ish pin packages near them are most likely SMPS controllers. Seems bit crazy that there are total of 18 of them, but I suppose that's what you gotta do when you are pushing possibly hundreds of amps of current.

Makes the normal buck converter arrangement too. Controller, inductor, diode. The GPU will be taking like half a volt so things are definitely going to be getting toasty.

Re: Nvidia Pascal GPU to Feature 17B Transistors and 32GB HBM2 VRAM

#37

Post by cwyers »

bryanlarsen wrote: post #25
raverbashing wrote: post #20

Earlier quoted context omitted.

Not sure about their graphics division, but AMD has stopped innovating in the CPU department...

So has Intel. Skylake (2016) and Sandy Bridge (2010) have roughly comparable single core desktop benchmarks. Power/performance ratios have increased drastically, but that's mostly because of process improvements. AMD has been stuck on 28nm for a long time, but that's not AMD's fault.

> AMD has been stuck on 28nm for a long time, but that's not AMD's fault.

How isn't it?

Re: Nvidia Pascal GPU to Feature 17B Transistors and 32GB HBM2 VRAM

#38

Post by CHY872 »

varelse wrote: post #27
icegreentea wrote: post #16

Earlier quoted context omitted.

That's because GPUs were frozen at the 28nm node since like 2011. It'll be ~4 years of no die shrinks at the top end of GPUs when they finally transition to 16nm. If anything, Moore's law is behind schedule in the GPU space. Note, that both NVidia and AMD rely on TSMC to manufacture their chips, so they're completely constrained by TSMC's ability to implement new process nodes.

2011: GTX 580, 1.5 TFLOPS 2012: GTX 680, 3.0 TFLOPS (~2.0 attainable) 2013: GTX Titan, 4.4 TFLOPS (~3.2 attainable) 2014: GTX 980, 4.6 TFLOPS 2015: GTX Titan X, 6.7 TFLOPS Looks to me like they're doubling perf roughly every 2 years. Meanwhle, my Core i7-5930k's SOL is <1/2 of 2011's GTX 580 at 672 GFLOPS and it still doesn't have fast approximate transcendentals. Skylake begins to fix this, but c'mon, GPUs have had…

Moore's law isn't about performance, it's the number of transistors on a single IC. Perf is related but irrelevant to the discussion.

Re: Nvidia Pascal GPU to Feature 17B Transistors and 32GB HBM2 VRAM

#39

Post by bduerst »

x3sphere wrote: post #28
bryanlarsen wrote: post #17

Earlier quoted context omitted.

It could be argued that AMD does have it together. If you look at the benchmarks for pretty much any particular price point, AMD & nVidia cards are roughly comparable. AMD is better at some games and resolutions, and nVidia is better at others. Rarely is the difference more than 10%. nVidia used to have a sizable power/noise advantage, but Fury appears to close that gap. AMD even seems to be closing the driver stabil…

As someone who has bought AMD cards for the past 5 years for gaming, I switched over to Nvidia this time. You've overlooked that Maxwell / 980 Ti has a ton of overclocking headroom. OC to OC, you're looking at 20-30% performance difference at more commonly used resolutions like 1440p and 1080p. The gap narrows only at 4K. Voltage is locked on Fury right now and AMD isn't saying why. The best OC I've seen on one is 10…

OOB they tend not to be that different, hardware wise.

I didn't care either way until NVidia pulled the hairworks stunt, which was a pretty controversial move.

Re: Nvidia Pascal GPU to Feature 17B Transistors and 32GB HBM2 VRAM

#40

Post by cfallin »

bryanlarsen wrote: post #25
raverbashing wrote: post #20

Earlier quoted context omitted.

Not sure about their graphics division, but AMD has stopped innovating in the CPU department...

So has Intel. Skylake (2016) and Sandy Bridge (2010) have roughly comparable single core desktop benchmarks. Power/performance ratios have increased drastically, but that's mostly because of process improvements. AMD has been stuck on 28nm for a long time, but that's not AMD's fault.

> Skylake (2016) and Sandy Bridge (2010) have roughly comparable single core desktop benchmarks.

That's not quite true -- Intel aims for a big IPC (instructions/clock) improvement for each "tock" generation (Nehalem -> Sandy Bridge -> Haswell -> Skylake), and IIRC has pretty much delivered. Some benchmarks are really hard to push because they're memory/cache-miss bound (so it's really just about throwing in more memory channels and clocking them up), but a lot of things have gotten seriously better for tricky integer code, especially in e.g. branch prediction/uop cache in the frontend and available execution ports in the backend.

Post reply on HN