Vulkan C++ CrossPlatform

Ich habe hin und wieder mal was von Vulkan gehört und mich aber nie wirklich damit beschäftigt. Erst als ich gelesen habe, dass Star Citizen wahrscheinlich auf Vulkan umgestellt wird, bin ich neugierig geworden. Es wurde auch gelobt und man meinte es sei eine sehr gute Alternative zu OpenGL und bietet sogar Crossplatform Unterstützung. Jetzt wollte ich mir Vulkan eigentlich mal ansehen, aber anscheinend gibt es noch nicht viel dazu im Internet. Hat jemand eine Idee wo ich mich über Vulkan schlau machen kann? Ich würde gerne wissen, wie man eine Applikation mit Vulkan baut.

Hatte jetzt nur das hier gefunden und finde es nicht sehr ausführlich. https://vulkan-tutorial.com
Zum Beispiel wird nicht direkt erklärt was VkDeleter ist (was sich für mich irgendwie seltsam anhört).

Außerdem finde ich diesen Code nicht sehr viel versprechen.

VkWin32SurfaceCreateInfoKHR createInfo;
createInfo.sType = VK_STRUCTURE_TYPE_WIN32_SURFACE_CREATE_INFO_KHR;
createInfo.hwnd = glfwGetWin32Window(window);
createInfo.hinstance = GetModuleHandle(nullptr);

Sieht für mich so aus, dass man doch verschiedene Crossplatformelemente selbst programmieren muss. Der Code oben wird sicher nicht unter Linux funktionieren. Und dazu würde ich gerne mehr erfahren.

Kann mir jemand helfen?

edit: hab gerade ein paar Infos gefunden, werde mir die mal ansehen.

Biolunar

Auf der Seite wird doch erklärt was VkDeleter ist: https://vulkan-tutorial.com/Drawing_a_triangle

Vulkan folgt, wie OpenGL auch, dem Extension-Modell. Der Hauptteil von Vulkan wird nur dazu benutzt mit der Hardware zu sprechen. Wie das Resultat auf dem Bildschirm landet ist nicht Teil der Spezifikation von Vulkan. Dazu gibt es die WSI (= Window System Integration) Extensions. Da man bei Vulkan keine Kompromisse eingehen möchte bezüglich der Fenstererstellung, wird diese komplett dem Progammierer überlassen. Man erstellt also wie gewohnt sein Fenster (je nach Platform verschieden!) und kann mit Hilfe der WSI ein VkSurfaceKHR Handle erstellen, welches fortan als Platformunabhängig angesehen werden kann.

Ich finde das ein super API Design. Man hat 100% Kontrolle, weil man die Platform API selbst verwenden muss und die Berührpunkte mit der Vulkan API sind wirklich minimal. So kann man die Stärken jeder Platform gezielt ausnutzen und muss sich nicht mir irgendwelchen Abstraktionen herumschlagen. Das ermöglicht es auch ein crossplatform Bibliothek wie GLFW zu verwenden, wie in dem Tutorial.
OpenGL ist im Vergleich dazu eine Katastrophe: der Kontext muss irgendwie magisch aus dem Äther erstellt werden; überall globale Zustände; Extensions sind auch nur Platformabhängig zu ermitteln; usw.

Hilfreich finde ich https://software.intel.com/en-us/articles/api-without-secrets-introduction-to-vulkan-preface

Das klingt alles unglaublich gut. Fast zu schön um war zu sein. Ich werde das alles auf jedenfall mal weiter verfolgen. Da ich ein Linuxfan bin, hoffe ich natürlich, dass Vulkan bei den Entwicklern Anklang findet.

Ich habe da gerade was gelesen und hab eine Frage dazu. In der verlinkten Seite von Biolunar steht, dass Vulkan eine Low-Level API ist. Und, soweit ich das verstanden habe, bedeutet das, dass größenteils oder ganz auf Treiber verzichtet werden kann. Würde das unter Linux bedeuten, dass man in so einem Fall garnicht auf non-free Treiber, wie Nvidia, angewiesen wäre?

Biolunar

Bennisen schrieb:

Ich habe da gerade was gelesen und hab eine Frage dazu. In der verlinkten Seite von Biolunar steht, dass Vulkan eine Low-Level API ist. Und, soweit ich das verstanden habe, bedeutet das, dass größenteils oder ganz auf Treiber verzichtet werden kann. Würde das unter Linux bedeuten, dass man in so einem Fall garnicht auf non-free Treiber, wie Nvidia, angewiesen wäre?

