Cyperpunk 2077 nutzt SMT für AMD-Prozessoren nicht

Ich habe CB über GOG bezogen und finde die entsprechenden Zeilen (aktueller patch) einfach nicht :(
 
Wenn Du diese Anzeige nicht sehen willst, registriere Dich und/oder logge Dich ein.
1608122512937.png
 
Is ja nicht so als wäre Performance so ein undurchsichtiges und ominöses Konstrukt, dass keiner versteht und deswegen Monate an dem verschlüsselten Geheimnis hin forschen muss.
Jedes Feature kostet Performance X.
Die Konsole hat Performance Y.
Man kann so viele Features aktivieren, bis die Summe aus den ganzen X(en) bei Y ankommt. Will man dann noch mehr Features, muss man andere Features dafür kastrieren,... oder hat halt sub 60fps.
So einfach ist das nicht.
Bei Konsolen kannst du dich ewig mit Optimierungen beschäftigen und immer noch was rausholen.
Du hast ja unterschiedlichste Szenen mit unterschiedlichen Anforderungen in so einem Spiel. Das geht soweit, dass während wenig fordernder Szenen schon Mal Daten für die vermutlich folgende schwierige Outdoor Szene mit großer Fernsicht berechnet werden.

Die Abstimmungen in welcher Szene welche Grafikdetails in welcher Auflösung angezeigt werden können ohne das die FPS dabei zu sehr einbrechen und welche Vorausberechnungen man dabei noch vornehmen könnte sind ein quasi unendlich tiefer Optimierungspool.

Auf dem PC macht das keiner, weil ja noch die Hardwarevarianten und die Background Prozesse in die Gleichung mit einfließen. Man würde nie zu einem Ergebnis kommen (vielleicht in Zukunft wenn der komplette Prozess automatisiert von KIs durchgeführt wird).
 
Wieso? Es gab doch die ganze Entwicklungszeit über nur die "alten" Konsolen, auch alle ursprünglich geplanten Veröffentlichungstermine hätten keine "neuen" Konsolen bedienen können. CDPR wusste also genau auf was sie sich einlassen und wie es dort um die Performance steht.
Natürlich wussten die ENTWICKLER das.
Aber die Entwickler entscheiden nicht über Releasetermine, oder über unterstützte Hardware und Konsolen.

Da beißen sich leider, wie bei jeder größeren Firma, die Großkopferten mit den Arbeitern. :-(
 
Natürlich wussten die ENTWICKLER das.
Aber die Entwickler entscheiden nicht über Releasetermine, oder über unterstützte Hardware und Konsolen.

Da beißen sich leider, wie bei jeder größeren Firma, die Großkopferten mit den Arbeitern. :-(
Doch, die Entwickler entscheiden. Die Entwickler entscheiden ob das Spiel fertig ist oder nicht. Die Entwickler geben eine ziemlich genaue Abschätzung wie viele Bugs es gibt und wie lange man den Mist noch patchen wird, wenn es jetzt live geht.
Die Entwickler entscheiden ob das Spiel spielbar ist oder ob das nur ein Codehaufen ist.

Die Firma kann sich natürlich über die Entwickler hinwegsetzen und alles releasen was halt so rumliegt, aber die sind nicht doof - die wissen das aktuell mit Refunds und negativer Publicity massive Probleme folgen, die es ehrlich gesagt nicht wert sind. Verkackte Releases kennt man genug. Nur Bugs sind die Spieler mittlerweile gewohnt, das ist nicht so kritisch das da gleich Fackeln und Mistgabeln rausgeholt werden. Die Konsoleros haben aber aktuell noch bissl nachgelegt, gab richtig Drama obwohl das Spiel an sich gar nicht so schlecht läuft auf der current gen (nicht last gen, wen juckt denn die Hardware von vor 7 Jahren - im PC-Bereich kriegt man die mittlerweile kostenlos hinterhergeworfen, damit sie nicht rumliegt :d ).
 
Natürlich wussten die ENTWICKLER das.
Aber die Entwickler entscheiden nicht über Releasetermine, oder über unterstützte Hardware und Konsolen.

Da muss ich dir recht geben, in der Regel sitzt nur der Projekt Koordinator mit am Management Tisch und muss mit den Anweisungen klar kommen. Es gibt fast keine Möglichkeit das Angebot vom Management auszureden.

Da werden Deadlines gesetzt, in gewisser Weise mit friss oder stirb...

Der Fische fängt immer an am Kopf zu stinken.
Beitrag automatisch zusammengeführt:

Doch, die Entwickler entscheiden. Die Entwickler entscheiden ob das Spiel fertig ist oder nicht. Die Entwickler geben eine ziemlich genaue Abschätzung wie viele Bugs es gibt und wie lange man den Mist noch patchen wird, wenn es jetzt live geht.
Die Entwickler entscheiden ob das Spiel spielbar ist oder ob das nur ein Codehaufen ist.

Ja und nein. Der Entwickler wird vom Management erpresst. Der will Resultate egal wie das zu realisieren ist. Im schlimmsten Falle musst du zwischen irgendwas fertiges vorstellen und deinem Job entscheiden.
 
Doch, die Entwickler entscheiden. Die Entwickler entscheiden ob das Spiel fertig ist oder nicht. Die Entwickler geben eine ziemlich genaue Abschätzung wie viele Bugs es gibt und wie lange man den Mist noch patchen wird, wenn es jetzt live geht.
Die Entwickler entscheiden ob das Spiel spielbar ist oder ob das nur ein Codehaufen ist.

So eine Firma habe ich dann noch nicht einmal in meinen 25 Jahren Berufserfahrung erlebt.
Die Entwickler hatten da nie auch nur ein Wort mitzureden. Bestenfalls werden sie befragt wie viele Bugs noch drin sind, damit PR abschätzen kann wie der Backlash wird, aber entscheiden kann ein Entwickler gar nichts.
 
So eine Firma habe ich dann noch nicht einmal in meinen 25 Jahren Berufserfahrung erlebt.
Die Entwickler hatten da nie auch nur ein Wort mitzureden. Bestenfalls werden sie befragt wie viele Bugs noch drin sind, damit PR abschätzen kann wie der Backlash wird, aber entscheiden kann ein Entwickler gar nichts.

Da wo ich aktuell bin herrscht Entwicklermangel (wie so ziemlich überall) und deswegen werden die Projekte dann released wenn sie halt fertig sind, also überwiegend bugfrei (100% bugfrei gibt es eh nicht).
Halbfertig releasen geht nicht. Gut, wir haben Projekte die eher Monate dauern, keine Jahre wie solche Spiele, die Budgets sind auch ganz anders.
Es ist aber mittlerweile normal, auf die Entwickler zu hören, denn nur die wissen wie weit das Projekt eigentlich ist, wann es in die internen Tests gehen kann und wie lange sie noch brauchen.
Entwicklung ist ein kreativer Prozess, ähnlich einer Album-Aufnahme inklusive Mixing & Mastering. Kein Musiker würde sich trauen, ein unfertiges Album zu releasen - und das dauert halt so lange wie es dauert. Bei manchen Bands halt auch mal 10 Jahre für ein Album. Das sollte bei Spielen nicht anders ablaufen, nur so kriegt man Qualität.
Also ja, die Entwickler haben sehr wohl was zu sagen, nur streiten die sich halt oft mit dem Management oder anderen Abteilungen wenn ihre Sachen nicht zum geplanten Zeitpunkt fertig werden (was eh Quatsch ist weil kreative Arbeit).
 
Entwicklung ist ein kreativer Prozess, ähnlich einer Album-Aufnahme inklusive Mixing & Mastering. Kein Musiker würde sich trauen, ein unfertiges Album zu releasen - und das dauert halt so lange wie es dauert.
Ja das ist Richtig, wenn aber das Konzept feststeht muss runter programmiert werden und umgesetzt werden. Das ist dann wie beim Industriemechaniker am Fließband bei VW etc. Nach der Blaupause muss Produziert werden.

Prottypen gab es schon vor 2-3 Jahren, sonst hätte man kein Gameplay zeigen können. (40 Minuten Demo)..
 
Ja das ist Richtig, wenn aber das Konzept feststeht muss runter programmiert werden und umgesetzt werden. Das ist dann wie beim Industriemechaniker am Fließband bei VW etc. Nach der Blaupause muss Produziert werden.
Ähm nope.
 
Ja das ist Richtig, wenn aber das Konzept feststeht muss runter programmiert werden und umgesetzt werden. Das ist dann wie beim Industriemechaniker am Fließband bei VW etc. Nach der Blaupause muss Produziert werden.

Prottypen gab es schon vor 2-3 Jahren, sonst hätte man kein Gameplay zeigen können. (40 Minuten Demo)..

Nicht ganz. der Mechaniker am Fließband kriegt alle Teile vorgesetzt und muss den Mist nur so zusammenschrauben das da nix wackelt.
Wäre programmieren so einfach, würden wir bug-freie Spiele in kürzester Zeit bekommen.
Programmieren ist hingegen eher so ein Prozess wie eine Album-Aufnahme der Band im Studio. Das kreative Material ist da, aber das muss so aufgenommen und bearbeitet werden damit es sich nicht wie eine Klospülung anhört. Und das ist auch kreative Arbeit und sie braucht sehr viel Zeit. Und wenn sie fertig ist, dann ist sie fertig. Man kann bei so was NIEMALS ein Datum vorher setzen und darauf bestehen das es bis dahin fertig sein muss. Es KANN bis dahin fertig werden oder eben nicht.
Und die besagten Prototypen sind wie eine Demo. Wenn die Band in der Garage was aufnimmt und dir eine Demo sendet, ist das noch Jahre entfernt von einem fertigen Produkt das zum Kunden kann ohne das der Kunde kotzt.
Die Entwickler im Studio bestimmen das Tempo und den Release. Da kann das Management noch so sehr toben, wenn das Produkt nicht fertig ist, dann ist es nicht fertig. Gute Studios überlegen sich also ganz genau wann sie ein Produkt auf die Kunden loslassen.
Deswegen wurde Cyberpunk 2077 mehrfach verschoben und deswegen wurde es jetzt released - weil 99% der Probleme behoben sind. Die Kleinigkeiten wie visuelle Bugs sind die letzten Schritte die man jetzt patchen kann. Und das die Konsoleros etwas bekommen haben das so aussieht wie es eben aussieht, liegt daran das die alte Hardware von vor 8 Jahren nichts gebacken bekommt.
 
Ich habe gestern je ca. 1 Stunde Gameplay gebenchmarked mit "Hack" und ohne und die Unterschiede sind kleiner als ~5 fps je nach Parameter. Die mittleren FPS sind sogar auf 0,6 fps gleich.
 
Die sollten sich einfach nur schämen. Ich kaufe nie wieder was von cdpr, nur noch EA!
 
Die Konsolen haben kein SMT zumindest nicht die alten PS4 und die Xbox, möglicherweise ist es deshalb deaktiviert...
 
Ich habe CB über GOG bezogen und finde die entsprechenden Zeilen (aktueller patch) einfach nicht :(
In der GOG Version 1.04 (SHA1 992e3a07d3339d2d967a06f07db43f02547e7a3d) liegt das Byte bei Offset 0x142a822b3.
Beitrag automatisch zusammengeführt:

Die Konsolen haben kein SMT zumindest nicht die alten PS4 und die Xbox, möglicherweise ist es deshalb deaktiviert...
Der betreffende Code ist Windows-spezifisch, mit den Konsolen hat das also wahrscheinlich nichts zu tun.

Ich hab mir das ganze mittlerweile auch mal heruntergeladen und selbst angesehen. Es handelt sich tatsächlich um eine 1:1 Umsetzung von getDefaultThreadCount() (zuzüglich Compiler Optimierungen); vermutlich wurde der AMD Beispielcode einfach direkt übernommen.

Den "offiziellen" Gedankengang, warum Ryzen (technisch gesehen alle nicht-15h) CPUs die physische, statt der logischen Kern-Anzahl verwenden, kann man hier nachlesen:

For today’s Ryzen processors with SMT enabled, we’ve found that the vast majority of multithreaded games and applications work and scale really well when managing an active thread pool up to the number of logical cores that the processor supports. However, our experience with a small number of games is that driving a hardware thread pool with more than the number of physical cores can reduce performance, primarily due to contention for available per-core resources by the multiple running hardware threads.

However, for our own prior generation of Bulldozer-based processors designs, we recommend a default thread count equal to the number of logical processor cores. Other processor vendors are encouraged to provide their own guidance to software developers. AMD does not provide guidance for other processor vendors.

Therefore no matter the processor or processor vendor, we strongly recommend that you profile your games extensively to make a decision on how to manage your thread pool for the processor designs you’ll find your game code running on. Our sample code, linked below, errs on the side of caution for our Ryzen processors and encourages you to profile: the getDefaultThreadCount() function draws attention to that fact, returning a starting default count equal to the number of physical processor cores on Ryzen.

Es handelt sich dabei nur um ein Codebeispiel, nicht ein Framework oder eine Bibliothek, die dafür gedacht wäre direkt wäre, direkt in Anwendungscode verwendet zu werden. Der Entwickler wird auch sowohl in dem Artikel, als auch durch den Kommentar im Code selbst darauf hingewiesen, immer für die jeweilige Anwendung zu profilieren.

Auch wenn es imo nicht Verkehrt und gängige Praxis ist, Code aus Beispielen quasi unverändert zu übernehmen, hat hier jemand bei CDPR einfach seine / ihre Hausaufgaben nicht gemacht. Vermutlich wurde der Code zu einem Zeitpunkt zur Engine hinzugefügt, als es noch zu früh war, Leistungstests und Optimierungen durchzuführen und ist dann später einfach unter den Tisch gefallen / wurde als bereits erledigt angenommen / NeVer tOuCh A rUnNiG SySteM.
 
Zuletzt bearbeitet:
Ja echt (zu)viel off topic hier, aber schön, dass das mit dem SMT jetzt gepatcht wird - bin gespannt, wann der PC Patch geliefert wird. Wäre wieder ein Puzzlestück in die Richtung, dass ich mir das Spiel mal ansehe.
 
Ja echt (zu)viel off topic hier, aber schön, dass das mit dem SMT jetzt gepatcht wird - bin gespannt, wann der PC Patch geliefert wird. Wäre wieder ein Puzzlestück in die Richtung, dass ich mir das Spiel mal ansehe.
patch 1.05 bezieht sich nur auf 4&6-Kern Ryzen Prozessoren. Alles ab 8 Kernen funktioniert wie geplant.
Was man auch hier schon festgestellt hat.
 
Es soll ja hauptsächlich bei RYZEN CPUs helfen die mit nur einem CCX ausgestattet sind, während es bei Ryzen mit 2 CCX zu weniger Performance führt.

Mit meinem 5900X werden auch nur 12 Threads ausgelastet, da die Performance mit der 3080 aber im Rahmen der Erwartungen ausfällt habe ich bisher keine Hand an die .exe angelegt.
...


Das heißt, mit einem 5800x würde sich ein Versuch sogar lohnen, da ja auch nur ein ccx da ist ?...
 
Das wäre ausgesprochen interessant.

Wenn man reddit glauben darf*, stammt der problematische Code aus AMDs GPUOpen CPU core counts Sample, oder ist zumindest eine Implementierung der gleichen Logik. In dem Fall sollten nicht-AMD CPUs nicht betroffen sein und der Patch keine Wirkung zeigen.

Außer man verwendet die 74 … Variante. Dann würde auf intel CPUs die Anzahl der tatsächlichen Kerne, statt der logischen als Basis für den Thread Count verwendet (also genau das Verhalten, dass für einige Ryzen CPUs problematisch ist). Andererseits hat der Patch wohl die Performance für bestimmte Ryzen CPUs auch verschlechtert, insofern wäre es auch möglich, dass bestimmte intel CPUs vom umgekehrten Verhalten profitieren.

Langsam bekomme ich Lust, mir das das Spiel runterzuladen, nur um mir die Sache mal selbst im Kontext anzuschauen. Zum zocken fehlt ja leider die Zeit. :(

* vermutlich keine gute Idee
** Kann natürlich sein, dass CDPR speziell für intel CPUs nochmal eigene Checks umgesetzt hat

Ich bin mir nicht mehr sicher mit welcher Variante ich die .exe editiert habe. Vorher hatte ich aber das Phänomen, dass CP77 nur die Tatsächlichen Kerne genutzt hat. Nach dem edit auch die Threads. Ähnlich wie bei AMD. Das kann auf folgendes hin deuten.
Da die CPU 10 Jahre alt ist (Xeon W3670, Q3'10). Hat AMD eventuell (VERMUTUNG) bei der Entwicklung neuere CPUs. Sich angesehen wie Multicore bei Intel funktioniert und gewisse Ideen davon übernommen hat.

Interessant wäre zu Wissen ob aktuelle 4 bis 6 Kern Intel CPUs ebenfall von diesem edit, jetzt Patch, profitieren.

Denn vorher konnte ich nur mit minimalen Details spielen. Nach dem diesem edit mit Medium Details. Wobei ich jetzt festellen durfte das es so etwas wie eine Bufferoverflow Bug im VRAM gibt. Da ich nur eine RX570 ITX (4GB) habe.Das Spiel belegt mir den Spiecher bis 3,8 bzw. 3,9 GB und versucht immer weiter ihn zu befüllen bis ich ernsthafte Grafikprobleme bekomme. Bis hin zum Treiberabsturz bzw. Bluescreen.
In der Regel ist es so, dass wenn die ersten Grafikprobleme auftreten. Das ich dann das Spiel beende und neustarte.
 
CD Projekt Red hat den Hotfix 1.05 für Cyberpunk 2077 veröffentlicht, der das SMT für Ryzen-Prozessoren mit vier und sechs Kernen aktiviert. AMD-Prozessoren mit mehr als sechs Kernen profitieren vom SMT-Patch nicht.

==> Also profitiert der Ryzen7 3700X, 5800X und besser nicht

Allerdings wird der Hotfix aktuell nur für die Konsolen-Version angeboten

==> Also profitiert auch der Ryzen 3600(X), und 5600 nicht

Was für eine CPU hat die Konsole

Zitat aus einem Test zur XBOX Series X und PS 5 von Gamestar (link)
PlayStation 5- 8 Kerne/16 Threads (AMD Zen 2)
- maximal 3,5 GHz
- variable Taktrate
Xbox Series X- 8 Kerne/16 Threads (AMD Zen 2)
- 3,8 GHz (mit 16 Threads 3,6 GHz)
- fixe Taktrate

Oh ... mehr als 6 Kerne

der das SMT für Ryzen-Prozessoren mit vier und sechs Kernen aktiviert.
Konsole XBox S/X und PS5 haben mehr als 8 Kerne.

Frage:

WAS MACHT DER PATCH NOCH?
 
Steht in den Patchnotes.
Die Ausnutzung der Kerne bei meinem 3800X ist jetzt wieder genau wie vor dem Hex Fix.:cautious: Und der Fix ist nicht mehr nutzbar, weil die entsprechende Zeichenfolge nicht mehr vorhanden ist.
Im CPU Limit hatte der Fix bei mir durchaus was gebracht. Die Auslastung der Graka wurde deutlich erhöht und es waren etwa 3 FPS mehr avg und P1.
Im GPU Limit waren es aber nur zwischen 2 und 3 FPS im P1. Nach dem Patch habe ich wieder 3 FPS weniger bei den P1.
 
Zuletzt bearbeitet:
Verstehe nicht wieso sowas wieder weggepatched wird und nicht sogar implementiert wird -.-
 
Steht in den Patchnotes.
Die Ausnutzung der Kerne bei meinem 3800X ist jetzt wieder genau wie vor dem Hex Fix.:cautious: Und der Fix ist nicht mehr nutzbar, weil die entsprechende Zeichenfolge nicht mehr vorhanden ist.
Im CPU Limit hatte der Fix bei mir durchaus was gebracht. Die Auslastung der Graka wurde deutlich erhöht und es waren etwa 3 FPS mehr avg und P1.
Im GPU Limit waren es aber nur zwischen 2 und 3 FPS im P1. Nach dem Patch habe ich wieder 3 FPS weniger bei den P1.
Also fahre ich besser kein Update, da es jetzt ja läuft
 
 
Verstehe nicht wieso sowas wieder weggepatched wird und nicht sogar implementiert wird -.-
Ist doch geändert worden - aber eben nur für die 4- und 6 Kerner. Für die 8- und mehr Kerne wurde das nicht für nötig gehalten. CDPR und AMD waren sich darüber einig, dass die CPU's mit 8 und mehr kernen "laufen wie vorgesehen".
 
Den Eintrag für Hex-Edit gibt es auch bei meiner Exe nicht mehr. Und der Prozessor nutzt geschmeidig nur die physischen Kerne und kein SMT.:cry:
Schade drum, irgendwie versaut es mir das ganze Game.
 
Den Eintrag für Hex-Edit gibt es auch bei meiner Exe nicht mehr. Und der Prozessor nutzt geschmeidig nur die physischen Kerne und kein SMT.:cry:
Schade drum, irgendwie versaut es mir das ganze Game.
Es versaut Dir das Game, dass Deine CPU im optimalen Setting läuft und Du es nicht künstlich schlechter machen kannst? Uhm,...
... da kann ich Dich beruhigen: Du kannst es weiterhin runterdrehen. Sind jetzt nur andere Hexzahlen, nach denen Du suchen musst. Keiner hält Dich auf das Spiel langsamer zu machen. ;-)

Kannst aber auch einfach die CPU untertakten,... hat dasselbe Ergebnis und ist einfacher / muss nicht nach jedem Patch neu gemacht werden!
 
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