Afbeelding toont vermoedelijk Nvidia Tesla A100-module met zes hbm2-stacks

Er is een afbeelding online verschenen van wat Nvidia's Tesla A100-module zou zijn, met daarop een GA100-gpu van de nieuwe Ampere-generatie. Te zien is dat de gpu wordt gecombineerd met zes stacks van hbm2.

Op de afbeelding, die door VideoCardz online is gezet, staat een sxm-module. Nividia gebruikt dat formaat ook bij zijn huidige Tesla V100-accelerator. VideoCardz heeft geen verdere details ontvangen over wat er op de afbeelding staat, maar het zou gaan om de Tesla A100, die Nvidia vermoedelijk later vandaag zal presenteren tijdens zijn GTC 2020-keynote.

Uit de afbeelding is op te maken dat de GA100-gpu gecombineerd wordt met zes stacks hmb2. Dat betekent dat de nieuwe gpu voor datacenters een grotere geheugencapaciteit en meer geheugenbandbreedte krijgt. Samsung maakt bijvoorbeeld hbm2e-chips van 16GB, daarmee zou de Nvidia-module in totaal over 96GB vram kunnen beschikken.

De afmetingen van de getoonde sxm-module komen niet exact overeen met die van eerdere generaties; mogelijk past Nvidia de formfactor iets aan. Nvidia presenteert tijdens zijn GTC 2020-evenement naar verwachting de Ampere-gpu-architectuur. Die zal aanvankelijk ingezet worden in Tesla-producten voor datacenters. Mogelijk komt er later ook een aangepaste consumentenversie voor GeForce-videokaarten. Nvidia's presentatie begint donderdagmiddag om 15 uur Nederlandse tijd.

Reacties (36)

[Balance]

Op dit moment heeft de Nvidia Tesla V100S vier stacks HBM2 van elk 8GB. Elke stack heeft een 1024-bits bus en is geklokt op 2214 MHz, goed voor in totaal 1134 GB/s aan bandbreedte.

De A100 krijgt dus 6 stacks, wat de bandbreedte meteen vergroot naar 1700 GB/s. Daarbij is het de vraag of Nvidia overstapt naar HBM2E. Deze specificatie maakt hogere stacks mogelijk (van 12 dies hoog) en verhoogt de maximale kloksnelheid formeel naar 2,5 GHz. Deze formele specificatie wordt echter bij HBM2 ook overschreden.

SK Hynkix en Samsung hebben beide HBM2E geheugen in de pijplijn:

• Samsung to Advance High Performance Computing Systems with Launch of Industry’s First 3rd-generation (16GB) HBM2E
• HBM2E Opens the Era of Ultra-Speed Memory Semiconductors

Samsung neemt dus 3,2 GHz HBM2E in de eerste helft van dit jaar in massaproductie en SK Hynix heeft het over zowel 3,2 als 3,6 GHz HBM2E maar nog niet over massaproductie.

Meestal eindigen producten met iets lagere kloksnelheden dan geadverteerd, we zagen bij de introductie van GDDR6 ook dat bijna niemand voor de volle 16 Gb/s opteerde. Dit is vaak alleen haalbaar met lage yields en/of hoog stroomverbruik.

3,2 GHz per stack zou 410 GB/s aan bandbreedte opleveren, een nette stijging over de huidige 283 GB/s per stack. Ik verwacht echter eerder rond de 2,8 GHz geheugen, als er al voor HBM2E wordt gegaan, om de prijs en stroomverbruik acceptabel te houden. Dan zou het 358 GB/s per stack zijn, met 6 stacks goed voor 2150 GB/s. Dat 90% meer dan de huidige V100S en 139% meer dan de V100, best een mooie sprong generatie over generatie.

Leuke speculatie, we gaan vanmiddag om 15:00 zien of er ook iets van waar is .

Edit: Zoals @-The_Mask- correct opmerkt moeten alle bovenstaande frequenties gehalveerd worden, HBM (en HBM2 en HBM2E) leveren 2 bits per pin per hertz, dus 3,2 Gb/s/pin draait op 1,6 GHz. Thanks!

[Reactie gewijzigd door Balance op 23 juli 2024 07:31]

[-The_Mask-]

Je zit sowieso overal een factor 2 er naast wat betreft de frequentie van het HBM.

[Slinke]

Binnenkort gamen we met zen allen in de cloud, De corporate server hardware is er al.

[PainkillA]

het zal altijd een latency probleem blijven omdat je gegarandeerd met hoge input lag zit. Als ik nu mijn muis beweeg dan zie ik direct op het scherm mijn beweging.

Met gaming in de cloud zal mijn input eerst over het netwerk naar een andere server gestuurd moeten worden. Dat moet dan nog gerenderd en teruggestuurd worden en als laatsts afgespeeld worden op mijn beeldscherm.