Treiber braucht man. Unter Linux ist die Open Source Situation momentan so: In der Mesa Bibliothek sind zwei Vulkan-Treiber, ein Intel (genannt Anvil) und ein AMD (gennant RADV). Der von Intel unterstützt alle Karten von Haswell und aufwärts, bei RADV habe ich keine Ahnung Der Treiber ist allerdings auch noch stark in Entwicklung und besteht die Conformance Test Suit auch nicht. Allerdings ist RADV nich mal ein Jahr alt! Das Zeugt von der Schmalheit der Vulkantreiber, im Gegensatz zu den fetten OpenGL implementierungen.
Die proprietären Treiber AMDGPU-PRO und der von Nvidia sind afaik voll Vulkan fähig. Einen Open Source Treiber für Nvidia gibt es noch nicht.

Bennisen schrieb:

Einen Open Source Treiber für Nvidia gibt es noch nicht.

Den wird es wohl auch niemals geben, aber es gibt ja einen Open Source Treiber der aber nicht von Nvidia ist. Da Vulkan ja an sich dann leicht zu implementieren ist, müsste doch normal der Open Source Treiber davon profitieren!?

Wäre halt schön, wenn man nicht an den propritären Nvidia Treiber gebunden ist, da Nvidia an sich wenig Interesse für Linux zeigt und sehr stark hinterher hinkt.

Biolunar

Der Open Source Treiber für Nvidia heißt Nouveau. In einem Vortrag (von 2016?) habe ich erfahren, dass die Nouveau Entwickler kein Interesse haben auch einen Vulkan Treiber zu schreiben; sie haben schon genug an Nouveau zu tun, da alles von Nvidia reverse engineert werden muss.

Übrigens wenn ich von Treiber spreche meine ich immer die Userspace Bibliotheken und nicht die Kerneltreiber. So genau kenne ich mich mit den Innereien nicht aus, kann dir da also kein klares Bild von machen wie alles zusammenspielt, vorallem wie die proprietären Blobs von AMD und Nvidia funktionieren, keine Ahnung

Für Vulkan mit AMD oder Nvidia braucht man im Moment noch die propritären Treiber. Wobei man zum Lernen von Vulkan mit RADV bestimmt schon weit kommt. Mit halbwegs aktueller Intel CPU (Haswell++) brauchst du nicht mal eine dezidierte Grafikkarte. Ich würde empfehlen einfach mal ein bisschen mit der API herum zu spielen, wenn du kannst.
Mit

$ vulkaninfo | less

in der Konsole bekommst du Infos dazu, welche GPU von dir Vulkan-Ready ist oder nicht.

hustbaer

Bennisen schrieb:

Das klingt alles unglaublich gut. Fast zu schön um war zu sein.

Achherrjeh. Es ist nicht anders als bei OpenGL. Es hat bei OpenGL gut funktioniert. Wieso sollte es dann bei Vulkan nicht ... naja whatever.

Bennisen schrieb:

In der verlinkten Seite von Biolunar steht, dass Vulkan eine Low-Level API ist. Und, soweit ich das verstanden habe, bedeutet das, dass größenteils oder ganz auf Treiber verzichtet werden kann.

Es werden dadurch bestimmte Teile im Treiber nicht mehr benötigt. Wegfallen tun aber eher Teile die grösstenteils GPU-unabhängig implementiert werden können. Die ganzen GPU-abhängigen Sachen werden aber natürlich weiterhin benötigt.

Bennisen schrieb:

aber es gibt ja einen Open Source Treiber der aber nicht von Nvidia ist. Da Vulkan ja an sich dann leicht zu implementieren ist

Ach?

rapso

hustbaer schrieb:

Bennisen schrieb:

Das klingt alles unglaublich gut. Fast zu schön um war zu sein.

Achherrjeh. Es ist nicht anders als bei OpenGL.

klingt scho wie die erfindung vom feuer

OpenGl ist schon sehr alt und irgendwie scheint es für Entwickler auch nicht so attraktiv zu sein. Vulkan scheint ja da mehr Möglichkeiten zu bieten. Man kann jetzt noch wenig sagen, aber ich hoffe halt das Vulkan mehr Beachtung bekommt als OpenGL.

Würde halt gerne meine Spiele alle unter Linux spielen

hustbaer

Bennisen schrieb:

OpenGl ist schon sehr alt und irgendwie scheint es für Entwickler auch nicht so attraktiv zu sein.

OpenGL wurde (und wird) massiv verwendet. Hauptsächlich weil es sehr gut cross-Plattform verwendbar war (ist). Bloss nicht so sehr für Spiele.

