Details van AMD Radeon Pro V340 met twee Vega 10-gpu's verschijnen online

Op internet zijn details verschenen van de AMD Radeon Pro V340, een gpu voor de professionele markt die met 32GB hbm2 en twee Vega 10-gpu's is uitgerust. De kaart zou 32 gebruikers tegelijk kunnen bedienen.

AMD richt zich volgens de slide die Benchlife publiceert, op ontwerpers, de olie- en gas-sector en de professionele media- en entertainmentmarkt. Benchlife publiceert vaker authentieke slides van cpu's en gpu's die nog niet aangekondigd zijn. De slide staat aan het einde van een volledige presentatie die AMD op 14 juni hield. De AMD Radeon Pro V340 bevat 32GB hbm2-geheugen. Een enkele Vega 10-gpu kan met maximaal 16GB hbm2 gecombineerd worden, schrijft Hardwareluxx, die aanvankelijk suggereerde dat de Radeon Pro V340 daarom met een op 7nm geproduceerde Vega 20-gpu, met een 4096bit- in plaats van een 2048bit-bus, uitgerust zou worden,

Videocardz tekent aan dat de Pro V340 al in de drivers terug te vinden is en wel als 'AMD Radeon Pro V340 MxGPU', wat erop wijst dat de kaart over meer dan één gpu beschikt. Daaruit valt af te leiden dat de Radeon Pro twee Vega 10-gpu's heeft. Verder is gedeelde hardwarematige codering voor de h264- en h265-codec aanwezig en is er een ingebouwde coprocessor voor beveiliging.

Reacties (43)

[|sWORDs|]

MxGPU wil helemaal niet zeggen dat er meerdere GPU's aanwezig zijn. MxGPU zegt alleen iets over het kunnen delen van de GPU met meerdere gebruikers. Delen van GPU in vSphere topic

Gezien de naam is het een enkele GPU, anders had er wel x2 in gestaan net als bij de S7150 en S7150 x2 MxGPU videokaarten. Erg vreemd is dat ook niet, NVIDIA is na de M60 met vGPU en twee GPU's ook naar een enkele GPU gegaan met de P40. Of er komen weer twee versies (eentje met 16GB en een x2 met twee GPU's en 32GB?).

Als jullie hier ooit nog iets over willen schrijven, ik heb MxGPU (s7150) en vGPU (K2, M60, P40) kaarten liggen en jullie kunnen delen van mijn whitepaper gebruiken...

[Reactie gewijzigd door |sWORDs| op 26 juli 2024 03:53]

[HeepH]

Misschien off-topic maar ik probeer het.

Ik begrijp dat het op deze manier inzetten van GPUs vooral bruikbaar is voor compute taken, maar hoe zit het met real-time 3d GFX?

Mijn droom is om 1 ontzettend zware PC/server te gebruiken met 1 gigantische GPU om dan met 10 vrienden tegelijkertijd met behulp van virtuele machines te gamen tegen elkaar.

Ik ben bekend met hardware virtualisatie en iedere VM zijn eigen GPU geven, maar hoe dicht bij zijn we bij het dynamisch alloceren van GPU rekenkracht op één GPU. Dus 1 gamer: alle GPU kracht naar hem. 10 gamers op de server? Iedere user 1/10e van de totale GPU power.

Dit dynamisch alloceren van resources is wat virtualisatie zo interessant maakt, dus ik vroeg me af wanneer dit mogelijk wordt voor real-time 3d gfx... Dat het misschien kwa kostenplaatje (nog) geen interessant scenario is begrijp ik, maar qua tech heeft het zeker mijn interesse!

[|sWORDs|]

