Vulkan Grafik-API

[Entropy]

Kurzer Test Doom Windows vs. Wine 2.0 Staging (RC5) auf Linux 4.9 mit GTX 1070 OC, Ultra Details & Standard:

Windows 10:
OpenGL: ~105fps
Vulkan: ~92fps

Linux:
Vulkan: ~86fps (CPU: ~4,6ms)
OpenGL: ~70fps (CPU: ~14,13ms)das ist recht unerwartet. Eigentlich sollte es CPU limitiert sein und auf beiden gleich laufen. Kannst du noch ein paar mehr stellen testen?
OpenGL auf Linux scheint CPU limitiert zu sein.

Vulkan läuft bei dem Spiel auf Nvidia mit Windows schon mitunter merkbarer langsamer als OGL.Bei mir lief das eigentlich ziemlich gleich, wenn ich kein SLI nutze.

Aus id's Versprechen, den Vulkan-Pfad auch noch für NV zu optimieren, ist offenbar nichts geworden. Genau so hört man nichts mehr von Async Compute für andere AA-Modi als TSSAA, was Sousa auf Twitter angekündigt hatte...
Das ist was mir Sorgen macht mit den neuen APIs. Früher hat der Treiber Probleme in Spielen gefixt. Mit Vulkan und Direct3D 12 sind wir heute auf Entwickler angewiesen. Was ist wenn ein 5Jahre altes Spiel dann ein Patch braucht für eine neue GPU? Kann sein, dass etwas von der Spec nicht beachtet wurde, weil es keine Probleme auf aktuellen GPUs macht und auf GPUs in 5Jahren schon.
(Das ist nicht gegen Entwickler gemeint, sondern gegen das Konzept an sich).

[Entropy]

Talos ist primär DX11, OpenGL gibts wohl nur wegen Linux (und das läuft richtig mies).
Das ist vom Croteam, den Serious Sam machern. Jede Engine von denen hat bisher OpenGL genutzt, deswegen ist es aus meiner sicht offensichtlich, dass die Vulkan statt Direct3D 12 vorzeigen. (Macht ja auch Sinn, wenn die das ebenfalls auf Linux nutzen können).

[pixeljetstream]

Was ist wenn ein 5Jahre altes Spiel dann ein Patch braucht für eine neue GPU? Kann sein, dass etwas von der Spec nicht beachtet wurde, weil es keine Probleme auf aktuellen GPUs macht und auf GPUs in 5Jahren schon.
(Das ist nicht gegen Entwickler gemeint, sondern gegen das Konzept an sich).

Es ist ja kein Treibercode was die Leute schreiben, die vorhandenen Abstraktionen sollten in der Lage sein das immer noch abzufangen. Worst-case läufts halt nicht mehr optimal, aber dafür ist die 5 Jahre "neure" GPU dann auch flotter und es spielt weniger eine Rolle.

Das Problem mit dem "lebenden Gebilde" ist nicht neu. Wir haben lediglich nen "rebase" mit den apis, OpenGL 1.1 war sicher auch früher mal relativ low-level, wo jedes enable/disable mehr oder weniger direkt auf nen register zu mappen war.

Die Verantwortung mag aus Deiner Perspektive theoretisch eher beim Entwickler liegen, aber glaube dass die Hersteller das nachwievor eher abfangen. Indirekt sind sie auch selbst Schuld wenn die Spec zu löchrig wäre. Beide Parteien haben ein Interesse die Konformität, Genauigkeit usw. hochzuhalten und sind auch in der Pflicht.

Wenn neue GPUs entwickelt werden, werden diese gegen den bestehenden Softwarekatalog getestet, Treiber sind für die Simulation von Chips ja auch schon viel eher fertig als die Chips selbst. Das heißt schon aus diesem Eigennutz würde es workarounds seitens der Hersteller geben, wenn wirklich was kracht. Das mag nicht für jedes Spiel gelten.

Sicher wird man die Validierungstools verbessern und Entwickler hinweisen, aber es ist kaum realistisch dass es derartige Supportleistung von Entwicklern geben wird. Die Erwartung der Endkunden wird auch sein "es lief doch vorher auch bei Hersteller XYZ".

Je weiter man in die Zukunft geht, desto problematischer, aber man kann dann auch argumentieren, dass wir komplett andere Hardware/Systeme auch emulieren (siehe PS, Nintendo etc. emulatoren). En service den quasi die community liefer kann, wenn sowohl Hersteller als auch Entwickler das Problem nicht lösen konnten.

[Ganon]

Das ist was mir Sorgen macht mit den neuen APIs. Früher hat der Treiber Probleme in Spielen gefixt. Mit Vulkan und Direct3D 12 sind wir heute auf Entwickler angewiesen. Was ist wenn ein 5Jahre altes Spiel dann ein Patch braucht für eine neue GPU? Kann sein, dass etwas von der Spec nicht beachtet wurde, weil es keine Probleme auf aktuellen GPUs macht und auf GPUs in 5Jahren schon.
(Das ist nicht gegen Entwickler gemeint, sondern gegen das Konzept an sich).

Ist jetzt aber auch nicht so, als wenn du mit alten Spielen auf einem modernen Windows keine Probleme hast. Bugs gibt es immer und ob ein altes Spiel auf moderner Hardware effizienter laufen könnte als es tut... das ist auch heute bei DX9+ bereits so. Auch, dass eine Engine in DX11 mal AMD mal NVidia eher schmeckt, das gibt's heute auch schon so. Performance-"Gleichheit" kam auch nicht kostenlos, sondern der Entwickler hat zum Teil dafür dafür gesorgt.

Es ändert sich also nur theoretisch etwas. Praktisch hat man aber (zumindest mit Vulkan, kA über DX) die Möglichkeit z.B. für Validation Layer. Hier wird dem Entwickler direkt um die Ohren gehauen, wenn er Mist baut. Klar ist der auch nicht perfekt, aber unter OpenGL hatte man sowas z.B. gar nicht. Das sorgt auch für Performance-Optimierungen, da der Validation Layer auch allgemeine Performance-Tipps geben kann.

Wenn in 5 oder 10 Jahren die Hersteller GPUs bauen die validen Vulkan 1 Code nicht mehr ausführen können, dann hat hier der GPU-Hersteller Mist gebaut. Man schickt ja auch keinen herstellerspezifischen Assembler an den Treiber. Das Zeug folgt schon einem universellen Standard. Der Treiber hat schon noch genug Möglichkeiten den Bytecode zu optimieren.

[SaschaW]

Es gibt ein neues SDK (1.0.39.0) mit neuen Extensions:
- VK_KHR_get_physical_device_properties2
- VK_KHR_maintenance1
- VK_KHR_shader_draw_parameters
- VK_EXT_direct_mode_display
- VK_EXT_display_surface_counter
- VK_EXT_display_control

Download via https://vulkan.lunarg.com/. Von NVIDIA gibts auch schon passende öffentliche Treiber (Hardware Report (http://vulkan.gpuinfo.org/displayreport.php?id=1058)).

Im Header findet man u.a. VK_USE_PLATFORM_VI_NN (https://github.com/KhronosGroup/Vulkan-Docs/blob/1.0/doc/specs/vulkan/appendices/VK_NN_vi_surface/vk_nn_vi_surface.txt), also zum ersten Mal was von Nintendo. Damit kann man ein Surface für die WiiU erstellen (VI = Video Interface), der Punkt ist also ggü. der Shield TV anders. Bin mal gespannt ob Nintendo auch Extensions entwickeln und zum Vulkan Ökosystem beitragen wird.

[Hübie]

Wenn kein Programm das benutzt ist es leider noch nutzlos für Endanwender wie mich, oder?

@pixeljetstream: An wen müsste ich mich wegen der Performanceprobleme in Doom wenden? Bethesda, id software oder an euch bei NVIDIA? :confused: Ergibt einfach keinen Sinn, wenn man an bestimmten Stellen auf den Boden guckt und die fps einbrechen.

[Chris Lux]

Versuche es bei id Software. Aber ob sich da für Doom noch etwas tut ist leider sehr unwahrscheinlich. Seit letztem Sommer hat sich bei Doom technisch nichts mehr getan es gab nur noch (Pay)-Content Updates.

Vielleicht kommt ja noch etwas wenn Doom-VR erscheint.

[HOT]

Kurzer Test Doom Windows vs. Wine 2.0 Staging (RC5) auf Linux 4.9 mit GTX 1070 OC, Ultra Details & Standard:

Windows 10:
OpenGL: ~105fps
Vulkan: ~92fps

Linux:
Vulkan: ~86fps (CPU: ~4,6ms)
OpenGL: ~70fps (CPU: ~14,13ms)

Teststelle (angezeigten fps niedrig wegen Screenshot-Aufnahme):
https://abload.de/thumb/screenshot20170117172tssr5.png (http://abload.de/image.php?img=screenshot20170117172tssr5.png)

Irgendwas klemmt bei OpenGL auf Linux mit Wine bei der CPU. Vulkan läuft bei dem Spiel auf Nvidia mit Windows schon mitunter merkbarer langsamer als OGL. Aus id's Versprechen, den Vulkan-Pfad auch noch für NV zu optimieren, ist offenbar nichts geworden. Genau so hört man nichts mehr von Async Compute für andere AA-Modi als TSSAA, was Sousa auf Twitter angekündigt hatte...
Ist glaube ich wieder falsch herum gedacht. NV wird den OpenGL-Pfad in deren Treiber wieder so stark auf Doom optimiert haben, dass die id-Optimierung über Vulkan langsamer ist. Die Linux-Werte würden ebenfalls genau dafür sprechen.

[Ganon]

Die OpenGL (ES) und Vulkan Conformance Test Suite ist nun OpenSource:

https://github.com/KhronosGroup/VK-GL-CTS

[iuno]

Ist glaube ich wieder falsch herum gedacht. NV wird den OpenGL-Pfad in deren Treiber wieder so stark auf Doom optimiert haben, dass die id-Optimierung über Vulkan langsamer ist. Die Linux-Werte würden ebenfalls genau dafür sprechen.
Sicher hat Nvidia da einiges versucht, gerade weil es vergleichsweise so gut auf AMD lief. Es haengt ja auch nach wie vor von der CPU ab, ist aber trotzdem erstaunlich.
Bzgl. dieses Themas ist mir aber noch eine andere Sache eingefallen, um die Unterschiede bei GL aufzuzeigen: Firefox und Chrome nutzen unter Windows fuer WebGL standardmaessig Angle als translation layer von GLSL zu HLSL bzw. gles -> d3d9. Mit einer AMD wird man dadurch deutlich(!) schneller, bei Nvidia habe ich das nicht (bzw. sogar leichte Einbussen) feststellen koennen. Das, und alleine schon die Tatsache, dass Google sich genoetigt sieht, Angle zu entwickeln, spricht wohl Baende :freak:
Zugegebenermassen war das aber auch ein eher realitaetsfremder Test (shadertoy, also nur fragment shader).

[Foobar2001]

Intel ist bei OpenGL aber auch nicht besser.

Die OpenGL (ES) und Vulkan Conformance Test Suite ist nun OpenSource:

https://github.com/KhronosGroup/VK-GL-CTS
Ich meine zumindest die Vulkan CTS schon mal frueher auf Github gesehen zu haben.

[SaschaW]

Der Vulkan CTS ist schon länger open source und auf Github, die für OpenGL und ES sind neu.

[Ganon]

Dazu muss man aber auch sagen, dass OpenGL unter Windows halt relativ selten zum Einsatz kommt. Entsprechend kommen mit neuen Spielen, welche OpenGL nutzen, auch meist direkt neue Treiber ohne die es gar nicht geht, weil bei der Entwicklung genug Bugs gefunden wurden. Mal als Beispiel No Man's Sky. Bei DOOM weiß ich das gerade nicht.

Auch Emulatoren welche OpenGL und Direct3D unterstützen werden unter Windows meist mit dem Direct3D Backend benutzt. Andere "breitflächig genutzte Software" nutzt selten bereits OpenGL 4.x. Als Beispiel mal Blender was jetzt gerade erst auf OpenGL 3.2 upgraden will.... von 1.x/2.x.

Ist natürlich in dem Sinne auch ein Henne/Ei Problem. Aber z.B. unter Linux nutzen diverse Spieleports ja OpenGL, somit mehr OpenGL Software allgemein, somit auch mehr Tester. Fast nach jedem neuen Spiel für Linux werden in Mesa irgendwo noch Bugs gefunden, sofern es nicht ein Bug im Spiel ist, was auch oft genug passiert.

Von daher ist auch ANGLE keine sooo schlechte Idee, wenn man sich viele Kopfschmerzen ersparen will. Aber auch ANGLE bekommt ja gerade ein Vulkan-Backend verpasst.

[Loeschzwerg]

Frage zu vkQuake:
Warum kann man die Farbtiefe nicht ändern? Steht immer auf 24 bpp. Quakespasm ist auf 32 bpp festgenagelt.

Jemand nen Hinweis?

[Foobar2001]

Macht keinen Unterschied

[SaschaW]

Die Anzeige kann man bei vkQuake ignorieren. Die Swapchain wird immer mit dem ersten verfügbaren Format erstellt, und das ist i.d.R. 32 Bit RGBA oder BGRA, 24bpp Formate gibt es unter Vulkan eigentlich nicht mehr (http://vulkan.gpuinfo.org/listsurfaceformats.php). Kann man afair auch nicht zur Laufzeit umstellen, aber die 24bpp unter OpenGL sind ja i.d.R. auch 32bpp ;)

[Loeschzwerg]

Danke für die Erklärung :)

5x demo1 @ 1920x1080:
vkQuake ~571fps 1,7sec
Quakespasm ~500fps 1,9sec

Win10 64Bit und Iris Pro 580

[aufkrawall]

Wo wir gerade dabei sind, eine dumme Frage zwischendurch: Weiß jemand, woran es liegen kann, wenn die Linux-Version die PAK0.PAK nicht findet? Zumindest erscheint die gleiche Fehlermeldung, wie wenn der Windows-Version die Datei fehlt. Die Windows-Version mit Wine läuft.

[SaschaW]

In welchem Ordner (relativ zur Binary) liegt die .pak? Das Linux FS ist btw. case-sensitiv, also pak0.pak statt PAK0.PAK.

[aufkrawall]

Oh nein, nicht schon wieder diese Ursache.. :usad: :uhammer2:
Läuft, thx. :freak:

[Kartenlehrling]

https://www.khronos.org/developers/library/2017-vulkan-devu-vancouver
Video & Presentations: 2017 Vulkan DevU Vancouver

[Kartenlehrling]

https://01.org/linuxgraphics/blogs/imad/2017/all-advanced-graphics-features-all-certified-all-open
Intel kündigt zertifizierte Treiber unter Linux für #OpenGL 4.5 #OpenGLES 3.2 und #Vulkan 1.0

[Ganon]

Ich muss ja schon schmunzeln hierbei: https://webkit.org/blog/7380/next-generation-3d-graphics-on-the-web/

Apples WebKit Team schlägt eine neue WebAPI für 3D vor...


The major platform technologies in this space are Direct3D 12 from Microsoft, Metal from Apple, and Vulkan from the Khronos Group. While these technologies have similar design concepts, unfortunately none are available across all platforms.

Ist natürlich lustig, da ja gerade Apple daran schuld ist, dass Vulkan nicht auf allen Plattformen verfügbar ist :ugly:

[aufkrawall]

d2kx hatte ja vor einiger Zeit Hitman Vulkan für Linux geteasert, womöglich steht das nun unmittelbar bevor:
http://www.phoronix.com/scan.php?page=news_item&px=HITMAN-Linux-Feral

[iuno]

Hat er?
Ich glaube, dass das geteaste erste Vulkan Spiel von Feral eher rottr wird.

davon ab:
https://twitter.com/feralgames/status/829003687225868288


@feralgames #vulkan?
@tesfabpel OpenGL.
@feralgames Vulkan or OpenGL?
@JugandoenLinux The second one.


Ist natürlich lustig, da ja gerade Apple daran schuld ist, dass Vulkan nicht auf allen Plattformen verfügbar ist :ugly:

Ernsthaft, wen wollen die eigentlich damit trollen? :facepalm:

Goals
[...]
A technology that does not follow a single native API, which reduces the difficulty of implementation on platforms that do not support the chosen native API.

Hoffentlich bekommen sie dafuer eine dicke Schelle.

Alle(!) anderen sollen also jetzt eine neue Schnittstelle implementieren, weil Apple Vulkan nicht in den Kram passt. Und dann erdreisten sie sich noch dazu, das "einfacher" zu nennen.

Apple being Apple

Waere schoen, wenn devs, die mit Vulkan zu tun haben/hatten auch wirklich was dazu schreiben.
To submit feedback, please use GPU on the Web Github (https://github.com/gpuweb/) Issues where this charter is being developed.

[Foobar2001]

Ich muss ja schon schmunzeln hierbei: https://webkit.org/blog/7380/next-generation-3d-graphics-on-the-web/

Apples WebKit Team schlägt eine neue WebAPI für 3D vor...



Ist natürlich lustig, da ja gerade Apple daran schuld ist, dass Vulkan nicht auf allen Plattformen verfügbar ist :ugly:
Das ist so hirnlos. Die Metal Shading Language ist inkompatibel mit allem anderen.

Diese Firma geht mir so auf die Nerven. Sollen an ihrem Metal ersticken.

[aufkrawall]

Hat er?

Er meinte auch, man solle ihn nicht steinigen, wenn es anders kommt. :biggrin:
Schade, schon wieder kein Vulkan.

[SaschaW]

Vulkan auf Apple geht (über Umwege und kommerziell) mit MoltenVK, wer also nur auf Vulkan setzt kann seinen Rendercode rein technisch auch auf Apple nutzen. Ob man das will sei mal dahingestellt.

Vulkan für das Web (als Nachfolger zu WebGL, also z.B. WebVulkan) wurde schon oft diskutiert ist aber aufgrund schwierig weil die API recht nah an der Hardware ist. Man müsste dann bestimmte Dinge aus Sicherheitsgründen abstrahieren (z.B. das explizite Speichermanagement ) bzw. vereinfachen (Synchronisation) und wäre dann aber ja wieder irgendwo (fast) bei OpenGL.

Und da WebGL eigentlich recht gut läuft (bzw. nicht so stark fragmentiert war wie OpenGL) und grade erst WebGL2 live ging wird es da von Khronos zumindest kurzfristig nix neues geben.

Aber eine neue API halte ich auch für keine gute Idee. Dann lieber mit z.B. der Khronos-Gruppe zusammenarbeiten und was bestehendes erweitern bzw. verbessern.

[Ganon]

Vulkan auf Apple geht (über Umwege und kommerziell) mit MoltenVK, wer also nur auf Vulkan setzt kann seinen Rendercode rein technisch auch auf Apple nutzen. Ob man das will sei mal dahingestellt.

Naja, ich weiß nicht wie aktuell das Dokument ist, aber ist nicht so als wenn die Implementierung vollständig ist:

https://www.moltengl.com/docs/readme/moltenvk-0.13.0-readme-user-guide.html#limitations

Wobei ja, glaube ich, Sachen wie Geometry Shader von Metal gar nicht unterstützt werden, somit auch in Vulkan generell nicht gehen können. Aber da bin ich zu wenig aktiv drin.

Dann lieber mit z.B. der Khronos-Gruppe zusammenarbeiten und was bestehendes erweitern bzw. verbessern.

Es ist immer noch Apple. Sie haben nun so gut wie alle Khronos APIs in macOS und iOS sterben lassen. Selbst ihre eigene OpenCL API fassen sie nicht mehr an. Apple ist halt schnell darin irgend eine neue API zu definieren und dann, je nachdem, schneller oder langsamer sterben zu lassen.

[Ganon]

Hier wird auch gerade fleißig über die "Vulkan ist nicht überall verfügbar" geprügelt: https://github.com/gpuweb/admin/issues/1#issuecomment-278213012

[iuno]

@Sascha: Du koenntest dich ja als Vulkan Insider auch an der Diskussion auf GitHub beteiligen. Inzwischen gibt es dort auch haufenweise Anti-Apple Kommentare. Das hat zwar wohl seine Berechtigung, ist aber sicher auch nicht zweckdienlich. Insofern waeren ein paar konstruktive Einwaende sicher nicht verkehrt ;)

Hier wird auch gerade fleißig über die "Vulkan ist nicht überall verfügbar" geprügelt
Wo ist es denn nicht verfuegbar? Auf uralten Androids und eben bei Apple.

While Vulkan is young, and there isn't much content written for it, it's basically the only modern low-level API available on some platforms (e.g. Linux), so its success is important to many people.
Das wird glaube ich schon so langsam zum Klassiker, Vulkan aufs "ist eh nur fuer Linux-Freaks interessant"-Abstellgleis zu schieben. Vulkan ist cross-platform und sollte endlich auch so wahrgenommen werden.

Was auch toll ist: "die Implementierung vereinfachen" heisst wohl, dass nur Apple keine Arbeit haben soll. Leider ist es nur so, dass das Web nicht nur aus Safari besteht und die meistverwendeten Browser ebenfalls cross-platform sind (Chrome, auch der weniger genutzte FF). Und die sollen dann halt mal eben 3 Backends fuer alle Plattformen implementieren? :freak:

[aufkrawall]

Kann es sein, dass Apple nun, statt es wie bisher zu ignorieren, sich aktiv an einer Beschädigung Vulkans versucht?
Käme mir aber ziemlich hilflos vor.

[iuno]

Keine Ahnung

A: Webkit Leute haben einfach von sich aus gesagt, dass es toll waere, im Web was anderes als WebGL zu haben. Das ganze wird jetzt kontrovers diskutiert und am Ende kommt noch was Brauchbares heraus
B: Apple will eine Metal-aehnliche API durchdruecken, die auch auf nicht-Apple Plattformen oberhalb von d3d12 und Vulkan implementiert und von vielen benutzt wird, um Metal nebenbei zu pushen.

Von A-B ist imho alles moeglich :ulol: Es ist halt Apple. Ich hoffe, dass sich entsprechend gewichtige Parteien wie Google mit Chrome, aber auch Mozilla oder Khronos bald einschalten und eine gute Loesung finden.

[Ganon]

Wo ist es denn nicht verfuegbar? Auf uralten Androids und eben bei Apple.

Na das ist doch der Punkt. Das Argument ist "Vulkan ist nicht überall verfügbar"... und das kommt von einem Apple-Mitarbeiter.

Seine Argumente dort sind "Windows bietet es nicht ootb und ChromeOS auch nicht". Ja, also das mit Windows ist Käse, weil Windows ootb gar keine Treiber liefert, sondern sie nachinstalliert und ChromeOS kriegt Vulkan-Support.

Das verbleibende Argument ist also "seitens Apple" (bzw. dem WebKit Team): "Vulkan ist nicht überall verfügbar, weil Apple es nicht unterstützt". Das ist halt das grundlegende Argumentationsproblem bei dem ganzen Vorschlag. Und das wird gerade recht intensiv diskutiert.

edit:
Nebenbei unterstützt Apple ja auch kein modernes OpenGL. Man versucht hier also schlicht etwas vorzuschlagen was nur dabei hilft auf Metal abbildbar zu sein. Nichts anderes.

[iuno]

Ja eben, aber das will er ja nicht einsehen bzw. schiebt es beiseite.
So provoziert man doch nur dass man am Ende wieder ein Chaos hat wie bei OGL/GLES/WebGL. Dann gibt es ueberall plattformabhaengige Implementierungen und am Ende kommen noch solche Flicken wie ANGLE dazu.

Ich habe auch die dringende Notwendigkeit fuer eine "LL" API im Web eh noch nicht verstanden. WebGL 2 ist noch sehr frisch, und dann hat man im Browser eh auch nur vergleichsweise lahmes JS (oder benutzt irgendwer WebAssembly?). Wer braucht da top-notch Grafik?

Und die Bedenken einger bzgl. Mining ads o.Ae. kann ich auch nachvollziehen. Dann hat man die Situation dass man es manuell im Browser aktivieren muss wie ein PlugIn und genau das will man ja nicht haben bei solchen Standards. Und es abzuwaelzen auf die grossen Werbenetzwerke wird auch nicht funktionieren.

[SaschaW]

Wobei ja, glaube ich, Sachen wie Geometry Shader von Metal gar nicht unterstützt werden, somit auch in Vulkan generell nicht gehen können. Aber da bin ich zu wenig aktiv drin.

Geometry und Tessellation (shader) sind optional, müssen also nicht von jeder Vulkan-Implementation unterstützt werden. Compute hingegen schon.

Die Diskussion um den neuen Standard von Apple muss ich jetzt nach Feierabend erstmal nachholen, bin aber (erstmal) der Meinung dass man sowas lieber einer Gruppe wie Khronos überlassen sollte und nicht dem W3C, und ich hoffe dass Apple da mit sich reden lasen ;)

