Tråden som skvallrar om Polaris.

Det har alla Radeon-kort haft sedan man stoppade in stöd för transform & light (Radeon 7x00). Däremot så är geometrikapaciteten i dagens GCN en av de saker där Nvidias kort är rejält mycket snabbare (t.ex. kapacitet för tessellation) så är ju helt rätt av AMD att specifikt fokusera på denna punkt med Polaris.

Polaris har ju också en förbättrad komprimeringsteknik för "frame-buffer", något som infördes i GCN1.2. Samma sak hände mellan Kepler (som fick sådan komprimering) och Maxwell (där effekten av komprimering ökade rätt rejält).

Sedan är det också känt att man förbättrat tekniken kring att tidigt detektera trianglar som inte kommer påverka den slutliga scenen. Tekniker som back-face culling har funnits sedan Voodo 1 korten, men här lär det finnas massor med heuristik och smarta algoritmer att ta till. Jämför med CPUer, "branch prediction" har ju funnits sedan ursprungliga Pentium, ändå är det något varje ny CPU-design fortfarande får små förbättring i.

Enligt det sättet att resonera har "IPC" i GCN1.2 (Fury X) minskat med 33 % jämfört med GCN1.1 (390X)...

Rejält förenklat består en GPU av fem delar

• shader-array

• TMU (texturenheter)

• ROP (raster & blending)

• geometri/vertex-array

• VRAM+cache

och en jämförelse av den första punkten (diskussionen var runt stream-processorer och CUDA-cores) genom att studera resultat som extremt mycket beror på balansen mellan alla dessa punkter (SweC prestandaindex) blir ju totalt nonsens.

Håller med om att det mest intressanta är hur de nya kretsarna kommer prestera i sin helhet, men den enda del det finns några rykten som har någon form av substans är första punkten. Min invändning här är att Maxwells shader-array är definitivt mer effektiv än Keplers, men det är inte nära några 25 %. Och ja, det kanske du anser är "detaljer" men en del av mitt arbete består i att göra extrema optimeringar och i dessa lägen ligger definitivt djävulen i detaljerna, så för mig är detta kanske långt mer självklart än för de flesta andra.

Många verkar helt missa hur extremt mycket Kepler och Maxwell skiljer sig åt i designen samt också hur mycket bättre balans Maxwell har av dessa enheter givet den riktning moderna spelmotorer tagit. Jämför vi 980 och 780Ti så har de väldigt snarlik kapacitet i shader-array, tittar man på AotS som är extremt shader-tungt så är fördelen där mindre för Maxwell än vad SweC prestandaindex skvallrar om.

En trend i nya spel är att man lägger på allt mer post-processing, många av dessa efter är ROP och bandbreddskrävande. ROP-kapaciteten i 980 är 175 % högre än 780Ti! Bandbredd kan vid första anblick tala för 980Ti, men mycket post-processing har hög datalokalitet vilket gynnar Maxwells större cache (både L1 och L2, en sak som nämns i whitepaper om Pascal är att L1 dubblas från Maxwell).

Textureffekter har däremot minskat i relevans då spel aldrig mindre använder olika former av "maps" (cube-maps, environment-maps etc), motsvarande görs idag med shaders och post-processing. 980 har faktiskt ca 40 % lägre kapacitet här än 780Ti. Maxwell är helt enkelt en långt bättre balanserad krets för moderna spel.

Det man kan notera när man jämför 390, 390X och Fury X är att balansen mellan delar blir allt sämre. 390 (och även 380) verkar vara de AMD kretsar som har bäst balans mellan de olika delarna. Från 390 och uppåt är ROP-kapacitet och geometri-kapacitet densamma, vilket syns i väldigt dålig effektivitet av all den extra shader-kapasitet som högre modeller lägger på.

Av de rykten som finns kring Polaris tycker jag att AMD fokuserat på helt rätt punkter, man pratar ju om rejält mycket bättre geomtrikapacitet t.ex. (något som t.ex. kommer säkerställa att Polaris hanterar Gameworks-effekter långt bättre). Så förväntar mig definitivt mer är 25 % högre prestanda med motsvarande antal stream-processorer som dagens kretsar då shared-array absolut inte är en flaskhalsarna i dagens GCN.

Därför jag inte riktigt reagerade på min missuppfattning om 2048 stream-cores, är övertygad att en GCN med 2048 cores där man biffade upp ROPs och geomtrikapacitet skulle vara snabbare i >90 % av fallen än dagens 390X (980 har 2048 "kärnor" med samma teoretiska kapacitet per "kärna" och MHz som GCN).