NVIDIA doet dit al met Geforce Now vanuit 'de cloud' en op bijvoorbeeld een P40 of V100 zou je dit zelf kunnen doen daar is een behoorlijk potje op te gamen. Een quick test met Superposition geeft hier met een P40 4GB vGPU een score tussen een 1070 en 1080 in. Of je 10 gebruikers op een enkele GPU gaat halen betwijfel ik, dit ligt heel erg aan de game, de resolutie en de framelimiter instellingen, maar er is altijd meer uit een GPU te halen door deze te delen. Een GPU is vaak even bezig om de framebuffers te vullen en 100% belasting is vrijwel niet altijd geheel 100%, als je ver genoeg zou inzoomen zitten daar nog aardig wat blokjes met 0% tussen (al dus NVIDIA). 12 personen op 4 GPU's met recente games in een enkel systeem lijkt me aannemelijker dan 10 op 1. We hebben het echter dan wel over meerdere tienduizenden euro's aan hardware, daar kun je 12 flinke game machines van bouwen.

Maar het hele delen van een GPU is natuurlijk pas echt zinnig waar er niet continu een hoge belasting is, iets wat je bijvoorbeeld vaak bij CAD e.d. ziet.

[Reactie gewijzigd door |sWORDs| op 26 juli 2024 03:53]

[Duca_griff]

Heel erg verhelderende whitepaper!

[rjmno1]

Rare kaart, zou het om cryptomining te gebruiken zijn?
Of moet ik hem catalogiseren onder Nvidia 1080 ti en titan xp.
Meerdere gebruikers kunnen deze kaart gebruiken, dus ook onder VMWare.
Goede ingeneurs bij amd, je hebt er daadwerkelijk iets aan, .misscien ook leuk voor een sandbox te draaien.Jammer dat dit geen sentetische benchmark erbij is, dan zou hij kunnen vergeleken kunnen worden met andere videokaarten.

[Reactie gewijzigd door rjmno1 op 26 juli 2024 03:53]

[|sWORDs|]

Je moet hier denken aan een Fire Pro (tegenhanger van Quadro, kaarten voor workstation gebruik met andere drivers geschikter voor bijvoorbeeld CAD en rendering) kaart met extra geheugen waarbij je de kaart kunt delen, deze gaat niet in een workstation of desktop, maar in een server. Buiten virtualisatie worden deze kaarten eigenlijk niet gebruikt. NVIDIA wil met Volta (V100 e.d.) de kaarten dichter bij elkaar brengen, dus mogelijk dat die in de toekomst een minder duidelijke scheiding tussen Quadro/Tesla en Grid kaarten gaan krijgen. Net als dat de Titan V ook de lijn tussen Geforce en Quadro vervaagd.

vGPU/MxGPU kaarten hebben bijvoorbeeld geen video output, dus geen HDMI/Displayport/DVI/VGA en dergelijke en zijn vrijwel altijd passief gekoeld (de machine moet de kaart van flinke airflow voorzien).

[Reactie gewijzigd door |sWORDs| op 26 juli 2024 03:53]

[gameguy12]

Mhm interessant, maar is de vega 10 niet de gpu uit de Ryzen 5 2400G en Ryzen 7 2700U? Zouden ze in dit topic niet de VEGA 56 of 64 bedoelen?

[NiLSPACE]

Het is verwarrend, maar met Vega 10 bedoelen ze de vorige (huidige) generatie Vega kaarten, dus de Vega 56, 64 en de geïntegreerde GPU's. Vega 20 is de volgende generatie die dus ook op 7nm gebakken wordt.

[White Feather]

Dat is de RX Vega 10.

Lekker duidelijk inderdaad:
Ryzen 3 2200U: Vega 3
Ryzen 3 2300U (Pro): Vega 6
Ryzen 3 2500U (Pro): Vega 8
Ryzen 3 2700U (Pro): RX Vega 10

Ryzen 3 2200G(E) (Pro): RX Vega 8
Ryzen 3 2400G(E) (Pro): RX Vega 11

Als je naar de bovenstaande kijkt is het eigenlijk 64 Unified shaders en 4 Texture Mapping Units "per Vega"=Compute Unit
Je moet bovenstaande dus lezen als: Vega-ontwerp, nummer als aantal Compute Units.

Ze hadden eerder al de Vega 10-chip op de markt gebracht. Die zit in de Radeon
RX Vega 56 en Radeon RX Vega 64. Ook daar verwijzen de nummers in de naam (56 en 64) naar de CU's.

Dan komen ook de Vega 11-, 12- en 20-chips nog.
En dan hebben ze ook weer de Pro, XT en GL(XT) in gebruik genomen.