Vulkan in seiner aktuellen Form wäre aus Sicherheitsgründen zwar eher ungeeignet für das Web, aber es wird ja auch z.B. an einer Safety Criticial Variante gearbeitet (wie schon bei OpenGL SC), da würde dann auch eine solche Web-API ggf. reinpassen.

[d2kx]

Croteam: Serious Sam/Talos Principle 2017 Roadmap (http://www.croteam.com/serious-wednesday-update/)
Croteam

Serious Sam VR: The Last Hope “Shanti” update
SSVR: The Second Encounter
Serious Sam 3 VR: BFE
The Talos Principle VR
Serious Sam 4

Kommen alle dieses Jahr und laufen alle mit dem kommenden Serious Sam Fusion 2017 Engine Update. Alle Spiele unterstützen Vulkan auf Windows und Linux, VR und nonVR, Multiplayer läuft Crossplatform, auch zwischen VR und nonVR:

All games now support SteamOS/Linux/OSX!
Split-screen!
64bit executables
Support for Vulkan API (DirectX9 is now being removed; so long and thanks for all the bugs)
Multithreaded rendering
The new “lightweight” savegame system; savegames are now saved much faster, are very small and stored in the Steam cloud, and savegames still work even if a level is changed in a patch, or if a mod is updated
Full support for all controllers including Steam controller, PS4 gamepads, all older DInput joysticks
Proper multimonitor support
Borderless window support
Customizable sound outputs
Proper 3D audio using a proprietary sound-mixer (the same approach as used in the old Classics games)
Improved physics engine with better handling of character movement
Texture streaming in all games
Much better modding support with customizable weapons and items, improved scripting (including better support for scripting networked games)
Lots of other improvements, optimizations and fixes
And last but not the least – we will now be able to more easily ship updated code towards all these titles more regularly!

[Loeschzwerg]

Mega!!! :eek: Ein Engine Update für alle Games. Richtig fette Sache von Croteam.

[aufkrawall]

Und last but not least SS4 2017 Vulkan Linux bestätigt. =)
SS: SE HD mit neuer Engine macht auch definitiv Sinn. Nicht nur wegen Linux, sondern weil SE 3.0 noch ziemlich ekligen Input Lag hatte.

[d2kx]

Ich sollte vielleicht nochmal darauf hinweisen, dass im Blog nirgendswo steht, dass Serious Sam 4 noch 2017 erscheint. Ich weiß, dass das ihr Plan ist, aber es ist keine offizielle Angabe und kann sich natürlich immer verzögern.
Aber Linux & (vollständiger) Vulkan-Support (und LiquidVR für die VR-Varianten) sind bombenfest.

[aufkrawall]

Es gab ein Update für Talos Principle mit Verbesserungen für Vulkan (nicht zu verwechseln mit dem ausstehenden SE 2017 Update).
Ich hatte ja häufig die Frametimes mit dem Vulkan-Renderer des Spiels kritisiert, und um so mehr freut es mich sagen zu können, dass sich besagte Frametimes mit dem Update massiv verbessert haben (auch zusammen mit dem Textur-Streaming, ich hatte da schon immer einen Zusammenhang vermutet).
Wenn sich das Spiel ein paar Sekunden eingelaufen hat, läuft es nun mit Vulkan fast genau so sauber wie mit DX11 (Edit: In neuen Gebieten muss es sich aber erst wieder "einlaufen", Verbesserungspotenzial also weiterhin vorhanden).
fps am Spawnpunkt des Demo-Levels (4k, Custom Settings)
DX11: 87fps
Vulkan: 79fps (sowohl Windows 10 als auch Linux Tumbleweed)
Vulkan ist in dem Spiel nun endgültig ein massiver Gewinn auf der Linux-Plattform. Ich hatte zwischendurch allerdings einen System-Freeze, jemand mt 970 berichtet bei Steam ähnliches. Tippe auf Treiber-Bug.

[Ganon]

Haswell + Mesa 17 + Dolphin mit Vulkan-Backend:

https://abload.de/thumb/bildschirmfotovom2017onuye.png (http://abload.de/image.php?img=bildschirmfotovom2017onuye.png)

Intels OpenSource Linux Treiber Team ist einfach klasse! Ging mit Mesa 13 noch nicht.

[Stebs]

Vielleicht hat es ja der eine oder andere verpasst:

Intel bringt endlich auch offizielle Windows Vulkan Treiber für Skylake (Win 7, 8.1, 10) und Kabylake (Win 10).
https://software.intel.com/en-us/blogs/2017/02/10/intel-announces-that-we-are-moving-from-beta-support-to-full-official-support-for

[Ailuros]

Vulkan vs. OGL von IMG auf einer 3D sattelite navigation application: https://www.imgtec.com/blog/vulkan-3d-satnav-app-powervr/

[d2kx]

There Are Signs Of Vulkan Within Feral's Linux Port Of HITMAN (http://www.phoronix.com/scan.php?page=news_item&px=Vulkan-Signs-HITMAN)
Phoronix

Serious Sam VR: The First Encounter Update 291416 - The Vulkan/Linux Update (http://steamcommunity.com/app/552450/discussions/0/133257324790016617/)
Steam

Und der Februar ist ja noch lang, munkelt man~

[Complicated]

Der ist einfach zu gut um ihn nicht hier zu posten
Intel supports Vulcans (http://www.fudzilla.com/news/processors/42872-intel-supports-vulcan)

mit diesem Bild als Aufmacher.

http://www.fudzilla.com/media/k2/items/cache/1a6f0ff9014fc95fac616eb07e79f5c6_L.jpg

;D;D;D;D;D;D;D

[Foobar2001]

Der Artikel ist grottenschlecht.

"For those who came in late Vulkan is similar to DirectX 12 – it is supported by AMD.".

Bullshit. NVIDIA hat viel mehr Macht im Konsortium im Moment.

[aufkrawall]

Und der Februar ist ja noch lang, munkelt man~
Diesmal nagel ich dich drauf fest, zumindest kauf ich mir nun wohl noch die übrigen Episoden. :tongue:

[Complicated]

@Foobar2001
Seit wann gibt es bei Fudzilla gute Artikel?
Das Bild war gemeint mit dem Spruch dass Intel "Vulcans" unterstützt.

Was die Macht von Nvidia in dem Konsortium angeht...der Kommentar hat mindestens die selbe Qualität wie der Artikel über den du schreibst.
AMD "supported" Vulkan aber "Nvidia hat viel mehr Macht"? Relevanz und Zusammenhang?

[Foobar2001]

Was soll der Satz sagen? "It is supported by AMD". Im Gegensatz zu NVIDIA? Nein. Im Gegensatz zu DX12? Nein.

Die einzige Interpretation die irgendwie Sinn ergibt, ist das er denkt, dass Vulkan eine AMD-Technologie ist und sie deswegen einen Vorteil haben. Das ist nicht der Fall.

[Complicated]

Keine Ahnung ich finde den Bericht ebenso schlecht und kaum gehaltvoll, das schrieb ich schon. Ich fand Spock lustig und dass er supported wird von Intel. Thats all. Kapiert diesmal? Sie schreiben nicht "Vulkan" sondern "Vulcans" - eine humorvolle Homage, die an dir vorbei geht anscheinend. Sorry für deine Verwirrung.

Welcher Humor allerdings hinter deiner "Machtergreifung von Nvidia" steht entgeht mir allerdings ebenfalls. Daher sind wir wohl Quit und müssen den OT nicht weiter ausweiten. Tief durchatmen und eine Mütze voll Schlaf wäre meine Empfehlung ;)

[Foobar2001]

Ich bin in einer anderen Zeitzone.

[Iruwen]

Axel?

[Screemer]

Axel?
Kann ich mir nicht vorstellen. Seine post lesen sich irgendwie anders. Würde noch aber sehr freuen.

[aufkrawall]

Seine post lesen sich irgendwie anders.
Kein Stück. :freak:

[Screemer]

sind kurz und knapp ;)

[samm]

Geworden. Waren sie nicht immer, also foobar's. Ist so oder so cool, wieder Dev-Einblicke zu haben, die seit Coda's und Alphatier's Verschwinden und die Ausrichtung von Demirug weggefallen sind.

[Gast]

dass Vulkan eine AMD-Technologie ist und sie deswegen einen Vorteil haben. Das ist nicht der Fall.Basiert es nicht auf Mantle und hat vieles was bei NVidia überflüssig ist? Gibt es irgendwas an Vulkan was NVidia affin ist?

[bnoob]

Die nVidia-eigenen Befehlserweiterungen, beispielsweise

[Foobar2001]

Basiert es nicht auf Mantle und hat vieles was bei NVidia überflüssig ist? Gibt es irgendwas an Vulkan was NVidia affin ist?
So gut wie alles wurde geaendert gegenueber Mantle. Nein, es hat nichts was bei NVIDIA ueberfluessig ist. Im Gegenteil, viele Features wurden entfernt die nicht auf NVIDIA funktionieren oder hinzugefuegt die eigentlich nicht so toll sind auf AMD (push constants z.B.)

Es ist ein Mythos, dass Vulkan eine AMD-API ist.


