1. Foren
  2. Kommentare
  3. Software-Entwicklung
  4. Alle Kommentare zum Artikel
  5. › AMD: "DirectX steht PC…

Daher favorisiere ich auch OpenGL

Helft uns, die neuen Foren besser zu machen! Unsere kleine Umfrage dauert nur wenige Sekunden!
  1. Thema

Neues Thema Ansicht wechseln


  1. Daher favorisiere ich auch OpenGL

    Autor: /mecki78 22.03.11 - 13:40

    Immer wieder liest man, dass OpenGL der Entwicklung hinterher hinkt, aber das stimmt nicht. In Wahrheit war und ist OpenGL der Entwicklung schon immer weit voraus gewesen. Nur haben die meisten Leute gar keine Ahnung, wie die OpenGL API aufgebaut ist. Vor allem übersehen sie einen ganz wichtigen Punkt, jeder, wirklich JEDER darf OpenGL beliebig erweitern. Bei DirectX, oder nennen wir das Kind doch beim Namen, Direct3D, gibt es genau eine Firma, die die API festlegt, und das ist Microsoft. D.h. wenn morgen eine GPU auf dem Markt kommt, die irgendwas neues kann, dann kann man das solange nicht in Direct3D benutzen, bis Microsoft sich freundlicher Weise bequemt eine neue Direct3D Version heraus zu bringen, die diese Funktion auch anbietet. Das nervt Hersteller von GPUs, das nervt Entwickler, indirekt nervt es somit die Kunden, die tolle Hardware haben, aber keine Software, die diese wirklich im vollem Umfang nutzen könnte; das nervt eigentlich jeden außer Microsoft.

    Wenn Leute sagen, OpenGL ist doch viel weiter hinterher, dann schauen sie immer auf die Core Funktionalität der API und übersehen dabei, dass die Core Funktionalität eben genau das ist, die Core Funktionalität, aber die API bestand schon immer aus deutlich mehr als der Core Funktionalität. Ich gebe mal einen kurzen Abriss, wie OpenGL sich entwickelt:

    ATI (ja, ich weiß, das ist jetzt AMD, aber lasst mich bitte trotzdem ATI schreiben, der guten, alten Zeiten wegen, okay? Außerdem benutzt AMD immer noch ATI Suffixe in OpenGL) baut morgen eine GPU, die was ganz geniales kann, aber es gibt keinen API Call, um diese Funktionalität zu nutzen. Bei Direct3D, Pech gehabt. Warten bis MS den Hintern hoch kriegt. Bei OpenGL, kein Thema, ATI baut einfach eine neue Funktion ein, denn das dürfen sie, eine sogenannte "OpenGL Extension":

    glDoSomethingGreatATI(....);

    Dann releasen sie einen neuen Treiber und fertig, jeder OpenGL Entwickler, der mag, kann jetzt in seiner App testen, ob diese Funktion vorhanden ist und wenn ja, diese auch sofort nutzen. D.h. wie lange es dauert, bis man diese Funktion nutzen kann liegt einzig in der Hand von AMD und niemanden sonst.

    Was passiert jetzt, wenn NVidia auch GPUs baut, die das können? Nun, als erstes baut einfach auf NVidia die gleiche Funktion ein, damit sind sie zu ATI kompatibel und alle Software, die diese Funktion bisher benutzt, läuft auch sofort auf NVidia-Karten. Das dürfen sie auch, denn OpenGL Extensions sind offen für jedermann. So hat mal vor Urzeiten eine Firma namens S3 eine Texturkompression in OpenGL eingebaut, speziell für ihre Karten. Heute unterstützt die jeder Grafikkarte.

    Wenn sich ATI und NVidia irgendwann mal an einen Tisch setzen, und das tun sie tatsächlich ab und an, dann sprechen sie vielleicht mal über die glDoSomethingGreat() Funktion und vielleicht hat NVidia etwas Kritik oder Verbesserungsvorschläge. Vielleicht hat NVidia auch eine eigene, ähnliche, aber nicht ganz gleiche Funktion, glDoSomethingGreatNV(...) und man einigt sich jetzt darauf die Funktionen zusammenzuführen und die Vorschläge beider Seiten dabei zu berücksichtigen. Es entsteht eine Vendor Neutrale Extension:

    glDoSomethingGreatEXT(...);

    Davon gibt es unzählige in OpenGL; wobei manche sind Vendor spezifisch geblieben und werden einfach nur von praktisch allen Herstellern so unterstützt, wie sie ursprünglich mal definiert wurden. Viele werden aber irgendwann neutral.

    Wenn jetzt NVidia und ATI Wert drauf legen, dass diese wichtige Funktion irgendwann mal fester Bestandteil von OpenGL wird, dann beantragen sie, diese Extension vom ARB prüfen zu lassen. Das ARB ist, "Architecture Review Board", besteht aus einem Zusammenschluss vieler an OpenGL interessierten Firmen, die sich diese Extension anschauen, darüber diskutieren, Kritik daran üben und dann über sie abstimmen werden. Stimmberechtigte Mitglieder im ARB wechseln stetig, keine Ahnung wie der Stand 2011 ist. Hier eine Liste bekannter Firma, die bereits im ARB Stimmrecht hatten in der Vergangenheit: 3Dlabs, Apple, ATI, AMD, Dell, IBM, Intel, NVIDIA, Sony Computer Entertainment, Texas Instruments, Microsoft, SGI, Sun Microsystems, Creative Labs, Graphic Remedy, id Software. Wenn das ARB die Extension offiziell absegnet, dann bekommt sie einen neuen Präfix:

    glDoSomethingGreatARB(...);

    Jetzt ist sie offiziell und damit so gut wie fester Bestandteil, aber immer noch optional, d.h. ein Grafikkartenhersteller kann einen 100% konformen OpenGL Treiber liefern, ohne dass er zwangsweise diese Funktion unterstützen muss. Er darf, er sollte vielleicht auch, aber er muss nicht. Die meisten allerdings unterstützen so viele ARB Extension wie möglich.

    Wenn diese Funktion sich bewährt über einen langen Zeitraum und die Khronos Gruppe sich irgendwann dazu entschließt, eine neue OpenGL Version offiziell zu releasen, dann schauen sie sich die ganzen ARB Erweiterungen an und überlegen, welche davon jetzt fester Kernbestandteil werden soll. Diese kommen dann in den Core und haben keinen Präfix mehr:

    glDoSomethingGreat(...);

    So funktioniert OpenGL. Damit ist OpenGL die flexibelste API und wer so dumm ist, und nur auf die Core Funktionalität schaut beim Vergleich OpenGL vs Direct3D, der hat OpenGL leider einfach überhaupt nicht verstanden!

    Was auch immer Microsoft jemals in einer neuen DirectX Version in Direct3D eingebaut hat, gab es vorher schon für OpenGL, vielleicht nicht im Core, aber als Extension. Oft bereits als EXT Extension (manchmal sogar bereits als ARB Extension) und als herstellerspezifische sogar oft schon seit die erste GPU mit der Funktion auf dem Markt kam.

    Und genau das ist das Problem bei Direct3D: Hier gibt es nur den Core und hier bestimmt nur eine Firma, was in den Core kommt und was nicht. Und deswegen hinkt Direct3D immer der Entwicklung um mindestens ein Jahr hinterher. Jetzt wo MS immer langsamer bei der DirectX Entwicklung zu werden scheint, oft sogar mehr als ein Jahr.

    Wenn AMD irgendwo ein Problem mit der OpenGL API hat, weil sie nicht nahe genug an der Hardware ist, kein Problem, AMD kann es morgen ändern und zwar so, wie es ihnen beliebt.

    /Mecki



    1 mal bearbeitet, zuletzt am 22.03.11 13:41 durch /mecki78.

  2. Re: Daher favorisiere ich auch OpenGL

    Autor: ChilliConCarne 22.03.11 - 13:47

    Ich ernenne dich zu demjenigen der hier am meißten Ahnung hat.

    Aber ein Punkt: Die flexible Erweiterbarkeit OGLs kann sich auch Nachteilig wirken. Stichwort 'Extension Chaos'.

  3. Re: Daher favorisiere ich auch OpenGL

    Autor: Mindcraft 22.03.11 - 13:53

    Echt super geschrieben :). Habe heute echt mal wieder was gelernt und bei Heise würde ich dir ein Doppel-Plus geben :).

    Gerne mehr davon :).

  4. danke für den interessanten artikel

    Autor: blood32 22.03.11 - 14:02

    bei Ct einreichen

  5. Re: Daher favorisiere ich auch OpenGL

    Autor: DER GORF 22.03.11 - 14:03

    Und was macht ATi wenn sie nicht wollen das Nvidia das auch kann weil sich Ihre GraKas sich sonst nicht so gut verkaufen wie wenn Nvidia das nicht könnte?

    - Es gibt nichts das eine million Chinesen nicht billiger tun könnten.

    - Alle Verdächtigen sind schuldig, sonst wären sie ja keine Verdächtigen.

  6. Re: Daher favorisiere ich auch OpenGL

    Autor: Der braune Lurch 22.03.11 - 14:13

    Es wäre meist nicht von Vorteil, exklusive Grafikkartenfeatures zu bieten, jedenfalls nicht, wenn es um Spiele geht. Ein Feature, das nur 50% der potentiellen Kunden nutzen können, wird weniger wahrscheinlich in einem Spiel aufgenommen als eins, von dem alle profitieren. Bestes Beispiel Tesselation, das AMD über eine Extension länger drin hatte als Nvidia. Konkurriert wird idR über Leistung, Preis oder Leistungsaufnahme.

    ------------------------------
    Der Molch macht's.
    ------------------------------

  7. Re: Daher favorisiere ich auch OpenGL

    Autor: /mecki78 22.03.11 - 14:19

    ChilliConCarne schrieb:
    --------------------------------------------------------------------------------
    > Aber ein Punkt: Die flexible Erweiterbarkeit OGLs kann sich auch Nachteilig
    > wirken. Stichwort 'Extension Chaos'.

    Ich würde es nicht als Chaos bezeichnen, denn zum einen sind Hersteller "faul", d.h. sie machen sich selten die Mühe eine Extension zu definieren für etwas, für das ein anderer bereits eine definiert hat. D.h. es kam bisher nicht oft in der Geschichte von OpenGL vor, dass es die gleiche Extension zweimal von unterschiedlichen Firmen gab. Meistens hat man sich vorher bereits mit dem Initiator der ersten Extension zusammengetan und gleich eine neutrale EXT Extension definiert.

    Zum anderen wird jede Software irgendwann released und den Programmierer interessiert immer nur der JETZT Stand. D.h. wenn jetzt gerade nur eine ATI spezifische Extension für etwas existiert, dann kann und wird er auch nur diese benutzen. Dass es in einem halben Jahr dann eine ARB Extension für das gleiche gibt ist schön, interessiert aber jetzt gerade im Moment überhaupt nicht. Ein Direct3D Entwickler kann auch nur das verwenden, was Direct3D gerade bietet, nicht das, was die nächste Version in einem Jahr bieten wird. Und wenn man eine Momentaufnahme von OpenGL macht, dann ist die eigentlich immer eindeutig: Wenn es teil vom Core ist, dann benutzt du die Core Funktion. Gibt es eine ARB Extension dafür, benutzt du diese. Gibt es nur eine EXT Extension, dann nimmst du diese. Und gibt es nur eine Hersteller Extension, dann nimmst du eben diese. Dann haust du die Software auf dem Markt. Hättest du ein halbes Jahr gewartet, dann hättest du vielleicht diese Funktion auf viel mehr Karten nutzen können, aber nach dieser Argumentation kann man genauso sagen, hätten Hersteller bei anderen Spielen gewartet, dann hätten sie mehr/größere Texturen oder Polygone nutzen können. Nicht jede Firma kann es sich erlauben an einem Duke Nukem Forever über ein Jahrzehnt zu schrauben :-P

    /Mecki

  8. Re: Daher favorisiere ich auch OpenGL

    Autor: Aison 22.03.11 - 14:23

    Ich programmiere auch mit OpenGL und ich bin genau der gleichen Meinung wie /mecki78. Direct3D hinkt OpenGL hinterher (teilweise Jahre!) und das schon immer. Natürlich kann man jetzt mit dem "Extension Chaos" bei OpenGL argumentieren und das mag vieleicht sogar stimmen. Aber man muss sich einfach entscheiden:

    1) Entweder will ich möglichst hardwarenah programmieren und nehme in kauf, mich mit den verschiedenen Extensions der verschiedenen Hersteller abzugeben. Dafür ist mein Resultat sehr effizient.

    2) Oder ich warte drauf bis eine einheitliche Schnittstelle da ist, die evtl. intern nur über Wrapper vereinheitlicht wurde und gebe mich dann mit einem langsameren Resultat zufrieden.

    Aber eines ist klar, beides gleichzeitig ist meistens nicht möglich - Jedenfalls so lange nicht, so lange das Monopol der Hardware und der API nicht beim gleichen Hersteller liegt (siehe Consolen).


    Was auch noch möglich wäre: Ich beschränke mich darauf mein Programm auf 2-3 GPUs zu optimieren und für alle anderen GPU programmiere ich eine allgemeine Fallback Routine, die überall läuft.


    -Aison

  9. Re: Daher favorisiere ich auch OpenGL

    Autor: /mecki78 22.03.11 - 14:24

    DER GORF schrieb:
    --------------------------------------------------------------------------------
    > Und was macht ATi wenn sie nicht wollen das Nvidia das auch kann weil sich
    > Ihre GraKas sich sonst nicht so gut verkaufen wie wenn Nvidia das nicht
    > könnte?

    Glaubst du wirklich, dass Spieleentwickler, die schon den Stress haben, dafür zu sorgen, dass ihr Spiel auf der XBox, der Playstation, dem Wii und auf normalen PCs läuft, Lust darauf haben, ihr Spiel jetzt auch noch mal extra für verschiedene Grafikkarten am PC gezielt anzupassen? Wenn ATI eine Funktion einbaut, die man nur über eine proprietäre API von ihnen steuern kann, dann müssen sie damit rechnen, dass sie keiner benutzt, weil der Aufwand zu groß ist, für nur einen Grafikkartenhersteller so viel zusätzliche Entwicklungszeit und -kosten in Kauf zu nehmen. Womit ATI dann zwar einen Vorteil gegenüber der Konkurrenz hätte, aber was nützt der, wenn keine Spiele diesen Vorteil ausnützen?

    /Mecki

  10. Re: Daher favorisiere ich auch OpenGL

    Autor: Turrican101 22.03.11 - 14:32

    /mecki78 schrieb:
    --------------------------------------------------------------------------------
    > Glaubst du wirklich, dass Spieleentwickler, die schon den Stress haben,
    > dafür zu sorgen, dass ihr Spiel auf der XBox, der Playstation, dem Wii und
    > auf normalen PCs läuft, Lust darauf haben, ihr Spiel jetzt auch noch mal
    > extra für verschiedene Grafikkarten am PC gezielt anzupassen?


    Also zu 3DFx-Zeiten hats niemanden gestört, die hatten auch ne Extrawurst...

  11. Re: Daher favorisiere ich auch OpenGL

    Autor: /mecki78 22.03.11 - 14:39

    Aison schrieb:
    --------------------------------------------------------------------------------
    > Was auch noch möglich wäre: Ich beschränke mich darauf mein Programm auf
    > 2-3 GPUs zu optimieren und für alle anderen GPU programmiere ich eine
    > allgemeine Fallback Routine, die überall läuft.

    Ich denke, das ist heute bei den meisten so. Du schreibst deinen Code erstmal so, dass er mit der Core API von OpenGL einwandfrei funktioniert; welche Funktionen du hier zur Verfügung hast, hängt von der OpenGL Version ab, die du voraussetzt; es muss ja nicht unbedingt OpenGL 1.3 sein ;-) Und dann schaust du, wo du bessere optische Effekte erzielen kannst, unter Ausnutzung verschiedenster Extension. Wenn zur Laufzeit erkannt wird, dass eine Karte z.B. kein Anisotropes Filtern von Texturen beherrscht, dann nutzt du es einfach nicht. Sieht halt nicht ganz so hübsch aus, aber läuft trotzdem nicht viel schlechter.

    Extensions bieten noch einen weiteren Vorteil für Hardwarehersteller: Alles was Core Funktionalität ist, muss ein Treiber unterstützen, wenn er eine bestimmte OpenGL Version unterstützen möchte. Was aber, wenn die GPU es nicht kann? Tja, dann muss der Treiber es eben in Software Emulieren, weil die Funktionalität muss vorhanden sein! Extensions hingegen muss man nicht in Software Emulieren. Wenn die GPU es nicht kann, dann lässt man sie einfach weg. Wenn man glaubt, man kann es einfach und schnell in Software emulieren, dann kann man das natürlich machen, aber man muss eben nicht. Apple emuliert z.B. auf manchen Karten bestimmte Shader Funktionalität in Software und erstaunlicher Weise, das ist gar nicht so langsam wie man glaubt (bei einfachen Shadern schafft es 66% der Performance, die meine echte GPU schafft), allerdings kostet es einiges an CPU Zeit, die an anderer Stelle wieder fehlen könnte.

    /Mecki

  12. Re: Daher favorisiere ich auch OpenGL

    Autor: /mecki78 22.03.11 - 14:47

    Turrican101 schrieb:
    --------------------------------------------------------------------------------
    > Also zu 3DFx-Zeiten hats niemanden gestört, die hatten auch ne
    > Extrawurst...

    GLIDE ist ein Subset von OpenGL. D.h. im Prinzip ist GLIDE das gleiche wie OpenGL, nur wurden eben nicht alle OpenGL Funktionen übernommen:

    "Glide is based on the basic geometry and "world view" of OpenGL. OpenGL is a large graphics library with 336 calls in the API, many of which are of limited use. Glide was an effort to select primarily features that were useful for real-time rendering of 3D games."
    - http://en.wikipedia.org/wiki/Glide_API

    /Mecki

  13. Danke und eine Frage

    Autor: Norky 22.03.11 - 14:52

    Danke für die Ausführungen!

    Eine Frage zum Verständnis habe ich dazu: Mal angenommen, ich würde ein Programm kaufen, das die Vendor Extension glDoSomethingGreatATI() benutzt. Der Hersteller geht Pleite und es gibt keine Updates mehr, ich möchte das Programm jedoch weiterhin benutzen. Nehmen wir weiter an, dass glDoSomethingGreatATI() so wichtig ist, dass es zu glDoSomethingGreatEXT(), glDoSomethingGreatARB() oder glDoSomethingGreat() führt. Wie sieht es da mit der Kompatibilität aus? Werden standardmässig Wrapper für alte Funktionen angeboten, die im Standardisierungsprozess weiter fortgeschritten sind, so dass mein altes Programm auch nach Jahren mit neuen Treibern noch funktioniert?

  14. Re: Daher favorisiere ich auch OpenGL

    Autor: Supermax 22.03.11 - 15:02

    Sehr gut und interessant geschrieben.

    Keine Ahnung wie OGL gegenüber D3D performancemäßig abschneidet, aber jedenfalls existiert OGL auf so gut wie allen Plattformen wo es 3D-Grafik gibt, sei es Windows, Unix/Linux/BSD, MacOS X,.... - D3D gibt es ja nur auf Windows.

  15. Re: Danke und eine Frage

    Autor: Satan 22.03.11 - 17:20

    Wenn sich nur der Name der Funktion ändert, ist das in der Regel Aufgabe des OpenGL-Headers, ansonsten bleiben aber zumindest bei NVidia alle Funktionen drin, und für ATI sollte das gleiche gelten. Du kannst z.B. heute noch ein Programm mit GL 1.5-API und GLSL-Shadern über ARB-Extensions schreiben, das wird wohl überall laufen..

  16. Danke Danke Danke

    Autor: Top-OR 23.03.11 - 10:21

    Ich danke dir hier aufrichtig für diesen Beitrag, weil du mal sagst, wie es läuft und diesen ganzen blöden DX-ist-viel-schneller-als-OGL-weils-gewrappt-wird und den anderen geilen Gerüchten, die aus Halbwissen entstanden sind, damit was entgegensetzt.

    Genau diese Verfahrensweise, dass Leute ohne Ahnung falsche Aussagen in Foren machen, führt dazu, dass zu einem späteren Zeitpunkt andere Leute ohne Ahnung falsche Aussagen und Foren machen. Und SO entstehen Gerüchte - und plötzlich ist OpenGL nur noch für CAD ausgelegt und was weiß ich noch ...

    DANKE! DANKE! DANKE!
    Top-OR(.de)

    -----
    Verallgemeinerungen sind IMMER falsch.



    3 mal bearbeitet, zuletzt am 23.03.11 10:24 durch Top-OR.

  1. Thema

