Cookies op Tweakers

Tweakers maakt gebruik van cookies, onder andere om de website te analyseren, het gebruiksgemak te vergroten en advertenties te tonen. Door gebruik te maken van deze website, of door op 'Ga verder' te klikken, geef je toestemming voor het gebruik van cookies. Wil je meer informatie over cookies en hoe ze worden gebruikt, bekijk dan ons cookiebeleid.

Meer informatie

Samsung begint productie 8GB-hbm2 met verhoogde datarate van 2,4Gbit/s

Samsung is begonnen met de productie van een nieuwe generatie 8GB-dram-modules met hbm2-interface, genaamd Aquabolt. Het geheugen haalt een datarate van 2,4Gbit/s, terwijl de vorige generatie niet verder kwam dan 1,6Gbit/s.

Volgens Samsung haalt Aquabolt een totale bandbreedte van 307GB/s. Dat zou 9,6 keer zo snel zijn als de bandbreedte die kan worden gehaald met een 8Gbit-gddr5-chip, die niet verder dan 32GB/s zou komen. In vergelijking met de 8GB-hbm2-modules van de vorige generatie levert Aquabolt door de datarate van 2,4Gbit/s een prestatieverbetering tot vijftig procent op.

Om de verhoogde doorvoersnelheid te halen, heeft Samsung het ontwerp van de toegepaste through silicon via-technologie verbeterd. Elk van de acht gestapelde hbm2-dies is voorzien van ruim vijfduizend tsv-kanalen en dit hoge aantal kan volgens Samsung leiden tot verminderde prestaties door clock skew. Samsung zegt dit effect te hebben geminimaliseerd. Bij de tsv-technologie lopen de interconnects als tunnels door de verschillende plakjes silicium van de gestapelde chips, wat snelheidswinst met zich meebrengt.

Daarnaast zegt de fabrikant de temperatuurcontrole te hebben verbeterd door het verhogen van het aantal thermal bumps tussen de hbm2-dies. Daar komt bij dat Samsung een nieuwe beschermlaag heeft aangebracht waardoor de algehele stevigheid van de 8GB-packages is verbeterd.

De 8GB-hbm2-modules van Samsung bestaan uit acht gestapelde hbm2-dies met ieder een capaciteit van 8Gb en aan de onderkant van de stack zit een buffer-die. Iedere laag is voorzien van ruim vijfduizend tsv-kanalen, waarmee het totale aantal op meer dan veertigduizend komt voor een 8GB-package.

Onder andere Nvidia en AMD gebruiken hbm2 in high-end videokaarten. Nvidia gebruikte hbm2 in 2016 voor het eerst op zijn Tesla P100-kaarten en past het ook toe op de in mei 2017 geïntroduceerde Tesla V100, maar in beide gevallen gaat het om modules van 4GB. AMD gebruikte de eerste generatie hbm-geheugen op zijn Fury-kaarten en past hbm2 toe op zijn Radeon Vega Edition.

Samsung zegt dat het Aquabolt op een stabiele snelheid zal leveren aan zijn klanten, waarmee de fabrikant inspeelt op de groeiende vraag naar hbm2-dram met hoge prestaties. Vorig jaar maakte het bedrijf bekend de productie van 8GB-hbm2-modules van de vorige generatie op te schroeven.

 

 

Door

Nieuwsredacteur

41 Linkedin Google+

Reacties (41)

Wijzig sortering
Als je bestaande chips met het nieuwe geheugen zou uitrusten:
  • Nvidia Tesla V100: 900 GB/s --> 1228 GB/s (+36%)
  • Nvidia Titan V: 652 GB/s --> 921 GB/s (+41%)
  • AMD RX Vega 64: 484 GB/s --> 614 GB/s (+27%)
  • RX Vega M GH*: 204 GB/s --> 307 GB/s (+50%)
  • RX Vega M GL*: 179 GB/s --> 307 GB/s (+71%)
