AMD toont Radeon Pro-kaart met aansluitingen voor twee m2-ssd's

AMD heeft op de Siggraph-beurs een videokaart uit de Radeon Pro-lijn getoond met twee aansluitingen voor m2-ssd's. Daarmee moet het mogelijk zijn om de kaart te voorzien van aanvullend geheugen, oplopend tot enkele terabytes.

AMD meldde dat de technologie, die zich nu nog in een bètafase bevindt, bekendstaat onder de naam 'solid state graphics technology', oftewel ssg. Deze maakt het mogelijk om via een m2-aansluiting een nand-ssd op de videokaart aan te sluiten, zo schrijven Anandtech en PCWorld naar aanleiding van het AMD-event op de beurs. Anandtech schrijft dat het nog onduidelijk is of de kaart direct aan de ssd is aangesloten en dat ook aanvullende details nog ontbreken.

Op het event zei David Watters, hoofd van industry alliances bij AMD, dat deze techniek voordelen kan opleveren bij het verwerken van videobestanden. Zo toonde het bedrijf in een demonstratie dat de kaart een 8k-videobestand met een resolutie van 7680x4320 pixels met 90fps kon afspelen, terwijl een 'gewone' kaart het bestand kon weergeven met 17fps, aldus PCWorld.

Kaarten maken op dit moment incidenteel gebruik van het werkgeheugen van een systeem, waardoor onder andere vertraging ontstaat en de cpu verzoeken moet verwerken. Met de ssg-techniek zou de cpu volledig omzeild worden, wat voor snelheidswinst moet zorgen. AMD wil dit jaar devkits voor de kaart beschikbaar maken op aanvraag. In 2017 zou de beschikbaarheid vervolgens moeten toenemen. De prijs van een devkit zou op dit moment ongeveer 10.000 euro zijn.

Raja Koduri van AMD toont een ssg-kaart met 1TB geheugen, afbeelding via PCWorld

Reacties (72)

[dmantione]

Ik vind het een vreemde ontwikkeling: Een SSD is nuttig als informatie langer bewaard moet blijven, anders kun je namelijk beter een langzame vorm van RAM nemen. En ik zie niet in waarom informatie in een videokaart lang bewaard moet blijven.

[Trygve]

Hierom:

Hugely complex and highly detailed CAD models that took the better part of an hour to load up and decompress will still take the better part of an hour to load up and decompress on an SSG GPU based system. Why bother? Because it takes the better part of an hour to load and decompress the first time, then it can stay resident on the GPU’s flash storage. The second time it should take seconds. If you look at the cost of a modern automotive or aerospace engineer’s time, SSG is a no-brainer, any CTO would be foolish not to deploy this tech ASAP, the ROI would be measured in weeks.

Bron: http://semiaccurate.com/2...sive-ssds-gpus-calls-ssg/

[Reactie gewijzigd door Trygve op 23 juli 2024 03:19]

[teacup]

then it can stay resident on the GPU’s flash storage

Allemaal heel leuk voor lokale CAD modellen in een native CAD omgeving.

Waar ik benieuwd naar ben is of deze cache ook geïntegreerd kan worden in het bewustzijn van een productdatamanagement tool die alle CAD files centraal op een serveromgeving plaatst. In de huidige situatie hebben PDM/PLM database-systemen wel cache mechanismes op de massa opslag van de lokale cliënt (vooralsnog werkstation). Bij mijn weten zal PLM software eerst geleerd moeten worden om deze cache te adresseren. Blijft de massaopslag daar als cache ook nog tussen aanwezig dan hebben we dus een extra indirectheidslaag.

Een andere vraag die ik heb hoe dit concept gaat werken in een graphic farm (server met batterij grafische kaarten) waar VDI cliënts naar kijken. Heeft dan iedere graka een prive SSD, of kijkt het hele spul naar een gemeenschappelijke SSD vijver die ik weet niet hoe toegankelijk zal zijn. Ook bij een VDI benadering blijft de vraag hoe deze cache geïntegreerd raakt in de database cache van de PDM/PLM databases.

Begrijp me niet verkeerd, ik vind dit een hele interessante ontwikkeling, maar ben heel geïnteresseerd om te weten of grote CAD en PLM producenten op deze ontwikkeling zijn aangesloten.

