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

[Alexander2]

@bad_sign ja, schön ne? haben die lange und hart dran gearbeitet sich das zu verdienen. Und sie bekommen es.

 

[Haldi]

Hm, AMD-CPUs kennt das Tool natürlich (noch) nicht. Bild 1
Und auch von der GPU können noch nicht alle Daten ausgelesen werden. Bild 2.

Unglaublich! Releasen die einfach eine unvollständige Beta version!
Was erlauben die sich eigentlich?

btw -.-
Danke für die News....
eigentlich wollte ich heute Baldurs Gate 3 Weiter zocken und nicht den ganzen tag Benchmarken -.-

 

[Wolfgang]

Was genau ist an einem Kommandozeilenprogramm umständlich. Ich lege da jetzt mal die Finger auf die Wunde. In Ordnung?

Ich gebe da gerne zu: Ich komme aus einer Windows-Welt, als DOS habe ich nur als kleines Kind erlebt und mit Linux komme ich von vorne bis hinten nicht klar. Ich will kein Kommandozeilenprogramm, für mich ist sowas mega umständlich.

Aber PresentMon Beta kann ja beides, umso besser würde ich sagen!

@Wolfgang Escape from Tarkov ist für einen CPU-Limit-Test prädestiniert. Es existiert quasi nur um von CB auf sein CPU-Limit getestet zu werden. Und eventuell auf andere Probleme wie u.a. Memory-Leaks deluxe

Ich denke, dass die Metrik generell bei neuen Spiele-Releases super hilfreich und interessant sein kann. Man muss jetzt mal halt schauen, wie man die Metrik am besten einsetzen kann. Bei generellen GPU-Releases sehe ich es dagegen nicht so.

@Wolfgang erste Versuche, die neue Metrik einzubinden, laufen
Der Wert ist übrigens auch ganz cool, um zu sehen wie viel Luft man noch hat, wenn man nen FPS Limiter drin hat ^^


Edit 03:13: weitere Fortschritte^^
(diese 10,11s Aufnahme kommt übrigens noch von Presentmon direkt, von einer auf 10s gestellten Aufnahme. Komisch, dass ausgerechnet das Tool vom Entwickler selbst so unpräzise ist)

Schaut doch schonmal ganz gut aus soweit!
Ja, das mit den nicht ganz eingehaltenen Zeiten ist mir auch schon aufgefallen...Ich habe Intel eine lange Liste mit Verbesserungsvorschlägen geschickt, das hab ich aber leider vergessen. Mal nachholen.

 

[polyphase]

Für alle die meinen, das Intel das Tool zu ihren Gunsten "manipuliert".
Das Tool ist OpenSource, dann schaut euch den Programmcode doch einfach Mal selbst an!




Hier gibt es auch schönes Erklärvideo zum Tool und der neuen Funktion:

YouTube

An dieser Stelle steht ein externer Inhalt von YouTube, der den Forumbeitrag ergänzt. Er kann mit einem Klick geladen und auch wieder ausgeblendet werden.

YouTube-Embeds laden

Ich bin damit einverstanden, dass YouTube-Embeds geladen werden. Dabei können personen­bezogene Daten an YouTube übermittelt werden. Mehr dazu in der Datenschutzerklärung.

YouTube-Embeds laden

Datenschutzerklärung

 

[GerryB]

... Macht dieses GPU Busy dann im Prinzip was ähnliches, was man bei manchen integrierten Benchmarks, wie z.B. SotTR hat, wo man CPU und GPU FPS aufgeschlüsselt hat?

Jo, da könntet Ihr mal vergleichen, wobei ich denke, das SoTR@chill vllt. nur die GPU-Auslastung hernimmt und damit dann die Fps von CPU-Render zu nem fiktiven GPU@100%Auslastung-Wert hochrechnet, weil die GPU ja net wirklich soviel Fps berechnet.
Bei NV-Grakas dürfte es mit Fps-Limit per RTSS ähnlich sein. (CPU-Render wird eingebremst)

z.Bsp. mal ein sparsames daily Setting (128,8Wtgp) mit Chill=57fps@60Hz-Moni bei avg. 60% Auslastung(?)
Fehlerquelle der ganzen Aktion= die Volt/MHz-Kurve ist ja net konstant und bei 60% Last nur im Sparmodus.
Das wird gerade mit UVen und kleinen minGFX seeehr sparsam = avg.50Wtgp@avg.730mV.
Dagegen bei 100% Last wäre man schon im exponentiell ansteigenden Bereich!?

Das kann natürlich jetzt reiner Zufall sein, das bei Chill57fps=60%(?) dann 95fps-GPU@100%(?) da stehen.
edit: Da habe ich sogar gut geschätzt, .... avg.3D-Last=60% .... siehe log.file
Die 3D-Last richtet sich wohl mehr nach eff.Takt zu "theoretischem" maxTakt oder ROP-Last als nach Powerlimit.
(bei den 6000ern könnte der theor.maxTakt der Wert aus dem MPT-Frequency-Tab sein)

 