*Geïntegreerde AMD GPU in Intel's Kaby Lake-G processoren

Ter vergelijking, een Titan Xp heeft 548 GB/s aan geheugenbandbreedte met GDDR5X.

[Reactie gewijzigd door Balance op 11 januari 2018 11:21]

De vraag is voor welke toepassing heeft sneller geheugen ook daadwerkelijk zin.

Als het voor computing is waarbij data-to-compute aangeleverd/afgevoerd worden via geheugen, is dat anders dan pre-loaden van 3D images voor games...

HBM geheugen werd voornamelijk voor supercomputers gebruikt. Nu dat supercomputers steeds meer GPU's gebruiken is dit een logisch vervolg.

Echter is het slecht nieuws voor consumenten, immers grafische kaarten zijn nu al slechts verkrijgbaar ivm mining van crypto currency en straks zal er vast wel iemand zijn die consumenten kaarten gaat gebruiken om voordelig een supercomputer te bouwen....

[Reactie gewijzigd door totaalgeenhard op 11 januari 2018 11:32]

Games, gezien hoe Vega schaalt met een geheugen overclock bij gelijke core clock is de architectuur duidelijk bandwidth limited. Een snellere geheugen bus zal dus tot een zeker (nog onbekend niveau) helpen de prestaties op te krikken..
Games, gezien hoe Vega schaalt met een geheugen overclock bij gelijke core clock is de architectuur duidelijk bandwidth limited.
Nee, bandwith limited is het niet. De timings van de geheugen blijft staan,de mhz gaat hoger dus de geheugen is sneller in dingen verwerken. Want die bandbreedte van de HBM krijg jij niet volgeladen met de textures van je games. Je zit te snelheid van je geheugen te clocken.

HBM heb je dan ook echt niet nodig voor games.

[Reactie gewijzigd door Jeroentjeeuh op 11 januari 2018 14:40]

Vega wordt sneller als je de timings gelijk houdt en de memory clock opvoert. Met andere woorden, als je de bandwidth verhoogd. Duidelijk gevalletje van bandwidth limited en precies datgene wat in deze nieuwe chips verbeterd.

HBM is in het algemeen niet noodzakelijk voor gaming, maar voor Vega wel, die is gebouwd met HBM in gedachte en gebruikt onder gaming load duidelijk de bandwidth die het tot beschikking heeft.

Uiteraard kan je die bandwidth ook bereiken met een bredere bus en hoog geklokt GDDR5x, maar daar werkt Vega niet mee.
Ah, ik zie dat je de comment hebt aangepast.
Vega wordt sneller als je de timings gelijk houdt en de memory clock opvoert. Met andere woorden, als je de bandwidth verhoogd. Duidelijk gevalletje van bandwidth limited en precies datgene wat in deze nieuwe chips verbeterd.
Nee, timings is het ding. Die regelt de snelheid van dat bandbreedte. Hoe hoger de bandbreedte en hoe lager de timings des ter sneller de geheugen is. En zo werkt geheugens.

Voorbeeld: Ook al heb je 3000mhz ram op c16 en je zet het op c18 dan is het slomer. Maar hoe kan dat dan ? De bandbreedte van 3000mhz is der toch ? maar zo werkt het niet.

Maar wat nou als ik het op 3000mhz c14 zet ? Dan krijg ik een boost maar ik zit niet aan de bandbreedte want die 3000mhz is der nog steeds. Precies, je zit aan de snelheid te clocken van de ram en daarom krijg jij meer fps.

Is het zelfde als timings laten staan en hoger in MHZ gaan.

[Reactie gewijzigd door Jeroentjeeuh op 11 januari 2018 14:43]

Memory clock bepaald de bandwidth
http://www.hardwaresecrets.com/everything-you-need-to-know-about-the-dual-triple-and-quad-channel-memory-architectures/

