Djupdykning i Asynchronous Compute

Trädvy Permalänk
Inhibitor
Registrerad
Dec 1999

Djupdykning i Asynchronous Compute

Efter några år under radarn började Asynchronous Compute beskrivas som ett trumfkort som var inbyggt i AMD:s grafikkort. Frågan är dock vad tekniken innebär, egentligen.

Läs hela artikeln här

Observera att samma trivselregler gäller i kommentarstrådarna som i övriga forumet och att brott mot dessa leder till avstängning. Kontakta redaktionen om du vill uppmärksamma fel i artikeln eller framföra andra synpunkter.

Trädvy Permalänk
Testpilot
Plats
Göteborg
Registrerad
Nov 2002

Tack! Bra genomgående artikel.

Trädvy Permalänk
Medlem
Plats
Kryptan/Lund
Registrerad
Nov 2004

Tackar.

CPU: I7 2600k @ 4.4ghz med Noctua NH-D14 GPU: GTX 1070 med Accelero Xtreme III @2 120mm cf-v12hp hydro dynamic @skitsnabbt. MODERKORT: Gigabyte GA-Z77X-UD3H. RAM: 16GB DDR3 PC19200/2400MHz@2133MHz. HÅRDDISK: Samsung 850 EVO 250GB SSD, Intel SSD 320 Series 160GB , 4 Mekaniska. MONITOR:1 Samsung S27A950D 3D" MONITOR:2 Samsung 2693HM 25,5" MONITOR/Tv:3 LG 47lv355n-ZB 47". Nätagg: Corsair Newton R2 1000W. Allt i ett Cooler Master CM Storm Stryker.

Trädvy Permalänk
Medlem
Registrerad
Jul 2011

Sånt här verkar rätt komplicerat och det är svårt att förstå, men bilderna gjorde så man hängde med lite bättre i alla fall! Tack Andreas!

sweclockers prestandaindex

Efter 10 kommer 11.

Trädvy Permalänk
Medlem
Plats
Stockholm
Registrerad
Sep 2010

Upplysande artikel
PC Close To Metal närmar sig alltså konsolerna förutsatt att utvecklaren satsar tillräckligt på det. Lägg till Shader Intrinsics och alla spel skulle kunna vara lika bra optimerat som Doom Vulkan.
Mantle var inte en så dåligt idé trots allt...

Trädvy Permalänk
Medlem
Registrerad
Jul 2011

En sak jag inte förstår riktigt är detta:

Dold text

Varför visar det ens någon skillnad på 980/970? Kan hända att det är förklarat i artikeln och möjligt att jag missat det bland alla tekniska termer. Det är ju inte mycket och inom felmarginalen men det stod ingenting om det i den artikeln jag hittade testet i så dom bör väl kört testet ett par gånger.

sweclockers prestandaindex

Efter 10 kommer 11.

Trädvy Permalänk
Datavetare
Plats
Stockholm
Registrerad
Jun 2011
Skrivet av ClintBeastwood:

En sak jag inte förstår riktigt är detta:

Varför visar det ens någon skillnad på 980/970? Kan hända att det är förklarat i artikeln och möjligt att jag missat det bland alla tekniska termer. Det är ju inte mycket och inom felmarginalen men det stod ingenting om det i den artikeln jag hittade testet i så dom bör väl kört testet ett par gånger.

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.

Care About Your Craft: Why spend your life developing software unless you care about doing it well? - The Pragmatic Programmer

Trädvy Permalänk
Hedersmedlem
Plats
Norrland
Registrerad
Jan 2002

Jag har sneglat lite snabbt, tänkte spara läsningen till lite senare. Bra med dessa djupdykningar och det är något jag gärna ser mer av på denna sida i framtiden.

Main: Corsair 350D, Ryzen 1700, 32GB RAM, 4,5TB SSD+HDD, GTX 1070 Phoenix GS, XB271HU, U2713HM, HP ZR24w
Spel: R5 Blackout, 6700K, 32GB RAM, 2TB SSD, 1080 Ti Phoenix GS, X34A + Oculus Rift
"HTPC": Ncase M1, 2700K, 16GB RAM, 0,75TB SSD lagring, GTX 1070 Mini, TV
Lenovo 700-15ISK: 6300HQ, 16GB RAM, 2,25TB lagring, 950m 4GB
Switch, Wii U, 3DS, GBA, PS4, PS3, PS2, PSP, PS Vita, Xbox One, Dreamcast

Trädvy Permalänk
Medlem
Registrerad
Dec 2004

Fantastisk läsning, tack så mycket!