Warum so wenig Spiele für Linux verfügbar sind hat andere Gründe, sicher nicht die paar Codezeilen die man für Linux und Windows wegen OpenGL oder Vulkan unterschiedlich schreiben muss.

Bennisen schrieb:

Vulkan scheint ja da mehr Möglichkeiten zu bieten.

Mehr Möglichkeiten würde ich nicht unbedingt sagen. Ne modernere API die einem weniger Klötze in den Weg legt wenn man gute Performance will. Aber möglich war mit den letzten OpenGL Versionen eigentlich auch sehr viel.
Dafür muss man bei Vulkan sehr viel selbst implementieren (bzw. von Middleware erledigen lassen) was einem OpenGL abnimmt -- der Preis den man für die bessere Performance zahlt. Ist aber bei den aktuellen D3D Versionen auch nicht anders.

dot

hustbaer schrieb:

Bennisen schrieb:

Vulkan scheint ja da mehr Möglichkeiten zu bieten.

Mehr Möglichkeiten würde ich nicht unbedingt sagen. Ne modernere API die einem weniger Klötze in den Weg legt wenn man gute Performance will. Aber möglich war mit den letzten OpenGL Versionen eigentlich auch sehr viel.

Genaugenommen könnte man sogar argumentieren, dass im Moment das Gegenenteil der Fall ist, denn Vulkan supported noch nichtmal die ganze Grafikpipeline. Transform Feedback fehlt z.B. (noch?)...

RHBaum

Ich glaub nicht das OpenGL und Vulkan wirklich alternativ zu sehen ist.

Der Overhead an Entwicklung und BoilerPlate Code bei Vulkan ist schon immens ...
Das ganze Tuning, aka wieviel Queue/Queue families mit welcher anbindung für welchen zweck hab ich, wird zum Anwender verlagert.

Klar, dafür ist die verantwortung für die Performance bei mir, man hat aber auch mehr möglichkeiten. Und man bekommt über die gleiche Schnittstelle das Thema GPU Computing gleich mit dazu ...

Aber richtig lohnen wird sich der Aufwand für kleinere Anwendungen, Demos, und Software, wo das ausreizen der Graka nicht im verdergrund steht, nicht wirklich.

Also ich denke das das Zielpublikum ein anderes ist.
Apps, Demos usw. dafür wirds weiterhin OpenGL geben.

Für größere Projekte, Spezial Render Engines / High performance Render Engines wird Vulkan sicher genug Vorteile liefern.

Oder es gibt halt doch mal die Super duper render engine die alle Anforderungen abdeckt, guenstig ist, nutzbare Lizenz besitzt ... und dann auf Vulkan setzt. Die würde dann vielleicht auch OpenGL ablösen ...

Sieht für mich so aus, dass man doch verschiedene Crossplatformelemente selbst programmieren muss.

Jein
Du musst halt oft Typen abfragen, was das system kann, und dann eine Instanz vom typ abstract erzeugen, die sich aber genau so verhält dir gegenüber wie die anderen, nicht verfügbaren typen von Instanzen ...

Dann bekommst du wieder Deteils in form von supported Operations bzw. Interfaces, auf was du reagieren musst. So baust du eigentlich plattform und hardware unabhaengigkeit nach.
Was früher mit #ifdef 's gmacht hasst, geht hier so

Klingt aber schlimmer als es ist .. und um HW performant zu nutzten, muesstest es soweiso machen ^^

Ciao ...

*rant*

Ich habe leider keinerlei Motivation, mich in Vulkan einzuarbeiten. Anfänglich war ich sehr begeistert, aber die Freude ist schnell verflogen. Es ist zwar immer die Rede von Cross Platform Support, aber wenn man genau hinschaut ist es eben leider nicht so rosig. Vulkan läuft genau auf Windows und einigen Androiden brauchbar. Für Linux gibt es wie immer keine offene, stabile, performante Treiber. Das wirkliche Problem liegt aber bei Apple, welche für die Verbreitung im Mainstream wesentlich wichtiger wären als Linux

Apple ist der grosse Betonklotz am Bein hier, da bereits OpenGL extrem stiefmütterlich behandelt (macOS unterstützt selbst heute nur OpenGL 4.1 von 2010) und Vulkan überhaupt nicht unterstützt wird auf deren Plattformen. Ich verstehe die Strategie hier schon seit langem nicht mehr. Sie pushen eine eigene Schnittstelle namens Metal, diese unterstützt aber bei weitem nicht dasselbe Feature-Level (braucht es auch nicht, da die Zielgruppe auf iOS und nicht macOS arbeitet). Vulkan und neuere OpenGL Spezifikationen werden ausgeschlossen. Als Entwickler auf macOS ärgere ich mich, dass ich OpenGL 4.1 verwenden muss, um die neusten auf dieser Plattform verfügbaren Features zu nutzen