Timings bepalen hoe snel het geheugen is om een gegeven instructie uit te voeren.
http://www.hardwaresecrets.com/understanding-ram-timings/

Ik weet dat deze artikels over RAM gaan, maar appels met appels vergelijken moet kunnen
Hij heeft aan de ene kant wel gelijk.

Je verhoogd de bandbreedte maar de timings blijven staan. Dus die ram krijg meer boost omdat het sneller zijn werk kan doen omdat de bandbreedte verhoogd is.

Maar aan de andere kant hadden we het over HBM. HBM heeft zoveel bandbreede die we eigenlijk niet nodig hebben maar het clocken ervan werkt precies het zelfde. Maar dat is bij elke ram zo. Maar de bandbreedte wat de geheugen bij zich heeft is niet altijd nodig. Zowel hoge ddr4 ram als HBM.

[Reactie gewijzigd door Jeroentjeeuh op 11 januari 2018 15:14]

De vraag was voor welke toepassing sneller HBM zin had. Een toepassing waar het zin heeft is een VEGA kaart, want deze is ontworpen voor HBM en kan in zekere mate gebruik maken van sneller HBM geheugen.

En er is geen sprake van schuld, tenzij je natuurlijk vindt dat AMD de fout is gegaan dat ze een GPU core hebben ontworpen die sneller kan werken dan dat het huidige geheugen de data aan kon leveren.

Ik vindt dat op zich slim, ze kunnen dus zonder aanpassingen in de GPU core VEGA combineren met dit geheugen en krijgen daar een snelheidswinst uit. Ik ben benieuwd of we dat gaan zien bij de VEGA refresh.
Toepassing is verschillind. En ja, HBM heeft zeker wel nut bij het ene dan het ander. Maar we hadden het over gaming en daar is HBM nogal een dikke overkill.

[Reactie gewijzigd door Jeroentjeeuh op 11 januari 2018 14:33]

Ofwel VEGA is gewoon een slecht ontwerp. Je gebruikt HBM2 maar weet er vervolgens niets mee te bereiken.

Overigens, als je memory op een Nvidia kaart hoger clockt wordt ie ook sneller. Is dat dan ook meteen bandwidth limited?
In zekere mate natuurlijk ook, maar een Vega kaart schaalt beter met memory overclocking dan met core overclocking.

En Vega is geen slecht ontwerp, noch is het een slechte gaming kaart. Voor 4k gaming moet je nog steeds bij het groene kamp zijn, maar het gros speelt op 1440p of zelfs nog 1080p dan is een Vega 64 of 56 ruim voldoende en is een Freesync monitor een stuk goedkoper dan een G-sync monitor. En voor compute is het een geweldige kaart (en daar zit meer volume en marge dan extreme high end gaming). AMD heeft gewoon de keuze gemaakt zich op dat laatste te focussen en heeft daarmee meteen een kaart waar het leeuwendeel van de gamers prima mee uit de voeten kan.

Gamers die 1080Ti nodig hebben zijn echt maar druppel op een gloeiende plaat en verder nauurlijk de vele review sites en youtubers die het sprookje hoog houden dat je niet kan mee doen als je niet minstens 1080Ti verslaat.

Ik speel zelf op 1440p en werk met compute, ik pijns er niet over om een Titan te kopen als een Vega 64 voor gaming prima voldoet en voor compute beter...
Wat is dan volgens jou hét ding wat nu de bottleneck is?
Ja dat snap ik, maar welk onderdeel van de videokaart is dan de bottleneck?
De core ! Nee, een beetje flauw.

Geheugen is altijd een bottleneck zowel voor de ramgeheugen als het gpugeheugen. Het is alleen: Waar ga je het voor gebruiken. Hoge mhz met zeer lage timings, dikke boost bump. Tuurlijk is ook logisch.(Snelheid) Maar die bandbreedte, heb je die nou echt nodig.(om dingen in te laden) Gaming ? Nee.. Vega had ook gewoon met GDDR5x uitgebracht kunnen worden en liet de zelfde performance zien. Want de bandbreedte is groot zat voor gaming.(Gddr5x)