i7-5775C @4GHz | GTX 970 G1 Gaming | 2x8GB DDR3-2133 C9 | Z97-AR
Define R5 Blackout | Noctua NH-U14S | EVGA G2 SuperNOVA 850W
Dell P2416D | G502 Proteus Spectrum | Vortex Pok3r RGB

Trädvy Permalänk
Medlem
Plats
Här
Registrerad
Jun 2010

Högintressant artikel och ger svar på en hel del man funderat på, tycker jag!

En jädra massa prylar.

Trädvy Permalänk
Datavetare
Plats
Stockholm
Registrerad
Jun 2011

Håller med andra i denna tråd: absolut fler artiklar modell "djupdykning"!

Care About Your Craft: Why spend your life developing software unless you care about doing it well? - The Pragmatic Programmer

Trädvy Permalänk
Medlem
Registrerad
Mar 2006

Antar jag förmycket om jag säger att AMD borde få + här då konsolerna kommer att köra på AMD hårdvara och de spel som optimeras för dessa kommer att rulla bättre på AMD GPUer...

I Övrigt bra artikel + i kanten

Trädvy Permalänk
Medlem
Plats
::1
Registrerad
Aug 2009

Fler djupdykningar, ja tack!

Gammalt nick: Darkst@r
Intel Core i7 860 @ 3,6 GHz/Noctua NH-D14|Asus GTX 970 Strix|2x2 GB Corsair Dominator DDR3 1600 CL8|Asus P7P55D Deluxe|Intel X-25M G2 80GB|Samsung 850 Pro 256 GB|Samsung Spinpoint F3 1TB|Windows 7 Home Premium 64-bit|Nanoxia Deep Silence 1|Corsair VX550|

Trädvy Permalänk
Datavetare
Plats
Stockholm
Registrerad
Jun 2011

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.

Care About Your Craft: Why spend your life developing software unless you care about doing it well? - The Pragmatic Programmer

Trädvy Permalänk
Medlem
Plats
Malmö
Registrerad
Jul 2010

Känner mig blåst som har lagt ner 3,8 på Nvidia's 970...
Först 500 mb minne och nu få reda på att det är med dagens teknik lika korkat som ett AGP kort var när PCI-express kom ut..
Va ju så nära på att köpa ett 390 istället...
"Nvidias Mark Aevermann bekräftar problematiken och menar att det åtgärdats med arkitekturen Pascal." Okej så ni ska ha mer pengar?!

Aja. Rolig läsning hur som!
Men jag blev väldigt chockad faktiskt. Trodde redan att alla grafikkort hade såpass bra jobbhanteringen som det beskrivs här.
Att förra generationens kort inte kunde avbryta vissa jobb eller prioritera / samarbeta bättre var otippat!

Trädvy Permalänk
Medlem
Registrerad
Jan 2013
Skrivet av Yoshman:

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?
http://cdn.sweclockers.com/artikel/bild/43883?l=eyJyZXNvdXJjZSI6IlwvYXJ0aWtlbFwvYmlsZFwvNDM4ODMiLCJmaWx0ZXJzIjpbInQ9YXJ0aWNsZUZ1bGwiXSwicGFyYW1zIjpbXSwia2V5IjoiMzZmMzlmY2MyMDI1NjdiZjkzMjBlM2QzODM0ZWQ3YzIifQ%3D%3D
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...
http://cdn.sweclockers.com/artikel/bild/43882?l=eyJyZXNvdXJjZSI6IlwvYXJ0aWtlbFwvYmlsZFwvNDM4ODIiLCJmaWx0ZXJzIjpbInQ9YXJ0aWNsZUZ1bGwiXSwicGFyYW1zIjpbXSwia2V5IjoiZTE2ZmY3NjM3NzU0MjFlMTgyMmUwMTMwNTM2NDliNDkifQ%3D%3D
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.

"finns en väldigt stor risk för att vissa spel börjar fungera riktigt illa om man har "fel" GPU"

Du får det att låta som "Shader Intrinsic Functions" skulle vara någon slags blockering.

Nvida kommer ju kunna använda sig av dom funktioner som finns i DX12 / Vulkan i vilket fall. Så varför skulle det fungera dåligt om man har annat märke av GPU?

Är ju inte så att AMD "Shader Intrinsic Functions", kommer köras på Nvidia hårdvara, då just dessa funktioner endast fungerar på GCN arkitekturen.
Nvidia har sina egna "Shader Intrinsic Functions" för sina arkitekturer.

Så ser inte att detta skulle paja något för Nvidia, dom använder sig av de funktioner som finns i DX12/Vulkan, det är ju inte så att AMD försöker stoppa Nvidia från att lägga till sina egna "Shader Intrinsic Functions".

