News Beta-Chipsatztreiber: Destiny 2 startet erstmals auf AMD Ryzen 3000

Die Lösung über den Chipsatztreiber wird alle Spieler sehr freuen, weil das schneller geht als das Warten auf ein neues BIOS, und so kann man beim morgen startenden Solstice of Heroes Event pünktlich dabei sein.

Jan schrieb:
Haddock... Der funkt mir aber auch immer wieder rein.
Den hatte ich auch sofort als Kopfkino.
 
R00tMaster schrieb:
Ich kann ja auch nur das Feststellen und Mitteilen was ich jetzt in 6 Durchläufen mit CB20 festgestellt/gemessen habe. ;)

Taxxor schrieb:
Zumindest im SC Test sollte es theoretisch was bringen, da die Kerne schneller durchgewechselt werden

Möglicherweise... Wobei die Kerne auch nicht gerade sehr häufig durchwechseln. Auf jedenfall lässt sich festhalten, dass AMD CPPC2 als Performance steigerndes Feature bewirbt, sagt das aktuell der Ryzen Performance Plan dazu aktiviert sein soll und das UEFI das unterstützen muss.

Wobei AMD nur den App Launch Benchmark des PCMark als Beispiel gibt. 6% + beim Programstart wären jetzt kein Killer Argument pro CPPC2 wobei viele ja immer sagen ein Sys sich max. Snappy anfühlen muss (Schwupdizität nennen das manche wie ich kürzlich lernen durfte)
 

Anhänge

  • 1564416375475.png
    1564416375475.png
    625,6 KB · Aufrufe: 502
Zuletzt bearbeitet:
  • Gefällt mir
Reaktionen: R00tMaster
Funktioniert CPPC2 nur im UEFI-Modus gestarteten System?

Oder meinst Du, dass die Funktion im UEFI/BIOS enthalten & ggf. aktiviert sein soll?
 
Tanzmusikus schrieb:
Oder meinst Du, dass die Funktion im UEFI/BIOS enthalten & ggf. aktiviert sein soll?

Ist scheinbar Teil der AGESA zu den neuen Ryzen (keine Ahnung ob schon immer oder erst ab 1.0.0.3)

Braucht Ryzen 3000*, BIOS Support*, Chipsatz Treiber*, Ryzen Balanced PP* und 1903* laut AMD

*@R00tMaster erfüllt eigentlich alle Kriterien.
 
Digi Quichotte schrieb:
Also da kommt mir irgendwie der P68 Bug in Erinnerung. Da hat Intel über 1 Mrd $ rausgehauen um MBs zurückzurufen, und der Vertrieb um fast 3 Monate herausgezögert, um einen Fehler zu beheben der ähnlich belanglos war. Und alle schrien dann: "Intel - was für ein Drecksladen".

Kommt es aber bei AMD zu einer ähnlichen Situation, und AMD kommt nur mit Marketingsprüchen und Workarounds dann heißt es von den gleichen Leuten nur: "Gut daß sie an dem Problem arbeiten".

Ist schon krass wie unterschiedlich die menschliche Wahrnehmung ausfallen kann. :evillol:

Meinst Du den Bug bei den Intel 6er Chipsätzen? Der war aber auch etwas schwerwiegender, Fehler bei der Datenübertragung an bestimmte SATA Ports (neben der schnelleren Alterung der Controller) finde ich nun nicht so witzig.
Hier starten halt Destiny II und ein paar Linuxsysteme nicht. In beiden Fällen kaum verwunderlich, dass das erst niemand gemerkt hat :D :D :D

Außerdem konnte das Problem bei Intel tatsächlich nur durch neue Hardware gelöst werden, in dem Fall hier ist zumindest noch ein Fix per Microcode in Aussicht. Von daher sind die Probleme nicht zu vergleichen.
 
  • Gefällt mir
Reaktionen: CMDCake, Kodak, derSafran und 5 andere
Ned Flanders schrieb:
Wobei AMD nur den App Launch Benchmark des PCMark als Beispiel gibt. 6% + beim Programstart wären jetzt kein Killer Argument pro CPPC2 wobei viele ja immer sagen ein Sys sich max. Snappy anfühlen muss (Schwupdizität nennen das manche wie ich kürzlich lernen durfte)

Genau das würde für mich Sinn ergeben.

Einzelne Kerne vom 3700x schlafen, und wenn ich ein Programm starte werden die benötigten Kerne mit Ryzen-Ausbalanciert im Bestfall 14ms schneller gestartet als mit Windows-Ausbalanciert.

