AMD maakt details over Vega-architectuur bekend

AMD heeft tijdens de CES details bekendgemaakt over de Vega-architectuur, die in zijn nieuwe videokaarten terug te vinden zal zijn. De nadruk ligt daarbij op sneller hbm2-geheugen dat bovendien efficiënter gebruikt wordt dan bij vorige architecturen.

Over kloksnelheden, compute units of verbruikscijfers laat AMD nog niets los, maar de fabrikant heeft wel details over de architectuur van zijn nieuwe gpu met codenaam Vega naar buiten gebracht. De nadruk ligt daarbij op het geheugen, want tot dusver was de groei in rekenkracht relatief gezien groter dan de groei in geheugencapaciteit, aldus AMD.

De nieuwe architectuur maakt daarom gebruik van hbm2, waarvan de maximale capaciteit 32GB is, terwijl de bandbreedte verdubbelt ten opzichte van de eerste generatie hbm. Daardoor kan de geheugenbandbreedte oplopen tot in de terabytes per seconde. Of AMD daadwerkelijk een videokaart van 32GB hbm2 zal voorzien is overigens een kwestie van afwachten, want over dergelijke zaken wordt nog geen uitspraak gedaan.

Behalve snel geheugen is efficiënt gebruik van het geheugen volgens AMD ook belangrijk. Om het geheugengebruik in het gareel te houden heeft AMD de 'high-bandwidth cache controller' ontwikkeld, die op de gpu zit en de virtual address space beheert. De hbcc kan maximaal 512TB adresseren, verspreid over videogeheugen, werkgeheugen en opslag zoals een ssd of harde schijf. De controller zorgt ervoor dat data die de gpu nodig heeft in het snelle geheugen staat, terwijl data die niet direct beschikbaar hoeft te zijn elders geparkeerd wordt. Uit eigen tests van AMD zou bijvoorbeeld blijken dat in Fallout 4 en The Witcher 3 grofweg slechts de helft van het geheugen dat gealloceerd is daadwerkelijk gebruikt wordt en er dus geheugen vrij gemaakt kan worden om voor andere dingen te gebruiken.

AMD heeft ook de gpu zelf aangepakt. Er is ondersteuning voor primitive shaders, die het werk van een vertex en geometry shader kunnen overnemen en sneller kunnen uitvoeren. Dat kan op driverniveau, waarbij de driver bepaalt wanneer dat mogelijk is, of dat kan wanneer ondersteuning daarvoor in een game is ingebouwd. Per kloktik zou dat een verdubbeling van de snelheid betekenen.

Verder heeft AMD de load balancing verbeterd en zijn de compute units verbeterd. Daardoor kunnen ze op hogere frequenties werken en bovendien meer instructies per kloktik uitvoeren. Daarnaast is de geheugencompressie verbeterd en zijn de render backends nu clients geworden van de l2-cache, wat meer snelheid oplevert bij applicaties die van deferred shading gebruikmaken.

Het is nog een kwestie van afwachten hoe de Vega-videokaarten eruit gaan zien en wat het resultaat van deze architecturale verbeteringen in de praktijk zal zijn, want behalve deze details heeft AMD nog niets concreet gemaakt over daadwerkelijke kaarten.

Reacties (69)

[-The_Mask-]

Op YouTube zijn de filmpjes te zien.

• Vega in Action: DOOM® at 4K
• Vega for Radeon Pro
• Vega for Radeon Instinct
• Vega and Radeon for Gaming
• Vega: Changing the Game for Game Developers
• Making of “After the Uprising”

Oudere video's zie: https://www.youtube.com/user/amd/videos

Nu ook beschikbaar op ve.ga

Foto van de Vega chip met twee stacks HBM2 op Computerbase:
https://www.computerbase.de/2017-01/amd-vega-preview/

[Reactie gewijzigd door -The_Mask- op 31 juli 2024 10:19]

[s0larus]

Zo te zien geen livestream (volgens VideoCardz). Dan moeten we het maar doen met de slides en deze videos.

[JanW]

Aankondiging betrof ook alleen nog maar de preview, dus geen details nog over nieuwe kaarten.

[Razzah]

