Battlefield 1 PC: Tolle Optik, saubere Performance- erste Benchmarks der Release-Version

DirectX12 ist in den PCGH-Benchmarks wohl eher nicht der Bringer, weil der Faktor CPU fast komplett ausgeklammert wird. Mit einem übertakteten Achtkerner (i7-6900K @ 4,0 GHz) nützen die Vorteile von DirectX12 (oder die alten Vorteile von Mantle) eher wenig, die auf die Verringerung des Prozessor-Overheads ausgelegt sind. Von daher kann man sich fragen, ob die PCGH-Benchmarks in diesem Fall sonderlich praxistauglich sind. In gewisser Weise sind sie es natürlich - sie vergleichen die Leistung der Grafikkarten im Idealfall ohne CPU-Bottleneck; dass die Leistung und das Verhältnis DX11 zu DX12 aber deswegen nicht 1 zu 1 auf andere Systeme skaliert, sollte klar sein!

Laut DF ist die RX480 in DX12 leicht schneller als die GTX1060 in DX11:
Battlefield 1: GTX 1060 vs RX 480 DX11/DX12 Gameplay Frame-Rate Test - YouTube
Die nutzen für beide Tests einen I5 6600K
PCGH findet bei jedem Spiel irgend eine Szene in der Nvidia besser abschneidet!
 
ICH HABE ABER KEINE AMD GRAFIKARTE...

Dein Fehler. Denk dran, dafür hast du Aufpreis bezahlt. Nur weil du nicht mehr fps hast, heißt das ja noch lange nicht dass es keinen Vorteil gibt. Die CPU wird entlastet und hat entweder mehr Reserven, oder wird schlicht nicht so warm. Das war doch sicher einer der Gründe für die grüne Karte, weniger Abwärme und Lüfterdrehzahl?
 
Definitiv müssen Entwickler nun unter Vulkan und DX12 selber viel mehr erledigen und anscheinend haben die meisten Entwickler Probleme damit den Zugriff auf ihre Daten richtig zu verwalten, Seite 18:
http://32ipi028l5q82yhj72224m8j.wpe...oads/2016/03/d3d12_vulkan_lessons_learned.pdf

Was im Übrigen dazu führen wird, dass am Ende des Tages der Einfluss von Engines auf die Qualität und Performance nochmal weiter steigt. Es wird Engines geben, die die Ressourcen sehr gut verwalten, die Performance gut im Griff haben, und andere, die da eher Defizite haben (und ihre Stärke ggf. an anderer Stelle sind).

Ich bin ehrlich gar nicht so sicher, ob ich das gut finden soll, oder nicht. Vielleicht steuern wir auf ein Engine-Monopol zu?
 
Danke! Das ist die perfekte Abendlektüre um mitreden zu können, ohne selbst Programmierer sein zu müssen, damit man das Geschriebene überhaupt versteht.
"GDC" und "Siggraph" sind die besten Stichwörter, um alle möglichen Präsentationen bezüglich Rendering, Spieleproduktion usw. zu finden.
Als Laie kann es sein das man über die Hälfte gar nicht versteht, aber dank paar Bildern und etwas Text kann man sich immerhin ein grobes Bild ausmalen, was natürlich definitiv besser ist, als völlig orientierungslos zu sein.

Was im Übrigen dazu führen wird, dass am Ende des Tages der Einfluss von Engines auf die Qualität und Performance nochmal weiter steigt. Es wird Engines geben, die die Ressourcen sehr gut verwalten, die Performance gut im Griff haben, und andere, die da eher Defizite haben (und ihre Stärke ggf. an anderer Stelle sind).

Ich bin ehrlich gar nicht so sicher, ob ich das gut finden soll, oder nicht. Vielleicht steuern wir auf ein Engine-Monopol zu?
Ich würde es so sehen, ab einem bestimmten Zeitpunkt gibt es keine bessere Alternative, falls man die besten Ergebnisse erzielen möchte, entsprechend ist der Weg vorgegeben.
Wir sind ja sowieso schon an dem Punkt, wo fast nur noch "Mega-Engines" existieren, sei es intern bei den großen Publishern oder extern wie bei der Unreal Engine, Unity oder vielleicht noch der CryEngine.
Dazwischen existiert nur noch wenig.

