Du verwendest einen veralteten Browser. Es ist möglich, dass diese oder andere Websites nicht korrekt angezeigt werden. Du solltest ein Upgrade durchführen oder einen alternativen Browser verwenden.
BerichtPresentMon Beta: Intel mit neuem Benchmark-Tool und neuer Messmetrik
Wäre ja zu schön gewesen, wenn das Tool (egal ob PresentMon oder CapFrameX) die möglichen FPS einfach selbst ausspucken würde.. Anstatt dass ich mir immer noch manuell die Mühe machen muss es zu berechnen.
So nach dem Motto... hey, wenn du eine bessere CPU hättest, dann würdest du mit deiner Grafikkarte hier jetzt mind. XX Fps mehr erreichen.
Der Punkt ist auch irgendwo, das du da mit FPS garnichts anfangen kannst, weil die viel zu ungenau sind, das ist etwas gemitteltes über eine volle sekunde, da kannste 60fps haben und 250ms hackt es einfach nur und es ist komplett unspielbar, aber eben 60fps
Klar verstehen die meisten besser was FPS ist, es ist eine bekanntere größe, aber uinbrauchbarer für so Fehlersuchen.
Das liegt daran das der Wert FPS "Bilder pro Sekunde" eigentlich gar nicht existiert und immer nur ein Mathematischer Mittelwert ist.
Was physikalisch existiert ist die RenderZeit, die benötigt wird bis der Computer EIN Bild darstellt. Und die ist halt so meistens 16.6ms wenn man alle 16.6ms ein Bild darstellt ergibt das am Ende diese 60 FPS.
Und weil es einfacher ist den Leuten zu erklären das sie auf ihrem 60hz Monitor mit dieser Graka 60FPS bekommen und somit alles in Ordnung ist, anstatt das sie mindestens alle 16ms ein neues Bild benötigen, hat irgendjemand die Metrik FPS erfunden und erfolgreich verbreitet.
Ich wüsste zu gern wer das war. Hier jemand Ahnung von IT Geschichte? Oder kommt das noch aus der Film Branche?
Payne19 schrieb:
So nach dem Motto... hey, wenn du eine bessere CPU hättest, dann würdest du mit deiner Grafikkarte hier jetzt mind. XX Fps mehr erreichen.
Genau das ist eben noch nicht bewiesen! Theoretisch ja.
Praktisch kann aber gut sein das da noch 2-3 andere Faktoren mit reinspielen die das verhindern.
Der Punkt ist auch irgendwo, das du da mit FPS garnichts anfangen kannst, weil die viel zu ungenau sind, das ist etwas gemitteltes über eine volle sekunde, da kannste 60fps haben und 250ms hackt es einfach nur und es ist komplett unspielbar, aber eben 60fps
Dafür hast du ja die Perzentil FPS oder die x%Low FPS, mit so einem 250ms Hänger in einem Benchmark Run hättest du dann halt bei den 1% lows nur 4FPS stehen.
Wird real trotzdem alles in ms gerechnet, nur die finale Ausgabe ist in FPS damit sich auch jeder was drunter vorstellen kann.
Hab wohl etwas zu wenig geschlafen gestern....
Wenn man kein CPU Limit hat, macht man sich einfach selbst eins!
CPU Affinity eingestellt im Task Manager!
Und die Resultate vom Internen Benchmark:
Interessant ist hierbei das bei 2 und 4 Threads der GPUbusy Wert sehr sehr ähnlich ist, und auch wenn 4 Threads nur 78% GPU Bound ist, so sind die effektiven FPS nicht sooo weit vom msGPUactive wert entfernt.
Nur bei einem Thread wo das spiel im KOMPLETTEN CPU Limit ist... (ernsthaft, Lädt ca 10 Minuten lang bis Benchmark endlich startet....) stimmt der GPUbusy wert nicht überein mit 2Threads und 4 Threads.
Wir können also sagen das sobald sich der msGPUactive Wer zu gross vom msBetweenPresents unterscheided ist keine korrekte Aussage mehr möglich "Wie viel würde die GPU wirklich schaffen mit neuer CPU"
Wir können also sagen das sobald sich der msGPUactive Wer zu gross vom msBetweenPresents unterscheided ist keine korrekte Aussage mehr möglich "Wie viel würde die GPU wirklich schaffen mit neuer CPU"
Ich hab gerade mal den Test mit verschiedenen FPS Limitern gemacht, einmal RTSS, einmal nvCP und einmal Ingame und das ganze dann gegen die tatsächlichen FPS ohne Limit gestellt.
Zumindest hier kann man mit dem GPU-Busy Wert nix anfangen, keiner der Werte war in der Nähe von dem was ich wirklich erreichen konnte.
Man kann aber immerhin sehen, dass der Limiter von RTSS wohl recht ähnlich wie der vom Spiel arbeitet, während der vom Treiber komplett anders ist.
Ergänzung ()
Hier noch die Taktraten und Auslastungen der 3 limiter, man sieht auch hier, dass nvCP anders zu arbeiten scheint, als die anderen beiden.
60fps RTSS
Auslastung 29,7%
Takt 1919MHz
60fps nvCP
Auslastung 49,8%
Takt 841MHz
60FPS Ingame
Auslastung 32,6%
Takt 1859MHz
Und was erkennt man hier noch?
Wenn man die 60FPS bei den jeweiligen GPU Auslastungen auf 100% hochrechnet, kommt man bei 202, 120 und 184 FPS raus.
Also alles im Bereich von 2-3% um den Wert, den PresentMon als GPU-Busy ausspuckt.
Selbst ohne Limit bzw mit dem 250er Hard-Limit vom Spiel passt es.
Hier hab ich 93,7% Auslastung, auf 100% hochgerechnet kämen 267FPS raus, gerademal 1% entfernt vom GPU-Busy Wert.
Bei meinem allerersten 89,9FPS Limit Bench von Seite 2 genauso, hier waren es 58,9% Auslastung, normiert auf 100% kommen 152,6 raus, der GPU-Busy Wert sagte 148,6.
Also bisher würde ich anhand dieser Ergebnisse vermuten, dass da wirklich nichts anderes rauskommt als das, was man bisher auch schon immer selbst errechnen konnte, wenn man FPS und GPU Auslastung nimmt und auf 100% normiert, was damit auch genauso wenig aussagekräftig ist, solange man nicht den Takt bei seiner GPU festgesetzt hat.
Ich vermute sehr stark, dass Wolfgang bei seinem Test in 1080p mit den 78,9 FPS
und den 145,3 GPU-Busy FPS eine durchschnittliche GPU Auslastung von ca. 54% hatte.
Macht auch Sinn, wenn man drüber nachdenkt: Die Auslastung hängt mit den Taktraten zusammen und beide kombiniert beschreiben, wie schnell die GPU arbeitet und hängen damit direkt mit dem GPU Busy Wert zusammen.
Wenn der nvCP Limiter die Taktraten auf <1GHz drückt, braucht die GPU natürlich länger für den Frame, als bei einem Limiter, der sie mit 1,9GHz laufen lässt.
Aber dann hat man von der Geschichte doch den gleichen Erkenntnisgewinn, denn man bisher rein über die GPU Auslastung auch schon hatte, nämlich so gut wie gar keinen. Man weiß, die GPU könnte mehr liefern, aber wie viel mehr ist völlig unklar, solange wir dynamische Taktraten haben.
Auch auf den vorgestellten Nutzen im GN Video mit dem frametime Graphen bezogen: Ja, hier sieht man dadurch dass die frametimes hoch gehen aber die GPU-Busy times unten bleiben, dass man aus dem GPU Limit raus war und irgendwas anderes limitiert hat.
Genau das gleiche sieht man in CapFrameX aber auch schon ewig, wenn man den Verlauf der GPU Auslastung einblendet, denn die wäre an der Stelle dann entsprechend gesunken, wodurch man auch direkt sieht, dass man nicht mehr im GPU Limit war.
Wenn wir im overlay die Prozente anzeigen, die die GPUBusy FPS über den realen FPS liegen, dann gehe ich davon aus, dass dieser Wert recht genau der Kehrwert der GPU Auslastung sein wird, sprich wenn ich ~80% GPU Load habe, wäre der GPUBusy Vorsprung ~25%.
Edit:
Ein potenzieller Vorteil fällt mir dann aber doch noch ein: Man braucht mit diesem Wert nun keine zusätzlichen Telemetriedaten mehr erfassen um zu wissen, ob man zum Zeitpunkt X im GPU Limit war oder nicht.
Wer bisher mit CapFrameX die Sensordaten mitgeloggt hat, hatte sowieso immer die GPU Auslastung mit aufgezeichnet, daher bietet der GPU-Busy Wert hier nicht wirklich einen Vorteil, außer, dass man nun für jeden einzelnen Frame einen Wert bekommt, während unsere Sensordaten nur einen Wert alle 250ms geliefert haben. Da konnten minimale CPU Limits über 100ms schon mal unentdeckt bleiben, wenn nicht genau zu dem Zeitpunkt ein Wert geloggt wurde
Wer bei Intel nicht erstmal skeptisch ist und die Motive versucht zu hinterfragen und das wichtigste die Ergebnisse gegenchekt, der lädt die geradezu dazu ein wieder zu bescheissen, das deren hemmschwelle da besonders gering ist als Firma haben die schon bewiesen.
@aid0nex du kommst halt jetzt so an wie.. "mamma mamma, aber die anderen Kinder ..."
In dem GPU busy time Wert sehe ich jetzt noch keinen wirklichen Vorteil.
Wie Taxor schon gezeigt hat, kann man nicht einfach der Hochrechnung trauen, da die GPUs(vor allem AMD) heruntertakten, wenn sie nicht richtig gefordert werden.
Wo ich in Zukunft Vorteile sehe, ist wenn noch weitere Werte dazu kommen, wie es im Gamers Nexus Video geteasert wurde....also detailierte Infos darüber, wie die Anteile der Rechenzeit der CPU Frametimes und der GPU Rechenzeit zusammengesetzt sind.
Dann kann man in Zukunft eventuell sehen, was der genaue Grund für ein absinken der Frametimes war...Nachladeruckler, Raytracing, PCIe Bandbreite, physikberechnung, KI, Drawcalls.....usw.
Das wäre dann hilfreich für eine gezielte Bekämpfung der Problemstellen und für die Spieleentwickler eine große Hilfe bei der Optimierung.
Dann kann man in Zukunft eventuell sehen, was der genaue Grund für ein absinken der Frametimes war...Nachladeruckler, Raytracing, PCIe Bandbreite, physikberechnung, KI, Drawcalls.....usw.
Das wäre dann hilfreich für eine gezielte Bekämpfung der Problemstellen und für die Spieleentwickler eine große Hilfe bei der Optimierung.
Alle Regler auf MAXED kann halt für manche Systeme (CPU oder/und GPU) too much sein.
Deswegen gabs früher mal OptimierungsGuides bei HUB, z.Bsp. für RDR2.
(wo Waterphysik sooo reinknallt)
Taxxor schrieb:
Man weiß, die GPU könnte mehr liefern, aber wie viel mehr ist völlig unklar, solange wir dynamische Taktraten haben.
Noch mal mit höherem minTakt, 1800 statt 1500MHz, nachgetestet, ... sollte jetzt nicht mehr sooo schwanken.
Und tatsächlich gibts ein anderes Ergebnis. GPU-Schätzung steigt von 95fps auf 103fps.
(in Post#45 hatte ich minTakt=1500MHz)
Wers ganz genau wissen will, könnte in MPT-FeatureControl noch ds gfxclk deaktivieren.
(das ist der Stromsparmodus für den GFX-Clock)
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!
PresentMon 0.5 Beta wird noch richtig Open Source, genauso wie es aktuell PresentMon Legacy ist. Vermutlich am Montag soll es soweit sein. Ein bisschen Geduld noch
Payne19 schrieb:
Wäre ja zu schön gewesen, wenn das Tool (egal ob PresentMon oder CapFrameX) die möglichen FPS einfach selbst ausspucken würde.. Anstatt dass ich mir immer noch manuell die Mühe machen muss es zu berechnen.
Das ist auch durchaus eine Sache, die ich bei Intel angesprochen habe. Kleine Baustellen gibt es halt noch eine Menge, ist eben noch der Anfang.
Haldi schrieb:
Wir können also sagen das sobald sich der msGPUactive Wer zu gross vom msBetweenPresents unterscheided ist keine korrekte Aussage mehr möglich "Wie viel würde die GPU wirklich schaffen mit neuer CPU"
Zumindest das Frame-Pacing geht bei manchen Spielen gerne mal kaputt, wenn die GPU gar keine Rolle spielt und alles an der CPU hängt. Dafür scheinen die Engines alle nicht ausgelegt zu sein. Vielleicht ist das dann auch ein ähnlicher Effekt, den man da beobachten kann.
Taxxor schrieb:
Ich hab gerade mal den Test mit verschiedenen FPS Limitern gemacht, einmal RTSS, einmal nvCP und einmal Ingame und das ganze dann gegen die tatsächlichen FPS ohne Limit gestellt.
Ich vermute sehr stark, dass Wolfgang bei seinem Test in 1080p mit den 78,9 FPS
und den 145,3 GPU-Busy FPS eine durchschnittliche GPU Auslastung von ca. 54% hatte.
Wenn du einen FPS-Limiter aktivierst, stoppt die GPU ja auch mal den ganzen Rendering-Prozess, da die Render-Queue ja eh schon voll ist. Da bringt es dann nichts, dass ein Frame schnell gerendert wird, du siehst quasi auch die Pausen die die GPU macht.
Zu deinem zweiten Punkt:
Das funktioniert, ich hatte 53,9 Prozent
Kann man in zukünftigen Tests vielleicht ein oder zwei Spiele auch mit unterschiedlichen RAM-Geschwindigkeiten testen, um zu zeigen ob schnellerer Ram das CPU-Limit verschiebt?
Wenn du einen FPS-Limiter aktivierst, stoppt die GPU ja auch mal den ganzen Rendering-Prozess, da die Render-Queue ja eh schon voll ist. Da bringt es dann nichts, dass ein Frame schnell gerendert wird, du siehst quasi auch die Pausen die die GPU macht.
Klar, mir ging es ja darum zu sehen was dieser Busy Wert generell aussagt.
Und wie man sieht, sind Schlussfolgerungen wie „die GPU könnte eigentlich X FPS liefern“ damit nicht möglich.
Nochmal bestätigt durch deinen eigenen Test ohne Limiter:
Wolfgang schrieb:
Zu deinem zweiten Punkt:
Das funktioniert, ich hatte 53,9 Prozent
Also könntet ihr auch weiterhin einfach auf die Auslastung schauen, macht keinen Unterschied. GPU busy nimmt einem im Grunde nur einen Rechenschritt ab.
Ich hoffe doch schwer die grossen Entwickler Studios haben da bessere Möglichkeiten zur Analyse direkt in der Engine integriert.
Wobei... wenn ich da Jedi Survivor oder Remnant 2 angucken wage ich das irgendwie zu bezweifeln -.-
P.S
Im letzten community benchmark hat doch einer ne rtx4090 mit i7 6600k gepart gehabt oder? Erinnert sich gerade noch wer wer das war? Finde das nicht mehr
Das wäre sicher ein interessanter Test.
Das könnte man ja zumindest für die Dauer des Benchmarks verhindern. Mit Nvidia-smi z.B. Dadurch würde man doch verlässliche GPU-busy Werte bekommen, oder?
Aber das will man doch nicht, wenn man aussagekräftige Benchmarks haben will, die Zeiten wo die Karte den Takt eunterschraubt tragen schließlich dazu bei danach wieder für gewisse Zeit einen höheren Takt anfahren zu können. Da veränderst du halt das standardverhalten, das alle GPU bei den Nutzern zu hause gewöhnlich haben.
Auch die AAA Titel sind ja meist eingekaufte Engines und die Entwickler haben vermutlich selbst keine Ahnung warum es ruckelt... Und das Herausfinden und fixen ist scheinbar keine Priorität.
Aber mit einem Tool, dass es jederman ermöglicht die Schwachstellen relativ einfach zu identifizieren, wären sie eher unter Druck auch etwas dagegen zu unternehmen.
tomcat66 schrieb:
Das könnte man ja zumindest für die Dauer des Benchmarks verhindern.
Ich wüsste nicht wie man das bei AMD GPUs macht.
Ich habe aber auch keine der aktellen Karten.
Bei Vega gab es 7 PStates und man konnte den Karten die unteren verbieten, aber wenn die die GPU Auslastung zu weit unten war, wurde das ignoriert und die Karte hat trotzdem heruntergetaktet.
Und bei meiner Radeon VII gibt es eine Spannung/Takt Kurve, die man zwar theoretisch verkürzen kann, aber das hält die Karte nicht davon ab trotzdem herunterzutakten.
Also ich kenne da keinen Weg den Takt zu fixieren.
Alexander2 schrieb:
Aber das will man doch nicht, wenn man aussagekräftige Benchmarks haben will,
Die Idee war ja, dass man auch im CPU Limit einen Wert für die Rechenzeit der GPU hat und daraus errechnen könnte, was die GPU leisten könnte wenn sie nicht limitiert würde.
Nicht limitiert würde die Karte aber boosten....im CPU/FPS Limit verfälscht das Stromsparen aber die GPU-Busy Zeit.
Es wäre halt schön, wenn man die Karte auf 2GHz fixieren könnte(wenn 2GHz der typische Boost unter Vollast wäre)...dann kann man auch mit z.B. 60 FPS im CPU Limit die GPU Busy Zeit nutzen und sehen, dass diese z.B. bei 5ms liegt und die Karte theoretisch 200 FPS schaffen würde.
Wenn die Karte aber stromspart weil sie unterfordert ist, wird sie nicht in den möglichen 5ms fertig werden sondern in z.B. 10 ms.....dann würde man fälschlicher Weise annehmen, die Karte könnte 100 FPS liefern, wo sie in Wahrheit 200 liefern kann.
Da sehe ich zwar so Dinge wie "GFX Minimum = 700" aber die Karte geht ja auch unter 700MHz....denke also nicht, dass ich die Karte damit fixieren kann.
Ich spiele aber auch ungerne mit den MorePowerTool rum wenn ich nicht genau weiß was es bewirkt.
Aber wenn jemand das bestätigen könnte wäre das interessant.
Und laut Intel sollen alle auf den Wert Zugriff bekommen. So wie ich das verstehe, vermutlich ab Montag. Vielleicht haben einige (inklusive CapFrameX) ja auch schon Zugriff drauf, wer weiß.
