Minecraft RTX analysiert: Bildqualität, Leistung, Speicherhunger, DLSS und mehr

[ZeroZerp]

@Zero: Lass doch mal ein OSD laufen währenddessen

Hier mal die relevanten Daten der Batterie, die CX so default bietet:

System diesmal: 99000K 5GHz / 4000MHz RAM 2x16 (medium subs) / 2080TI Stock
1080P Maximum/ RT / DLSS (Wolken aus)

32 Chunks


64 Chunks


Schau mal das Bus Interface der GK bei letztem Screen an Maximum overflow.

Kein Wunder, dass der Kram so einbricht...
Alle Screens wurden nach ca. 15 Sekunden ohne Kamerabewegung gemessen.

Bei 64 Chunks zudem entspannte 18 Gigabyte RAM- Auslastung... Für ein Klötzchenspiel nicht schlecht.

LG
Zero

 

[gaussmath]

Super, das sind doch mal ein paar interessante Werte! Danke fürs Teilen.

 

[ZeroZerp]

Super, das sind doch mal ein paar interessante Werte! Danke fürs teilen.

Man sieht auch deutlich, warum sich die Entwickler entschieden haben, die Engine bei 24 Chunks "dicht" zu machen. Es zerreisst einfach den VRAM, wie Raff schon treffend festgestellt hat.

LG
Zero

 

[gaussmath]

Mit PCIe 4 hätte man 8 FPS.

 

[Geldmann3]

Ich möchte diversen nachfolgenden Beiträgen nach diesem https://extreme.pcgameshardware.de/...icherhunger-dlss-und-mehr-9.html#post10281083 nochmal widersprechen. Es stimmt durchaus was ich schrieb. Es werden über mehrere Frames temporale Samples via Jitter der Samplingkoordinate in den Pixeln gesammelt, diese Samples werden dann in ein Bild mit höherer Auflösung verteilt und von dem neuronalen Netz lediglich ,,verrechnet". Das Netz upscaled nichts, auch wenn das oftmals so dargestellt wird, es ,,säubert" das Bild am Ende nur von z.b. Moiré Artefakten.
Bei DLSS < 2.0 war es scheinbar noch anders.

Aus Entwicklersicht nimmt sich das NGX SDK die ganzen TXAA-Samples, die Jitter Offsets, die Motion Vektoren, den Depht Buffer und ,,macht die Samples schön". Mit den Samples, die man ohne zusätzliches AA bereits als die Pixelfarben bezeichnen könnte, hat DLSS bereits genügend Informationen für die volle Auflösung und muss nichts mehr upscalen. Wenn, dann könnte man es eher als ein Denoising verstehen, doch es verringert nicht nur Noise.

 

[ZeroZerp]

@Geldmann3

Alles gut, lass Dich nicht ärgern. Man sieht ja allein schon an der Schreibweise, wer hier vernünftig diskutieren will und wer nicht. Im großen und ganzen hast Du das System richtig erfasst, wobei das DL in DLSS schon gehörig dafür sorgt das Bild ruhigzustellen.

Im Namen der Wissenschaft hab ich mir überlegt das Bild eines Framebuffers nach Jitter&co jedoch vor der Bearbeitung durch die Tensor- Cores zu extrahieren (müsst ich mal sehen, wie das timing- technisch oder per breakpoint geht und ob die mir zur Verfügung stehenden Tools die Trennung weit genug durchführen können).
Dann haben wir einen direkten Vorher- Nachher- Vergleich und der Anteil der Tensor Core- Berechnung wird ersichtlich. Interessiert mich ja selber.

Konstruktiv bleiben, dann machts auch spaß.

LG
Zero

 

[gaussmath]

@Zero: Wie geht das? Willst du den DirectX Objekt Stream über Nsight abgreifen?

 

[ZeroZerp]

@Zero: Wie geht das? Willst du den DirectX Objekt Stream über Nsight abgreifen?

1.Ich versuche direkt an die einzelnen Buffer zu kommen und füge sie dann selbst zusammen.
2.Disassemblieren und den Teil der Bearbeitung durch die Tensor Cores überspringen.
3.Vielleicht kann man das auch über nsight entsprechend zerpflücken
4.Direkte Speichermanipulation/Tracing
....muss mir heute mal Gedanken dazu machen und ein wenig rumspielen.

LG
Zero