News Vulkan: Erste Benchmarks der neuen API in Talos Principle

Wo kommt denn der Output her? Software-Emulation ist das bei den GL3+-Programmen ganz sicher nicht, sonst würden z.B. die Unigine-Demos kaum mit 50 FPS laufen.

Stellt sich sowieso die Frage, warum Apple unbedingt eine eigene Implementierung braucht. Die von Nvidia ist recht gut. Die von AMD taugt nicht viel, unterstützt aber immerhin GL 4.5. Mesa ist aus verschiedenen Gründen recht langsam, inzwischen aber weiter als Apples eigene Implementierung.

Naja, wenn MetalVK was wird, dürfte das auch nicht mehr so wirklich relevant sein. Dass Apple sich aber selbst von Mesa hat überholen lassen, die ja nun wirklich extrem lange für GL 4-Support gebraucht haben, ist schon ein Armutszeugnis, zumal es auf den Macs ja auch bis Metal keine Alternative gab.
 
Zuletzt bearbeitet:
Gab heute ein Update vom Spiel. Leider lässt sich nun die 64bit Version nicht mehr starten. Einem Steam Community Eintrag zufolge hat man erst vor 2 Tagen eine Build an die IHVs geschickt, um Bugs auszumerzen. Im Gegenzug haben die IHVs auch Bugs beim Spielt entdeckt.

Schön zu sehen dass daran so fleißig gearbeitet wird. Hoffentlich hält man die GPU Treiber auch dementsprechend aktuell.
 
blackiwid schrieb:
Selbst das halte ich fuer zu pesimistisch, valve opengl spiele laufen unter linux zumindest, 110% fps im vergleich zu windows dx versionen.

Ich pfeif auf die Valve engine ...
https://de.wikipedia.org/wiki/Quake_(Spieleserie)#Quake-Engine
https://de.wikipedia.org/wiki/Quake-Engine

Zu Quake3 Zeiten, sagte man schon das es besser läuft auf Linux & OpenGL, aber das ist ja sehr laaaaange her.

Ob das überhaut etwas noch wird ist eher fraglich bei Zenimax & idSoftware, vielleicht ja ab Doom 2016 im Steam Store.

soweit ich weis, benutzte Carmack ein Xbox DX-devkit für die Engine zum *debuggen*, so hat er es in einem Vortrag auf einer QuakeCon gesagt.
 
dMopp schrieb:
Das mit dem 4.0 ist rein software emuliert (soweit ich mich erinnere) und das ist einer der Gründe, warum Spiele unter OSX so beschissene Performance aufweisen...
[…]
Ha, ich wusste es, bis heute wird nur OpenGL 2.1 voll supported, 3.0 zu 95% und 4.x 0%

Du meinst vermutlich, dass OS X den Legacy Müll von OpenGL nicht mitmacht. (Wie Mesa auch) Das ist nicht negativ, das ist eher positiv. Legacy Context geht nur bis OpenGL 2.1, darüber hinaus core context or bust.

Mit der Geschwindigkeit von Spielen hat das nichts zu tun, das ist lediglich ein weiteres Hindernis für Entwickler, die neue Features in alte Software einbauen wollen. Ein Hindernis, das für besseren Code am Ende sorgt und im Zweifelsfall das Spiel eher schneller macht – schon alleine dadurch, dass mehr Zeit für Treiber Optimierung da ist, die sonst für Legacy Support draufgehen würde.

http://www.g-truc.net/doc/OpenGL 4 Hardware Matrix.pdf

dMopp schrieb:
Kann es sein, dass die Spiele die bisher unter OSX laufen nur openGL 3.x nutzen ?

Nein, neue Ports wie zum Beispiel Shadow of Mordor nutzen 4.1.
 
Zuletzt bearbeitet:
Danke für die Aufklärung. Wieder was gelernt.
 
Zehkul schrieb:
Mit der Geschwindigkeit von Spielen hat das nichts zu tun, das ist lediglich ein weiteres Hindernis für Entwickler, die neue Features in alte Software einbauen wollen.

Kennst Du dich ein wenig mit OpenArena aus ?

Da ich mich von id verabschiedet habe, ist das noch meine einzíge Freude und Hoffnung ...

http://openarena.ws/news.php
*Next Release: 3.0.0 (aka OA3, content reboot) ETA: ???!?!*

https://de.wikipedia.org/wiki/OpenArena
https://ioquake3.org/news/

Ich hatte bisher nur Probleme mit der Wiederholrate des Bildschirms an meinem PC, auch mit GTX760 & nVidia Treiber + alten Röhrenmonitor :-/
 
Bin ja gespannt, ob Vulkan eine echte Alternative zu DX 12 wird. Wir werden es sehen.
 
9t3ndo schrieb:
Das man dann auf DX12 setzt um Xone und PC gleichzeitig abzudecken (2 Fliegen mit einer Klappe und so) ist da nur naheliegend.
Ich bin gespannt wie es mit Vulkan weiter geht.
DX12 deckt den PC aber nicht komplett ab sondern nur Windows 10. Diesen Umstand erwähnen die Talos-Entwickler ausdrücklich in ihrer FAQ:
Q: Oh, so it's like Direct3D 12?

A: Quite like it, but portable, and not restricted to Windows 10 OS.
Mit Vulkan erreicht man gegenüber DX12 noch Win7, Win8, Linux PCs und Android-Geräte.
Mit DX12 erreicht man gegenüber Vulkan nur die Xbox One.
 
VikingGe schrieb:
Stellt sich sowieso die Frage, warum Apple unbedingt eine eigene Implementierung braucht. Die von Nvidia ist recht gut. Die von AMD taugt nicht viel,