Det trevliga med att öka frekvensen är att allt utom VRAM-kapacitet skalar med frekvens (inklusive L1/L2, så även bandbredd skalar till viss del), så tror att en design där man kanske förenklar vissa delar för att möjliggöra högre frekvens inom en viss effektbudget är en bra idé. Dagens processer verkar väldigt effektiva upp till 1,5-2,0 GHz om man tittar på var ARM och Intel designer lägger sig när man uteslutande optimerar för perf/W, GPUerna borde därför kunna lyftas lite från dagens ~1,0 GHz nivå med positiv effekt (väldigt mycket spekulation från min sida dock).

Du menar att det varit signifikant värre än detta tidigare, notera 1,2 GHz resultaten med DX11?

Visa innehåll

Dold text

Tittar jag på de artiklar som testade "Omega" samt nu "Crimson" drivarna så handlar det i genomsnitt om förbättringar på 1-2 %, vissa titlar får någon procent lägre prestanda medan vissa ser upp mot 5 % högre (t.ex. GTA med Crimson). Visst rent matematiskt är det väl en förbättring, men knappast något som gör en relevant skillnad. Huruvida grafikkortet är "fabriksöverklockat" eller inte har en större påverkan än detta.

De som har Maxwell gen 2 fick vid något läge en drivare som ökade prestanda i spel som använder MSAA med 10-30 % via MFAA förutsatt att man innan använde minst MSAA x4 (vilket SweClockers alltid använder i sitt prestandaindex för de titlar som stödjer MSAA).

Ändå verkar konsensus vara att Nvidias drivare inte ger någon boost med tiden... Och just detta fall ligger det något i detta, allt färre titlar stödjer MSAA då det fungerar dåligt med många tekniker som nya titlar använder.

Och där kom klassiska finten à la Yoshman. Helt plötsligt så låtsas du som att vi pratade om prestandan i varje enskild shader. Vi pratade om prestandan i kretsen som helhet, och om man kunde förvänta sig 45% högre prestanda per shader. Då självklart genom bättre balans för att utnyttja befintlig beräkningskapacitet, alltså eliminering av flaskhalsar.
Du kom och sa dumheter som att Maxwell inte hade nämnvärda prestandaökningar över Kepler per Hz och shader, även fast prestandaskillnaden i praktiken är imponerande 25%. Och nu försöker du finta bort det hela genom att försöka lära ut GPUns beståndsdelar som om det ens vore på tapeten. Dina inlägg riktar sig som vanligt mer till läsande tredjepart än till den du citerar.

Frågan gällde om vi kunde förvänta oss Fury X-/980Ti-prestanda ur en krets med endast 2560 shaders. Du sa mer eller mindre att frekvenser är enda vägen dit och det skulle ju vara orimligt då deras fokus varit energieffektivitet. Jag poängterar att man mycket väl kan nå dit om man balanserar kretsen bättre eftersom det finns mycket outnyttjad kapacitet i dagens GCN. Jag pekade på förbättringarna i Maxwell över Kepler. Du fortsatte då prata om frekvens som om det vore enda förbättringen man kunde göra för att få ut mer prestanda trots "låga" 2560 shaders. Du förklarade övertaget 980 har över 780Ti med frekvenser, trots att jag poängterat att prestandan per Hz och Shader ökat med 25%. Poängen är alltså att AMD också kan ta bort flaskhalsar i övriga GPUn för att befintliga shaders ska få sträcka på benen. Och då kommer ditt svammel ovan.
Jag uppskattar inte att du i diskussion efter diskussion försöker finta på detta vis. Det är fult och lågt. Inte god ton och direkt förolämpande. Det tär på tålamodet helt enkelt.

@Aleshi: vi kan spekulera om prestanda för hela kretsen, det enda vi vet med någorlunda säkerhet är antalet shaders samt att geometridelen "är signifikant förbättrad". Ser personligen ingen mening med att hålla på med helt oinformerad spekulation, men ändå kul att teoretisera kring de saker det ändå finns någon form av information kring.

Tyckte också det var ett lämpligt tillfälle att belysa det faktum att GPUer består av mer än shaders. Av någon anledning är det alltid den aspekten ihop med minnesbandbredd som nämns i de flesta artiklar, Kepler och Maxwell visar med överdådig tydlighet hur stor påverkan övriga delar har på kretsen prestanda.

Sa inte att frekvens är enda vägen dit, sa att högre frekvens är väldigt trevligt då högre frekvens ökar kapaciteten för alla delar av kretsen förutom bandbredd mot VRAM. Påpekade också att Nvidia verkar köra samma variant en gång till (baserat på den faktiskt information som finns kring Pascal i deras whitepaper) med lite enklare delar som går att klocka högre. Hade sedan en stilla förhoppning att AMD går samma väg med Polaris, de har faktiskt ännu mer potential på denna punkt då de startar från en lägre frekvens.

