Ich muss sagen ich bin froh, dass ich mir eine r9 390 statt einer 980ti geholt habe, weil ich mir aufgrund des gesparten Gelds in 1-2 Jahren eine 700€ Karte leisten kann. Da kann ich mir die Karte aussuchen, die die meisten Features nutzt und die beste Leistung hat.
DirectX 12: Maxwell soll Asynchronous Compute via CPU emulieren
- Ersteller PCGH-Redaktion
- Erstellt am
G
Gast1655586602
Guest
Das Problem waren doch eher die vielen unterschiedlichen Grafikmodelle mit unvereinbaren Architekturen. Sowohl GCN als auch die Geforce-Ableger sind nicht einmal untereinander kompatibel.
Microsoft hat aus dem Mischmach irgendwie eine API gezimmert und die Entwickler müssen das nun ausbaden. Diese Generation wird das "Chaos" also noch anhalten. Erst ab der FinFET-Generation der Nachfolger könnte es besser werden. Das hatten wir allerdings bei der DX9, 10 und 11 Version ebenfalls.
Ohne die Feturelevels hätte DX12 nie das Licht der Welt erblickt. Die Entwickler brauchen klare Richtlinien in den Programmierguides. Auch hätte MS den Unterschied zu DX11 nicht anders erkären können.
Die Alternative wäre gewesen auf die nächste Generation von Grafikkarten zu warten. Redmond musste aber unbedingt ein Zugpferd für ihr fragwürdiges neues Betriebssystem haben. Die Featureliste von Windows 10 ist sowieso seher kurz.
Aktuell blenden viele Meckerer genau diesen Punkt aus. AMD verliert quasi die Verbesserungen, die sowohl Leistung als auch Eyecandy bringen können. Nicht eine einzige GCN-Karte unterstützt Featurelevel 12.1 und AMD ist somit komplett abgeschnitten.
Mit Asynchronous Shader kann man nur die Auslastung der Shader optimieren. Beim Processing der Daten kann man eine Menge Tricks anwenden. Nvidia ist hier noch nicht aus dem Rennen. Sie sind ja in diesem Gebiet als Trickser bekannt.
Für die Geschichten aus 12.1 gilt allerdings die Art des Renderings. Hier hat man wenig Möglichkeiten als in jedem Spiel einen komplett anderen Renderpfad zu programmieren. Die zukünftigen Diskussionen hierüber werden sehr sehr zermürbend für uns alle (vorallem die Redakteuere!).
Erst kürzlich hatte ich ein Enwicklervideo zu DirectX12 gesehen in der genau diese drei DX12.1 Funktionen angepriesen wurden. Der Inhalt war sehr technisch, weshalb ich zuerst zuerst dachte, es wäre ein Knilch von Nivida gewesen, der die eigenen Produkte hervorhebt.
Dann war ich jedoch überrascht, dass es sich um einen Entwickler von Microsoft gehandelt hat. In den Ausführungen wurde gesagt, für alle neuen Microsoft Games werden die 12.1 Features als eigene Renderingpfade eingebaut.
Alle Karten ohne diese Unterstützungen bekommen einen Fallback-Pfad zu DX11.1 bzw. 11.3 (u.a. GCN, Kepler oder älter ). Es wurde dann viel über Fable geredet. Für mich ist das in dem Kontext dann der erste Titel. Leider finde ich das verdammte Video nicht mehr.
Locuza
Lötkolbengott/-göttin
Die Sache ist aber nicht ganz so simpel.
Dieser Bottleneck besteht bei jeder Hardware unterschiedlich stark ausgeprägt, bei AMDs GCN am krassesten.
Selbst wenn Intel und Nvidia verschiedene Kontexte gleichzeitig berechnen und einblenden könnten, wäre der Vorteil nicht so groß wie bei GCN, weil deren Idle-Phasen mit hoher Sicherheit kleiner sind (z.B. kleinere Thread-Groups, mehr Schedular).
Von der Software-Seite ist es natürlich auch nicht trivial oder allgemein ein Vorteil.
Man muss die erhöhte Parallelität explizit einbauen, überprüfen, synchronisieren.
Es ist wie bei einigen anderen Dingen auch, keine einfache Sache die Software und Hardware eindeutig nach etwas zu richten.
Selbst bei GCN kann eine suboptimale Implementierung von Async Compute zu schlechter Performance führen, wenn es zu Konfliktsituationen kommt, der Cache und die Logik von verschiedenen Workloads belastet wird usw.
Ein anderes Beispiel sind geometry-shader, praktisch geht man am Besten einen Bogen darum, was AMD Hardware angeht, weil AMDs Hardware sehr schlecht dort abschneidet.
Weil die Architektur nicht dafür konzipiert ist. Es ist schwer eine Architektur zu konzipieren die optimal für alle Anwendungsfälle geeignet ist.
Bei Nvidia läuft es etwas besser, aber immer noch relativ schlecht.
Intel ist der einzige Vendor, bei dem Geometry-Shaders anständig laufen.
Was sollen jetzt AMD und Nvidia tun? Ihre Architektur so umgestalten, damit Geometry-Shaders endlich vernünftig laufen?
Nicht so einfach, ohne wieder irgendwelche Kompromisse und komplexe Design-Entscheidungen zu treffen.
Ähnliches wird jetzt wohl auch für Intel und Nvidia gelten, keine einfache Sache Async Compute wie bei AMD zu implementieren.
Das zieht einen Rattenschwanz nach sich.
FL12.1 bitte.
DX12.1 kann ich nicht mehr lesen.
Ich Maße mir übrigens schon jetzt an, ohne zu wissen um welches Video es geht, dass die Aussage darin nicht war, dass alle neuen MS Games mit 12.1 Features ausgestattet werden.
Die Konsolen bieten die Features nicht und Conservative Rasterization und Tiled Resources Tier 3 sind kein Plug&Play, neben der Implementierung noch einen geeigneten Fallback zu entwickeln ist ein Haufen Arbeit.
Uns erwarten gerade mal so MS Spiele für PC, zusätzliche PC exklusive Features wären ein zusätzliches Wunder.
Zuletzt bearbeitet:
G
Gast1655586602
Guest
Die ganze Begriffsfindung bei DirectX12 über Featurelevels und Tiers ist ohnehin Banane. Wird sicher noch einige Zeit dauern bis wir unseren Jargon drauf haben. Ok, ich gebe zu mir ist es persönlich auch zu blöde immer FL12.1 zu schreiben. Für mich ist das optisch unästhetisch.
Alle DX12-kompatiblen Spiele müssen laut Microsoft schon einen "Fall-Back" haben. Das steht in den Guidelines. Für die Featurelevels wird das ebenfalls gelten. Der wichtige Unterschied war für MS wohl, dass alle PC Spiele von Microsoft eher auf DX12-FL12.1 setzen werden. Gleichzeitig könnten sich die Konsolen mehr in Richtung Asynchronous Compute bewegen. Das ist aber abhängig von den Entwicklern. Die Frage war dann noch offen, in wiefern die Konsolen die PC-Umsetzungen beerben werden.
Eine Situation wie diese könnte chaotischer nicht sein. Die vielen Exklusivtitel von Microsoft machen die Lager auch nicht übersichtlicher.
Soweit ich das beurteilen kann, ist Conservative Rasterization und Tiled (Volume) Ressources aber einfacher in der Implementierung als Asynchronous Compute. Bei Letzterem muss der Programmierer sehr tief in den Code und an alles denken. Passieren ihm Fehler oder bedenkt er etwas nicht, bricht die Leistung schlagartig ein.
Locuza
Lötkolbengott/-göttin
Das mit dem Fallback wäre eine relativ witzlose Sache, für jedes FL und Feature einen Fallback schreiben zu müssen, der Ausschluss von Hardware sollte eine offene Option sein (Wobei mich das sehr interessiert, was bei zukünftigen Games passieren wird, welche FL12.1 Features und darüber verwenden.)
FL12.1 spezifiziert aber nur zwei konkrete Features, welche sicher nicht den Standard bei zukünftigen MS-Spielen darstellen werden.
CR und TR3 und auch ROVs, wobei ROVs scheinbar einfacher umzusetzen sind, betreffen alle, wie Sachen konkret gerendert werden.
Man muss entsprechend direkt seine Rendering-Pipeline anpassen.
Async Compute ist auch nicht trivial, man muss Kommandos separat in eine Queue stecken, mit Synchronisationspunkten versehen und schauen, dass es am Ende noch ordentlich funktioniert.
Letzteres ist aber dank Konsolen eine Anpassung die quasi bei jedem mehr oder weniger auf der TODO-Liste steht.
FL12.1 spezifiziert aber nur zwei konkrete Features, welche sicher nicht den Standard bei zukünftigen MS-Spielen darstellen werden.
CR und TR3 und auch ROVs, wobei ROVs scheinbar einfacher umzusetzen sind, betreffen alle, wie Sachen konkret gerendert werden.
Man muss entsprechend direkt seine Rendering-Pipeline anpassen.
Async Compute ist auch nicht trivial, man muss Kommandos separat in eine Queue stecken, mit Synchronisationspunkten versehen und schauen, dass es am Ende noch ordentlich funktioniert.
Letzteres ist aber dank Konsolen eine Anpassung die quasi bei jedem mehr oder weniger auf der TODO-Liste steht.
Zuletzt bearbeitet:
G
Gast1655586602
Guest
Nein, du musst auf jeden Fall einen Fallback haben. Zum Glück ist das nicht so schlimm wie es sich erstmal anhört. Es besteht bereits ein Fallback für DX12 im Standard.
Die Abfrage lautet:
1. DirectX12.1 kompatibel -> DX12 Renderpfad FL12.1
2. nicht kompatibel mit FL12.1 -> Fallback prüfen (Punkt ab 3.)
3. DirectX12 kompatibel -> DX12 Standard (alle GPUs)
4. DirectX12 nicht kompatibel -> Fallback auf DX11.x
Das heißt letztendlich prüft das Spiel von vorne herein welche Spezifikation verwendet werden muss. Zukünftige MS-Spiele werden das sicherlich optional anbieten. Alle Games oder Engines, die FL12.1 noch nicht anbeiten, werden wohl den STandard DX12-Pfad nehmen. Hierzu zähle ich alle DX11-Games, die ein Upgrade auf DX12 via Patch erhalten.
Reine DX12 Titel werden garantiert alle Features unterstützen, es sei denn der entsprechende Entwickler entscheidet sich selbst dagegen. Aber warum sollte man es weglassen, wenn zukünftige Karten diese Featurelevel eh unterstützen werden?
Für die großen Engines machst du das genau einmal. Danach wird es nur noch gepflegt. Die meisten Entwickler sind mehr Designer als Programmierer. Viele von ihnen wollen vom eigentlichen Code nichts sehen. Der Großteil nutzt daher die üblichen Engines, in denen alles schon eingebaut ist.
Das ist noch garnicht sicher! Die Konsolenspiele nutzen Async Compute bereits teilweise. PC-Umsetzungen werden aber nicht automatisch umgesetzt.
Der Grund ist einfach:
-Nach momentanem Stand unterstützen weder Intel noch Nvidia(?) Asynchronous Compute in der Weise wie es AMD tut. Der Begriff ist übrigens eine AMD-Marketingerfindung und quasi ein GCN exklusives Feature seit der 7000er Generation, erstmals groß vermarktet seit der 290X.
-Es ist unwahrscheinilch, dass Entwickler 90% des Marketes ausschließen, nur um AMD zu unterstützen. Wie willst du deinem Management diese extra Kosten erkären?
-> Bis zu x% Mehrleistung für weniger als 10% des Marktes mit Kosten X wird immer nur eines finden: "ABGELEHNT"
Atent123
Volt-Modder(in)
Der Großteil des Marktes is inzwischen bei vielen Spielen aber auf Konsolen unterwegs und die nutzen GCN APUs und werden deshalb sher wahrscheinlich dieses Feature nutzen.
Ich kann mir vorstellen das das Feature bei den meisten Portierungen erhalten bleibt.
Locuza
Lötkolbengott/-göttin
Es ist "schlimm", weil es nicht so funktioniert wie du ausgeführt hat.
Es gibt kein DX12.1 oder Fallback auf DX11.x (andere Runtime).
Das einzige was es gibt ist DX12 und vier Feature-Levels 11.0, 11.1, 12.0 und 12.1, wobei auch die Möglichkeit besteht unter jedem FL zusätzliche Abfragen zu gewissen Features zu machen.
Man kann das FL11.0 abfragen + ROVs und dann eben ROVs mit einem FL11.0 Device verwenden.
FL12.1 verwendet man in dem Fall eig. nur um sich einen Haufen Abfragen zu ersparen.
Da muss man erst einmal definieren, was sind reine DX12 Spiele?
Wenn ein Entwickler aber alle Features in seinem Spiel von DX12 umsetzen will, dann kann man das mit den Fallbacks aber schön vergessen.
Ein Fallback zu ROVs würde so aussehen, dass es das Grafikfeature dann gar nicht gibt oder der Entwickler sich die Mühe macht einen anderen Algorithmus umzusetzen.
Das gilt dann natürlich auch für Conservative Rasterization, da gibt es keinen direkten Fallback.
Wenn es die Hardware nicht kann, muss der Entwickler schauen wie er das manuell löst.
Hardware auszuschließen wäre im Prinzip das einfachste, wenn gewisse Features einen integralen Anteil vom Spiel darstellen.
Da möchte ich nicht zweifelsfrei widersprechen.
Eine Garantie das die PC-Umsetzungen Async Compute behalten muss nicht 100% bestehen.
Async Compute ist kein AMD Marketingbegriff.
Ausschließen definitiv nicht.
Die Frage ist wie Entwickler das umsetzen werden.
Deaktivieren und dann läuft es auf allen, ohne große Gedanken oder für AMDs GPUs aktiviert lassen und für Intel und Nvidia ein Pfad ohne Async Compute?
S
Schaffe89
Guest
Dass so getan wird, als ob Asynchronous Compute jetzt ein AMD Marketingbegriff wäre, hat jetzt wirklich ne neue Qualität.
Warum kann man sich nicht wie Locuza auf technischer Ebene unterhalten und das bewusste Herstellerbashing außen vorlassen?
Jedenfalls finde ich es klasse hier auch mal etwas tiefergehendes lesen zu können.
Warum kann man sich nicht wie Locuza auf technischer Ebene unterhalten und das bewusste Herstellerbashing außen vorlassen?
Jedenfalls finde ich es klasse hier auch mal etwas tiefergehendes lesen zu können.
Locuza
Lötkolbengott/-göttin
Bei DX10 gab es auch kein Interface für Tessellation, viel glauben musste man entsprechend nicht.
Freakless08
Volt-Modder(in)
Du vergisst die Tier abfrage.
Tier 1, Tier 2 oder Tier 3.
1. DirectX12.1 kompatibel -> DX12 Renderpfad FL12.1
1.1 Tier 3 kompatibel -> DX12 FL12.1 Tier 3 Renderpfad
1.2 Tier 3 nicht kompatibel -> DX12 FL12.1 Tier 2 Renderpfad
2. nicht kompatibel mit FL12.1 -> Fallback prüfen (Punkt ab 3.)
3. DirectX12 kompatibel -> DX12 Standard (alle GPUs)
3.1 Tier 3 kompatibel -> DX12 FL12.0 Tier 3 Renderpfad
3.2 Tier 3 nicht kompatibel -> DX12 FL12.0 Tier 2 Renderpfad
4. DirectX12 nicht kompatibel -> Fallback auf DX11.x
Locuza
Lötkolbengott/-göttin
Es gibt keine globale Tier-Abfrage. (Danke an alle Journalisten die einem Thema praktisch nie nachgehen und ungefiltert die heiße Gerüchteküche verbreiten)
Ich weiß das du eig. Resource Binding meinst.
In Feature-Levels ist grundsätzlich alles enthalten, auch das Resource-Binding auf was du dich beziehst.
Z.B.
FL11.0/1 --> Resource Binding Tier 1
FL 12.0/1 --> Resource Binding Tier 2
Resource Binding kann man wie Conservative Rasterization oder ROVs oder viele andere Features optional unter jedem FL extra abfragen.
Entsprechend kannst du neben dem Feature-Level noch 5-20 weitere Sachen in so einer Auflistung mixen.
Ich weiß das du eig. Resource Binding meinst.
In Feature-Levels ist grundsätzlich alles enthalten, auch das Resource-Binding auf was du dich beziehst.
Z.B.
FL11.0/1 --> Resource Binding Tier 1
FL 12.0/1 --> Resource Binding Tier 2
Resource Binding kann man wie Conservative Rasterization oder ROVs oder viele andere Features optional unter jedem FL extra abfragen.
Entsprechend kannst du neben dem Feature-Level noch 5-20 weitere Sachen in so einer Auflistung mixen.
Zuletzt bearbeitet:
Es gab ein Interface des AMD Treibers welches man zur Erweiterung von DX10 ansprechen konnte(sprich alles ausser Tesselation lief dabei ganz normal über DX10). Für einen Entwickler ist das auch nicht anders als ein Sonderfeature in DX selbst anzusprechen.
Freakless08
Volt-Modder(in)
Nicht wirklich.
AMD Karten unterstützen FL12.0 und DX12 Tier 3,
Nvidia Karten unterstützen FL12.1 und DX12 Tier 2
Hier sieht man das die Tiers nicht an den FeatureLevel gekoppelt sind.
Zuletzt bearbeitet:
Da es nirgendwo eine Liste von sowas gibt lässt sich das kaum abschätzen. Fakt ist aber dass eine der möglichen Optimierungen auf XB360 ein LOD über Tesselation war. Trotzdem haben wir sowas nie auf dem PC gesehen. Das was dann mit DX11 an Tess. Verschönerungen kam gab es wiederum nicht auf der Xbox(galt oft sogar als ach so genialer Vorteil der "PC Masterrace"). Ergo ein kompatibles Hardwarefeature was trotzdem den Brückenschlag von der Konsole nicht geschafft hat.
Ähnlich dürfte es Async Compute ergehen wenn es nicht auf beiden Herstellern was bringt.
burnbabyburn2
Gesperrt
Du kannst auch Cuda oder OpenCL Code in einem DX Code einbinden, also quasi alles parallel laufen lassen ob es performant ist, ist ein andere Frage, daher erübrigt sich der Rest.
B
BlauX
Guest
Dort geht es um AS und das NV damit deutlich Probleme hat. Treiber hat dahingehend mit dem Problem nichts zutun, das behauptet NV nur....
Und die hohe Latenz, ungeeignet für VR, ebenfalls angesprochen.
https://www.youtube.com/watch?v=tTVeZlwn9W8&feature=youtu.be&t=1h19m01s
David Kanter - Betreiber von Real World Tech
Und die hohe Latenz, ungeeignet für VR, ebenfalls angesprochen.
https://www.youtube.com/watch?v=tTVeZlwn9W8&feature=youtu.be&t=1h19m01s
David Kanter - Betreiber von Real World Tech
Zuletzt bearbeitet:
B
BlauX
Guest
Wenn du David Kanter nicht kennst, hol es nach. Der erzählt kein BS.
P.S
Der Treiber ist nicht das Problem.
P.S
Der Treiber ist nicht das Problem.
Ähnliche Themen