Eben aus diesem Grund. Jede Implementierung ist anders und Apple hat das für ihre Plattform zum Glück vereinheitlicht. AMDs OpenGL Implementierung ist nicht so schlecht wie ihr ruf, das Problem sind dann eher Nvidias Comfort Features. Dinge die nicht Spezifiziert oder gar möglich sein sollten funktionieren auf Nvidia Hardware die dann bei AMD und Intel zur Katastrophe führen. Mesa musste das auch schon mal erleben und musste damit beginnen ebenfalls solche Hacks einzubauen.
 
Eben aus diesem Grund. Jede Implementierung ist anders und Apple hat das für ihre Plattform zum Glück vereinheitlicht.
Wenn Apples Implementierung nicht auf dem Stand von 2010 wäre und nicht an ungerfähr 50% der OpenGL-Samples von g-truc scheitern würde, wäre das vielleicht ein Argument, ja. Und bei Talos Principle hat Apple offenbar auch viele Probleme bereitet, siehe Link von MotherPink - wobei GL 3.2+ besser laufen könnte, ist ja doch das sauberere API.

Was Nvidia angeht: Auf Nvidias Implementierung funktioniert standardkonformes OpenGL in weiten Teilen so, wie es soll. Was du meinst, ist ja eher der umgekehrte Fall, dass nicht standardkonformes GL eben auch funktioniert. Da fallen mir auch spontan zwei größere Probleme ein:

- Nvidias libgl exportiert alle Symbole, was nicht sein sollte. Einige Spiele verlassen sich darauf und Mesa exportiert jetzt die Symbole, die für ganz bestimmte Spiele gebraucht werden - statt sich da wenigstens konsequent nicht an den Standard zu halten.

Vulkan hat das Chaos übrigens schon in der Spezifikation integriert. Loader können Symbole exportieren, müssen es aber nicht. Der Standard-Loader exportiert sie aber und ich denke mal, so viele verschiedene Loader wird es nicht geben.

- Nvidia arbeitet bei der Abfrage diverser Framebuffer-Eigenschaften so gekonnt am Standard vorbei, dass sich alle anderen Implementierungen - außer Mesa - an das Nvidia-Verhalten angepasst haben.

Beim zweiten Punkt kann man als Entwickler nichts machen als nen Workaround zu schreiben, bei allen anderen Punkten sehe ich aber die Entwickler in der Pflicht, a) mal die Dokumentation zu lesen und zu schauen, was erlaubt ist und was nicht, b) ihr Zeug auch mal auf anderen Implementierungen zu testen, c) auf GL_NV_xyz-Erweiterungen zu verzichten. Das Problem ist ja nicht nur, dass das Nvidia-spezifische Zeug existiert, das Problem ist, dass es genutzt wird.
 
Nvidias Vulkan-Treiber hat auch einen major fuckup:

Code:
       [HINT] Vulkan: Extension support status:
       [HINT] Vulkan: Supports VK_EXT_debug_report                 : yes
       [HINT] Vulkan: Supports VK_KHR_surface                      : yes
       [HINT] Vulkan: Supports VK_KHR_wayland_surface              : no
       [HINT] Vulkan: Supports VK_KHR_win32_surface                : no
       [HINT] Vulkan: Supports VK_KHR_xcb_surface                  : yes
       [HINT] Vulkan: Supports VK_KHR_xlib_surface                 : yes
      [...]
      [DEBUG] Vulkan: [instance] vkCreateXlibSurfaceKHR                             = nullptr  <-- AUTSCH!!
      [DEBUG] Vulkan: [instance] vkGetPhysicalDeviceXlibPresentationSupportKHR      = 0x140557036473960
      [DEBUG] Vulkan: [instance] vkCreateXcbSurfaceKHR                              = 0x140557036448384
      [DEBUG] Vulkan: [instance] vkGetPhysicalDeviceXcbPresentationSupportKHR       = 0x140557036448400
      [DEBUG] Vulkan: [instance] vkCreateWaylandSurfaceKHR                          = nullptr
      [DEBUG] Vulkan: [instance] vkGetPhysicalDeviceWaylandPresentationSupportKHR   = nullptr

...was leider dazu führt, dass man es mit SDL im Moment nicht so wirklich sinnvoll benutzen kann. GLFW hatte damit auch schon ein Problem und irgendwo existiert auch bei NV ein Bugreport. Wird mal Zeit für nen Hotfix. :freak:

Ich weiß auch nicht, wie die XCB-Anbindung implementiert ist. Möglicherweise ist das ganze aber genau deswegen unter Linux langsamer, XCB selbst unterstützt nämlich kein Direct Rendering.
 
Zuletzt bearbeitet:
Naja, die ersten Versionen von Direct3D waren 1995 auch größtenteils chancenlos gegen das bereits etablierte und populäre Glide von 3dfx. Aber für den Anfang sieht das doch schon gut aus. Luft nach oben ist auf jeden Fall vorhanden.
Aber ohne Support seitens der Engine- und Spieleentwickler wird Vulkan keinen großen Erfolg haben, abgesehen von ein paar Vorzeigespielen und netten Techdemos.
 
Das S7 von Samsung unterstützt wohl die Vulkan API.
Das ist meiner Meinung nach schon mal eine Hausnummer für die API.
Ergänzung ()

Passend auch der Post von EPIC zu der Unreal Engine mit Vulkan auf dem Samsung Galaxy.
Das Video ist auf der Facebook-Seite zu finden oder youtube.

https://www.youtube.com/watch?v=FnKu7MLB7vQ
 
Zurück
Oben