[Reactie gewijzigd door Jeroentjeeuh op 11 januari 2018 15:23]

Nou ik denk het niet.
Bandbreedte is belangrijk latency is meer random acces isue.
GPU hardware software aanpak is van massive parrallel functional execution.
Juist niet random.
Latency is geen probleem als data goed alined is. En de prefetcher goed execution unit gevoed houd door goed gebruik van de data of goede aanvoer van code data stream.
Als kernel local in de registers van compute units past. En samen met de data niet al te groot zodat samen local binnen compute unit afgehandeld kan worden heb je top performance. Dan heb je de CU blok met zijn groeps buffer als die goed gevuld wordt blijven de cores bussy.
Video is traag dus de manier van exevutie is burst van data naar buffer nog voordat het nodig is. Daarmee maskeer je latency.
Bij GPU is het de aantal en reken kracht van mini cores de vele duizenden.
Games zijn texturebound daarmee is de texel throughput belangrijk.
Dus daarbij is bandbreedte en aantal TMU en ROP belangrijk om goed gebruik te kunnen maken van de bandbreedte.

CPU pakken het anders aan omdat er niet data oriented geoptimaliseerd wordt iig niet met die high level languages met hun garbage collector. Waar je sneller een solutie kan opleveren.
Daar heb je vaker te maken met excesive gebruik van branches virtual tables wat memory hoppen door class hiarchie is. Daar geld vette branch predictor en out of order execution en SMT om wachten op memory request ergen random in de heap.

Bij simple in order cores is random acces helemaal desatreus dus de CELL cpu kakt performance nog harderer in en bij gpu ook.

HBM tech reduceerd juist de inter chip memory controler to memory verbruik per lane.
Reduceerd de Gkaart PCB complexiteit en de routing.

Bij gpu voor games is pixel texel troughput belangrijk. En texel is dus texture.
In api bind je ergens in de shader pipeline met texture resource.
Met ook optie als texture als target ipv backbuffer.
RX Vega 64... Die chips zijn ontzettend memory bandwith limited.
ik vind het best goed dat ze met dit type geheugen hardwarematige updates mee komen.
het is goed voor amd aangezien zij zijn die dit type geheugen weer sneller word, ik ben benieuwd
wat de algehele snelheid word van zo een amd videokaart, en hoeveel snelheidswinst ze daar mee kunnen bereiken.
En als aanvulling is de Power Consumptie ook nog eens met 20% verlaagd op 1,3 Volt tegenover GDDR5 dit is ook aardig meegenomen en snap niet echt waarom dit niet vermeld word :X .

[Reactie gewijzigd door wow7 op 11 januari 2018 16:29]

De 8GB-hbm2-modules van Samsung bestaan uit acht gestapelde hbm2-dies met ieder een capaciteit van 8GB en aan de onderkant van de stack zit een buffer-die.
8x8 = 64GB. Moet 8x1 zijn.

Wel mooi dat HBM ontwikkeling toch wel snel gaat, on die HBM heeft echt wel voordelen vs gddr5(x), zeker als je kijkt naar de recente apu's.
Of zoals in het bronartikel staat:
A single 8GB HBM2 package consists of eight 8Gb HBM2 dies ...
8GB is iets anders dan 8Gb gigabytes versus Gigabits! Gb delen door 8 heb je GB. Dus 8Gb - 1GB.
We bedoelen het zelfde, mijn reactie was gericht op het "8x8 = 64GB. Moet 8x1 zijn", blijkbaar stond het in de originele text verkeerd. Zowel @MarvTheMartian als ik reageren op de originele text.

