Om AMDs Vega 10!

SemiAccurate har testat förbrukning med fler skärmar, sammt steamVR.

Imponerande att en extra skärm bara drar 1W extra i idel jämfört med RX580 som drar ca 25W+, riktigt bra för dom som sitter med multi-monitor setups.
StemVR testerna ser också rätt bra ut.
Dom testar även mot Furyx m.m

Länk till hela testet: https://semiaccurate.com/2017/08/14/amds-radeon-rx-vega-56-review/

Fast om man tittar på RX480 vs 1060/1080 så är ju relativ prestanda enligt prestandaindex inom några enstaka procent samma idag som det var vid lansering av dessa kort. Kan ju naturligtvis vara så att Pascal fått en stor boost, fast relativ prestanda mellan 1080 och 980Ti är också inom någon procentenhet samma nu och då.

Så hur mycket boost har egentligen drivers gett? Framförallt mot bakgrund att Hardware Unboxed nyligen visade att de nästan 10 % som skilde deras resultat från AnandTechs resultat vid testing av Vega64 helt kunde förklaras av skillnader i vilka speltitlar som testades. Så prestanda förändringar <10 % kan lika gärna komma från val av speltitlar än från drivers, skillnaden från när 1000-serien och 400-serien lanserades är väsentligt under 10 % (med SweC prestanda index som mall).

Vad det gäller Ethereum mining borde väl ändå all din research ändå talat om att ~60 MH/s är teoretiskt max (när Vega64 har minnet på standardfrekvens), borde väl vara rätt uppenbart att rapporter som hävdar >60 MH/s är "fake news" (är realistiskt att nå kanske ~90 % av max som absolut bäst, det är ungefär för Polaris når med GDDR5 så 60 MH/s är kanske inte omöjligt med hyfsad HBM2-overclock).

Ethereum-mining är inte ett beräkningsmässigt hårt problem, det är "by design" ett bandbreddsbegränsat problem just för att man inte enkelt skulle kunna bygga ASICs.

Jämför man prestandaindex för Fury X och Vega 64 är den senare ~30 % snabbare, det med ~20 % högre basfrekvens och ca 45 % högre boost frekvens. Nu nämndes att Vega64 inte riktigt fixade att hålla sin boostfrekvens under SweClockers testning, men håller med att det borde vara större skillnad. Nu presterar Vega10 väldigt mycket som en högre klockad Fury X.

Det man ändå måste komma ihåg att Fury X har något högre bandbredd (i praktiken), så lägen där bandbredd

Ursäkta? Jag trollar ingenting. vad vill du säga med fetmarkeringen? Det är en fullkomligt logisk och solklar mening. Har du mer bandbredd än du kan utnyttja så kommer du inte få högre prestanda om du ökar bandbredden. Det är så enkelt. Precis som att du inte har nytta av 16GB RAM i en dator som bara kan adressera 4GB. Kan du inte utnyttja mer RAM så hjälper det inte att lägga till mer RAM. Solklart. Samma med bandbredd. Oavsett om du ökar bandbredd genom frekvens eller bitbredd så kommer du inte tjäna på att öka bandbredden om du inte kan utnyttja det.
Om Vega som du hypotiserar inte kan utnyttja sin bandbredd så spelar det ingen roll om du ökar frekvenserna, det enda som händer är att du ökar bandbredden.
Och du får ursäkta om du känner att jag läxar upp dig, men det känns som att du inte begriper ens grunden för det du diskuterar. Och nej, ett kort klarar inte lägre upplösningar snabbare för att det har sämre bandbredd. Det är fullkomligt ologiskt. Anledningen till att korten har låg bitbredd är för att svagare kort inte behöver lika mycket bandbredd. Och du sparar inga pengar på att sänka bandbredden med frekvenser. Däremot sparar du pengar på minneskapslar, PCB och på kretsyta ifall du sänker bandbredden genom att minska bitbredd. Alltså, att 1060 har lägre bitbredd än 1080TI är för att hålla kostnaderna nere. Inte för att 1060 skulle bli snabbare i lägre upplösningar om du minskar bandbredden, för det blir det inte.