https://www.youtube.com/watch?v=4DEfj2MRLtA

Hier

EDIT: Oh die gaat over Zen

[Reactie gewijzigd door Razzah op 31 juli 2024 10:19]

[s0larus]

De countdown blijkt alleen voor de NDA van de presentatie slides te zijn.

[Atmosphere]

ve.ga had net wel behoorlijk last van het slash.dot effect

[Devaqto]

Ik kan niet wachten om te zien hoe deze technische verbetering effect hebben op praktische performance. Die technische termen klinken natuurlijk allemaal wel sexy, maar wij als consument willen FPS zien

[HanG-BuiK-ZwijN]

ik heb liever zo constant mogelijke frametijden om dat vreselijke microstuttering tegen te gaan dan bergen fps.

[Verwijderd]

Fps en frame-time zijn gewoon manieren om precies hetzelfde te beschrijven. Wat jij wil is een stabiele fps. Wat reviews vaak laten zien is gemiddelde fps waar je niet uit kunt halen of er stotteringen in zitten.

[HanG-BuiK-ZwijN]

niet helemaal correct, een stabiele fps wil niet zeggen stabiele frame tijden. Ik kan prima gemiddeld 60 fps hebben maar dan kunnen nog 59 frames er zijn in 1/120 seconde en de 60ste frame de rest van die seconde, dit zal toch ervaren worden als stottering, waardoor 60 fps gemiddeld niet zegt dat het beeld ook echt vloeiend gaat lopen. dat zegt een stabiele frame tijd wel.

[Verwijderd]

FPS en frame tijd zijn EXACT dezelfde wat betreft informatie. Ik kan ook gemiddeld een frametime hebben van 16.67ms waarbij er uitschieters in voorkomen.

Dit is gewoon de relatie tussen Hertz(Hz) en periode(secondes) welke beschreven word met de formule 1/frequentie(fps) = periode(frame-time). Je kan elke frame-time grafiek omflippen waardoor je de fps krijgt.

Ik snap dan ook niet waar het gedoe met frame-times vandaag komt. Het maakt het onderwerp alleen maar gecompliceerder. Het is niet eens intuïtief om te gebruiken.

Als je het concept van frequentie niet begrijpt dan raad ik je aan om deze wikipedia pagina even door te nemen: https://nl.wikipedia.org/wiki/Frequentie

edit: Mensen serieus het klopt gewoon dat frame-tijd en fps PRECIES DEZELFDE INFORMATIE OVERBRENGEN. FPS hoeft geen gemiddelde te zijn.

Hier heb je een random grafiek met frametime:
https://www.pcper.com/fil...Hitman_1920x1080_PLOT.png

En nu omgeflipt (1/Hz= periode):
http://i.imgur.com/ADisGge.png

Ongelooflijk hoeveel misinformatie "professional youtubers" kunnen verspreiden.

[Reactie gewijzigd door Verwijderd op 31 juli 2024 10:19]

[sdk1985]

FPS en frame tijd zijn EXACT dezelfde wat betreft informatie. Ik kan ook gemiddeld een frametime hebben van 16.67ms waarbij er uitschieters in voorkomen.

Dit is gewoon de relatie tussen Hertz(Hz) en periode(secondes) welke beschreven word met de formule 1/frequentie(fps) = periode(frame-time). Je kan elke frame-time grafiek omflippen waardoor je de fps krijgt.

Ik snap dan ook niet waar het gedoe met frame-times vandaag komt. Het maakt het onderwerp alleen maar gecompliceerder. Het is niet eens intuïtief om te gebruiken.

Als je het concept van frequentie niet begrijpt dan raad ik je aan om deze wikipedia pagina even door te nemen: https://nl.wikipedia.org/wiki/Frequentie

edit: Mensen serieus het klopt gewoon dat frame-tijd en fps PRECIES DEZELFDE INFORMATIE OVERBRENGEN. FPS hoeft geen gemiddelde te zijn.

Hier heb je een random grafiek met frametime:
https://www.pcper.com/fil...Hitman_1920x1080_PLOT.png

En nu omgeflipt (1/Hz= periode):
http://i.imgur.com/ADisGge.png

