Ich interessiere mich sehr für die Grafikprogrammierung am PC, daher
werde ich mich damit intensiv beschäftigen. Eigentlich wollte ich mit
OpenGL anfangen, aber dann habe ich gelesen, dass Vulkan der Nachfolger
von OpenGL ist. Es soll u.a. performanter sein aber auch komplexer als
OpenGL. Jetzt wollte ich mal hier im Forum Ratschläge/Meinungen
einholen.
Soll ich als Neuling auf dem Gebiet der Grafikprogrammierung lieber mit
OpenGL oder gleich mit Vulkan anfangen? Tutorials gibt es für beide
APIs. Meine Kenntnisse in C++ würde ich als fortgeschritten einstufen.
Beschreibe doch mal was du machen möchtest. Generell kann man heute
denke ich mit Vulkan anfangen, aber es erfordert bzw. Vermittelt mehr
Kenntnisse über Aufbau und Funktionsweise von Gpus.
OpenGL zieht einen mehr oder weniger großen Rattenschwanz an Altlasten
hinter sich her. Mordern ist das nicht.
Auch wenn du Tutorials findest wie z.B. von NeHe solltest du dich eher
in Richtung OpenGL 3.3 und Aufwärts orientieren. Alles drunter ist mit
Vorsicht zu genießen und als veraltet zu betrachten.
Es gab versuche das ganze zu verbessern, es ist auch besser geworden.
Aber es ist nicht gut geworden.
Ich würde die Empfehlen mit Vulkan anzufangen. Wenn du das verstanden
hast wirst du auch sehr schnell und leicht auf OpenCL migrieren können.
Wenn es Windows sein darf würde ich dir auch noch DirectX 10 oder 11
Empfehlen.
DirectX12 ist von der Mentalität her gesehen schon eher in Richtung
Vulkan angesiedelt.
Insgesamt kann man sagen, dass DirectX12, OpenCL und Vulkan mehr
Management der Details von dir verlangen. Wie z.B. Speicher anfordern,
zuweisen und kernels ausführen.
Aber dafür lernst du mehr und hast auch mehr Kontrolle.
Ich selber habe wenig Erfahrung mit DirectX11 gemacht, viel mit OpenCL,
wenig mit Vulkan und mittelmäßig mit OpenGL.
Danke Dennis für die ausführliche Antwort. Dann werde ich es wohl wagen
mit Vulkan.
@Martin: Spiele/Apps programmieren für PC und Smartphones/Tablets. Keine
aufwändigen Sachen die zwingend Vulkan erfordern würden.
Dennis R. schrieb:> OpenGL zieht einen mehr oder weniger großen Rattenschwanz an Altlasten> hinter sich her.
Genau das habe ich auch gelesen, das macht die Überlegung Vulkan zu
nutzen interessanter.
Hallo,
Marsmensch schrieb:> @Martin: Spiele/Apps programmieren für PC und Smartphones/Tablets. Keine> aufwändigen Sachen die zwingend Vulkan erfordern würden.
wieso dann nicht Unity oder Unreal Engine?
Modernes OpenGL, insbesondere das GLES subset, ist immernoch für die
meisten Anwendungen mehr als ausreichend, ist auf allen Platformen
verfügbar, inklusive Phones, und kann mit WebGL auch vom Browser aus
genutzt wersen. Es hat einige nachteile gegenüber vulken, speziell, dass
man nur einen Thread fürs rendering verwenden kann, und minimal mehr
overhead. Bei vulkan ist die initialisierung komplexer, und der
Hardwaresupport momentan noch geringer. Die grundlegenden Ablaufe sind
dann aber bei beiden die selben. Vulkan hat noch den Vorteil, dass es
etwas bessere mit OpenCL integriert, da es diesem von den APIs her sehr
änlich ist.
Marsmensch schrieb:> Gilt das mittlerweile nicht auch für Vulkan?
Ist im kommen. Gerade auf mobilen Plattformen wird Vulkan begrüßt, weil
es deutlich schonender mit der CPU umgeht aus ogl. Spart einfach Strom.
Wie so oft könnte man sich noch für Frage stellen, was erlernt werden
soll. 3d Grafik im allgemeinen oder eine API. VK bürdet dem Entwickler
viel Arbeit auf, die in klassischen APIs vom Treiber erledigt wird,
bietet dafür aber viele Vorteile in Form von Kontrolle, geringe CPU Last
und ganz wichtig: multithreading.
Ogl und dx11 sind weiter weg von der hw, erleichtern aber so manche
Sache. Der Trend scheint nicht zu sein, dass sich alle wie wild auf die
neuen APIs stürzen.
Falls du erst Mal lernen willst was man alles machen kann in der 3d
Grafik, würde ich eher mit ogl beginnen. Alternativ: 3dcenter.org. da
tummelt sich mancher Experte, inkl einem der Entwickler von Doom und
Wolfenstein 2.
Karl schrieb:> Wie so oft könnte man sich noch für Frage stellen, was erlernt werden> soll. 3d Grafik im allgemeinen oder eine API
Höchstwarscheinlich muss man sowieso irgendwann umsteigen, weil OpenGL
von Vulkan abgelöst wird. Dann macht es schon Sinn das neue zu lernen.
Ich habe ein sehr detailliertes Tutorial gefunden, da arbeite ich mich
jetzt mal durch. Da ich mit Grafik APIs bis jetzt nich nichts zu tun
hatte, würde ich den Mehraufwand gar nicht merken. Wenn es mir doch zu
komplex wird, versuche ich mich mal an OpenGL.
Marsmensch schrieb:> Höchstwarscheinlich muss man sowieso irgendwann umsteigen, weil OpenGL> von Vulkan abgelöst wird. Dann macht es schon Sinn das neue zu lernen.
Nein, Vulkan ist kein Ersatz für OpenGL. OpenGL ist eine ordentliche
Stufe über Vulkan, Vulkan ist mehr low-level. Aber halt mit allen Vor-
und Nachteilen.
Marsmensch schrieb:> Ich habe ein sehr detailliertes Tutorial gefunden, da arbeite ich mich> jetzt mal durch. Da ich mit Grafik APIs bis jetzt nich nichts zu tun> hatte, würde ich den Mehraufwand gar nicht merken.
Wirst du definitiv, wie schon gesagt wurde, musst du mit Vulkan
wesentlich mehr (langweiligen) Verwaltungsaufwand selbst machen. Bei
OpenGL macht das der Treiber für dich. Vergleiche mal den Code zum
Erstellen eines Graphikkontextes für Vulkan und OpenGL...
Fang lieber mit OpenGL an, du musst sowieso schon genug lernen, wie z.B.
Shaderprogrammierung, und solang du nicht an den Performancegrenzen
moderner Grafikkarten und CPUs stößt, bringt dir Vulkan eh nichts, aber
du hast wesentlich mehr Arbeit.
Christopher C. schrieb:> Fang lieber mit OpenGL an, du musst sowieso schon genug lernen
Ich habe mir jetzt das ganze Tutorial durchgesehen. Ich kanns fast nicht
fassen, 900 Codezeilen um ein Dreieck auf den Bildschirm zu bringen. Ok
das meiste davon hat mit der aufwändigen Initialisierung von Vulkan zu
tun. Aber das waren ja erst die Basics, wenn der Rest ähnlich
umfangreich ist, dann ist das in der Tat Momentan nichts für mich.
Wenn es dir ums Spieleentwickeln geht, bist du am besten mit einer
Gameengine bedient. Besonders Unity hat eine sehr flache Lernkurve und
bringt dich schnell zu tollen Ergebnissen.
Wenn du die Feinheiten der Grafikprogrammierung (aus wissenschaftlichem
Interesse) erlernen möchtest, führt wohl kein Weg an Vulkan vorbei ;-)
Borislav B. schrieb:> Wenn du die Feinheiten der Grafikprogrammierung (aus wissenschaftlichem> Interesse) erlernen möchtest, führt wohl kein Weg an Vulkan vorbei ;-)
Vielleicht vereinfacht Khronos Vulkan mit der Zeit auch wer weis. Oder
es wird für bestimmte Abläufe Abstraktionsbibliotheken geben.
Muss man bei Vulkan grundsätzlich so viel Codeaufwand betreiben oder
betrifft das immer nur den Initialisierungsteil und der renderingteil
ist dann nicht so umfangreich?
Zu OpenGL eine Frage noch. Macht es einen Unterschied ob ich mit Opengl
3.3 oder 4.x beginne? Glaube das "moderne" also das "core" OpenGL
beginnt ja ab 3.3. Die meisten Tutorials raten davon ab altes OpenGL zu
lernen.
Marsmensch schrieb:> Borislav B. schrieb:>> Wenn du die Feinheiten der Grafikprogrammierung (aus wissenschaftlichem>> Interesse) erlernen möchtest, führt wohl kein Weg an Vulkan vorbei ;-)>> Vielleicht vereinfacht Khronos Vulkan mit der Zeit auch wer weis. Oder> es wird für bestimmte Abläufe Abstraktionsbibliotheken geben.
Vereinfacht wird die API auf keinen Fall, dass würde dem Design von
Vulkan widersprechen. Was ich mir vorstellen kann ist, dass es in
Zukunft kein natives OpenGL mehr geben wird, sondern der OpenGL Treiber
nur noch ein Vulkan-Wrapper sein wird.
Marsmensch schrieb:> Muss man bei Vulkan grundsätzlich so viel Codeaufwand betreiben oder> betrifft das immer nur den Initialisierungsteil und der renderingteil> ist dann nicht so umfangreich?
Natürlich ist das nicht alles. Wie gesagt, mehr LowLevel, mehr
Möglichkeiten, aber auch mehr Verantwortung und Aufwand.
Marsmensch schrieb:> Zu OpenGL eine Frage noch. Macht es einen Unterschied ob ich mit Opengl> 3.3 oder 4.x beginne? Glaube das "moderne" also das "core" OpenGL> beginnt ja ab 3.3. Die meisten Tutorials raten davon ab altes OpenGL zu> lernen.
Nimm gleich 4.x und ein gescheides Buch. Zum Beispiel dieses
Standardwerk:
https://www.cs.utexas.edu/users/fussell/courses/cs354/handouts/Addison.Wesley.OpenGL.Programming.Guide.8th.Edition.Mar.2013.ISBN.0321773039.pdf
Marsmensch schrieb:> Zu OpenGL eine Frage noch. Macht es einen Unterschied> ob ich mit Opengl 3.3 oder 4.x beginne?
Hängt davon ab, ob du seltsame Grafikchips mit schlechten Treibern
unterstützen möchtest. Nicht alle Open-Source-Treiber können OpenGL 4
(oft aber ein mehr oder weniger großes Subset davon) und wirklich alte
Chips auch nicht. Mobilplattformen können sowieso kein OpenGL, sondern
nur GLES.
In wenigen Jahren wird Vulkan auf allen neuen Android-Geräten vertreten
sein müssen, bisher ist das noch nicht der Fall.
S. R. schrieb:> In wenigen Jahren wird Vulkan auf allen neuen Android-Geräten vertreten> sein müssen, bisher ist das noch nicht der Fall.
Muss man sich halt Hilfsbibliotheken bauen um Dinge die immer gleich
gemacht werden zu verstecken (Komplexität verstecken)
Nur so nebenbei gefragt welche Programmiersprache verwendest du? Ich
empfehle unbedingt C, Vulkan ist eine reine C-API.
C++ ist ohnehin viel zu kompliziert und viele Konzepte der Sprache sind
überflüssig, mit C sind deine Programme performanter da kein Overhead
generiert wird. Just my 5 cent.
cfreak schrieb:> Just my 5 cent.
What an Unfug.
Vulkan mag mit einer C-API kommen, aber die kann man problemlos aus C++
heraus benutzen. Nimm also, was du am besten kannst und nutze die
Features deiner Zielsprache, die dir einen Nutzen bringen.
Viel Erfolg.
Was ist denn eigentlich der Grund wieso OpenGL nur ein Thread zum
rendern nutzt?
Wird dieser Mangel in der Praxis von Gameengines irgendwie umgangen? Ist
also ein rendern mit mehreren Threads trotzdem möglich?
Kann doch nicht sein dass man quasi ein Vielfaches an Renderleistung
einfach nicht nutzt weil OpenGL nur ein Thread nutzt.
So als hätte man ein Auto mit einem 1000 PS Motor aber die Software des
modernen Autos würde Architektur bedingt nur 250 oder 500 PS rausholen.
So was bereinigt man doch sofort und wartet nicht Jahrzehnte bis eine
neue Software kommt, hm?
RenderZ schrieb:> Was ist denn eigentlich der Grund wieso OpenGL> nur ein Thread zum rendern nutzt?
Damit müssen weder der Grafiktreiber, noch die OpenGL-Bibliotheken oder
andere Teile des Render-Stacks reentrant sein. Außerdem ist die
Reihenfolge, in der Aufgaben an den Grafiktreiber übergeben werden,
eindeutig definiert (es gibt also keine Race-Conditions auf der Ebene).
RenderZ schrieb:> Kann doch nicht sein dass man quasi ein Vielfaches an Renderleistung> einfach nicht nutzt weil OpenGL nur ein Thread nutzt.
Es geht nicht um das Rendern, sondern um die Aufgabe von Render-Paketen
an den Grafiktreiber. Das Rendern - also den eigentlichen Aufwand -
übernimmt die Hardware selbst, damit ist der Performance-Verlust nicht
besonders groß.
Moderne Engines mit massiv vielen Threads müssen ihre Aufgaben
allerdings in Pakete bündeln und an einen (Render-)Thread weiterleiten,
was deren Architektur beschränkt und einen Schedulerschritt mehr
erfordert.
RenderZ schrieb:> So als hätte man ein Auto mit einem 1000 PS Motor aber die Software des> modernen Autos würde Architektur bedingt nur 250 oder 500 PS rausholen.
Nein. Das ist so, als hätte man ein Auto mit einem 1000 PS Motor, aber
nur einer Tür. Das Auto fährt trotzdem nicht langsamer, aber die Zeit
fürs Ein- und Aussteigen ist länger als nötig und erfordert zusätzliche
Regeln.