Adam Jackson, Red Hat
Adam Śmigielski, Mobica
Alex Bourd, Qualcomm Technologies, Inc.
Alexander Galazin, ARM
Allen Hux, Intel
Alon Or-bach, Samsung Electronics (WSI technical sub-group chair)
Andrew Cox, Samsung Electronics
Andrew Garrard, Samsung Electronics (format wrangler)
Andrew Poole, Samsung Electronics
Andrew Rafter, Samsung Electronics
Andrew Richards, Codeplay Software Ltd.
Andrew Woloszyn, Google
Antoine Labour, Google
Aras Pranckevičius, Unity
Ashwin Kolhe, NVIDIA
Ben Bowman, Imagination Technologies
Benj Lipchak
Bill Hollings, The Brenwill Workshop
Bill Licea-Kane, Qualcomm Technologies, Inc.
Brent E. Insko, Intel
Brian Ellis, Qualcomm Technologies, Inc.
Cass Everitt, Oculus VR
Cemil Azizoglu, Canonical
Chad Versace, Intel
Chang-Hyo Yu, Samsung Electronics
Chia-I Wu, LunarG
Chris Frascati, Qualcomm Technologies, Inc.
Christophe Riccio, Unity
Cody Northrop, LunarG
Courtney Goeltzenleuchter, LunarG
Damien Leone, NVIDIA
Dan Baker, Oxide Games
Dan Ginsburg, Valve
Daniel Johnston, Intel
Daniel Koch, NVIDIA (Shader Interfaces; Features, Limits, and Formats)
Daniel Rakos, AMD
David Airlie, Red Hat
David Neto, Google
David Mao, AMD
David Yu, Pixar
Dominik Witczak, AMD
Frank (LingJun) Chen, Qualcomm Technologies, Inc.
Fred Liao, Mediatek
Gabe Dagani, Freescale
Graeme Leese, Broadcom
Graham Connor, Imagination Technologies
Graham Sellers, AMD
Hwanyong Lee, Kyungpook National University
Ian Elliott, LunarG
Ian Romanick, Intel
James Jones, NVIDIA
James Hughes, Oculus VR
Jan Hermes, Continental Corporation
Jan-Harald Fredriksen, ARM
Jason Ekstrand, Intel
Jeff Bolz, NVIDIA (extensive contributions, exhaustive review and rewrites for technical correctness)
Jeff Juliano, NVIDIA
Jeff Vigil, Qualcomm Technologies, Inc.
Jens Owen, LunarG
Jeremy Hayes, LunarG
Jesse Barker, ARM
Jesse Hall, Google
Johannes van Waveren, Oculus VR
John Kessenich, Google (SPIR-V and GLSL for Vulkan spec author)
John McDonald, Valve
Jon Ashburn, LunarG
Jon Leech, Independent (XML toolchain, normative language, release wrangler)
Jonas Gustavsson, Sony Mobile
Jonathan Hamilton, Imagination Technologies
Jungwoo Kim, Samsung Electronics
Kenneth Benzie, Codeplay Software Ltd.
Kerch Holt, NVIDIA (SPIR-V technical sub-group chair)
Kristian Kristensen, Intel
Krzysztof Iwanicki, Samsung Electronics
Larry Seiler, Intel
Lutz Latta, Lucasfilm
Maria Rovatsou, Codeplay Software Ltd.
Mark Callow
Mark Lobodzinski, LunarG
Mateusz Przybylski, Intel
Mathias Heyer, NVIDIA
Mathias Schott, NVIDIA
Maxim Lukyanov, Samsung Electronics
Maurice Ribble, Qualcomm Technologies, Inc.
Michael Lentine, Google
Michael Worcester, Imagination Technologies
Michal Pietrasiuk, Intel
Mika Isojarvi, Google
Mike Stroyan, LunarG
Minyoung Son, Samsung Electronics
Mitch Singer, AMD
Mythri Venugopal, Samsung Electronics
Naveen Leekha, Google
Neil Henning, Codeplay Software Ltd.
Neil Trevett, NVIDIA
Nick Penwarden, Epic Games
Niklas Smedberg, Epic Games
Norbert Nopper, Freescale
Pat Brown, NVIDIA
Patrick Doane, Blizzard Entertainment
Peter Lohrmann, Valve
Pierre Boudier, NVIDIA
Pierre-Loup A. Griffais, Valve
Piers Daniell, NVIDIA (dynamic state, copy commands, memory types)
Piotr Bialecki, Intel
Prabindh Sundareson, Samsung Electronics
Pyry Haulos, Google (Vulkan conformance test subcommittee chair)
Ray Smith, ARM
Rob Stepinski, Transgaming
Robert J. Simpson, Qualcomm Technologies, Inc.
Rolando Caloca Olivares, Epic Games
Roy Ju, Mediatek
Rufus Hamede, Imagination Technologies
Sean Ellis, ARM
Sean Harmer, KDAB
Shannon Woods, Google
Slawomir Cygan, Intel
Slawomir Grajewski, Intel
Stefanus Du Toit, Google
Steve Hill, Broadcom
Steve Viggers, Core Avionics & Industrial Inc.
Stuart Smith, Imagination Technologies
Tim Foley, Intel
Timo Suoranta, AMD
Timothy Lottes, AMD
Tobias Hector, Imagination Technologies (validity language and toolchain)
Tobin Ehlis, LunarG
Tom Olson, ARM (working group chair)
Tomasz Kubale, Intel
Tony Barbour, LunarG
Wayne Lister, Imagination Technologies
Yanjun Zhang, Vivante
Zhenghong Wang, Mediatek

[d2kx]