Ongelooflijk hoeveel misinformatie "professional youtubers" kunnen verspreiden.

Dat er een correlatie is tussen FPS en frametimes is logisch. Echter FPS gaat over frames per second. Het probleem daarmee is dat een seconde een te lange eenheid van tijd is voor hetgeen we willen beschrijven. Je krijgt dan binnen die seconde een gemiddelde waarde. Dat is de reden dat de minimum fps niet voldoende informatie verschafte. Met FPS kregen we de microstutter nooit in beeld terwijl we wel wisten dat hij bestond.

Hier kun je het hele verhaal eens rustig nalezen: http://techreport.com/rev...look-at-game-benchmarking .

Uiteindelijk is daar ook FCAT uit voort voren gekomen. Alleen zijn er weinig reviewsites die echt met FCAT meten (erg duur). De meeste doen het alsnog met FRAPS (wat suboptimaal is). Toch krijg je daar alsnog nuttige extra informatie van omdat er dan vaak ook een 95th of 99th percentile analyse wordt toegevoegd. Je ziet dan wat de waarde is gedurende de uitschieters.

Daar komt vervolgens de aap uit de mouw want in je 99th percentile analyse gaat de grafiek niet langer de FPS grafiek spiegelen. Vandaar het belang van Frametimes. Zie o.a. deze voorbeelden: http://techreport.com/rev...ok-at-game-benchmarking/6.

[Reactie gewijzigd door sdk1985 op 31 juli 2024 10:19]

[sdk1985]

Verdiep je eerst eens in FCAT, wat het is, wat het meet, hoe het dingen meet. Daar kom je verder mee dan dat we auto analogieën erbij moeten halen om een punt te maken.

Zie bijvoorbeeld: https://www.pcper.com/rev...aphics-Performance-Test-0 .

Als je dan een punt hebt dat er een fout in de methodologie van Nvidia/deelnamende websites zit dan is iedereen daar blij mee.

[Reactie gewijzigd door sdk1985 op 31 juli 2024 10:19]

[Baggio666]

Dat klopt, maar om jouw voorbeeld te gebruiken kan je als je weet dat een auto 120 km/u heeft gereden voor de periode die je gemeten hebt niets zeggen over de snelheid op een bepaald punt in die periode. En dat is nu juist hét verschil. Zolang je het gemiddelde per tijdperiode neemt zegt dat niets over de minimum en maximum tijd/snelheid in die periode.

[GoT.Typhoon]

Gemiddelde FPS en frametijden zijn niet hetzelfde... Lees de reactie van @HanG-BuiK-ZwijN nog eens goed. Die heeft het goed samengevat.

[SG]

Zijn exaxt het zelfde 1/x relatie.
Wat verschillend is elke frametime staat voor fps dat bij de frame hoort.

Als in 1 sec 101 frame times hebt dan heb je ook 101 fps punten voor elke frame time

Frametime groot is is fps laag.
Lage fps frame time hoog.

Het verschil is dat voor frametimes elke frametime wordt weergegeven.
Maar FPS is vaak grillige grafiek met resolutie die niet 1 op 1 gelijk is aan de frametimes dus vertekend beeld geeft.
Geinterproleerde gemiddelde van resolutie van 1/100 sec.
Dan mis je dus wat frametime detail bij 144 hz monitor

Als van frametime een 1 op 1 FPS maakt. Dan zie je bij frametime spikes een fps dip. Wat exact het zelfde zegt. Maar fps resolutie van punten grover dan frame times dan vlak je de dip af. Frametime is dan duidelijker.
Dan lijkt frame time duidelijker.
Met frame times van 5 minuten steady 144 fps met 10 matige dips krijg je ook gemiddelden vlakt het even hard af 5x60x144 waar aan 1920 grafiek niet genoeg aan hebt.

Daarnaast is wat hang buikzwijn zegt fout
59 frames in 1/120 sec
En 1 frame time 119/120
Is dus gemiddelde van 60 fps in die seconde maar is extreem onstabiel fps