Global gesehen wird es kein Engine-Monopol geben, aber es könnte sein das es immer weniger unterschiedliche Engines geben wird und nur noch die "Besten" überleben.
Bei EA hat die Frostbite-Engine die Unreal Engine 3 und fast alle anderen internen Engines ersetzt.
Bei Square Enix betreiben die westlichen Studios Kooperationen und teilen R&D miteinander aus, die Dawn-Engine ist eine stark modifizierte Glacier 2 Engine von Hitman.
Bethesda recycelt viel von der id Tech Engine.
Dann gibt es Ubisoft, die auch einige sehr moderne Engines in Entwicklung haben.
Die letzten Kandidaten könnten es ähnlich wie EA machen, immer mehr R&D-Sharing, bis nur noch eine große Engine für alle Studios übrig bleibt.
Am Ende haben wir vielleicht wirklich nur so 5 Publisher und 5 Giga-Engines, dazwischen etwas Krimskrams und fertig.
Ist das schlecht?
Aus technischer Perspektive würde ich eher nein sagen, es liegt primär am Content und dem Art-Design wie ein Spiel aussieht, wenn es dank dem riesigen R&D Budget gut läuft, dann freut es mich als Anwender natürlich.
 
Zuletzt bearbeitet:
Was im Übrigen dazu führen wird, dass am Ende des Tages der Einfluss von Engines auf die Qualität und Performance nochmal weiter steigt. Es wird Engines geben, die die Ressourcen sehr gut verwalten, die Performance gut im Griff haben, und andere, die da eher Defizite haben (und ihre Stärke ggf. an anderer Stelle sind).

Ich bin ehrlich gar nicht so sicher, ob ich das gut finden soll, oder nicht. Vielleicht steuern wir auf ein Engine-Monopol zu?
Gerade das geht aus dem Link von Locuza nicht hervor.

Zudem gibt es seit jeher Engines die effizienter als andere sind. Das hat wenig mit DX11/12 zu tun. Die Frostbite stellt auch unter DX11 viele andere DX11 Engines in den Schatten.

Auch unter DX11 ist seit Ewigkeiten klar, dass die Zeiten, wo man für ein Spiel eine Engine schreiben kann, ohne dass das Jahre und Milionen kostet, vorbei sind. In Zukunft wird alles über große Lizenzengines und modulare Middlewares (Physik, Vegetation, Beleuchtung etc.) laufen, die sich dann jedes Studio nach Bedarf zusammenlizenziert. Das wusste Crytek schon 2006.
 
Gerade das geht aus dem Link von Locuza nicht hervor.

Zudem gibt es seit jeher Engines die effizienter als andere sind. Das hat wenig mit DX11/12 zu tun. Die Frostbite stellt auch unter DX11 viele andere DX11 Engines in den Schatten.

Auch unter DX11 ist seit Ewigkeiten klar, dass die Zeiten, wo man für ein Spiel eine Engine schreiben kann, ohne dass das Jahre und Milionen kostet, vorbei sind. In Zukunft wird alles über große Lizenzengines und modulare Middlewares (Physik, Vegetation, Beleuchtung etc.) laufen, die sich dann jedes Studio nach Bedarf zusammenlizenziert. Das wusste Crytek schon 2006.

Muss nicht unbedingt sein. Siehe Witcher 3. Das Studio ist ja angeblich relativ klein und trotzdem haben sie ne Engine auf die Beine gestellt, die mehr als konkurrenzfähig ist. Vielleicht rein technisch nicht absolute Oberklasse, aber zusammen mit der hohen Dichte an gut gestaltetem Content im Spiel ist das alles sehr ansehnlich. Und effizient läuft das Spiel ja scheinbar auch (siehe CPU Tests von PCGH). Für ne riesige open World schon ne beachtliche Leistung.

Wenn CD Project das schafft, dann schaffen das andere Entwickler auch. Mit DX12 ist das Potenzial, sich von der Konkurrenz abzusetzen ja noch höher. Vielleicht kommt irgendwann ein Studio mit ein paar genialen Programmierern aus nem Loch gekrochen und präsentiert uns das nächste "Crysis". Unmöglich ist das sicherlich nicht. Trotz der Effizenz von Frostbite und co.
 
Läuft das Spiel FPS Mäßig ein bisschen besser als in der Beta ?. Ich hatte auf der map in der Beta immer zwischen 60-80 fps. Habe Angst das es 50-60 sind je nach map in der finalen Version.
 
Wenn doch nun die Umsetzung entscheidend ist und nicht der IHV/API - warum sollte DX12 dann der große Renner sein?

Ist dann nicht eher entscheidend, wie gut/schlechter der Entwickler ist und wie gut/schlechter die API auf sein Spiel passt?


Ja, genau das passiert.