Även Nvidia ser prestanda boost i DOOM Vulkan:
https://www.youtube.com/watch?v=ZCHmV3c7H1Q

OT: Intressant och bra djupdykning i ämnet.

Trädvy Permalänk
Hedersmedlem
Plats
Linköping
Registrerad
Apr 2004
Skrivet av Oaktree:

Är ju inte så att AMD "Shader Intrinsic Functions", kommer köras på Nvidia hårdvara, då just dessa funktioner endast fungerar på GCN arkitekturen.
Nvidia har sina egna "Shader Intrinsic Functions" för sina arkitekturer.

Risken är väl att spel använder de funktioner som är vanligast när det släpps och att man, om man sitter med något äldre (eller nyare (någon gång i framtiden)), får problem?

Trädvy Permalänk
Medlem
Registrerad
Jan 2013
Skrivet av Elgot:

Risken är väl att spel använder de funktioner som är vanligast när det släpps och att man, om man sitter med något äldre (eller nyare (någon gång i framtiden)), får problem?

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.

Trädvy Permalänk
Medlem
Plats
Göteborg
Registrerad
Jul 2016

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

Fractal Design Define C TG || ASUS ROG STRIX B350-F Gaming || Ryzen 5 1600@3.8Mhz || Noctua NH-D15 || G.Skill 16GB 3200MHz CL14 Flare X || Asus GTX 1070 Dual 8GB || SSD 180GB || HDD 5TB || HDD 3TB || Corsair RM750x || Acer 27" XF270HUA

Trädvy Permalänk
Medlem
Plats
Ålesund
Registrerad
Jun 2002

Först och främst, roligt med en djupdykningsartikel. Bra jobbat!

Sen så tycker jag att det känns ganska självklart att AMD har bättre DX12/Vulkan optimeringar i sina grafikkort. Men nVidia verkar ha bättre grafikkort i stort i dagens läge (energieffiktivitet, rå-prestanda etc). Det är synd att vi konsumenter inte kan få det bästa av båda världar, ett riktigt bra energisnålkt snabbt kort med bra optimeringar för framtidens beräkningstekniker...

Trädvy Permalänk
Medlem
Plats
Stockholm
Registrerad
Apr 2006

Tänkte på en sak, man talar om asyncront och sekventiellt i artikeln och där vissa asyncrona anropen körs samtidigt med andra anrop. Tycker det lite konstigt att syncront skulle utesluta samtida anrop som tycks reserveras för asyncrona anrop.

Skrivet av Firsov:

Känner mig blåst som har lagt ner 3,8 på Nvidia's 970...
Först 500 mb minne och nu få reda på att det är med dagens teknik lika korkat som ett AGP kort var när PCI-express kom ut..
Va ju så nära på att köpa ett 390 istället...
"Nvidias Mark Aevermann bekräftar problematiken och menar att det åtgärdats med arkitekturen Pascal." Okej så ni ska ha mer pengar?!

Aja. Rolig läsning hur som!
Men jag blev väldigt chockad faktiskt. Trodde redan att alla grafikkort hade såpass bra jobbhanteringen som det beskrivs här.
Att förra generationens kort inte kunde avbryta vissa jobb eller prioritera / samarbeta bättre var otippat!

Håller med om minnesmängden men det är ju bara att du ser över sweclockers prestandaindex så ser du att du fortfarande har bra valuta för pengarna, iaf vid köptillfället, allt tappar i värde. Däremot kostade mitt strix gtx 970 3.2-3.3k, inte 3.8k men du kanske köpte senare, kronan gick ner i värde där någonstans.
Men till hösten är det ändå uppgraderingsdags till 16 el 14nm för min del iaf.

Intel Core i7 8700K, MSI GeForce GTX 1080 Ti 11GB Gaming X, Samsung 960 EVO 1TB, MSI Z370 GAMING M5, Corsair 32GB (4x8GB) DDR4 3200MHz CL16 Vengeance, EVGA Supernova G3 850W

INTEL CORE I7 3930K 3.20GHZ 12MB S-2011, FRACTAL DESIGN MIDITOWER DEFINE R3, CORSAIR HX 1050W, ASUS RAMPAGE IV FORMULA, Asus STRIX GTX970, CORSAIR 16GB DDR3 DOMINATOR QUAD 1866MHZ CL9 (4X4GB) Ljud: ASUS Xonar D2X/XDT 7.1 | Elac 5.1 +förstärkare | Cambridge dacmagic plus | Astro gaming A40 | Sennheiser HD 650
You ask me if I have a god complex? Let me tell you something, I am god!