[Ned Flanders]

USB kommt von Intel, Thunderbolt kommt von Intel, UEFI kommt von Intel, ATX kommt von Intel, XMP kommt von Intel, praktisch der ganze x86 Befehlssatz kommt ebenfalls von Intel. Ist nun mal so, man muss die Welt nicht jedes mal neu erfinden, wer meint es besser zu können, nur zu.

Das ist ja nicht das Problem. Was viele eben in Erinnerung haben ist die undokumentierte Schieberei Intels gerade bei Benchmarks, aber auch darüber hinaus. Stichwort Sysmark, PCMark, MKL... ich verlinke es Dir bei Bedarf natürlich, aber Du kennst die Stories ja.

Ist doch klar, dass die Leute da misstrauisch werden und das ist ja auch gut so, wenn auch in diesem konkreten Fall wohl eher nichts dahintersteckt.

Ich verstehe aber auch nicht, warum AMD und VIA etc. nicht jeweils eine Kleinserie CPUs mit gefakter CPUID produzieren und ein zwei man Büro damit beschäftigen solche Fälle zu identifizieren.

 

[Haldi]

Mhmmm
ich denke ich habe nicht so das Optimale Setup im diese funktion zu Testen.....

Alles 30 Sekunden schnipsel.

(K öffnet das Inventar.... darum der Drop GPU load und FPS Boost....)

Ausser Star Citizen welches zum Teile üble Nachlade Ruckler hat und daher GPU Load+FPS drops verursacht läuft eigentlich alles extrem rund, genau so wie es sollte....

 

[schneeland]

CapFrameX arbeitet wohl auch schon an einer direkten Integration: Twitter (via Videocardz).

 

[Haldi]

Dachte kumpel mit seinem i9 9900k würde vielleicht eher Resultate sehen....
War leider ein Trugschluss. Jedi Survivor ist einfach extrem mies optimiert.
Und AMD Fidality Upscaling benötigt die ganze CPU leistung!

Normal:

mit Upscaling Quality:

Besonders verwirrend ist dabei das wenn man sich durch die Welt bewegt sinkt die GPU Busy wesentlich tiefer runter. Sobald man dann stehen bleibt gleichen sich die FPS wieder an. Wenn man dann wieder davon läuft steigen die Frametimes wieder wobei die GPU Busy gleich bleiben.
Echt komisch wie Fidelity Upscaling da funktioniert.

Müsste das ganze wohl mal mit DLSS testen...

 

[flaphoschi]

Ich gebe da gerne zu: Ich komme aus einer Windows-Welt, als DOS habe ich nur als kleines Kind erlebt und mit Linux komme ich von vorne bis hinten nicht klar. Ich will kein Kommandozeilenprogramm, für mich ist sowas mega umständlich.

Nun. Auf die Gefahr hin die gleiche Frage zu stellen: Was ist umständlich?



Pfeiltaste nach oben drücken, um das gleiche Kommando nochmal auszuführen (Benchmarks und so…)? CTRL+R drücken und suchen was die Lösung vor zwei Monaten war? Sich von der Shell den Kommandonamen, die Optionen und Parameter per Autocomplete vervollständigen lassen? Und wenn man keinen Plan hat „man kommando“ und dann wird es einem kurz und bündig erläutert.

Oder ist das falsche Erfahrung „Shell == CMD.EXE“? Die CMD.EXE ist technisch keine Shell und kein Terminal (eher Pesudomischung aus Beidem)? Oder weil die Leute kein Zehn-Finger-Tippen gelernt haben?

Ich feier ja GNOME dafür, dass man seit bald 13 Jahren alles als Kommando eintippen kann. Die Maus ist für Shooter und GIMP, braucht sonst alles ewig mit dem Geklicke…

Microsoft hechelt halt auch verzweifelt hinterher. Inzwischen kann man ja diese Windowstaste drücken und das Ding macht nach einer Eingabe halbwegs was man will. Und jetzt versuchen sie so einen Art Terminalklon zu vermarkten. Meanwhile at Linux:

Hey Leute. Meint Ihr OpenGL reicht noch? Ich denke wir sollte das Terminal auf Vulkan portieren. Wir brauchen mehr Leistung, mehr Farben, mehr Prompts. Und was kann eigentlich die Shell noch für mich tun?

 

[Payne19]

Wo genau steht das nun, wie viel FPS die GPU könnte, wenn die CPU nicht limitieren würde?

 

[ZashIN]

Das Tool wird als Open Source angegeben (auch von Intel selbst), jedoch ist der Quellcode der neuesten Version 0.5 Beta (noch) nicht veröffentlicht?!
Zumindest ist auf Intels Release Seite nur der Quellcode des "legacy" PresentMon SDK auf GitHub verlinkt, was der alten Version 1.8 von 2022 (Release im März, letzter Commit im November) entspricht.

