OpenGL oder Vulkan lernen?



  • Hallo,

    Ich möchte gerne eine Grafik api lernen und frage mich, ob es sich noch lohnt OpenGL zu lernen oder gleich mit der neuen Vulkan api zu starten.

    Ich habe noch keinerlei Erfahrung mit Grafik api´s.

    Danke schonmal.



  • Ich würde erstmal OpenGL oder D3D9...11 lernen. So kannst du dich erstmal mit dem Rendering etc ... beschäftigen und musst dich nicht mit dem durch Vulkan bzw. D3D12 eingeführten Memory Management etc ... rumschlagen. Das gelernte kannst du dann, falls du dich dann doch mal mit Vulkan oder D3D12 beschäftigen willst ohne probleme übertragen, denn die Grundprinzipen sind, egal welche API du verwendest, immer die gleichen.

    Vulkan ist auf jeden Fall ein böses Biest und ist wirklich nur für "Experten" gedacht, die schon viel Erfahrung in diesem Bereich haben, und vorallem auch wissen, wie sie die neu gewonnen Freiheiten durch Vulkan auch richtig einsetzen können um einen Performanceboost zu erreichen.


  • Mod

    perfekte Antwort 👍



  • Vulkan ist so ein komplexes Biest, dass eigentlich nur Engineentwickler davon profitieren.
    Für alle anderen frisst es zu viel Zeit. Jemand der nur Spiele entwickeln will, kauft sich also besser die Engine oder bleibt bei OpenGL oder dem klassischen DirectX.

    Also wenn du nicht gerade für Crytek oder Epic Games usw. arbeiten willst, lerne vorerst erstmal OpenGL.



  • dass eigentlich nur Engineentwickler davon profitieren

    oder embedded entwickler, wo generische Ansätze wegen ressourcenknappheit ausfallen ... also wenn du was ganz spezielles auf ner bestimmten Hardware(Familie) so performant wie möglich laufen lassen willst.


  • Mod

    das ist eher keine zielgruppe. ganz spezielle dinge auf ganz spezieller hardware -> wird mit ganz spezieller API gemacht. (Oft am OS vorbei).

    Vulkan ist da eher zuviel overhead (weil es eben cross platform und nicht fuer eine hardware ist).



  • wird mit ganz spezieller API gemacht

    Ja klar, vor allem wenn die Anwendung der Sinn der HW ist.

    Ich dachte aber eher so an generische OS'e (Android, spezielles Linux) mit irgend einem dsp / graka drauf, und irgendwer, nicht der Hersteller, will damit max Performance rausholen. Und die openGL ES Profile sind für solche zwecke oft suboptimal ....



  • Also ich habe mal so ein paar Vulkan Tuts überflogen und das ist doch ziemlich komplex. Da vergeht mir am Anfang schon jegliche Lust weiter zu gehen. In dem Tut wird auch gleich mit C++ Templates gearbeitet und ich verstehe nur Bahnhof.

    Besser ich lasse die Finger von Vulkan. C++ ist ja übel genug für einen Einsteiger, aber Vulkan legt da noch eine Schippe drauf.

    Wer sich durch die Thematik duchqäalen möchte, hier der Link:
    https://vulkan-tutorial.com/Drawing_a_triangle

    Ich bin dann auch mal wieder weg von C++, man das ist echt übel im Vergleich zu anderen Sprachen.



  • Zee++ schrieb:

    Also ich habe mal so ein paar Vulkan Tuts überflogen und das ist doch ziemlich komplex. Da vergeht mir am Anfang schon jegliche Lust weiter zu gehen. In dem Tut wird auch gleich mit C++ Templates gearbeitet und ich verstehe nur Bahnhof.

    Besser ich lasse die Finger von Vulkan. C++ ist ja übel genug für einen Einsteiger, aber Vulkan legt da noch eine Schippe drauf.

    Wer sich durch die Thematik duchqäalen möchte, hier der Link:
    https://vulkan-tutorial.com/Drawing_a_triangle

    Ich bin dann auch mal wieder weg von C++, man das ist echt übel im Vergleich zu anderen Sprachen.

    Nun ja, bevor man in die Grafikprogrammierung mit C++ einsteigt ist es sicher sinnvoll erstmal C++ zu können.

    Das Tutorial scheint etwas mehr als "nur Vulkan" zu machen. Den Wrapper den die da bauen, den brauchst du nur wenn du ordentlich nach dem RAII Prinzip arbeiten willst. Und dazu verwenden die C++11 Sprachfeature, die einen C++ Anfänger vielleicht erstmal überfordern.
    Es gibt da bestimmt einfachere Tutorials, wobei ich aus meiner Erfahrung mit OpenGL sagen kann, Grafikprogrammierung ist halt nicht einfach, sondern schon fordernd.



  • Ja, ich bin da echt überfordert. C++ macht mich ab einem gewissen Level echt fertig. Ich finde es auch schwer zu lesen und schwer zu erkennen was da nun eigentlich passiert. Früher habe ich eine simple 3D-Grafikengine für den Amiga in Assembler geschrieben, das war wesentlich einfacher.


  • Mod

    Schlangenmensch schrieb:

    Das Tutorial scheint etwas mehr als "nur Vulkan" zu machen. Den Wrapper den die da bauen, den brauchst du nur wenn du ordentlich nach dem RAII Prinzip arbeiten willst. Und dazu verwenden die C++11 Sprachfeature, die einen C++ Anfänger vielleicht erstmal überfordern.

    Aber der Ratschlag kann wohl kaum lauten, das nicht von Anfang an sauber zu machen. Grundsätzliche Ressourcenverwaltung in C++ sollte man schon können, wenn man C++ benutzt. Das hat aber nichts mit Vulkan vs. OpenGL zu tun, sondern würde für beide gelten. Bringt einem schließlich nichts, wenn man aufgrund mangelnder Grundlagen irgendetwas schnell hin frickelt, das Ressourcen leckt ohne Ende und bei der kleinsten Änderung explodiert.

    Da muss man eben erst die Grundlagen der verwendeten Sprache lernen (Templates sind Grundlagen von C++!), und wie man allgemein Ressourcen sauber verwaltet (Das ist Grundlage jeder Programmierung!). Ganz besonders bei Vulkan, bei dem diese Aufgabe wieder verstärkt in den Händen des Programmierers liegt.

    Früher habe ich eine simple 3D-Grafikengine für den Amiga in Assembler geschrieben, das war wesentlich einfacher.

    War die denn auch technisch korrekt, dass sie keine Ressourcen geleckt hat? Ich behaupte mal, dass die Antwort Nein sein dürfte, du es aber bloß nicht bemerkt hast.



  • SeppJ schrieb:

    Aber der Ratschlag kann wohl kaum lauten, das nicht von Anfang an sauber zu machen.

    Das heißt es nicht. Aber das in einem Tutorial mit std::function, lamdas und delegating contructors zu implementieren ist schon 'ne Ansage. Das geht auch mit "alt bekannten" Sprachmitteln, auch wenn das dann nicht so nach "modernem c++" aussieht.

    Aber natürlich ist es keine Frage zwischen Vulkan oder OpenGL, dass gilt für beide. Meiner Meinung nach gilt auch für beide, dass sie nicht Anfängerfreundlich sind.


  • Mod

    Schlangenmensch schrieb:

    SeppJ schrieb:

    Aber der Ratschlag kann wohl kaum lauten, das nicht von Anfang an sauber zu machen.

    Das heißt es nicht. Aber das in einem Tutorial mit std::function, lamdas und delegating contructors zu implementieren ist schon 'ne Ansage. Das geht auch mit "alt bekannten" Sprachmitteln, auch wenn das dann nicht so nach "modernem c++" aussieht.

    Ahh, ok. Die Beschreibung klang so, als ob die Nutzung von RAII und Templates als zu fortschrittlich angesehen würde.



  • Eine naive D3D11/OpenGL Implementierung wird eine naive D3D12/Vulkan Implementierung von der Performance locker schlagen. Auf gamedev sind ab und zu mal Leute unterwegs die auf D3D12 umgestellt haben und dadurch einiges an Performance verloren haben.



  • SeppJ schrieb:

    Früher habe ich eine simple 3D-Grafikengine für den Amiga in Assembler geschrieben, das war wesentlich einfacher.

    War die denn auch technisch korrekt, dass sie keine Ressourcen geleckt hat? Ich behaupte mal, dass die Antwort Nein sein dürfte, du es aber bloß nicht bemerkt hast.

    Keine Ahnung ob die technisch korrekt war, was auch immer das zu bedeutet hat. Sie hat so funktioniert wie sie sollte. Da gab es kein Ressourcen-Management, die Ressourcen waren alle von Anbeginn im Speicher an festen Adressen. Da musste kein Speicher alloziert werden etc. Das war alles noch sehr unkompliziert zu programmieren.

    Ich wollte damit auch nur zum Ausdruck bringen, dass ASM + Software Rendering alles von der Pike auf selfmade mir früher extrem leichter fiel, als heute C++ und Vulkan oder OpenGL. Hat einfach mehr Spaß gemacht und das zählt unter dem Strich. Was soll ich Sachen machen die mir keinen Spaß machen?



  • Zee++ schrieb:

    ]Keine Ahnung ob die technisch korrekt war, was auch immer das zu bedeutet hat. Sie hat so funktioniert wie sie sollte. Da gab es kein Ressourcen-Management, die Ressourcen waren alle von Anbeginn im Speicher an festen Adressen. Da musste kein Speicher alloziert werden etc. Das war alles noch sehr unkompliziert zu programmieren.

    Naja, Technik entwickelt sich weiter. Ich habe zwar nie auf 'nem Amiga gearbeitet, aber wenn du dir heute einen Assembler nimmst und einfach Werte in eine feste Speicherstelle schreibst, stürtzt bestenfalls dein Programm ab. Heutzutagen laufen mehrere Anwendungen gleichzeitig auf dem Computer, die sich nicht in die Quere kommen dürfen. Dafür verwaltet dein Betriebssystem die Speicherbereiche, die für dich zur Verfügung stehen. Das ist unabhägig davon, welche Programmiersprache du verwendest, dass ist nur unterschiedlich abstrahiert.

    Und da ich mich auch schon mal ein bisschen mit Assembler auseinandergesetzt habe, fällt es mir schwer zu glauben, dass alles Selfmade für dich einfacher war (könntest du heute immer noch machen). Aber Menschen sind ja zum Glück unterschiedlich.



  • Ja klar, die Systeme sind komplexer geworden und dann brauch es auch solch Monstersprachen wie C++ um Herr der Lage zu werden. Was nicht heißt, dass in C++ nicht viel mehr Mist programmiert wird als andersherum. Dass immer nur auf die Lernenden zu schieben ist natürlich der Weg des geringsten Widerstands. Mir ist das im Endeffekt alles egal. Ich programmiere nur so zum Hobby, da ich in Rente bin und mir jeden Tag mit den Sachen fülle die mir Spaß machen.

    Vielleicht ist die Idee von dir aber nicht schlecht, einfach wieder für die alten Kisten was in Assembler zu machen, oder mich auf C und OpenGL zu beschränken. C++ und Vulkan kann man ja immer noch mal in Betracht ziehen falls das andere nicht gut für mich funktioniert.


  • Mod

    Vulkan und OpenGL sind ziemlich unabhängig von der benutzten Sprache. Du kannst super auch alles in Assembler machen (oder in C). Du wirst aber voraussichtlich folgende Dinge feststellen:
    * Mit den gestiegenen Ansprüchen ist auch alles sehr viel komplizierter geworden, auch - oder gerade erst recht - in low-level-Sprachen. Mit ein paar statischen Speicherbereichen kommt man eben nicht besonders weit. Sonst sieht's am Ende eben auch aus wie auf dem Amiga.
    * Die höherleveligen Sprachen versuchen dir viel von dieser Komplexität abzunehmen. Dynamische Ressourcenverwaltung ist in Assembler sehr viel anstrengender als z.B. in Python. Da passiert dann mehr oder weniger unsichtbar im Hintergrund, was dich in Assembler viel Mühe kostet.
    * Am Ende fährt man aber meistens am besten mit der Sprache, die man am besten beherrscht. Wenn du Assembler besser als C++ kannst, ist klar, dass die Assembler einfacher vorkommt und du bessere Ergebnisse erzielen wirst.
    * Deine Ergebnisse in Assembler werden aber voraussichtlich sehr viel bescheidener Aussehen, als die von irgendeinem anderen Programmierer, der genau so gut ist wie du, dabei aber eine höher-levelige Sprache benutzt, bei der er weniger Denkarbeit auf unnötige Details aufwenden muss.



  • Schlangenmensch schrieb:

    SeppJ schrieb:

    Aber der Ratschlag kann wohl kaum lauten, das nicht von Anfang an sauber zu machen.

    Das heißt es nicht. Aber das in einem Tutorial mit std::function, lamdas und delegating contructors zu implementieren ist schon 'ne Ansage. Das geht auch mit "alt bekannten" Sprachmitteln, auch wenn das dann nicht so nach "modernem c++" aussieht.

    Der Code aus diesem Tutorial gehört auch zum grottigsten C++, das mir in letzter Zeit so untergekommen wäre. Das Ganze ließe sich einfach mit std::unique_ptr und custom Deleter lösen und fertig; da braucht es weder einen dermaßen selbst-hingekotzten Smartpointer noch Lambdas, delegating Constructors, std::function oder dergleichen...



  • Ja und als Anfänger hat man keine Chance gutem vom schlechtem C++ Code zu unterscheiden.

    @SeppJ
    Logisch, es wurde mehr Abtraktionsebenen erschaffen um dem Entwickler die Arbeit mit dem Komplexen einfacher zu machen. Nur scheint mir C++ zu versuchen eine hohen Abstraktion mit LowLevel zu vermischen, was auch meiner Sicht schwer möglich ist.

    Mir ist auch klar, dass jemand mit gleichem Produktions-Aufwand in C++ die besseren Ergebnisse erzielt(Wenn es einer der wenigen ist der C++ wirklich kann). Was für mich zählt ist nicht wie technisch korrekt oder effektiv ich programmiere, sondern wie viel Spaß mir die Sache macht.


Log in to reply