je hebt in dat laatste geval altijd een bijzonder irritante input lag van minimaal een ms of 30 tot wel veel meer wat zeer merkbaar is tegenover de 1ms die je lokaal hebt.

[Gamebuster]

Als ik nu mijn muis beweeg dan zie ik direct op het scherm mijn beweging.

Nope!

Voor het gemak ga ik uit van klikken ipv bewegen, gezien dat meestal de meting is die gedaan wordt. Mijn aanname is dat beweging en klikregistratie een vergelijkbare latency heeft.

Volgens RTINGS.com is een muis-latency van onder de 18 milliseconden "goed". Er zijn muizen die dit met 6ms doen, maar ook genoeg die er meer dan 20ms over doen, incl. zogenaamde gaming muizen. Draad of draadloos lijkt hier geen bepalende factor: Er zijn trage draadmuizen en snelle draadloze muizen. De snelste muizen hebben een latency van 6ms bedraad en 7ms draadloos. Enkele muizen die aangeprezen worden in de E-Sports wereld hebben volgens RTINGS.com een latency van 8 tot 11ms.

Dan heb je aan de andere kant van de keten te maken met display lag. Voor zowel TVs als monitoren is de theoretische minimum gemiddelde zo'n 9ms op 60fps. Een 60fps scherm ververst nl. 60x per seconde: Iedere 16.6ms dus. De gemiddelde perfecte latency is dan de helft daarvan: 8.8ms, of 9ms voor het gemak.

Volgens displaylag.com hebben de beste monitoren en TVs een input lag van 11ms tot 14ms. Genoeg gaming monitoren die cijfers van 20-30ms neerzetten, of zelfs meer.

De game software moet de input ook verwerken. Ook dit heeft displaylag.com in de database, ook al is de database vrij beperkt. Merk op hoe de "AVG Input Lag" hier uitgedrukt is in frames, niet in milliseconden. Dat is ongeveer hoe slecht het ervoor staat bij input lag in games.

De betere games in de lijst zitten rond de 4 tot 6 frames aan input lag! Games als Tekken, Street Fighter, Mortal Kombat dus ook, waar timing essentieel is. Met 16.6ms per frame is dat dus een input lag van 6*16.6: 100 milliseconden!

Vergelijk dit met de ping van je internet verbinding, wat de latency is voor een signaal van en naar een server, en dan zie je dat een goede Nederlandse verbinding naar een Nederlandse server gewoon 4ms latency heeft. Dat wil zeggen dat ik sneller een signaal naar Amsterdam en terug kan sturen, dan een muisklik van mijn muis naar mijn computer. Die 4ms is een retour signaal; het duurt dus 2ms om een signaal te sturen naar een server, en 2ms om 'm weer te ontvangen. 5G doet het nu al in 30ms volgens Verizon, en sneller is mogelijk:

1–4 ms will be extremely rare for years outside the lab.

Een optimist leest hier dat 1 tot 4ms latency gewoon mogelijk is over 5G. We hebben het hier over een mobiele verbinding met een latency van 1 tot 4ms!

Cloud gaming komt er wel. De latency issues zijn tijdelijk: Een symptoon van legacy verbindingen en een gebrek aan optimalisatie in een nieuwe markt. Onze kinderen gaan straks op 5G of 6G op hun smartphone of tablet lekker gamen in de cloud vanuit de trein, met een input lag die minder is dan jij nu op je PS4/xbox hebt. Terwijl wij achter onze grote desktop towers aan gigabit ethernet praten over of cloud-gaming mogelijk is, heeft de technologie ons al ingehaald met mobiele netwerken en smartphones.

Overigens, je vergeet 1 gigantisch voordeel van cloud gaming: Geen lag tussen clients in multiplayer, en sterk beperkte mogelijkheden voor cheaten, anders dan aimbots die gewoon naar het scherm kijken.

Je zal geen CSGO gaan spelen over de cloud, maar de toekomstige Fortnite/Call of Duty/Battlefield (games die nu al 30fps draaien op consoles) voor massa-comsumptie kan prima en zal niet slechter zijn dan de huidige console versies, behalve dat je geen dure console hoeft aan te schaffen en dat je het overal kan spelen, niet alleen thuis.

[Reactie gewijzigd door Gamebuster op 23 juli 2024 07:31]

[marwatt]

Want in de cloud gelden natuurlijk niet de latencies zoals op je eigen pc en kunnen rustig genegeerd worden, en moet enkel rekening gehouden worden met de latency van het signaal over het netwerk..

[Gamebuster]

Nee... mijn boodschap is dat de standaard 100ms verandert in 104ms en dat je dat verschil niet merkt. Bovendien kan je in de cloud andere optimalisaties doen. Als je bijv. een game presenteert in 60fps, maar de videokaart kan 240fps renderen, dan zou je 4 clients tegelijk bedienen, waarbij iedere client een frametime van 4ms heeft ipv 16ms. Die 12ms besparing is compensatie voor de netwerk lag.