[Clemens123]

voor grote numerieke simulaties kan dit misschien helpen...ik vermoed vooral dat ze er nu aan werken omdat ze hopen das misschien Intel Optane hiervoor heel geschikt zou kunnen zijn (zou wel eens een samewerking tussen Intel en AMD kunnen betekenen)

[Mathieu_Hinder]

Los van gaming toepassingen is dat zeker handig om data permanent op de gpu te kunnen zetten. Ben zelf op dit moment bezig met een machine learning toepassing waar gpu's een grote snelheidswinst kunnen vormen, en daar moet je regelmatig data opsplitsen om binnen de limieten te blijven. Dat zijn dan zaken waar er een paar uur / dagen op gereken wordt, dus die moet geen frame binnen een paar milliseconden afvoeren.

[WoBBeL]

Zorgt dit niet voor inmens veel write cycles op je SSD, met een korte levensduur tot gevolg?

[Anoniem: 705078]

Hier is een test uit 2013 van een Samsung SSD 840 250GB TLC SSD die een paar maanden continu is beschreven.

SSD geheel dood 7 juni
Cycles 3706
Data beschreven 888 TiB
10GB/ dag 249 jaar
WAF3 87 jaar
30GB / dag + WAF 3 29 jaar

888TiB = 976,366TB

Vraag me niet wat WAF3 is

WAF : http://searchsolidstatest...-amplification-factor-WAF

Bron test: https://nl.hardware.info/...9-eindconclusie-20-6-2013

[Reactie gewijzigd door Anoniem: 705078 op 23 juli 2024 03:19]

[Vulcanic]

Overduidelijk een verbeterde versie van de Wife Acceptance Factor.

[jqv]

2013... De techniek is al wat verder ontwikkeld dan deze SSD.
Maar het is wel een indicatie. De duur van gebruik zal wel wat zijn toegenomen.

[BruT@LysT]

De SSD in het voorbeeld laat al zien dat deze niet kapot te krijgen is ! (kort door de bocht maar je snapt me) Dus wat betreft hedendaagse SSD's is het gelijk al dan niet beter geworden. Conclusie is dus dat een SSD belachelijk lang meegaat!, vele malen langer dan de gemiddelde HDD.

Pas kapot na 976366 Terabyte aan data schrijven, how insane

[Reactie gewijzigd door BruT@LysT op 23 juli 2024 03:19]

[Dark_man]

Ja geheel kapot na zoveel writes.

Maar warschijnlijk zijn er lang daarvoor al errors begonnen en onvoorspelbaar gedrag van de SSD.

Overigens denk ik niet dat de videokaart zoveel data zal sturen dat de SSD zal slijten.

Het is waarschijnlijk voornamelijk lezen, er wordt hoogstens wat save data gestuurd naar de SSD.

[swampy]

Ja en Nee

Je ziet meer en meer het gebruik van TLC inplaats van MLC. Want ja goedkoper en meer opslag. Intel heeft bijvoorbeeld zijn eigen lijn van TLC SSD's.

8 voltages in plaats van 4 in een cel betekent dat hij minder lang meegaat. BIj een factor van 10 vergeleken met 2bits per cel.

Dus ja de goedkoopste SSD's worden weer slechter. Maar met een moderne controller valt de schade wel me. En waar vind je nog SLC? Zelf enterprise drives hebben MLC geheugen deze dagen.

[Anoniem: 87301]

jouw berekening klopt niet!
888TiB = 976.366 GB niet TB!
Dus ongeveer 976 TB

[Anoniem: 705078]

Klopt, aangepast. (Komma i.p.v. punt gebruikt) Te veel met Engels bezig

[ManIkWeet]

Zeker, maar ik denk dat de doelgroep daar totaal niet mee zit.

Daarbij is het ook mogelijk dat de m2 kaarten helemaal geen SSDs zijn, m2 is een formfactor, je kan er alles in doen!

[Iblies]

Ik lees dat er twee aansluitingen zijn,
ik ga er van uit dat je de data hierdoor redundant kunt opslaan.

Stopt een ssd er mee, dan heb je nog de ander.


Gezien de prijs lijkt zal de doelgroep wel iets kritischer waarbij de mogelijkheid om een zo lang mogelijke up-time te garanderen wel belangrijk is.

