DGL
https://delphigl.com/forum/

Vulkan.pas
https://delphigl.com/forum/viewtopic.php?f=14&t=11484
Seite 2 von 3

Autor:  Ida [ Sa Feb 27, 2016 19:05 ]
Betreff des Beitrags:  Re: Vulkan.pas

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 :mrgreen:
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 :mrgreen: :mrgreen: :mrgreen:
Bild

Autor:  TAK2004 [ Sa Feb 27, 2016 19:14 ]
Betreff des Beitrags:  Re: Vulkan.pas

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 :)

Autor:  Sascha Willems [ Sa Feb 27, 2016 20:52 ]
Betreff des Beitrags:  Re: Vulkan.pas

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 :mrgreen:
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 :mrgreen: :mrgreen: :mrgreen:


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.

Autor:  Ida [ Sa Feb 27, 2016 21:44 ]
Betreff des Beitrags:  Re: Vulkan.pas

Sascha Willems hat geschrieben:
Für mein erstes Dreieck hab ich auch über einen Monat gebraucht.


Das kann Ich mir sehr gut vorstellen. :mrgreen:

Autor:  bero [ So Feb 28, 2016 00:03 ]
Betreff des Beitrags:  Re: Vulkan.pas

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.

Autor:  Bergmann89 [ So Feb 28, 2016 23:45 ]
Betreff des Beitrags:  Re: Vulkan.pas

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...

Autor:  Sascha Willems [ Mo Feb 29, 2016 13:37 ]
Betreff des Beitrags:  Re: Vulkan.pas

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.

Autor:  Bergmann89 [ Mo Feb 29, 2016 19:02 ]
Betreff des Beitrags:  Re: Vulkan.pas

OK, dann werden wir wohl nicht drum rum kommen die mit zu machen, wenn es was handfestes werden soll.

Autor:  bero [ Mo Mär 07, 2016 12:18 ]
Betreff des Beitrags:  Re: Vulkan.pas

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.

Autor:  Jens01 [ Mo Mär 07, 2016 13:19 ]
Betreff des Beitrags:  Re: Vulkan.pas

Zitat:
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.

Autor:  Sascha Willems [ So Apr 10, 2016 18:35 ]
Betreff des Beitrags:  Re: Vulkan.pas

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:
  1.   if (err < VK_SUCCESS) then
  2.     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.

Autor:  Bergmann89 [ Mo Apr 11, 2016 17:29 ]
Betreff des Beitrags:  Re: Vulkan.pas

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:
  1. <!-- Return codes for successful operation execution (positive values) -->
  2. <enum value="0"     name="VK_SUCCESS" comment="Command completed successfully"/>
  3. <enum value="1"     name="VK_NOT_READY" comment="A fence or query has not yet completed"/>
  4. <enum value="2"     name="VK_TIMEOUT" comment="A wait operation has not completed in the specified time"/>
  5. <enum value="3"     name="VK_EVENT_SET" comment="An event is signaled"/>
  6. <enum value="4"     name="VK_EVENT_RESET" comment="An event is unsignalled"/>
  7. <enum value="5"     name="VK_INCOMPLETE" comment="A return array was too small for the resul"/>
  8. <!-- Error codes (negative values) -->
  9. <enum value="-1"    name="VK_ERROR_OUT_OF_HOST_MEMORY" comment="A host memory allocation has failed"/>
  10. <enum value="-2"    name="VK_ERROR_OUT_OF_DEVICE_MEMORY" comment="A device memory allocation has failed"/>

Autor:  Sascha Willems [ Mo Apr 11, 2016 17:38 ]
Betreff des Beitrags:  Re: Vulkan.pas

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.

Autor:  Bergmann89 [ Mo Apr 11, 2016 18:15 ]
Betreff des Beitrags:  Re: Vulkan.pas

Okay, dann guck ich mal ob ich das mit dem SDK hin bekomm. Das mit dem ErrorCode mach ich auch noch. Auf alle Fälle hab ich erstma n Bild :) Danke!

Autor:  Sascha Willems [ Do Apr 14, 2016 17:15 ]
Betreff des Beitrags:  Re: Vulkan.pas

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.

Wenn die Bindings dann halbwegs stabil sind kann man die auch in den Resourcenbereich (https://github.com/KhronosGroup/Khronos ... api/vulkan) von Vulkan packen.

Seite 2 von 3 Alle Zeiten sind UTC + 1 Stunde
Powered by phpBB® Forum Software © phpBB Group
https://www.phpbb.com/