Fout is dat fps niet om hele seconde gaat maar kan kiezen van bijna oneindig klein tot nano sec maar ook jaar tot eind der tijden kan pakken.
Fps is frames per second dus 1/144 frame time wordt naar 1 seconde aan frames gezet x 144/144 is 1 second en heb frames per sec voor frametime 144 FPS
Je kan dus t1 frame time van 1/100 zien als FPS ten tijde van die frame van 100 fps. De frame van t2 van 1/50 is fps van 50 en t3 1/144 is 144 fps.
Je kan dus frame time verloop 1 op 1 een fps verloop exact aan frame time.

Je kan gemiddelde van 1 sec pakken. Maar dat kan je van elke delta time pakken. Uiteraard heeft resolutie kleiner dan kortste frametime geen zin en jaar ook niet. Gemiddelde van minuut pakken om game sessie te registreren.

In de game loop wordt er delta time genomen. Soms ook gemiddelde van laaste paar frame time om zwaar afwijkende frametimes op te vangen.
Zoals het starten van de loop. Pauze en andere grens gevallen.

[Sissors]

De gemiddelde FPS en frametimes zijn niet hetzelfde nee, dat zegt hij ook niet. Maar de instantane FPS en frametimes zijn wel degelijk identiek. Ben het ook geheel eens met Bonobo dat frametimes nu ineens een hype zijn, net alsof je dat niet gewoon in de fps kan zien. Nee dat kan niet als je eerst de FPS gaat middelen over een seconde of meer, maar bij de instantane FPS kan je dat direct zien.

Of een ander voorbeeld: Jij hoeft niet eerst een uur te rijden in je auto voor de snelheidsmeter lang genoeg heeft geteld om je snelheid in kilometer per uur op te geven.

[Sissors]

Waarom zou je FPS maar eens per seconde updaten? Bij afstand over tijd loopt het mank volgens jou, maar bij frames over tijd is het geheel logisch om maar eens per die tijdseenheid te updaten?

Je kan prima de FPS na elk frame updaten. En dan is het gewoon 1/frametijd, precies zoals Bonobo hierboven uitlegt.

[sjaakwortel]

Dat is het zelfde als je over een uur eerst een half uur 80km/u rijdt en daarna 160. Dat is gemiddeld ook 120, maar wel met een flinke afwijking. Inderdaad is er een relatie tussen frametijd en fps, echter is fps een gemiddelde(over een seconde) terwijl bij frametijd kan er gekeken worden naar uitschieters.
Gemiddelde frametijd is dus gelijk aan fps, maar het is echt iets anders.

[Reactie gewijzigd door sjaakwortel op 31 juli 2024 10:19]

[Sissors]

Dat is hetzelfde als zeggen dat je eerst een uur moet rijden voordat je weet hoeveel kilometer per uur je rijdt. En dan als je met 160 geflitst wordt claimen dat je niet te snel ging, immers over het hele uur ging je slechts 120km/u.

Oftewel wie zegt dat FPS een gemiddelde is, km/u is immers ook geen gemiddelde.

[HanG-BuiK-ZwijN]

Als ik met een gemiddelde fps van 120 1 frame er tussen heb zitten wat er 10 keer zo lang over doet om in beeld te komen dan ervaar je dat als microstuttering en dus vervelend. Het is nog steeds 120 fps gemiddeld dan.

Echter dat frametijden zijn om te rekenen naar fps klopt, is een simpel sommetje. Ik kan echter fps niet omrekenen naar frametijden. Ik heb dus geen informatie over mogelijke microstuttering dan.

Een minimale fps van 100 icm een gemiddelde van 500 met max 1200 zegt niets over echt vloeiend beeld. hetzelfde in frametimes zegt dat wel.

[DohnJoe]

Wel als je het over gemiddelde frame tijd hebt, maar volgens mij gebruikt men vaak juist een soort percentiel waarde, zodat je inzage krijgt in hoe constant de frame tijden zijn.

[Werelds]

Men neme: 100 frames in 1 seconde.

FPS: 100
Gemiddelde frame-tijd: 10ms

Nu, HanG-BuiK-ZwijN had het specifiek over zo constant mogelijke frame tijden. Goed lezen.

