-
Mitspieler gesucht? Du willst dich locker mit der Community austauschen? Schau gerne auf unserem ComputerBase Discord vorbei!
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.
Du solltest ein Upgrade durchführen oder einen alternativen Browser verwenden.
Test Spider-Man Remastered im Test: Eine richtig schicke PC-Version mit Raytracing, DLSS & FSR 2.0
Das ust ja ein seltsames Verhalten.W0dan schrieb:Ich hab ja Gsync, aber mit FPS Limit ruckelts trotzdem permanent.
Wenn ich auf 60 Hz stelle und das Spiel ins Vsync limit laufen lasse, ist es deutlich smoother.
Auch der Energiehuger des 5800x über alle Frameraten hinweg. Oder wird die hohe Last tatsächlich durch das fehlende direct storage verursacht? Oder die minen einen CPU coin im Hintergrund 😉
O
Otterliebe
Gast
Das Spiel scheint diverse Probleme mit den Schatten und der Lichtdarstellung bei RX4XX/RX5XX Karten zu haben. Konnte ich mit den aktuellen 12.8.1 Treiber bei mir exakt genauso wie in den unteren Videos beobachten.
Läuft soweit bei mir auch mit der betakten RX570 + Ryzen 3600 mit 50-60fps. (Preset: Hoch, FSR2.0 auf Quality). Ab und zu nur irgendwelche kurze FPS-Einbrüche, wenn dieser wohl etwas nachlädt. Hoffe das wird noch gefixt.
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.
Ich bin damit einverstanden, dass YouTube-Embeds geladen werden. Dabei können personenbezogene Daten an YouTube übermittelt werden. Mehr dazu in der Datenschutzerklärung.
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.
Ich bin damit einverstanden, dass YouTube-Embeds geladen werden. Dabei können personenbezogene Daten an YouTube übermittelt werden. Mehr dazu in der Datenschutzerklärung.
Läuft soweit bei mir auch mit der betakten RX570 + Ryzen 3600 mit 50-60fps. (Preset: Hoch, FSR2.0 auf Quality). Ab und zu nur irgendwelche kurze FPS-Einbrüche, wenn dieser wohl etwas nachlädt. Hoffe das wird noch gefixt.
Schinken42
Commander
- Registriert
- März 2021
- Beiträge
- 2.319
Doch. Das ist doch der Witz. Egal in welcher Auflösung man im CPU Limit ist, CPU Limit bleibt CPU Limit.Czk666 schrieb:aber wir bekommen auch nicht mind. die Frames welche die Benchmarks in 720p zeigen wenn wir im CPU Limit sind?
Alphanerd schrieb:Auch der Energiehuger des 5800x über alle Frameraten hinweg. Oder wird die hohe Last tatsächlich durch das fehlende direct storage verursacht?
Wenn Nixxes schon gesagt hat, dass es an Decompression liegt, dann wird es auch vermutlich daran liegen...
Lässt sich dann auch nicht mit einem Patch beheben und wird in den nächsten PC-Ports von Playstation 5 Titeln (auf der PS5 wird Direct Storage wohl bei fast allen Titeln genutzt) dann vermutlich ebenfalls eine große Rolle spielen.
Ist halt die Frage, was hat RT mit Dekompression zu tun. Würde eher auf BHV und die dafür benötigte CPU-Last setzen, die wohl nicht von der GPU sondern von der CPU geleistet wird.Beg1 schrieb:Wenn Nixxes schon gesagt hat, dass es an Decompression liegt, dann wird es auch vermutlich daran liegen...
Lässt sich dann auch nicht mit einem Patch beheben und wird in den nächsten PC-Ports von Playstation 5 Titeln (auf der PS5 wird Direct Storage wohl bei fast allen Titeln genutzt) dann vermutlich ebenfalls eine große Rolle spielen.
- Registriert
- Nov. 2002
- Beiträge
- 8.928
So wie ich das verstehe (keine Garantie) ist nicht die Anzahl der Strahlen das CPU-lastige bei RT, sondern das erstellen der BVH-Struktur. Und die sollte sich mit mehr Auflösung nicht ändern. Zumal die Anzahl der Strahlen und die Auflösung der Reflexionen wieder zwei verschiedene paar Schuhe sind. Aber hier gibt es sicher Leute, mit mehr Ahnung als ich was das anbelangtleonM schrieb:Also die CPU-Last ist unabhängig von der Auflösung ? Also bezogen auf RT, dachte immer, dass die Strahlenmenge mit der Auflösung skaliert und je mehr Strahlen, desto mehr CPU-Last. Ist also doch nicht der Fall, sprich, die Strahlenmenge ist unabhängig von der CPU-Last und geht nur auf die Last der GPU?
Wurde in der Analyse von DigitalFoundry auch erwähnt (timestamp funktioniert nicht, ab 21:39):leonM schrieb:Ist halt die Frage, was hat RT mit Dekompression zu tun. Würde eher auf BHV und die dafür benötigte CPU-Last setzen, die wohl nicht von der GPU sondern von der CPU geleistet wird.
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.
Ich bin damit einverstanden, dass YouTube-Embeds geladen werden. Dabei können personenbezogene Daten an YouTube übermittelt werden. Mehr dazu in der Datenschutzerklärung.
Zeit 21:39
@Wolfgang
Danke.
Meine Vorstellung bzw. hier anhand eines Beispiels, wie ich es mir vorstelle:
Ich hab eine Auflösung A die hat insgesamt 10 Strahlen, diese werden dann über N-Verfolgerstrahlen für z.B Reflektionen weiterverfolgt. Das wird in BHV abgespeichert und abgearbeitet.
Wenn ich z.B Auflösung B nehme, die 20 Strahlen hat, so steigert sich das. Sprich, 20^n im Vergleich zu 10^n. Wie auch immer^^
Danke.
Meine Vorstellung bzw. hier anhand eines Beispiels, wie ich es mir vorstelle:
Ich hab eine Auflösung A die hat insgesamt 10 Strahlen, diese werden dann über N-Verfolgerstrahlen für z.B Reflektionen weiterverfolgt. Das wird in BHV abgespeichert und abgearbeitet.
Wenn ich z.B Auflösung B nehme, die 20 Strahlen hat, so steigert sich das. Sprich, 20^n im Vergleich zu 10^n. Wie auch immer^^
Taxxor
Fleet Admiral
- Registriert
- Mai 2011
- Beiträge
- 20.659
Ich meinte sofern du es nicht deaktiviert hast, sollte die Package Power doch in den CX Dateien drin stehenWolfgang schrieb:Puh, ich hab mir die Leistungsaufnhame-Werte bei den Einzelmessungen leider nicht genauer angesehen
Ich verstehe es so, dass die Bvh Struktur im Vorfeld erstellt werden muss. Gespeichert werden simplere Entsprechungen der tatsächlichen Objekte der Szene. Die Grundidee ist, dass man nicht testen muss, ob ein Strahl ein Objekt trifft, sofern der Strahl auch die simplere Entsprechung nicht trifft (was wohl einfacher zu prüfen ist).
Für mein Verständnis ist dieser Aufwand erst einmal immer gleich hoch, sofern man nicht die Anzahl der zu berücksichtigen Objekte reduziert (Objekt Sichtweite in unsrem Fall).
Bei Erhöhung der Strahlenanzahl wird die BVH entsprechend häufiger auf Schnittpunkte geprüft, daher der erhöhte Aufwand für die GPU. Vielleicht sind mehr Strahlen auch etwas aufwändiger am Ende für den Denoiser (macht ja ebenfalls die GPU). Aber die Arbeit für den Aufbau der BVH dürfte mit der Strahlenmenge nicht skalieren.
Bisher bin ich aber immer davon ausgegangen, dass die GPU die BVH aufbaut und pflegt. Oder erfolgt das immer auf der CPU?
Für mein Verständnis ist dieser Aufwand erst einmal immer gleich hoch, sofern man nicht die Anzahl der zu berücksichtigen Objekte reduziert (Objekt Sichtweite in unsrem Fall).
Bei Erhöhung der Strahlenanzahl wird die BVH entsprechend häufiger auf Schnittpunkte geprüft, daher der erhöhte Aufwand für die GPU. Vielleicht sind mehr Strahlen auch etwas aufwändiger am Ende für den Denoiser (macht ja ebenfalls die GPU). Aber die Arbeit für den Aufbau der BVH dürfte mit der Strahlenmenge nicht skalieren.
Bisher bin ich aber immer davon ausgegangen, dass die GPU die BVH aufbaut und pflegt. Oder erfolgt das immer auf der CPU?
syfsyn
Admiral
- Registriert
- Nov. 2010
- Beiträge
- 8.160
So mal reingesehen erste 2 missionen bisher butterweich
Bild mal lauf übe spiegelnde Flächen
Bisher ist das keineswegs unausgewogen
Aber ein typisches marvel spiel hat anleihen zu den filmen
Was nervt ist die deutsche syncro teils steif und gewollt locker
Die minispiel sind nett
Die steuerung per maus tasta stark gewöhnungsbedürftig
Siehe
ja es gibt nen cpu limit aber das ist marginal
Und das war in der offenen welt aufn weg zum Missionspunkt (Polizeirevier).
Daher gut portiert die Ruckler die einige beklagen können nur vom zu geringen vram und ram kommen
Wie man am bsp sieht ist das 1080p dlaa und zieht nur nach 15 Minuten 8gb vram von 12gb.
daher sollte man das spiel min auf en OS mit 32 gb ram spielen
Inhaltlich naja die Vertonung nervt
Wird aber durchaus nen snack sein irgendwann wenn es an der reihe ist beim berg der Schande.
Installiert auf ner HDD
Bild mal lauf übe spiegelnde Flächen
Bisher ist das keineswegs unausgewogen
Aber ein typisches marvel spiel hat anleihen zu den filmen
Was nervt ist die deutsche syncro teils steif und gewollt locker
Die minispiel sind nett
Die steuerung per maus tasta stark gewöhnungsbedürftig
Siehe
ja es gibt nen cpu limit aber das ist marginal
Und das war in der offenen welt aufn weg zum Missionspunkt (Polizeirevier).
Daher gut portiert die Ruckler die einige beklagen können nur vom zu geringen vram und ram kommen
Wie man am bsp sieht ist das 1080p dlaa und zieht nur nach 15 Minuten 8gb vram von 12gb.
daher sollte man das spiel min auf en OS mit 32 gb ram spielen
Inhaltlich naja die Vertonung nervt
Wird aber durchaus nen snack sein irgendwann wenn es an der reihe ist beim berg der Schande.
Installiert auf ner HDD
@rumpeLson
Dachte ich zuvor auch, dass es die GPU regelt. Bei BVH dachte ich an folgendes Vorgehen:
Pro Pixel wird in BVH ein Array erstellt, dieser hat z.B die Grundinformation des Polygons bzw. der Texturfarbe. Jetzt wird durch die Beleuchtung wie auch durch z.B Reflektion der Wert angepasst, sprich, Wert 0 bekommt zuerst dem Wert 0,1 da z.B das Licht(RT-Strahl) auf dem Polygon trifft, dann erhält es eine Veränderung durch die Reflexion(hier hat es keine Bedeutung wie viele Strahlen verfolgt werden), hier ist es die Zeit der GPU bis sie dem Wert ermittelt hat aber die Gesamtanzahl des BVH ist die Anzahl an Pixel und somit hat die CPU, wenn sie wirklich mit der Strukturierung des BVH zutun hat eine gewisse Mehrlast, da der Baum einfach größer ist. Ich glaube, dass Nvidia BVH es in GPU bewältigen kann aber nicht die AMD RDNA-Architektur und da es sich um ein Konsolenport handelt, wird dies universal über die CPU gemacht. K.a^^
Dachte ich zuvor auch, dass es die GPU regelt. Bei BVH dachte ich an folgendes Vorgehen:
Pro Pixel wird in BVH ein Array erstellt, dieser hat z.B die Grundinformation des Polygons bzw. der Texturfarbe. Jetzt wird durch die Beleuchtung wie auch durch z.B Reflektion der Wert angepasst, sprich, Wert 0 bekommt zuerst dem Wert 0,1 da z.B das Licht(RT-Strahl) auf dem Polygon trifft, dann erhält es eine Veränderung durch die Reflexion(hier hat es keine Bedeutung wie viele Strahlen verfolgt werden), hier ist es die Zeit der GPU bis sie dem Wert ermittelt hat aber die Gesamtanzahl des BVH ist die Anzahl an Pixel und somit hat die CPU, wenn sie wirklich mit der Strukturierung des BVH zutun hat eine gewisse Mehrlast, da der Baum einfach größer ist. Ich glaube, dass Nvidia BVH es in GPU bewältigen kann aber nicht die AMD RDNA-Architektur und da es sich um ein Konsolenport handelt, wird dies universal über die CPU gemacht. K.a^^
Zuletzt bearbeitet:
@leonM
Ampere kann in Hardware den Durchlauf durch die Struktur beschleunigen. RDNA2 hingegen muss diesen Schritt in den normalen Shadern erledigen. Dies ist zwar etwas langsamer, bedeutet aber, da es ja immer noch innerhalb der GPU erfolgt, keinen Mehraufwand für die CPU.
Und so oder so dürfte das ja eh der jeweilige Grafikkartentreiber steuern.
Woher der erhöhte Aufwand für die CPU mit Raytracing kommt und ob eine höhere Auflösung hier reinspielt, scheint aber eine Frage an Leute zu sein, die mehr Plan haben als wir
Ampere kann in Hardware den Durchlauf durch die Struktur beschleunigen. RDNA2 hingegen muss diesen Schritt in den normalen Shadern erledigen. Dies ist zwar etwas langsamer, bedeutet aber, da es ja immer noch innerhalb der GPU erfolgt, keinen Mehraufwand für die CPU.
Und so oder so dürfte das ja eh der jeweilige Grafikkartentreiber steuern.
Woher der erhöhte Aufwand für die CPU mit Raytracing kommt und ob eine höhere Auflösung hier reinspielt, scheint aber eine Frage an Leute zu sein, die mehr Plan haben als wir
syfsyn schrieb:
Du hast 45 FPS bei den P1. So viel hab ich in etwa bei den P0.2, wenn ich mit maximaler Geschwindigkeit über den Boden schwinge. Hab also bessere Frametimes und trotzdem merke ich das als Ruckler. Es ist einfach nicht richtig smooth.
Ohne RT gehen bei mir die P0.2 auf 60 FPS hoch und ich merke keine Ruckler mehr.
Frage: Nutzt du nen Adaptive Sync Monitor? Würde mich stark interessieren. Ich gehe davon aus, dass man die Frametime Spikes z.B. ohne Adaptive Sync gar nicht sehen, also wahrnehmen kann.
Und wenn der VRAM schuld wäre, würde man das logischerweise auch in den Frametimes sehen.
Na ja, letzten Endes zeigt sich hier einfach, dass der PC wohl heftig ins straucheln gerät, wenn Spiele für die neuen Konsolenarchitekturen entickelt werden.
Ob es nun das fehlende Direct Storage, die fehlende hardwarebeschleunigte Dekompression oder der fehlende Unified Memory zwischen GPU und CPU ist, der PC muss sich dringend anpassen und hängt aktuell hinterher. Rohleistung alleine reicht halt nicht.
Aber mal sehen, ob künfitge Patches da noch was richten können.
Zuletzt bearbeitet:
Taxxor
Fleet Admiral
- Registriert
- Mai 2011
- Beiträge
- 20.659
So sieht eine Tour durch die Straßen bei mir aus, wenn ich ohne FSR und ohne FPS Limit spiele, schnelle Schwinger knapp über den Boden sind gegen Ende der Szene drin.W0dan schrieb:Du hast 45 FPS bei den P1. So viel hab ich in etwa bei den P0.2, wenn ich mit maximaler Geschwindigkeit über den Boden schwinge. Hab also bessere Frametimes und trotzdem merke ich das als Ruckler. Es ist einfach nicht richtig smooth.
Ohne RT gehen bei mit die P0.2 auf 60 FPS hoch und ich merke keine Ruckler mehr.
Settings alle auf Max(außer HBAO+) und RT auf Hoch mit Sichtweite 5
Normalerweise spiele ich dann aber mit 60FPS Lock und FSR Q und da merke ich nichts von irgendwelchen Rucklern. Dafür sinkt die GPU TGP von ~180W auf ~110W.
Und ja, 144Hz VRR Monitor.
syfsyn
Admiral
- Registriert
- Nov. 2010
- Beiträge
- 8.160
nicht unbedingt
kann sein das ich die sehr kurzen spikes nicht wahrnehme mein monitor ist an displayport angeschlossen ansonsten hab ich kein sync an
Auch die gpu zeigt mir kein gsync oder ähnliches so was wird aber definitiv bei der nächsten gen an gpu kommen da dann ein Wechsel auf 1440p ansteht. (unklar ob rtx4060ti oder rtx5060)
Derzeit ist das einzige ruckeln das ich Wahrnehme oft in grim dawn bei Gebietswechsel.
Das spiel ist Überraschend fordernd ist gedacht fürn laptop igp
hier mal die frametimes dieser szene
kann sein das ich die sehr kurzen spikes nicht wahrnehme mein monitor ist an displayport angeschlossen ansonsten hab ich kein sync an
Auch die gpu zeigt mir kein gsync oder ähnliches so was wird aber definitiv bei der nächsten gen an gpu kommen da dann ein Wechsel auf 1440p ansteht. (unklar ob rtx4060ti oder rtx5060)
Derzeit ist das einzige ruckeln das ich Wahrnehme oft in grim dawn bei Gebietswechsel.
Das spiel ist Überraschend fordernd ist gedacht fürn laptop igp
hier mal die frametimes dieser szene
highsociety
Commander
- Registriert
- März 2012
- Beiträge
- 2.317
Hat jemand eine Idee wie das Spiel in der Kombination i7 8700k @4,7Ghz und einer RTX2080 in 1440p laufen würde?
Der 8700k dürfte ungefähr dem getesteten 10600k entsprechen und die RTX 2080 knapp 10% flotter sein als die getestete RTX 2070 super. Ohne Raytracing müsste es also ganz gut laufen und mit Raytracing dann vielleicht mit DLSS und etwas reduzierter Sichtweite ebenfalls noch passabel.highsociety schrieb:Hat jemand eine Idee wie das Spiel in der Kombination i7 8700k @4,7Ghz und einer RTX2080 in 1440p laufen würde?
Ähnliche Themen
- Antworten
- 175
- Aufrufe
- 11.304