Starten somit natürlich einen ticken schneller laut "Schwupdizitäts-Gesetz". :D:schluck:

Aber das die Gesamtleistung des PCs um 4-5% ansteigt, nur weil man Ryzen-Ausbalanciert statt Windows-Ausbalanciert nimmt und weil einzelne Kerne dann bei Bedarf 14ms schneller geweckt werden, glaube ich nicht.
Für so einen Leistungssprung müssten die einzelnen Kerne im Ryzen-Energieprofil schon höher Takten als unter dem Windows-Energieprofil, aber das ist ja nicht der Fall
 
Zuletzt bearbeitet von einem Moderator:
  • Gefällt mir
Reaktionen: killingspree und Ned Flanders
Sie müssen ja nicht jede Anwendung testen, sondern nur sicher gehen das die Grundfunktionen der CPU funktionieren. Die CPUs hätten mit defektem RDRAND nie raus gehen dürfen.
 
  • Gefällt mir
Reaktionen: Kalsarikännit, oemmes, Ned Flanders und eine weitere Person
Lieber warten bis die Treiber vernünftig und die Preise 20-30€ gesunken sind. ;)
 
Pr3c4rio schrieb:
Hast du evtl. nen link zur IOMMU Thematik?

Es geht darum das man ohne Kernel Patch das ganze nicht mehr ans laufen bekommt. Dies ist der Einstieg https://community.amd.com/thread/241650

Dazu gibt es noch weitere Probleme bei den GPUs. Diese haben seit Vega bzw. Polaris die Eigenschaft verloren per PCIe zurückgesetzt zu werden. Wenn du eine AMD GPU in eine VM durchschliefen willst, klappt das nicht mit mit Linux Gästen da der Treiber eine GPU in einem unbekannten Status Zustand vorfindet. Der Windows Treiber bekommt das noch irgendwie hin. Die VM kannst du aber dann nicht mehr Neustarten ohne das Ganze System neu starten zu müssen.

Einer meiner Kontakte kann keine Virtualisirung unter Windows mit dem 3700x nutzen. Jedes mal wenn er die Option einschaltet bootet Windows nicht mehr.
 
Zuletzt bearbeitet:
  • Gefällt mir
Reaktionen: Pr3c4rio und Tanzmusikus
nille02 schrieb:
Die CPUs hätten mit defektem RDRAND nie raus gehen dürfen.

Ja, das ist in der Tat schon sehr verwunderlich, hatte AMD erstklassige QC ursprünglich als eine "Gründungsdoktrin" als das noch keiner hatte. Ich vermute aber, dass die das wohl auch schon vorher wussten, denn nichtmal eine Woche nach release war das gepatchte AGESA schon bei den Board Partnern. Vieleicht hat sich der Fehler auch erst kurz vor Release eingeschlichen.

Anyway... eigentlich darf sowas nicht passieren.

R00tMaster schrieb:
Aber das die Gesamtleistung des PCs um 4-5% ansteigt, nur weil man Ryzen-Ausbalanciert statt Windows-Ausbalanciert nimmt und weil einzelne Kerne dann bei Bedarf 14ms schneller geweckt werden, glaube ich nicht.

Gut möglich das Du recht hast. Wäre irgendwie gut wenn wir das rausfinden könnten. Kannst du auf Deinem mal den PC Mark rennen lassen (mit und ohne RPP)

Und woher kommen die 5% im CB Test? Irgend ne idee?
 
Zuletzt bearbeitet:
Wie verhält sich das, bei solchen Fehlern; werden solche Dinge auch Hardwareseitig bereinigt, so dass später korrigierte Modelle vom Band laufen können, oder bleibt der Defekt, welcher dann mit einem solchen Patch ausgebügelt wird, bis es dann mal irgendwann einen Refresh/Ryzen 4000 gibt?
 
Digi Quichotte schrieb:
Also da kommt mir irgendwie der P68 Bug in Erinnerung. Da hat Intel über 1 Mrd $ rausgehauen um MBs zurückzurufen, und der Vertrieb um fast 3 Monate herausgezögert, um einen Fehler zu beheben der ähnlich belanglos war. Und alle schrien dann: "Intel - was für ein Drecksladen".

Kommt es aber bei AMD zu einer ähnlichen Situation, und AMD kommt nur mit Marketingsprüchen und Workarounds dann heißt es von den gleichen Leuten nur: "Gut daß sie an dem Problem arbeiten".