Dank je AMD, lekker helder.

[Juzzby]

Ik snap de conclusie voor vega 10 ook niet helemaal. Er staat "De AMD Radeon Pro V340 bevat 32GB hbm2-geheugen. Een enkele Vega 10-gpu kan met maximaal 8GB hbm2 gecombineerd worden" en "een gpu voor de professionele markt die met 32GB hbm2 en twee Vega 10-gpu's is uitgerust". Maar dan hou ik toch echt nog 16GB over. Of is dat nodig om die 32 gebruikers gescheiden van elkaar te houden ofzo?

[Reactie gewijzigd door Juzzby op 26 juli 2024 03:53]

[Sandor_Clegane]

Volgens mij geldt dat voor de GPUs waarin je hem opdeelt. Dus je kan maximaal 32 GPUs hebben met 1 GB, of je kiest ervoor om bijvoorbeeld 4 van 8 te maken.

Zo lees ik het in elk geval.

[Verwijderd]

Radeon instinct was de professionele 'kaart' als tegenhanger voor Vega 10. Die had inderdaad 16GB HBM2. De Vega 'maar' 8GB. Dus het klopt wel dat dit op basis van de Instict is en zo 2x 16GB kan hebben.

[nelizmastr]

De Vega 56 en 64 staan bekend als Vega 10 als serie. Bij de mobiele chips en IGP's wordt met Vega 10 een Vega chip met 10 CU's bedoeld.

[t!n0]

Multi GPU is dood (voor gaming), why bother? Bak liever eens fatsoenlijke (lees: écht concurrerende) single GPU chips AMD...We hebben de concurrentie nodig met die prijzen van Nvidia van tegenwoordig.

[Reactie gewijzigd door t!n0 op 26 juli 2024 03:53]

[Crp]

Multi gpu werkt beter als het op 1 kaart zit. Want dan werkt het als 1 videokaart. Anders dan crossfire of sli waar 2 kaarten moeten samenwerken

[|sWORDs|]

Het voordeel van meerdere GPU's op één kaart is de density (op deze manier krijg je 8-16 GPU's in 1U) en het maximaliseren van het gebruik van de PCIe lanes. Voor de werking maakt het niets uit of de GPU's op één of meerdere kaarten zitten, elke gebruiker krijgt toch maar een share van een enkele GPU.

Je moet het als volgt zien:
Ik stop een S7150 x2 in een machine en krijg twee GPU's met elk 8GB geheugen.
Deze GPU kan ik opknippen in meerdere virtuele GPU's, bijvoorbeeld 16 GPU's met elk 512MB.
Dan delen 16 gebruikers een GPU maar hebben elk een eigen deel van het geheugen.
De eerste gebruiker heeft tijdelijk 100% van de GPU tot zijn beschikking (tenzij predictable performance aan staat dan gelijk 1/16e deel), maar zijn er 16 gebruikers die allemaal de GPU wat zwaarder belasten dan krijgen ze elk 1/16e van de GPU tijd.
Maar een gebruiker krijgt nooit GPU tijd van meerdere GPU's of zal zich tijdens een sessie tussen GPU's verplaatsen.

Later dit jaar is het met NVIDIA op vSphere wel mogelijk om de sessie naar een andere host te verplaatsen om de prestaties in balans te houden met vGPU vMotion.

Het kunnen delen van de GPU met zoveel gebruikers is in de meeste gevallen niet waar, voor vrijwel alle taken heb je 1GB framebuffer nodig en voor heel veel zaken 2GB. In de meeste gevallen zul je met 32GB dus maximaal 16 gebruikers van een GPU kunnen voorzien. NVIDIA heeft bij Pascal de 512MB profielen laten vervallen en gezien de aantallen in de slide hierboven doet AMD nu bij Vega hetzelfde.

[Reactie gewijzigd door |sWORDs| op 26 juli 2024 03:53]

[Crp]

Bedankt voor de uitleg!
maar mijn reactie was op t!no die het over multi-GPU gaming heeft als in Crossfire/SLI

[dylan111111]