Also viel Spaß mit den dann zukünftig unpatchbaren Konsolenports :wall:
Weil sich viele Entwickler genau das gewünscht haben, mehr Kontrolle, eine höhere Transparenz darüber was geschieht und am Ende mehr Effizienz.
Das hängt dann auch mit mehr Verantwortung und Arbeit zusammen, aber es ist offensichtlich das eine API von 2009 nicht auf Dauer halten kann.

DX11 ist zu alt und ineffizient, um noch weitere 10 Jahre Bestand für moderne Software zu haben, auch weil DX12/Vulkan eine höhere Performance pro Watt ermöglichen können, dass interessiert viele PC-Nutzer aktuell nicht, aber unter Smartphones und Tablets kann hier viel gewonnen werden.
Und auch in der Zukunft kann das für "klassische" Geräte eine Rolle spielen.
Wir haben schon jetzt immer dynamischere Regulierungsmethoden, GPUs und CPUs haben teilweise "Bis zu" Taktraten, die davon abhängen, wie viel Strom konsumiert wird und wie heiß der Prozessor wird.
Wir haben SoCs, wo CPU und GPU sich das thermische Budget und den Verbrauch teilen müssen, hier kann dank effizienterer Software auch Performance gewonnen werden.

Aktuell geschieht der Übergang, wo die ersten Umsetzungen entwickelt werden, Erfahrung gesammelt und das ganze Ökosystem reifer wird
Teilweise sind es auch einfache Hürden, die man "einmal" überwinden muss und dann hat man auch fertig.
Es ist nicht so, als ob man sich bei allen zukünftigen DX12/Vulkan Spielen jedes mal aufs neue die Finger brechen muss, bevor etwas läuft.
 
Zuletzt bearbeitet:
Ja, genau das passiert.

Also viel Spaß mit den dann zukünftig unpatchbaren Konsolenports :wall:

Aha... weshalb sollen die Spiele plötzlich unpatchbar sein?
Das hat doch gar nichts mit den Treibern der Grafikkarten zu tun.
Die Karten werden noch immer über einen eigenen Treiber angesprochen, der eben die API Befehle umsetzt.
Nur ändert sich eben etwas am Ort der Optimierung.

Durch welche Veränderung bei DX12 sollen die Spiele diese Wandlung denn erleben?


Edit: kleine Änderung der Struktur, Ergänzungen
 
Zur Zeit ist DX12 DEUTLICH langsamer als DX11 !
Nicht nur in Battlefield 1

Das ist das einzige was für mich wichtig ist !
DX12 ist der Grund für den wechsel auf Win10 !

Es gibt quasi kein Gamerleben ohne DX12 ..auch das ist zur Zeit nicht haltbar !
 
DX12 wird sich durchsetzen, nur wird es länger dauern als gedacht, vielleicht auch erst als DX13. Wieso sollte ein Entwickler heutzutage voll auf DX12 setzen und somit die Hälfte der potentiellen Windows Kunden aussperren? Mit der Zeit werden wir auch eine auf DX12 optimierte Frostbite Engine sehen, die 15% schneller als unter DX11 ist, nur nicht heute oder 2017. Hätte MS damals DX12 für Win 7, 8 und 10 released würde sich alles schneller entwickeln.

Und irgendwann werden auch die Verweigerer Win 10 installieren. Ich bin auch von Win 10 und DX12 enttäuscht, aber früher oder später wird man umsteigen müssen, warum also nicht jetzt.
 
Zuletzt bearbeitet:
DX12 wird sich durchsetzen, nur wird es länger dauern als gedacht, vielleicht auch erst als DX13. Wieso sollte ein Entwickler heutzutage voll auf DX12 setzen und somit die hälfte der potentiellen Windows Kunden aussperren? Mit der Zeit werden wir auch eine auf DX12 optimierte Frostbite Engine sehen, die 15% schneller als unter DX11 ist, nur nicht heute oder 2017. Hätte MS damals DX12 für Win 7, 8 und 10 released würde sich alles schneller entwickeln.

Und irgendwann werden auch die verweigere Win 10 installieren. Ich bin auch von Win 10 und DX12 enttäuscht, aber früher oder später wird man umsteigen müssen, warum also nicht jetzt.

Entwickler werden DX12 nutzen, weil die XBox ebenfalls ein DX12 Derivat benutzt.
 
Laut DF ist die RX480 in DX12 leicht schneller als die GTX1060 in DX11:
Battlefield 1: GTX 1060 vs RX 480 DX11/DX12 Gameplay Frame-Rate Test - YouTube
Die nutzen für beide Tests einen I5 6600K
PCGH findet bei jedem Spiel irgend eine Szene in der Nvidia besser abschneidet!