[pietje63]

Er worden volgens mij verschillende soorten gebruik voorzien. Bij het afspelen van een 8K video bestand dat op de SSD staat met bypass van CPU en de rest van het mobo voorzie ik niet zoveel writes. Dit gebruik is mogelijk nuttig bij 8K films die vooraf helemaal klaargezet kunnen worden (bioscoop, concerten, ??)

Bij gebruik als cache (die lijkt vooral voor de hand te liggen bij ander gebruik dan voor beeld rendering, bijvoorbeeld machine learning) dan loop je hier wel tegenaan.

[watercoolertje]

Op de oude manier natuurlijk ook, want dan wil je je video ook van een SSD laden ivm de bandbreedte die nodig is. Enig is dat het dan allemaal langzamer gaat en je dus minder writes hebt. Maar uiteindelijk kan je dus net zo veel bestanden bewerken voordat ie stuk gaat. Met het verschil dat het hier tig keer sneller kan...

Het is een beetje het 4G vs 3G verhaal waar je meer kan doen in minder tijd waardoor je meer MB's verbruikt

[spokje]

Is dit geheugen niet veel te traag? GDDR5 haalt toch veel hogere snelheden dan SSD's? (ook al is het M2?)

[VNA9216]

Het is denk ik meer als een soort buffer bedoeld.

Je zou het in theorie ook kunnen gebruiken om onder het gamen een cache aan te leggen van "uncompressed" textures enzo. Dan kan je die bij een reboot gewoon laten staan, en kunnen ze gewoon in het VRAM geladen worden als je weer aan het gamen bent (je zal waarschijnlijk wel de games nog moeten optimaliseren dr voor). Zo kan je je CPU nog een beetje ontlasten en je laadsnelheden verder verbeteren als je "data" SSD/HDD alleen de rest van de data nog maar hoeft te laden aangezien hedendaagse hoge resolutie textures vaak het grootste deel van de totale disk GB's van een game is.
Als je dan het inladen, decompressen en optimaliseren voor de specifieke GPU er uit kan halen en ze geoptimaliseerd direct in het vram kan gooien op de kaart zonder de CPU en PCI-E bus te belasten zou dat nog wel eens de moeite waard kunnen zijn.

Ik denk dat het een interessant experiment zou kunnen worden. Nu zal het het nog niet waard zijn voor de gemiddelde consument, maar in de toekomst als die opslag sneller en goedkoper word kan dat in ene omslaan.

[SkyStreaker]

Dat zijn dan enkel de voordelen die je benoemt. Het probleem is dat variatie onder kaarten dan nog groter wordt. Wat weeg je af in de game die je maakt? Het merendeel die nog een traditioneel GPU heeft of eentje die uitbreidbaar is met cache. De laatste is heel erg nieuw, zal ook lekker veel kunnen gaan kosten omdat je natuurlijk specifieke optimalisaties gaat krijgen (PR gedoe, voornamelijk). Ga je de ene klant benadelen door de andere voor te trekken.

Ik weet het niet hoor...

[maratropa]

Is niet anders dan nu lijkt me. Je hebt nu ook mensen met minder vram die ingame de settings wat omlaag moeten schroeven, bijv. Geen ssd cache, dan gewoon settingkje lager.

[VNA9216]

Je kan het voor een groot deel natuurlijk in de driver afhandelen en eventuele in-engine optimalisaties optioneel maken.
De meest belangrijke wijziging die doorgevoerd zal moeten worden is een wijziging in de graphics API's zodat je aan de hand van een uniek ID kan checken of een texture al op de 3dkaart aanwezig is voordat je hem van je disk gaat laden, immers heeft het weinig nut om hem eerst van de disk te laden, te decompressen, te optimaliseren voor de 3dkaart, naar de 3dkaart te sturen en daar dan te laten checken of hij ook al in het flashgeheugen staat

Zoiets implementeren in een game engine zal niet zo'n probleem zijn, en voor een traditionele kaart kan je gewoon de standaard laadcode gebruiken. Dat stukje extra code zal niet zo'n drama zijn om toe te voegen.

[Reactie gewijzigd door VNA9216 op 23 juli 2024 03:19]

[DoubleYouPee]

Dat is echt geen gaming GPU

[perseus93]