Onzin, het blijven 2 aparte gpu's, de workload moet alsnog gesplit worden.

[halofreak1990]

Nee hoor. Da's alleen met de brakke implementaties die nVidia en AMD gebruiken. 3dfx had dit véél beter voor elkaar met hun implementatie van SLI, waarbij het geheel door de driver werd afgehandeld en de software er geen weet van had. Dit is naar mijn mening de enige correcte implementatie, en ook de enige manier waarop het gebruik van meerdere GPUs ooit mainstream kan worden.

[SG]

Nou nee ten eerste was nv al met T&l in hadware bezig en was 3DFX met aparte t&l chip bezig om paar VS100 chips aan te sturen. Voor de toen accient API. Maar toen had 3Dfx al loodje gelegt.

Maar dat is niet relevant want lost het probleem niet op laat staan dat direct mee te maken heeft.

Net als bij CPU heb levels van snel geheugen. Latency tussen de verschillende soorten in verschilde orde kwa delay.

Systeem ram is traagst vram minder L2 van gpu zit daar boven dan local block buffers voor constanten sharen en dan de locale memory of registers in compute units.

Het probleem is dat data wat verwerkt moet worden van games groot en veel varianten voorkomen.

En probleem is dus dat elke resource nodig voor huidige en wat er in de pipeline zit voor elke gpu gebuffert moet worden in elk hun eigen lokale vram omdat de latency van de vram van de andere gpu hoger is dan locale Vram. Bij gelijke latency en bandbreedte is verdeling van taak makkelijker.

Dus daarom sli ruk omdat vram niet kan optellen wel de bandbreedte.

En dat heeft te maken met data locality en latency

[halofreak1990]

Ik snap niet veel van de +2 die jij gekregen hebt voor dit niet samenhangende 'verhaal' wat
- nauwelijks iets te maken heeft met wat ik schreef
- weinig tot geen uitleg geeft
en ook totaal niets toevoegt aan de discussie

[dylan111111]

Ah duidelijk, dat is voor mijn tijd

Ook mee eens dat dit geheel door de driver afgehandeld moet worden, je ziet het nu met dx12 waar de ontwikkelaar zelf de implementatie kan maken. Dat gebeurt gewoon niet op een enkele game na.

[SuperDre]

MultiGPU is verre van dood hoor, juist met DirectX12 heb je die onzin als SLI/crossfire niet meer nodig.
Maar je hebt gelijk, de prijzen van de huidige GPU's moeten eens grondig gaan zakken, want 350+ euro voor een midrange kaart is belachelijke (waar dat 5 jaar geleden nog geen 200 euro was).

[Ardjee]

Multigpu is helaas hardstikke dood: de developer is met dx12 verantwoordelijk om multigpu support fatsoenlijk in te bakken. Aangezien 90% van alle triple a games ports zijn, gaat die support er gewoon niet komen en ondersteunen games actief sli/crossfire niet

[SuperDre]

Onzin, want steeds meer games maken gebruik van de grote engines (Unreal Engine 4, Unity, CryEngine, Frostbite, etc), en ondertussen ondersteunen de meeste van die engines al native DX12 multigpu, dus de doorsnee gamedeveloper hoeft daar niets voor te doen.

[Foxpat]

Omdat het gericht is op virtualisatie in de professionele markt, daarom ook de "pro" in de naam Dat is helemaal niet dood.

[Cave_Boy]

Voor een enkele pc ja. Maar in virtuele omgevingen zeker niet. Deze markt is nu juist flink aan het groeien en ik voorzie nog wel dat er kastjes komen die een hele lichte Linux versie hebben waarmee je inlogt op een server waarna je gewoon je game kunt starten. Voor heel veel gamers is de latency die je krijgt (via internet) acceptabel.

[t link]

Ik zie nog best mogelijkheiden om netzoals met infinity fabric meerdere gpu dies aan elkaar te lijmen.

[LopendeVogel]

Haha wat maakt mij gaming nou uit? Daar heb ik een console voor.

[jqv]

Gelukkig is deze Rade9n Pro NIET gericht op gaming, maar op de professionele workstations.