Direct3D 12 und Vulkan sind meiner Ansicht nach interessant für extrem anspruchsvolle Grossproduktionen wie sie auf PC und früher macOS vorkommen. Auf Android sehe ich mangels Hardwareleistung nicht, wie sich Aufwand/Ertrag ausgleichen. Direct3D 12 wird problemlos überleben, da Microsoft gross genug ist und verschiedenste Plattformen damit bedienen kann (Xbox spielt hier eine grosse Rolle) und auch Innovation forciert. Vulkan für AAA Produktionen wiederum ist nur auf Windows brauchbar. Android hat die Hardware dafür nicht. macOS hat die Hardware (zumindest teilweise), aber kein Vulkan.

Wenn ich momentan Cross Plattform einen möglichst grossen Markt abdecken möchte, dann ist Vulkan nicht meine erste Wahl. Stattdessen sind wir noch immer bei OpenGL was im kleinsten gemeinsammen Nenner auch wirklich überall funktioniert. Oder man baut eine Engine, welche OpenGL als Fallback nutzt, bei Windows auf Direct3D 12 und bei Apple auf Metal setzt. Und bei der Komplexität von diesen neuen low-level APIs sind wir dann schnell bei der Frage: Selber programmieren oder Unreal Engine verwenden?

rapso

Ich verstehe deinen Frust, aber ich denke es ist ganz logisch von Apple Ihre eigene Platformen zu erstellen. Nur durch diversität lässt sich ein Vorteil erarbeiten. Wenn alles gleich ist, ist halt wirklich alles gleich. Apple kann linux nutzen, Microsoft kann linux nutzen. Alle nutzen Vulkan, aber weshalb sollte dann noch irgendjemand sich einen Mac oder iOS kaufen?

Alle predigen cross platform, wenn es ihnen nutzt. Microsoft macht ja jetzt auch bei linux mit, baut cross platforms Visual Studio (was erstaunlich gut ist fuer android/iOS deving). usw.
Aber das machen die nicht weil sie ihr Mindset veraendert haben, sie koennen halt frontal nicht gewinnen, also unterminieren sie den Feind. Wenn leute fuer OSX/iOS/Android/Linux weiter MS Office/Visual studio usw. nutzen, wird es irgendwann nur "sinnig" das auf windows zu tun. so jedenfalls die hoffnung.

Ich finde ehrlichgesagt, obwohl ich zZ kein Apple geraet nutze, dass ich lieber Apples "f**k the rest" bevorzuge als von den anderen konkurierenden firmen ihr "wir sind doch alle freunde" gerede. Ob Vulkan oder Metal oder D3D, das ist fuer die allermeisten programme wirklich unwichtig. Wenn jemand die Kunst beherrscht eine "next gen" API auszureizen, dann sollte er das 1% mehr investieren koennen um einen api-proxy fuer die anderen zu erstellen.
Wenn jemand nicht die Zeit/faehigkeit/usw. hat um eine next gen api auszureizen, dann wird das resultat mit opengl/d3d11 weitaus besser und stabiler sein. Man konkuriert immerhin mit firmen die jahrelang im treiber machen was jetzt vulkan/d3d12/metal entwickler tun sollen.

Deswegen, wenn dir gl 4.1 nicht reicht und du nur fuer apple entwickelst, versuch mal Metal. Das wird vermutlich nicht so schnell verschwinden und falls GL doch reicht, musst macht es nur sinn, dass du lieber was anderes machst als dich in vulkan/d3d12/metal einzuarbeiten. Time is limited.

RHBaum

@ /rant/
Versuch mal zu analysieren, was dein Prog, deine lib etc ... wirklich braucht um was aufm Bildschirm zu bringen.
Dann überleg ob doch nicht besser kommst, für 1-3 Varianten einen eigenen Pfad / modul zu erstellen.
Die Grakas generell funktionieren alle gleich, nur die API's dazwischen sind anders. Am Ende machst aber mit allen fast das selbe, nur anderen klassen / Typen.

Leider Gibts selbst für modernes OpenGL keine schlanke, linzenzrechtlich unbedenkliche, performante, moderne Engine.
Aus den selben Gründen wirds sicher auch für Vulkan so bald keine Engine mit obigen Kriterien geben.

Oder ich hab noch nichts gefunden ... wenn wer was kennt ...

Ciao ...