Bericht PresentMon Beta: Intel mit neuem Benchmark-Tool und neuer Messmetrik

SweetOhm schrieb:
Wenn ich auf Deinen Download Link klicke kommt folgende Meldung (siehe Anhang).

Kann ich diese bedenkenlos ignorieren ?
Schau den Link an, denk drüber nach, komm zu einem hoffentlich richtigen Schluss.

Defender sperrt so ziemlich alles, legal oder nicht. Warum weiss vermutlich auch bei MS niemand.
 
burkm schrieb:
Mein akueller Windows Defender meldet einen Virus im Download der Beta und weigert sich damit dann auch die Datei abzuspeichern...

Diese Website wurde als unsicher gemeldet.​

Gehostet von intelpresentmon.s3.amazonaws.com​

Microsoft rät davon ab, zu dieser Website zu wechseln. Microsoft wurde gemeldet, dass die Website schädliche Programme enthält, die personenbezogene oder Finanzinformationen ausspähen können.

Zurück
Weitere Informationen
Schädliche Websites, die Links zu Schadsoftware enthalten, können Ihr Gerät beschädigen und dazu führen, dass das Gerät nicht mehr verwendet werden kann. Wenn Sie eine schädliche Website besuchen, kann Ihr Gerät automatisch von Schadsoftware infiziert werden. Darüber hinaus gefährden Sie unter Umständen vertrauliche Informationen wie Kennwörter, Kreditkartennummern, Kontaktinformationen oder Softwareaktivierungsschlüssel. Mehr erfahren

Schädliche Websites verwenden häufig Spam-E-Mails, Werbung oder Umleitungen von anderen Websites, um Sie zum Herunterladen von Schadsoftware zu verleiten. Manchmal kann eine vertrauenswürdige Website von böswilligen Benutzern gehackt und zum Verknüpfen bösartiger Inhalte verwendet werden. Navigieren Sie zurück., wenn Sie unsicher sind.
  • Melden, dass diese Website keine Bedrohungen durch Schadsoftware enthält
  • Weiter zur unsicheren Website (nicht empfohlen)
Komisch. dass sich dazu noch keiner geäußert hat...
Ich habe jetzt mehrfach versucht mit aktuellen Windows Defender Viren-Updates das Tool herunterzuladen, erhalte jetzt aber sogar den Hinweis, dass Dateien von dem Hoster amazonaws.com als nicht vertrauenswürdig eingestuft werden. Vorher waren da immer Warnungen mit Verweis auf bekannte Viren erschienen, die ein Herunterladen verhindert haben.
Was nun ???
Ergänzung ()

ThirdLife schrieb:
Schau den Link an, denk drüber nach, komm zu einem hoffentlich richtigen Schluss.

Defender sperrt so ziemlich alles, legal oder nicht. Warum weiss vermutlich auch bei MS niemand.

Na ja, dass dürfte schlichtweg eine Übertreibung von Dir sein. Bei den eher seltenen fehlerhaften Identifikationen des Windows Defenders werden die mit dem nächsten MS Scanner Update Release normalerweise eigentlich entschärft, hier scheint aber eher das Gegenteil zu passieren, wie man dem aktuellen Meldungsstand entnehmen kann...
 
Zuletzt bearbeitet:
Baal Netbeck schrieb:
... kann man nicht einfach der Hochrechnung trauen, da die GPUs(vor allem AMD) heruntertakten,
Würde ich net sagen, in dem Sonderfall SoTR wird der minTakt vom AMD-Treiberpaneel ganz gut beachtet!

ggü. heute früh mal noch von 1800MHz auf 2048Mhz angehoben, bringt noch mal mal meeehr
GPU-Schätzwert, minTakt 1800MHz=103fps und mit 2048MHz=114fps.
nice,
chill 57fps wird zu Schätzwert 114fps = 100% Reserve, wenn man denn so will
 

Anhänge

  • SoTR@min2048MHz_smaa4x_chill57fps.jpg
    SoTR@min2048MHz_smaa4x_chill57fps.jpg
    489,7 KB · Aufrufe: 65
Zuletzt bearbeitet:
  • Gefällt mir
Reaktionen: Baal Netbeck
3 Jahre nach dem M1 gibt es weder ein Intel noch ein AMD Notebook, das in Sachen Leistung, Akkulaufzeit und Emissionen konkurrenzfähig wäre.
Intel soll sich mal darum kümmern.
 
