AW: AMD-Manager spricht über Konkurrenzkampf mit Intel: "Wir haben jetzt ein Jahr Vorsprung"
Da kommt es mir vor als würde der erste Satz davon eher auf dich zutreffen.
LowLeverl Apis sind genau das gegenteil von Platform unabhängig - es muss genau auf die hardware abgestimmt wwerden oder es läuft garnicht - was es sogar schon schwer macht den Code sowohl auf AMD, Intel und Nvidia GPUs laufen zu lassen - es sei den man beschränkt sich auf den Grundbefhelsatz womit dann auch die Vorteile nicht genutzt werden. Es gibt einen grund warum man von den früheren low-level APIs und Sprachen weggegangen ist: weil es ein derartig großer Aufwand ist.
Mit den highlevel APIs hat man auch einen entsprechend Umfangreichen und mächtigen Treiber der viele Aufgaben übernimmt und vom GPU Hersteller und nur diesem allein gewartet werden muss. Und da setzt dann AMD an - sie wollen mehr open Source und lowlevel APIs sehen denn das bedeutet das die Veranwortung nichtmehr bei ihnen liegt - sie müssenen keine komplexen Treiber mehr erstellen.
Eine kleine Grafik anzeigen ist mit allen Apis eigentlich elicht wenn man ein Framework hat.
Will ich die vorteile meiner AMD Karte nutzen muss ich mich schon mehr mit den APIs auseinander setzen. Will ich Vulkan nutzen heist das ich muss das ganez Speicher Managment, Texturverwaltung und so weiter.
Mit lowlevel APIs muss dann der Programierer sich um sachen wie die CommandQueues selber kümmern. Da kommt man dann schnell auf Probleme wie zB das auf einer Architectur das erstellen von MipMaps in eine Queue erfolgen muss, in einer anderen kann es aufgeteilt werden.
Zu wissen welche Architektur jetzt was macht/kann/benötigt fällt nunmehr dem programmierer zu. Für jede Engine muss dies dann seperat gemacht werden.
Dezeit wenn eine neue Architektur heraus kommt wird vom Hersteller ein entsprechend angepasster neuer Treiber released der dann die neue ahrdware auch für ältere Spiele nutzen kann.
lowLevel? Ja viel Spaß - wenn man nciht schon im vorhinein die nächste hardware kennt kann man sie auch nicht ausnützen. Um dann von neuen Features zu profitieren (zB delta color compression, hardware accelerated trilinear filtering etc) muss dann das Spiel gepached werden.
Und da sieht man dann schnell warum das Aufwendig ist:
AMD/Intel/Nivdia haben duzende Programierer die nur daran arbeiten die Treiber aktuell zu halten und neue Hardwarefeatures zu nutzen. Ein Team für einen Hersteller.
Wenn die das ncihtmehr machen - wer dann? Ja - 1 Team pro ENGINE. Schlimmer ncoh wenn man dann ncoh angepasste Engines oder Hauseigen hat.
Wenn man sich an die DX12 Spec hält, läuft der Code prinzipiell auf jeder Hardware, wie es der Theorie nach immer funktioniert und neue Hardware braucht entweder explizite Unterstützung für neue Feautures wie bei jeder API oder setzt das transparent hinter der API um, was mehrheitlich unter DX12 genauso funktioniert, wie unter DX11, da die ganzen Ressourcen, Buffer-Typen und Shader im Prinzip gleich funktionieren und abstrahiert sind.
Man arbeitet mit fetten PSOs, der Shader-Sprache und das ist alles nicht hardware spezifisch standardiziert und muss vom IHV Treiber und nicht dem Programmierer selber explizit für die Hardware übersetzt werden.
Die Vergleiche mit der Vergangenheit sind auch sehr krude.
Die Situation früher war wie im wilden Westen, es gab stark unterschiedliche APIs, keine abstrahierte Shader-Sprache wie HLSL/GLSL, sondern Shader Assembly Code, es gab viele Treiberbugs, unsaubere Spezifikationen, schlechte Conformance zum Standard, keine oder miese Tools für Entwickler etc.
Was man jetzt als "low-level" bezeichnet oder coding to the metal ist arg unterschiedlich, zudem was um die Jahrtausendwende getan wurde.
Aber DX12/Vulkan sind in ihrer Rohform natürlich keine APIs für schnelles und einfaches Programmieren, es sind explizite High-Performance APIs für Anwendungen die an die Grenzen von bisherigen APIs stoßen.
Auf der anderen Seite gibt es aber viele Bemühungen, dass ganze für Einsteiger und andere Anwendungsbereiche einfacher zu machen.
AMD bietet einen genrischen Memory-Allocator für Vulkan an, man muss sich dann nicht damit herumschlagen selber einen zu schreiben, sogar einen fett abstrahierten Layer mit Vulkan-EZ bietet AMD an, der die Programmierung ziemlich ähnlich gestaltet wie unter DX11/OGL:
V-EZ brings “Easy Mode” to Vulkan - GPUOpen
Das Feature DCC funktioniert übrigens transparent, die Hardware verwendet das Feature bei AMD, je nachdem ob die Anwendung für ihr Rendertarget ein UAV flag gesetzt hat oder nicht, die Geschichte unterscheidet unter DX11 und DX12 nicht voneinander.
AF kann Nvidias Treiber nach wie vor unter DX12 erzwingen, genauso wie höhere Auflösungen (DSR), FXAA, LOD-Bias etc..
Jeder Softwarehersteller, der sich die grafische und technologische Führungsposition auf die Fahne schreiben will, wird auf DX12/Vulkan umsteigen. Haben ja auch garkeine andere Wahl.
Bin jedenfalls mal gespannt, wann man was zu AnvilNext Engine mit DX12 hört, bei AC: Odyssey stand wohl mal kurz DX12 als Mindestanforderung drin. Entweder ein Omen, dass DX12 enthalten sein wird - oder nur ein Tippfehler
Präsentiert hat es Ubisoft schon letztes Jahr:
http://32ipi028l5q82yhj72224m8j.wpe...07/GDC2017-Moving-To-DX12-Lessons-Learned.pdf
Ob es endlich mit AC: Odyssey Einzug erhält?
The Division 2 hatte den gleichen Platzhalter, DX12 als Min und empfohlene Spec.
Sehr wahrscheinlich haben aber beide Spiele noch DX11-Support, The Division 2 sehr wahrscheinlich DX12, weil schon das erste Spiel besaß DX12-Support nach einem Patch und AMD kooperiert bei dem Spiel mit Ubisoft.
Wäre aber schon interessant zu wissen, ob AC auch DX12 implementiert.
Inwiefern? Mein letzter Stand war, dass die beiden Verfahren ziemlich ähnlich sind, zumindest, was die realen Maße der Einheiten betrifft.
Hoffentlich. Es wirken allerdings auch sehr viele "Kräfte" dagegen: die Entwicklungskosten, viele Leute nutzen immer noch Windows 7, die Entwicklungskosten, Nvidias Hohheit bei DirectX 11, die Entwicklungskosten...
Wie ist eigentlich die Abdeckung von Entwicklern mit LL API Know-How auf dem Arbeitsmarkt?
Zwei Artikel die es ausführlich darlegen:
IEDM 2017 + ISSCC 2018: Intel’s 10nm, switching to cobalt interconnects – WikiChip Fuse
IEDM 2017: GlobalFoundries 7nm process; Cobalt, EUV – WikiChip Fuse
Geht es nach Intels MTr/mm²-Metrik, welche verschiedene Eigenschaften eines Prozesses unterschiedlich gewichtet, dann hat Intel eine ~20% höhere Dichte als der 7nm Prozess bei GloFo.
TSMC hat einen etwas kleineren Contacted Gate Pitch als Glofo (54nm vs. 56nm), gibt aber praktisch die gleiche Größe für eine SRAM-Zelle wie GloFo an, deren Prozesse sollten nah beieinander liegen.
Intel erreicht nicht so Dichte SRAM-Zellen wie die Konkurrenz, aber deren Metalverbindungen sind kleiner, als bei der Konkurrenz und Intel kann die Transistoren dichter gruppieren, dank Contact-Over-Gate, was die Konkurrenz erst später selber verwenden möchte.
Ich weiß jetzt nicht, ob Intel auch als einziger Single-Dummy-Gates verwenden wird.
Intel wird wahrscheinlich auch noch Vorteile bei der Schaltgeschwindigkeit der Transistoren haben.
Aber Intels 10nm Prozess könnte erst 1 Jahr nachdem 7nm TSMC Prozess als High-Volume-Prozess zum Einsatz kommen und auch nachdem Release sollte Intels Vorsprung relativ kleiner ausfallen, als er aktuell ist.
--------
Bezüglich APIs würde ich generalisiert einfach die Zeit als größten Limiter ansehen.
Zwei bis drei Komponenten sind der größte Bremsfaktor.
1. Windows 7, wären alle bei W10 würde die Sache mittelfristig anders aussehen.
2 und 3 praktisch, die nötigen Engine-Anpassungen dauern mehrere Jahre, die Spieleentwicklung selber dauert auch mehrere Jahre und nicht immer sind Engine-Entwicklungen synchron mit Spieleentwicklungen.
Manchmal kann es einen viel moderneren Engine-Branch geben, aber die Spiele welche schon 2-3 Jahre in Entwicklung sind, können da nicht einfach wechseln und setzen erst auf die nächste Kadenz, dass kann dann dazu führen, dass Spiele mit guter API-Umsetzung dann 4-6 Jahre entfernt sind.