Och faktum kvarstår att med "ditt" sätt att mäta "IPC" så får man ju resultatet att IPC minskar från 390 till 390X, minskar rejält från 390/390X till Fury-serien. Är inte det bakvänt?

Jaha! Så det var mot spekulerandet du argumenterade? Det var ju inte helt klart får jag säga. Tänk, det känns som att vad diskussionen handlat om ändras allt eftersom. Men tycker nog att du spekulerar precis lika mycket. Jag konstaterar bara att det inte är orimligt att en krets med 2560 shaders presterar som en annan med 4096 shaders när så pass mycket runt omkring är omarbetat. Det är inte direkt några spekulationer då jag inte sitter och försöker räkna ut något eller säga att något blir på ett eller annat sätt. Du tyckte jag hade fel men har inte riktigt kunnat förklara varför. Nu slirar du bara runt på ämnet som vanligt.

Ja och det behövdes? Du vet att jag är mer än väl medveten om detta. Det är liksom grunden för hela mitt argument att det inte är orimligt att nå högre prestanda trots "få" shaders.

Men det där har jag tagit hänsyn till. Ju snabbare kort desto mer begränsas prestandaindex av flaskhalsar. Det är därför jag valde att lägga mig vid ungefär samma prestanda med 980 och 780Ti och aktade mig för att jämföra 980Ti med 780Ti.
Det är förövrigt helt förväntat att skalningen mellan 390 och 390X inte är linjär. Och angående Fury så är det också uppenbart att kretsen innehåller en del kompromisser. Innan det var känt att man gjort sådana kompromisser så förväntades också högre prestanda.

EDIT: Råkade lägga till en EDIT i fel inlägg, den finns i inlägget nedan.

Och där låtsas du om att vi pratar om prestandan på CUDA-kärnorna allena igen. När vi pratar kretsen som helhet. Inser du inte varför jag tycker du diskuterar så fult?
Ja, Maxwell är bättre balanserad än Kepler. Det är lite det jag sagt hela tiden eller hur? Därför den presterar bättre. Och just därför man inte kan döma ut Polaris 10 jämfört med Fury X/980Ti enbart med antalet shaders som bas för sitt argument. Eftersom AMD varit så tydliga med att de adresserat just sådant. Fast du kör en halmgubbe och låtsas att vi pratar prestandan i enbart shaders för då kan du få rätt genom att säga det jag sa redan från första början.
Det var DU som enbart pratade shaders och angav frekvens som enda verkyg att påverka effektiviteten i en krets per shader. Det var JAG som poängterade att underutnyttjade shaders på grund av obalanserad krets ger AMD större möjligheter än vad nVidia hade med att nå högre prestanda per shader än tidigare genom att adressera flaskhalsar. Det är inte bara ROPs de förbättrat. De har adresserat mer än så. Effekten av detta får vi vänta och se. Men till skillnad från dina påståenden i början av diskussionen så tror jag att Polaris 10 kommer prestera avsevärt bättre sett till antalet shaders och frekvens än både Hawaii och Fiji. Eftersom dessa kretsar varit underdimensionerade på vissa övriga nyckelpunkter. Dels har vi det med ROPs, men dels tycks de ha krävt mer av CPU för att hålla sina beräkningsenheter matade. Där kan nog förbättringar i detas Command Processor och minnessystem hjälpa en hel del med.

EDIT:
Läs från början. Gruarn ifrågasatte möjligheterna i att Polaris 10 skulle nå den prestandanivån som det ryktats om i och med att det skulle innebära 45% mer prestanda för kretsen som helhet per shader. Jag poängterade att eftersom GCN i dagsläget har mycket prestanda som inte kan komma fram på grund av suboptimal balans så finns det gott om utrymme att öka den prestandan om man stärker upp svaga punkter. Pekade sedan på Maxwell, där vi såg optimeringar och frekvenser ge sammanlagt över 50% mer prestanda sett till antalet shaders. Då kan vi gott se 45% hos AMD när vi dessutom har en nodkrympning som hjälper till. Du har invänt mot detta utan att kunna framföra något argument till varför, du har pratat om frekvenser, för att sedan göra som du brukar, glida in på det jag sagt och låtsas att det är jag som sagt annat. Det är ganska ruttet.

@Gruarn: är väldigt olyckligt att termen "async compute" används då det inte alls beskriver vad det man faktiskt försöker lösa för problem. Överhuvudtaget verkar ordet "asynchronous" ställa till det, Microsoft har haft väldigt problem att förklara för folk att det "async" stöd man lade in i sin .NET plattform överhuvudtaget inte har något med parallellism att göra. Och missförståndet låg väldigt djupt, inte bara det man var slarvig med terminologin utan många missförstod konceptet så pass gravt att det under en lägre tid fanns en speciell kanal på Channel 9 som pratade om vanliga misstag, vilka buggar det resulterade i och hur man i stället borde gjort.