Ist schon krass wie unterschiedlich die menschliche Wahrnehmung ausfallen kann. :evillol:
das kann wohl getrost zu dir genauso sagen , Intel hat 30-40 Din A4 Seiten zu Fehlern bei jeder Gen , nur die wenigsten werden in Hardware gefixt , meist alles Workarounds
Sieh dir Intels Fehlerlisten an zu den CPU s mal an .....

Gen7 + 8 ....
https://www.intel.com/content/dam/w...n-updates/7th-gen-core-family-spec-update.pdf

Gen6 ...
https://www3.intel.com/content/dam/...s/desktop-6th-gen-core-family-spec-update.pdf

Gen5...
https://www.mouser.com/pdfdocs/5th-gen-core-family-spec-update.pdf

und da willst du dich über eine nicht funktionierenden Zufallsgererator Funktion mokieren die zudem offenbar gefixt wurde ?
 
Zuletzt bearbeitet:
  • Gefällt mir
Reaktionen: derSafran
Taxxor schrieb:
Ja weil du dadurch den Ryzen Energiesparplan bekommst.


@Jan
Hallock heißt der gute Mann ;)

Ja schon auf jeden Fall auch bei meinem Dad sein lappi bringt es was.

Ja der ander ist nämlich ein Schauspieler.
 
miwob schrieb:
Wie verhält sich das, bei solchen Fehlern

Das kommt sehr auf den Bug an. In diesem Fall ist das ja eher ein Software Bug im AGESA, denn der RDRNA Zufallsgenerator funktioniert ja nach dem Patch AGESA Patch wieder. Bei echten Hardware Bugs, wie dem TLB Bug bei AMDs Phenom I oder den diversen Intel Bugs der letzten Jahre lässt sich das eventuell nur unter Performance Verlusten umschiffen was natürlich dann per Hardware gefixt wird. Dazu braucht es aber mindestens ein neues Stepping oder gar ein Redesign.

Alle aktuellen CPUs sind relativ voll von Bugs. Die meisten werden schon vor Release gepatched.
 
MK one schrieb:
und da willst du dich über eine nicht funktionierenden Zufallsgererator Funktion mokieren die zudem offenbar gefixt wurde ?

Ich habe mich weder über AMD noch um den Bug mokiert. Mein Post betraf eher die unterschiedliche Wahrnehmung/Reaktionen der User.
 
Ned Flanders schrieb:
denn nichtmal eine Woche nach release war das gepatchte AGESA schon bei den Board Partnern.

Wurde dann aber doch wieder zurückgezogen.
Ich finds mittlerweile total unübersichtlich vernünftige Infos zu bekommen wie weit man da mit nem fix ist.
Da ist die Kommunikation von AMD auch nicht sehr offen
 
Pr3c4rio schrieb:
Da ist die Kommunikation von AMD auch nicht sehr offen

Scheinbar gibts ja morgen was dazu, ich würde aber vermuten dass das gepatchte AGESA noch nicht fertig ist/sich zu langsam per BIOS updates auf alten Boards verteilen lässt, wenn AMD_Robert einen Beta Chipsatz Treiber unters Volk bringt.

Was ich nicht ganz verstehe ist warum Destiny oder SystemD nicht auch mit -1 als Zufallszahl starten. Zahl angefragt und bekommen müsste ja reichen. Kann ja eigentlich nicht sein das Destiny mit dem Wert unzufrieden ist.
 
Zuletzt bearbeitet:
  • Gefällt mir
Reaktionen: CMDCake
Ned Flanders schrieb:
Schwupdizität nennen das manche wie ich kürzlich lernen durfte
Das und die Fluffigkeit sind die wichtigsten Systemeigenschaften. -^^
 
  • Gefällt mir
Reaktionen: blackTEHhawk, Tanzmusikus und Ned Flanders
Ned Flanders schrieb:
Was ich nicht ganz verstehe ist warum Destiny oder SystemD nicht auch mit -1 als Zufallszahl starten. Zahl angefragt und bekommen müsste ja reichen. Kann ja eigentlich nicht sein das Destiny mit dem Wert unzufrieden ist.

Bei systemd verstehe ich das auch nicht, es ist eine Komponente die Robust sein muss, wobei ich mir hier eher an dem Umgang mit dem Fehler bei systemd Aufrege. Bei Destiny kann ich es nachvollziehen, warum sollte ich von einem Fehler ausgehen wenn die CPU mir das Gegenteil mitteilt.
 
Schwupdizitätsgesetz ist für mich jetzt schon auf alle Fälle "Wort des Jahres". :daumen: :schluck:
 
  • Gefällt mir
Reaktionen: knoxxi, NerdmitHerz und Ned Flanders
Zurück
Oben