Korrigiert mich bitte, falls ich einen neuen Link zum Quellcode übersehen habe.
Anderenfalls ist die Angabe klar falsch, das Tool ist in der 0.5b Version noch nicht Open Source!

 

[Taxxor]

Korrigiert mich bitte, falls ich einen neuen Link zum Quellcode übersehen habe.
Anderenfalls ist die Angabe klar falsch, das Tool ist in der 0.5b Version noch nicht Open Source!

Sollte ab Montag auf Github aufschlagen.
Was schon sehr schnell ist, bie FSR 2.2 hats Monate gedauert, bis der Code öffentlich gemacht wurde^^

Wo genau steht das nun, wie viel FPS die GPU könnte, wenn die CPU nicht limitieren würde?

Exakt das ist der GPU-Busy Wert, dem hier in der News ein ganzer, langer Absatz gewidmet wurde.

 

[MehlstaubtheCat]

Wo genau steht das nun, wie viel FPS die GPU könnte, wenn die CPU nicht limitieren würde?

Nein, so funktioniert das nicht!
Es zeigt nur an ob die CPU mehr FPS berechnen kann als die Grafikkarte liefern kann.
Wenn die Frametimes nicht der GPU Time entsprechen, das jetzt vereinfacht gesagt!

 

[Payne19]

Wie kommen dann solche sätze hier zustande? "GPU Busy verrät dann, dass die Grafikkarte ohne Ende Leistungsreserven hat: 145,3 FPS wären laut der GPU-Busy-Metrik möglich, wenn der Prozessor unendlich schnell wäre."

Will es nur verstehen.
Muss ich das anhand mit den Werten, die mir das Tool ausspuckt, selber errechnen?

 

[syfsyn]

Und genau das ist das interessante daran und wenn das in capframex drin ist wird es perfekt für benches da man dann definitiv die min fps herausfinden kann wenn eine andere cpu verwendet wird.
Das wird aber dazu führen das GPu test nicht mehr Balken haben sondern Diagramme
Alternative wäre mehrere Balken mit gpu load
Die Diagramm Lösung wäre aber nur mit wenigen gpu möglich maxed 3 da dann 6 linien sind eine gestrichelt als cpu fps eine gpu fps gleiche Farbe
Sonst wird es unübersichtlich Hintergrund schwarz bzw grau gpu Linie je Modell in blau rot grün
In riva turner wäre es als graph interessant da könnten dann die frametimes weg

 

[GerryB]

man wüsste, ob sich ein Aufrüsten der CPU für das Game lohnt

 

[Taxxor]

Es zeigt nur an ob die CPU mehr FPS berechnen kann als die Grafikkarte liefern kann.

Genau umgekehrt.
GPU-Busy ist, was die GPU leisten könnte, wenn nichts anderes limitiert.
Im GPU Limit sind beide Werte gleich hoch, im CPU Limit ist der GPU-Busy Wert niedriger bzw in FPS umgerechnet höher.

Ergänzung (19. August 2023)

Muss ich das anhand mit den Werten, die mir das Tool ausspuckt, selber errechnen?

Wenn du nur die rohdaten von dem Tool nimmst, ja.
Die Rechnung ist aber sehr simpel denn die Zeiten pro Frame bekommst du ja.
1000/ms =fps und andersrum 1000/fps=ms.

Also die gpu könnte in dem Fall im Schnitt alle 6,88ms ein Bild ausgeben, wenn sie auf nichts anderes warten müsste, was im Schnitt 145 Bilder pro Sekunde entspricht.

 

[Alexander2]

1000 geteilt durch die Zeiten ergeben dann die fps

Das ist Dann korrekt, wenn wie in einer Idealen Welt Eine ganze Sekunde lange alle weiteren Frames mit identischem abstand Folgen.

Zu erwarten ist aber eine immer wenn evtl. auch nur leicht schwankende Renderzerit. Also wenn er einen genauen FPS Wert mit seinen Daten haben wollte müsste er mehr aufwand betreiben, wie zum Beispiel immer Checken, wieviel Bilder in eine Sekunde Passen anhand der millisekunden Frametime Werte der aneinander folgenden Bilder.

 

[Taxxor]

@Alexander2 wir Mitteln nicht nach Sekunden, wir wandeln absolut jede frametime in FPS um.

Hat ein bench 2000 frames haben wir auch 2000 FPS Werte die durch 2000 geteilt die avg fps ergeben.

Alternativ mitteilt man erst die 2000 frametime werte, wo dann eben 6,88 rauskommt und wandelt das in FPS um. So gibts auch weniger Rundungsfehler.

Nur so kannst du ja auch die perzentile berechnen.

Will man wirklich für jede Sekunde einen gemittelten FPS Wert haben(bieten wir zumindest in grafischer Form auch an mit 250, 500 oder 1000ms intervall), sammelt man solange die frametimes his deren Summe 1000 erreicht und mitteilt dann immer diesen Wert.