Bericht Doom mit Vulkan: Benchmarks zeigen bis zu 66 Prozent mehr FPS
- Ersteller Wolfgang
- Erstellt am
- Zum Bericht: Doom mit Vulkan: Benchmarks zeigen bis zu 66 Prozent mehr FPS
Nai
Lt. Commander
- Registriert
- Aug. 2012
- Beiträge
- 1.577
Eventuell noch ein paar Gedanken dazu, wann die Rops/Rasterizer nicht oversized sind:ampre schrieb:
-Falls es zur Entwicklungszeit der Anwendung noch keine API gab um Async Compute zu nutzen. Das war jetzt schon mehrere Jahre einer der Gründe dafür, dass AMD eine reduzierte Performance hatte
-Falls man sich als Programmierer heutzutage aus diversen Gründen dennoch gegen eine Low Level API entscheidet
-Falls es für den Entwickler zu viel Aufwand ist auf Async Compute zu optimieren: Eine Anwendung ohne Async Compute zu programmieren ist immer noch ein Stück einfacher als eine Anwendung mit zu programmieren
-Falls es keine sinnvolle Möglichkeit gibt Graphik und Compute gleichzeitig zu berechnen
Unter anderem der letzterer Fall spielt in der Industrie unteri CAD eine größere Rolle: In einem CAD Programm will man oft nur sehr große Modelle (mehrere hundert Millionen Dreiecke sind keine Seltenheit) mit sehr einfachen Shadern zeichnen. Da spielt nur die Performance der Rasterpipeline und nicht die Performance der Shader eine Rolle. Dementsprechend gibt es dort auch keine Compute Aufgaben um Async-Compute verwenden zu können. Und wie wir alle wissen lässt sich mit professionellen Quadros für CAD viel Geld machen. . . .
Na ja Cad Programme sind heute wirklich keine Hürde mehr! Es gibt ja auch noch culling, das wird dann dort auch angewand. Auch die Rasterizer sind oversized! Amd packt 4.1 gigapolygon. Ware ein Polygon so groß wie ein Pixel hatte man bei UHD Auflösung noch 351 Fps.
Nai
Lt. Commander
- Registriert
- Aug. 2012
- Beiträge
- 1.577
Die Polygone sind aber deutlich kleiner als ein Pixel, da Simplifizierung von Meshen nicht gerade einfach zu berechnen ist. Culling ist bei komplexeren Szenen auch nicht immer so trivial zu berechnen und will zudem ersteinmal implementiert werden. Jedoch haben diverse beliebte CAD Programme so vom hören und sagen her nur einen ziemlich grausamen und rudimentären OpenGL 2.X Renderpfad.
So als Beispiel für komplexere CAD Szenen stütze ich mich einfach mal auf die Benchmarks mit dem CAD Modell einer Ölplattform von http://developer.download.nvidia.com/presentations/2008/NVISION/NVISION08_MGPU.pdf mit 230 Millionen Dreiecken. Da erreichte NVIDIA mit 4xGT200 gerade einmal 4 FPS. Bei der anderen Testszene, die vermutlich als Beispiel für ein 3D Programm dienen sollte, mit 217 Millionen Dreicken war die Performance mit 6 FPS ähnlich schlecht
So als Beispiel für komplexere CAD Szenen stütze ich mich einfach mal auf die Benchmarks mit dem CAD Modell einer Ölplattform von http://developer.download.nvidia.com/presentations/2008/NVISION/NVISION08_MGPU.pdf mit 230 Millionen Dreiecken. Da erreichte NVIDIA mit 4xGT200 gerade einmal 4 FPS. Bei der anderen Testszene, die vermutlich als Beispiel für ein 3D Programm dienen sollte, mit 217 Millionen Dreicken war die Performance mit 6 FPS ähnlich schlecht
Zuletzt bearbeitet:
Ich weiß ja nicht was für 0815 Cad du benutzt aber die großen wie proe Autodesk und Nx haben das sicher drin!
https://knowledge.autodesk.com/supp...8A203E1E-3BA3-4208-91E0-653F5C653707-htm.html
https://knowledge.autodesk.com/supp...8A203E1E-3BA3-4208-91E0-653F5C653707-htm.html
Zuletzt bearbeitet:
Nai
Lt. Commander
- Registriert
- Aug. 2012
- Beiträge
- 1.577
Sie verwenden bei deinem Autocad laut beschreibung zumindest die drei eher nur trivialen Culling Arten:
-Backface Culling: Einfache flag im State der Rasterpipeline auf der GPU - trivial durch eine Zeile Code zu implementieren
-Frustrum Culling: Das macht die Rasterpipeline automatisch und alternativ kann man es manuell über den Geometry Shader mit einen Overhead pro Polygon machen oder auch über die CPU mit einem Overhead pro Objekt. Letzteres läuft auf Schnittberechnung zwischen Frustrum und AABB oder etwas konservativer durch Schnittpunktberechnung zwischen einer Bounding Box und einer AABB heraus.
-Weglassen kleinerer Objekte (fällt für mich aber eher unter Level of Detail als unter Culling, aber ok. . . .): Auch ein trivialer Fall. Einfach vor dem Zeichnen eine Boundingbox um das Objekt erstellen und diese auf den Bilschirm projezieren. Dann die Größe in Pixel abzählen. Falls zu wenige Pixel wird das Objekt nicht gezeichnet.
Das einzige was an diesen drei Culling modes eventuell etwas komplexer zu implementieren wäre, wäre die Anbindung: Man kann in OpenGL effizient den Overhead reduzieren, falls man Objekte nicht einzeln per Drawcall zeichnet, sondern mehrere unterschiedliche Objekte mit einem einzigen Drawcall. Dafür muss man sie allerdings auch nacheinander in ein und die selben Vertex-Buffer schreiben, was dann das Speichermanagement für die Buffern komplizierter macht. Alternativ könnte man größere Objekte auch zuerst geschickt in kleinere Unterteilen, was dann ein besseres Culling ermöglichen würde.
Wirklich interessant von der Implementierung her ist eigentlich nur das Occlussion Culling, da man hierfür ermitteln muss, welche Objekte welche anderen überdecken. Computerspiele tricksen aus Performancegründen hierfür immer und treffen zusätzliche Annahmen über die Szene oder designen die Szene extra dafür. Letzteres sieht man z.B. sehr gut in Silbermond aus wow(http://vignette1.wikia.nocookie.net...oonCity.jpg/revision/latest?cb=20071104181155). Hier kann man dank geschickt platzierten Occludern in den Verbindungsgassen nicht von den einen in den anderen Stadtteil schauen. Das ist aber im CAD nicht möglich.
Und nocheinmal zu der Performance von CAD: Wenn ich mir zum Beispiel die CAD Benchmarks bei Tomshardware (http://www.tomshardware.com/reviews/geforce-gtx-titan-opencl-cuda-workstation,3474-6.html, http://www.tomshardware.com/reviews/specviewperf-12-workstation-graphics-benchmark,3778-2.html ) so anschaue, dann ist man auch hier weit davon entfernt überall mehrere 100 FPS zu haben und damit komplett im grünen Bereich zu sein. Die Benchmarks haben zwar oft mehr als 30 FPS, aber falls die Modelle komplexer werden schrumpft das wieder dementsprechend.
-Backface Culling: Einfache flag im State der Rasterpipeline auf der GPU - trivial durch eine Zeile Code zu implementieren
-Frustrum Culling: Das macht die Rasterpipeline automatisch und alternativ kann man es manuell über den Geometry Shader mit einen Overhead pro Polygon machen oder auch über die CPU mit einem Overhead pro Objekt. Letzteres läuft auf Schnittberechnung zwischen Frustrum und AABB oder etwas konservativer durch Schnittpunktberechnung zwischen einer Bounding Box und einer AABB heraus.
-Weglassen kleinerer Objekte (fällt für mich aber eher unter Level of Detail als unter Culling, aber ok. . . .): Auch ein trivialer Fall. Einfach vor dem Zeichnen eine Boundingbox um das Objekt erstellen und diese auf den Bilschirm projezieren. Dann die Größe in Pixel abzählen. Falls zu wenige Pixel wird das Objekt nicht gezeichnet.
Das einzige was an diesen drei Culling modes eventuell etwas komplexer zu implementieren wäre, wäre die Anbindung: Man kann in OpenGL effizient den Overhead reduzieren, falls man Objekte nicht einzeln per Drawcall zeichnet, sondern mehrere unterschiedliche Objekte mit einem einzigen Drawcall. Dafür muss man sie allerdings auch nacheinander in ein und die selben Vertex-Buffer schreiben, was dann das Speichermanagement für die Buffern komplizierter macht. Alternativ könnte man größere Objekte auch zuerst geschickt in kleinere Unterteilen, was dann ein besseres Culling ermöglichen würde.
Wirklich interessant von der Implementierung her ist eigentlich nur das Occlussion Culling, da man hierfür ermitteln muss, welche Objekte welche anderen überdecken. Computerspiele tricksen aus Performancegründen hierfür immer und treffen zusätzliche Annahmen über die Szene oder designen die Szene extra dafür. Letzteres sieht man z.B. sehr gut in Silbermond aus wow(http://vignette1.wikia.nocookie.net...oonCity.jpg/revision/latest?cb=20071104181155). Hier kann man dank geschickt platzierten Occludern in den Verbindungsgassen nicht von den einen in den anderen Stadtteil schauen. Das ist aber im CAD nicht möglich.
Und nocheinmal zu der Performance von CAD: Wenn ich mir zum Beispiel die CAD Benchmarks bei Tomshardware (http://www.tomshardware.com/reviews/geforce-gtx-titan-opencl-cuda-workstation,3474-6.html, http://www.tomshardware.com/reviews/specviewperf-12-workstation-graphics-benchmark,3778-2.html ) so anschaue, dann ist man auch hier weit davon entfernt überall mehrere 100 FPS zu haben und damit komplett im grünen Bereich zu sein. Die Benchmarks haben zwar oft mehr als 30 FPS, aber falls die Modelle komplexer werden schrumpft das wieder dementsprechend.
Zuletzt bearbeitet:
r4yn3
Admiral
- Registriert
- Mai 2006
- Beiträge
- 7.683
Für den Fall für den Thread interessiert sich noch jemand, hier nochmal 2 neue Bilder mit "neuer" Karte. Leider bewirkt Vulkan bei mir nicht wirklich eine CPU Entlastung. Beide Screens 2560x1080, 8xTSAA und maxed Out.
Das witzige ist, mit Nightmare Textures scheint Vulkan dann doch mit nur "4GB" Vram fehleranfällig zu sein. Es schließt sich dann einfach. Und wenn nicht, brechen die Frames stark ein. Under OpenGL läuft das selbst mit Nightmare Textures problemlos. Außer der Treiber verhakt sich mal, und lädt vermutlich Daten in den falschen Teil des Vram.
Das witzige ist, mit Nightmare Textures scheint Vulkan dann doch mit nur "4GB" Vram fehleranfällig zu sein. Es schließt sich dann einfach. Und wenn nicht, brechen die Frames stark ein. Under OpenGL läuft das selbst mit Nightmare Textures problemlos. Außer der Treiber verhakt sich mal, und lädt vermutlich Daten in den falschen Teil des Vram.
Zuletzt bearbeitet:
t3chn0
Admiral
- Registriert
- Okt. 2003
- Beiträge
- 9.721
Du solltest dir wirklich...wirklich mal eine neue CPU gönnen. Diese Spikes bei Vulkan sind quasi analog zwischen GPU und CPU.
Die CPU wird durch Vulkan nicht entlastet, sondern die GPU kann effektiver arbeiten. Irgendwas stimmt da nicht. Außerdem solltest du die Option "Nightmare Textures" gar nicht haben. Mit meinen 970ern konnte ich das nicht wählen, da war bei Ultra Schluss.
Die CPU wird durch Vulkan nicht entlastet, sondern die GPU kann effektiver arbeiten. Irgendwas stimmt da nicht. Außerdem solltest du die Option "Nightmare Textures" gar nicht haben. Mit meinen 970ern konnte ich das nicht wählen, da war bei Ultra Schluss.
r4yn3
Admiral
- Registriert
- Mai 2006
- Beiträge
- 7.683
Och für meine Zwecke reicht sie dicke. Mal sehen was Skylake-E bringt.
Ja doch, Ziel sollte es unter anderem auch sein die CPU zu entlasten, und es gibt ja teils auch Tests wo das klappt, nur irgendwie bei mir nicht. Aber egal, ich hab auch so genug FPS.
Stimmt, darum gibts ja auch den Steambefehl der die Begrenzung aushebelt. Entgegen meiner Erwartungen läuft das einwandfrei.
Natürlich geht dann auch mal der Ramverbauch auf 12GB hoch. Mit lediglich 8GB Systemram würde das ganze wohl nicht funktionieren, und es würde mich nicht wundern wenn eine 970 deswegen oft so verschrien ist.
Ja doch, Ziel sollte es unter anderem auch sein die CPU zu entlasten, und es gibt ja teils auch Tests wo das klappt, nur irgendwie bei mir nicht. Aber egal, ich hab auch so genug FPS.
Stimmt, darum gibts ja auch den Steambefehl der die Begrenzung aushebelt. Entgegen meiner Erwartungen läuft das einwandfrei.
Natürlich geht dann auch mal der Ramverbauch auf 12GB hoch. Mit lediglich 8GB Systemram würde das ganze wohl nicht funktionieren, und es würde mich nicht wundern wenn eine 970 deswegen oft so verschrien ist.
Disposable Hero
Newbie
- Registriert
- Apr. 2014
- Beiträge
- 7
Hallo,
also zum Thema Vulkan und CPU entlasten: Das ist GENAU das, was Vukan bzw. DX12 so wichtig macht. Es behandelt die Draw-Calls, die die CPU an die Grafikkarte schickt extrem viel effizienter und entlasstet damit hauptsächlich die CPU. Die alten APIs sind da extrem ineffizient und verballern durch Ihren overhead CPU-Leistung, während die Grafikarte auf neue Befehle wartet und Däumchen dreht.
Zu DooM und Vulkan:
Das hat bei meinem System (6700k4.5GHz, GTX 780SC) schon einiges gebracht. In engen Korridoren (wenig geometrie & calls) so 20-25 Prozent mehr FPS, in größeren Gebieten (z.B. dieser Schmelze mit dem großen, zentralen Raum über mehreren Etagen) bis zu 60% mehr FPS - und das für lau, nur durch die effizienter arbeitende API - das finde ich schon beeindruckend.
Habe mir am Donnerstag nun endlich ne 1080 FTW bestellt, kommt hoffentlich in der ersten Augustwoche bei mir an, dann werde ich damit nochmal OpenGL vs. Vulkan testen....
also zum Thema Vulkan und CPU entlasten: Das ist GENAU das, was Vukan bzw. DX12 so wichtig macht. Es behandelt die Draw-Calls, die die CPU an die Grafikkarte schickt extrem viel effizienter und entlasstet damit hauptsächlich die CPU. Die alten APIs sind da extrem ineffizient und verballern durch Ihren overhead CPU-Leistung, während die Grafikarte auf neue Befehle wartet und Däumchen dreht.
Zu DooM und Vulkan:
Das hat bei meinem System (6700k4.5GHz, GTX 780SC) schon einiges gebracht. In engen Korridoren (wenig geometrie & calls) so 20-25 Prozent mehr FPS, in größeren Gebieten (z.B. dieser Schmelze mit dem großen, zentralen Raum über mehreren Etagen) bis zu 60% mehr FPS - und das für lau, nur durch die effizienter arbeitende API - das finde ich schon beeindruckend.
Habe mir am Donnerstag nun endlich ne 1080 FTW bestellt, kommt hoffentlich in der ersten Augustwoche bei mir an, dann werde ich damit nochmal OpenGL vs. Vulkan testen....
V
VikingGe
Gast
Also Vulkan sollte schon die CPU entlasten, im Vergleich zu Dx11 lässt OpenGL aber auch schon Programmierung mit vergleichsweise geringem Overhead zu (Stichwort AZDO) und da Doom auch GL 4.5 nutzt, kann man denke ich davon ausgehen, dass zumindest einige der entsprechenden Features auch genutzt werden.
Zumindest, wenn man die Texturauflösung so weit zurücknimmt, dass das Zeug auch wirklich alles in den VRAM passt
wenn der überläuft, bringt auch die schnellste CPU nichts.
t3chn0 schrieb:
Also schneller ist meine CPU jetzt auch nicht, in 720p läuft Doom bei mir aber mit fluffig konstanten 60 FPS. Das sollte der Quad eigentlich auch problemlos schaffen, wenn im Hintergrund nicht zu viel Unsinn mitläuft.r4yn3 schrieb:
Zumindest, wenn man die Texturauflösung so weit zurücknimmt, dass das Zeug auch wirklich alles in den VRAM passt
wenn der überläuft, bringt auch die schnellste CPU nichts.
r4yn3
Admiral
- Registriert
- Mai 2006
- Beiträge
- 7.683
Ja wie gesagt läuft das eigentlich problemlos. Im Schnitt wohl mit 80 FPS. Die Stelle bei der Kernschmelze ist schon eine durchaus fordernde Szene.
Den Vram managed hier der Treiber in OpenGL ziemlich gut. Ob das auch bei anderen Spielen klappt hab ich nicht getestet.
Den Vram managed hier der Treiber in OpenGL ziemlich gut. Ob das auch bei anderen Spielen klappt hab ich nicht getestet.
Weiss nicht ob es hier schon gepostet wurde - aber ich finde mein Vorschlag von weiter oben zunehmend interessant:
http://www.3dcenter.org/news/neuer-artikel-amd-zieht-unter-directx-12-vulkan-nvidia-vorbei
Zeit das man das ganze mal thematisch und breiter anpackt und etwas genauer als bei Golem. Dann kommt dabei auch was rum.
http://www.3dcenter.org/news/neuer-artikel-amd-zieht-unter-directx-12-vulkan-nvidia-vorbei
Zeit das man das ganze mal thematisch und breiter anpackt und etwas genauer als bei Golem. Dann kommt dabei auch was rum.
Krautmaster
Fleet Admiral
- Registriert
- Feb. 2007
- Beiträge
- 24.238
http://www.pcgameshardware.de/Doom-2016-Spiel-56369/Specials/Vulkan-Benchmarks-Frametimes-1202711/
hier noch Benchmarks mit deaktivierter Vulkan Vsync die bei Nvidia wohl massiv leistung kosten
hier noch Benchmarks mit deaktivierter Vulkan Vsync die bei Nvidia wohl massiv leistung kosten
t3chn0
Admiral
- Registriert
- Okt. 2003
- Beiträge
- 9.721
Wow, danke für den Link.
Ich muss sagen, in letzter Zeit macht PCGH wirklich tolle Arbeit! Früher war ich selten auf der Seite, heute nahezu täglich 1x-2x.
Mittlerweile sind unter dem Link:
http://www.pcgameshardware.de/Doom-2016-Spiel-56369/Specials/Vulkan-Benchmarks-Frametimes-1202711/
auch noch andere Karten zu finden, sogar die 280x, oder die 780Ti.
Also sieht man, dass die Pascal karte noch gar nicht ihre optimale Leistung entfalten können. Mit neuen Treibern, Spiele-Patches geht da mit Sicherheit noch einiges.
Man sollte aber auch ehrlich sagen, dass AMD hier top Arbeit geleistet hat.
Ich muss sagen, in letzter Zeit macht PCGH wirklich tolle Arbeit! Früher war ich selten auf der Seite, heute nahezu täglich 1x-2x.
Mittlerweile sind unter dem Link:
http://www.pcgameshardware.de/Doom-2016-Spiel-56369/Specials/Vulkan-Benchmarks-Frametimes-1202711/
auch noch andere Karten zu finden, sogar die 280x, oder die 780Ti.
Also sieht man, dass die Pascal karte noch gar nicht ihre optimale Leistung entfalten können. Mit neuen Treibern, Spiele-Patches geht da mit Sicherheit noch einiges.
Man sollte aber auch ehrlich sagen, dass AMD hier top Arbeit geleistet hat.
ToniMacaroni
Captain
- Registriert
- Juni 2008
- Beiträge
- 3.444
Das erklärt auch, warum in 4k der Vorsprung der Fury X so viel geringer wird. Da greift die Synchronisation bei nVidia nämlich nicht mehr.
ToniMacaroni schrieb:
derfledderer
Lt. Commander
- Registriert
- Sep. 2014
- Beiträge
- 1.322
Es gibt mal wieder schlechte Nachrichten für nVidia Nutzer: https://www.youtube.com/watch?v=GFAqBkOo6z4
t3chn0
Admiral
- Registriert
- Okt. 2003
- Beiträge
- 9.721
Wieso denn schlechte Nachrichten? Das sind doch sehr gute Nachrichten =). Das kann man doch ganz easy via Treiber und Patch lösen.
Für mich zeigt das einfach, dass auch Pascal unter DX12 und Vulkan durch Treiber eine Menge zulegen wird. Guck dir mal die 1080 "korrigiert" an. Das wären unter Vulkan nochmal krassere Frametimes und fast eine gerade Linie...quasi perfekt.
Wenn Nvidia jetzt noch Async via Treiber einpflegt, dann geht da richtig was.
Für mich zeigt das einfach, dass auch Pascal unter DX12 und Vulkan durch Treiber eine Menge zulegen wird. Guck dir mal die 1080 "korrigiert" an. Das wären unter Vulkan nochmal krassere Frametimes und fast eine gerade Linie...quasi perfekt.
Wenn Nvidia jetzt noch Async via Treiber einpflegt, dann geht da richtig was.
H
hrafnagaldr
Gast
t3chn0 schrieb:
Eine Software-Emulation bringt aber nix an Leistung und nur dafür ist das Feature da. Mehr als das wirds wohl nicht werden.
V
VikingGe
Gast
Nur blöd, dass Nvidia auch mit den "korrigierten" Werten in Doom kaum mehr Frames liefert als mit OpenGL. Denn bei den PCGH-Werten verliert NV mit dem Treiberproblem gegenüber OpenGL massiv an Leistung.t3chn0 schrieb:
Das Problem lässt sich beheben, die ungefähr zu erwartende Leistung der Karten ohne das Problem hat PCGH ausgerechnet, aber ich sehe nicht, wo du da noch "eine Menge" Mehrleistung erwartest.