Dus snap niet dat je dan begint over gaming als deze kaart een geheel andere doelgroep heeft.

Ik ga ervan uit dat je niet verder gelezen hebt dan de kop...En daar staat Radeon en Vega in.
Lees je verder dan kom je achter het doel van deze kaart.

[Reactie gewijzigd door jqv op 26 juli 2024 03:53]

[t!n0]

Zeker het hele artikel wel gelezen, eerder dan het hier erop stond ik kijk naar de potentie van een chip en generatie. We weten toch allemaal dat AMD eerst Pro kaarten uitbrengt om deze chips in een gaming variant te stoppen.

[comatoast]

`` Een enkele Vega 10-gpu kan met maximaal 8GB hbm2 gecombineerd worden ``
met 2 gpu's kun je dus 16GB gebruiken .. kaart heeft 32GB maar niet 4 gpu's .. no compute

artikel is ondertussen gewijzigd naar 16GB per gpu

[Reactie gewijzigd door comatoast op 26 juli 2024 03:53]

[|sWORDs|]

Ook een quad GPU kaart zou mogelijk zijn (zie bijvoorbeeld NVIDIA M10), maar aangezien Oil & Gas bij de doelgroep staat lijkt me dat onwaarschijnlijk, om daar voldoende rekenkracht per GPU uit te krijgen zou de TDP veel te hoog worden.
NVIDIA heeft wel een high performance (bijna 20x zo snel als een 1080Ti in double precision) single GPU kaart met 32GB HBM2:
https://www.nvidia.com/en-us/data-center/tesla-v100/

[Reactie gewijzigd door |sWORDs| op 26 juli 2024 03:53]

[sonnemans]

De Vega frontier edition had gewoon 16gb hbm2... Dat was dus gewoon vega64 maar dan 16GB, dus dan keer twee zou wel kunnen uitkomen op 32. Rare conclusie dus van die 8Gb

[renslmf23]

Volgens mij inmiddels aangepast naar 16 gb, dus toch 32 gb in totaal.

[comatoast]

you are right

[Sandor_Clegane]

Zou mooi zijn als ze dat SR-Iov ook gewoon aan zouden zetten in hun "gewone" kaarten. Leek me wel wat om meerdere VMs te draaien, allemaal met hardware acceleratie.

[Fred_Perry]

Is dit nu de tegenhanger van de nvidia m10? Iemand een idee hoe het licentiemodel bij AMD geregeld is? Sinds Grid 2.0 is dit bij Nvidia een flinke kostenpost. Wij willen gaan overstappen van K2 naar M10 in de VDI, maar hopelijk krijgen we nog de tijd om iets van AMD te poc-en.

[PolarWolf]

't zou mooi zijn, een beetje fatsoenlijke concurrentie op die markt is best wel gewenst. nvidia maakt nu een beetje de dienst uit en dat is nooit goed voor de betaalbaarheid van dergelijke oplossingen.

[|sWORDs|]

AMD vraagt geen licenties op de huidige kaarten, geen idee wat ze bij Vega gaan doen. K2 naar M10 is wel een rare stap, van performance naar density? Ook denk ik niet dat je nu nog aan M kaarten moet beginnen, die zijn al een flinke tijd EOL.

[Fred_Perry]

oeps, mijn fout. We willen van de K1 af ipv de K2. Goed gezien.

Ik wil ook liever niet meer aan de M kaarten beginnen, maar Pascal ontbeert het nog aan een Density-Optimized kaartje.

Hopelijk snel meer info over deze Radeon kaart!

[|sWORDs|]

Kleine correctie, de M10 blijft voorlopig gewoon leverbaar, alleen de M6/M60 zijn vervangen.

[Verwijderd]

Ik ben benieuwd naar de koeling van deze Vega, een enkele 64LC zit al flink op het randje voor een 120mm AiO, aan de andere kant lijkt het mij stug dat zij een 240mm AiO er bij gaan leveren?

Of zou het dezefde principe zijn als bij de "accelerators" van Nvidia - gewoon een zeer groot koellichaam zonder fan en dan airflow binnen de kast gebruiken?