Två saker som är asynkrona har inget direkt beroende mellan sig på tidsaxeln. Det är allt, även första Voodo-kortet kan därför fullt ut stödja "async compute". Att man använder denna term beror gissningsvis på att AMD har pratat väldigt mycket om ACE (Async Compute Engines) som finns i GCN, man använder dessa för att implementera vad DX12 kallar "Multi-engine".

Det är dessa fall som ska lösas på bästa sätt

1. Asynchronous and low priority GPU work. This enables concurrent execution of low priority GPU work and atomic operations that enable one GPU thread to consume the results of another unsynchronized thread without blocking.

2. High priority compute work. With background compute it is possible to interrupt 3D rendering to do a small amount of high priority compute work. The results of this work can be obtained early for additional processing on the CPU.

3. Background compute work. A separate low priority queue for compute workloads allows an application to utilize spare GPU cycles to perform background computation without negative impact on the primary rendering (or other) tasks. Background tasks may include decompression of resources or updating simulations or acceleration structures. Background tasks should be synchronized on the CPU infrequently (approximately once per frame) to avoid stalling or slowing foreground work.

4. Streaming and uploading data. A separate copy queue replaces the D3D11 concepts of initial data and updating resources. Although the application is responsible for more details in the D3D12 model, this responsibility comes with power. The application can control how much system memory is devoted to buffering upload data. The app can choose when and how (CPU vs GPU, blocking vs non-blocking) to synchronize, and can track progress and control the amount of queued work.

5. Increased parallelism. Applications can use deeper queues for background workloads (e.g. video decode) when they have separate queues for foreground work.

Här finns en annan term som folk extremt ofta missförstår, "concurrent". "Concurrent" och "parallell" är INTE samma sak, alla parallella program är också "concurrent" men det omvända gäller inte.

Punkt 4 är inget att orda om, alla dagens GPUer har explicit HW för att hantera detta separat.

Den form av "async compute" man hoppades skulle ge en boost för dagens GCN är inte direkt med i denna lista, men man kan se det som en variant av punkt 3. Tanken är att köra flera oberoende beräkningar på samma prioritet och på så sätt få högre nyttjandegrad av existerande beräkningsresurser. Detta diskuterades en hel del på årets Games Developer Conference och konsensus var att detta är väldig svårt att få till, det kräver väldigt mycket undersökning och trial&error. Finns vissa specifika fall som kan ge upp till 5-10 % bättre prestanda, men finns också fall där prestanda sjunker om man kör "async compute". Vidare är skillnaden i resultat mellan olika GPU-modeller signifikant, så här långt har GCN1.1 (390/390X) sett störts potentiell boost, följt av GCN1.2 (Fury-serien). Trots att 380/380X också kör GCN1.2 ser man här sällan någon boost alls, vilket också är fallet för GCN1.0.

Rent tekniskt går det att implementera 1, 2, 3 och 5 i alla dagens GPUer. Även Kepler och Maxwell kan ju köra all kod som använder separat grafik och beräkningskö. Med undantag för punkt 5 kan man dock inte vänta sig att totala mängden arbete som utförs på något sätt ska öka och punkt 2 och 3 har ett problem på Maxwell/Kepler som kan manifestera sig i t.ex. VR då preemption bara kan ske vid draw-call boundaries på dessa kort.

"This extra latency – the waiting for a call to end – can really mess up very time-sensitive applications, such as virtual reality headsets. A 5ms delay could lead to a missed Vsync and a visible glitch in the real-time rendering, which drives some people nuts. By getting down to the instruction level, this latency penalty should evaporate, which is good news for VR gamers." (länk)

Med Pascal har man lägsta möjliga latensens, varje instruktion. GCN löser detta via den schemaläggare som finns i ACE, exakt granulatet är inte specificerad (och kan mycket väl variera mellan olika GCN-versioner) men den är mer än tillräckligt låg för att VR ska fungera lysande.

En av förbättringarna i Polaris är bättre "prefetch" av instruktioner. Om man lyckas väldigt bra på denna punkt (och andra punkter som minskar pipeline-stalls) så minskar också potentiella effekten man kan få av "async compute" som det idag används i spel. Däremot kvarstår alltid fördelen med låg latens, vilket är det VR behöver. Vad förbättringar i saker som schemaläggning och prefetch ändå kan ge är större vinst från punkt 5, av den information som finns idag borde både Polaris och Pascal relativt sätt vinna mer än tidigare kretsar av att nyttja denna punkt.

TL;DR compute preemtion är inte samma sak som ACE, men båda kan användas som byggstenar för att implementera användarfallen DX12 ser som relevanta för "multi engine" konceptet, vilket är det enda DX12 specificerar kring just detta.