Yes, ik merkte bijvoorbeeld bij het trainen van neurale netwerken op grote datasets dat de snelheid helemaal weg viel omdat het geheugen vol zat; alleen al een factor 2 versnelling zou een verschil maken van weken!

Los daarvan vraag ik me af, zou dit niet al op driver level geïmplementeerd kunnen worden? Misschien niet dat je het maximale er uit kan halen.. (Zo veel weet ik hier nu ook weer niet van af )

[jvaneijk]

Omdat de meeste videokaarten op een PCIe x16 of x8 worden aangesloten denk ik dat het misschien nog wel eens kan zijn dat het nog steller is dan de gewone m2 sloten welke op x4 draaien. Er zou op dat moment meer bandbreedte moeten zijn waardoor je volgens mij ook gewoon nog snellere SSD's kan gebruiken. Nu lopen we volgens mij gewoon tegen de bandbreedte van het slot aan.

[jqv]

Als deze rechtstreeks dor de kaart aangesproken heb je niets te maken met de PCIe.
Dan wordt de data rechtstreeks aangesproken en niet via een of andere bus.

Natuurlijk zal data vanaf de computer ernaartoe verzonden moeten worden (net als nu) maar als ze het goed implementeren, heb je daarna de harddisk van de pc niet meer nodig totdat je het aangemaakte model/bestand wilt opslaan/verzenden. Je haalt daarmee en potentieel vertragende factor weg.

[MSalters]

Het gaat wel degelijk via PCI-e, maar je veronderstelt ten onrechte dat PCI-e een bus is. De verwarring komt vermoedelijk van de voorganger PCI (zonder e), wat wel degelijk een bus was. PCI-e is een point-to-point interface met lanes tussen devices.

In dit geval komen er PCI-e lanes tussen GPU en SSD. Die lanes staan los van de PCI-e lanes tussen GPU en CPU. De belangrijke winst is dus dat het aanspreken van de SSD niet meer ten koste gaat van de CPU-CPU bandbreedte,

[360Degreez]

Twee aansluitingen. Als de kaart een Raid0 ondersteuning biedt zou je uitgaande van een vlotte M.2 SSD 4400 MB/s read en 1800 MB/s write kunnen halen.

Niet verkeerd als aanvullend geheugen :-)

[Spekkie88]

Even een snelle quote van wikipedia

Computer bus interfaces provided through the M.2 connector are PCI Express 3.0 (up to four lanes), Serial ATA 3.0, and USB 3.0 (a single logical port for each of the latter two)

Dus als je aan de M.2 standaard wil voldoen zit je wel degelijk vast aan een bepaalde bus, anders zou je op de kaart geen M.2 SSD's kunnen gebruiken en is het dus onzin om uberhaubt een M.2 slot te gebruiken en daarnaast zit je dan dus ook nog eens vast aan maximaal 4 pci-e lanes terwijl de gpu toegang heeft tot 16 lanes. Dat is ook waar jvaneijk op doelt.

Het enige is dat je met M.2 hoe dan ook een "bottleneck" hebt van "slechts" 4 pci-e lanes of het nu direct op de gpu zit of op je moederbord.

Het grote verschil is dat als het direct aan de gpu gekoppeld wordt je veel minder overhead hebt van cpu en eventueel chipset (als bijvoorbeeld de pci-e lalnes voor het M.2 slot op het moederbord niet direct door de cpu geleverd worden) waardoor de data sneller beschikbaar is voor de gpu.

[Toettoetdaan]

Het gaat ook om de reactie tijd, nu de SSD direct (via PCI-e) is verbonden met de GPU, hoeft het niet meer door het moederbord/(pci-bridge/mutliplexer)/cpu heen, hierdoor is er een merkbaar voordeel tegenover het normaal aansluiten op het moederbord.

[maratropa]

Volg HW.info zit er gewoon een PEX8747 op die elke ssd 4 lanes geeft en de gpu waarschijnlijk dus 8. Dus er zit wel een plx chippie tussen.

Wat ik me dan wel afvraag is wat het verschil is met dezelfde ssd's in een ander pci-e slot? Oh wacht als je dat doet loopt het via de cpu..

[Reactie gewijzigd door maratropa op 23 juli 2024 03:19]

[Nibelnoya2]

Je moet het zien als level3 cache op je processor.