Digital Foundry misst ja auch den Singleplayer... (!!!) Den du dann mit unseren Multiplayer-Messungen vergleichst:ugly: Das sind ja auch zwei verschiedene Paar Schuhe ;) Da sieht die Performance nunmal etwas unterschiedlich aus. Und das kann auch hinkommen, im Multiplayer ist die RX 480 ziemlich genauso schnell wie die GTX 970, während sie im Singleplayer ein gutes Stück schneller ist (die GTX 970 ist ungefähr auf dem Level der R9 390 - in Full HD zumindest). Die GTX 1060 hab ich im Singleplayer noch nicht messen können, aber sie liegt im Multiplayer rund 11 % vor der RX 480 und wenn ich das aufrechne, landen die RX 480 und GTX 1060 auf einem Punkt...

EDIT: Wobei es interessant ist, dass die RX 480 dort mit DX12 zulegen kann und auf unserem System und mit unserer Testszene Performance verliert... ich werd mir Morgen mal das Einleitungslevel ansehen und schauen, ob ich das reproduzieren kann. Vielleicht eine CPU-Geschichte (unsere Szene ist deutlich grafiklastiger als das Intro-Level, und die Test-CPU ist natürlich deutlich stärker bzw. hat deutlich mehr echte Kerne zur Verfügung), aber ein bisschen seltsam ist das schon...


Gruß,
Phil
 
Zuletzt bearbeitet:
Super dass es auf dem PC so toll läuft, auf den Konsolen hat es Dice anscheinend nicht wirklich geschafft, auf der Xbox One haben wir eine sehr instabile Framerate und die Auflösung ist stellenweise unter 720P:
Battlefield 1 Conquest Xbox One Frame Rate Test (Pre-Release) - YouTube

Die PS4 Version wird aufgrund der niedriger getakteten CPU wohl noch schlechter laufen.

Dabei scheint das Spiel sowieso grafisch sehr beschnitten.

Leadplattform ist wohl ganz offensichtlich der PC.
 
[...]
EDIT: Wobei es interessant ist, dass die RX 480 dort mit DX12 zulegen kann und auf unserem System und mit unserer Testszene Performance verliert... ich werd mir Morgen mal das Einleitungslevel ansehen und schauen, ob ich das reproduzieren kann. Vielleicht eine CPU-Geschichte (unsere Szene ist deutlich grafiklastiger als das Intro-Level, und die Test-CPU ist natürlich deutlich stärker bzw. hat deutlich mehr echte Kerne zur Verfügung), aber ein bisschen seltsam ist das schon...

Danke. :daumen:
Stieß ich mich auch etwas dran. BTW, nicht daß ich Dir noch Arbeit aufhalsen will, (aber) – interessant vielleicht auch der Blick zu Sweclockers mit "nur" 8GB RAM Systemspeicher...
Snabbtest: Battlefield 1 i DirectX 11 och DirectX 12 - Test

Viele Grüße & gute Nacht
Thomas Schmidt
 
Zuletzt bearbeitet:
Moment! "Viele"? Doch wohl eher "manche". Oder gar eher "wenige".
Ja, viele oder wurden DX12 und Vulkan in der Mittagspause von zwei Geeks spezifiziert und irgendein Nerd im Keller von Googel meinte, hey cool, wie wäre es wenn wir das in die neuste Version von Android packen?
DICE, Oxide, Eidos Montreal, Epic, Unity, Crytek, Chris Roberts Space Industries, id tech, Arkane Studios, Crystal Dynamics, Nixxes usw.
Bei jedem sitzt ein oder mehrere Engine-Architekten, welche dafür aktiv geworben haben und/oder es aktuell umsetzen bzw. werden.

Das heißt aber noch lange nicht, dass sich "viele" Entwicklern gern Gedanken darüber machen wollen, ob ihr Spiel auf Architektur X oder Y läuft. Eher im Gegenteil. Nicht ohne Grund gibt es fest definierte APIs. Damit Entwickler A, der Ahnung von der Architektur hat, seinen Teil der Arbeit macht und Entwickler B, der eine Videoengine programmieren möchte, seinen Teil. Und nicht B Beides machen muss.
DX12 ist eine fest definierte API, die Entwickler müssen nicht für jeden IHV einen angepassten Renderpfad schreiben, Oxide hat z.B. nur einen für alle IHVs.
Andere setzen auf spezielle Anpassungen pro IHV, andere tun dies auch schon lange unter DX11.
Jedem dem das zu technisch ist, kann weiterhin die älteren APIs verwenden oder lizenzierte Engines/Middlewares verwenden.

