[Sammelthread] Liste von Spielen die für Zen optimiert werden

YB0b

Enthusiast
Thread Starter
Mitglied seit
04.08.2009
Beiträge
745
  • Bethesda
    -Doom​
  • Creative Assembly
    -Totalwar: Attila und spätere Totalwar-Titel​
  • DICE
    -Battlefield 1​
  • Eidos
    -Deus Ex: Mankind Divided​
  • Oxide
    -AotS​
  • SEGA
    -???​
  • VALVE
    -DOTA 2​
 
Zuletzt bearbeitet:
Wenn Du diese Anzeige nicht sehen willst, registriere Dich und/oder logge Dich ein.
werden? quelle? ;)
 
Creative Assembly ist, auch wenn ich ein absoluter Fan der Total War Reihe bin, eine total Katastrophe wenns ums die Engine der Titel geht. Da würde ich mich auf absolut nichts verlassen, speziell nicht die Warscape Engine, die entspannte 8 Jahre alt ist und wahrscheinlich für die nächsten großen Titel weiter verwendet wird.
 
Zuletzt bearbeitet:
Hi. :) I can answer some of this:
1) Improving core engine performance was a major goal. We call that Instruction Level Parallelism (ILP), or extracting more throughput from instructions coming into the processor. That's a large component of the >52% IPC. Our new micro-op cache is also useful for short-cutting time-intensive processes inside the engine. And our new cache prefetchers + branch prediction units are a major piece of that >52% as well.
2) Optimizing a codebase for an all-new microarchitecture is an important aspect of extracting the best performance. We have not had a high-end desktop processor in a while, and nothing remotely like Zen that could be used to inform early expectations. So getting our software development efforts ramped up will be key. Bethesda, Oxide Games and SEGA are already onboard, and we've sampled 300+ devkits with a plan for 1000+ by year's end.
3) Zen2 and Zen3. :)

AMD_Robert comments on We are AMD, creators of Athlon, Radeon and other famous microprocessors. We also power the Xbox One and PS4. Today we want to talk RYZEN, our new high-speed CPU five years in the making. We're celebrating with giveaways, and you can ask us anything! Special guest: AMD President and CEO Dr. Lisa Su.
 
Die DX12@Async compute Games wie Sniper E4 und Halo Wars 2 dürften AMD ziemlich gut schmecken. Sieht man schon an der Fury.
 
Das optimieren beschränkt sich darauf das ein game nicht den Thread wechselt und möglichst 4+0 gepinnt wird
Somit sind alle >4 core games nicht mehr schneller auf amd r7 1700x als auf einen ci7 7700.
Das einzige was wirklich helfen wird ist den IMC höher takten (ramtakt)
Das gap bei ccx kopieren liegt bei etwa 12-30%
laut eines test auf pcgh forum Eintrag
Ryzen 7 1800X im Test: AMDs Rückkehr in den High-End-Markt - Seite 190
 
Das optimieren beschränkt sich darauf das ein game nicht den Thread wechselt und möglichst 4+0 gepinnt wird
Somit sind alle >4 core games nicht mehr schneller auf amd r7 1700x als auf einen ci7 7700.
Das einzige was wirklich helfen wird ist den IMC höher takten (ramtakt)
Das gap bei ccx kopieren liegt bei etwa 12-30%
laut eines test auf pcgh forum Eintrag
Ryzen 7 1800X im Test: AMDs Rückkehr in den High-End-Markt - Seite 190

Halte ich nichts von. Das Hauptproblem von Ryzen wie für Haswell-E bleibt CoreParking.

Nimmt man mal nur Spiele aus 2016/2017 ist Ranking und die extrem skurielen DX12-Ergebnisse raus so liegen alle Intel und AMD CPUs mit mehr als 4 Kernen vor dem 7700k.

attachment.php
 
Zuletzt bearbeitet:

Das lässt sich aber nicht so beliebig auch auf Windows beziehen, denn die Zahlen sind mit Linux entstanden, und der Treiber, der für die Vulkan- Ergebnisse benutzt wurde, ist der OpenSource- Treiber RADV, der aktuell gerademal 55% der Vulkan- Konformitäts- Tests besteht, und von dem bekannt ist, dass er in jedem einzelnen Test, egal mit welcher CPU, aktuell schlechter performt, als die OpenSource OpenGL- Implementierung, weil diese im Gegensatz dazu schon vollständig ist, und nur noch Optimierungen erhält, und - man glaubt es kaum - eher besser im Multithreading ist.(Natürlich wird sich das mit dem Reifeprozess von RADV ändern)

Hier ist also eher der Vulkantreiber im Alphastadium schuld, während die OpenGL- Ergebnisse, egal mit welcher Konfiguration, ja vergleichsweise stabil bleiben. Außer, wenn alles komplett aktiv ist, aber da wissen wir ja bereits, dass für SMT zwischen beiden Modulen in den Schedulern noch ein paar Optimierungen nötig sind. Das ist bei Linux nicht anders als mit Windows 10.
 
@oooverclocker
Unter Linux kannst halt alle Module (Treiber) in den Kernel compilieren, dabei wird nicht vorhandene Hardware aus dem Kernel geschmissen.
Der Kernel wird schlanker und schneller, da er keine Treiber mehr "laden" muss und sich über zig Software Layer hinweg unterhalten muss. ;)

Alpha wäre doch 0.x Version?
Unter Windows 10 hat die Vulkan API Version bei mir: 1.0.30
 
Alpha wäre doch 0.x Version?
Unter Windows 10 hat die Vulkan API Version bei mir: 1.0.30