Een videokaart die 4 games tegelijk in 1/4e tijd kan renderen is natuurlijk heel duur en kan een consument niet normaal betalen.

Denk aan 4 stuks AI-upscaled 900p content op medium settings. (Xbox one S niveau) renderen op RTX 2080 niveau hardware. Videogeheugen kan deels gedeeld worden, want er draait wel 4x dezelfde game.

Dat AI upscaling kan zelfs wel lokaal gedaan worden om zo ook minder data over een draadje te hoeven vervoeren.

Waarschijnlijk kan je ook werken met halve framerates met frame interpolatie waarbij je iedere 2e frame in de client voorspelt, net zoals VR brillen dat doen bij tragere PCs. (reprojection?). Zo heb je alsnog 60fps terwijl je er maar 30 hoeft te sturen over het netwerk.

In het begin is dat natuurlijk super glitchy en duidelijk zichtbaar, maar met wat optimaliseren en een flinke bak software valt het waarschijnlijk bijna niet meer op.

Opeens kan je dan 8 clients voorzien met in totaal 240fps op een RTX2080. (30 fps per client met frametime van 4ms; die framerate wordt clientside verdubbeld met allemaal software magic)

Je kan zelfs reprojection technologie gebruiken icm de nieuwe input data om direct al de frame te manipuleren. Zo heb je alsnog native input lag voor iedere frame, in ruil voor subtiele grafische glitches. Die glitches nemen toe bij tragere verbindingen, en zijn nagenoeg onzichtbaar bij goede verbinding.

Met een vlotte google actie zie ik dat daar al vele papers over zijn. Er worden oplossingen bedacht die we nu nog niet kunnen voorzien.

[Reactie gewijzigd door Gamebuster op 23 juli 2024 07:31]

[sdk1985]

Nee... mijn boodschap is dat de standaard 100ms verandert in 104ms en dat je dat verschil niet merkt.

Klinkt meer alsof je low latency gaming zelf nog niet ervaren hebt.

Ik ben dit jaar 120 Hz (8.3 ms) met 60 Hz (16ms) gaan vergelijken en die 8ms is zichtbaar en voelbaar. Technieken als G-sync zijn ook duidelijk voelbaar. Verschil met 144Hz was niet om te zetten in betere ingame resultaten.

Ik heb een website tegelijk open gezet op de pricewatch: LG UltraGear 34GK950F Rood, Zwart en de pricewatch: LG UltraGear 34GK950G Zwart en heb ik toen één van de 2 monitoren op 60 Hz gezet. Vervolgens ben ik gaan scrollen; omhoog, pause, omlaag, pause. Met mijn Samsung S9 heb ik hiervan burst shots gemaakt. Als je die terugkijkt (al dan niet door er een gif van te maken) dan zie je duidelijk dat het beeld dat op 60 Hz draait trager naar onderen beweegt en pas 1-2 foto's later tot stilstand komt. Dat bevestigd de soepelere 'ervaring'.

Via in-home streaming kun je al jaren van je lokale pc naar een andere tragere pc (bijvoorbeeld een HTPC) streamen met de netwerk latency van +- 1ms. Uit eigen ervaring weet ik dat het eindresultaat dat je daar mee behaald niet echt geschikt is voor de meeste games. Een mmo is prima speelbaar maar zelfs in een arcade racer als the crew merk je meteen dat je minder goed presteert door de extra latency. De vraag is wel welk deel van die latecny veroorzaakt werd door de TV en welk deel door het streaming systeem. Ik zou het eens opnieuw kunnen testen op mijn gaming monitor .

[Gamebuster]

Klinkt meer alsof je low latency gaming zelf nog niet ervaren hebt.

Ik heb een 165Hz scherm aan een 2080TI, een G Pro Wireless muis. Ik merk direct al op mijn desktop wanneer dit scherm op 60fps staat stiekem. Echter, framerate is niet gelijk aan latency. Dat zijn 2 verschillende dingen. Ik durf met zekerheid te zeggen dat als je bij jou 20ms latency zou toevoegen aan je 120Hz scherm (en wel alsnog 120fps haalt dus), dat je het verschil niet merkt. Bij een "onervaren persoon" kan je 20ms vervangen door 200ms, en ik durf te wedden dat 50% van de normale mensheid het niet zal merken buiten een AB test.

Ik heb ook een nintendo switch aan een TV hangen die in Zelda 20-30fps haalt. Ik heb ook een Steam Link.

Natuurlijk speelt mijn PC / native BETER. Maar de switch is "goed genoeg". De Steam Link werkt ook prima. Er is latency en beeldverlies, maar ik vind het niet storend genoeg, en dat is voor technologie in babyschoenen.