Frage: Warum hat man überhaupt jemals angefangen HighLevel Programmiersprachen (C++ z.B.) zu entwickeln, wenn doch Assembler viel effizienter ist?
Weil die Komplexität und Lesbarkeit einfach zu schlecht im Vergleich ausfällt und man auch viele Vorteile bezüglich der Portabilität genießen kann.
DX12 ist bei weitem nicht so ein krasser Vergleich.

Einfach: Weil es Vorteile hat. So zu tun, als wäre DX12 jetzt die Quadratur des Kreises und einfach nur per se "besser" ist Quatsch. Das wird es für manche sein, gern auch viele, wenn du das möchtest (ich denke eher: Wenige), aber sicherlich nicht für "Alle".
Das achte Weltwunder verkaufe ich dir jedenfalls nicht.
Ich schreibe lediglich Argumente nieder, wieso man nicht gleich DX12 als mies abstempeln sollte bzw. wieso sich die neuen APIs durchsetzen werden.
Einige sehen schon einen massiven Fehlschlag klar vor Augen und ein geringeres Engagement was die Zukunft angeht, dagegen argumentiere ich, dass bedeutet allerdings nicht das ich DX12 als Heiland für jetzt sofort und spätestens nächste Woche anpreise.

Viele der heute üblichen Optimierungen sind mit DX12 oder auch Vulkan nicht mehr möglich, weil die Hardware direkt angesprochen wird. Da mag es eine API geben - aber die geht eben Bare-to-the-Metal. Da kann der IHV dann nichts mehr dran ändern. Wenn der Entwickler es völlig verkackt (wie es ja oft genug tun, Beispiele gibt es - gerade in letzter Zeit - massenhaft) dann hat er es und der IHV kann darin nix tun.
Low-Level-APIs bzw. coding to the metal sind aber auch Bezeichnungen worüber man sich streiten kann.
Tobias Hector von Imagination, Mitglied der Khronos Group, mag die "handelsübliche" Bezeichnung z.B. nicht, er spricht viel lieber von explicit APIs.
Argumente dafür sind, dass die grundlegende Abstraktion oder Arbeitsweise mehr oder weniger auf dem gleichen Level sitzt wie davor, nach wie vor sind alle Shader abstrahiert durch eine Shader-Sprache wie HLSL, nach wie vor gibt es State-Modelle und Objekte, die erst vom Treiber aufgelöst werden und womit jede spezifizierte Hardware angesprochen werden kann.
Viele Dinge die früher der Treiber gemacht hat, sind jetzt im Aufgabenbereich der Entwickler, wobei man die Ansicht vertreten kann, dass man sich hier nicht vertikal nach unten bewegt, sondern horizontal in die Breite.

Man kann natürlich anderer Ansicht sein, der IHV kann im Zweifel weniger retten, aber wenn der Entwickler es früher verkackt hat, dann hilft auch die größere Abstraktion unter DX11 nicht, Batman: Arkham Knight oder Mafia 3 werden auch durch AMDs oder Nvidias Treibergurus nicht von sich aus deutlich besser laufen.

Heute, mit DX11, gibt es eine API auf der Seite A, beim Entwickler und eine auf Seite B beim IHV. Der IHV kann auf seiner Seite schalten und walten, wie er will. Woher kommen wohl die hohen Steigerungen durch "einfach" Treiberupdates? Doch deswegen, weil der IHV auf seiner Seite aufräumt und nicht deshalb, weil der Spieleentwickler optimiert (kann er auch, ja, aber wenn zwei Treiberversionen 10% unterschiedliche Performance haben, dann ist daran der IHV "Schuld").

Das ist mit DX12 so nicht mehr bzw. nur noch eingeschränkt möglich.
Das ist teilweise auch der Knackpunkt am neuen Design, welche Aufgaben sollten im Treiber zu finden sein und welche auf Seiten der Anwendung?
Hier gibt es Pro/Kontra-Argumente, ob es sich allgemein als richtiger Kompromiss herausstellt, wird man dann bei zukünftigen Umsetzungen sehen und zwar am Besten welche, die nicht die erste darstellen und dabei nicht nur den DX11-artigen Unterbau mit DX12 nachahmen und entsprechend wenig attraktive Resultate hervorbringen.
 
Zuletzt bearbeitet:
Zurück