SteamVR for Linux (Beta) (https://github.com/ValveSoftware/SteamVR-for-Linux)
GitHub (Release Notes)

SteamVR/Linux ist soeben als Beta gelaunched. Es wird (vorerst?) keinen OpenGL-Support geben, sondern man setzt voll auf Vulkan. Aus diesem Grund stellt Valve gerade auch mehr und mehr Treiberentwickler für den freien AMD-Treiberstack ein.

Einer der drei kommenden VR-Titel von Valve setzt auf die Unity-Engine, aus diesem Grund hat Valve derzeit auch ein starkes Interesse daran, den Vulkan-Support in Unity voranzutreiben.

#edit:

Von Valve gibt es jetzt über GitHub einen speziellen radv-Treiberbuild mit Vulkan VR-Extensions für AMD, die noch nicht offiziell veröffentlicht wurden/Teil von Vulkan 1.0 sind. Valves Destinations und Dota2 VR für SteamVR/Linux sind inzwischen ebenfalls veröffentlicht und laufen ebenfalls erstmals auf Vulkan (nutzen unter Windows nutzt derzeit DX11).

Aber die GDC ist ja auch vor der Tür...

[hmmm]

...
Es ist ein Mythos, dass Vulkan eine AMD-API ist.
...
Wurde so ja auch nicht behauptet und natürlich ist Vulkan nicht 1:1 Mantle,
aber das Vulkan seine Wurzeln bei Mantle hat wird sowieso von niemanden
bestritten. --Ok, kenne Nvidias "Fun fact" Haltung zu diesem Thema nicht.

Ps: Mantle is a Vulkan :smile:

[Arcanoxer]

Ps: Mantle is a Vulkan :smile:
Mantle ist AMDs gescheiterer versuch eine low level API für Radeon only auf den Markt zu bringen. Vulkan ist Khronos offener standard.

/topic
Unity 5.6 supports Vulkan out-of-the-box (35:25) (https://blogs.unity3d.com/2017/02/28/updates-from-unitys-gdc-2017-keynote/)

[Foobar2001]

Wurde so ja auch nicht behauptet und natürlich ist Vulkan nicht 1:1 Mantle,
aber das Vulkan seine Wurzeln bei Mantle hat wird sowieso von niemanden
bestritten. --Ok, kenne Nvidias "Fun fact" Haltung zu diesem Thema nicht.

Ps: Mantle is a Vulkan :smile:
Nein.

Mantle ist AMDs gescheiterer versuch eine low level API für Radeon only auf den Markt zu bringen. Vulkan ist Khronos offener standard.
Gescheitert ist daran gar nichts, sie haben exakt das bekommen was sie wollten mit DX12 und Vulkan.

[EOVI]

Es ist ein Mythos, dass Vulkan eine AMD-API ist.

Also hat laut dir Vulkan seine Wurzeln nicht bei Mantle? Ich weiss nicht, was du unter "derived" verstehst aber selbst Khronos spricht davon:

The release of the Vulkan™ 1.0 specification is a huge step forward for developers. The Vulkan API, which was derived from Mantle, will bring the benefits of low-overhead high-performance Graphics API to the benefit of cross-platform and cross-vendor targeted applications

[1] https://www.khronos.org/news/press/khronos-releases-vulkan-1-0-specification

[hmmm]

Nein.

Wie meinen?

[Kartenlehrling]

Die wichtigste Meldung von der GDC17 ist das alle kommende Bethesda Spiele mit Vulkan daher kommen.

[dargo]

Immerhin... schade nur, dass Dishonored 2 es nicht mehr geschafft hat.

[Foobar2001]

Also hat laut dir Vulkan seine Wurzeln nicht bei Mantle? Ich weiss nicht, was du unter "derived" verstehst aber selbst Khronos spricht davon:



[1] https://www.khronos.org/news/press/khronos-releases-vulkan-1-0-specification
Es hat seine Wurzeln bei Mantle, aber die Unterschiede sind gravierend. Schon seit der ersten Vulkan-Revision. Selbst DX12 ist aehnlicher als Mantle von der Semantik als Vulkan.

Vulkan hat z.B. "render passes" fuer mobile TBR GPUs, was es weder in Mantle noch in DX12 gibt. Es gibt auch keine Descriptor Heaps sondern nur Pools, damit es auch auf aelterer Hardware funktioniert.

Wie meinen?
Vulkan ist nicht Mantle.

Und falls ihr mir das alles nicht glaubt, schaut doch einfach mal die neuen Khronos-Extensions an die reingekommen sind (push constants, multi view fuer VR, device groups fuer SLI, etc.). Alles von NVIDIA geschrieben, vor allem von Jeff Bolz.

[Hübie]

Warum kommt das immer wieder auf? Ich check's net. X-D
Bethesda wird ja nun erst mal alle Hände voll zu tun haben und man konnte mit Doom ja schon gut Erfahrungen sammeln. Mit id-Tech 6 ist man zumindest intern gut aufgestellt (und wohl auch flexibel genug für andere Projekte). Ich hoffe dass es sich auf andere Studios auswirkt. :smile:

Sind die Performance-Probleme denn schon behoben? Es gab ja einige Stellen in Doom die unerklärlich mies liefen. Das wurde hoffentlich gefixt und Erkenntnisse fließen in die künftige Entwicklung ein.

Ob man den Creation-Murks endlich mal über Board wirfst? In TES VI erwarte ich aber dennoch hohe Modifiziertbarkeit - egal ob nun neue oder alte Engine, neue API oder alte API. :naughty:

[Kartenlehrling]

WI7nXq8oozw
Vulkan API vs OpenGL ES in Unity: Get 10-12% extra playtime on mobile!

[Arcanoxer]

Khronos 3D Portability Initiative (https://www.khronos.org/3dportability)

Due to industry demand, Khronos is initiating the development of a solution to enable 3D applications that are portable across Vulkan, DX12 and Metal.

[Foobar2001]

Das ist so eine Seuche. Es gibt bereits eine Cross-Platform-API, warum muss man da jetzt noch mal was darueber stuelpen?

[Arcanoxer]

Das ist so eine Seuche. Es gibt bereits eine Cross-Platform-API, warum muss man da jetzt noch mal was darueber stuelpen?
Bedank dich bei Apple und Microsoft die unbedingt ihre eigene low level API rausdrücken mussten und eben nicht Cross-Platform sind.

[Foobar2001]

Schon klar, das war auch die Kritik.

[StefanV]

Kann Vulkan eigentlich schon mGPU?

[Foobar2001]

Ja, VK_KHX_device_group

Ist experimentell und wird nur vom NVIDIA-Treiber unterstuetzt im Moment.

[Entropy]

Mantle ist AMDs gescheiterer versuch eine low level API für Radeon only auf den Markt zu bringen. Niemand hat lust eine API zu maintainen. Das macht eine Firma nur aus Protektionismus. AMD ganz sicher auch nicht, es war nur um endlich Treiber schwere APIs abzustoßen.
Mantle war ein strategischer Zug. Sie haben noch nie die besten Treiber gemacht und auch nicht die finanziellen Mittel diese Situation zu verbessern. Es macht da doch nur Sinn den Entwicklern zu verkaufen, dass alles besser wird, wenn Sie alles selbst machen. Die Zukunft wird zeigen, ob z.B. Doom einen Patch bekommt, z.B. falls Volta gut mit Async-Compute umgeht oder wenn Vulkan endlich Crossfire/SLI erlaubt, oder wenn sonst eine Arbeit nötig wird, die sonst treiberseitig war.

NVidia hatte einen Gegenvorschlag wie eine neue API aussehen sollte: https://www.slideshare.net/tlorach/opengl-nvidia-commandlistapproaching-zerodriveroverhead aber AMD hatte den besseren "Hype Train".

Das nette ist, dass in Vulkan auch NVidias Vorschlag möglich ist. Sobald Spiele persistenter und besser Datan auf der GPU halten, die Shader selbst auf Texturen zugreifen, statt wie jetzt alles von der CPU-Seite bei jedem DIP neu aufgesetzt zu bekommen, sind wir wieder GPU limitiert, da wo NVidias Vorschlag hinzielte. (Deswegen ging das schon mit OpenGL).

[Complicated]

Naja der Vorschlag kommt aus 2014 und die "Token Buffers" sind mit AMDs Asyncronous Compute noch flexibler umgesetzt worden. HSA setzt die Idee mit den Pointers besser um, da auch die CPU hier mit einbezogen wurde und vor allem auch das Mulit-Threading. Nvidia fehlt nach wie vor der gemeinsame Zugriff auf den Speicher durch CPU und GPU um Pointer übergeben zu können und so den Overhead weiter zu verkleinern. Das gemeinsame virtuelle Memory ist nicht ausdehnbar auf SSD/XPoint so wie es AMD mit Vega und dem HBCC nun kann. Die virtuelle Speicherasdressierung bei Nvidia ist somit begrenzt auf den verbauten System-RAM und den verbauten VRAM. AMD kann die Speicheradressierung auf Massenspeicher ausdehnen und die Kosten somit enorm drücken für das Gesamtsystem.

Das hat eher mit der besseren Umsetzung für das Gesamtsystem inkl. CPU zu tun als mit Hype warum AMD sich hier durchgesetzt hat mit ihrem technisch besseren Ansatz. AMD hat nun mal beide Technologien im Haus und dadurch einen Vorteil bei der Entwicklung von Kommunikation bei CPU und GPU.

[Foobar2001]

NVidia hatte einen Gegenvorschlag wie eine neue API aussehen sollte: https://www.slideshare.net/tlorach/opengl-nvidia-commandlistapproaching-zerodriveroverhead aber AMD hatte den besseren "Hype Train".
OpenGL noch weiter zuzumuellen war nie ein erfolgsversprechender Vorschlag.

Das nette ist, dass in Vulkan auch NVidias Vorschlag möglich ist. Sobald Spiele persistenter und besser Datan auf der GPU halten, die Shader selbst auf Texturen zugreifen, statt wie jetzt alles von der CPU-Seite bei jedem DIP neu aufgesetzt zu bekommen, sind wir wieder GPU limitiert, da wo NVidias Vorschlag hinzielte. (Deswegen ging das schon mit OpenGL).
Bitte was? Ich erkenne Worte in diesem Satz, aber keinen Sinn.

[vinacis_vivids]

Kann Vulkan eigentlich schon mGPU?

https://www.heise.de/newsticker/meldung/Doom-Update-integriert-Vulkan-Schnittstelle-und-Async-Compute-3265027.html

AOS:
https://abload.de/thumb/ashesmgpux0u1y.png (http://abload.de/image.php?img=ashesmgpux0u1y.png)

Weit weg dürften die nicht mehr sein.

[dildo4u]

Alte Karte GTX970 1080p Ultra 78fps

http://abload.de/img/vulkangz7s83.png

Neue Karte 1070 SC 1080p Ultra 122 fps

http://abload.de/img/img_20160923_103709715mk6b.jpg

Vulkan nutzt die Karte aber nicht wirklich aus geht locker über 2Ghz,Witcher 3 hängt bei 1.85.
Und irgendwie bekomm ich keine Vulkan Screens über druck mehr hin zeigt mir immer das Menü auf dem Screen.

Jetzt 98% GPU Last mit neuem Treiber 135 fps

http://abload.de/img/doomx64vk_2017_03_09_hkjbe.png

Noch ein Doom Test mit neuem Treiber:

Die Titan X ist nun fast 14 Prozent schneller als im August, so dass es in der Tat so aussieht, als habe Nvidia positive Änderungen umgesetzt – entweder über seine Treiber oder über eine Zusammenarbeit mit id.

http://www.tomshardware.de/nvidia-geforce-gtx-1080-ti,testberichte-242335-3.html

http://abload.de/img/doomvul8xkwd.png

[pixeljetstream]

Niemand hat lust eine API zu maintainen. Das macht eine Firma nur aus Protektionismus. AMD ganz sicher auch nicht, es war nur um endlich Treiber schwere APIs abzustoßen.
Mantle war ein strategischer Zug. Sie haben noch nie die besten Treiber gemacht und auch nicht die finanziellen Mittel diese Situation zu verbessern. Es macht da doch nur Sinn den Entwicklern zu verkaufen, dass alles besser wird, wenn Sie alles selbst machen. Die Zukunft wird zeigen, ob z.B. Doom einen Patch bekommt, z.B. falls Volta gut mit Async-Compute umgeht oder wenn Vulkan endlich Crossfire/SLI erlaubt, oder wenn sonst eine Arbeit nötig wird, die sonst treiberseitig war.

NVidia hatte einen Gegenvorschlag wie eine neue API aussehen sollte: https://www.slideshare.net/tlorach/opengl-nvidia-commandlistapproaching-zerodriveroverhead aber AMD hatte den besseren "Hype Train".

Das nette ist, dass in Vulkan auch NVidias Vorschlag möglich ist. Sobald Spiele persistenter und besser Datan auf der GPU halten, die Shader selbst auf Texturen zugreifen, statt wie jetzt alles von der CPU-Seite bei jedem DIP neu aufgesetzt zu bekommen, sind wir wieder GPU limitiert, da wo NVidias Vorschlag hinzielte. (Deswegen ging das schon mit OpenGL).

Meiner Meinung nach sind das drei verschiedene Themenkomplexe.

Du hast Recht dass AMD's Mantle Entscheidung stark strategisch motiviert war. Mit dem Gewinn der Konsolen, war es nur natürlich diesen Vorteil stärker unter PC ausspielen zu wollen, und neue APIs die flacher/günstiger für IHVs sind zu pushen. Man musste hier öffentlich was Auffahren um gegen die zwei anderen Hersteller im Markt (NVIDIA und Intel) sich durchzusetzen.

Allerdings kann man auch nicht bestreiten, dass keine der existierenden APIs auf einem ordentlichen Modernisierungskurs war. OpenGL's Pseudo-abwärtskompatibilität erlaubt kein richtiges Multi-threading-Modell, und MS hatte wohl hier auch nicht allzu viel vor, bis sie dann durch Mantle unter Zugzwang gerieten, wie GL ja auch. Eine API-Generation die Multithreading-freundlich und auch das Prinzip der verschiedenen Hardware-queues mitbringt, sowie Prevalidierung mehr nutzt war ohne Zweifel wichtig. Egal wie "low-level" oder "high-level" man das ganze dann am Ende umsetzt. Zum CPU-Overhead für einen CPU Thread würde ich sagen, gabs schon relativ coole Technik unter GL, sowohl von NV also auch AMD (bindless, MDI usw.).

Nun zur NV_command_list und vergleichbarem: das ist kein Gegenmodell und war auch nicht als solches gedacht. Es ist eine Evolution der Techniken, die der GPU mehr Fähigkeiten geben. Genau wie eben die neuen APIs eine Evolution sind, in Sachen multi-threading, queues usw. Sowohl CPU-API also auch "GPU-API" haben ihre Daseinsberechtigung und man sollte kein entweder oder daraus machen.

OpenGL noch weiter zuzumuellen war nie ein erfolgsversprechender Vorschlag.

Was die Vielfalt von GL oder Vulkan extensions angeht, so sehe ich das nicht als Zumüllen, sondern als Möglichkeit neue Techniken auszuprobieren, das ist ja unabhängig davon was im Core landet. NVIDIA hatte relativ viel in GL Extensions investiert die auf CPU-overhead und Programmierbarkeit abzielten (bindless, pointer in GLSL), was die Platform sehr beliebt bei Forschern oder Nischenmärkte machte, die ähnlich wie bein Konsolen andere Hardware nicht bedienen muss und wo Speziallösungen kein Problem sind. Doom nutzt z.B ja auch AMD extensions und wartet nicht bis KHR/KHX daraus geworden ist... auch wenn's dann am Ende mehr Extensions/Wege für ähnliche Features geben wird.

[Ganon]

OpenGL hat aber in dem Sinne die gleichen Probleme wie Vulkan. Bei einem top-aktuellen macOS kriegst du nur OpenGL 4.1. Daran wird sich vermutlich auch ne Weile nichts ändern, da Apple jetzt an ihrem Metal und ihrem WebGPU Kram bastelt.

Bis vor kurzem bekam man unter Linux mit aktuellen Intel-Treibern auch nur OpenGL 3.3. Seit einem halben Jahr bzw. bis vor kurzem dann OpenGL 4.5, je nachdem ob man Haswell, Broadwell oder Skylake hatte. Unter Windows mit Intel kriegst du teilweise nicht mal das. D.h. ein Top-Aktuelles OpenGL bekam man entweder nur unter Windows, oder nur unter Linux mit NVidia-Treiber. AMDs geschlossener OpenGL Treiber unter Linux kann man in die Tonne werfen. Der offene Treiber ist gerade noch in Arbeit, aber auch bei 4.5.

OpenGL weiter zufrachten mit Kram oder überhaupt noch daran zu arbeiten wäre verschwendete Zeit. Das ganze Ding ist mit seinem "Kompatibilitätsprofil", "Coreprofil" und zig Extensions die teils sich auch schon selbst überholt haben einfach nur verdammt unübersichtlich, die Treiber sind je nach Hersteller und OS voller Bugs und Eigenheiten.

Die Mobile-Sparte unterstützt OpenGL fast gar nicht (nur NVidia-Geräte), es bleibt nur OpenGL ES. Aber auch hier unterstützt nicht jedes Gerät OpenGL ES 3.2 (ich glaube Apple hat auch hier bei 3.1 aufgehört).

Und am Ende steht man dann wieder vor dem Problem, dass Hersteller die APIs einfach nicht implementieren. Es bleibt also nur, dass man es schafft die API als Web-Standard vorzubringen. Dann haben die Hersteller einfach keine Wahl.

OpenGL und Vulkan zeigen es doch wunderschön, dass die Idee und Umsetzung einer Cross-Platform API nicht funktioniert, weil die großen kommerziellen OS-Anbieter es nicht wollen. Bei OpenGL war's MS die über den WUS Treiber ohne OpenGL ausgeliefert haben, Apple hat dann auch irgendwann aufgehört. Bei Vulkan ist's Apple die es so es komplett bremsen, und MS die DX12 in bestimmten Situationen verlangen.

Was will man schon dagegen tun? Kampf gegen Windmühlen. Aber Vulkan ist zumindest schon mal ein Fortschritt in Sachen Windows/Android/Linux, aber auch im Bereich Tooling (offizielle Compiler etc.).

[Foobar2001]

Was die Vielfalt von GL oder Vulkan extensions angeht, so sehe ich das nicht als Zumüllen, sondern als Möglichkeit neue Techniken auszuprobieren, das ist ja unabhängig davon was im Core landet. NVIDIA hatte relativ viel in GL Extensions investiert die auf CPU-overhead und Programmierbarkeit abzielten (bindless, pointer in GLSL), was die Platform sehr beliebt bei Forschern oder Nischenmärkte machte, die ähnlich wie bein Konsolen andere Hardware nicht bedienen muss und wo Speziallösungen kein Problem sind. Doom nutzt z.B ja auch AMD extensions und wartet nicht bis KHR/KHX daraus geworden ist... auch wenn's dann am Ende mehr Extensions/Wege für ähnliche Features geben wird.
OpenGL war einfach zu unhandlich geworden. Das ist eine generelle Kritik von mir. Selbst für Basics gab es fünf Wege das gleiche zu machen (VAO, VBO, arrays, etc.). Es war an der Zeit einen Reset zu haben.

Der Bindless-Kram hatte auch Bugs als ich es dann mal wirklich benutzt hatte abseits von simplen Demos. In Vulkan gibt's für das meiste conformance tests.

[pixeljetstream]

Und am Ende steht man dann wieder vor dem Problem, dass Hersteller die APIs einfach nicht implementieren. Es bleibt also nur, dass man es schafft die API als Web-Standard vorzubringen. Dann haben die Hersteller einfach keine Wahl.

Die größeren IHVs sind vermutlich nicht unbedingt Fans vom Web-Standard, weil das Ziel der Platformstabilität und einfachen Verfügbarkeit, dem der Innovation durch neue Hardware gegenüber steht.
Ausserdem ist es hier den Browserherstellern überlassen wie sie die API implementieren (siehe WebGL auf DirectX).

Wer hat die Kontrolle und was ist denen wichtig: billigere Hardware um die Magen zu steigern (je mehr man die Technik einbremst, desto mehr Hersteller können das günstig anbieten), oder Differenzierung zur Konkurrenz (sei es die Platform, die Hardware etc.).

Zumindest die Grafik IP Hardwarehersteller brauchen Märkte wo sie ihre Fähigkeiten entfalten können, ansonsten sind Sie nur austauschbarer Zulieferer und die ganze Kohle die in die Forschung geht verpufft. Ein langfristiger Ausweg könnte da das cloud rendering sein, dann ist das Endgerät wieder nicht so wichtig.

[Ganon]

Die größeren IHVs sind vermutlich nicht unbedingt Fans vom Web-Standard, weil das Ziel der Platformstabilität und einfachen Verfügbarkeit, dem der Innovation durch neue Hardware gegenüber steht.
Ausserdem ist es hier den Browserherstellern überlassen wie sie die API implementieren (siehe WebGL auf DirectX).

Ja, sorry, mit Hersteller meinte ich den OS-Hersteller. Denn z.B. bei macOS hat der Grafikkartenhersteller gar nicht die Möglichkeit eine aktuellere OpenGL Version oder Vulkan-Support auszuliefern.

Das ist ja gerade das Problem bei Vulkan. Unter Windows kriegst du es, obwohl MS es nicht direkt unterstützt. Aber Apple eben. Die blockieren es auf ganzer Linie.

Wenn etwas aber in den Web-Standard wandern, dann geht das schlicht nicht mehr. Ob sie es intern ummappen oder nicht ist dann ja auch egal. Man sieht ja an MoltenVK, dass Apple auch "einfach" Vulkan auf Metal mappen könnte... wenn sie dann wollen.

[Achill]

Die größeren IHVs sind vermutlich nicht unbedingt Fans vom Web-Standard, weil das Ziel der Platformstabilität und einfachen Verfügbarkeit, dem der Innovation durch neue Hardware gegenüber steht.
Ausserdem ist es hier den Browserherstellern überlassen wie sie die API implementieren (siehe WebGL auf DirectX).


Für den Web-Teil wäre mir das egal, als User überwiegt bei mir mein Bedürfnis nach Sicherheit und Kompatibilität statt einen direkten Zugriff auf die HW/Features. Für eine Web-Anwendungen entscheidet man sich, weil der Browser eine Universale Plattform ist.

Hat man andere (spezifiziere) Anforderung, dann ist eine Web basierte Lösung nicht optimal.

Entwicklungen die nur ein IHVs (gut) unterstützt, hat hier natürlich nicht viel Wert, weil es den Werten der Plattform zuwider läuft und die Browser-Hersteller auch ein Wörtchen mit zu reden haben.


Wer hat die Kontrolle und was ist denen wichtig: billigere Hardware um die Magen zu steigern (je mehr man die Technik einbremst, desto mehr Hersteller können das günstig anbieten), oder Differenzierung zur Konkurrenz (sei es die Platform, die Hardware etc.).


... oder man müsste sich absprechen, in welchen Zeitlaufen welches neue Feature aufgenommen wird bzw. optional ist.

Das zerstört natürlich den Upgrade-Druck (wichtige Marketing Instrumente) den wir auf der PC-Plattform vor gelebt bekommen.


Zumindest die Grafik IP Hardwarehersteller brauchen Märkte wo sie ihre Fähigkeiten entfalten können, ansonsten sind Sie nur austauschbarer Zulieferer und die ganze Kohle die in die Forschung geht verpufft. Ein langfristiger Ausweg könnte da das cloud rendering sein, dann ist das Endgerät wieder nicht so wichtig.


Es würde einfach die hohen Gewinne bei einigen IHVs stark schmälern und/oder die aktuellen Preise wäre nicht abrufbar.

[Gast]

Kann Vulkan eigentlich schon mGPU?
Ja unter W10 im WDDM LDA Mode: https://msdn.microsoft.com/en-us/library/windows/hardware/dn894177(v=vs.85).aspx Unter Windows 7 und 8.1, naddanich. http://hexus.net/tech/news/software/103633-vulkan-multi-gpu-support-will-require-windows-10/

[Foobar2001]

Ich glaube die 1% der Enthusiast-Spieler mit SLI werden es ertragen koennen Windows 10 zu brauchen.

[dildo4u]

Star Citizen wird Vulkan nutzen und DX11 droppen.

https://forums.robertsspaceindustries.com/discussion/comment/7581676/#Comment_7581676

[N0Thing]

Sicher die richtige Entscheidung. Aber mal sehen, wie lange dieser Schritt benötigen wird.

[Screemer]

Ob die den renderer dann auch in lumberyard zur Verfügung stellen.

[vinacis_vivids]

Star Citizen wird Vulkan nutzen und DX11 droppen.

https://forums.robertsspaceindustries.com/discussion/comment/7581676/#Comment_7581676

Richtige Entscheidung.

[Foobar2001]

Sicher die richtige Entscheidung. Aber mal sehen, wie lange dieser Schritt benötigen wird.
Von DX11 ordentlich nach DX12 zu migireren ist erheblich mehr Arbeit als DX12 nach Vulkan. Die APIs sind sich extrem aehnlich. Das geht das schnell. Sehe da keine grossen Huerden.

Ob die den renderer dann auch in lumberyard zur Verfügung stellen.
Der Code ist viel zu sehr divergiert.

[N0Thing]

Von DX11 ordentlich nach DX12 zu migireren ist erheblich mehr Arbeit als DX12 nach Vulkan. Die APIs sind sich extrem aehnlich. Das geht das schnell. Sehe da keine grossen Huerden.

Ist eben die Frage, wie weit sie schon sind. Bisher habe ich nur von (Vor)Arbeiten an der job-Verwaltung der "CryEngine" gelesen, die auch für DX11 Vorteile bringen soll. In Bezug auf konkrete Arbeit an DX12 und/oder Vulkan fällt mir nichts ein.

[Unicous]

Mozilla Proposes "Obsidian" Low-Level Graphics API For The Web, Based On Vulkan (http://phoronix.com/scan.php?page=news_item&px=Mozilla-Obsidian-Graphics-API)

Sweet.

[iuno]

:up:
Apple hat ja schon einen aehnlichen Vorschlag fuer eine WebGL Alternative gebracht, wuerde aber von jedem Browserhersteller erstmal erwarten, drei verschiedene backends zu unterstuetzen, weil sie keinen Bock auf Vulkan haben. Mozillas Vorschlag sollte besser ankommen, ich bin mal auf die Reaktionen gespannt.

[Foobar2001]

Auf PC muss ein Browser leider sowieso DX12 als Backend benutzen, weil Vulkan nicht vorinstalliert ist. Browser werden leider auch von Nicht-Gamern benutzt und die installieren praktisch *nie* Treiber.

[aufkrawall]

Warum sollte das ein Hinderungsgrund sein? Auch OpenCL und OpenGL werden über WU-Treiber ausgerollt und mit Win 10 werden die gar ungefragt auf jedem Rechner installiert.

[iuno]

Auf der anderen Seite installieren Leute aber alles, wenn sie irgendwas haben wollen. Auch sowas wie Unity Web Player Plugin und weit weniger "harmlose" Sachen.
Wenn der Vulkan Treiber nicht mitinstalliert wird ueber Windows Update (wofuer ich keinen Grund sehe, oder ist das aktuell so dass MS das aktiv blockiert?) kann der Betreiber der Website einfach einen Hinweis mit Anleitung und Link einblenden. Zumal man das nicht auf jeder Webseite braucht geschweige denn fuer jeden Nutzer.

[d2kx]

Auf PC muss ein Browser leider sowieso DX12 als Backend benutzen, weil Vulkan nicht vorinstalliert ist. Browser werden leider auch von Nicht-Gamern benutzt und die installieren praktisch *nie* Treiber.

Dieses Argument hat Apple bei ihrem "Vorschlag" bereits gebracht, ist aber immernoch Blödsinn. Windows installiert bei Neuinstallationen die jeweils aktuellsten Treiber, die NVIDIA/AMD/Intel für Windows Update freigegeben haben.

AMD sendet ungefähr einmal im Quartal einen neuen Treiber, der dann über WU verbreitet wird, bei NVIDIA/Intel kenne ich die genauen Zyklen nicht, sind aber halbwegs ähnlich. Und die Treiber kommen als Paket mit DX11, DX12, OpenGL und Vulkan-Unterstützung (bei Intel erst in Kürze, da ist der Vulkan-Support noch frisch).

Warum sollte das ein Hinderungsgrund sein? Auch OpenCL und OpenGL werden über WU-Treiber ausgerollt und mit Win 10 werden die gar ungefragt auf jedem Rechner installiert.

So ist es.

[iuno]

Unter Windows 7 und 8.1, naddanich. http://hexus.net/tech/news/software/103633-vulkan-multi-gpu-support-will-require-windows-10/
https://www.khronos.org/blog/vulkan-multi-gpu-support-not-just-for-windows-10

[Foobar2001]

Warum sollte das ein Hinderungsgrund sein? Auch OpenCL und OpenGL werden über WU-Treiber ausgerollt und mit Win 10 werden die gar ungefragt auf jedem Rechner installiert.
Werden sie, aber ohne OpenGL. Die WU-Treiber haben nur OpenGL 1.irgendwas Emulation ueber D3D.

[aufkrawall]

Werden sie, aber ohne OpenGL. Die WU-Treiber haben nur OpenGL 1.irgendwas Emulation ueber D3D.
Wie kommt man denn auf so einen grotesk-abstrusen Unfug? :eek:
Ich habs gerade ausprobiert: Per WU wird der 376.53 verteilt, mit Vulkan, OpenCL und OpenGL 4.5. Und nix "Emulation". :rolleyes:
Du liebe Güte...

[Unicous]

Meint er vllt. den Standard VGA-Treiber?:confused:

[aufkrawall]

Der Kontext war ja, dass er meinte, die Vulkan-Abdeckung auf Windows-Geräten wäre nicht gegeben. Also eher nein. ;)

[Unicous]

Aber schon komisch, dass dieses meiner Meinung nach ziemlich plumpe und seit mehreren Jahren faktisch falsche Argument angebracht wird um jegliche Vulkan-Unterstützung auf breiterer Front zu torpedieren. Und damit meine ich im Speziellen auch diese Apple-Clowns die immer ihr eigenes Bratwurstbratgerät mitbringen müssen anstatt sich mal in die Gemeinschaft zu integrieren.:rolleyes:

[Ganon]

Es kann auch durchaus sein, dass sich das über die Jahre geändert hat, oder mit Windows 10, aber das WU durchaus Treiber ohne OpenGL verteilt hat, hab ich selbst erlebt. Nicht umsonst wurde damals ANGLE entwickelt, weil die Browserhersteller durch Browser-Rückmeldungen gesehen haben, dass ein Großteil der Windows-User kein aktuelles OpenGL installiert haben.

Es war zumindest Windows 7 mit einer AMD Grafikkarte. Direct3D Spiele liefen ohne Probleme, aber nicht ein OpenGL Spiel/Programm. Treiber kam über Windows Update.

[kruemelmonster]

aber das WU durchaus Treiber ohne OpenGL verteilt hat, hab ich selbst erlebt.

Ich ebenfalls, und das ist locker 5 Jahre her -> Nullargument.

[aufkrawall]

Ich glaube eher, dass es bei Angle hauptsächlich um die Güte bzw. Nicht-Güte der OpenGL-Treiber ging und um die Plattform-Portabilität.

Ein ähnliches Prinzip könnte man auch für Vulkan nutzen, Nvidia hatte ja schon eine Lösung für einen erhöhten Abstraktionsgrad vorgestellt.

[Foobar2001]

Okay, wenn sie inzwischen wirklich volle NVIDIA-Treiber verteilen bin ich gluecklich. Was ist mit den Surfaces? Die haben irgendwelche Custom-Treiber, man kann die offiziellen von Intel gar nicht installieren.

Aber schon komisch, dass dieses meiner Meinung nach ziemlich plumpe und seit mehreren Jahren faktisch falsche Argument angebracht wird um jegliche Vulkan-Unterstützung auf breiterer Front zu torpedieren. Und damit meine ich im Speziellen auch diese Apple-Clowns die immer ihr eigenes Bratwurstbratgerät mitbringen müssen anstatt sich mal in die Gemeinschaft zu integrieren.:rolleyes:
Ich torpedier die Vulkan-Unterstuetzung? Oh the irony.

[Unicous]

Nö, ich 'schrub' Und damit meine ich im Speziellen auch diese Apple-Clowns.

Es ist nun mal so, dass dieses Argument nicht nur außerordentlich schwach wäre wenn es denn heutzutage noch zuträfe sondern auch eine Kapitulation an den Status Quo ist.

Und soweit ich das mitbekommen habe, wurden bislang auch keine wirklich starken Argumente hervorgebracht die Vulkan daran hindern würden plattform- bzw. betriebssystemübergreifend genutzt werden zu können oder dem entgegen stehen würden außer eben dem einen Punkt, dass natürlich Apple ihren Status etwas "Besonderes" zu sein verteidigen möchte und als pinnacle of innovation dastehen will (obwohl sie diesen Status ja schon ca. 2010 wieder verloren haben:freak:).

Ich habe jedenfalls das ungute Gefühl, dass jetzt wirklich jeder seine Vorschläge einbringt und man sich am Ende wieder gegenseitig auf die Füße tritt, weil niemand einen Stück zurückweichen will und es am Ende wieder zig "Standards" gibt und man nichts gekonnt hat. Stattdessen hätte man sich lieber an einen Tisch setzen sollen und es gemeinsam ausgearbeitet. Von daher finde ich diesen allgemeinen Aufruf von Khronos auch wenig zielführend.

[Foobar2001]

Oh. Ja. Apple kann an ihrem Metal ersticken.

[DanMan]

Khronos haben ihre GDC 2017 Präsentationen auf YT geladen: https://www.youtube.com/playlist?list=PLYO7XTAX41FPg08uM_bgPE9HLgDAyzDaZ

[d2kx]

Apple hat den High-End-Bereich praktisch aufgegeben, noch mehr als vor einigen Jahren ohnehin schon, und unterstützt nicht einmal modernes OpenGL mehr (sie hängen seit Jahren bei OpenGL 4.1 fest). Man wird vermutlich irgendeinen Kompromiss finden, aber Sympathien haben sie bei mir auch keine mehr wenn es um ihre Meinung zu einer neuen Web API geht.

[Demogod]

ich mein ich find jetzt auch nicht alles megacool was apple tut (trotzdem fanboi) aber vllt gibt es ja tatsächlich irgendwelche security considerations... bin gespannt auf die performance des deus ex mankind divided metal ports..!! (und hätte auch SEHR gerne full vulkan support!!1337)

[StefanV]

Wie kommt man denn auf so einen grotesk-abstrusen Unfug? :eek:
Weil das der Standard vor einiger Zeit bei Windows war.
k/a, wann das geändert wurde und auf welche Betriebssysteme das sonst noch zutrifft...

[Troyan]

Futuremark unterstützt nun Vulkan beim API-Overhead-Test: https://www.techpowerup.com/231764/futuremark-releases-3dmark-v2-3-3663-adds-vulkan-support

[aufkrawall]

Weil das der Standard vor einiger Zeit bei Windows war.
k/a, wann das geändert wurde und auf welche Betriebssysteme das sonst noch zutrifft...
Was soll "vor einiger Zeit" bedeuten? "Damals"?

[dargo]

Futuremark unterstützt nun Vulkan beim API-Overhead-Test: https://www.techpowerup.com/231764/futuremark-releases-3dmark-v2-3-3663-adds-vulkan-support
Ist zwar ganz nett, mir wäre aber lieber mehr Spiele würden damit kommen anstatt mit den Steinzeit APIs. :usad:

[dildo4u]

Futuremark unterstützt nun Vulkan beim API-Overhead-Test: https://www.techpowerup.com/231764/futuremark-releases-3dmark-v2-3-3663-adds-vulkan-support
FX 8320e@4.3Ghz GTX 1070@2Ghz 378.92

http://abload.de/img/oberheada0s3k.png

Schätze mal der FX bremst hier noch ordentlich,kann mal jemand Ryzen testen.

[dargo]

Nicht wirklich. Mein Hassi...
59315

Natürlich spielt hier auch die Graka eine entsprechende Rolle. Schließlich muss diese die Draw Calls auch verarbeiten können.

[HOT]

Ich kapier das Kackprogramm nicht, der DX12-Test schießt bei mir nach dem Durchlauf knallhart das Programm ab und DX11 MT misst sinnlos niedrige Werte... na ob das mal irgendwann vernünftig läuft... Hab die Steam-Version und scheinen einige von betroffen zu sein. Vulkan misst er bei mit auch >17m, der Test läuft wenigstens :D.

[Hübie]

Ist zwar ganz nett, mir wäre aber lieber mehr Spiele würden damit kommen anstatt mit den Steinzeit APIs. :usad:

Für Steinzeit APIs rennt D3D11 auf NV doch verdammt gut und bedeutet weniger Aufwand für Devs. Irgendwo hat beides noch eine Daseinsberechtigung. Das kann sich ändern wenn entsprechend breitflächiges know-how und ausführliche Dokumentationen vorhanden sind. Du schaust immer nur aus deinem Fenster in die Welt. ;) Ich wünsche mir zwar auch mehr Vulkan-Titel, jedoch kann es mir aus meiner persönlichen Situation egal sein. Läuft alles einwandfrei.

[HOT]

DX11 SingleThreaded bekomm ich mit meiner RX480 auf 6600k >2Mio Drawcalls, ich glaub der Wert ist sogar besser als bei NV. Seit der 16.60 scheint das Overhead-Problem endgültig Geschichte zu sein. DX11 MT spuckt bei mir Müll aus, warum auch immer. Der bricht irgendwie den Test vorzeitig ab.

[dargo]

DX11 SingleThreaded bekomm ich mit meiner RX480 auf 6600k >2Mio Drawcalls, ich glaub der Wert ist sogar besser als bei NV.
Das ist merkwürdig. Ich bekomme mit Hassi i7 @3,7Ghz und R9 390 nur 1,1xMio raus.

[HOT]

Dann bricht er bei dir auch vorzeitig ab. Diese Quatschwerte kenn ich.
Hab nen
- 6600k mit RX480 > 2Mio Drawcalls
- 5650c mit 290X > 1,7Mio Drawcalls
aber nur singlethreaded, multithreaded wird vorzeitig beendet und spuckt Quatschwerte aus (so 1,2 - 1,4Mio unabhängig vom Prozessor). Ab und zu bricht der auch SingleThreaded vorzeitig ab bei mir. DX12 Drawcalls kackt gänzlich ab bei mir, wenn ich das blöde Infotool nicht ausmache, dann muss ich neu starten, um das wegzubekommen (deshalb hab ich den Mist immer aus). Das verhält sich aber auch komisch, weil das arschlangsam mit MondFPS startet, das stimmt sowieso was nicht.
Ich würd sagen, mit Radeon-Treibern kann man diesesn ganzen Test getrost in die nächste Mülltonne kegeln.

[dildo4u]

DX11 SingleThreaded bekomm ich mit meiner RX480 auf 6600k >2Mio Drawcalls, ich glaub der Wert ist sogar besser als bei NV. Seit der 16.60 scheint das Overhead-Problem endgültig Geschichte zu sein. DX11 MT spuckt bei mir Müll aus, warum auch immer. Der bricht irgendwie den Test vorzeitig ab.
Das Problem war nie Single Thread DX11 Leistung sondern das DX11MT nicht gegenüber ST zulegt,das hat AMD GPU's z.b bei Projekt Cars gebremst.

[dargo]

@HOT

Naja... mit Abbrüchen oder sowas hatte ich bisher noch nie Probleme. Das einzige was mir bisher auffiel. Je nach Run spuckt er etwas unterschiedliche Werte aus. So hatte ich mal bei einem Run unter DX12 knapp 16Mio Draw Calls. Beim anderen Run knapp 17Mio. Was ich aber merkwürdig finde sind die niedrigen Draw Calls bei DX11. Ich habe wirklich nur 1,1xMio. Hatte mit dem gleichen System aber auch schon bei älteren Crimsons 1,4xMio. Fände es schon etwas seltsam wenn mit neueren Treibern der Wert wieder geringer wäre.

[aufkrawall]

Womit man an Performancerückschlüsse auf Spiele von diesem Test mal ein dickes Fragezeichen machen kann.

[dildo4u]

http://abload.de/img/indexd8l4y.png

http://www.guru3d.com/news-story/quick-test-futuremark-3dmark-v2-3-3663-vulkan-api-overhead-benchmarks.html

[Hübie]

Jop. Das hat einfach nur theoretische Natur und bedeutet praktisch noch nichts.
Frage: Mehr Polys = mehr Draw Calls. Gilt dann auch dass mehr Draw calls auf mehr Polys hindeuten oder kann es auch andere Komponenten wie z.B. Texturen oder -formate betreffen (z.B. Bump- und Displacement-Maps)? Ist wahrscheinlich eine blöde Frage. :D So richtig verstanden habe ich bis heute nicht was ein Draw Call alles 'beinhaltet'.

[dildo4u]

Es hat schon Relevanz Fury kackt aktuell z.b in Mass Effect 4 ab vermutlich wegen der Drawcall's.Der Test zeigt wie viel besser die 480 ist.

[dargo]

Wenn da dieses "vermutlich" nicht wäre.

[fondness]

Da limitiert wohl bei den älteren Radeons schlicht der Dreiecksdurchsatz. Mit dem APi Overhead hat das jedenfalls nichts zu tun, denn der wird sich zwischen einer Fury und einer RX480 sicherlich wenig bis gar nicht unterscheiden.

[dildo4u]

Da limitiert wohl bei den älteren Radeons schlicht der Dreiecksdurchsatz. Mit dem APi Overhead hat das jedenfalls nichts zu tun, denn der wird sich zwischen einer Fury und einer RX480 sicherlich wenig bis gar nicht unterscheiden.
Der Test testet Dreiecksdurchsatz,warum sollte gerade Fury und die 390 ein höheren Overhead haben wenn sie die selben Treiber wie die 480 nutzen?

[aufkrawall]

Ich hab bei dem Vulkan/DX12-Test 80% GPU-Last in 720p mit der 1070 OC, da wird schlicht und ergreifend die allgemeine GPU-Geschwindigkeit limitieren. Die Fury X ist in 720p ja sowieso kaum auslastbar.
Immer diese verrückten Theorien hier. :freak:

[Gastroenterologe]

Ich hatte mich übrigens in dem Zusammenhang über den DX11 Test Single/Multi auf RX 480er gewundert. Dachte Polaris hat mächtig aufgeholt bzw. zu NV aufgeschlossen. Hier hat jemand jeweils über 2k als Ergebnis.
http://www.3dmark.com/compare/aot/198443/aot/182034

Guru3D misst wiederum andere Ergebnisse. Was ist nun korrekt?

[Locuza]

Ein Kommentar von Graham Sellers bezüglich AMDs Vulkan-Treiber, der scheinbar immer noch irgendwann (TBA) open sourced werden soll:
https://youtu.be/9QemaBKYmeU?t=1h49m6s

Bei der Desktop Deep Dive Session hat Dan Baker von Oxide eine gute Übersicht über die Unterschiede zwischen Vulkan und DX12 präsentiert:
https://youtu.be/RkXa4RiERu8?t=40m52s

DX12 und Vulkan sollen sich so ähnlich sein, dass es so einfach wie nie zuvor ausfällt, zwei unterschiedliche APIs in einem Rendering-System umzusetzen und die Komplexität von DX11 zu DX12 oder DX11 zu Vulkan soll praktisch gleich ausfallen.
Da nun auch HLSL zu SPIR-V praktisch produktionsreif ist, kann man endlich die selbe Shader-Sprache für beide APIs verwenden.

Die größte strukturelle Codeänderung die bei Vulkan nötig gewesen ist, kam vom Renderpass-Konzept.
Ansonsten gibt es gewisse Unterschiede, wo teilweise DX12 besser/eleganter spezifiziert wurde, teilweise Vulkan, nichts davon scheint wirklich ins Gewicht zu fallen.
- Vulkan unterscheidet zwischen Buffern und Texturen, DX12 ist es egal.
- Descriptor sets sind unter Vulkan praktisch wirkliche Objekte, während bei DX12 das einfach ein großer Pool mit einer Zuweisung darstellt.
- Beim Descriptor Layout gibt es die Regel, dass es mit den PSOs exakt übereinstimmen muss, ich verstehe hier nur, dass es bei DX12 mehr Freiraum besteht und etwas effizienter vom Platzverbrauch ausfällt, aber wirklich interessieren tut das nicht.
- Das Pipeline-Layout ist ähnlich gegenüber dem Root-Layout unter DX12, allerdings gibt es weniger strikte Regeln, weshalb man generell einfach aufpassen sollte nicht zuviele dynamishe Descritpors zu verwenden.
- Texture Uploading fällt ein wenig anders aus, da Vulkan gar kein Layout dafür definiert, dass muss der Entwickler selber erstellen.
- Resource Barriers fallen unter Vulkan expliziter aus, haben aber den Vorteil das die Entwickler den Layout-Mode ändern können, solange der Inhalt (oder Kontext?) nicht interessiert, bei DX12 muss man das nachverfolgen, was sehr nervig ausfallen soll.

Noch ein wenig zu SPIRV, der Bytecode fällt ~10-20 mal größer gegenüber D3D aus, also besteht bei jedem Entwickler das grundsätzliche Interesse das zu komprimieren.
Nach der Kompression mit SMOLV und LZ4 ist der Bytecode nur noch doppelt so groß.

[Hübie]

Danke für die Zusammenfassung. :up: Das sagte foobar2001 ja auch schon mehrere Male. Also kann man durch den Einsatz von Vulkan ebenfalls sehr gute Performance erreichen (nicht mehr diese Lücke wie damals OGL<->D3D) und bietet halt den Vorteil mehr Plattformen zu erreichen. Wobei das Prozentual der Linux-Gamer geringer ausfallen dürfte als z.B. SLi-User.

[fondness]

Der Test testet Dreiecksdurchsatz,warum sollte gerade Fury und die 390 ein höheren Overhead haben wenn sie die selben Treiber wie die 480 nutzen?

Ja genau, und eine RX480 schafft wesentlich mehr Dreiecke als eine Fury, das ist bekannt. Mit dem APi Overhead hat das allerdings nichts zu tun.

[HOT]

@HOT

Naja... mit Abbrüchen oder sowas hatte ich bisher noch nie Probleme. Das einzige was mir bisher auffiel. Je nach Run spuckt er etwas unterschiedliche Werte aus. So hatte ich mal bei einem Run unter DX12 knapp 16Mio Draw Calls. Beim anderen Run knapp 17Mio. Was ich aber merkwürdig finde sind die niedrigen Draw Calls bei DX11. Ich habe wirklich nur 1,1xMio. Hatte mit dem gleichen System aber auch schon bei älteren Crimsons 1,4xMio. Fände es schon etwas seltsam wenn mit neueren Treibern der Wert wieder geringer wäre.

Der Benchmark bricht ja nicht wirklich ab, er beendet sich vielmehr zu früh.

http://abload.de/img/indexd8l4y.png

http://www.guru3d.com/news-story/quick-test-futuremark-3dmark-v2-3-3663-vulkan-api-overhead-benchmarks.html

Die AMD-Werte sind einfach nur BS, die kannste in die Tonne treten. Wie gesagt liefern ST-Durchläufe oft auch deutlich höhere Werte.

Es hat schon Relevanz Fury kackt aktuell z.b in Mass Effect 4 ab vermutlich wegen der Drawcall's.Der Test zeigt wie viel besser die 480 ist.

Die kacken wegen der Tesselation und dem Dreiecksdurchsatz ab, da haben die Drawcalls genau 0 mit zu tun. AMD hat hier in Wirklichkeit einfach keine Nachteile mehr. Der Benchmark dazu in der 3DMark ist einfach nur Schrott, das ist alles.

Womit man an Performancerückschlüsse auf Spiele von diesem Test mal ein dickes Fragezeichen machen kann.

Exakt.

[dildo4u]

Interessant mit einem 7700k + GTX 1070 ist Vulkan deutlich schneller als DX12.


https://www.forum-3dcenter.org/vbulletin/showpost.php?p=11329477&postcount=645

[IchoTolot]

FX 8320e@4.3Ghz GTX 1070@2Ghz 378.92

http://abload.de/img/oberheada0s3k.png

Schätze mal der FX bremst hier noch ordentlich,kann mal jemand Ryzen testen.


Der AMD bremst sehr deutlich. Hier mal mein System, siehe Signatur. 1070 läuft Stock, also max 18xx Boost. CPu auch Stock.

1080p

https://lh3.googleusercontent.com/tC_DwZbCPajeNZ3JHEDMvHakmmO4m7nTBu_aVI_4chpFuH733y75K3vf5NFY1ZWTEznb_IQlQgVJpjac _eeLACkmt7zpO70QdtEimjXPesXPMxe3nT4oCItiwO_eys06Rw4tQLQN27zkPDzHNf1N_dThowfRifgS AO4LzLA_2IjChcMz-P_Jv8mytqsKhTQg8e8YPQv_8BugkeUA9q2BN4IerjvJ3VNikhX0OUJs5cRNV5qAGR-NgE-2Ag6DRHkelB8_O4I8yE-Q0yORBWC4tLf8niL9zDnaf_cn_XGhUk7xsZi9N8fghc8k0KaXuPZOUOvvYcxObec4QVKLrf1LOuT7G16 WDjZl0tlnfTHXip23bpwQcd-XQw1M2kZDlp32-ewWdMbekp_Eodnm6bSi4MC_mxSd2b4s-6AuNquRNsoWkVCqLzjWq_gRTRR-UBPV1WD6-FdSakhhbEMgepsF7ZVqfdpn5ZYHknaUFIZDVgrNHSBHlsm-akZaeiNcXDBCIyDJ95Ibw-iuomyD19oNqzv_peOtJwTUgZVXAk4oPbAgXbrLYpQrp3dHcq-fhNhKL1EZu_uaDUVc6MqA3kvL1Tz4ztlJiTGsZNYWsl9vp8jejTvdcMjIWA=w1636-h990-no

4K:

https://lh3.googleusercontent.com/b94IgDwi2ia11iRSS0Sb2NLDOU2dKOnvHtXb9dO9qOYsyJGkVQpA7txymg1Y6ONLXpln5rhZD2b8hJ1r nD9lgt-wdHEp9VWNsUwWQ7nNQMFOT7ym4gZ3d1XhXOKr-fT65P34M-7BWd4jK5BS0JkQQMAtVLErdlXrVY8hUNmyAp5PPkacdycnKzMl2fuMCmzy4awzYbhnYnTT8YSbdpxAm7 Y44WFfwS2X_mrutTAdS9olS3xM7eNeVhyIvXUURtfCzr_eihzzIqoXc8UwfJGF7Ugp7cpNNQ_xHhqOXx NJdWr5KtK6ZP8A656uYxKNVHslQ7h237Zaz4WeTG78BFdKoBK_A5gNg9RuSmGPUFPPobLL1mX3P3qFpB 6ovAAABqYdX9wcDAUIcyzhMkG17qBh0jHoyXY-QGX2Qgzhn_5J2VngWcYKVC18qPtcUogwQyogrfES01giS0o5KnRW-X1VEL-EKdqvTVI8u4e8tJmZ4AmJl9cmGu2v53nukv0qwyc4mJlSxrHMlQ1iWdWmTXbLuXOxIX6fwtpwKlWvDS6 JEuVbc782SRsw6sFohYX6J1fkU9Jycj-ilfx6GHURx7Fqu4iUp2px6Od2hTLN1nCpLkNh8ttCCIAVow=w1636-h990-no

Der Benchmark bricht ja nicht wirklich ab, er beendet sich vielmehr zu früh.


Er beendet sich, wenn man unter 30 fps fällt. Steht irgendwo.

[Locuza]

AMD hat das Anvil Framework für Vulkan veröffentlicht:
http://gpuopen.com/gaming-product/anvil-vulkan-framework/

Ziele und Features:
Anvil is a cross-platform, open-source, MIT-licensed wrapper library for Vulkan™, developed by AMD engineers. It has been designed with the goal of reducing the amount of time that developers need to spend in order to write a working Vulkan application from scratch. As such, not only does the library provide the usual C++ wrappers one would expect, but also includes extra features, as described below:

- A memory allocator which allocates as little memory as necessary for the specified list of memory regions, miptails, objects or subresources from one or more memory heaps, depending on platform’s capabilities.
- Automatic object lifetime management, thanks to auto pointers being used across the library.
- Descriptor sets and descriptor set layouts are automatically generated from user-created descriptor set groups.
- Helper routines for FP16<->FP32 conversion.
- Integrated validation support. Validation can be enabled by changing a single argument value at Vulkan instance creation time.
- Integration with glslang for run-time GLSL -> SPIR-V conversion. Assembly of the result blob can also be retrieved for further analysis.
- Object tracker which can be used to detect wrapper object leaks.
- Page tracker, useful for the purpose of tracking memory bindings, if sparse residency is used for buffers or images.
- Windowing system integration – current support includes XCB and Windows platforms.

[=Floi=]

was limitiert denn eine moderne engine? bzw. wie stark limitieren überhaupt die drawcalls?

[IchoTolot]

Die Drawcall sind doch meinem Verständnis nach DIE Methode zu schauen was ein Prozessor leisten kann. Wie schnell kann er der Grafikkarte Daten liefern? Je mehr desto besser, desto weniger limitiert die CPU.

[BlacKi]

6 core 5820k@4,4 2666cl13 + 1070@2ghz, mem +335
https://abload.de/img/unbenanntwmumm.png

4 core 5820k@4,4 2666cl13 + 1070@2ghz, mem +335
https://abload.de/img/unbenanntfkswd.png

[SaschaW]

Die Drawcall sind doch meinem Verständnis nach DIE Methode zu schauen was ein Prozessor leisten kann. Wie schnell kann er der Grafikkarte Daten liefern? Je mehr desto besser, desto weniger limitiert die CPU.

Das war früher mal so. Unter Vulkan packt man das in statische CB (die man bei Bedarf auch aus mehreren Threads raus befüllen kann), und dank indirect draws (gibts auch für GL) kann man das sogar z.B. mit compute shadern direkt auf der GPU machen ohne dass die CPU am Erzeugen beteiligt ist.

[BlacKi]

http://abload.de/img/indexd8l4y.png

http://www.guru3d.com/news-story/quick-test-futuremark-3dmark-v2-3-3663-vulkan-api-overhead-benchmarks.html
kann mir einer helfen das richtig einzuordnen? bei mir hat auflösung und gpu/vram takt keine großen auswirkungen auf das ergebniss. welcher faktor abseits der cpu, rein gpu technischer natur hat denn nun den größten einfluss auf das ergebniss?

[Foobar2001]

Nur die CPU.

was limitiert denn eine moderne engine? bzw. wie stark limitieren überhaupt die drawcalls?
Kommt drauf an. Mit DX11 ist es jedenfalls erheblich, vor allem weil es Single-Threaded ist.

Das war früher mal so. Unter Vulkan packt man das in statische CB (die man bei Bedarf auch aus mehreren Threads raus befüllen kann), und dank indirect draws (gibts auch für GL) kann man das sogar z.B. mit compute shadern direkt auf der GPU machen ohne dass die CPU am Erzeugen beteiligt ist.
Sorry, aber noe. Tut man nicht. Man fuellt immer noch jeden Frame die Command-Buffer. Alles andere ist wegen Culling und Sorting (Tiefe, State, etc.) einfach nicht praktikabel abseits von kleineren Demos.

[HOT]

Irgendwie fällt der AMD -Treiber zu früh auf <30FPS zurück und der Test wird beendet bei MT, die Werte müssten eigentlich gleich sein.

Hier das Ergebnis mit MSI RX480 @ stock und 6600k @ stock:

[Unicous]

Ich schätze diese Vorträge von der GDC waren noch nicht verfügbar, oder?


D3D12 & Vulkan: Lessons learned (http://32ipi028l5q82yhj72224m8j.wpengine.netdna-cdn.com/wp-content/uploads/2017/03/GDC2017-D3D12-And-Vulkan-Lessons-Learned.pdf) von Matthäus G. Chajdas

und

D3D12 & Vulkan Done Right (http://32ipi028l5q82yhj72224m8j.wpengine.netdna-cdn.com/wp-content/uploads/2017/03/GDC2017-D3D12-And-Vulkan-Done-Right.pdf) von Gareth Thomas

[4Fighting]

Vulkan kann anscheinend auch negativ wirken ...


http://www.gamestar.de/software/google-android/android_70_nougat,760,3301851.html

Interessant: Das M8 mit SD801 bekommt nun doch offiziell Nougat (über T-Mobile). Haben die sich ihren eigenen Grafiktreiber gebastelt?:freak:

https://support.t-mobile.com/docs/DOC-18828

[EOVI]

Feral Interactive has pushed a Vulkan renderer for their recent Mad Max Linux port into public beta.

https://www.facebook.com/feralinteractive/photos/a.121305254560653.15582.118120444879134/1478462805511551/?type=1&theater

[d2kx]

Feral Interactive has pushed a Vulkan renderer for their recent Mad Max Linux port into public beta.

https://www.facebook.com/feralinteractive/photos/a.121305254560653.15582.118120444879134/1478462805511551/?type=1&theater

Und es läuft 2-3x schneller vs OpenGL auf einer NVIDIA GTX 980 Ti:

https://www.gamingonlinux.com/articles/mad-max-meets-vulkan-in-a-new-fully-public-beta-for-linux-benchmarks-and-opengl-vs-vulkan-comparisons.9345

Der Vulkan-Renderer und neue Benchmark-Mode sind im Moment nur als Beta für Linux verfügbar, nicht für Windows. Traditionell sind die OpenGL-Portierungen immer ein wenig langsamer als die DirectX 11-Originale, aber wenn ein neuer Vulkan-Renderer auf einmal davonrennt, dann sind das auch für reine Windows-Studios sehr interessante Werte.

[Kartenlehrling]

Klingt wirklich toll sogar Intel wird unterstützt.

We’re crazy excited to announce that Mad Max is getting revved to utilise Vulkan,
the Khronos Group’s next-generation graphics API.
To join the public Beta:
In your Steam library, right click on Mad Max.

From the drop-down menu, select Properties. The Properties window will appear.
Select the Betas tab.
Enter "livelongandprosper" into the text box, then select Check Code. A message will appear to confirm that you now have access to vulkan_beta.

From the drop-down menu above the text box, select vulkan_beta.

Close the Properties window.

If Mad Max is already installed, an update will begin downloading automatically. If Mad Max is not installed, highlight Mad Max in your Steam library, then select Install and follow the instructions.

The following driver versions are required to participate in the Beta:

NVIDIA
Requires NVIDIA driver version 375.26 or later.

AMDGPU-PRO
Requires 16.50 or 16.60. 16.60 has a known regression which causes the game to appear darker than it should.
A driver fix for this is in progress. We’re aware of some rare full system hangs when using GPU-PRO.

MESA (RADV/ANV)
Requires latest Mesa 17.1-dev (as of this post) compiled with Vulkan support.
On Ubuntu this can be installed using the Padoka ppa found at https://launchpad.net/~paulo-miguel-di…/+archive/ubuntu/mesa.
INTEL ANV requires Broadwell or Skylake, but Haswell is currently unsupported.

Please make sure Steam is up to date (built March 22 2017 or later). This Beta does not currently support SteamOS.
To pass us your feedback, emailvulkanfeedback@feralinteractive.com with a support report generated from the options window. Please provide as much detail as possible.

[SaschaW]

Klingt wirklich toll sogar Intel wird unterstützt.

Intel ANV unter Linux ist inzwischen richtig gut. Hab ja quasi die komplette Entwicklung miterlebt, und als ich vor kurzem neue Binaries für meine Beispiel erzeugt und getestet hab war ich total erstaunt dass selbst auf Haswell alle Beispiele (bis auf Sparse, aber das geht aktuell eh nur auf neueren NVs) laufen (und die Performance auch brauchbar ist). Da hab die Jungs echt nen sehr guten Job gemacht :)

[Loeschzwerg]

Wäre schön wenn die Fortschritte auch auf den Windows Treiber abfärben würden :( Doom läuft unter Vulkan immer noch schlechter als OGL.

[Hübie]

Hö? Auf welcher Arch? Auf Maxwell 2.0 ist Vulkan das Mittel der Wahl. Einige wenige Stellen haben unerklärlich schlechte Performance, aber ansonsten... Mad Max probiere ich gleich mal. Danke Kartenlehrling. :up:

[Loeschzwerg]

Intel IGP :)

[dargo]

Und es läuft 2-3x schneller vs OpenGL auf einer NVIDIA GTX 980 Ti:

https://www.gamingonlinux.com/articles/mad-max-meets-vulkan-in-a-new-fully-public-beta-for-linux-benchmarks-and-opengl-vs-vulkan-comparisons.9345

Der Vulkan-Renderer und neue Benchmark-Mode sind im Moment nur als Beta für Linux verfügbar, nicht für Windows. Traditionell sind die OpenGL-Portierungen immer ein wenig langsamer als die DirectX 11-Originale, aber wenn ein neuer Vulkan-Renderer auf einmal davonrennt, dann sind das auch für reine Windows-Studios sehr interessante Werte.
Alter Schwede. X-D
https://www.youtube.com/watch?v=eFevTC0RTEo

Warum dauert das immer so lange mit den Spielen? :usad:

[iuno]

Klingt wirklich toll sogar Intel wird unterstützt.
Nice, soll sogar mit radv laufen.

Traditionell sind die OpenGL-Portierungen immer ein wenig langsamer als die DirectX 11-Originale, aber wenn ein neuer Vulkan-Renderer auf einmal davonrennt, dann sind das auch für reine Windows-Studios sehr interessante Werte.

Habe keinen Vergleich zw. OpenGL und Windows gefunden, aber Feral hat mit der Windows Version ja nichts am Hut. Es muesste denke ich schon deutlich schneller sein als d3d11, bevor die anderen auch mal auf den Trichter kommen. Und nicht nur bei einem einzigen Spiel.
Aber natuerlich sehr gut gemacht von Feral bei dem ersten Titel gleich derartige Zuwaechse vorweisen zu koennen :up: Ich hoffe immer noch, dass die noch ROTTR mit Vulkan bringen.

[DanMan]

Habe keinen Vergleich zw. OpenGL und Windows gefunden,
BKZRVbMga4A

Wenn man dann dort noch die Verbesserung durch Vulkan (https://www.gamingonlinux.com/articles/mad-max-meets-vulkan-in-a-new-fully-public-beta-for-linux-benchmarks-and-opengl-vs-vulkan-comparisons.9345) oben drauflegt...

[aufkrawall]

...dürfte ein unrealistisches Ergebnis herauskommen. ;)
Windows lief da offenbar teilweise mit fps-Limit bei 120. Will allerdings nicht ausschließen, dass es womöglich ein CPU-Limit geben könnte und da ein gescheiter Vulkan-Port Vorteile hätte.
Problem bei den meisten OGL-Ports auf Linux ist jedenfalls die CPU, dabei ist ein Kern meist am Anschlag und die fps sind eher bescheiden. Wenn Feral das mit Vulkan besser hinbekommt, wär das schon ziemlich gut.

[dargo]

Windows lief da offenbar teilweise mit fps-Limit bei 120.
:confused:

Ich sehe im Video bei normalen Settings bis zu 229fps.

[aufkrawall]

"Teilweise":
https://youtu.be/BKZRVbMga4A?t=100

[dargo]

*g*

Da spinnte wohl Vsync Off. :D Aber gut... die ~20 Sekunden dürften jetzt am Gesamtergebnis auch nicht so gravierend viel ändern.

[Loeschzwerg]

Weil wir gerade bei Vulkan sind... schon bekannt?
https://steamdb.info/app/564310/

[aufkrawall]

*g*

Da spinnte wohl Vsync Off. :D Aber gut... die ~20 Sekunden dürften jetzt am Gesamtergebnis auch nicht so gravierend viel ändern.
Trotzdem sollte man mal besser den Hypetrain im Depot lassen, bis Apples vs. Apples getestet wurden: Also Linux Vulkan vs. Windows DX11 mit identischer Testszene.
Dass ein Vulkan-Port (wenn man es denn noch Port nennen kann) eines Portier-Studios im GPU-Limit auf Nvidia magisch schneller laufen soll als der DX11-Renderer vom ursprünglichen Entwickler-Team, möchte ich mal bezweifeln.

@Loeschzwerg: Ist schon bekannt, DX11 läuft im GPU-Limit immer noch besser. Der Vulkan-Renderer hat auch noch ein Problem mit dem Shader-Compiler, was zu Frametime-Spikes führt.
Im CPU-Limit lief hier Vulkan aber immerhin schon schneller als DX11.

[Loeschzwerg]

Ok, schade :( Aber ist auch noch Beta.

[aufkrawall]

Es war hier aber noch nicht gepostet, falls es dich tröstet. :biggrin:

[Loeschzwerg]

Ich installiere trotzdem mal irgendeinen Teil und schaue wie bescheiden die Leistung mit Intel IGP ist ^^

[aufkrawall]

Problem bei den meisten OGL-Ports auf Linux ist jedenfalls die CPU, dabei ist ein Kern meist am Anschlag und die fps sind eher bescheiden. Wenn Feral das mit Vulkan besser hinbekommt, wär das schon ziemlich gut.

Dass ein Vulkan-Port (wenn man es denn noch Port nennen kann) eines Portier-Studios im GPU-Limit auf Nvidia magisch schneller laufen soll als der DX11-Renderer vom ursprünglichen Entwickler-Team, möchte ich mal bezweifeln.

Oha, die Bestätigung vom Entwickler selbst ^^ :
For the most part Mad Max on GL is CPU bound - ie. limited by the single threaded CPU performance on the GL thread. We already use a separate thread for GL dispatch but this doesn’t mean GL itself is multithreaded.

Vulkan helps us massively here, as you can see in the graphs, and is almost always GPU bound now. If you've got the time to spec this out you could look into average GPU utilisation (using nvidia-smi) with GL and with Vulkan, and you'll see the difference.

To be clear the benchmark areas are some of the absolute *worst* cases for the CPU, designed that way so we could target the issue directly. That obviously produces some skewed results towards the best case for Vulkan, but I'd hope the jump in performance across the board proves it's not just a one off.

Other games might not get as large a boost, the exact benefits very much depend on if the game is CPU or GPU bound and why.
https://www.phoronix.com/forums/forum/phoronix/latest-phoronix-articles/942104-feral-interactive-vulkan-izes-mad-max/page4

[Hübie]

Also mit 2160p merke ich keinen Unterschied (stable 60 synced fps bei 85-90% GPU utilization, 5,1 GB VRAM, also besser als mit D3D11). Also belasse ich es bei Vulkan. :smile: Einfach weil es die neuere API ist und man so etwas gut heißen sollte. Mir war gar nicht klar was für ein geiles Spiel das ist. Sobald ich DA:I durch habe ist das auf meiner Liste an Alien:Isolation vorbei gezischt. :D
Das mit Serious Sam hab ich nicht ganz gecheckt. Was ist dieses Fusion? :confused:

[Demogod]

Serious Sam Fusion is a central hub for existing and upcoming Serious Sam games developed by Croteam. Cool new features, engine upgrades, patches and updates will be released to existing ownerers for FREE!



Games available in Serious Sam Fusion 2017
(http://www.croteam.com/serious-sam-fusion-2017-beta-live/)
Serious Sam HD: The First Encounter – now available!
Serious Sam HD: The Second Encounter (coming soon)
Serious Sam 3: BFE (coming soon)
VR versions of all games will be a part of Serious Sam Fusion 2017, too!

[Hübie]

Ah, also werden alle Level in die neue Engine importiert und zusammengefasst. :D Das Spiel spricht mich nicht so an um da noch mal soviel auszugeben. Hab glaub ich alle Teile schon gekauft.

[blaidd]

Btw. Mad Max hat ein Vulkan-Update bekommen. (https://www.gamingonlinux.com/articles/mad-max-meets-vulkan-in-a-new-fully-public-beta-for-linux-benchmarks-and-opengl-vs-vulkan-comparisons.9345) Von Feral. Also den Typen, die quasi alle Windows-Spiele für Linux portieren...

EDIT: Hoppla. ;)

[DanMan]

Btw. Mad Max hat ein Vulkan-Update bekommen. (https://www.gamingonlinux.com/articles/mad-max-meets-vulkan-in-a-new-fully-public-beta-for-linux-benchmarks-and-opengl-vs-vulkan-comparisons.9345) Von Feral. Also den Typen, die quasi alle Windows-Spiele für Linux portieren...
Lesen (https://www.forum-3dcenter.org/vbulletin/showthread.php?p=11335538#post11335538) bildet.

[aufkrawall]

Phoronix hat es jetzt auch auf Nvidia getestet, Vulkan auch in 4k immer (teils extrem) schneller als OpenGL:
http://www.phoronix.com/scan.php?page=article&item=nvidia-vlk-madmax&num=5
Scheint also offenbar gegenüber OpenGL auch im GPU-Limit noch zuzulegen.

[SaschaW]

Phoronix hat es jetzt auch auf Nvidia getestet, Vulkan auch in 4k immer (teils extrem) schneller als OpenGL:
http://www.phoronix.com/scan.php?page=article&item=nvidia-vlk-madmax&num=5
Scheint also offenbar gegenüber OpenGL auch im GPU-Limit noch zuzulegen.

Bzgl. des GPU-Limits gehe ich davon aus dass die Jungs von Feral ihre Hausaufgaben gemacht haben und die Synchronisationsobjekte (v.a. Barrieren) perfekt abgestimmt sind. Darüber hatte man in OpenGL kaum Kontrolle, also musste der Treiber raten und hat dann i.d.R. zu generell synchronisiert. Zusammen mit einem viel schlankeren Treiber (gab mal nen Artikel von afair NV dass die allein für das glClear 2~3k LOC brauchten wegen der riesen Statemachine von GL) bringt VK auch dann was wenn man im GPU-Limit ist.

Was ich bisher so lese ein sehr guter Port. Wenn man bedenkt dass man für den Renderer den selben Code auch auf Windows benutzen kann bin ich mal gespannt ob das nicht auf bei den letzten DX12-Verfechtern zumindest zu Wechsel-Gedanken führt (mal ganz abgesehen von Ports nach Android z.B. Switch).

[dargo]

Kommt eigentlich der Vulkan Renderer für Mad Max noch für die Windows Version? Ich würde mir glatt nur deswegen das Game kaufen, kostet ja mittlerweile nichts. :tongue:
https://www.instant-gaming.com/en/835-buy-key-steam-mad-max/?igr=289098&utm_source=keyforsteam.de&utm_medium=referral&utm_campaign=keyforsteam&r_url=http%3A%2F%2Fwww.keyforsteam.de%2Foutgoinglink%2Fkeyforsteam%2F132326624%3 Fmerchant%3D13

[Troyan]

Die Ergebnisse sehen bei AMD fast konträr zu nVidia aus: http://www.phoronix.com/scan.php?page=article&item=radv-mad-max&num=4

Zeigt eindrucksvoll, wie wenig Aussagekraft man einzelnen Implementierungen geben darf. Keine Anpassung an die Architektur und man steht viel schlechter dar.

[iuno]

@dargo: Wie schon gesagt: Feral macht nicht die Windows Version. Du kannst dich aber gerne beim Publisher oder dem Entwickler fuer Win melden, nachfragen und uns mitteilen was die Antwort war ;p

Wuerde jetzt schon gerne einen Direktvergleich Win vs. Vulkan sehen und dem Publisher unter die Nase schmieren ;p


@Troyan: du weisst aber schon, dass da nur die freien Treiber getestet wurden?
radv ist weder feature complete/Vulkan konform noch schnell, wird ausserhalb von AMD entwickelt und nicht offiziell unterstuetzt.

[dargo]

Wie schon gesagt; Feral macht nicht die Windows Version.
Ach Mist, stimmt auch wieder.

[aufkrawall]

@Troyan: du weisst aber schon, dass da nur die freien Treiber getestet wurden?

Offenkundig weiß er das nicht, leider äußert er sich trotzdem. :redface:

[Gast]

Kommt eigentlich der Vulkan Renderer für Mad Max noch für die Windows Version?Nö, Windows tangiert Feral nicht die Bohne. :up:

[Gast]

AMD tut gut daran wenigstens einen anständigen Vulkan Treiber zu haben, denn bisher haben die Radeons bei jeden Vulkan Titel unter Linux das nachsehen und nVidia zieht davon.
Mit Abstand!

[aufkrawall]

AMD tut gut daran wenigstens einen anständigen Vulkan Treiber zu haben, denn bisher haben die Radeons bei jeden Vulkan Titel unter Linux das nachsehen und nVidia zieht davon.
Mit Abstand!
Bitte richtig informieren, der AMD Vulkan-Treiber aus amdgpu-pro sollte nicht langsamer sein als der von Windows.

[Gast]

Bitte richtig informieren, der AMD Vulkan-Treiber aus amdgpu-pro sollte nicht langsamer sein als der von Windows.
Sollte villeicht so sein, ist aber nicht so.

Ich denke Vulkan ist die Radeon Königsdisziplin, wie kommt es dann das die Geforce unter Linux schneller sind? Der RADV Vulkan Treiber ist oftmals sogar langsamer als OpenGL, bei amdgpu-pro schaut es nicht anders aus.
Du sagst ja selber, ist der gleiche Vulkan Treiber.

Und das sich die GTX1060 vor der R9 Fury platziert ist normal?

http://fs5.directupload.net/images/170331/cwaee9bp.png (http://www.directupload.net)

http://fs5.directupload.net/images/170331/gbefss6o.png (http://www.directupload.net)

http://www.phoronix.com/scan.php?page=article&item=nvidia-vlk-madmax&num=1
http://www.phoronix.com/scan.php?page=article&item=radv-mad-max&num=1

[Ganon]

Bitte richtig informieren, der AMD Vulkan-Treiber aus amdgpu-pro sollte nicht langsamer sein als der von Windows.

Sollte er auch nicht, denn es ist effektiv der gleiche Treiber, nur für Linux kompiliert. Da rennt der gleiche Code wie unter Windows.

Es muss nur noch der (momentan noch von den Kernel-Entwicklern abgelehnte) Kernel-Code im Mainline Kernel landen, bevor der amdgpu-Treiber nicht so kompliziert zu benutzen ist und AMD den Code für den Vulkan-Treiber raushaut.

[AffenJack]

Phoronix hat es jetzt auch auf Nvidia getestet, Vulkan auch in 4k immer (teils extrem) schneller als OpenGL:
http://www.phoronix.com/scan.php?page=article&item=nvidia-vlk-madmax&num=5
Scheint also offenbar gegenüber OpenGL auch im GPU-Limit noch zuzulegen.

Liegt aber auch daran, dass Opengl bei Madmax auf Nvidia überhaupt nicht läuft.

https://www.phoronix.com/scan.php?page=article&item=radv-mad-max&num=2
http://www.phoronix.com/scan.php?page=article&item=nvidia-vlk-madmax&num=2

Bei OpenGl ist Fury teils schneller als eine GTX1080Ti, erst mit Vulkan normalisieren sich die Verhältnisse. Woran es bei Nvidia in opengl klemmt, keine Ahnung.

[aufkrawall]

Ich hab den Eindruck, NV ist mittlerweile etwas außen vor, weil Feral und Valve offenbar den Fokus auf Mesa legen.
CS:GO stottert hier z.B. teilweise wie die Pest, während es mit amdgpu recht sauber laufen soll.
Edit: Bez. OGL natürlich.

[iuno]

BTW, @dargo: Was ist bei dir "nichts"? Bei Steam sind es noch 20€

@Ganon: Wenn der Vulkan Treiber so weit waere koennten sie ihn auch einfach so schon raus hauen, das wuerde immerhin radv helfen. Der andere kommt eh nicht in Mesa. Ausserdem braucht man nur die gepatchte libdrm damit er mit dem Mainline Kernel/amdgpu laueft, waere also auch nicht so ein Problem mit der Komplexitaet.

oha, da stimmt ja etwas ganz ordentlich nicht mit Mad Max auf Nvidia/Linux.
Dass NV aussen vor ist wuerde ich nicht sagen. Feral hat jahrelang nur Nvidia unterstuetzt, das ist bei Mad Max uebringens nicht anders. Erst seit neuestem schauen sie auch naher (bzw. ueberhaupt mal) auf Mesa Treiber. Das ist natuerlich sehr zu begruessen, rechtfertigt aber nicht, dass das Spiel fuer Nvidia offenbar komplett kaputt ist.
Auch Steam Boxen gab es immer nur mit Nvidia. Valve will sicher dort ansetzen, dass auch guenstigere Spielerechner moeglich und tauglich werden. Ausserdem haben sie halt unmittelbaren Einfluss, wenn sie an Mesa mitarbeiten. Das ist aber bisher auch sowieso nur VR Kram. Die Nvidia Performance bleibt natuerlich trotzdem mindestens genauso wichtig, der Marktanteil ist ja viel hoeher.
Kann auch sein dass NV sich bisher eben nicht um das Spiel geschert hat. Mesa bekommt auch immer haeufiger Patches wo es um Verbesserungen in speziellen Spielen geht.

Wird aber jetzt doch sehr OT :redface:

[aufkrawall]

Trotzdem komisch, dass CS:GO/Source so mies mit dem proprietären läuft.
Ist auch auf Kepler so, während Nouveau (bei natürlich viel niedrigeren avg-fps) ziemlich sauber läuft.
Liegt auch nicht allein am MT.

[dargo]

BTW, @dargo: Was ist bei dir "nichts"? Bei Steam sind es noch 20€

Habs doch verlinkt. :confused:
https://www.forum-3dcenter.org/vbulletin/showpost.php?p=11336604&postcount=2433

4€ ist für mich nichts.

[iuno]

Sorry, war wohl komplett blind. :facepalm: Taugt der shop?

Michael Larabel scheint Spass an Mad Max gefunden zu haben. Es gibt jetzt auch einen Ryzen Test (http://www.phoronix.com/scan.php?page=article&item=amd-ryzen-madmax&num=2) wo Nvidia uebrigens nicht so unterirdisch ist. Ausserdem sollen noch governor Tests kommen, wo das Spiel sicher auch dabei ist.

@aufkrawall: Ja, wenn Nouveau besser laeuft als Nvidia stimmt schon was gehoerig nicht. Hast du CS eigentlich auch schon mal mit schedutil oder performance versucht?

[DanMan]

Sorry, war wohl komplett blind. :facepalm: Taugt der shop?
Der taugt was: https://de.gamesplanet.com/game/mad-max-steam-key--2831-1

Idealer Weise unter Linux freischalten, damit Feral auch ihren Anteil abbekommen. Sonst gehen sie leer aus.

Hab es mir gestern von Gamesplanet bestätigen lassen, dass es bei ihnen so läuft. Ist nicht in jedem Shop so. In manchen bekommen sie auch dann nichts.

[d2kx]

https://blogs.unity3d.com/wp-content/uploads/2017/03/Blog_Header_Edit_2-560x200.png

Unity 5.6 Release Notes (https://blogs.unity3d.com/2017/03/31/5-6-is-now-available-and-completes-the-unity-5-cycle/)

Vulkan support
Vulkan support brings increased speed while reducing driver overhead and CPU workload; this leaves the CPU free to do additional computation or rendering and saves on battery life for mobile platforms.

Unity 5.6 adds Vulkan support on Android, Windows and Linux platforms. We also added initial support for OpenVR.

[dargo]

Taugt der shop?

Hier hatte ich schon öfter eingekauft.
http://www.cdkeys.com/pc/games/mad-max-pc?mw_aref=8023ef0aa94165947417b567beee956d&utm_source=keyforsteam.de&utm_medium=referral&utm_campaign=keyforsteam

Noch nie Probleme gehabt.

[aufkrawall]

@aufkrawall: Ja, wenn Nouveau besser laeuft als Nvidia stimmt schon was gehoerig nicht. Hast du CS eigentlich auch schon mal mit schedutil oder performance versucht?
Hab gerade nochmal alles durchprobiert (Shadercache aus, Threaded-Optimierung aus, CPU-Volltakt, GPU-Volltakt...): keine Chance. :(
Sieht für mich aber auch schon wieder wie ein Shadercompiler-Problem aus: Immer, wenn Effekte erstmalig dargestellt werden, gibts üble Renderstalls + zwischendurch immer mal wieder. Mit der Zeit läuft es dann wesentlich besser, evtl. hilft hier der Disk-Shadercache des Treibers.

Mad Max kauf ich mir jetzt nicht extra wegen Vulkan, ich hege eher Hoffnungen in einen Hitman-Patch. Das hängt mit OGL nämlich auch auf einem Thread fest, wenn auch nicht so schlimm wie bei Mad Max + NV.

[Stebs]

Bei OpenGl ist Fury teils schneller als eine GTX1080Ti, erst mit Vulkan normalisieren sich die Verhältnisse. Woran es bei Nvidia in opengl klemmt, keine Ahnung.Mit der Mad-Max (Vulkan) Beta gibt es aktuell Performance-Probleme unter OpenGL mit Nvidia, die es bei der stabilen (normalen) Version nicht gibt, dort hat man mit OpenGL mehr FPS als in der neuen Beta!

Vulkan ist dann aber nochmals schneller als OpenGL in der regulären Version.
Die Zuwächse mit Nvidia sind (manchmal?) wohl nur nicht so dramatisch wie es zuerst aussah.

Erstaunlicherweise profitiert bei mir sogar eine Nvidia 650Ti Boost etwas von Vulkan, mit einem i7 2600k @ 4,4 Ghz laufe ich auch unter OpenGL quasi im GPU-Limit (und nicht im CPU-Limit), theoretisch sollte Vulkan da also nicht viel bringen, tut es aber...

[aufkrawall]

Siehe eine mögliche Erklärung von SaschaW dazu:
https://www.forum-3dcenter.org/vbulletin/showpost.php?p=11336597&postcount=2432

[Stebs]

Siehe eine mögliche Erklärung von SaschaW dazu:
https://www.forum-3dcenter.org/vbulletin/showpost.php?p=11336597&postcount=2432Ja, hatte ich schon gelesen, danke.
"theoretisch sollte Vulkan da also nicht viel bringen" bezieht sich da eher auf die allgemeine Meinung dazu...

Edit: So, zur Feier des Tages mal einen neuen Avatar reingetan :tongue:

[Gast]

Das erklärt so einiges bzgl. der Nvidia OpenGL performance.

https://www.gamingonlinux.com/articles/some-notes-and-benchmarks-about-a-performance-regression-in-mad-maxs-opengl-rendering.9432

[iuno]

Mit der Mad-Max (Vulkan) Beta gibt es aktuell Performance-Probleme unter OpenGL mit Nvidia, die es bei der stabilen (normalen) Version nicht gibt, dort hat man mit OpenGL mehr FPS als in der neuen Beta!

Hier mit belegender Messung: https://www.gamingonlinux.com/articles/some-notes-and-benchmarks-about-a-performance-regression-in-mad-maxs-opengl-rendering.9432

[aufkrawall]

Nachtest von Mad Max Vulkan:
https://www.gamingonlinux.com/articles/opengl-vs-vulkan-in-mad-max-re-tested.9457
Interessant ist der Aspekt mit den mülligen CPU-Takt Governors auf Linux, hab das in eigenen Tests auch schon festgestellt.

[dildo4u]

Quake Champions soll ein Vulkan Pfad bekommen.

http://www.pcgameshardware.de/Quake-Champions-Spiel-57337/Specials/Hands-On-Test-Arena-Vulkan-1224732/

[aufkrawall]

Mit aktuellem Pascal-Treiber (liegt es daran?) gibt es offenbar so gut wie keinen Unterschied mehr bei Dooms Performance im GPU-Limit zwischen OGL und Vulkan:
https://abload.de/thumb/ogltarof.jpg (http://abload.de/image.php?img=ogltarof.jpg) https://abload.de/thumb/vulkan5vow0.jpg (http://abload.de/image.php?img=vulkan5vow0.jpg)
In WQHD ist manchmal OGL noch minimal vorn, im CPU-Limit siehts dann natürlich alt aus.
Doom scheint btw. mit Vulkan mehr Threads zu nutzen als mit OGL, der Performance-Gewinn geht also nicht nur auf geringeren Overhead zurück.

[Troyan]

Nö, mit Alptraum-Einstellungen ist der Vulkan-Pfad immer noch kaputt. Aber hey, id hat über Twitter ja schon angekündigt, dass in Zukunft keine Optimierungen für nVidia-Hardware erfolgen werden. Auch eine Unternehmensphilosophie...

https://abload.de/thumb/doomx64_2017_04_15_22rzq9s.png (http://abload.de/image.php?img=doomx64_2017_04_15_22rzq9s.png) https://abload.de/thumb/doomx64vk_2017_04_15_kurbq.png (http://abload.de/image.php?img=doomx64vk_2017_04_15_kurbq.png)

Sind weiterhin ~15% Leistungsunterschied im reinen GPU-Limit.

[aufkrawall]

Mit den unsinnigen Nightmare-Schatten hatte ich nicht getestet, die fressen Performance für eine ohne direkten Vergleich kaum wahrnehmbare Qualitätssteigerung.
Streaming-Pool stand aber auf nightmare.

[Locuza]

[...] Aber hey, id hat über Twitter ja schon angekündigt, dass in Zukunft keine Optimierungen für nVidia-Hardware erfolgen werden. Auch eine Unternehmensphilosophie...

Tell that NVIDIA. They are the sole reason for vec4 alignment, 64KiB limits and the existence of constant buffers.

Ist halt unsinnig für schlechte Hardwarerestriktionen Zeit und Ressourcen zu verschwenden. ¯\_(ツ)_/¯

[Troyan]

Deswegen ist OpenGL auch besser als Vulkan. Böses nVidia.

[Locuza]

Hey, irgendjemand muss doch seine Zeit damit verschwenden, um an dämlichen Flaschenhälsen herum zu optimieren, wer wenn nicht Nvidia eignet sich am Besten dafür?
Vor allem wenn man als Kunde Premiumpreise für Mainstreamprodukte bezahlt. =)

[Troyan]

Sage ich ja: nVidia-User spielen für diese Firma keine Rolle. Es gibt keine Optimierungen. Das hat der Chef auch per Twitter offiziell verkündet:
https://twitter.com/idSoftwareTiago/status/835919666249936897

nVidia ist nicht verantwortlich für Vulkan. Den Pfad unoptimiert lassen, ist eben auch ein Verrat an der eigenen Kundschaft von id.

[dargo]

Schon vor einiger Zeit gab es Unkenrufe, dass manche keinen Bock auf Nvidia haben. Ein bisschen Wahrheit wird schon dran sein.

[fondness]

Es gab natürlich schon einen guten Grund, warum AMD die low level APIs wollte. Man hat eine sehr flexible HW, wo Entwickler viel damit machen können. NV hat einige relativ unschöne HW-Limits, holt aber enorm viel über die SW raus, was bei DX11 kein Problem ist, weil es dort der Treiber macht. Bei LL kann das für Entwickler natürlich lästig werden. Foobar hat sich ja auch mal darüber ausgelassen:
https://www.forum-3dcenter.org/vbulletin/showthread.php?p=11177950#post11177950

[dildo4u]

Nö, mit Alptraum-Einstellungen ist der Vulkan-Pfad immer noch kaputt. Aber hey, id hat über Twitter ja schon angekündigt, dass in Zukunft keine Optimierungen für nVidia-Hardware erfolgen werden. Auch eine Unternehmensphilosophie...

https://abload.de/thumb/doomx64_2017_04_15_22rzq9s.png (http://abload.de/image.php?img=doomx64_2017_04_15_22rzq9s.png) https://abload.de/thumb/doomx64vk_2017_04_15_kurbq.png (http://abload.de/image.php?img=doomx64vk_2017_04_15_kurbq.png)

Sind weiterhin ~15% Leistungsunterschied im reinen GPU-Limit.
Läuft bei mir ganz Normal mit dem Ultra Preset@4k,die Nightmare Schatten werden einfach mehr Vram belegen unter Vulkan.
Oder DSR macht Probleme ich zocke jetzt nativ 4k auf meinem TV.

https://c1.staticflickr.com/3/2816/34027369396_87f2d884fd_h.jpg (https://flic.kr/p/TQTaqG)DOOMx64_2017_04_16_11_55_10_257 (https://flic.kr/p/TQTaqG) by Gorgul (https://www.flickr.com/photos/56281102@N02/), auf Flickr

https://c1.staticflickr.com/3/2850/34027568586_7215795291_h.jpg (https://flic.kr/p/TQUbD1)DOOMx64vk_2017_04_16_12_10_14_607 (https://flic.kr/p/TQUbD1) by Gorgul (https://www.flickr.com/photos/56281102@N02/), auf Flickr

[Kriton]

Sage ich ja: nVidia-User spielen für diese Firma keine Rolle. Es gibt keine Optimierungen. Das hat der Chef auch per Twitter offiziell verkündet:
https://twitter.com/idSoftwareTiago/status/835919666249936897

nVidia ist nicht verantwortlich für Vulkan. Den Pfad unoptimiert lassen, ist eben auch ein Verrat an der eigenen Kundschaft von id.

Liest Du eigentlich die eigenen Links?

Oh, one last tip, on adoption topic: research that only runs on one GPU vendor ( unless is consoles ) is not usable

Keine Präferierung vendor-spezifischer Technik. Das ist prinzipiell weder pro AMD, noch Nvidia.

[iuno]

Keine Präferierung vendor-spezifischer Technik. Das ist prinzipiell weder pro AMD, noch Nvidia.
AMD steckt in Konsolen, wird also in dem Satz explizit ausgeschlossen. DOOM verwendet vendor-spezifische Technik, die Skalareinheit.

[Kriton]

AMD steckt in Konsolen, wird also in dem Satz explizit ausgeschlossen. DOOM verwendet vendor-spezifische Technik, die Skalareinheit.

Das ist mir klar. Aber das Thema Konsolen ist betriebswirtschaftlich und technisch begründet und insoweit vendor-agnostisch. Sein ID-Bashing ist deshalb in der geübten Form im Kontext unsubstantiiert. Übrigens ist auch die Switch eine Konsole - mit Nvidia-Tech.

[Unicous]

Liest Du eigentlich die eigenen Links?

Das ist sein modus operandi. Er zieht Aussagen aus dem Kontext, verkehrt sie ins Negative oder dichtet diesen Aussagen eine Bedeutung an die er eindeutig erfunden hat.

Solche Trolle kann nur ignorieren.

[deekey777]

Eine Frage zu den Doom-Bildern: Das ist doch bloß der Anfang des Spiels, oder? Oder ist es nur die Demoversion?

[aufkrawall]

Hat keinen Benchmark-Modus eingebaut. Ich hatte aber auch eine andere Stelle später getestet (nach dem ersten Imp aus nächster Nähe durch die Scheibe schauen), machte keinen Unterschied bzw. war Vulkan in WQHD hier genau gleich schnell wie OGL statt minimal langsamer.

[Hübie]

Also die Schmiede war noch ein sehr fordernder Abschnitt des Spiels. Krass war afair auch das Level wo man den Cyberdemon in der Hölle erledigte (also der Teil im Anschluss). Eine Zeit lang lief Vulkan insgesamt runder als OpenGL. Kleine Stellen mit unerklärlich schlechter Leistung mal ausgenommen. Da erinnere ich mich an Blutflecken.
Das ist genau das was auch immer über low level API gesagt wird: Man muss eben viel Arbeit als Entwickler in Kauf nehmen. :) Wenn die Hardware limitiert bringt aller Fleiß jedoch nix.

[aufkrawall]

Ist nur die Frage, ob die Hardware so sehr limitiert, dass man einfach die Performance gar nicht rausholen kann, oder ob man nicht Umwege dafür in Kauf nehmen muss, auf die man keinen Bock/keine Zeit hat.
Sniper Elite legt jedenfalls auch auf NV mit DX12 zu, und das je nach GPU kaum weniger als AMD.

[fondness]

Sniper Elite legt jedenfalls auch auf NV mit DX12 zu, und das je nach GPU kaum weniger als AMD.

Es ist wohl keine gewagte These, dass NV bei Doom 3 sicherlich wesentlich stärker optimiert hat als bei Sniper Elite.

[dargo]

Alleine schon der AC-Einsatz in Sniper Elite ist ein Witz im Vergleich zu Doom.

[vinacis_vivids]

AMD macht +20% und Nvidia +5% bei DX12@Async
Der Performancegwinn für die grünen sind signifikant schlechter.
https://abload.de/img/se4dx11dx12asyncxhavb.jpg

FuryX > 1070
https://abload.de/img/se44kcbxnas4.jpg

[dargo]

AMD macht +20% und Nvidia +5% bei DX12@Async
Der Performancegwinn für die grünen sind signifikant schlechter.
https://abload.de/img/se4dx11dx12asyncxhavb.jpg
Falsch... AMD legt nur 3% bei AC On zu. Deine 20% kommen von DX11 auf DX12 + AC.

[vinacis_vivids]

Falsch... AMD legt nur 3% bei AC On zu. Deine 20% kommen von DX11 auf DX12 + AC.

Ja, und +20% sind deutlich mehr als +5%.

http://www.guru3d.com/articles_pages/sniper_elite_4_pc_graphics_performance_benchmark_review,7.html

Erschreckend ist der Einbruch von Pascal bei WQHD -> UHD trotz größerem VRAM.
TitanX: 116 -> 72fps (-61%)
1080: 90 -> 55fps (-63%)
1070: 72 -> 40fps (-80%)

FuryX: 71 -> 49fps (-45%)

Vega braucht bei diesem Spiel nur pusten und Pascal wird umfallen.

[Ex3cut3r]

AMD macht +20% und Nvidia +5% bei DX12@Async
Der Performancegwinn für die grünen sind signifikant schlechter.
https://abload.de/img/se4dx11dx12asyncxhavb.jpg

FuryX > 1070
https://abload.de/img/se44kcbxnas4.jpg

Nicht mehr aktuell, ist vom 14.2.2017. Mittlerweile sind zig Patches und Treiber erschienen.

[vinacis_vivids]

Ja, klar, auf den Wundertreiber von Nvidia warten ihre Fans schon Jahrzehnte.

Update mit 378.78:
http://www.guru3d.com/articles_pages/zotac_geforce_gtx_1080_mini_review,12.html

Fazit: Kein Wundertreiber.

[dargo]

Ja, und +20% sind deutlich mehr als +5%.

Du hast da einen kleinen Denkfehler. Die GTX1060 ist unter DX11 schon 8% vor der RX480. Da ist es nur logisch, dass der Zugewinn von DX11 auf DX12 bei NV entsprechend kleiner ausfällt.

[vinacis_vivids]

Du hast da einen kleinen Denkfehler. Die GTX1060 ist unter DX11 schon 8% vor der RX480. Da ist es nur logisch, dass der Zugewinn von DX11 auf DX12 bei NV entsprechend kleiner ausfällt.

Nein ist es nicht. Die Tatsache, dass RX480 schneller ist als GTX1060, wird gerne übersehen.

BTT:
Bei Doom gilt auch FuryX > 1070 bzw. RX480> 1060
http://www.guru3d.com/articles_pages/zotac_geforce_gtx_1080_mini_review,19.html

[StefanV]

Ja, klar, auf den Wundertreiber von Nvidia warten ihre Fans schon Jahrzehnte.
Wenn man jetzt richtig fies wäre, was wir ja nicht sind, würde man DX12 für Fermi erwähnen...


Aber wie schauts eigentlich mit 2GiB GK104 Karten und Doom aus? Geht das inzwischen oder ist das immer noch nicht 'supported'?

Aber wann gabs denn wirklich mal "Wundertreiber", die 2stellige Prozentbeträge brachten??
Außer natürlich kurz nach Vorstellung einer neuen Architektur...

[dargo]

Erschreckend ist der Einbruch von Pascal bei WQHD -> UHD trotz größerem VRAM.
TitanX: 116 -> 72fps (-61%)
1080: 90 -> 55fps (-63%)
1070: 72 -> 40fps (-80%)

FuryX: 71 -> 49fps (-45%)

Mal davon abgesehen, dass deine Prozentrechnung völlig daneben ist. :tongue: Auch hier hast du einen kleinen Denkfehler. Fiji profitiert einfach von hoher Pixellast. Oder anderes formuliert... Fiji liefert bei geringerer Pixellast etwas zu wenig. Dadurch sieht dann natürlich der Leistungsabfall in 4k im Vergleich zu anderen GPUs (übrigens auch RX480, diese verliert 37%) kleiner aus.

Edit:
Ich habs mal korrigiert weil es in den Augen schon brennt. :D

TitanX: 116 -> 72fps (-38%)
1080: 90 -> 55fps (-39%)
1070: 72 -> 40fps (-44%)

FuryX: 71 -> 49fps (-30%)

[aufkrawall]

Mit der Full Chip Titan Xp wäre der Verlust auch noch leicht geringer als mit der X. Und siehe da, ein voll aktivierter Highend-Chip bricht am wenigsten mit steigender Auflösung ein. :rolleyes:

[Iruwen]

Ist ja schon bezeichnend wenn man immer wieder die gleichen zwei bis drei Games cherry picken muss um seinen Standpunkt zu untermauern.

[gravitationsfeld]

Ist halt unsinnig für schlechte Hardwarerestriktionen Zeit und Ressourcen zu verschwenden. ¯\_(ツ)_/¯
Wo steht da, dass man nicht dafür optimiert? Darf man jetzt NVIDIA nicht mehr kritisieren, oder was?

[Hübie]

Ja, klar, auf den Wundertreiber von Nvidia warten ihre Fans schon Jahrzehnte.

Update mit 378.78:
http://www.guru3d.com/articles_pages/zotac_geforce_gtx_1080_mini_review,12.html

Fazit: Kein Wundertreiber.

Du machst den gleichen Fehler wie dargo: Die Werte sind von damals übernommen worden. Wenn du etwas wirklich beurteilen willst, dann prüf das selber oder guck nach aktuellen Benchmarks. :rolleyes:

POE: https://abload.de/thumb/guru3d_sniperelite4j0o6d.png (http://abload.de/image.php?img=guru3d_sniperelite4j0o6d.png)

Fazit: Dein Fazit ist für den Arsch!

[Ex3cut3r]

Danke Hübie für die Aufkärung, vinacis_vivids malt sich gerne die Welt so, wie es ihm grade gefällt.

[dargo]

Fehler? :tongue:

Die Geschichte mit Copy & Paste ist schon ein lang bekanntes Problem. Wer sagt, dass die Radeons in der Zeit nicht auch paar Prozent @DX12 zugelegt haben und sich entsprechend an den Verhältnissen kaum bis gar nichts geändert hat?

[Screemer]

Dann nimm die Werte von CB vom 9.4.. Da sind alle Karten neu getestet worden und das Bild ist das gleiche wie oben: http://www.computerbase.de/thema/grafikkarte/rangliste/#abschnitt_gpuvergleich_die_aktuelle_gpurangliste_april_2017. wer sich die Welt malt wie sie ihm gefällt ist in dem Fall wohl eher hübie.

[dargo]

Die haben da allerdings irgendeinen riesen Fehler drin. Wenn ich nur Doom markiere kommt die RX480 in 1080p auf 43,1fps und in 1440p auf 46,7fps. :| Beides vieeeel zu niedrig. Besonders @1080p. Fehler in der Berechnungsformel? Selbst die Fury X kommt auf 51fps in 1080p. :ulol: :usweet:

Edit:
Zum Vergleich... hier sind es 160,4fps für die Fury X. ;D
https://www.computerbase.de/2017-03/geforce-gtx-1080-ti-test/2/#diagramm-doom-1920-1080

Edit 2:
Ah... jetzt verstehe ich. Im neuen Test bildet die 1080 TI die Ausgangsbasis mit 100%, das sind ja gar keine fps. :tongue: Trotzdem sind manche Werte merkwürdig. Am 09.04.17 ist die Fury X in Doom @Vulkan in 1080p nur noch 18% vor der RX480. Am 09.03.17 waren es noch 31%.

[dildo4u]

PCGH hat neue Test's im Heft dort sieht man die Limit's von Fury ganz deutlich,ich vermute mal wenn Fury in 4k mithält werden Detail's ausgeblendet weil sie nur 4GB Ram hat.



https://c1.staticflickr.com/3/2821/34089933275_b0a29d19d7_h.jpg (https://flic.kr/p/TWpPug)IMG_20170417_095018866 (https://flic.kr/p/TWpPug) by Gorgul (https://www.flickr.com/photos/56281102@N02/), auf Flickr

[dargo]

PCGH hat neue Test's im Heft dort sieht man die Limit's von Fury ganz deutlich,ich vermute mal wenn Fury in 4k mithält werden Detail's ausgeblendet weil sie nur 4GB Ram hat.

Das ist Quatsch. Zum x-ten Male... Fury braucht hohe Pixellast! Es gibt bisher nur sehr wenige Games die automatisch bei zu wenig Vram Details senken. Schau dir das ganze einfach mal nicht mit max. Details in 4k an (da sind die Frameraten eh oft zu niedrig) sondern zb. mit einem High Preset. Möglichst so, dass die 4GB nicht bremsen.

[vinacis_vivids]

Du machst den gleichen Fehler wie dargo: Die Werte sind von damals übernommen worden. Wenn du etwas wirklich beurteilen willst, dann prüf das selber oder guck nach aktuellen Benchmarks. :rolleyes:

POE: https://abload.de/thumb/guru3d_sniperelite4j0o6d.png (http://abload.de/image.php?img=guru3d_sniperelite4j0o6d.png)

Fazit: Dein Fazit ist für den Arsch!

Treiber 378.92
https://abload.de/img/sniperelite4_3840_216sapg4.png
https://www.techpowerup.com/reviews/Gigabyte/GTX_1080_Ti_Xtreme_Gaming/23.html

Hier von der transparenten Bibel:
https://abload.de/img/se44kcbxnas4.jpg

Wie ich schon sagte: Keine Wundertreiber für Nvidia. FuryX > 1070. Ist nunmal ne Tatsache, die man hinnehmen muss auch wenn es einen das Fazit vllt. nicht schmeckt.

[Hübie]

Bei PCGH ist es wieder umgekehrt. Was soll das nun sagen bzw. worauf willst du hinaus? :|