[Reactie gewijzigd door Gamebuster op 23 juli 2024 07:31]

[sdk1985]

Ik zou die weddenschap maar niet aan gaan want ik kan op 2 meter afstand zien als een game onder de 60 fps draait, laat staan als ik er zelf mee speel. Microstutter merk ik ook meteen. Dit zeg ik niet in de context van "kijk mij eens goed zijn", het is gewoon een storende factor waarbij ik inderdaad moet opmerken dat sommige van mijn vrienden er minder last van hebben. Als ik Forza Horizon 4 op mijn Xbox speel dan kan ik unbeatable ai niet verslaan, hangt toevallig momenteel niet aan een TV maar aan een gewone monitor, op mijn pc wel. Heel knap van al die xbox spelers die dat wel kunnen.... Enige wat bij mij helpt is de binnen camera van de auto gebruiken zodat je de auto wat beter kunt plaatsen, op de pc is dat niet nodig.

Via project-xcloud (streaming van xbox naar telefoon waarop je controller via BT is aangesloten) kan ik de wagens overigens niet eens op de weg houden.

O.a. bij tftcentral kun je total lag test bekijken, in mijn geval:

The screen showed a total lag of only 9.2ms. Approximately 3.95ms of that can be accounted for by pixel response times, leaving an estimated signal processing lag of only 5.25ms. This is basically nothing and means the screen should be fine for all levels of gaming. Other G-sync screens to date have shown similar very low levels of lag which is pleasing.

Meer uitleg

Input Lag vs. Display Lag vs. Signal Processing

To avoid confusion with different terminology we will refer to this section of our reviews as just "lag" from now on, as there are a few different aspects to consider, and different interpretations of the term "input lag". We will consider the following points here as much as possible. The overall "display lag" is the first, that being the delay between the image being shown on the TFT display and that being shown on a CRT. This is what many people will know as input lag and originally was the measure made to explain why the image is a little behind when using a CRT. The older stopwatch based methods were the common way to measure this in the past, but through advanced studies have been shown to be quite inaccurate. As a result, more advanced tools like SMTT provide a method to measure that delay between a TFT and CRT while removing the inaccuracies of older stopwatch methods.

In reality that lag / delay is caused by a combination of two things - the signal processing delay caused by the TFT electronics / scaler, and the response time of the pixels themselves. Most "input lag" measurements over the years have always been based on the overall display lag (signal processing + response time) and indeed the SMTT tool is based on this visual difference between a CRT and TFT and so measures the overall display lag. In practice the signal processing is the element which gives the feel of lag to the user, and the response time of course can impact blurring, and overall image quality in moving scenes. As people become more aware of lag as a possible issue, we are of course keen to try and understand the split between the two as much as possible to give a complete picture.

The signal processing element within that is quite hard to identify without extremely high end equipment and very complicated methods. In fact the studies by Thomas Thiemann which really kicked this whole thing off were based on equipment worth >100,1000 Euro, requiring extremely high bandwidths and very complicated methods to trigger the correct behaviour and accurately measure the signal processing on its own. Other techniques which are being used since are not conducted by Thomas (he is a freelance writer) or based on this equipment or technique, and may also be subject to other errors or inaccuracies based on our conversations with him since. It's very hard as a result to produce a technique which will measure just the signal processing on its own unfortunately. Many measurement techniques are also not explained and so it is important to try and get a picture from various sources if possible to make an informed judgement about a display overall.

For our tests we will continue to use the SMTT tool to measure the overall "display lag". From there we can use our oscilloscope system to measure the response time across a wide range of grey to grey (G2G) transitions as recorded in our response time tests. Since SMTT will not include the full response time within its measurements, after speaking with Thomas further about the situation we will subtract half of the average G2G response time from the total display lag. This should allow us to give a good estimation of how much of the overall lag is attributable to the signal processing element on its own.

[Reactie gewijzigd door sdk1985 op 23 juli 2024 07:31]

[Sp3ci3s8472]

Nee... mijn boodschap is dat de standaard 100ms verandert in 104ms en dat je dat verschil niet merkt. Bovendien kan je in de cloud andere optimalisaties doen. Als je bijv. een game presenteert in 60fps, maar de videokaart kan 240fps renderen, dan zou je 4 clients tegelijk bedienen, waarbij iedere client een frametime van 4ms heeft ipv 16ms. Die 12ms besparing is compensatie voor de netwerk lag.

