Nvidia Maxwell saknar viktig finess i DirectX 12 uppger Oxide Games

Var säger AMD att de har sämre stöd än Nvidia? de säger att ingen har fullt stöd.

Vilket är fel då Skylake har fullt stöd

I korthet låter det som att AMD har separat hårdvara för graphics och compute så att de går att köra samtidigt.
Med andra ord, i DX11 och tidigare så har det funnits hårdvara som legat och sugit strömming utan att göra någon nytta men som nu med DX12 faktiskt går att använda.

Medans i nVidia's hårdvara så har man inte haft extra som legat och varit oanvänt.

Står det någonstans i DX12 spec att async compute kräver att graphics och compute kör parallelt, eller är det enbart en programmeringsmodell som gör vissa saker enklare?

#15642863 är hittills det vettigaste inlägget jag sett i tråden.

Fast minimum floating point precision går bara ner till 16 bit... Inte ner till 10 bit...

Jag skulle också vilja veta om DX12 faktiskt säger något om detta. Vet att jag kommer gräva i detta själv när tids ges, vad jag hittade igår under en lite snabbare Google-övning var detta om "creating command lists" och detta om vilka typer som finns.

Här står det ingenting om att något av t.ex. typen D3D12_COMMAND_LIST_TYPE_COMPUTE ska kunna köras parallellt med saker av typen D3D12_COMMAND_LIST_TYPE_DIRECT. Vad man ska kunna göra är att köra saker asynkront/oberoende av varandra om de postas till olika typer av kommando-köer, det är inte samma sak som att det måste vara parallellt.

Folk blandar väldigt ofta ihop "concurrent programming" med "parallell programming", är en liknande sak här. Saker kan köras "concurrent" även om det bara finns en CPU-kärna och en CPU-tråd i systemet, det är ett sätt att resonera kring hur olika programflöden förhåller sig till varandra. Parallellprogrammering handlar däremot just om att effektivt köra saker på flera CPU-kärnor, det säger dock väldigt lite om hur man bör strukturera programmet.

Nu råkar det vara så att program som använder bra "concurrent programming" design tenderar att också kunna köras effektivt på flera kärnor, men finns definitivt undantag.

Tycker det ser ut att vara lite samma sak i DX12, med GCN är det fördelaktigt att köra jobb från olika köer parallellt då det passar mikroarkitekturen väldigt väl. Ser inget i MSDN dokumentationen som säger att det måste implementeras så. Det jag tror kan vara ett problem är att spelmotorer nog vill att saker som postas till "command queue" ska prioriteras över det som ligger i "compute/memcpy queues". Det är möjligt via HW med GCN tack vare ACE, ser inte att motsvarande HW stöd finns i Maxwell men fullt möjligt att man kan fixa ett sådant beteende via drivers.

En annan möjlighet här är att DX12 också tillåter något man kallar "multiadapter". Ett väldigt bra sätt att använda den iGPU som nästan alla har i sitt system skulle ju vara att köra "compute queue" saker som har lägre prio på iGPU och på så sätt säkerställa minimal latens i den GPU som jobbar med grafik!

Extremt bra skrivet och sammanfattat.

Grymt intressant att läsa, och väldigt smidigt med en sådan kompakt sammanställning (hade inte haft tid att göra det grundliga jobb du gjort med att läsa på här). Yoshman; du är utan tvekan Swecs största tillgång.

Nu förstår jag att du garanterat är extremt upptagen med ditt normala jobb, och att även om detta kanske är strakt relaterat så är det förmodligen ett intresse lite på sidan för nöjes skull (sådant som jag själv tycker är kul när man kan välja vad man vill läsa in sig på). Hade du någon gång haft tid så skulle du blivit en enormt stor redaktionell tillgång till en sajt som SweC om du haft tid/intresse för det.

Även om så aldrig sker så ser jag alltid fram enormt emot att läsa dina lagom djupa och väl förklarande (och för mig som inte är så insatt längre pga bla tid och annat, väldigt pedagogiskt bra förenklade) beskrivningar av objektiv fakta bakom intressanta tekniska lösningar. Rent nöje och grym underhållning för mig (som likt många på SweC fortfarande är en extremt nyfiken nörd längst inne).

Allt detta sagt så vill jag bara komma med några rena realpolitiska/taktiska spekulationer ifrån min sida som knyter an till det som du själv redan är inne på:

