OpenGL: Ich komme langsam in der Moderne an.. Aber wie modern darfs sein und was macht den Unterschied?



  • Nabend!
    Mit OpenGL 1.1 bin ich inzwischen grob durch, darum gehts nun langsam in Richtung 'modernes OpenGL'.. Eigentlich interessiert mich besonders GLSL! Damit habe ich mich aber quasi noch garnicht auseinandergesetzt..
    Kann man eigentlich klassische und moderne Features zusammen nutzen??

    Mal angenommen ich lade mir mit GLEW alle aktuellen OpenGL-Funktionen.. Oder sagen wir mal alle für v3.3.
    Wenn ich mich nun entscheide nur mit OGL 2.1/GLSL 1.2 zu arbeiten, also nur die Funktionen nutze, die in den 2.1-Specs vorkommen..
    ..Kann ich dann sicher sein, dass die jew. Funktion auch funktioniert?!
    (Kann ich auch OGL v2.1 und GLSL v1.1 nutzen (oder umgekehrt)? Und wenn ja, habe ich überhaupt was davon?!)

    Also es könnte ja sein, dass eine Funktion, die es schon in v2.1 gab, für v3.3 aktualisiert wurde. Und darum dann nicht mehr in v2.1 läuft..
    Ist das so? Oder muss ich mir darum keine Gedanken machen, solange ich nur Funktionen aus der Version nehme, auf die ich abziele?
    Also anders: Wenn ich mit v3.3 arbeiten möchte und nur eine Funktion aus v4.x nehme, hat dann mein komplettes Programm v4.x ?

    Und alles nochmal umgekehrt (so modern bin ich noch nicht):
    ..Es wird zwar immer vom deprecated_mode geredet, aber das habe ich nicht ganz durchblickt..
    Was passiert im Treiber, wenn ich den Modus deaktiviere? Werden dann einfach alle alten Funktionen nicht "in C++" geladen?? Ist das dann letztlich eher eine Aufgabe von GLEW??

    Und noch eine letzte Frage dazu (die eigentlich alle vorigen klären kann):
    Wie sieht das eigentlich im Treiber aus? -Gibt es dort für jede OGL-Version eine eigene Sektion mit den entsprechenden Funktionen der Version, oder gibt es jede Funktion nur 1mal ??
    ...Und wie passen da Extensions rein..? Ist das, was ich in v1.5 noch als Extension laden musste, in v2.1 aber schon im Core ist, eigentlich das Gleiche?

    Nur falls sich jemand fragt, was ich überhaupt vor habe:
    Ich möchte meinen Code auf sovielen Rechnern wie möglich zum laufen bringen, aber auf sowenig Funktionalität wie möglich verzichten!
    Also was ist besser: Z.B. OGL v1.5 + Extensions, oder v2.1 ohne Extensions?? Oder macht es keinen Unterschied, weil die Funktionen eh identisch sind?

    Wie geht ihr dieses Problem an?

    Ach ja, als wären's nicht schon genug Fragen.. Gibt es irgendein bahnbrechendes Feature das jew. für OGL 2.1 statt 1.5, oder für v3.3 statt 2.1 spricht?
    Ich denke, sowas kann man nur beantworten, wenn man schon damit gearbeitet hat..

    Sooo, das wars auch schon wieder, mit meinem Fragenkatalog... ...aber alles zu einem Thema - mehr oder weniger.

    Gruß
    OpenGl-Fifi


  • Mod

    OpenGl-Fifi schrieb:

    Kann man eigentlich klassische und moderne Features zusammen nutzen??

    bis 3.2 oder so wurde alles alte immer behalten.

    Mal angenommen ich lade mir mit GLEW alle aktuellen OpenGL-Funktionen.. Oder sagen wir mal alle für v3.3.
    Wenn ich mich nun entscheide nur mit OGL 2.1/GLSL 1.2 zu arbeiten, also nur die Funktionen nutze, die in den 2.1-Specs vorkommen..
    ..Kann ich dann sicher sein, dass die jew. Funktion auch funktioniert?!

    wieso sollten funktionen nicht funktionieren? (wenn wir bugs usw. ausschliessen). Ich glaube es ist nicht wirklich klar was du meinst.

    (Kann ich auch OGL v2.1 und GLSL v1.1 nutzen (oder umgekehrt)? Und wenn ja, habe ich überhaupt was davon?!)

    2.1 ist eine erweiterung von 1.1, wenn du 2.1 nutzt, nutzt du 1.1 automatisch.

    Also es könnte ja sein, dass eine Funktion, die es schon in v2.1 gab, für v3.3 aktualisiert wurde. Und darum dann nicht mehr in v2.1 läuft..
    Ist das so? Oder muss ich mir darum keine Gedanken machen, solange ich nur Funktionen aus der Version nehme, auf die ich abziele?
    Also anders: Wenn ich mit v3.3 arbeiten möchte und nur eine Funktion aus v4.x nehme, hat dann mein komplettes Programm v4.x ?

    wenn du das compatibility profile nutzt, dann sollte alles noch gehen.

    Und alles nochmal umgekehrt (so modern bin ich noch nicht):
    ..Es wird zwar immer vom deprecated_mode geredet, aber das habe ich nicht ganz durchblickt..
    Was passiert im Treiber, wenn ich den Modus deaktiviere? Werden dann einfach alle alten Funktionen nicht "in C++" geladen?? Ist das dann letztlich eher eine Aufgabe von GLEW??

    der mode heisst 'compatibility' und den musst du erst einschalten. der treiber bietet eine c schnittstelle, opengl ist nur c. glew nutzt nur den normalen extension mechanismus um alles bekannte zu laden falls es vorhanden ist. Potentiel musst du immer davon ausgehen, dass etwas nicht vorhanden ist. In openGL ES sind z.b. in den emulatoren fuer Desktop oft funktionen nicht vorhanden die auf der echten hardware existieren (z.b. glMap/glUnmap im Adreno SDK).

    Und noch eine letzte Frage dazu (die eigentlich alle vorigen klären kann):
    Wie sieht das eigentlich im Treiber aus? -Gibt es dort für jede OGL-Version eine eigene Sektion mit den entsprechenden Funktionen der Version, oder gibt es jede Funktion nur 1mal ??

    die implementation ist jedem Treiberhersteller komplett ueberlassen, das definiert der standard nicht. Der Standard definiert nur die Schnittstelle.

    ...Und wie passen da Extensions rein..? Ist das, was ich in v1.5 noch als Extension laden musste, in v2.1 aber schon im Core ist, eigentlich das Gleiche?

    auf windows schon, da wird nur 1.2 oder so supported, alles darueber hinaus wird mittels extensions angeboten, deswegen brauchst du GLEW.

    Nur falls sich jemand fragt, was ich überhaupt vor habe:
    Ich möchte meinen Code auf sovielen Rechnern wie möglich zum laufen bringen, aber auf sowenig Funktionalität wie möglich verzichten!
    Also was ist besser: Z.B. OGL v1.5 + Extensions, oder v2.1 ohne Extensions?? Oder macht es keinen Unterschied, weil die Funktionen eh identisch sind?

    opengl v2.1=opengl v1.5+extension. das duerfte wohl alles beantworten, oder?
    Opengl ist wie ein formelbuch mit immer neuen auflagen, da kommen hinten immer neue kapitel dazu und zwischendurch ergaenzungen (z.B. neue formate fuer texturen) aber es bleibt lange gleich. mit Core vs Compatibility modes hat man nach 2000Jahren zauberei und voodoo rausgenommen und von elle+fuss auf meter umgestellt.

    Wie geht ihr dieses Problem an?

    ich nutze immer das kleinste was noetig ist. Mehr als noetig ist->wozu? weniger als noetig ist -> dann gehts ja nicht.

    Ach ja, als wären's nicht schon genug Fragen.. Gibt es irgendein bahnbrechendes Feature das jew. für OGL 2.1 statt 1.5, oder für v3.3 statt 2.1 spricht?
    Ich denke, sowas kann man nur beantworten, wenn man schon damit gearbeitet hat..

    GL 2 hat glaube ich shader eingefuehrt, vorher war es kein standard, sondern pro platform eine extension. GL 3 hat glaube ich deprecation eingefuehrt, es kann sein dass eine platform die GL 3 support hat, keinen compatibility mode hat, also auch kein opengl 2 oder 1 zulaesst.



  • Und da OpenGL einen kompletten Neuanfang vor hat(OpenGL NG), dafst du bald wieder alles alte vergessen.



  • Enter OpenGL NG, which will be a ground-up redesign of OpenGL that isn’t backwards compatible.

    http://www.extremetech.com/gaming/187796-opengl-4-5-released-next-gen-opengl-unveiled-cross-platform-mantle-killer-dx12-competitor



  • Also ich habe mich jetzt nochmal kreuz und quer durchs Netz gelesen und auch dank deiner außführlichen Beantwortung hier, glaube ich es endlich verstaden zu haben. Naja weitestgehend..

    Ich bin wieder beim manuellen Laden von Funktionen. Dabei sind mir dann doch noch ein paar Fragen aufgekommen..

    In den Beispielen, die ich dazu gefunden habe, wird erst nach dem Extension-Namen gesucht (z.B. GL_EXT_CONVOLUTION) und falls vorhanden, werden dann die entsprechenden Funktionen geladen.
    Jetzt ist aber GL_EXT_CONVOLUTION seit v1.2 Teil vom GL_ARB_IMAGING; oder ein GL_ARB_... wandert in den Core..
    Bedeutet das, dass mein altes Programm, welches nach GL_EXT_CONVOLUTION sucht nichtmehr funktioniert, da der String ja nun verschwunden ist?!
    Ich sehe es doch richtig, dass alle GL_ARB_... (GL_EXT_... sowieso) garkeine Core-Funktionen enthalten, sondern eben nur ARB-Extentions?!
    Da es aber oft vorkommt, dass Extensions in den Core wandern, müsste es doch haufenweise Programme geben, die nichtmehr funktionieren, einfach weil der GL_EXT_..- oder GL_ARB_...-String fehlt! Das wäre mir bisher allerdings nicht aufgefallen. Also was machen die Programmierer anders, sodass ihre Programme noch laufen??

    Was hat man beispielsweise mit dieser Funktion gemacht, damit das Programm auch in Zukunft läuft?
    Erst kam glBlendEquationEXT(), wurde dann zu glBlendEquationARB() und ist nun glBlendEquation(). ...Die Enums sind im schlimmsten Fall auch alle verschieden, mal mit ..EXT im Namen, mal ohne etc..
    Sehe ich das richtig: Entweder ich nehme extra die glBlendEquationARB()-Funktion, damit mein Code auch mit OGL-Versionen läuft, die diese Funktion noch nicht im Core haben, aber eben hoffentlich als Extension..
    Oder ich nehme nur Core-Funktionen wie glBlendEquation(), damit ich mir sicher sein kann, dass die auch in zukünftigen Versionen noch vorhanden sein wird (notfalls in irgendeinem compatibility-mode)..
    Zusammengefasst also entweder auf alte OGL-Versionen + Extensions abzielen und hoffen, dass die Extensions lange unverändert bleiben. Oder auf eine neuere Mindestversion abzielen und wissen, dass die Funktionen auch zukünftig noch funktionieren, dafür eben nicht mit alten Versionen... !?

    Was für ein Durcheinander... So gesehen hat der Neuanfang mit OpenGL-NG auch was gutes.. ..Zumindest für Spiele-Entwickler, die nicht großartig auf alte Hardware rücksicht nehmen wollen.. ..Wobei man mit dieser Einstellung auch jetzt schon keine Probleme hat..
    Tja, auf andere Rücksicht zu nehmen ist eben der Fehler schlechthin... Gewissens- und Versionskonflike vorprogrammiert.. 😉
    Dass sich auch alles immer so rasant weiterentwickeln muss, gerade im Informatik-Bereich. Da fängt man mit OpenGL 1.1 an (1997) und haste nicht gesehen, schon veraltet...

    ... that isn’t backwards compatible.

    Was meinen die eigentlich mit abwärts-kompatibel?! Sobald eine Funktion in eier neuen Version nichtmahr vorhanden ist (sei es nur wegen eines neuen Namens), bzw. sobald die alte Version nicht komplett eine Teilmenge der neuen ist, ist die neue Version doch auch nicht mehr abwärts-kompatibel..
    So gesehen, ist das doch seit v1.2 nichts neues...

    Das ist das was mich am meisten verwirrt: Einerseits wird vieles aus alten Versionen mitgeschleppt, andererseits wird aber manches auch weggelassen (bzw inkompatibel abgeändert). Kann mir mal jemand sagen, was das soll???
    Aus meiner Sicht sieht das aus wie ein einziger Brei aus altem und neuem ,gerade weil man alle Funktionen, die nicht zu OGL v1.1 gehören separat laden muss.
    Sehe ich es richtig, dass darum der compatibility-mode eingeführt worden ist. Also um das besser zu trennen?!
    Wenn ja, warum hat man das dann nicht schon früher so gemacht??

    Und noch was anderes: Da ich eigentlich immer auf eine Funktion stoße, die ich brauchen könnte und nicht auf eine Extension (also z.B. GL_ARB_...): Gibt es irgendwo eine Auflistung, welche Extension zu welcher Funktion gehört (nicht welche Funktion zu welcher Extension), z.B. "glXyz -> GL_ARB_ASD" ??? Die können doch nicht von einem erwarten, dass man alle Extensions auswendig kennt, um dann sagen zu können: "Ach das ist Funktion glXyz. Na klar, die ist in GL_ARB_ASD vorhanden."
    So wie ich das sehe, brauche ich den Namen der Extension, um dann nachzusehen, welche Enums dazu gehören, oder etwa nicht?!
    Außerdem würde mich ja auch interessieren, welche OGL-Version (oder je nach dem, welche Extension) ich dann nutze, wenn ich mit Funktion glXyz arbeite..

    ...Ist schon wieder länger geworden, als geplant...



  • Ich habe manchmal das Gefühl, selbst die OpenGL-Leute sind verwirrt..
    Z.B. findet sich in alten glext.h ,der beim Compiler dabei ist, die glBlendEquation() unter GL v1.2 wieder. Im neuen Header aber unter GL v1.4 ...
    ..Was solls..


Log in to reply