Zo werkt dat niet, als je 4 clients hebt die 60fps per seconde vragen dan rendered elke client gewoon op 16.6ms, niet ineens 4ms.... Die 4ms krijg je alleen als je ook serverside op 240 fps rendered (dus 1 client), want dat zou betekenen dat je bij het versturen van die 60 fps steeds de frame kan pakken die het meest recent is. 4 clients die op 60 fps renderen is gewoon 16ms input lag in het meest optimale geval.
Het is dus of 1 client 4ms, of 4 clients 16.6ms, niet magisch beiden want dan moet die kaart nog een factor 4 sneller zijn.

Waarom denk je dat een consument dat niet kan betalen? Niet iedereen zal dat kunnen betalen, maar die kaart die ze in die datacenters gebruiken zullen het echt niet veel beter doen dan de highend consumenten gpu's.
Ze zijn alleen beter in een aantal specifieke taken zoals ML.

Wat denk je dat reprojection gaat doen als je dat lokaal doet dat gaat gewoon een overhead geven en dus ook inputlag toevoegen, waardoor de winst die je daarmee haalt misschien niet eens zo groot is. Hetzelfde geld voor AI en interpolatie. Het mooie van AI is dat je dat ook nu al kan doen, DLSS. Dus je kan op een tragere kaart die de meeste consumenten kunnen betalen een spel er een stuk beter uit laten zien.

Ik zie er meer brood in dat game engines pas op het laaste moment in het rendering process de de keyboard/mouse input gebruiken. Dat zie je met VR al gebeuren, maar die winst zal je dan zowel op PC als in de cloud gaan zien.

Het is dus niet technisch misschien niet onmogelijk, maar het is zeker nog niet op het niveau dat ik het zou willen gebruiken. Daarnaast zijn game uitgevers hard bezig om alle cloud oplossingen te slopen (door hun spellen er van af te halen), dus of er toekomst hier in zit is nog maar even afwachten. Ik wil een spel een keer kopen en de controle daar over hebben en ik ben niet van plan bij elke game uitgever een abo te moeten afnemen wat we nu al met de film industrie zien.

[Reactie gewijzigd door Sp3ci3s8472 op 23 juli 2024 07:31]

[Gamebuster]

Zo werkt dat niet, als je 4 clients hebt die 60fps per seconde vragen dan rendered elke client gewoon op 16.6ms, niet ineens 4ms.... Die 4ms krijg je alleen als je ook serverside op 240 fps rendered (dus 1 client),

Zo werkt dat wél. Als 1 GPU op 240fps met 4 clients bediend met 60fps per client (dus A, B, C, D, A, B, C, D, etc), dan heeft ieder frame een frametime van 4ms, niet 16.

Je kan input blijven ontvangen/verwerken voor client D terwijl je de frame van C aan het renderen bent.

Waarom denk je dat een consument dat niet kan betalen? Niet iedereen zal dat kunnen betalen, maar die kaart die ze in die datacenters gebruiken zullen het echt niet veel beter doen dan de highend consumenten gpu's.

Hoeveel consumenten kunnen videokaarten betalen die 4x zoveel performance hebben als huidige generatie consoles? Ze zijn er vast wel, maar dat is niet de doelgroep van deze streaming-diensten.

Wat denk je dat reprojection gaat doen als je dat lokaal doet dat gaat gewoon een overhead geven en dus ook inputlag toevoegen

Ik heb niemand horen klagen over de input lag bij reprojection in VR games. Waarom zou dit bij streaming anders zijn?

Het mooie van AI is dat je dat ook nu al kan doen, DLSS. Dus je kan op een tragere kaart die de meeste consumenten kunnen betalen een spel er een stuk beter uit laten zien.

DLSS-achtige technologie zou je dus ook kunnen gebruiken om game streams te upscalen

Ik zie er meer brood in dat game engines pas op het laaste moment in het rendering process de de keyboard/mouse input gebruiken. [...] Het is dus niet technisch misschien niet onmogelijk, maar het is zeker nog niet op het niveau dat ik het zou willen gebruiken

Dat is zo ongeveer mijn boodschap: De technologie is er nu nog niet helemaal, al is het wel bruikbaar. Zodra er meer spelers komen, komt er meer ontwikkeling voor de technologie om de performance te verbeteren, waardoor er meer spelers komen.

Ik wil een spel een keer kopen en de controle daar over hebben

Jij wel, net als die 1 in de 10.000 die nu nog CDs, MP3s, DVDs en BluRays koopt. De rest van de "normale" mensen nemen gewoon spotify, netflix, youtube en straks dus ook een game streaming dienst.

Daarnaast zijn game uitgevers hard bezig om alle cloud oplossingen te slopen (door hun spellen er van af te halen)

Zo begon het met audio- en videostreaming ook. Geef het een paar jaar. Straks heb je 10 game-streaming diensten.

- Worden wij er vrolijk van? Nee.
- Is het een goed business model? Ja. Maandelijkse inkomsten whoopwhoop.
- Vereist het grote investeringen zoals een gaming PC of console? Nee.
- Is het daardoor toegankelijk voor de nieuwe generatie jongeren? Ja.