Som sagt, det enda som spelar roll är i vilken hastighet minnet kan skyffla data (bandbredd) och hur snabbt ett data börjar flöda efter att det efterfrågats (latens). Om ett kort inte kan använda bandbredden som det har så kan du öka frekvens (därmed bandbredd) hur mycket du vill, det kommer inte ge högre prestanda. Det du eventuellt kan fixa är latens, men det är inte alls viktigt på samma sätt som för processorer, och det kan du fixa med timings.

Polaris är ju en GCN arkitektur den också så den har ju redan fått med sig mycket av det man ordnat i drivarna sedan 290 serien kom. Pascal har haft betydligt mer att tjäna, speciellt då den inte varit lika handikappad i DX12/Vulkan. Jag var dock väldigt specifik vilka GPU'er det handlade om (680, 7970, 780 och 290 serien) där Vega är ny gen och där bl.a FP16, DBSR, primitive shaders osv är rena prestandafunktioner som det i spel kommer att implementeras stöd för. DBSR har inte varit aktivt varken i FE eller nuvarande vega så vitt jag vet. Ensamt ger det stora prestandavinster på nvidia's GPU'er.

Jag har i dom flesta fall försökt kika på större speltitlar eller helt enkelt dom som va aktuella då och ser hur situationen ser ut idag. Jag har ju sett detta fenomen så många gånger man läst diagram och skummat igenom men visst kan jag lägga ner tid på att hitta siffror om det finns anledning att misstro det jag skrev. Jag tror att dom som köpte både 680 och 780 förstår mer än precis vad jag menar

Jag är glad om man når 60MH/s. Jag hade väl inledningsvis räknat med 45MH/s och kanske 55MH/s optimerat, men vi får väl se. Det är ju som vi bägge kan konstatera kul men svårt att estimera konkret prestanda baserat på det du skrev här under:

Med hänsyn till både liten avsaknad i ren bandbredd (utan att ta hänsyn till övrig cache och minneshantering i Vega) samt något underklockade resultat så är det fortfarande på tok för låga resultat i samma typ av operationer. Ett Vega 56 ska omöjligen kunna vara långsammare än ett Fury X. Samtidigt så har jag sett Vega pressa samma min-fps som Titan X i vissa fall. Det känns som att drivaren är fruktansvärt omogen (värre än vad dom vart i tidigare GCN lanseringar). Man kan ta det för vad det är, ett konkurrenskraftigt kort till priset med potential för att bli lite/mycket snabbare beroende på drivers/kommande titlar som kan använda Vega specifika funktioner/ISA's, men jag hade förväntat mig minst 20-30% högre prestanda. Något som verkligen inte stämmer. Enorma förluster någonstans som jag undrar är arkitektoniska eller inte.

Newegg har nya RX64 priser, motsvarande 7000kr för vanliga RX64 air och 8000kr för liquid edition.

Bra där, typ sämsta pris/prestanda som finns. Tror inte ens det är värt att vänta på partner kort, kommer kosta lika mycket som 1080Ti...

Freesync ska vad jag minns in som en standard i nya hdmi standarden 2.1. Effektivt dödande av g-sync

Skickades från m.sweclockers.com

Jag ställer mig till skaran som är skeptiska till AMD:s grafikavdelning. Lanseringen av Vega har varit katastrofal. De har medveten vilselett både recensenter och konsumenter genom den direkta höjningen av det aviserade priset, väldigt begränsad tillgång trots lovord om annat och hela marknadsföringskedjan under året. Att kortet ändå kommer så pass sent trodde jag personligen berodde på att de behövde mer tid för att finslipa drivrutinerna men bristen på hårdvara, speciellt hos partnertillverkarna, tyder på att det finns fler orsaker.

Vega-kortet i sig är inte ett dåligt kort. Problemet är att Nvidia ligger så pass långt före just nu. Som tidigare nämnt så har detta lett till att AMD har känt sig tvungna att pressa frekvenserna till nära max med hög effektåtgång till följd, likt Polaris. Kortet är helt klart bättre om man skruvar tillbaka det lite men då skulle det halka efter i prestandagraferna ytterligare så jag antar att det är den avvägningen AMD:s ledning har gjort.

