Registriert: Mi Apr 13, 2011 22:05 Beiträge: 218
Programmiersprache: Lazarus/FPC
Mal zu meinem Status: Also Ich tu mir unheimlich schwer mit Vulkan. Das ganze Erstellen und Definieren von Instanzen, Devices, Queues, Surfaces ect, bis das jetzt alles mal bugfrei funktioniert da bin Ich ne Woche dran gesessen und hab 3 verschiedene vulkan.pas - Header, Foren und Saschas Beispiele dabei durchgeeiert!! Und Ich seh noch nicht mal eine schwarze Fläche Kein Vergleich zu OpenGL von der Komplexität!
Aber hey, zumindest weiß Ich schon mal dass es Vulkan ist dass Ich da in meinem Programm anspreche und dass es meine GPU als vulkantauglich erkennt. Immer lächeln Ida
_________________ Ich teile manchmal heimlich durch Null. - Alber Einstein
Registriert: Di Mai 18, 2004 16:45 Beiträge: 2622 Wohnort: Berlin
Programmiersprache: Go, C/C++
Also bis man das erste 3eck in opengl 4.5 sieht schreibt man auch einige seiten code. Wenn man ein 3d 3eck mit rotation haben will wird der code gleich noch ein paar seiten länger. Wenn man von opengl 3.3 oder früher auf vulkan geht wird man natürlich ganz schön strapaziert
_________________ "Wer die Freiheit aufgibt um Sicherheit zu gewinnen, der wird am Ende beides verlieren" Benjamin Franklin
Registriert: Mo Sep 23, 2002 19:27 Beiträge: 5812
Programmiersprache: C++
Ida hat geschrieben:
Mal zu meinem Status: Also Ich tu mir unheimlich schwer mit Vulkan. Das ganze Erstellen und Definieren von Instanzen, Devices, Queues, Surfaces ect, bis das jetzt alles mal bugfrei funktioniert da bin Ich ne Woche dran gesessen und hab 3 verschiedene vulkan.pas - Header, Foren und Saschas Beispiele dabei durchgeeiert!! Und Ich seh noch nicht mal eine schwarze Fläche Kein Vergleich zu OpenGL von der Komplexität!
Aber hey, zumindest weiß Ich schon mal dass es Vulkan ist dass Ich da in meinem Programm anspreche und dass es meine GPU als vulkantauglich erkennt. Immer lächeln Ida
Man sollte sich halt vorher bewusst sein dass eine explizite API aufwendiger ist. Man entwickelt halt näher an der Hardware. Vulkan zielt auch eher auf Middleware, und nicht Hobbyentwickler. Wenn man einfach 3D machen möchte ist OpenGL immer noch die bessere Wahl. V.a. wenn die eigenen Anwendungen nicht so komplex sind dass sie durch die CPU limitieren.
Meine ersten Schritte damals als ich in das Advisory Panel eingeladen wurden waren aber ähnlich holprig. Nur gabs damals kein fertiges SDK, unfertige Doku und Betatreiber. Für mein erstes Dreieck hab ich auch über einen Monat gebraucht.
Registriert: Di Aug 26, 2003 20:08 Beiträge: 81 Wohnort: Mönchengladbach
Programmiersprache: ObjPas ASM C C++ etc
Sascha Willems hat geschrieben:
Wie sieht es eigentlich mit dem Rest der Tools aus? Werdet ihr auch die SPIR-V Tools übersetzen?
Ich bin da noch am überlegen, ob ich auf Basis von meinem CrossPascal ObjectPascal Compiler/Transpiler ( https://github.com/BeRo1985/crosspascal) eine pascalige Shadersprache erschaffen soll (wie fxPascal damals), oder ob ich auf Basis von meines GLSL Optimizers (welcher bereits Preprocessor, Parser mit AST-Erzeugung, AST-Optimierung und AST-zurück-zu-optimiertem-GLSL-Printer enthält) von meinem 64kb Intro Content Tool .marchfabrik einen eigenen (auch wenn erstmal (noch-)nicht-ganz-standard-konformen) GLSL-to-SPIR-V-Compiler bauen soll, oder ob ich eine komplett neue Shadersprache designen soll, etc.
Diesen Monat und nächsten Monat werde ich evtl. nicht dazu kommen, da ich momentan an meinem 64kb Intro für die Revision Demoparty arbeite und nebenbei auch noch die Slides für meinen Physik-Engine-Techtalk (zu https://github.com/BeRo1985/kraft) für die gleiche Demoparty vorbereiten muss.
_________________ Behindert ist man nicht, behindert wird man.
Registriert: Di Apr 29, 2008 18:56 Beiträge: 1213
Programmiersprache: Delphi/FPC
Sascha Willems hat geschrieben:
Wie sieht es eigentlich mit dem Rest der Tools aus? Werdet ihr auch die SPIR-V Tools übersetzen?
Ich wollte mich langsam an die Ganze Sache ran tasten und gucken wieviel deiner Beispiele ich dann übersetze. Wie schon beschrieben würde ich das dann alles in eine Einsteiger-Freundliche Klassen-Library packen. Woweit ich das verstanden hab ist SPIR-V ja das neue GLSL. Bis jetzt ist es geplant das ich mich dann auch mit den Shadern beschäftige wenn ich soweit bin.
Bleibt immer noch die Frage ob das überhaupt jmd nutzt. Ich arbeite zwar gern daran, aber wenn es dann keiner nutzt wäre es auch verschwendete Mühe...
Registriert: Mo Sep 23, 2002 19:27 Beiträge: 5812
Programmiersprache: C++
Bergmann89 hat geschrieben:
Sascha Willems hat geschrieben:
Woweit ich das verstanden hab ist SPIR-V ja das neue GLSL.
Nein, SPIR-V ist (dafür steht das I) ein binäre Sprache für graphische Shader (und Computekerne) , GLSL ist eine der möglichen Quellen aus denen SPIR-V erzeugt werden kann. Per Spec ist SPIR-V das einzige Eingabeformat dass ein Vulkan-Treiber versehen muss, wodurch die Notwendigkeit eines GLSL-Compilers im Treiber entfällt. Es teht aber letztendlich jedem frei seine eigen Shadersprache zu bauen, und die dann nach SPIR-V zu wandeln. Wenn man sich mal genauer mit SPIR-V beschäftigt, merkt man wie genial das eigentlich ist
Einige Hersteller (wie z.B. NVIDIA) erlauben das direkte Laden von GLSL über eine Extension, aber das sollte man nur während der Entwicklung nutzen.
Die unterschiedlichen GLSL-Compiler in den Treiber, und damit das Kompilieren vor Ort, waren ja eines der Hauptprobleme von OpenGL (ES), das gibt es mit SPIR-V nicht mehr, bzw. weit weniger kritisch.
D.h. ohne SPIR-V (eigentlich) kein Vulkan.
Wer die Tools nicht direkt im Quellcode nutzen will, kann aber den glslangvalidator benutzen, der GLSL nach SPIR-V wandelt. Das ist quasi der Referenzkompiler von Khronos. Nutze ich in meinen Demos auch.
Registriert: Di Aug 26, 2003 20:08 Beiträge: 81 Wohnort: Mönchengladbach
Programmiersprache: ObjPas ASM C C++ etc
Als kleine Randinfo:
FreePascal seit SVN Revision 33196 unterstützt auch nun hardfloat als Calling-Convention-Keyword, welches speziell u.A. für Vulkan unter Android/armv7a hinzugefügt wurde.
Mal schauen, ob Embarcadero bei ihrem Delphi NextGen Mobile Compiler da nachzieht, was ich aber nicht glaube, aus verschiedenen Gründen. Und vorallem arbeitet der Allen Bauer als letzter guter Compilerbauer dort auch nicht mehr bei Embarcadero.
Von daher überlege ich mir momentan, ob ich bei meinem Vulkan Header Kram den Delphi NextGen Mobile Compiler Support einfach ganz streichen sollte und dann komplett nur rein auf die Delphi Non-NextGen-Mobile Compiler und sowie auf FreePascal setzen sollte.
_________________ Behindert ist man nicht, behindert wird man.
Und vorallem arbeitet der Allen Bauer als letzter guter Compilerbauer dort auch nicht mehr bei Embarcadero.
Da sollte man erst einmal vorsichtig sein und dem neuen, jungen Chef bei Emba die Möglichkeit lassen, das in die richtigen Bahnen zu führen. Vllt wird es besser als mit Bauer.
Registriert: Mo Sep 23, 2002 19:27 Beiträge: 5812
Programmiersprache: C++
Bergmann89 hat geschrieben:
...bekomm ich beim Aufruf von vkCmdDrawIndexed eine SIGSEGV im Treiber (nvoglv32.dll DrvValidateVersion). Den Fehler hatte ich im Laufe der Implementierung schon öffters. Das lag meißtens an irgendwelchen Objekten die ich nicht richtig übergeben hatte (NULL-Objekt). Ich bin den Beispiel-Code nochmal durch gegangen und kann aber nichts finden was ich vergessen hätte. In meinem Projekt geht es um diese Zeile. Wäre super wenn wir das Problem zusammen lösen könnten, denn dann sollte man auch schon die ersten Bilder sehen können (endlich!).
Den Code habe ich mir im Detail noch nicht angesehen. Aber einer Exception im Treiber geht oft ein fehlerhaftes State Object voraus. Also z.B. falsches Binding, kein Descriptorset, etc.
Was sagt denn die Validierung? Bei mir war es bisher so dass ich über die Validierungslayer eigentlich immer alle Treibercrashes beheben konnte die von meiner Seite kamen.
P.S. : Wo wird denn (wenn überaupt) die Pipeline gebunden? Im Command buffer wird nur das descriptor set gebunden, und wenn ich das richtig sehe (Pascal + ganz viel withs ist irgendwie fies oO) wird im Command Buffer keine Pipeline gebunden, also ohne Pipeline gerendert. Evtl. liegts daran.
Edit : Ich nehme an BeginCommand (und EndCommand) wrappen die Vulkan-Funktionen? Wenn ja, gibt es da auch einen Overload um selbst eine CommandBufferBeginInfo zu übergeben? Z.B. für Inheritance Infos bei sekundären CommandBuffer.
Edit2 : Böse Falle :
Code:
if (err < VK_SUCCESS) then
raise TvkuErrorException.Create('unable to begin command buffer', err);
VK_SUCCESS == 0, alle Errocodes sind größer null (Fehlercodes < 0 sind i.d.R. Extensions vorbehalten, z.B. VK_NV_glsl_shader). Also unbedingt auf != VK_SUCCESS abragen.
Registriert: Di Apr 29, 2008 18:56 Beiträge: 1213
Programmiersprache: Delphi/FPC
Jap, die Pipeline war's. Hab ich gestern gar nicht bemerkt. Hab den Wald vor lauter Bäumen nicht mehr gesehen ^^
@Validierung: Kannte ich bis jetzt noch nicht, klingt aber nach nem echt guten Feature^^ Leider kommt bei mir immer ein VK_ERROR_LAYER_NOT_PRESENT sobald ich versuch auch nur einen der VK_LAYER_LUNARG_* zu aktivieren. Normalerweise muss ich die doch nur in der Instance- und Device-Create-Methode mit übergeben, oder?
@ErrorCodes: Ich hab mich an die Vulkan.xml gehalten und da steht folgendes:
Code:
<!-- Return codes for successful operation execution (positive values) -->
Registriert: Mo Sep 23, 2002 19:27 Beiträge: 5812
Programmiersprache: C++
Bergmann89 hat geschrieben:
@Validierung: Kannte ich bis jetzt noch nicht, klingt aber nach nem echt guten Feature^^ Leider kommt bei mir immer ein VK_ERROR_LAYER_NOT_PRESENT sobald ich versuch auch nur einen der VK_LAYER_LUNARG_* zu aktivieren. Normalerweise muss ich die doch nur in der Instance- und Device-Create-Methode mit übergeben, oder?
Das SDK muss installiert sein, und (unter Windows) muss die Umgebungsvariable "VK_LAYER_PATH" auf die für die Architektur passenden Layer-DLLs zeigen.
Bergmann89 hat geschrieben:
@ErrorCodes: Ich hab mich an die Vulkan.xml gehalten und da steht folgendes:
Sry,stimmt. Hab die Minuszeichen gestern übersehen. Ich würde aber trotzdem auf != VK_SUCCESS prüfen.
Registriert: Mo Sep 23, 2002 19:27 Beiträge: 5812
Programmiersprache: C++
Bergmann89 hat geschrieben:
Bevor ich jetzt aber weiter Energie und Zeit in das Projekt stecke würd ich gern wissen ob das überhaupt jemand nutzt, bzw. nutzen will. Ich denke der Anfang ist gemacht und es gibt eine solide Grundlage um in FPC mit Vulkan einzusteigen. Zugegeben ein wenig Doku fehlt noch, die mach ich bei Gelegenheit mal noch, aber ich denke das meißte ist selbst erklärend bzw. nichts anderes als in schon bekannten Tutorials. Soweit von mir. Wie gesagt, ein wenig Feedback wäre schön
Ich glaube das wird schwierig. Die Pascal Community ist ja inzwischen sehr überschaubar, und wenn man mal hier auf DGL schaut dann nutzen viele keine Pascal-Sprachen mehr für ihren 3D Kram. Ich würde auch nie wieder freiwillig zurück gehen wollen. Und Vulkan ist komplex und auch eigentlich nicht an Hobbyisten gerichtet, wird also eher in Middleware Verwendung finden. Wenn man "nur" 3D machen will dann ist man vorerst mit modernem OpenGL und AZDO besser dran weil man da nicht so viel falsch machen kann.
Aber evtl. würde es was bringen das Projekt mal außerhalb von DGL zu bewerben. Also auch mal den Quellcode irgendwo einstellen wo er eine größere Zielgruppe erreicht (als auf einem eigenen Repo). Z.B. github. Und dann was dazu als News auf Khronos oder zumindest in deren Forum.
Mitglieder in diesem Forum: 0 Mitglieder und 1 Gast
Du darfst keine neuen Themen in diesem Forum erstellen. Du darfst keine Antworten zu Themen in diesem Forum erstellen. Du darfst deine Beiträge in diesem Forum nicht ändern. Du darfst deine Beiträge in diesem Forum nicht löschen. Du darfst keine Dateianhänge in diesem Forum erstellen.