Als van deze 100 frames 10 stuks in 30ms gerenderd worden en de overige 90 in 7,78ms zit je nog steeds op 100 FPS en een gemiddelde frame tijd van 10ms, maar toch zal jouw beleving behoorlijk kut zijn. Dus nee, wat hij bedoelt en waar jij het over hebt zijn volledig andere dingen.

Daarom zie je in reviews tegenwoordig een 99th-percentile en 90th-percentile weergave van frame tijden. Dat geeft een veel betere indicatie van hoe vloeiend de game draait dan alleen de FPS of gemiddelde frame tijd doen.

[Vayra]

Als je het eerste comment goed gelezen had was deze hele uitleg (en de discussie die daarop volgt waarin vier man elkaar iets gaan uitleggen wat we allemaal al weten...) niet nodig geweest.

Hang-Buik-Zwijn zegt het namelijk precies goed: 'ik heb liever zo constant mogelijk frametijden' dan de hoogst mogelijk FPS. Sleutelwoord is hier: constant. En ja, je kunt bij een 'constante' FPS nog steeds fluctuerende frametimes hebben.

Verder is FPS ook een gemiddelde over tijd, namelijk die van één seconde, en binnen die enkele seconde kan er óók een fluctuatie optreden. Daarom gaat frametime ook over *ms* en kan dus toegepast worden op elk opeenvolgend frame. FPS is een veel minder nauwkeurige notatie. Ja, je kunt de grafiekjes mooi omdraaien, maar de grafiekjes die er écht toe doen vwb microstutter gaan over iets anders en dat is het zogenaamde '99th percentile FPS'..

...en ik zie nu dat Werelds dit ook haarfijn uitlegt.

[Reactie gewijzigd door Vayra op 31 juli 2024 10:19]

[VNA9216]

het is niet het zelfde. met name de maximale tijd tussen 2 frames is interessant. als je 2 seconden neemt, en de eerste seconde doe je 119 frames, en de 2e seconde zit er een volledige seconde tussen 2 frames is dat veeeeel storender dan wanneer je 2 seconden van 60 FPS hebt. en toch kom je gemiddeld op 60 FPS uit.

[SG]

Het is exact het zelfde t delta 1/144 maar voor fps 1 seconde pakt dus afwijkende tijden , moet je tijd ook in de formule mee nemen.
Constante frametimes is wat je wilt en hoge FPS.
Laat je tijd weg is dat een formule vereenvoudiging dan is t de constante dus delta t voor frame time resolutie is delta t voor FPS.
Als microstuttering wilt weergeven is dus al duidelijk dat je fijne resolutie moet nemen. Niet de AVG of Max FPS dat duidelijk te grof.

Optimaal is constante 1/144 frametimes en zelfde Als constante 144 fps tijdens bunny hoppen in FPShooter.

Hoge fps is niet alles , constante lagere FPS is beter. Dan zwaar varierende hoge FPS tot slide show.
Als BF rock solid 30FPS heeft is goed speelbaar. Maar 60 FPS met dal naar 10 FPS met zooi lange frame times dat gemiddelde naar 20 fps trekt is vervelend.

Maar dat houd in frametime groter dan 1/30 en dus FPS dips lager dan 30 fps.

Omdat FPS en frametime direct gerelateerd zijn

Aan wiskundige formule FPS = 1/Ft
FT = 1/FPS
Completer is
Frametime delta t is 1/fps
FPS delta t is 1/ FT

Geld als delta t FT is delta t FPS

Voor beide geld als ze in grafiek weergeeft bij delta t > dan korste frametimes dan demp je frametime spikes maar ook de FPS dips. Houd niet in dat ze er niet zijn tijd resolutie is te grof.

Micro stuttering zegt het al je moet dan naar FPS kijken met resolutie die overeen komt met frametimes.

Benchen doet men vaak unsync dus als dips hebt van 10 fps maar soms de 250 fps haald bij bunny hoppen extreem Tearing.
Een resolutie van 5 millie sec is voldoende

Doel is hardware benchen niet game ervaring
Daar tearing niet gewenst en meer rendering per frame zonde van de energy.
Gamen doe je vaak v- sync om tearing te mijden bij smooth gfx experience dus stabile hoge FPS vsync. Om dips te reduceren zoals missen van vsync is hoge refreshrate 144 hz beter en freesync en G- sync helpen dat ook te reduceren.