Trädvy Permalänk
Medlem
Registrerad
Jul 2011
Skrivet av Firsov:

Känner mig blåst som har lagt ner 3,8 på Nvidia's 970...
Först 500 mb minne och nu få reda på att det är med dagens teknik lika korkat som ett AGP kort var när PCI-express kom ut..
Va ju så nära på att köpa ett 390 istället...
"Nvidias Mark Aevermann bekräftar problematiken och menar att det åtgärdats med arkitekturen Pascal." Okej så ni ska ha mer pengar?!

Aja. Rolig läsning hur som!
Men jag blev väldigt chockad faktiskt. Trodde redan att alla grafikkort hade såpass bra jobbhanteringen som det beskrivs här.
Att förra generationens kort inte kunde avbryta vissa jobb eller prioritera / samarbeta bättre var otippat!

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...

sweclockers prestandaindex

Efter 10 kommer 11.

Trädvy Permalänk
Medlem
Plats
Stockholm
Registrerad
Jan 2006

Intressant artikel!
Mera sånt redaktionen!

AMD Ryzen 1600x, MSI B350 Mortar Arctic, Corsair lpx 3200, Sapphire Vega64 LC, Mbpro 15 Retina.

Trädvy Permalänk
Medlem
Plats
Digital medborgare
Registrerad
Aug 2004
Skrivet av Yoshman:

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.

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.

gfårs 1070. 3570K. 16 Gigabong RAM. Server, NAS, pi, steamlink, casts, nätverkssladdar, sega master system, massor av faptops, mus med 17 knappar, öronproppar, strumpor av ren bomull med elastiskt band för att hålla dem uppe. 2 barn, 1 fru, 99 problem.

Trädvy Permalänk
Datavetare
Plats
Stockholm
Registrerad
Jun 2011
Skrivet av kelthar:

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...

Care About Your Craft: Why spend your life developing software unless you care about doing it well? - The Pragmatic Programmer

Trädvy Permalänk
Hedersmedlem
Plats
Norrland
Registrerad
Jan 2002

Så, läst hela nu. Riktigt bra djupdykning, speciellt när folk från både AMD, Nvidia men även Crytek intervjuades. Synd att många utvecklare inte ville kommentera, det är ju vad dessa tycker som blir extra intressant.
Med tanke på att utvecklare fått och får de möjligheter och verktyg de ville ha och många studior gått in i Gameworks så förmodar jag att de är positiva till Async Compute men inte vill riskera Nvidias vrede.

I övrigt bra teknik som jag hoppas används mer på PC framöver. Fördelarna är många och ger fler möjligheter att få ur mer prestanda om man så vill.

Bra artikel som tidigare nämnts, hoppas på mer i samma klass från Andreas Eklöv.

Skickades från m.sweclockers.com

Main: Corsair 350D, Ryzen 1700, 32GB RAM, 4,5TB SSD+HDD, GTX 1070 Phoenix GS, XB271HU, U2713HM, HP ZR24w
Spel: R5 Blackout, 6700K, 32GB RAM, 2TB SSD, 1080 Ti Phoenix GS, X34A + Oculus Rift
"HTPC": Ncase M1, 2700K, 16GB RAM, 0,75TB SSD lagring, GTX 1070 Mini, TV
Lenovo 700-15ISK: 6300HQ, 16GB RAM, 2,25TB lagring, 950m 4GB
Switch, Wii U, 3DS, GBA, PS4, PS3, PS2, PSP, PS Vita, Xbox One, Dreamcast

Trädvy Permalänk
Testpilot
Plats
Göteborg
Registrerad
Nov 2002

@Yoshman: Förhoppningsvis kan du kanske svara på mina funderingar.

Om byte code är borttagen i shader-kompileringsprocessen behöver man då en code path för varje arkitektur t.ex. GCN och Pascal?
Blir det bättre, mer optimerat om det finns en code path för flera arkitektur-versioner som GCN 3gen och GCN 4gen samt GM & GP etc eller är AMDs och Nvidias arkitekturer bakåtkompatibla så att det enbart behövs en code path för den senaste arkitekturen och de äldre hakar på så gott det går?
Och sista frågan, Är det tänkt att det alltid kommer att finnas en code path som kan köras på alla dx 12 kort i någon slags kompatibilitetsläge eller kan ett grafikkort bli för gammal för att överhuvudtaget köras i dx12 för vissa spel; eller i värsta fall behöver emuleras?

Är inte insatt i de tekniska "konsekvenserna" där mer ansvar hamnar på utvecklarna som dx12 & Vulkan medför.