Intel und AMD müssen sich halt an X86 halten und schleppen daher viele Altlasten mit sich rum.
Dann noch die größere Modularität die gewährleistet werden muss.

Ich denke selber auch, dass Intel und AMD mehr machen könnten, aber sie haben definitiv mehr Steine im Weg liegen als ARM und Apple.
 
  • Gefällt mir
Reaktionen: SweetOhm
Der Unwinder wird das Ganze in den RTSS integrieren: Link
Ich freue mich schon auf die nächste RTSS-Beta!
 
  • Gefällt mir
Reaktionen: Haldi und GerryB
@Haldi Es macht ja auch total Sinn^^

GPU-Load ergibt sich aus dem Anteil den die GPU an den Frames hat.
"GPU Load = GPU-Busy / Frametime"

Daher ist auch GPU-Busy einfach "Frametime * GPU Load".

Hier auch ein schöner Vergleich, bei dem die GPU-Busy Time direkt hoch ging, als die GPU runtergetaktet hat und daher die Auslastung etwas gestiegen ist.
1693040163539.png


GPU-Busy Deviation: -77%
Die GPU-Busy Times sind also 77% niedriger als die Frametimes

Die GPU Load beträgt 23%. Das haben wir mit dem Sensor service mit geloggt, in Zukunft könnte man sich das auch sparen, denn:

"GPU-Busy / Frametime = GPU Load"
7,6 / 33,2 = 0,228 -> 23%
 
Zuletzt bearbeitet:
  • Gefällt mir
Reaktionen: GerryB und Baal Netbeck
Abgesehen davon, dass man die Werte pro Frametime bekommt und man daher viel genauer einzelne Ruckler analysieren kann, hat die GPU-nusy Zeit also keinen Vorteil
 
  • Gefällt mir
Reaktionen: Taxxor
Haldi schrieb:
Die Wirklich interessante Frage ist nun:
In welcher Situation werden sich diese beiden Werte merklich unterscheiden?
Theoretisch sollten sie sich niemals merklich unterscheiden, weil die Definition dieser GPU-Busy Zeit ja genau das ist, was auch die GPU Auslastung sagt.

Daher kann man mit dem Wert auch keine Aussage treffen, die sagt "1000 / GPU Busy sind die FPS, die du erreichen könntest, wenn deine GPU nicht limitiert wäre", weil dieser Wert nur mit der Auslastung korreliert, aber nicht mit den Taktraten.

Sieht man oben im Bild ja, in dem Moment wo die Karte sich entschieden hat, etwas runter zu takten, ist die GPU Busy Time logischerweise hoch gegangen, daher wären auch die damit umgerechneten FPS niedriger.
In der Realität würde die GPU, wenn sie nicht limitiert wird, aber ja höher takten.

Daher sind die FPS, die man so erreichen kann eigentlich immer höher als das was man aus den GPU-Busy Times ableiten kann, außer die Taktraten waren schon im Maximum, z.B. wenn die Auslastung >80% beträgt.
Aber selbst dann ist es fraglich, ob man das einfach so hochrechnen kann und sagen kann, wenn du bei 80% Auslastung 10ms=100FPS hast und deine GPU-Busy Time folglich ~8ms beträgt, dass du bei 100% Auslastung wirklich 8ms=125FPS hättest.
Ergänzung ()

Baal Netbeck schrieb:
Abgesehen davon, dass man die Werte pro Frametime bekommt und man daher viel genauer einzelne Ruckler analysieren kann, hat die GPU-nusy Zeit also keinen Vorteil
Daher war ich auch verwundert, als Wolfgang hier schrieb, dass sie bei zukünftigen Spieletests nun erst mal PresentMon Beta statt CapFrameX nutzen werden, weil diese Metrik so interessant ist.

Hab dann natürlich schnell mit den Implementierungen dieser Metrik in CapFrameX angefangen, aber bei den ersten Tests dann relativ schnell festgestellt:
Ja, für Nutzer der vorherigen Konsolenanwendung von PresentMon ist das vielleicht interessant, aber für Nutzer von CapFrameX, die schon ewig die GPU Load mitloggen können, bietet sie eigentlich nichts neues.
 
Zuletzt bearbeitet:
  • Gefällt mir
Reaktionen: Baal Netbeck
Aber die Abtastrate ist natürlich schon ein guter Vorteil für die Analyse, ich hab z.B. gerade beim Durchstöbern diese God of War Benches gefunden, bei denen immer ein Rucker gegen Ende auftritt

