Djupdykning i Asynchronous Compute

Tack! Bra genomgående artikel.

Rent tekniskt stödjer Maxwell async compute, men är 99 % säker att denna del av artikeln inte är korrekt

"Eftersom Maxwell exekverar beräkningsköer sekventiellt måste ett kontextbyte ske för att hårdvaran ska kunna växla från en uppgift till en annan."

Det är helt korrekt att Maxwell har problem med kontextbyte, men kontexten är i detta fall per SM och huruvida varje specifik SM ska plocka jobb från grafikkön eller från någon av de 31 beräkningsköer som finns. D.v.s. det finns HW-stöd för "async compute" även i Maxwell, men man måste statiskt dela upp SMs mellan att hantera grafikjobb eller hantera beräkningsjobb. Alla Nvidia kort sedan Fermi kan köra rena beräkningsjobb parallellt, innan Maxwell fanns däremot inget stöd att köra vissa SMs i grafik och andra mot beräkningar samtidigt. Först i Pascal kan man dynamiskt ändra om en SM jobbar med grafik eller med beräkningar utan att först vänta in en draw-call gräns.

Av allt att döma, i.e. vad GPUView visar i t.ex. Time Spy, är att dagens drivare inte längre försöker använda HW-compute köerna i Maxwell då det är hopplöst att generellt sett veta hur många SMs som lämpligen används till respektive uppgift. I stället serialiseras DIRECT (DX12s grafikkö) och COMPUTE (DX12s beräkningskö) till en enda HW-kö på Maxwell. Den skillnad du ser för Maxwell är i princip variansen i mätningen.

Fördelen med att göra så för Maxwell är att man nu slipper problemet vi initialt såg i Ashes of the Singularity där prestanda i praktiken blev lägre när COMPUTE kön användes, orsaken till detta är man man inte valt optimal fördelning mellan SMs som hanterar grafik kontra de som hanterar beräkningar. Nu kan utvecklare använda både DIRECT och COMPUTE oavsett GPU. Kör man Pascal eller GCN så körs jobben potentiell parallell. För Nvidias tidigare kort och för Intels GPUer serialiseras jobbet på sättet ovan vilket då ger samma prestanda vare sig man lägger allt på DIRECT-kön eller delar upp jobbet över DIRECT och COMPUTE.

Undrar hur många som förstår implikationen av "shader instricts functions"...

Den lila bubblan i mitten här borde förhoppningsvis höja ett par ögonbryn, varför finns den ens?

Den lila bubblan är borta är man kör med "shader instricts functions". Så endera var den värdelös eller så har något försvunnit...

De flesta som jobbat med Java känner nog till begrepp som "bytekod" och "write once, run anywhere".

DirectX bytekod bubblan är det som säkerställer att shaders skrivna med HLSL går att köra på alla GPUer som stödjer erforderlig DX-version. "Shader instricts functions" pajar detta, använder denna teknik låser man koden till den/de GPUer som råkar ha alla de instruktioner man använder via "instricts". T.ex. så kan inte Pascal använda det stöd för "async compute" som finns för GCN i Doom just därför man använder detta.

På en konsol är ju något som "instricts" självklart, maskinvaran är ju fixerad så är alla kunder kan ju fortfarande köra titeln. För PC verkar detta en väldigt dålig idé, finns en väldigt stor risk för att vissa spel börjar fungera riktigt illa om man har "fel" GPU. För AMD kan detta vara en pyrrhusseger då Nvidia har mycket större marknadsandel och långt mer ingenjörer som jobbar ihop med speltillverkare med optimeringar.

Detta verkar ha svarats på, av Robert från AMD.

En quote från reddit: https://www.reddit.com/r/Amd/comments/4kv6jv/gpuopen_shader_i...

"]Newbie__101

Is this something that will only affect new Polaris cards, or could my current card benefit (assuming developers do the optimizations, etc etc)?

Perhaps another way to ask is - are the tricks specific to different GCN versions, or will they be easy for developers to apply to a wide range of AMD cards (old and new)?

[–]AMD_RobertTechnical Marketing

As you probably know, GCN has evolved quite a lot over time. Four major versions, now. That means there are newer or different intrinsics to account for what has been added or changed over time. But, in general, we're mostly talking about core functionality common to the Graphics Core Next ISA that is now better exposed. This means applicability to any derivative part."

Så AMD verkar ha tagit med detta i sina beräkningarna.

Tack för mycket intressant och läsbar artikel trotts detta komplicerade ämne!

Rätt mig om jag har fel men känns som att vi har mycket att tacka konsolerna för utveckling av AC (Asynchronous Compute). Med konsolernas dåliga prestanda (jämfört med PC) har det mer eller mindre tvingat AMD att utveckla AC. För konsolerna ens ska ha en chans att överleva i 4-6år med samma hårdvara.

Skickades från m.sweclockers.com

Varför känner du dig blåst över 3.5+0.5? Du var ju medveten om det när du köpte kortet.
http://www.sweclockers.com/forum/trad/1378679-aterigen-ny-bur...

Det är väl inte mycket mer annorlunda än att man använder olika features inom dx 11. I de fallen frågar man drivrutinen vilket stöd det finns för olika funktioner inom versionen av dx och använder de som man har stöd för. Om man nu råkar ha stöd för dessa också, och har förkompilerad shaderkod för många olika GPU:er, så är väl detta inget konstigt? Jag gissar att det kommer finnas i högnivå-språk med verktyg för att förkompilera sådan shaderkod för olika GPU:er.