Har inga absoluta belägg för detta, men har precis som du fått till mig att DX12 (eller något liknande) troligen var på gång till redan första releasen/versionen av W8, men togs bort ifrån scopet under utvecklingen för att läggas i ett separat projekt och långt mycket senare W8-release/uppdatering. AMD (och även till viss del Nvidia) hade självklart sedan många år tillbaka fått förhandsinformation om att detta var på gång för W8.0, och därmed satsat resurser på att utveckla sin hårdvara i den riktningen. När DX12 (eller motsvarande) var "out of scope" för W8.0 så hade AMD, som satsat störst på detta med GCN, hamnat i en besvärlig situation. För att sätta press på Microsoft så beslöt de att ta fram ett eget alternativt API. För att göra detta till en hyfsat låg kostnad så samarbetade de med sin tekniskt nära partner i Stockholm, DICE. De valde att ta fram ett API inte allt för långt ifrån senaste XBox-API (som var betydligt mer paralleliserat och lite modernare än sin kusin på Windows-PC) som redan var hyfsat optimerat för GCN (som XB1 kör på). Detta var det som de sedermera döpte till Mantle. De hade nog aldrig tanken på att det någonsin skulle ta över och dominera marknaden, men det fick den hävstång och effekt som det avsåg. Detta satte fart och press på Microsoft att eskalera deras DX12-projekt, och se till att de prioriterade detta som en del av en planerad W8-uppdateringen (som sedermera blev det som vi känner som W10 idag, omdöpt av marknadsskäl då namnet W8 fått så dåligt rykte på marknaden). Önskad effekt uppnådd av AMD. Som en extra bonus så fick både AMD och DICE ytterligare testat och utvecklat bra mjukvara och drivrutiner för denna nyare typ av gränssnitt på Win/PC. Förutom denna värdefulla erfarenhet, och dess uppnådda press på Microsoft, så fick allt arbete de lagt ner även en direkt nytta i form av Vulcan i kommande versioner av OpenGL. Mycket bra PR och Goodwill för AMD, och dessutom en värdefull standard för att hålla Microsoft och deras dominans med DX/Windows lite i schack även framgent. Nu kan dock AMD äntligen "cash in" på deras långsiktiga arbete med GCN och Mantle genom att få nytta av detta i nya DX12-titlar och prestandamätningar i media - vilket vi nu ser resultatet av i artiklar som denna på SweC.

Men detta var ett lite OT-sidospår (utan något direkt värde i sig för ämnet för denna tråden), så skall nog stoppa där.

Ser hur som helst alltid fram emot alla dina välgrundade och elegant framställda tekniska förklaringar i aktuella ämnen.

Enligt Oxide så rapporterade drivrutinen stöd för async shaders men presterade så dåligt att Nvidia bad de att stänga av det. Så troligtvis saknas stöd i hårdvaran.

Sen så glömde du visst en rad.

"Därutöver finns sammanlagt nio kapacitetsnivåer (tiers), där AMD GCN 1.2 å andra sidan klarar mer än huvudkonkurrenten Nvidia Maxwell."

Med andra ord har varken de nyaste geforcekorten eller radeonkorten fullt stöd för Direct X 12. Men ännu så länge är det radeonkorten som har påvisat bäst prestandaskalning. Återstår att se vad som händer när fler titlar med stöd för Direct X 12 släpps.

Oxide tog upp saken med Nvidia och Nvida bad Oxide att ta bort funktionen, Nvidia sa alltså inte åt Oxide att se över sin kod.

Klart jag var där, du var ju också där, såg du mig inte?

Nej den bygger inte på rykten den bygger på betydligt mer än så, där bland annat ett uttalande från en utvecklare från Oxide väger tungt.
Men det spelar nog ingen roll för dig, du har verkar ha bestämt dig från att bortse från allt som talar för att detta stämmer.
Det känns inte som att det lönar sig att försöka argumentera med dig, jag har viktigare saker att göra, så jag låter bli.

Hade inte tänkt svara men.
Om du ser en nyhet som du tycker är lite tunn, varför inte klicka på länkarna som den refererar till.
tex denna.
http://www.overclock.net/t/1569897/various-ashes-of-the-singu...
Där har du en diskussion på 179 sidor om detta, det är något mer än en "enda fras".
Här har du vad utvecklaren från Oxide skrev.

Du verkar se saken i svart och vitt, vi vet inte till hundra procent om detta stämmer, eller om det går att fixa via en ny drivrutin men nog finns det fog att utreda vidare och kräva ett klargörande.
Att man hårdbevaker tillverkarna är inget vi konsumenter förlorar på, att det kan vara obekvämt för tillverkarna är inget vi behöver ta hänsyn till, det är våra intressen som vi skall försvara inte deras.