Als bij een frametime grafiek bijna steady 1/60 met 1/5 spike
Zou je bij FPS balk bijna 60FPS balk zien met min fps deel van 5 fPS.

Micro stuttering vereist fps per enkele millie seconden. Moet niet met avg of max en hele seconden komen

[aryan1171]

In mijn ogen niet iets wat je als tweakers zegt maar ja, deze website is allang niet meer alleen voor mensen die op de technische termen letten. We blijven technisch gezien allemaal consumenten maar ik zie mijzelf liever als iemand die niet 'alleen' op FPS geilt. Ik hou er dan ook van om alle informatie die op de achtergrond qua ontwikkeling afspeelt bij te houden. Grappig trouwens dat ik mensen steeds meer en meer richting AMD zie gaan omdat Intel de afgelopen jaren weinig voortgang heeft geboekt op het gebied van procedes verkleinen en performance vergroten. Ik las eerder dat Zen beter presteert dan vergelijkbare generatie intel processoren. Wellicht komen de 'AMD concurrentie' dagen er weer aan. Zou leuk zijn want ik was Intel eigenlijk al wel een beetje zat.

[Devaqto]

Bedankt voor het compliment!

Als je een tijdje het AMD nieuws had gevolgd, zie je een trend van technische vernieuwingen zonder grote vooruitgang in vergelijking tot Intel/Nvidia. Daarom ik als Tweaker, wil bij wijze van; FPS zien.

Jouw conclusie is daarom te kort door de bocht, en generalisatie houden we helemaal niet van

[Rhaegar1]

Geen concrete aankondiging, dan wordt het toch gewoon de 1070. Kan wel blijven uistellen maar die Rift met capabele computer moet er nu echt is komen.

[Verwijderd]

Rx480 is prima voor vr, zeker als het een tijdelijke setup is totdat vega komt. Vega komt nog de eerste helft van 2017. Gewoon tijdelijk rx480, of nog even geduld.

[Rhaegar1]

Ja en 480 is dan wel prima maar wel graag wel klaar zijn voor een paar jaar en op 1070 niveau is er gewoon geen alternatief. AMD laat dat echt een gat liggen hoor, blijkbaar is de Fury zo duur om te produceren dat die gebruiken om het hogere segment waar onder druk te zetten geen optie is. Denk dat nvidea zich rot lacht als monopolist in dit segment.

[Verwijderd]

Voorlopig is een rx480 zat hoor, zeker als je een goede AIB oc'ed naar 1450mhz+. Sowieso kont vega voor eind juni nog, dus vervang je hem waarschijnlijk toch snel weer. Wanneer je de rx480 verkoopt krijg je het grootste deel van het aankoopbedrag terug. Ik zou gewoon wachten als ik jou was.

[Jack77]

Als je de real-world VR tests op HardOCP bekijkt (al minstens 10 applicaties getest), dan is de RX480 spijtig genoeg helemaal niet voldoende voor deftige VR. In de meeste gevallen doet Fury het beter. En dan nog.

[Verwijderd]

Snap VR sowieso niet. Waarom niet een ultrawide en je muis bewegen, of xbox controller gebruiken? Is dat zo moeilijk?

Verder hoeft vr niet zo'n zware taak te zijn. Je kunt beter je mobiel in een kastje zetten, draadloos verbinden met je pc en gameplay streamen naar je mobiel. Er is zelfs een vr bril daarvoor. The visusVR gebruikt je mobiel voor 60hz gameplay, en gebruikt nvidia's gamestream op max 1920x1080, maar kan wel upscalen naar hogere resoluties. Als je pc 60fps haalt op 1920x1080 zit je goed. Verder zijn er ook andere headsets die van een soort gamestream gebruik maken.

Waarom koopt haast niemand een headset die je mobiel als scherm gebruikt in combinatie met een simpel tracking systeem op de headset en een streamingservice? Zo moeilijk kan het toch niet zijn?

[Nieuwevolger]

