AW: Xbox One X - Release und Preis: Ab 7. November 2017 für 499 Euro
[...]
Auf einem PC kann die CPU wegen Systemressourcenverteilungsroutinen nie so ausschließlich und zweckdienlich eingebunden werden, wie es auf einer Konsole möglich wäre.
Das mag prinzipiell stimmen, aber wie entscheidend ist so etwas in der Praxis?
Wie stark leiden die Frametimes oder gar FPS, wenn Hintergrundprozesse einen kleinen Time-Slice anfordern?
Bezüglich des Themas ist MS Gaming-Mode interessant, welcher teilweise ähnlich agiert wie die Reservierung unter Konsolen.
Ein paar Threads stehen exklusiv der Spiele-Exe zur Verfügung, zwei werden für Systemprozesse reserviert.
Ich habe nur gegenteilige Ergebnisse im Kopf, teilweise wollte Gamestar bessere Frametimes gefunden haben, aber bei anderen Publikationen und Usern gab es meistens negative Erfahrungen, vor allem wenn die CPU über wenige Threads verfügt, wird eben extrem viel Leistung verschenkt, wenn 2 Threads für Systemprozesse reserviert werden.
Kleine Time-Slices stören dagegen kaum.
Zudem ist uns Microsoft Strategie völlig unbekannt, denn CPUs müssen nicht in erster Linie Gaming beschleunigen. Bei einer GPU lastigen Entwicklung kann die CPU eine ziemlich unwesentliche Rolle spielen. Natürlich hängt es auch hier davon ab, was der Entwickler will (wie ich schon beschrieben habe, hat der Entwickler vollen Zugriff auf die gesamten Ressourcen, was bei einem PC nie so sein wird). API Overhead kann dabei aber auch entstehen, wenn ich zu viel will.
Auch hier stellt sich die Frage, wie groß der Unterschied in der Praxis ausfällt?
Immer mächtigere GPU-Pipelines und das auslagern von API und Runtime Aufgaben von der CPU zur GPU betrifft alle Plattformen.
Du solltest beides trennen, directX bleibt zum größten Teil HL-API, Mantle/Vulkan zuallererst LL-API.
Nein, denn DX12 ist genauso auf einer Ebene wie Vulkan, was die explizite Programmierung und die Grundmöglichkeiten betrifft.
Wer einen kleinen Überblick über die Unterschiede haben möchte, kann sich Dan Bakers Präsentation angucken, bezüglich der Vulkan Umsetzung von Ashes of the Singularity und den Unterschieden zu DX12:
Vulkan on Desktop Deep Dive - YouTube
Laienhaft zusammengefasst:
Die größte strukturelle Codeänderung die bei Vulkan nötig gewesen ist, kam vom Renderpass-Konzept.
Ansonsten gibt es gewisse Unterschiede, wo teilweise DX12 besser/eleganter spezifiziert wurde, teilweise Vulkan, nichts davon scheint wirklich ins Gewicht zu fallen.
- Vulkan unterscheidet zwischen Buffern und Texturen, DX12 ist es egal.
- Descriptor sets sind unter Vulkan praktisch wirkliche Objekte, während bei DX12 das einfach ein großer Pool mit einer Zuweisung darstellt.
- Beim Descriptor Layout gibt es die Regel, dass es mit den PSOs exakt übereinstimmen muss, ich verstehe hier nur, dass es bei DX12 mehr Freiraum besteht und etwas effizienter vom Platzverbrauch ausfällt, aber wirklich interessieren tut das nicht.
- Das Pipeline-Layout ist ähnlich gegenüber dem Root-Layout unter DX12, allerdings gibt es weniger strikte Regeln, weshalb man generell einfach aufpassen sollte nicht zuviele dynamishe Descritpors zu verwenden.
- Texture Uploading fällt ein wenig anders aus, da Vulkan gar kein Layout dafür definiert, dass muss der Entwickler selber erstellen.
- Resource Barriers fallen unter Vulkan expliziter aus, haben aber den Vorteil das die Entwickler den Layout-Mode ändern können, solange der Inhalt (oder Kontext?) nicht interessiert, bei DX12 muss man das nachverfolgen, was sehr nervig ausfallen soll.
Noch ein wenig zu SPIRV, der Bytecode fällt ~10-20 mal größer gegenüber D3D aus, also besteht bei jedem Entwickler das grundsätzliche Interesse das zu komprimieren.
Nach der Kompression mit SMOLV und LZ4 ist der Bytecode nur noch doppelt so groß.
Doch die besaßen sie, totzdem ist Denver nichts weiter als eine 64-bit ARM Architecture. Komischerweise besitzt sie nicht mehr Potential als ein Jaguarkern (die Jaguarkerne), der Takt ließe sich bei dem Design maximal auf 2,5 GHz bringen. Sie hat also nicht mal Vorteile beim reinen Leistungsvermögen oder Taktverhalten. Für die Konsolen war eine Androidsoftwarebasis (Kernel) kein Thema und ARM CPUs in Form von Denver, die als als ARM- und x86 CPU (Code Morphing Transmedia) geplant war, jedoch von Intel die nötigen Patente dafür nicht erhielt, konnte genau deshalb nicht in der Konsole platziert werden. Die Hersteller wünschten sich tatsächlich mehr Hardwarenähe zum PC und zu dessen Codebasis. Denver (Tegra) wird deshalb auch immer eine reine ARM CPU bleiben, die nach dem Befehlssatz von ARMvX-A 64-Bit programmiert werden kann. Dies war für Microsoft und Sony klar ein Ausscheidungskriterium.
Denver kam über ein Jahr später (Gegenüber dem Konsolenlaunch) und obwohl ARM v8 bzw. A64 schon Ende 2011 spezifiziert wurde und ARM Ende 2012 den Cortex A53 und A57 präsentiert hat, kam das ganze in der "realen" Welt erst sehr spät an.
Ich bin mir aber ziemlich sicher, wenn ARM64 und die nötige CPU-IP früher zur Verfügung gestanden hätte, die Entscheidung ob man ARM oder x86 nehmen soll, offen gewesen wäre.
sorry schreibe am Handy