Vega kommer även på tok för sent. AMD måste sitta och hoppas på att lanseringen av Volta drar ut på tiden. Om historien upprepar sig så kommer GTX 2070, eller vad det nu kommer att heta, prestera i klass med dagens 1080ti. (970 ~ 780ti, 1070 ~ 980ti). Det till ett pris runt $400. Det är inte så kul för AMD att behöva sälja en krets på 484m2 och HBM2-minnen för under det. Något de nu nästan tvingas göra med Vega 56. Nvidia har dock inte tidigare visat några tendenser på att sakta ner...

Vega drar paralleller med Nvidias lansering av Fermi-korten. Fast denna gång utan att ta prestandakronan (singel-gpu). Ett strömtörstigt kort, bra beräkningskraft och tvingat till ett högre pris tack vare detta.

Du hade ju läst "Vega" Instruction Set Architecture enligt tidigare inlägg, hur har du då helt missat att Vega är GCN5? Från första kapitlet

"The figure below shows a block diagram of the AMD GCN Vega Generation series processors"

Och även om man inte läst detta dokument utan bara följt med i nyhetsflödet borde det vara uppenbart att Vega är i det närmaste identisk med GCN3/4, initialt körde man enligt uppgift Vega på Fury drivarna vilket vore omöjligt om de hade olika ISA. (GCN3 är Fury och GCN4 är Polaris, de är ISA-identiska men skiljer sig till viss del i mikroarkitektur).

ISA-mässigt är GCN5 är till väldigt nära 100 % en utökning av av ISA i GCN3/4. Tydligen börjar man få ont om plats för opkoder så vissa instruktioner som i princip aldrig används har tagits bort för att ge plats för nya. På det stora hela är ISA för GCN4->GCN5 identisk med Maxwell->Pascal.

Så samma ISA men man har i det senare fallet lagt till stöd för FP16 i form av packed-math (d.v.s. man har inga 16-bitars register utan FP16 kräver att man packar in två 16-bitars tal i ett 32-bitars register, något mer komplicerat att använda än "fullt" FP16 stöd men kräver mindre transistorer att implementera).

Vilket än mer visar att det är sanning med en hel del modifikation att AMDs drivers blivit så mycket bättre. Dels är det egentligen bara efter övergången från VLIW till GCN som det blivit några stora vinster från drivers då de ursprungliga GCN-drivarna var allt annat än optimerade.

Vidare är det ingen hemlighet att riktningen tekniken i spelmotorer tog när de GCN-baserade konsolerna lanserades passade Kepler väldigt illa. Nu har jag glömt vem som gjorde testet, men finns ju en jämförelse av utvecklingen mellan GCN och Kepler drivarna där man testade exakt samma uppsättning spel. Slutsatsen där var att båda kretsarna såg ungefär samma förbättring på ~10 %.

Så förbättringarna för GCN har egentligen inte kommit från drivare och dessa förbättringar finns bara i någon statisk relevant magnitud när man jämför mot Kepler, orsaken är dock att de renderingstekniker som används passar Kepler extra dåligt.

Läs AMDs whitepaper om Vega, läs specifikt vad som skrivs om "peak kapacitet" på olika operationer. Undantaget kapacitet för antal fragment som kan hanteras per tidsenhet är kapaciteten per klockcykel identisk för Vega och Fury X, så varför ska man förvänta sig något annat än prestanda motsvarande en högre klockad Fury X?

Just kapacitet för fragmentshaders är extra intressant. Peak kapaciteten är högre tack vare bättre mikroarkitekturdesign (större L2 och man har organiserat den annorlunda). Men detta är också det steg som om någon del blir begränsat av bandbredd så är det detta, "sustained capacity" är ju något lägre i Vega 64 jämfört med Fury X p.g.a. något lägre bandbredd mot VRAM.

Vega kan vara mer effektiv jämfört med tidigare GCN, men det kräver att man explicit designat sin titel så den nyttjar "primitive shaders". Hur många spel tror du kommer använda det inom överskådlig tid då det inte stöds av något annat än Vega? (D.v.s. det stöds inte av något Nvidia-kort och inte av någon konsol, XboxX är Polaris-baserad så GCN4).