In een wereld buiten tweakers.net willen mensen gewoon een spelletje spelen. Die spelen op hun PS4/xbox one (niet de snelle pro versies) met hun TV met 200ms input lag en die zijn daar content mee. Die mensen willen hetzelfde spel spelen als hun vriendjes maar games zijn duur, dus spelen ze vooral gratis free-to-play games.

Als er een grote game (de volgende CoD/Fortnite/whatever) exclusief op een streaming dienst is die gewoon goed genoeg (let op mijn verwoording: GOED GENOEG) werkt voor het grote deel van spelers, dan breekt het door. Niet voor jou en mij, wij houden onze desktop & halen onze games van GoG.com, omdat we ons bewust zijn van een betere tijd. Echter, de nieuwe generaties... meh. Die vinden het wel best. De meesten wel, althans.

Je krijgt er ook iets voor terug: Je kan onbeperkt iedere game spelen. Je hoeft geen games of hardware voor te kopen. Net als bij netflix en spotify. De enige rede dat het nog niet grootschalig gebruikt wordt, is de negatieve imago (boehoe latency) en de technologie die nog in de kinderschoenen staat, maar dat is een kwestie van tijd.

[Reactie gewijzigd door Gamebuster op 23 juli 2024 07:31]

[Sp3ci3s8472]

Zo werkt dat wél. Als 1 GPU op 240fps met 4 clients bediend met 60fps per client (dus A, B, C, D, A, B, C, D, etc), dan heeft ieder frame een frametime van 4ms, niet 16.

Zo werkt dat niet, een GPU werkt parallel, niet serieel. Dus het is ABCD, ABCD; dus 16ms per frame. Als het inderdaad serieel is wat ik betwijfel dan heb je gelijk want je deelt een GPU op in 4 virtuele delen.
Tenzij je een bron hebt die dit aangeeft werkt dat gewoon niet zo, de clocks van de GPU zijn daar te laag voor. Als je GPU 4x zo hoge clocks had en 4x minder shader units dan had je dit inderdaad zo kunnen doen.


Natuurlijk kan je input blijven ontvangen, dat gebeurt nu ook al in een aantal VR titels die op het laatste moment pas die data gebruiken, dat gaf ik al aan in mijn vorige post.

Het is misschien 4x de performance van de oude generatie consoles, maar reken er maar op dat het niet 4x de performance van een PS5 of nieuwe XBox is. Sowieso zijn deze GPU's nu niet echt bedoelt voor gaming, de clocks zijn te laag en de focus op FP64 is te hoog. Je wil liever een RTX 3080Ti of dergelijk en dat in een server. Google pakt met stadia ook gewoon gaming GPU's (Vega56).

De reden dat je niemand hoort klagen over reprojection bij VR is omdat alle data al in de pipeline zit van de GPU. Als je die van een server krijgt moet je dat inladen etc, dat geeft overhead.
Zelfde voor DLSS en interpolatie. De overhead zal misschien niet drastisch zijn maar het is een extra stap.

Ik heb bijna nooit blurays of cd's gekocht.
Waar ik op doel is dat ik liever een of twee diensten heb zoals Steam en GOG waar ik een veel grotere garantie heb dat mijn games van mij blijven.

[Gamebuster]

Zo werkt dat niet, een GPU werkt parallel, niet serieel. Dus het is ABCD, ABCD; dus 16ms per frame. Als het inderdaad serieel is wat ik betwijfel dan heb je gelijk want je deelt een GPU op in 4 virtuele delen.

Een GPU's processor werkt inderdaad parallel. D.w.z., het kan dezelfde berekening over vele datasets tegelijk uitvoeren. Dat betekent niet dat een GPU "niet serieel" is: Het kan prima 1 berekening uitvoeren en daarna een andere. Beide zijn echter irrelevant voor de discussie.

Stel je voor dat je op 1 GPU met veel geheugen (bijv. 4x de minimum benodigd voor een game) alle data inlaad voor 4 instanties van dezelfde game tegelijk (en ik negeer hier even dat het theoretisch gezien mogelijk zou zijn om grote hoeveelheden data te delen tussen de 4 instanties van de game, zoals textures)

Tegelijkertijd draait op de CPU, 1tje met lekker veel cores, 4 instanties van de game. De CPU vangt voor speler A de input via het netwerk en verwerkt deze. Vervolgens stuurt de CPU de geupdate game-state naar de GPU voor speler A, en geeft de GPU de opdracht deze game-state te renderen op een relatief lage resolutie en GFX settings. Omdat de gekozen GFX settings laag genoeg zijn om een target van 240fps te halen, is de videokaart hiermee klaar in 1/240e van een seconde: 4ms dus.