So, jetzt muss ich lang ausholen... ich hoffe, dass die Erklärung OK ist, damit man versteht, warum die Zahlen der Quelle nicht aussagekräftig sind und mir keiner für das OT böse ist...
Die Vulkan API wird von Khronos spezifiziert und wird dann von den Firmen, Intel, AMD und Nvidia in ihre Treiber enigebaut. Auf Windows ist die Sache sehr übersichtlich: Von allen Firmen bekommt man Closed-Source- Treiber, die man sich downloaden muss.

Auf Linux ist es anders:
1. Intel hat voll funktionstüchtige OpenGL(i965) und Vulkan(ANV) - Treiber für ihre IGPs, die beide OpenSource sind, aber keinen Closed- Source- Treiber.(Optimal ;))
2. Nvidia hat einen Closed- Source- Treiber mit OpenGL und Vulkan, und sie setzen auch voll auf den - entsprechend mies laufen die Karten mit den OpenSource- Treibern(Nouveau).

3. Bei AMD ist es kompliziert... Sie haben einen Closed- Source- Treiber für OpenGL und Vulkan.
Das Problem ist: Auf Linux will keiner die Closed- Source- Treiber, weil man da nicht sehen kann, welche "schmutzigen Tricks" drin stecken(z.B. um FPS auf Kosten von Frametimes und Bildqualität zu boosten) und weil man dann ja noch extra etwas herunterladen und installieren muss, während die freien Treiber automatisch integriert sind. Und AMD hätte sicherlich auch nichts dagegen, wenn man sich mehr auf die Hardware konzentriert, und bei den Treibern Unterstützung bekommt.
Also haben sie vor einiger Zeit selbst mitgewirkt, dass MESA(sozusagen eine "Sammlung" von OpenSource- Treibern), mit RadeonSI einen sehr guten OpenGL- Treiber bekommt, und unterstützen den auch weiterhin. Zudem bauen sie mit dem AMDGPU- Kernelmodul auch die Grundlage dafür direkt in den Kernel. Sie haben aber auch mitgeteilt, dass sie die Vulkan- Implementierung des proprietären Treibers OpenSourcen werden. Allerdings ist dieses OpenSourcen extrem aufwändig, weil da ja möglicherweise noch Code drin sein könnte, der speziell rechtlich geprüft werden muss, bevor man ihn veröffentlichen kann.

Nachdem monatelang der Quellcode von Vulkan nicht preisgegeben wurde, entschloss sich David Airlie von Red Hat, selbst mit einem Vulkantreiber zu beginnen, dem RADV. Deshalb steht auch im Quellcode "Copyright 2016 Red Hat", obwohl der Treiber ja für AMD- Karten ist. Natürlich unterstützt AMD den "fremden" Vulkantreiber nicht, weil sie ja irgendwann ihren eigenen bringen wollen und somit finden die es sicher ein wenig doof, wenn der ganz anders aufgebaut ist.
Der Treiber konnte irgendwann The Talos Principle korrekt darstellen - zwar mit grottiger Performance, aber es ging. Etwas besseres in OpenSource für Vulkan gab es nicht... Außerdem brauchte man Strahlkraft, um das Projekt voranzutreiben und weitere Entwickler zu gewinnen... Also hat man bei MESA eine Ausnahme gemacht und das Ding schon so aufgenommen.
Mittlerweile rendert es alle Spiele korrekt, die es mit Vulkan- Support auf Linux gibt, aber ist noch deutlich langsamer als die gleichen Spiele mit OpenGL laufen und ist noch entfernt davon, alle Features der Khronos Group zu supporten.
Mittlerweile hat Valve 5 Entwickler für die MESA- Treiber eingestellt, die unter anderem auch an RADV mitarbeiten(Edit: Die suchen übrigens noch mehr ;)), es kamen zudem auch Patches von Entwicklerstudios. Deshalb sieht es so aus, dass wahrscheinlich der offizielle AMD- Vulkan- Treiber gar nie in das offene Treiberpaket aufgenommen wird, sondern RADV vorher schon voll funktionsfähig sein wird.

Und das bedeutet jetzt konkret: Eine aktuelle AMD- Karte läuft auf Linux direkt, aber nur mit OpenGL gut - und mit Vulkan noch zu langsam. Genau deswegen macht es keinen Sinn, die völlig inkonsistenten Werte dieses unfertigen Vulkan- Treibers(RADV) zu benutzen, um zu bescheinigen, dass Ryzen riesige Probleme mit den Threads hätte etc. Es ist umgekehrt - dieser eine Treiber hat aktuell noch extreme Probleme mit jeder CPU und kommt extrem schnell ins CPU-Limit.
 
Zuletzt bearbeitet:
@oooverclocker
Hm, sehr Gehaltvoll dein Beitrag, weiter ausholen in Textform fällt immer mehr Personen schwer.
Du scheinst davon nicht betroffen zu sein. :)

So sah es mit 1.0.17 aus bei DOOM 2016: http://abload.de/img/doom_vulkan_menv9s9q.png
 
Hardwareluxx setzt keine externen Werbe- und Tracking-Cookies ein. Auf unserer Webseite finden Sie nur noch Cookies nach berechtigtem Interesse (Art. 6 Abs. 1 Satz 1 lit. f DSGVO) oder eigene funktionelle Cookies. Durch die Nutzung unserer Webseite erklären Sie sich damit einverstanden, dass wir diese Cookies setzen. Mehr Informationen und Möglichkeiten zur Einstellung unserer Cookies finden Sie in unserer Datenschutzerklärung.


Zurück
Oben Unten refresh