Det är utvecklarna som har önskat högre kontroll och nu har de fått det. De behöver inte inte använda det. De kan lika bra tuffa på utan det ifall de vill. De kan köra HLSL och DX11 i stället om de nu skulle vilja det. Det är inget måste att göra det här utan snarare en möjlighet.

Du måste inte använda hissen, du kan ta trappan i stället.

Tycker sista raden är en dålig analogi, för att ta något mycket närmare:

Ett program skrivit i ren C kan kompileras och köras på precis alla CPU-arkitekturer som har en C-kompilator (vilket i praktiken är alla).

Det "shader intrinsic functions" gör är lägger till möjligheten att skriva inline-assembler. Lägger man in en enda rad x86 assembler går det inte längre att kompilera programmet för någon annan CPU-arkitektur.

Analogin här i det AMD säger är: de funktioner som används är ju främst assemblerinstruktioner som fanns redan i 8086. Det säkerställer att man kan köra programmet på precis alla kretsar som kör x86, men går fortfarande överhuvudtaget inte att köra på ARM.

Det som ger lite Pandoras ask känningar i "shader intrinsic functions" är två två saker. Dels lär man använda funktioner direkt från PS4/XBO, vilket betyder att det bara fungerar på GCN. Det kanske större problem är att om Nvidia nu kör någon form av "tile based rendering" i Maxwell och framåt så lär dessa kretsar har rätt mycket funktioner som absolut kan användas på sätt som inte passar andra GPUer...

Finns idag tre sätt att distribuera shaders

1. man har en standardiserad kompilator vars utdata är någon form av byte-kod, varje drivare måste ha stöd för att översätta byte-kod till den ISA GPUn använder. Detta är hur HLSL i DX samt SPIR-V i Vulkan fungerar

2. man distribuerar källkoden och kräver att varje drivare är kapabel att kompilera detta direkt från källkod till underliggande ISA. Detta är hur GLSL i OpenGL fungerar. Rent praktisk har detta visat sig vara en dålig idé då tolkning av källkod är relativt komplext och med denna metod måste göras av alla drivare. Det introducerar också fler felkällor jämfört med att distribuera bytekod.

3. man levererar en BLOB för en specifik ISA direkt, detta fungerar ju utmärkt på konsoler och man slipper kostnaden för översättningssteget samt finns inga direkta standarder att följa utöver vad som dikteras av ISA

Utanför konsoler fungerar inte 3. till 100 % med mindre än att man gör en BLOB för varje tänkbar GPU ISA. Vad Doom gör är en kombination av 1. och 3. Problemet är att den som inte har en BLOB för sin ISA kommer alltid vara i underläge om det faktiskt finns fördelar med att använda "shader instricts functions". Förhoppningsvis ser Nvidia Doom som så pass strategiskt viktigt att man själva ställer upp resurser till en egen BLOB, tyvärr lär Pandoras ask vara öppen om det faktiskt ger en signifikant boost över att använda den generella vägen.

Rent tekniskt finns det ju inget som hindrar att man använder "shader instricts functions" på DX (skulle vara möjligt på alla versioner). Här hoppas i alla fall jag att Microsoft försöker hålla emot då denna teknik absolut har potentialen att fragmentera PC-spelmarknaden. Tror inte AMD har något emot detta, för varje 10 PC-spelare som går till konsol är det i genomsnitt 7-8 st som då byter från Nvidia till AMD.

Visst kan man som @Oaktree hävda att det öppnar upp möjligheter, finns absolut saker man kan göra i assembler som inte är möjligt i t.ex. C eller Java. Men skulle säga att man stänger än fler möjligheter, även här är modern C/C++ ett bra exempel på hur det borde hanteras.

Innan 2011 års C++ standard var det faktiskt inte möjligt att skriva ett multitrådat program i det språket utan att förlita sig på odefinierade beteende då standarden helt enkelt inte beskrev hur läsningar/skrivningar av data ska fungera när det sker från flera trådar. Under många år skrev man ändå massor med multitrådade program i C++, men man använde olika tekniker på olika OS och för synkronisering av data användes även olika funktioner på olika CPU arkitekturer (typiskt via kompilator-instricts eller inline-assembler). C++11 (och C11) gjorde det rätta, man lyfte blicken över funktioner hos enskilda CPU-arkitekturer och definierade vettiga funktioner för att ge ett modernt och intuitivt stöd för flertrådade program som körs på multicore CPUer. För vissa arkitekturer blev det mindre bra, t.ex. PowerPC och 32-bitars ARM medan det passade x86 rätt OK. ARM regerade på "rätt" sätt här, man såg till att Aarch64 (64-bitars ARM) blev en perfekt match till standarden och på pappret har man nu den ISA som bäst matchar de funktioner och definition som C, C++, Java m.fl. har kring garantier och krav som programmerare har i språken kring multitrådade program på multicore.

"Shader instricts functions" placerar grafik på den nivå "vanlig" programmering låg för 10 år sedan, känns rätt bakvänt då man sedan Glide m.fl. dog och ersattes med DX/OpenGL faktiskt haft en mycket bättre situation än "vanlig" programmering ur denna aspekt. Det kan mycket väl finnas brister i SPIR-V och HLSL, fixa problem i standarden då i stället för att använda proprietära lösningar. Att man kör detta i Vulkan känns extra irriterande med tanke på att 1.0 precis är släppt och AMD dragit ett stort lass där, vad är fel med SPIR-V?