Neues Thema Ansicht wechseln


Um zu kommentieren, loggen Sie sich bitte ein oder registrieren Sie sich. Sie müssen ausserdem in Ihrem Account-Profil unter Forum einen Nutzernamen vergeben haben. Zum Login

Stellenmarkt
  1. Universitätsklinikum Münster, Münster
  2. über duerenhoff GmbH, Heidelberg
  3. karriere tutor GmbH, deutschlandweit (Home-Office)
  4. Berliner Wasserbetriebe, Berlin

Golem pur
  • Golem.de ohne Werbung nutzen

Anzeige
Hardware-Angebote
  1. (reduzierte Überstände, Restposten & Co.)


Haben wir etwas übersehen?

E-Mail an news@golem.de


Programm für IT-Jobeinstieg: Hoffen auf den Klebeeffekt
Programm für IT-Jobeinstieg
Hoffen auf den Klebeeffekt

Aktuell ist der Jobeinstieg für junge Ingenieure und Informatiker schwer. Um ihnen zu helfen, hat das Land Baden-Württemberg eine interessante Idee: Es macht sich selbst zur Zeitarbeitsfirma.
Ein Bericht von Peter Ilg

  1. Arbeitszeit Das Sechs-Stunden-Experiment bei Sipgate
  2. Neuorientierung im IT-Job Endlich mal machen!
  3. IT-Unternehmen Die richtige Software für ein Projekt finden

Weclapp-CTO Ertan Özdil: Wir dürfen nicht in Schönheit und Perfektion untergehen!
Weclapp-CTO Ertan Özdil
"Wir dürfen nicht in Schönheit und Perfektion untergehen!"

Der CTO von Weclapp träumt von smarter Software, die menschliches Eingreifen in der nächsten ERP-Generation reduziert. Deutschen Perfektionismus hält Ertan Özdil aber für gefährlich.
Ein Interview von Maja Hoock


    Fiat 500 als E-Auto im Test: Kleinstwagen mit großem Potenzial
    Fiat 500 als E-Auto im Test
    Kleinstwagen mit großem Potenzial

    Fiat hat einen neuen 500er entwickelt. Der Kleine fährt elektrisch - und zwar richtig gut.
    Ein Test von Peter Ilg

    1. Vierradlenkung Elektrischer GMC Hummer SUV fährt im Krabbengang seitwärts
    2. MG Cyberster MG B Roadster mit Lasergürtel und Union Jack
    3. Elektroauto E-Auto-Prämie übersteigt in 2021 schon Vorjahressumme