Skrivet av Enigma:
Ja för att det är en del av dess arkitektur? Du får det att på nått sätt låta orättvisst att använda funktioner som funnits tillgängligt i arkitekturen så många år. Skulle vilka säga att det är på tiden att AMD får glänsa med GCN som är så funktionsrik och stark som den är. Bägge korten körs under sin egen specifika codepath och Pascal körs redan väldigt nära sin kapacitet. Har det någonsin funnits ett spel från ID som inte vart nvidia-optimerat?
Vi har ju diskuterat SSE/AVX i denna tråd och är det något man lärt sig av att försöka utnyttja något via instrincs (som länge varit det enda sättet att använda SSE/AVX) är att
det är bräckligt, det som fungerar bra på CPU-modell A behöver inte nödvändigvis fungera bra på modell B även om båda stödjer all som används via instrincs
det låser fast programvara på en viss plattform
det försenar övergången till nyare tekniker inom samma område, SSE->AVX
På konsoler där man kodar mot en enda HW-specifikation är det självklart att utnyttja alla funktioner som finns, men PC-marknaden är extremt heterogen så en lågnivå optimering som är rätt för säg 390 kanske inte är en bra idé för 480. Rätt sätt att hantera sådana skillnader är att ha ett mellanlager (HLSL för DX11/12) som beskriver vad som ska göras och sedan översätter drivers detta till hur för varje specifik kort.
Om det nu finns saker som inte går att uttrycka väl i HLSL (eller SPIR-V för Vulkan) så gör fixen där. Är precis dit utvecklingen börjar gå för SIMD på CPUer där tekniker som OpenCL och SPMD gör det möjligt att beskriva dataparallella problem på ett sätt så man effektivt kan använda SSE, AVX, NEON (ARM) eller AltiVec (PowerPC). För x86 får man då fördelen att AVX kanske inte tar 10 år att slå igenom på bred front, för andra CPU-arkitekturer går det överhuvudtaget att använda källkoden och få något som är effektivt där. Det har visat sig att i majoriteten av fallen är den kod som genereras från sådana tekniker i majoriteten bättre än vad folk klarar av att skriva med instricts.
Att generera maskinkod är mycket bättre än direkt instrincs då man bara behöver optimera för varje specifik krets en gång, när man gör back-end till kompilatorn. Instrincs modellen kräver att man gör optimeringarna manuellt för varje krets i varje program/funktion.
Skrivet av Enigma:
AMD's GCN-GPU'er har inte ACE enheter eller instricts shaders functions för att inte användas och dom kan kompromisslöst (både vid lättare och mer extrema laster) beräkna grafik+data och har inte det problem som nvidia har med kontextbyte som arrangeras genom dess drivrutiner eftersom det inte finns någon hårdvara för det (inte i Pascal heller) vilket skapar hysteriska latenser, varav man inaktiverat det i Maxwell. Pascal låter istället dynamiskt allokera en del av dess shaderenheter till data och resten till grafik (låter för övrigt hysteriskt dåligt så länge du inte teoretiskt kan räkna på vilket förhållande för varje enskilt titel/tillfälle/scen som man måste allokera på förhand). Hos Pascal är det aktiverat endast för att man har DLB, vilket låter dom tappa mindre eller möjligtvis få lätt boost under lättare förhållanden där man tjänar mer på att offra ett kluster för compute än för grafik med andra ord. ID software vet om någon hur man gör spelmotorer... Async compute är aktiverat i Doom under non-AA eller 8x TSSAA. Rätt härligt att få grym kantutjämning samtidigt som FPS ökar markant, inte sant? Ska tydligen komma fler AA-lägen/modes som utnyttjar async compute med ännu fler optimeringar som kan köras som compute. Parallellism min vän, det är vad en GPU ska vara kapabel till.
Jo, dom har ju som sagt uppenbarligen problem med det och har haft ända sedan starten.
Nu är "ACE" rent tekniskt ett flashigt namn för "köer med potentiellt olika prioriteter". Vet inte hur "parallellt" det är i sig. Dagens GCN fyra ACE och två HWS, så 32 köer plus så många nu varje HWS har plus en grafikkö. Pascal har en grafikkö och 31 beräkningsköer. Så GCN vinner! Tja, Doom och antagligen alla DX12 spel som har "async shaders" använder i praktiken två av dessa. Grafikkön och en beräkningskö, mer behövs ju inte. Är i typiska GPGPU-beräkningar där det kan finnas poänger med massor med beräkningsköer, inte spel.
Grafikkort är främst kretsar som ska hantera dataparallella problem, så 99 % av all parallellism ligger där. Hur "parallell" kretsen är styrs då av antal "kärnor" (är inte kärnor i normal bemärkelse). I vissa lägen klarar inte kretsen av att hålla beräkningsenheterna sysselsatta, man får "bubblor i röret". Det enda "async shaders" tillför är en extra dimension att kompensera för dessa bubblor, hur mycket effekt man kan få av det beror på hur mycket bubblor som uppstår i normalfallet.
Här är det en nackdel med stor bredd för ju "bredare" krets man ha ju mer bubblor får man eftersom arbetet att dela upp data över alla "kärnor" och aggregera resultatet är seriellt, så Ahmdals lag sätter alltså en hård övre gräns på skalbarheten. Och vi ser exakt detta i att en krets av en viss generation får allt större boost av "async compute" ju "bredare" den är, detta gäller också Pascal där 1080 ser större boost i Time Spy jämfört med 1060 (Titan X lär se än större boost). Åter igen, att boosten blir större är ingenting bra, det betyder att man fått in mer bubblor i röret.
Ju bättre kislet är att mata sin dataparallella del med jobb ju mindre effekt är teoretiskt möjligt att erhålla från "async shaders". Vad det gäller parallellnivå på "async shaders" så är den i praktiken hårt satt till max två, försöker man köra mer än ett grafikjobb och ett beräkningsjobb parallellt så ser alla dagens GPUer lägre prestanda med "async shaders". Exakt vilka jobbpar som fungerar bra att kombinera måste man manuellt testa sig fram till (och det kan tyvärr skilja mellan olika GPUer). Detta nämndes bl.a. i denna AMD/Nvidia presentation på Games Developer Conference i våras.
Saker som kan paras är t.ex. något som är ALU-tungt (compute med hög cachelokalitet) med något som äter bandbredd (grafik, typiskt sådant som använder ROPs). Kör man två ALU-tunga jobb kommer man få cache-trashing, kör man två bandbreddstunga "stallar" de varandra då de slåss om VRAM-bandbredd.
Så vad det gäller "async shaders" är inte GCN mer "parallell" jämfört med Pascal. Pascal och även Polaris 10 har långt mindre bubblor i sina pipelines redan vid ett jobb jämfört med t.ex. 390X/Fury. Så att Polaris 10 och Pascal vinner mindre på "async shaders" jämfört med 390X/Fury är för att de är bättre designade på kiselnivå, inte för att de är "mindre parallella".
Tror ingen skulle säga att Bonnell (ursprungliga Atom) är "mer parallell" än Silvermont (andra generations Atom) bara för att den förra ofta såg upp mot 50 % vinst från Hyperthreading medan Silvermont presterar så nära sitt teoretiska max (båda kan maximalt köra två instruktioner per cykel) att det var meningslöst att ha HT.
Väldigt läsvärt blogg-inlägg kring detta ämne.