En sista väldigt viktig sak att suga i sig från Vegas whitepaper. Lär hur man fått designat om kretsen för att nå högre frekvenser (något Nvidia också fick göra i Pascal). Man har fått prioritera vissa specifika delar som fysiskt designats om så signalvägarna kortats, i andra delar har man fått lägga till pipeline-steg -> högre latens -> något lägre IPC allt annat lika.

Allt detta sammantaget: hur kan det förvåna någon om Vega presterar som ett högre klockad Fury X? Så länge FP16 och "primitive shaders" inte används är Vega (väldigt förenklat) ett högre klockad Fury X med något längre pipeline! Precis som Pascal är ett högre klockat Maxwell (och Pascal lär också ha längre pipeline) så länge man inte kör VR (bättre stöd för timewarp) eller "async shaders med parallell dispatch" (statiskt partitionering i Maxwell vilket gör det nära nog hopplöst att vinna något, dynamisk partitionering i Pascal).

Är det verkligen värt all ilska över en elektronisk produkt? Det blir inte någon av er som "vinner" argumentationen. Det är väl mer konstruktivt att objektivt diskutera dom fakta som finns. Prishöjningar är t.ex. än så länge obekräftade men verkar vara sanna igenom rabatter.

Skickades från m.sweclockers.com

Några kanske kommer ihåg denna bild som postades relativt tidigt i tråden.

Den bilden är ett litet destillat av vad AMD beskriver i detta patent. Någon som vet vad som hände med den tekniken?

Har nu läst de beskrivande delarna av Vegas ISA guide, där står bl.a.

"Conceptually, the kernel is executed independently on every work-item, but in reality the GCN processor groups 64 workitems into a wavefront, which executes the kernel on all 64 work-items in one pass."

Så Vega verkar, precis som alla GCN-kretsar, ha en fixerad bredd på en wavefront om 64 trådar.

En av orsakerna att GCN inte når lika nära sina teoretiska siffror som Nvidia är att 64 trådar delar på en programräknare medan 32 trådar delar programräknare Tesla-ISA (Nvidia har kört samma ISA sedan Tesla, så 200-serien).

Då spel börjar få allt med avancerade algoritmer och allt mer geometri blir en allt för "bred" wavefront/warp (AMDs resp Nvidias namn på en samling trådar som delar programräknare). Är möjligt att hantera villkorad körning där olika trådar inom en wavefront tar olika vägare, det är dock ineffektivt. Från Vegas ISA guide

"This GPU does no optimization when EXEC = 0. The shader hardware executes every instruction, wasting instruction issue bandwidth. Use CBRANCH or VSKIP to rapidly skip over code when it is likely that the EXEC mask is zero."

Sättet man hanterar fallet att någon/några trådar tar en avvikande väg är att GPUn kör alla vägar minst en tråd i en wavefront tar. Sedan sätter man EXEC masken så att instruktionerna bara tar effekt för de trådar som logiskt sett faktiskt borde köra instruktionerna. Så har man detta

if (pred) {
   foo();
} else {
   bar();
}

kommer både foo() och bar() köras, det i sekvens då det bara finns en programräknare för alla 64-trådarna. De trådar där pred var sann kör foo() med sin EXEC bit satt till 1 och kör bar() med EXEC satt till 0. För de trådar där pred blev falsk har då EXEC omvänt värde.

Det patentet beskriver är just en teknik för att optimera fallet där EXEC=0 för en större andel av trådarna, här står det specifikt att denna GPU (som då refererar till Vega) inte har någon sådan optimering.

Har man haft problem med denna teknik? Kanske till och med så att det här är förklaringen till förseningen och man fick till slut stänga av detta och skeppa utan. Eller finns annan insikt här och/eller andra spekulationer kring ovan?

Du är så långt ute och cyklar så vägen har tagit slut. Vad tog svaren på frågorna 2, 3, 4 vägen? Och dessutom svarar du fel på fråga 1 då ett normalt fabriksöverklockat GTX 1080 är snabbare, enligt Sweclockers även ett GTX 1080 FE.

Sure. Men att det saknas optimeringar och att något överhuvudtaget inte existerar enligt ISA-manualen är två väldigt olika saker.