Al ben ik wel benieuwd of dit over GB (1000 MB) of over GiB (1024MiB) gaat, bij HDDs en SSDs is het eigenlijk altijd GB/TB maar voor een HBM of DDR low level lijkt me GiB logischer... :?
RAM valt onder de JEDEC standaarden, en die gebruiken de IEC normen en dus 1024.
Het gebruik van SI prefixen (k=1000) in combinatie met niet-SI eenheden (bit/byte) is simpelweg inconsistent.

De SI eenheid van informatie is formeel gesproken de Joule, maar dat is ridicuul groot. Zelfs een picoJoule is veel meer dat een Terabit. Dat komt omdat in de natuurkunde informatie een vorm van entropie is, en entropie heeft dezelfde eenheid als energie.
Tegenwoordig GB dus de 1000 variant niet meer de 1024 variant. Die hebben ze min of meer al met pensioen gestuurd.
We hebben het over geheugen reken er maar op dat het om 1024 gaat. En dat één zo'n stack 8.192MB aan geheugen levert, of 8.388.608kB geheugen, etc...
Dat is precies wat ik zei toch? 8GB x 8GB = 64GB....
Ik schrijf het alijd uit om dit soort verwarring te voorkomen. 1 laag is 8 gigabit x 8 is 8 gigabyte.
Wel mooi dat HBM ontwikkeling toch wel snel gaat, on die HBM heeft echt wel voordelen vs gddr5(x), zeker als je kijkt naar de recente apu's.
Het is alleen zo jammer dat HBM nooit on-die zit. Het zit weliswaar on-package maar is nogsteeds een eigen die.
Komt nog wel, geef het nog 4 jaar en we doen niet anders ;) Het is alleen dat HBM nog nieuw is, en nog bepaald niet stabiel (zie de productieproblemen met HBM2 die vooral AMD een vertraging van bijna een jaar gegeven hebben). Als het eenmaal door meer producenten betrouwbaar gemaakt kan worden gaan we al heel snel combis zien.

Let wel op dat het stroomverbruik dan nog geconcentreerder gaat worden, dus voor high end GPUs is losse modules nog veel beter. Je moet tenslotte wel 300 W af kunnen voeren... (geheugen wordt ook lekker warm).
Niet on die, maar on package met infinity fabric is nog steeds sneller / lagere latency. Weet ook niet of het mogelijk is om het on die te krijgen zonder dat je alle chips echt specifiek zo ontwerpt ( en dus ook weg gaat van andere geheugen type's ). Verwacht ik eerlijk gezegd niet, HBM designs zullen daarom niet on die worden, niet met chips die ook met ander geheugen overweg moeten kunnen ( meeste cpu's / gpu's ). Alleen voor specifieke ontwerpen ( high end ) zou on die geheugen ( met bijbehorende nog lagere latency ) echt zinvol zijn lijkt mij.
Nee, 1 module bestaat uit 8 dies van 8Gb, met een kleine letter B dus. Klassieke bit/byte verwarring
Artikel is aangepast, ik vergiste mij niet was auteur die termen door elkaar gebruikte ;)
En dit "Samsung begint productie 8GB-hmb2 met verhoogde datarate van 2,4Gbit/s" moet HBM zijn :+
Vega 12nm met nieuwe HBM2?
Volgens de recente aankondiging van AMD zal de Vega refresh op basis van 7nm zijn.
Dat is niet de Vega voor consumenten desktops..
Vega 12nm is in het verhaal van AMD niet meer voorgekomen, dus er is een kans dat deze is geschrapt.


Om te kunnen reageren moet je ingelogd zijn


Apple iPhone X Google Pixel 2 XL LG W7 Samsung Galaxy S9 Google Pixel 2 Far Cry 5 Microsoft Xbox One X Apple iPhone 8

© 1998 - 2018 de Persgroep Online Services B.V. Tweakers vormt samen met o.a. Autotrack en Hardware.Info de Persgroep Online Services B.V. Hosting door True

*