Terwijl de GPU hiermee bezig is, is de CPU bezig met het voorbereiden van de data voor speler B. Na die 4ms is de CPU hiermee klaar, want ook de CPU is vlot genoeg om op 240fps te renderen of in ieder geval is in staat om verspreid over alle cores 4 instanties op 60fps te draaien.. De data aanvoer vanuit de CPU voor speler B wordt verzonden naar de GPU en krijgt nu de opdracht om te renderen met de game-data voor speler B. Opnieuw, dit wordt gedaan in 4ms, terwijl de CPU al werkt voor speler C.

De CPU doet dan: BCDABCDA (16.6ms per 4 tekens)
De GPU doet dan: ABCDABCD (16.6ms per 4 tekens)

Hierdoor heb je op 60fps alsnog 1/4e van de input lag als dat je zou hebben op 60fps op een PC zelf wanneer de PC net snel genoeg is om 60fps aan te kunnen. Die 3/4e tijd heb je dan extra om data over netwerk te sturen.

Op een normale PC, die 4x zo traag is, ziet dat er zo uit:

De CPU doet dan: AAAABBBBCCCC____ (16.6ms per 4 tekens)
De GPU doet dan: ____AAAABBBBCCCC (16.6ms per 4 tekens)

[Sp3ci3s8472]

Natuurlijk kan een GPU dingen serieel uitvoeren, maar daar ligt zijn kracht niet. Vandaar dat ik dit overtrok.

Dat hangt helemaal van de configuratie af hoe je een GPU gevirtualiseerd hebt. Als je deze zo virutaliseerd dat ze als 4 aparte GPU's worden gezien dan werkt dat niet zo.

Als je de GPU zo configureerd dat je niet 4 aparte virtuele GPU's hebt (zoals jij beschrijft) dan kan je inderdaad gebruik maken van dingen zoals Async Compute, maar dat gaat nooit je rendertijd terugbrengen van 16ms naar 4ms, dit geeft hooguit een performance winst van 20%.
In jouw situate ga je er ook van uit dat een GPU niks zit te doen en op input van de CPU zit te wachten.
Wat je je in theorie beschrijft kan heel mooi zijn. Alleen werkt het in de praktijk gewoon niet zo. Ook al zou je in de meest optimale situatie 4x hetzelfde spel op een GPU draaien, dan nog zal je dus voor elk frame (dus A, B, C of D) een hele hoop cache misses gaat krijgen op je GPU waardoor je die befaamde 240FPS nooit gaat halen.

De ontwikkeling van GPU's is al lang niet meer rauwe flops. Dat komt omdat de limitatie steeds meer aankomt op bandbreedte (en latency) en dat wordt met caches voor een gedeelte opgelost. Als jij bij elk frame een andere dataset krijgt dan ben je gigantisch ineffcient bezig.

Deel je de GPU op in 4 dan heeft elk stukje zijn eigen cache en geheugen en is dat een stuk efficienter en kan het allemaal parallel worden uitgevoerd.

Op een normale PC, die 4x zo traag is, ziet dat er zo uit:

De CPU doet dan: AAAABBBBCCCC____ (16.6ms per 4 tekens)
De GPU doet dan: ____AAAABBBBCCCC (16.6ms per 4 tekens)

Dat zal er op een normale PC ook anders uitzien, Async Compute kan er voor zorgen dat een GPU veel optimaler ingezet kan worden en niet aan het idlen is.

[boto]

Ik snap dat je dit graag wilt, maar hoe je t ook went of keert; er zit een vertraging in. Sommige mensen willen dat niet en merken dat. SOmmige mensen niet, en die kunnen prima cloud gamen.

lichtsnelheid gaat niet opeens sneller. En als jij denkt dat het pingen van een server hetzelfde is als een grafisch beeld over het internet pompen via udp dan is dat gwn niet waar.

Je hebt het overigens ook over consoles en 30fps, waarom zou ik dat willen? Ik wil 4k/60-144fps.

Dat kost gewoon teveel geld. Ik ben blij dat cloud gaming er is, want heel veel mensen die niet de hardware willen/kunnen kopen kunnen dat ook meegamen.

[Gamebuster]

Je hebt het overigens ook over consoles en 30fps, waarom zou ik dat willen? Ik wil 4k/60-144fps

Ja JIJ wil dat, maar de gemiddelde menigte heeft niet eens een gaming PC en speelt net zo graag met 30fps op een PS4/X1, of zelfs op hun smartphone. Dat is een interessantere doelgroep dan jij.

[Reactie gewijzigd door Gamebuster op 23 juli 2024 07:31]

[boto]

Dus we zijn het eens. Verschillende producten voor verschillende doelgroepen. Maar dan hoef je nog niet te zeggen dat de lag naar de servers niet te merken is. Want dat slaat natuurlijk nergens op.