Trädvy Permalänk
Datavetare
Plats
Stockholm
Registrerad
Jun 2011
Skrivet av SolidReactor:

@Yoshman: Förhoppningsvis kan du kanske svara på mina funderingar.

Om byte code är borttagen i shader-kompileringsprocessen behöver man då en code path för varje arkitektur t.ex. GCN och Pascal?
Blir det bättre, mer optimerat om det finns en code path för flera arkitektur-versioner som GCN 3gen och GCN 4gen samt GM & GP etc eller är AMDs och Nvidias arkitekturer bakåtkompatibla så att det enbart behövs en code path för den senaste arkitekturen och de äldre hakar på så gott det går?
Och sista frågan, Är det tänkt att det alltid kommer att finnas en code path som kan köras på alla dx 12 kort i någon slags kompatibilitetsläge eller kan ett grafikkort bli för gammal för att överhuvudtaget köras i dx12 för vissa spel; eller i värsta fall behöver emuleras?

Är inte insatt i de tekniska "konsekvenserna" där mer ansvar hamnar på utvecklarna som dx12 & Vulkan medför.

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?

Care About Your Craft: Why spend your life developing software unless you care about doing it well? - The Pragmatic Programmer

Trädvy Permalänk
Hjälpsam
Plats
Karlskoga
Registrerad
Jan 2007

AMD Robert skall absolut inte förväxlas med Boxer Robert, AMD Robbert är IRL, medan Boxer Robert är virtuell.

Fel i artikeln, Nvidia kommer släppa nya drivrutiner till Maxwell som stödjer Async Shaders, kanske tom under detta decenium.

Nvidia Actively Working To Implement DirectX 12 Async Compute With Oxide Games In Ashes Of The Singularity
Nvidia Will Fully Implement Async Compute Via Driver Support
Relax, NVIDIA's Maxwell GPUs can do DX12 asynchronous shading after all
(Analyzis) Async compute is it true nvidia cant do it?
Nvidia Will Fully Implement Async Compute Via Driver Support, Oxide Confirms

Dessutom gör det ju försumbar skillnad, ID software har bara fått ut 20-30% högre prestanda.

Gav rubrikerna på länkarna.

AMD Ryzen 7 1700 | Vega RX 64 | https://valid.x86.fr/fgqnte | Stockkylaren | Bitfenix Whisper M 750W | Corsair 600T Graphite vit.
AMD FX8350 | Polaris RX 460 4 GB | https://valid.x86.fr/0q5pkm | Cooler Master V 700W | 32 GB ECC-Minnen.
HTPC | https://valid.x86.fr/ez1zxw |

Trädvy Permalänk
Testpilot
Plats
Göteborg
Registrerad
Nov 2002
Skrivet av Yoshman:
  • 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.

För att förstå konsekvensen bättre, blir då förutsättningarna och scenarion eventuellt följande på branschnivå?
1) Att "Egenutvecklare" d.v.s. spelutvecklare som använder egen motor behöver lägga mer energi och pengar på de ISA som de vill stödja än tidigare behövt; vilket skulle innebär en ytterligare möjlighet för nvidia och amd vardera att "hjälpa" utvecklaren så att deras motor körs mera "exklusivt bra" (menar inte exklusivt som totallåsning), som en ytterligare möjlighet att "hjälpa" likt som dagens drivrutinsoptimering, kod-optimering, gameworks m.m..
Kan tänka mig att flera populära titlar kommer få sponsring för denna dx12/vulkan "boost" exklusivitet för grafiktillverkarens PR.

2) Engine utvecklare som UE, Unity & CryE kommer behöva lägga mycket(?) energi & resurser på att stödja och underhålla flera ISA som deras kunder(utvecklare) kan tänkas rikta sig mot inkl. mobilsidan. Innebär att det då blir en konkurrensfördel för stora engine-utvecklare ju mer komplext och svårare det blir att optimera och underhålla spelmotorer gentemot egenutvecklare av motorer, där båda som konkurrerar strävar efter prestanda.

Kan detta helt enkelt leda till att det blir mer svårmotiverat att behålla inhouse engines som i sin tur leder till vissa programmerare antingen mister jobb eller kommer bli lite mera åt UE, CryE eller Unity "engine specialist"?
Fördelen blir då kanske att det blir enklare som "engine specialist" att byta arbetsplats om den nya kör med samma populära motor eller att befintliga programmerare fokuserar mera på spelets mekaniker, funktioner, verktyg för speldesignerna och buggar?

Är detta som kan ske vid segmentering av detta slag på sikt tro eller är detta orimligt tänkt?