Op dit moment lijkt het vooral te wijzen naar de professionele toepassingen, CAD etc, oftewel voor de Firepro-reeks. Bij GPU rendering voor videobewerking zou het ook interessant kunnen zijn.

Ik zie ook op consumer-niveau een toepassing, de textures daar opslaan zou toch ook een leuke boost kunnen geven bij games, maar dat zal nog wel een paar jaar duren vrees ik.

[HollowGamer]

Dat is jammer in mijn ogen, want als het even snel (of sneller) zou zijn geweest zou je de geheugen limieten eindelijk kunnen oplossen. Een GPU heeft bijvoorbeeld 2GB geheugen, maar bij spellen die meer vereisen of beter presteren/mooier uitzien, zou 'even' 2GB of meer bijprikken een mooie oplossing zijn, i.p.v. een nieuwe GPU aanschaffen.

Had ook echt de hoop toen ik de titel zag staan, .. maar inderdaad heb je gelijk dat het veel te traag is.

[kuurtjes]

Wordt het een open standaard?

[prutser001]

AMD kennende zal het wel weer open worden, wat is het laatste wat ze gedaan hebben en 'open' was?

[Anoniem: 696390]

Mantle liquidvr

[satanas666]

hbm in samenwerking weliswaar maar toch

[d3x]

het is onderdeel van de HSA, AMD brengt nog meer van die dingen in 2017 en later.

[Crp]

http://gpuopen.com

[Laloeka]

M2 is geen AMD specificatie. Zoals ik het begrijp kun je hier non-AMD sticks in duwen en werkt het ook. In principe wordt hier een SSD direct op de grafische kaart aangesloten.

Theoretisch kan de grafische kaart dit geheugen een stuk sneller benaderen dan wanneer deze op een gedeelde bus aangesloten zou zijn, zoals de PCI-e bus of via een SATA connector aan het moederbord hangt. Dit kan erg nuttig zijn voor berekeningen op de GPU die enorme hoeveelheden gegevens moeten combineren.

[Anoniem: 304426]

Ik begreep dat bij machine learning meer geheugen voor de videokaart ook wenselijk is. Is dit waar men naar zoekt?

[Mathieu_Hinder]

Dat is één van de toepassingen waar dat wenselijk is ja. Een paar gigabyte ram klinkt veel, maar is in de praktijk zo op.

[MSalters]

Het zou handig zijn, ja. Het netwerk wat je traint past altijd wel in 1GB, wat je nekt is alle trainingsdata waarmee het netwerk getraind wordt. Maar je traint een netwerk herhaaldelijk met kleinere batches. Hiermee kun je dus alle trainingsdata op SSD dumpen, en bij elke batch een random subset van SSD naar GDDR laden.

En ja, dat maakt uit. Ik heb in juni een SSD gekocht voor precies dit doel, om een trainingsset te cachen. Zelfs zonder directe GPU access is het nog winst.

[Xyfi]

Betekend dit dat ik straks naast in mijn moederbord, ook nog een hoop losse componenten in mijn grafische kaart moet gaan steken?

[gjmi]

Niet persé. Dit kan een extra optie zijn, of er zal een sdd standaard al opzitten. Ze willen denk ik kijken wat ontwikkelaars er mee kunnen en hoeveel GB SSD wenselijk is. Dan zorgt het toevoegen via m.2 voor een flexibele oplossing. Kunnen ze later nog zien wat ze er mee doen.

[vix-ducis]

De GPU is de laatste jaren sowieso al een beetje een intern systeem op zich aan het worden, met zijn eigen verwerkingseenheden, geheugen en controllers. Waarom zou het dan niet logischer zijn om deze componenten afzonderlijk inprikbaar te maken. Toegegeven, meestal is de performance dan wel iets minder dan dat ze ergens op de kaart zelf gesoldeerd zijn, maar ik denk dat dit een mooie toevoeging kan zijn voor mensen die iets later in de levensduur van hun kaart wat performance willen toevoegen, of voor mensen die gewoon nog een losse SSD liggen hebben.

[iDEOwen]

Goede ontwikkeling dit. Het zou zomaar eens kunnen dat je straks in de firmware kan configureren hoeveel je toewijst aan de grafische kaart, en hoeveel echt als dedicted storage bus (waar je gewoon je data op kan slaan). Net zoals dat je vroeger de hoeveelheid gedeeld geheugen met de videokaart kon instellen, maar dan net anders

