Vulkan API - Erfahrungsaustausch
- Guru
- Beiträge: 38
- Registriert: 04.03.2009, 20:48
- Alter Benutzername: Guru
- Echter Name: Rainer Schmidt
- Kontaktdaten:
Vulkan API - Erfahrungsaustausch
Hallo,
ich bin ja seit Jahren nur noch sporadisch mal dabei mich mit Grafik- und Spieleentwicklung zu beschäftigen. Meist sind es mehr experimentelle Sachen die ich einfach mal ausprobieren möchte.
Seit einiger Zeit setze ich mich mit der Vulkan API auseinander, bin aber aktuell noch nicht über das Tutorial hinausgekommen.
Ich stelle beim mitlesen hier fest, das einige noch mit DX arbeiten, ganz selten poppt mal OpenGL hoch aber die meisten arbeiten wohl mit fertigen Engines wie Unity etc.
Ist Vulkan für die "Schrauber" ;-) kein Thema? Falls es doch von dem ein oder anderen genutzt wird, würde mich interessieren wie eure Erfahrungen damit sind und bei den anderen, was euch davon abhält Vulkan statt einer anderen API zu nutzen.
Ich habe vor meine vergangenen 3D Engine Experimente mit der Vulkan API wiederzubeleben. Ob ich das zeitliche tatsächlich hinbekomme, weiss ich noch nicht, aber ich würde mich freuen hier den ein oder anderen zu finden mit dem man sich über diese API austauschen kann.
VG
Rainer
ich bin ja seit Jahren nur noch sporadisch mal dabei mich mit Grafik- und Spieleentwicklung zu beschäftigen. Meist sind es mehr experimentelle Sachen die ich einfach mal ausprobieren möchte.
Seit einiger Zeit setze ich mich mit der Vulkan API auseinander, bin aber aktuell noch nicht über das Tutorial hinausgekommen.
Ich stelle beim mitlesen hier fest, das einige noch mit DX arbeiten, ganz selten poppt mal OpenGL hoch aber die meisten arbeiten wohl mit fertigen Engines wie Unity etc.
Ist Vulkan für die "Schrauber" ;-) kein Thema? Falls es doch von dem ein oder anderen genutzt wird, würde mich interessieren wie eure Erfahrungen damit sind und bei den anderen, was euch davon abhält Vulkan statt einer anderen API zu nutzen.
Ich habe vor meine vergangenen 3D Engine Experimente mit der Vulkan API wiederzubeleben. Ob ich das zeitliche tatsächlich hinbekomme, weiss ich noch nicht, aber ich würde mich freuen hier den ein oder anderen zu finden mit dem man sich über diese API austauschen kann.
VG
Rainer
Star Citizen Referal Code: STAR-Q5ZK-P66D - 5000 UEC im Game für dich wenn dieser Code bei der Registrierung verwendet wird
CU in the verse
CU in the verse
- Krishty
- Establishment
- Beiträge: 8305
- Registriert: 26.02.2009, 11:18
- Benutzertext: state is the enemy
- Kontaktdaten:
Re: Vulkan API - Erfahrungsaustausch
Doch, total! Vulkan ist definitiv das langfristige Ziel für alle meine Projekte. Warum ich es trotzdem nicht benutze:
1. Riesen Portierungsaufwand für meine Spiele. Mein Flugsimulator läuft noch auf Direct3D 9; meine anderen Projekte auf 11. Auf Direct3D 12 bin ich mangels Windows 10 nie umgestiegen. Das bedeutet ein komplettes Neuschreiben meiner Renderer, und dafür habe ich gerade schlicht keine Zeit. Gameplay hat eh gerade Vorrang.
2. Eingeschränkte Verfügbarkeit für meine Tools. Meine kleinen Viewer usw. nutzen Direct3D 11, da es auf jedem Windows-PC seit Vista SP1 zur Verfügung steht (notfalls als Software-Emulation via WARP). Vulkan-Treiber sind für viele alte Systeme nicht verfügbar, Gerüchten zufolge vor allem für Linux-Systeme mit alten Grafikkarten, die via Wine zumindest D3D 11 schaffen, aber nie mehr Vulkan-kompatibel werden können. In dem Sektor würde mir mit Vulkan ein beträchtlicher Teil des Marktes wegbrechen, deshalb plane ich das nur für Neuentwicklungen oder Dinge, die eh einen High-End-PC voraussetzen.
- Schrompf
- Moderator
- Beiträge: 4996
- Registriert: 25.02.2009, 23:44
- Benutzertext: Lernt nur selten dazu
- Echter Name: Thomas
- Wohnort: Dresden
- Kontaktdaten:
Re: Vulkan API - Erfahrungsaustausch
Ich setze aktuell immer noch auf DX9 wegen meines Frameworks dafür. Für meinen Voxelscheiß will ich irgendwann mal Vulkan einsetzen, weil a) der hardwarehungrig genug ist, dass mich der Treibersupport alter Systeme nicht kümmert und b) ich beim Voxelscheiß zumindest mit dem aktuellen Renderer viel und oft Daten auf die GPU schaufeln muss, was ne heftige Verpflichtung wird, aber auch Performance bringen kann. Aber der Voxelkram liegt aktuell auf Eis, also hab ich da keinen Leidensdruck.
Früher mal Dreamworlds. Früher mal Open Asset Import Library. Heutzutage nur noch so rumwursteln.
- Guru
- Beiträge: 38
- Registriert: 04.03.2009, 20:48
- Alter Benutzername: Guru
- Echter Name: Rainer Schmidt
- Kontaktdaten:
Re: Vulkan API - Erfahrungsaustausch
Das Problem habe ich ja nicht, da meine Projekte aus Zeitgründen meist nie über das "Jugend forscht" Stadium hinausgekommen sind.Krishty hat geschrieben: ↑10.01.2020, 10:50 1. Riesen Portierungsaufwand für meine Spiele. Mein Flugsimulator läuft noch auf Direct3D 9; meine anderen Projekte auf 11. Auf Direct3D 12 bin ich mangels Windows 10 nie umgestiegen. Das bedeutet ein komplettes Neuschreiben meiner Renderer, und dafür habe ich gerade schlicht keine Zeit. Gameplay hat eh gerade Vorrang.
Ich hab den Umstieg von Windows nach Linux ja schon vor ein paar Jahren gemacht und habe ja auch schon zu meinen Win Zeiten versucht fast alles mit OGL und ohne Windows Abhängigkeiten hinzubekommen.Krishty hat geschrieben: ↑10.01.2020, 10:50 2. Eingeschränkte Verfügbarkeit für meine Tools. Meine kleinen Viewer usw. nutzen Direct3D 11, da es auf jedem Windows-PC seit Vista SP1 zur Verfügung steht (notfalls als Software-Emulation via WARP). Vulkan-Treiber sind für viele alte Systeme nicht verfügbar, Gerüchten zufolge vor allem für Linux-Systeme mit alten Grafikkarten, die via Wine zumindest D3D 11 schaffen, aber nie mehr Vulkan-kompatibel werden können. In dem Sektor würde mir mit Vulkan ein beträchtlicher Teil des Marktes wegbrechen, deshalb plane ich das nur für Neuentwicklungen oder Dinge, die eh einen High-End-PC voraussetzen.
Der Umstieg gilt auch für die Zockerei. Allerdings habe ich keine alte Hardware zuhause. Aktuelle laufen meine ganzen Systeme ohne Probleme mit den Mesa-Vulkan-Treibern.
Was auch sehr gut funktioniert ist Proton via Steam für Win-only-Gamses mit durchaus aktuellen Titeln wie Wolfenstein2. Die mappen ja generell die DX Aufrufe nach Vulkan.
Wie das mit älterer Hardware und den Mesa-Treibern aussieht kann ich leider nicht nicht sagen. Das Problem habe ich nicht.
Auf jeden Fall schön zu lesen das ich nicht der einzige bin der sich für Vulkan interessiert
Star Citizen Referal Code: STAR-Q5ZK-P66D - 5000 UEC im Game für dich wenn dieser Code bei der Registrierung verwendet wird
CU in the verse
CU in the verse
-
- Establishment
- Beiträge: 487
- Registriert: 01.03.2009, 19:09
Re: Vulkan API - Erfahrungsaustausch
Zu Vulkan direkt kann ich nicht viel sagen, wohl aber zu DX12 (was ja sehr sehr aehnlich ist).
Ich persoenlich halte Vulkan/DX12 fuer Hobbyprojekte ein wenig zu komplex, und man sollte sich sehr genau ueberlegen ob man es wirklich wirklich braucht. Es sei denn natuerlich man will es als Forsch- und Lernprojekt machen (das war meine Motivation).
Da ich deinen Wissensstand nicht genau kenne, versuche ich einfach mal meine persoenliche Erfahrung wiederzugeben.
Gruendsaetlich hat man mit Vulkan/DX12 viel mehr Freiheiten also mit OpenGL/DX11, ABER auch viel mehr Verantwortung. Viele Dinge die der Treiber bei den "alten" APIs gemacht hat muss man jezt selber machen. Ein Beispiel dafuer: Du bist selbst dafuer verantwortlich CPU und GPU zu synchronisieren und dass alle Daten da sind wenn die GPU sie braucht.
Damit man dass besser hinbekommt also OGL/DX11 sollte man:
1. Schon den einen oder anderen Renderer geschrieben haben und wissen wo die Bottlenecks sind
2. Gut verstehen wie die Grafikarte arbeitet.
mit einer trivialen Sync (z.B. einfach warten bis die aktuelle CommandList abgearbeitet ist wird man naemlich eher langsamer als schneller....) und der Vorteil den CPU overhead (der eh schon gering ist) zu verstecken in dem die GPU asynchron arbeitet ist dahin.
BTW: MultiGPU + Multithreaded Rendering verursacht maximal viele Konten im Gehirn (zumindest bei mir ;) ), sollte man aber von Anfang an beim Design im Hinterkopf haben wenn man es spaeter evtl mal einbauen will. Vor allem Multithreaded Rendering kann bei vielen darzustellenden Objekten hier nochmal einen gewaltigen Performanceboost bringen.
MultiGPU ist imo nur dann interessant wenn man wenig frameuebergreifenden Abhaengigkeiten hat, ansonsten bleibt nur profilen ob man damit wirklich schneller oder eher langsamer wird.
Der notwendige Quellcode (alleine fuer die Initialisation und das erste Dreieck) ist im Vergleich zu den alten APIs sehr sehr laenglich. Bedeutet man braucht ein gutes SW Design und eine gute Kapselung damit das ganze halbwegs uebersichtlich bleibt.
Ich selbst habe fuer mich als Ausgangspunkt die MiniEngine von den Microsoft Samples genommen (https://github.com/microsoft/DirectX-Gr ... MiniEngine). Die ist in meinem Source zwar mittlerweile kaum wiederzuerkennen aber man kann gut einige Ideen und Konzepte abgucken.
Ein Grossteil sollte auch relativ einfach nach Vulkan portierbar sein dass man bei den API aufrufen teilweise nur das dx durch vk ersetzen muss ;)
Ein Portieren eines vorhandenen OpenGL oder DX11 Rendereres ist nicht sinnvoll da man damit nichts erreicht ausser einer hoeheren Komplexitaet.
Wenn dann sollte man von 0 beginnen um die Vorzuege der neuen API nutzen zu koennen.
Speicherverwaltung ist nochmal ein ganz eigenes Thema. Solange der vorhandene Grafikkartenspeicher nicht ueberschritten wird ist alles relative easy. Sobald man da aber drueber kommt und der Treiber zu swappen anfaengt ist die Performance im Keller. Dann muss man ein kluges Speichermanagement einbauen. Fuer DX12 gibt es da ein paar ganz brauchbare Hilfsbibliotheken, fuer Vulkan ka, im Zweifel selber machen.
Ausserdem wichtig von Anfang an: Profilen, Profilen und nochmal Profilen. Damit man von Anfang an sieht wer wann auf wen wartet. Hat man die effiziente Sync erst einmal verhauen ist es nur mit sehr viel Aufwand und Kopfschmerz wieder zu reparieren.
Alles in allem finde ich DX12 trotzdem eine ziemlich gelungene API, die Komplexitaet liegt nicht in der API an sich sondern daran dass man jetzt viele Dinge selber machen muss die einem bisher der Treiber abgenommen hat, dafuer hat man auch mehr Kontrolle.
Um Grafikprogramierung an sich zu lernen bzw. zu verstehen wuerde ich weder DX12 noch Vulkan empfehlen sondern nach wie vor die alten APIs. Wenn man natuerlich Dinge wie Raytracing nutzen will oder wie Schrompf viele Daten zur GPU schaufeln muss kommt man an den neuen APIs kaum vorbei. Da sind aber Dinge fuer die es aus meiner Sicht bereits eine gewisse Erfahrung braucht bevor man sie angeht.
Warum ich kein Vulkan nutze sondern DX12: ka ich entwickle privat seit jeher nur auf Windows und hab keinen Bock auf Multiplatform von daher war DX12 fuer mich einfach naheliegender, einen anderen Grund gibt es nicht.
Das war mal was mir aus dem Kopf dazu eingefallen ist, vielleicht faellt mir spaeter noch mehr ein.
Ich hoffe ich habe dich jezt nicht entmutigt, aber die Lernkurve ist wirklich sehr steil wenn man noch wenig Erfahrung im Bereich Rendererprogrammierung hat und bietet hier leider viel Potenzial fuer einen hohen Frustrationsgrad.
Wenn du noch Fragen hast melde dich einfach.
Ich persoenlich halte Vulkan/DX12 fuer Hobbyprojekte ein wenig zu komplex, und man sollte sich sehr genau ueberlegen ob man es wirklich wirklich braucht. Es sei denn natuerlich man will es als Forsch- und Lernprojekt machen (das war meine Motivation).
Da ich deinen Wissensstand nicht genau kenne, versuche ich einfach mal meine persoenliche Erfahrung wiederzugeben.
Gruendsaetlich hat man mit Vulkan/DX12 viel mehr Freiheiten also mit OpenGL/DX11, ABER auch viel mehr Verantwortung. Viele Dinge die der Treiber bei den "alten" APIs gemacht hat muss man jezt selber machen. Ein Beispiel dafuer: Du bist selbst dafuer verantwortlich CPU und GPU zu synchronisieren und dass alle Daten da sind wenn die GPU sie braucht.
Damit man dass besser hinbekommt also OGL/DX11 sollte man:
1. Schon den einen oder anderen Renderer geschrieben haben und wissen wo die Bottlenecks sind
2. Gut verstehen wie die Grafikarte arbeitet.
mit einer trivialen Sync (z.B. einfach warten bis die aktuelle CommandList abgearbeitet ist wird man naemlich eher langsamer als schneller....) und der Vorteil den CPU overhead (der eh schon gering ist) zu verstecken in dem die GPU asynchron arbeitet ist dahin.
BTW: MultiGPU + Multithreaded Rendering verursacht maximal viele Konten im Gehirn (zumindest bei mir ;) ), sollte man aber von Anfang an beim Design im Hinterkopf haben wenn man es spaeter evtl mal einbauen will. Vor allem Multithreaded Rendering kann bei vielen darzustellenden Objekten hier nochmal einen gewaltigen Performanceboost bringen.
MultiGPU ist imo nur dann interessant wenn man wenig frameuebergreifenden Abhaengigkeiten hat, ansonsten bleibt nur profilen ob man damit wirklich schneller oder eher langsamer wird.
Der notwendige Quellcode (alleine fuer die Initialisation und das erste Dreieck) ist im Vergleich zu den alten APIs sehr sehr laenglich. Bedeutet man braucht ein gutes SW Design und eine gute Kapselung damit das ganze halbwegs uebersichtlich bleibt.
Ich selbst habe fuer mich als Ausgangspunkt die MiniEngine von den Microsoft Samples genommen (https://github.com/microsoft/DirectX-Gr ... MiniEngine). Die ist in meinem Source zwar mittlerweile kaum wiederzuerkennen aber man kann gut einige Ideen und Konzepte abgucken.
Ein Grossteil sollte auch relativ einfach nach Vulkan portierbar sein dass man bei den API aufrufen teilweise nur das dx durch vk ersetzen muss ;)
Ein Portieren eines vorhandenen OpenGL oder DX11 Rendereres ist nicht sinnvoll da man damit nichts erreicht ausser einer hoeheren Komplexitaet.
Wenn dann sollte man von 0 beginnen um die Vorzuege der neuen API nutzen zu koennen.
Speicherverwaltung ist nochmal ein ganz eigenes Thema. Solange der vorhandene Grafikkartenspeicher nicht ueberschritten wird ist alles relative easy. Sobald man da aber drueber kommt und der Treiber zu swappen anfaengt ist die Performance im Keller. Dann muss man ein kluges Speichermanagement einbauen. Fuer DX12 gibt es da ein paar ganz brauchbare Hilfsbibliotheken, fuer Vulkan ka, im Zweifel selber machen.
Ausserdem wichtig von Anfang an: Profilen, Profilen und nochmal Profilen. Damit man von Anfang an sieht wer wann auf wen wartet. Hat man die effiziente Sync erst einmal verhauen ist es nur mit sehr viel Aufwand und Kopfschmerz wieder zu reparieren.
Alles in allem finde ich DX12 trotzdem eine ziemlich gelungene API, die Komplexitaet liegt nicht in der API an sich sondern daran dass man jetzt viele Dinge selber machen muss die einem bisher der Treiber abgenommen hat, dafuer hat man auch mehr Kontrolle.
Um Grafikprogramierung an sich zu lernen bzw. zu verstehen wuerde ich weder DX12 noch Vulkan empfehlen sondern nach wie vor die alten APIs. Wenn man natuerlich Dinge wie Raytracing nutzen will oder wie Schrompf viele Daten zur GPU schaufeln muss kommt man an den neuen APIs kaum vorbei. Da sind aber Dinge fuer die es aus meiner Sicht bereits eine gewisse Erfahrung braucht bevor man sie angeht.
Warum ich kein Vulkan nutze sondern DX12: ka ich entwickle privat seit jeher nur auf Windows und hab keinen Bock auf Multiplatform von daher war DX12 fuer mich einfach naheliegender, einen anderen Grund gibt es nicht.
Das war mal was mir aus dem Kopf dazu eingefallen ist, vielleicht faellt mir spaeter noch mehr ein.
Ich hoffe ich habe dich jezt nicht entmutigt, aber die Lernkurve ist wirklich sehr steil wenn man noch wenig Erfahrung im Bereich Rendererprogrammierung hat und bietet hier leider viel Potenzial fuer einen hohen Frustrationsgrad.
Wenn du noch Fragen hast melde dich einfach.
Bevor man den Kopf schüttelt, sollte man sich vergewissern einen zu haben
- Guru
- Beiträge: 38
- Registriert: 04.03.2009, 20:48
- Alter Benutzername: Guru
- Echter Name: Rainer Schmidt
- Kontaktdaten:
Re: Vulkan API - Erfahrungsaustausch
Wow, danke für diese ausführliche Antwort :-)Matthias Gubisch hat geschrieben: ↑13.01.2020, 12:19 Zu Vulkan direkt kann ich nicht viel sagen, wohl aber zu DX12 (was ja sehr sehr aehnlich ist).
Ich persoenlich halte Vulkan/DX12 fuer Hobbyprojekte ein wenig zu komplex, und man sollte sich sehr genau ueberlegen ob man es wirklich wirklich braucht. Es sei denn natuerlich man will es als Forsch- und Lernprojekt machen (das war meine Motivation).
Da ich deinen Wissensstand nicht genau kenne, versuche ich einfach mal meine persoenliche Erfahrung wiederzugeben.
Ich bin ja schon lange dabei (zum Teil mit Riesenpausen) und habe durchaus meine Erfahrungen, allerdings wirklich auf reiner Experimentierbasis, mit OGL und SDL(2) inkl. div. kleiner Minigames. Mir fehlt auch tatsächlich die Zeit für mehr, leider. Aber wenn ich mit Hilfe von Vulkan Papers, Tutorials und Google irgendwann ein Texturierten Würfel mit der Maus drehen und weiß warum er das tut ;-) ist das erste Etappenziel erreicht.
Da ich zu 100% unter Linux unterwegs bin, hat sich DX12 für mich erledigt. Von daher freue ich mich auf meine Erfahrungen mit Vulkan.
Ich kann aktuell auch noch nicht sagen wie schnell ich voran kommen werde, aber sobald es was zu sehen gibt, kann ich den Fortschritt gerne mal hier dokumentieren :-)
Yep, das habe ich auch schon festgestellt :-)Matthias Gubisch hat geschrieben: ↑13.01.2020, 12:19 Der notwendige Quellcode (alleine fuer die Initialisation und das erste Dreieck) ist im Vergleich zu den alten APIs sehr sehr laenglich.
Freue mich auf die Herausforderungen die ich noch so antreffe ;-)
Star Citizen Referal Code: STAR-Q5ZK-P66D - 5000 UEC im Game für dich wenn dieser Code bei der Registrierung verwendet wird
CU in the verse
CU in the verse
- Schrompf
- Moderator
- Beiträge: 4996
- Registriert: 25.02.2009, 23:44
- Benutzertext: Lernt nur selten dazu
- Echter Name: Thomas
- Wohnort: Dresden
- Kontaktdaten:
Re: Vulkan API - Erfahrungsaustausch
Ich baue übrigens gerade das Vulkan-Tutorial auf vulkan-tutorial.com nach, weil ich für mein nächstes Experiment Compute Shader brauche. Mein DX9-basiertes Framework, dass mich über 15 Jahre lang begleitet hat, kommt da an seine Grenzen.
Für die ewigen Kombos aus vkGetSomething( &count), vkGetSomething( &count, dataArrayPtr) hab ich mir einen kleinen Template-Helfer geschrieben.
So ganz geht das leider nicht so fluffig, weil die vkMethoden alle ihre Zusatzparameter vor dem uint32_t*, vkData*-Parameterpaar haben. Wrapper für ein und zwei Zusatzparameter kann man ganz einfach als Wrapperfunktionen ausschreiben, die obige Funktion mit expliziten Template-Params aufrufen. vkMethoden ohne Zusatzparameter gehen nicht so, weil man für den ParamPack nicht explizit Keine Params angeben kann. Wenn man den stattdessen für "0 Parameter" weg lässt, denkt der Compiler, er müsste deducen, und scheitert an der Funktionssignatur des Callbacks. Trotzdem sehr praktisch.
Mal gucken, wann ich tatsächlich das erste Dreieck sehe.
Für die ewigen Kombos aus vkGetSomething( &count), vkGetSomething( &count, dataArrayPtr) hab ich mir einen kleinen Template-Helfer geschrieben.
Code: Alles auswählen
/// Checks the return code and bails out if not successful
#define CHECK_VULKAN_RESULT(res) if( res != VK_SUCCESS ) { \
throw std::runtime_error{"VulkanCall failed with error " + std::to_string(res)}; \
}
/// Enumeration helper: first gets the count of struct Content using the given function, then allocates space for it
/// and calls the function again to get all Content entries.
template <typename ReturnType, typename ContentType, typename... Params>
std::vector<ContentType> getVulkanArray( ReturnType (*func)(Params..., uint32_t*, ContentType*), Params... params)
{
uint32_t count{};
auto result = func( params..., &count, nullptr);
if constexpr (!std::is_same_v<void, ReturnType>)
CHECK_VULKAN_RESULT( result);
if( !count )
return {};
std::vector<ContentType> content( count);
func( params..., &count, content.data());
if constexpr (!std::is_same_v<void, ReturnType>)
CHECK_VULKAN_RESULT( result);
return content;
}
Mal gucken, wann ich tatsächlich das erste Dreieck sehe.
Früher mal Dreamworlds. Früher mal Open Asset Import Library. Heutzutage nur noch so rumwursteln.
-
- Establishment
- Beiträge: 487
- Registriert: 01.03.2009, 19:09
Re: Vulkan API - Erfahrungsaustausch
Ja das ist echt nervig.
Es gibt aber einen einfach Loesung.
die CPP bindings aus der vulkan.hpp
auto avialableLayers = vk::enumerateInstanceLayerProperties();
availableLayers ist dann ein std::vector des entsprechenen Typs
macht die sache relativ gut lesbar.
Einziger Wehmutstropfen: Ich habe noch nicht herausgefunden wie ich mit da selber um das error handling kuemmern kann.
Die werfen einfach immer ein exception wenn was schiefgeht.
Ansonsten finde bin ich nach den ersten gehversuchen geneigt meine Engine zu potieren,
Mittlerweile kann Vulkan Raytracing, und Mulitgpu support geht auch einfacher als in DX12...
Es gibt aber einen einfach Loesung.
die CPP bindings aus der vulkan.hpp
auto avialableLayers = vk::enumerateInstanceLayerProperties();
availableLayers ist dann ein std::vector des entsprechenen Typs
macht die sache relativ gut lesbar.
Einziger Wehmutstropfen: Ich habe noch nicht herausgefunden wie ich mit da selber um das error handling kuemmern kann.
Die werfen einfach immer ein exception wenn was schiefgeht.
Ansonsten finde bin ich nach den ersten gehversuchen geneigt meine Engine zu potieren,
Mittlerweile kann Vulkan Raytracing, und Mulitgpu support geht auch einfacher als in DX12...
Bevor man den Kopf schüttelt, sollte man sich vergewissern einen zu haben
-
- Establishment
- Beiträge: 487
- Registriert: 01.03.2009, 19:09
Re: Vulkan API - Erfahrungsaustausch
Je mehr ich mich mit Vulkan beschaeftige desto mehr bereue ich dass ich meinen Renderer auf DX12 aufgebaut habe und zu wenig auf Abstraktion geachtet habe.
Vulkan ist wesentlich angehmer zu nutzten (kein ComPtr mist und so)
Die Validation layer spucken brauchbare Fehlermeldungen aus,
SLI ist ueber PhysicalDeviceGroups quasi inclusive (so verstehen ich die Doku, mangels SLI System aber noch nicht getestet)
Vulkan ist wesentlich angehmer zu nutzten (kein ComPtr mist und so)
Die Validation layer spucken brauchbare Fehlermeldungen aus,
SLI ist ueber PhysicalDeviceGroups quasi inclusive (so verstehen ich die Doku, mangels SLI System aber noch nicht getestet)
Bevor man den Kopf schüttelt, sollte man sich vergewissern einen zu haben
- Schrompf
- Moderator
- Beiträge: 4996
- Registriert: 25.02.2009, 23:44
- Benutzertext: Lernt nur selten dazu
- Echter Name: Thomas
- Wohnort: Dresden
- Kontaktdaten:
Re: Vulkan API - Erfahrungsaustausch
Ich hatte tatsächlich auch DX12 erwogen, weil das Tooling und die Doku dafür zumeist viel besser sind. Aber COM ist sowas von 2005, das stößt mich ab. Und in Sachen Doku ist Vulkan echt mal gut dabei. Die Validation Layer sind extra cool - prüfen jeden Mist, den man sich wünschen kann, und im Steam-Build lässt man sie dann einfach weg. Coole Sache.
Ich hoffe, dass ich mit NVidia NSight auch ein gutes Mittel zum Debuggen und Profilen in der Hand habe. NSight war bislang echt super, solange es noch DX9 unterstützt hatte. Wenn der Vulkan-Support genauso rockt, bin ich hochzufrieden. Ansonsten halt RenderDoc.
Ich hoffe, dass ich mit NVidia NSight auch ein gutes Mittel zum Debuggen und Profilen in der Hand habe. NSight war bislang echt super, solange es noch DX9 unterstützt hatte. Wenn der Vulkan-Support genauso rockt, bin ich hochzufrieden. Ansonsten halt RenderDoc.
Früher mal Dreamworlds. Früher mal Open Asset Import Library. Heutzutage nur noch so rumwursteln.
-
- Establishment
- Beiträge: 487
- Registriert: 01.03.2009, 19:09
Re: Vulkan API - Erfahrungsaustausch
Nsight hab ich für Vulkan noch nicht getestet
Hatte ich zum letzten Mal zu dx9 Zeiten in der Hand.
Aber mit renderdoc bin ich bisher sehr zufrieden was das debugging angeht.
Hatte ich zum letzten Mal zu dx9 Zeiten in der Hand.
Aber mit renderdoc bin ich bisher sehr zufrieden was das debugging angeht.
Bevor man den Kopf schüttelt, sollte man sich vergewissern einen zu haben
- Schrompf
- Moderator
- Beiträge: 4996
- Registriert: 25.02.2009, 23:44
- Benutzertext: Lernt nur selten dazu
- Echter Name: Thomas
- Wohnort: Dresden
- Kontaktdaten:
Re: Vulkan API - Erfahrungsaustausch
Bin im Urlaub aufm Laptop. Ich habe dadurch gelernt, dass der offizielle Vulkan-Loader des SDKs mitnichten einfach nur einen Strauß Funktionszeiger aus ner DLL zieht. Sondern dass die Deppen sich irgendwelche Pfade in Registry-Keys speichern, um die Layer-DLLs und die nötigen Extensions-DLLs zu finden. Und damit verhindern sie ziemlich effektiv, dass ich den ValidationLayer einfach neben die Exe lege, solange ich ihn haben will, und die Extensions benutzt werden, die von NVidia im Treiber mitkommen. Was zur Hecke haben die sich dabei gedacht?
Mein Problem: ich hätte gerne eine Lösung, bei der ich das VulkanSDK einfach wie alle anderen Libs mit Headern, LinkerLibs und DLLs einchecken kann. Und dann soll das so ausgecheckte System auf einem beliebigen Rechner mit VisualStudio einfach bauen, linken und laufen, wie es die systemspezifische GPU hergibt. Wie mache ich das?
Ich habe mir mal den "volk" genannten VulkanLoader von GitHub gegriffen. Der Loader will aber auch wieder nur vulkan-1.dll laden, was nach meinem Verständnis eben jener oben genannte "offizielle" Loader ist, der seine dummen Registry-Moves abzieht. Was also tut der moderne dependency-bewusste Programmierer, wenn er Vulkan programmieren will?
Mein Problem: ich hätte gerne eine Lösung, bei der ich das VulkanSDK einfach wie alle anderen Libs mit Headern, LinkerLibs und DLLs einchecken kann. Und dann soll das so ausgecheckte System auf einem beliebigen Rechner mit VisualStudio einfach bauen, linken und laufen, wie es die systemspezifische GPU hergibt. Wie mache ich das?
Ich habe mir mal den "volk" genannten VulkanLoader von GitHub gegriffen. Der Loader will aber auch wieder nur vulkan-1.dll laden, was nach meinem Verständnis eben jener oben genannte "offizielle" Loader ist, der seine dummen Registry-Moves abzieht. Was also tut der moderne dependency-bewusste Programmierer, wenn er Vulkan programmieren will?
Früher mal Dreamworlds. Früher mal Open Asset Import Library. Heutzutage nur noch so rumwursteln.
-
- Establishment
- Beiträge: 487
- Registriert: 01.03.2009, 19:09
Re: Vulkan API - Erfahrungsaustausch
Das scheint in dem Offiziellen Loader nicht vorgesehen zu sein
Unter Windows werden Registry-Keys gescannt, unter Linux vordefinierte Verzeichnisse, wie das unter Mac ist weis ich nicht.
Ich hab irgendwann aufgegeben und einfach ueberall das Vulkan SDK installiert.
Wenn du eine Loesung findest, waere ich auch daran interessiert ;)
Akutell sehe ich nur den Weg einen eigenen Loader zu schreiben, aber so richtig Lust darauf habe ich da auch nicht.
Unter Windows werden Registry-Keys gescannt, unter Linux vordefinierte Verzeichnisse, wie das unter Mac ist weis ich nicht.
Ich hab irgendwann aufgegeben und einfach ueberall das Vulkan SDK installiert.
Wenn du eine Loesung findest, waere ich auch daran interessiert ;)
Akutell sehe ich nur den Weg einen eigenen Loader zu schreiben, aber so richtig Lust darauf habe ich da auch nicht.
Bevor man den Kopf schüttelt, sollte man sich vergewissern einen zu haben
- Schrompf
- Moderator
- Beiträge: 4996
- Registriert: 25.02.2009, 23:44
- Benutzertext: Lernt nur selten dazu
- Echter Name: Thomas
- Wohnort: Dresden
- Kontaktdaten:
Re: Vulkan API - Erfahrungsaustausch
Oh, ok, Danke. Dann lösch ich den ganzen "volk"-Kram hier und installier erstmal einfach das SDK. Große Kacke, aber ich will erstmal vorwärts kommen.
Der "offizielle" LunarX-VulkanLoader ist ja OpenSource. Vielleicht sollte ich den einfach mal klonen und modifizieren, dass er die DLLs im lokalen Verzeichnis sucht und die Registry in Ruhe lässt. Ich linke den ja eh schon statisch.
Der "offizielle" LunarX-VulkanLoader ist ja OpenSource. Vielleicht sollte ich den einfach mal klonen und modifizieren, dass er die DLLs im lokalen Verzeichnis sucht und die Registry in Ruhe lässt. Ich linke den ja eh schon statisch.
Früher mal Dreamworlds. Früher mal Open Asset Import Library. Heutzutage nur noch so rumwursteln.
- Schrompf
- Moderator
- Beiträge: 4996
- Registriert: 25.02.2009, 23:44
- Benutzertext: Lernt nur selten dazu
- Echter Name: Thomas
- Wohnort: Dresden
- Kontaktdaten:
Re: Vulkan API - Erfahrungsaustausch
So schaut's aus. Aber die API ist echt heftig. Extrem starr, das Ganze, und gleichzeitig heftig nebenläufig. Das wird noch ein bissl brauchen, eh ich damit produktiv Sachen auf den Screen kriege.
Früher mal Dreamworlds. Früher mal Open Asset Import Library. Heutzutage nur noch so rumwursteln.
-
- Establishment
- Beiträge: 426
- Registriert: 23.01.2013, 15:55
Re: Vulkan API - Erfahrungsaustausch
Die Vulkan-API ist schon recht sperrig, aber ich denke eig. das es in richtigem Anwendungscode nicht so ins Gewicht fällt. Man muss nur ein paar schlanke Hilfsfunktionen schreiben, um die üblichen Fälle zu vereinfachen. In OpenGL habe ich immer das Problem, das mir nicht klar ist an welchen Stellen ich State-Variablen zurückgesetzen soll und es gibt dann den sehr nervigen Bug, dass in bestimmten Code-Pfaden irgendein spezieller State noch verstellt ist. Mit den Vulkan Pipeline-State-Objekten kann das nicht passieren, da man ja in jeder Rendering-Komponente einfach einen eigenen völlig unabhängigen Pipeline-State aufmachen kann. Außerdem, wenn man mit OpenGL ein paare neuere Extensions einsetzen will, falls verfügbar, ist das extrem ätzend mit Hilfsfunktionen.
Ich muss aber zu geben, dass ich noch keine Vulkan-Praxiserfahrung mit Anwendungsentwicklung habe. Ich kenne die ganze API nur, da ich mal eine Zeit lang mit einem Vulkan-Treiber experimentiert habe, der Vulkan-Funktionen in entsprechende OpenGL-Aufrufe übersetzt.
Bezüglich den Registry-Keys: Kennst du die VK_LAYER_PATH-Umgebungsvariable? Wenn das nicht ausreicht, kann man auch ziemlich unproblematisch den ganzen Loader einfach selbst kompilieren und entsprechend patchen (z.B. ]hier oder hier).
Ich sehe in dem Loader einen der sehr großen Vorteile von Vulkan über OpenGL. Man kann ihn direkt der Anwendung linken und braucht nicht irgendwelche Closed Source Windows-Komponenten, GLEW, GLAD usw. Validation-Layers und andere Tools sind nett und da der Loader außerdem Vendor-unabhängig ist, kann man den Treiber wählen oder sogar parallel verwenden (z.B. Intel Chip und echte GPU). In OpenGL ist das meines Wissens leider komplett unmöglich.
Ich muss aber zu geben, dass ich noch keine Vulkan-Praxiserfahrung mit Anwendungsentwicklung habe. Ich kenne die ganze API nur, da ich mal eine Zeit lang mit einem Vulkan-Treiber experimentiert habe, der Vulkan-Funktionen in entsprechende OpenGL-Aufrufe übersetzt.
Bezüglich den Registry-Keys: Kennst du die VK_LAYER_PATH-Umgebungsvariable? Wenn das nicht ausreicht, kann man auch ziemlich unproblematisch den ganzen Loader einfach selbst kompilieren und entsprechend patchen (z.B. ]hier oder hier).
Ich sehe in dem Loader einen der sehr großen Vorteile von Vulkan über OpenGL. Man kann ihn direkt der Anwendung linken und braucht nicht irgendwelche Closed Source Windows-Komponenten, GLEW, GLAD usw. Validation-Layers und andere Tools sind nett und da der Loader außerdem Vendor-unabhängig ist, kann man den Treiber wählen oder sogar parallel verwenden (z.B. Intel Chip und echte GPU). In OpenGL ist das meines Wissens leider komplett unmöglich.
-
- Establishment
- Beiträge: 487
- Registriert: 01.03.2009, 19:09
Re: Vulkan API - Erfahrungsaustausch
Sieht doch schonmal gut aus ;)
Was genau meinst du mit starr? Ich finde die API ziemlich flexible weil man wirklich jeden Furz selber einstellen kann (bzw muss...)
Wenn man mal Buffer, Images(Texture) und paar Grundfunktionen fuer Layout Transition und SingleTime submit weggekapselt hat ist die Benutzung auch relativ uebersichtlich.
Ich kaempfe mich gerade durch ein Problem dass ich nicht verstehe…
3 Rechner (Laptop mit GeforceMX, Laptop mit ner Mobile Radeon und mein Desktop Rechner mit RTX2080 Super)
3x gleiche SDL2 Version,
3x gleiche Vulkan SDK Version
3x gleiche Windows SDK Version
beiden Nvidia Karten haben auch die gleiche Treiber Version.
Auf den beiden Laptops tut alles, auf meiner RTX2080 kracht meine Resize Routine beim neu erzeugen der SwapChain mit einer ValidationFailed exception weg ohne jegliche weitere Fehlermeldung aus den Validation Layern….
Sollte jemand eine Idee haben immer her damit ;)
Was genau meinst du mit starr? Ich finde die API ziemlich flexible weil man wirklich jeden Furz selber einstellen kann (bzw muss...)
Wenn man mal Buffer, Images(Texture) und paar Grundfunktionen fuer Layout Transition und SingleTime submit weggekapselt hat ist die Benutzung auch relativ uebersichtlich.
Ich kaempfe mich gerade durch ein Problem dass ich nicht verstehe…
3 Rechner (Laptop mit GeforceMX, Laptop mit ner Mobile Radeon und mein Desktop Rechner mit RTX2080 Super)
3x gleiche SDL2 Version,
3x gleiche Vulkan SDK Version
3x gleiche Windows SDK Version
beiden Nvidia Karten haben auch die gleiche Treiber Version.
Auf den beiden Laptops tut alles, auf meiner RTX2080 kracht meine Resize Routine beim neu erzeugen der SwapChain mit einer ValidationFailed exception weg ohne jegliche weitere Fehlermeldung aus den Validation Layern….
Sollte jemand eine Idee haben immer her damit ;)
Bevor man den Kopf schüttelt, sollte man sich vergewissern einen zu haben