Had eigenlijk gehoopt dat ze de kaarten gingen revealen, maar dat wordt dus nog wachten net zoals de 1080ti.

[Jack77]

Nvidia heeft voorlopig nog inkomsten uit de 1070 en 1080 en moet met niets komen.
Het is pas als Vega geleverd wordt, dat ze waarschijnlijk moeten reageren.

Met Fury was Nvidia zo zeker dat ze een beter presterende en goedkoper te maken kaart hadden, dat ze AMD nog voor de release van Fury konden treffen door de 980Ti te lanceren. Op een lager prijsniveau dan de Fury X, dan nog. (Jaja, de prestaties van Fury zijn maanden na de release verbeterd, maar op het ogenblik van de release was het niet wereldschokkend meer.)

Nu is Nvidia blijkbaar wat minder zeker en zullen ze wachten tot ze meer weten over Vega vooraleer ze zoiets als een 1080Ti lanceren. Dan kunnen ze nog kiezen hoeveel shaders ze enablen en aan welke kloksnelheden de GPU zal werken.

Feit is dat AMD niet zal kunnen blijven uitstellen...

[Fredi]

Amd heeft een grote fout gemaakt door Fury van HBM-geheugen te voorzien. Daardoor is het geflopt. HBM-geheugen was toen nog veel te duur om te produceren waardoor ze Fury veel te duur moesten verkopen. Ze hadden veel beter voor GDDR-geheugen gekozen. Ik hoop voor AMD dat de prijzen van HBM-geheugen intussen gedaald zijn.

Nadeel is ook de slechts 4 GB vram vd Fury-kaarten

[Reactie gewijzigd door Fredi op 31 juli 2024 10:19]

[osmosis]

Laatste tech afbeelding van Vega.
Daarbij staat dat 'Network Storage' Rechtstreeks verbonden staat met de memory controller

Iemand enig idee wat ze hiermee bedoelen?

[MistahMastah]

Vanwege de virtuele address space (van max 512TB) kun je dus hele grote bestanden gebruiken om mee te werken en ben je niet gebonden aan de 8GB die op je videokaart zit meegebakken. Deze bestanden staan soms lokaal, soms op netwerken - zoals bij grote bedrijven het geval is.

[Reactie gewijzigd door MistahMastah op 31 juli 2024 10:19]

[osmosis]

Aaah oké dat klinkt logisch. Interessante feature lijkt me voor bijv grote studio's in de game en/of film sector.

[Huib_Bloodstone]

Ik wil meer info horen zoek namelijk een passende vervanger voor mijn R9 290x Trixx

Als die Rizen nou ook een hakbijl in Intel zet dan moeten ze dat ook kunnen met de nvidia 1080

Fingers Crossed

[Verwijderd]

dit! Ik heb ook een R9 290x, maar om die te vervangen, is bijna niet logisch... Tuurlijk er zijn al vele kaarten sneller, maar die rechtvaardigen op dit moment nog geen upgrade ( kijkend naar de increase in performance tegenover het prijskaartje van die nieuwe GPU's ).

Ik hoop dus dat deze Vega chip een leuke upgrade kan worden.

[Reactie gewijzigd door Verwijderd op 31 juli 2024 10:19]

[ProAce]

Ik ben benieuwd wat de nieuwe kaarten gaan doen en wanneer ze beschikbaar komen. Het klinkt allemaal leuk, maar eerst zien dan geloven.

[fraptor]

Ik ben ook nieuwsgierig naar alles wat AMD aan het doen is. Zowel GPU als CPU. Kijk wel weer uit naar een strijd tussen de twee titanen Intel en AMD. Ik hoop dat er ook weer een prijzenoorlog aan komt

[Hazzelaar]

Ik wacht eerst wel tot mensen benchmarks hebben gedaan voordat ik een upgrade zal doen.
M'n R9 290 op waterkoeling doet het nog steeds dikke prima!
Maar ik hoop echt dat AMD weer een beetje een concurrent zal worden tegen Nvidia en Intel.
Dat zal alleen maar beter worden voor ons allemaal.

[Vagax]

Wel geweldig dat AMD zich terug vecht op de GPU markt