Apple had trouwens al een SSD geplaatst op 1 van de grafische kaarten op de Mac Pro, alleen was dit gewoon om de SSD ergens te plaatsen, en had dit natuurlijk niets te maken met de grafische kaart zelf.

http://www.ozone3d.net/pu...repro-d500-gallery-05.jpg

[supersnathan94]

Klopt inderdaad. Dat was meer een passthrough omdat ze hem anders niet kwijt konden. Ik ben benieuwd naar de mogelijkheden om daar bijvoorbeeld twee kaarten van te pakken (de tweede kaart had geen SSD slot, daadwerkelijk fysiek ander ding). Dikke 1,5TB Raid 0 is wel lekker voor de snelheid als je wat grotere files hebt in archives. Moet je ook de 1200MB/s wel mee aan kunnen tikken dan. Maar voor de echte ruwe data heb je natuurlijk een thunderbolt raidset.

[iDEOwen]

Je mag een keer langs komen met een Mac Pro met D300 en het hier uitproberen met mijn Mac Pro... Ik heb het mijzelf ook altijd afgevraagd...
Als ik de block diagram bekijk, lijkt er alleen een PCIe lijntje af te komen vanuit Graphics Board B voor de SSD, maar kan niet zien of er op het LB wel de connectivity zit waar Board A aangesloten moet worden

[supersnathan94]

Helaas. Heb geen pro staan. Vraag me wel af wat er gebeurt als je twee MBP15"'s via thunderbolt en target diskmode in raid gooit.

[iDEOwen]

Dat gaat niet zo erg snel. Thunderbolt in Target Diskmode beperkt de snelheid naar de SSD, je krijgt niet de voledige SSD snelheid helaas. Dit is een beperking van Target Diskmode (zelf vaak uitgetest) op de Macs.

[supersnathan94]

Veel verder dan 2GB/s zal je ws niet komen met TB2 nee. Dat zit ik nu ook al met native PCIe ssd. Even vergeten dat TB2 minder bandbreedte heeft dan 1 SSD zelf kan leveren xD.

[iDEOwen]

Ik bedoel eigenlijk meer dat ie zelfs de thunderbolt bus niet verzadigd. De thunderbolt controller werkt niet op voledige snelheid zonder drivers, waardoor die ik in mijn geval 250 MB/s read haal op een SSD die ca 500 MB/s moet halen.
Ook via Target Diskmode over FW haal je niet de gehele FW snelheid (55 ipv 100 MBps)

[maratropa]

Terwijl je op de oude 4,1en 5,1 mac pro's nog wel opties hebt om tot 5GB p/sec te komen

[SpoekGTi]

Ow god, gaan we dat weer implementeren, doet me denken aan heel vroegah, mijn Tseng Labs ET6000 maar met 2MB was uitgerust en je 2x 1MB losse edovram kon bij prikken voor veel geld.

Of de SB AWE32 surfplant, met 30 pins ram sloten voor extra sound banks in te laden. 30 pins memory was toen al wat goedkoper.

[Martin-S]

aaahhh de Awe 32. moest er ook gelijk aan denken. ik heb hem nog steeds.

[SpoekGTi]

Gouwe tijden.... Toen je nog echt met dipswitches aan de gang moest

[Dreamvoid]

Is dit handig voor als je een mobo hebt zonder M2 slot? Of is het geen gewone storage dan?

[supersnathan94]

Nee. Het wordt gebruikt als storage voor de GPU en is niet beschikbaar voor de CPU (en dus file storage). Misschien kan je er via een GPGPU script wel data opslaan, maar als je al zoveel geld uitgeeft aan zowel deze GPU als de M2 SSD kan je beter een nieuw mobo kopen en een andere gpu.

[HJR]

de videokaart begint echt een computer binnen een computer te worden. goede ontwikkeling trouwens, maar ik vraag me alleen af hoelang die ssd's meegaan...

[Joecatshoe]

Yo dawg...

[CykkVii]

I heard you liked computers...

[supersnathan94]

... so we put a computer in your computer so you can compute while computing.

Klinkt mij meer als een hardware matige virtuele machine