Hier mal 2 aggregierte 25s Runs:
Beim ersten Run hatte ich das Glück,. dass die Sensor Abfrage genau dann stattgefunden hat und ich so sehen konnte, dass die GPU auslastung eingebrochen ist, der Spike also nicht von der GPU kommt.
Beim zweiten Run hatte ich dieses Glück nicht und könnte nicht sagen, ob der Spike von der GPU kommt oder nicht.
1693048963457.png


Hier würde ich vermuten, dass man mit der GPU-Busy Time an beiden stellen gesehen hätte, dass diese nicht nach oben geht, weil die Frametimes zwar sehr hoch sind, aber durch die geringere Auslastung die GPU Busy Times ca gleich bleiben, wie bei den umliegenden Frames auch.

Und würden sie ebenso an dieser Stelle genau so hoch nach oben spiken, wüsste man, dass es an der GPU liegt.
 
Zuletzt bearbeitet:
  • Gefällt mir
Reaktionen: Baal Netbeck und Haldi
@Taxxor Build #94 gleich mal getestet, funktioniert, wie es soll. Im GPU-Limit Frametimes und GPU-Busy identisch. Im CPU-Limit 62,8% Abweichung.
Fehler in CX: Die Balkendiagramme der Analyse zeigen nur BPU-Busy Average an. Die beiden anderen GPU-Busy Werte werden auch nicht angezeigt, wenn sie aktiviert sind. Und könntest du bitte die Deviation mit in die Balkendiagramme aufnehmen?
 

Anhänge

  • Supo_GPU-Limit.png
    Supo_GPU-Limit.png
    6,1 MB · Aufrufe: 64
  • Supo_CPU-Limit.png
    Supo_CPU-Limit.png
    1,3 MB · Aufrufe: 64
tomcat66 schrieb:
Fehler in CX: Die Balkendiagramme der Analyse zeigen nur BPU-Busy Average an. Die beiden anderen GPU-Busy Werte werden auch nicht angezeigt, wenn sie aktiviert sind.
Die beiden anderen wollte ich eigentlich komplett wieder rausnehmen, weil sie keinen wirklichen Informationsgehalt haben, in der Auswahlliste auf der Analysis hab ich sie wohl vergessen^^
tomcat66 schrieb:
Und könntest du bitte die Deviation mit in die Balkendiagramme aufnehmen?
Die Deviation ist ein Prozentwert, kann also nicht in die Balkendiagramme, maximal als absoluter ms Wert und das ist eher nichtssagend.
Sie steht halt aktuell als Prozentwert im Frametimegraphen, wenn man ihn anzeigen lässt, und ist auch auf der Report Page auswähl- und exportierbar
Ergänzung ()

Hab die beiden Werte jetzt auch wieder in der Analysis drin, aber ich finde die Konvertierung zu FPS echt schwierig, weil das für mich direkt den Anschein erweckt, als hätte man hier einen Wert der sagt "so hohe FPS könntest du haben, wenn deine GPU nicht limitiert werden würde", was der Wert aber ja nicht zuverlässig aussagen kann.

Deswegen möchte ich ihn so gut es geht eigentlich nur in seiner reinen Form als Zeitangabe oder im Vergleich mit anderen Zeiten nutzen, daher überlege ich, die drei Werte auch nur in dem Bar Chart anzeigen zu lassen, wenn man auf frametimes wechselt.
 
Zuletzt bearbeitet:
  • Gefällt mir
Reaktionen: Baal Netbeck und tomcat66
Zuletzt bearbeitet:
  • Gefällt mir
Reaktionen: tomcat66, ThirdLife, syfsyn und eine weitere Person
man dankt
 
  • Gefällt mir
Reaktionen: GerryB
GPUbusy zusammen mit CPUmaxThreadLoad zeigt eigentlich ganz gut, ob wo ein Bottleneck ist.
Im Idealfall läuft keines von Beiden mit 100% wenn man sein persönliches Fps-Limit verwendet.
(Chill57fps@60Hz-Moni)

CP2077_GPU-busy.jpg


Das man die GPU-Auslastung über den minTakt manipulieren kann, hatte ich bereits in SoTR gezeigt.
Also könnte man bei Rucklern mal den minTakt schrittweise anheben.(sofern man net im CPU-Limit ist)
 
Endlich werd ich RTSS los!
 
Zurück
Oben