Ik merk het al als ik game vanaf steam streaming ipv lokaal, laat staan op remote servers via nogal wat switches.

[Gamebuster]

Maar dan hoef je nog niet te zeggen dat de lag naar de servers niet te merken is. Want dat slaat natuurlijk nergens op.

ik denk dat vele mensen het verschil niet merken, nee.

Ik merk het al als ik game vanaf steam streaming ipv lokaal, laat staan op remote servers via nogal wat switches.

lokaal streamen is een technologie in de kinderschoenen en niet geoptimaliseerd. De lag is niet door je netwerk, maar waarschijnlijk door het encoden en decoden. Dit is geen beperking van netwerken, maar gewoon een kwestie van optimaliseren.

Overigens vind ik lokaal streamen via Steam Link eigenlijk al heel degelijk. Je merkt het, maar het is goed genoeg.

[lezzmeister]

Je hoeft geen dure console of pc aan te schaffen, maar als jij denkt dat ze zich niet rijk rekenen en je uiteindelijk minder geld afdraagt heb je het compleet mis.
Kijk nu wat ze vragen per uur/4weken/maand en reken het zelf uit.

Daarnaast ben ik niet tevreden over de beeldkwaliteit bij de cloudgamingdiensten die ik tot nu toe heb geprobeerd. Buiten de hoge latency.

[Reactie gewijzigd door lezzmeister op 23 juli 2024 07:31]

[Gamebuster]

als jij denkt dat ze zich niet rijk rekenen en je uiteindelijk minder geld afdraagt heb je het compleet mis.

Oftewel, heb is nog eens een goed verdienmodel ook? Nog meer rede om erin te investeren of zelfs exclusives uit te brengen.

[Sp3ci3s8472]

Ik raad je aan dit te kijken:
Gamers Nexus Google Stadia review

Latency van pc's is een stuk lager, en die 4ms waar jij het over hebt is er nog niet (maar komt misschien met 5G). Het zal uiteindelijk misschien genoeg zijn voor console peasants .

[Gamebuster]

Stadia is een kinderschoenen project. Een proof-of-concept.

Het zal uiteindelijk misschien genoeg zijn voor console peasants

Exact! Ik zeg ook niet dat WIJ die streamingdiensten wat gaan vinden, maar de jongere generaties die niet beter weten en opgroeien met TVs met 200ms input lag omdat ze de settings niet aanpassen... daar is het prima voor. Altijd iedere game kunnen spelen. Geen dure PS4/X1 aanschaffen. Geen dure games aanschaffen. Gewoon een 10tje of 2 per maand en onbeperkt gamen, net als netflix en spotify.

Net zoals dat spotify en netflix duidelijk slechtere kwaliteit* hebben dan CDs en blurays, maar toch zie je maar weinig mensen nog CDs of BluRays kopen. Jij misschien wel, en ik ook (ik koop CDs en BluRays), maar de rest van de menigte niet hoor.

*spotify op "high quality streaming" is overigens niet te onderscheiden van een CD, maar genoeg die dat niet aanzetten en het wel best vinden. Netflix daartegen is zichtbaar slechter dan een bluray, maar nog steeds ruim "goed genoeg".

[Reactie gewijzigd door Gamebuster op 23 juli 2024 07:31]

[Sp3ci3s8472]

Je hebt inderdaad hierin gelijk. Het is wat je gewend bent en wat je zelf als minimaal wilt zien.

[Zapato]

Stadia werkt bij mij anders perfect hoor.

[styno]

Wat zijn die goudkleurige rechthoekige blokken rondom de GPU?

[achtbaanfreak]

Ik vermoed de VRMs, om de GPU van de juiste spanning te voorzien.

[Ladiesman777]

Cooling van de VRM.

[Scriptkid]

Ligt het aan mij of ziet dit er uit als een render ipv een foto.

Heel veel dingen zijn enorm strak en die schroefgaatjes , en chips hebben geen nummering etc.

[_Thanatos_]

Er wordt ook nergens gemeld dat het een foto is

[loekf2]

Moest gisteravond wel lachen om die CEO van Nvidia die een datacenter AI accelerometer uit de oven in z'n eigen huis haalt:

https://arstechnica.com/g...dgx-deep-learning-system/

[bones]

Kun je hier mee minen?

[dehardstyler]

Ja hoor, geen enkel probleem. Moet het ook geld opleveren? Dat is waarschijnlijk een stuk lastiger.

[Guneyd]

VideoCardz heeft geen verdere details ontvangen over water op de afbeelding staat,

Typo?

[Reactie gewijzigd door Guneyd op 23 juli 2024 07:31]

[jeffrhap]

Of een spatie ertussen? (wat er)

[Guneyd]

Ah, dat zou logischer zijn dan 'wafer' . Thnx!