OpenGL - OpenGL

OpenGL
Logo OpenGL (2D).svg
Jądro Linuksa i gry wideo OpenGL.svg
Gry wideo zlecają obliczenia renderowania w czasie rzeczywistym na GPU za pośrednictwem OpenGL. Wyrenderowane wyniki nie są wysyłane z powrotem do pamięci głównej, ale do bufora ramki pamięci wideo. Sterownik wyświetlacza wyśle ​​następnie te dane do urządzenia wyświetlającego.
Pierwotny autor (autorzy) Grafika krzemowa
Deweloper(zy) Grupa Khronos
(dawniej ARB )
Pierwsze wydanie 30 czerwca 1992 ; 29 lat temu ( 1992-06-30 )
Wersja stabilna
4,6/31 lipca 2017 ; 4 lata temu ( 2017-07-31 )
Napisane w C
Rodzaj API grafiki 3D
Licencja
  • Licencja open source na korzystanie z SI: Jest to licencja wolnego oprogramowania B ściśle wzorowana na licencjach BSD, X i Mozilla.
  • Licencja na znak towarowy dla nowych licencjobiorców, którzy chcą używać znaku towarowego i logo OpenGL oraz zgodności oświadczeń.
Strona internetowa OpenGL .org

OpenGL ( Open Graphics Library ) to wielojęzyczny , wieloplatformowy interfejs programowania aplikacji (API) do renderowania grafiki wektorowej 2D i 3D . Interfejs API jest zwykle używany do interakcji z procesorem graficznym (GPU) w celu uzyskania renderowania z przyspieszeniem sprzętowym .

Silicon Graphics, Inc. (SGI) zaczął rozwijać OpenGL w 1991 roku i wydał go 30 czerwca 1992 roku; aplikacje wykorzystują go szeroko w dziedzinie projektowania wspomaganego komputerowo (CAD), rzeczywistości wirtualnej , wizualizacji naukowej, wizualizacji informacji, symulacji lotu i gier wideo . Od 2006 roku OpenGL jest zarządzany przez konsorcjum technologiczne non-profit Khronos Group .

Projekt

Ilustracja procesu potoku graficznego

Specyfikacja OpenGL opisuje abstrakcyjne API do rysowania grafiki 2D i 3D. Chociaż możliwe jest zaimplementowanie API w całości programowo, jest ono przeznaczone do implementacji głównie lub całkowicie sprzętowo .

API jest zdefiniowane jako zestaw funkcji, które mogą być wywoływane przez program klienta, obok zestawu nazwanych stałych całkowitych (na przykład stała GL_TEXTURE_2D, która odpowiada liczbie dziesiętnej 3553). Chociaż definicje funkcji są powierzchownie podobne do tych z języka programowania C , są one niezależne od języka. Jako takie, OpenGL ma wiele powiązań językowych , niektóre z najbardziej godne uwagi będąc JavaScript wiążące WebGL (API, w oparciu o OpenGL ES 2.0 , dla renderowania 3D z poziomu przeglądarki internetowej ); wiązania C WGL , GLX i CGL ; powiązanie C dostarczone przez iOS ; oraz powiązania Java i C dostarczane przez system Android .

Oprócz tego, że jest niezależny od języka, OpenGL jest również wieloplatformowy. Specyfikacja nie mówi nic na temat uzyskiwania i zarządzania kontekstem OpenGL, pozostawiając to jako szczegół podstawowego systemu okienkowego . Z tego samego powodu OpenGL zajmuje się wyłącznie renderowaniem, nie dostarczając żadnych interfejsów API związanych z wejściem, dźwiękiem lub oknami.

Rozwój

OpenGL to aktywnie rozwijany interfejs API. Nowe wersje specyfikacji OpenGL są regularnie publikowane przez Khronos Group , z których każda rozszerza API o obsługę różnych nowych funkcji. Szczegóły każdej wersji są ustalane w drodze konsensusu między członkami Grupy, w tym producentami kart graficznych, projektantami systemów operacyjnych oraz firmami zajmującymi się ogólnymi technologiami, takimi jak Mozilla i Google .

Oprócz funkcji wymaganych przez rdzeń API jednostka przetwarzania grafiki (GPU) producenci mogą zapewnić dodatkową funkcjonalność w postaci rozszerzenia . Rozszerzenia mogą wprowadzać nowe funkcje i nowe stałe oraz mogą rozluźniać lub usuwać ograniczenia istniejących funkcji OpenGL. Sprzedawcy mogą używać rozszerzeń do ujawniania niestandardowych interfejsów API bez potrzeby wsparcia ze strony innych dostawców lub całej grupy Khronos, co znacznie zwiększa elastyczność OpenGL. Wszystkie rozszerzenia są gromadzone i definiowane przez rejestr OpenGL.

Każde rozszerzenie jest skojarzone z krótkim identyfikatorem, opartym na nazwie firmy, która je opracowała. Na przykład identyfikator Nvidii to NV, który jest częścią nazwy rozszerzenia GL_NV_half_float, stałej GL_HALF_FLOAT_NVi funkcji glVertex2hNV(). Jeśli wielu dostawców zgodzi się wdrożyć tę samą funkcjonalność przy użyciu tego samego interfejsu API, udostępnione rozszerzenie może zostać wydane z identyfikatorem EXT. W takich przypadkach może się również zdarzyć, że Rada ds. Przeglądu Architektury Khronos Group wyrazi wyraźną zgodę na rozszerzenie, w którym to przypadku używany jest identyfikator ARB.

Funkcje wprowadzane przez każdą nową wersję OpenGL są zazwyczaj tworzone z połączonych funkcji kilku szeroko zaimplementowanych rozszerzeń, zwłaszcza rozszerzeń typu ARB lub EXT.

Dokumentacja

Rada Przeglądu Architektury OpenGL wydała serię podręczników wraz ze specyfikacją, które zostały zaktualizowane w celu śledzenia zmian w API. Są one powszechnie określane przez kolory ich okładek:

Czerwona Księga
Przewodnik programowania OpenGL, 9. edycja. ISBN  978-0-134-49549-1
Oficjalny przewodnik do nauki OpenGL, wersja 4.5 z SPIR-V
Pomarańczowa Księga
Język cieniowania OpenGL, 3. edycja. ISBN  0-321-63763-1
Samouczek i podręcznik dotyczący GLSL .

Książki historyczne (przed OpenGL 2.0):

Zielona Księga
Programowanie OpenGL dla systemu X Window. ISBN  978-0-201-48359-8
Książka o interfejsie X11 i OpenGL Utility Toolkit (GLUT).
Niebieska Księga
Podręcznik OpenGL Reference, wydanie czwarte. ISBN  0-321-17383-X
Zasadniczo wydruk strony podręcznika (man) Uniksa dla OpenGL.
Zawiera rozkładany diagram wielkości plakatu, pokazujący strukturę wyidealizowanej implementacji OpenGL.
Księga Alfa (biała okładka)
Programowanie OpenGL dla Windows 95 i Windows NT. ISBN  0-201-40709-4
Książka o łączeniu OpenGL z Microsoft Windows.

Dokumentacja OpenGL jest również dostępna na jego oficjalnej stronie internetowej.

Powiązane biblioteki

Najwcześniejsze wersje OpenGL zostały wydane z towarzyszącą biblioteką o nazwie OpenGL Utility Library (GLU). Dostarczał prostych, użytecznych funkcji, które raczej nie były obsługiwane we współczesnym sprzęcie, takich jak tesselacja oraz generowanie mipmap i prymitywnych kształtów . Specyfikacja GLU została ostatnio zaktualizowana w 1998 roku i zależy od funkcji OpenGL, które są obecnie przestarzałe .

Zestawy narzędzi kontekstowych i okiennych

Biorąc pod uwagę, że stworzenie kontekstu OpenGL jest dość złożonym procesem, a biorąc pod uwagę, że waha się od systemów operacyjnych , tworzenie kontekstu automatyczny OpenGL stał się wspólną cechą wielu gra-rozwojowych i interfejsu użytkownika bibliotek , w tym SDL , Allegro , SFML , FLTK , i Qt . Kilka bibliotek zostało zaprojektowanych wyłącznie do tworzenia okna obsługującego OpenGL. Pierwszą taką biblioteką był OpenGL Utility Toolkit (GLUT), później zastąpiony przez freeglut . GLFW to nowsza alternatywa.

  • Te zestawy narzędzi są przeznaczone do tworzenia i zarządzania oknami OpenGL oraz zarządzania danymi wejściowymi, ale niewiele poza tym.
  • GLFW – wieloplatformowy program obsługi okienek i myszy z klawiaturą; jest bardziej zorientowany na grę
  • freeglut – wieloplatformowy program obsługi okien i myszy; jego API jest nadzbiorem API GLUT i jest bardziej stabilne i aktualne niż GLUT
  • OpenGL Utility Toolkit (GLUT) — stary program obsługi okien, który nie jest już utrzymywany.
  • Kilka „bibliotek multimedialnych” może tworzyć okna OpenGL, oprócz wprowadzania, dźwięku i innych zadań przydatnych w aplikacjach podobnych do gier
  • Allegro 5 – wieloplatformowa biblioteka multimedialna z C API skoncentrowana na tworzeniu gier
  • Simple DirectMedia Layer (SDL) – wieloplatformowa biblioteka multimedialna z C API
  • SFML – wieloplatformowa biblioteka multimedialna z C++ API i wieloma innymi powiązaniami z językami takimi jak C#, Java, Haskell i Go
  • Zestawy narzędzi do widżetów
  • FLTK – Mała, wieloplatformowa biblioteka widżetów C++
  • Qt — wieloplatformowy zestaw narzędzi widżetów C++. Zapewnia wiele obiektów pomocniczych OpenGL, które nawet oddalają różnicę między desktopowym GL a OpenGL ES
  • wxWidgets – wieloplatformowy zestaw narzędzi widżetów C++

Biblioteki ładujące rozszerzenia

Biorąc pod uwagę duże nakłady pracy związane z identyfikowaniem i ładowaniem rozszerzeń OpenGL, zaprojektowano kilka bibliotek, które automatycznie ładują wszystkie dostępne rozszerzenia i funkcje. Przykłady obejmują GLEE , GLEW i glbinding . Rozszerzenia są również ładowane automatycznie przez większość powiązań językowych, takich jak Jogl i PyOpenGL .

Realizacje

Mesa 3D to implementacja OpenGL o otwartym kodzie źródłowym . Może wykonywać renderowanie czysto programowe, a także może korzystać z akceleracji sprzętowej na platformach BSD , Linux i innych, korzystając z infrastruktury Direct Rendering Infrastructure . Od wersji 20.0 implementuje wersję 4.6 standardu OpenGL.

Historia

W latach 80. opracowanie oprogramowania, które mogłoby współpracować z szeroką gamą sprzętu graficznego, było prawdziwym wyzwaniem. Twórcy oprogramowania napisali niestandardowe interfejsy i sterowniki dla każdego sprzętu. Było to kosztowne i skutkowało zwielokrotnieniem wysiłku.

Na początku lat 90. Silicon Graphics (SGI) była liderem w dziedzinie grafiki 3D dla stacji roboczych. Ich API IRIS GL stało się standardem branżowym, używanym szerzej niż PHIGS oparte na otwartych standardach . Wynikało to z faktu, że IRIS GL był uważany za łatwiejszy w użyciu i ponieważ obsługiwał renderowanie w trybie natychmiastowym . Natomiast PHIGS był uważany za trudny w użyciu i przestarzały pod względem funkcjonalności.

Konkurenci SGI (w tym Sun Microsystems , Hewlett-Packard i IBM ) również byli w stanie wprowadzić na rynek sprzęt 3D obsługiwany przez rozszerzenia wykonane zgodnie ze standardem PHIGS, co zmusiło SGI do udostępnienia wersji IrisGL jako standardu publicznego o nazwie OpenGL .

Jednak SGI miała wielu klientów, dla których przejście z IrisGL na OpenGL wymagałoby znacznych inwestycji. Co więcej, IrisGL posiadał funkcje API, które były nieistotne dla grafiki 3D. Na przykład zawierał interfejs API do obsługi okien, klawiatury i myszy, po części dlatego, że został opracowany przed X Window System i Sun's NewWS . Ponadto biblioteki IrisGL nie nadawały się do otwierania z powodu problemów licencyjnych i patentowych. Czynniki te wymagały od SGI dalszego wspierania zaawansowanych i prawnie zastrzeżonych interfejsów programistycznych API Iris Inventor i Iris Performer, podczas gdy wsparcie rynkowe dla OpenGL dojrzało.

Jednym z ograniczeń IrisGL było to, że zapewniał dostęp tylko do funkcji obsługiwanych przez podstawowy sprzęt. Jeśli sprzęt graficzny nie obsługuje funkcji natywnie, aplikacja nie może jej użyć. OpenGL przezwyciężył ten problem, dostarczając implementacje programowe funkcji nieobsługiwanych przez sprzęt, umożliwiając aplikacjom korzystanie z zaawansowanej grafiki w systemach o stosunkowo niskim poborze mocy. OpenGL ustandaryzował dostęp do sprzętu, przesunął odpowiedzialność za opracowywanie programów interfejsu sprzętowego ( sterowników urządzeń ) na producentów sprzętu i delegował funkcje okienkowe do bazowego systemu operacyjnego. Przy tak wielu różnych rodzajach sprzętu graficznego, skłonienie ich wszystkich do mówienia tym samym językiem w ten sposób miało niezwykły wpływ, dając programistom platformę wyższego poziomu do tworzenia oprogramowania 3D.

W 1992 roku SGI kierowało utworzeniem OpenGL Architecture Review Board (OpenGL ARB), grupy firm, które miały utrzymywać i rozwijać specyfikację OpenGL w przyszłości.

W 1994 roku SGI bawiło się pomysłem wydania czegoś o nazwie „ OpenGL++ ”, które zawierało takie elementy, jak interfejs API sceny (prawdopodobnie oparty na technologii Performer ). Specyfikacja została rozesłana do kilku zainteresowanych stron – ale nigdy nie przekształciła się w produkt.

Microsoft wypuścił Direct3D w 1995 roku, który ostatecznie stał się głównym konkurentem OpenGL. Ponad 50 twórców gier podpisało list otwarty do Microsoftu, opublikowany 12 czerwca 1997 roku, wzywający firmę do aktywnego wspierania Open GL. 17 grudnia 1997 r. Microsoft i SGI zainicjowały projekt Fahrenheit , który był wspólnym wysiłkiem, którego celem było ujednolicenie interfejsów OpenGL i Direct3D (oraz dodanie interfejsu API sceny-grafu). W 1998 roku do projektu dołączył Hewlett-Packard. Początkowo wykazywał pewną obietnicę uporządkowania świata interfejsów API interaktywnej grafiki komputerowej 3D, ale ze względu na ograniczenia finansowe w SGI, strategiczne powody w firmie Microsoft i ogólny brak wsparcia branżowego, został porzucony w 1999 roku.

W lipcu 2006 roku OpenGL Architecture Review Board zagłosowało za przekazaniem kontroli nad standardem OpenGL API firmie Khronos Group.

Historia wersji

Pierwsza wersja OpenGL, wersja 1.0, została wydana 30 czerwca 1992 roku przez Marka Segala i Kurta Akeleya . Od tego czasu OpenGL był od czasu do czasu rozszerzany o nową wersję specyfikacji. Takie wydania definiują podstawowy zestaw funkcji, które muszą obsługiwać wszystkie zgodne karty graficzne i na podstawie których można łatwiej napisać nowe rozszerzenia. Każda nowa wersja OpenGL zawiera zwykle kilka rozszerzeń, które mają szerokie poparcie wśród producentów kart graficznych, chociaż szczegóły tych rozszerzeń mogą ulec zmianie.

Historia wersji OpenGL
Wersja Data wydania Cechy
1,1 4 marca 1997 r. Obiekty tekstur, tablice wierzchołków
1.2 16 marca 1998 Tekstury 3D, formaty BGRA i spakowanych pikseli , wprowadzenie podzbioru obrazowania przydatnego w aplikacjach przetwarzania obrazu
1.2.1 14 października 1998 r. Koncepcja rozszerzeń ARB
1,3 14 sierpnia 2001 Multiteksturowanie , multisampling, kompresja tekstur
1,4 24 lipca 2002 r. Tekstury głębi, GLSlang
1,5 29 lipca 2003 r. Obiekt bufora wierzchołków (VBO), zapytania okluzji
2,0 7 września 2004 r. GLSL 1.1, MRT , tekstury Non Power of Two, Point Sprites, dwustronny szablon
2,1 2 lipca 2006 GLSL 1.2, obiekt bufora pikseli (PBO), tekstury sRGB
3,0 11 sierpnia 2008 GLSL 1.3, tablice tekstur, renderowanie warunkowe, obiekt bufora ramki (FBO)
3.1 24 marca 2009 GLSL 1.4, tworzenie instancji, obiekt bufora tekstur, obiekt bufora jednolitego, restart prymitywny
3.2 3 sierpnia 2009 GLSL 1.5, Geometry Shader, Wielopróbkowe tekstury
3,3 11 marca 2010 GLSL 3.30, Backporty jak najwięcej funkcji ze specyfikacji OpenGL 4.0
4.0 11 marca 2010 GLSL 4.00, teselacja na GPU, shadery z 64-bitową precyzją
4.1 26 lipca 2010 GLSL 4.10, przyjazne dla programistów wyjścia debugowania, kompatybilność z OpenGL ES 2.0
4.2 8 sierpnia 2011 GLSL 4.20, Shadery z licznikami atomowymi, instancja sprzężenia zwrotnego z transformacją rysowania, pakowanie shaderów, ulepszenia wydajności
4,3 6 sierpnia 2012 GLSL 4.30, moduły obliczeniowe wykorzystujące równoległość GPU, obiekty bufora pamięci modułu cieniującego, wysokiej jakości kompresja tekstur ETC2/EAC, zwiększone bezpieczeństwo pamięci, rozszerzenie odporności na wiele aplikacji, zgodność z OpenGL ES 3.0
4.4 22 lipca 2013 r. GLSL 4.40, kontrola rozmieszczania buforów, wydajne zapytania asynchroniczne, układ zmiennych cieniowania, wydajne wiązanie wielu obiektów, usprawnione przenoszenie aplikacji Direct3D, rozszerzenie tekstury bez Bindless, rozszerzenie tekstury rzadkiej
4,5 11 sierpnia 2014 GLSL 4.50, Direct State Access (DSA), Flush Control, Robustness, OpenGL ES 3.1 API i kompatybilność z shaderami, funkcje emulacji DX11
4,6 31 lipca 2017 r. GLSL 4.60, Wydajniejsze przetwarzanie geometrii i wykonywanie shaderów, więcej informacji, brak kontekstu błędów, clamp offsetu wielokąta, SPIR-V, filtrowanie anizotropowe

OpenGL 2.0

Data wydania : 7 września 2004 r.

OpenGL 2.0 został pierwotnie wymyślony przez 3Dlabs, aby rozwiązać obawy, że OpenGL znajdował się w stagnacji i brakowało mu silnego kierunku. Firma 3Dlabs zaproponowała szereg głównych uzupełnień do standardu. Większość z nich została w tamtym czasie odrzucona przez ARB lub w inny sposób nigdy nie została zrealizowana w formie proponowanej przez 3Dlabs. Jednak ich propozycja języka cieniowania w stylu C została ostatecznie ukończona, co zaowocowało obecnym sformułowaniem języka cieniowania OpenGL ( GLSL lub GLslang). Podobnie jak języki cieniowania przypominające asembler, które zastępował, umożliwiło zastąpienie wierzchołka o stałej funkcji i potoku fragmentów shaderami , choć tym razem napisanym w języku wysokiego poziomu podobnym do C.

Projekt GLSL był godny uwagi ze względu na stosunkowo niewielkie ustępstwa w zakresie ograniczeń dostępnego wówczas sprzętu. Nawiązywało to do wcześniejszej tradycji OpenGL, która wyznaczała ambitny, wybiegający w przyszłość cel dla akceleratorów 3D, a nie tylko śledzenie stanu aktualnie dostępnego sprzętu. Ostateczna specyfikacja OpenGL 2.0 obejmuje obsługę GLSL.

Longs Peak i OpenGL 3.0

Przed wydaniem OpenGL 3.0 nowa wersja miała nazwę kodową Longs Peak . W momencie pierwotnego ogłoszenia, Longs Peak został zaprezentowany jako pierwsza poważna rewizja API w życiu OpenGL. Polegał na przebudowie sposobu działania OpenGL, wzywając do fundamentalnych zmian w API.

Projekt wprowadził zmianę w zarządzaniu obiektami. Model obiektowy GL 2.1 został zbudowany na podstawie projektu OpenGL opartego na stanie. Oznacza to, że aby zmodyfikować obiekt lub go użyć, należy powiązać obiekt z systemem stanów, a następnie dokonać modyfikacji stanu lub wykonać wywołania funkcji, które używają powiązanego obiektu.

Ze względu na użycie systemu stanów przez OpenGL, obiekty muszą być mutowalne. Oznacza to, że podstawowa struktura obiektu może ulec zmianie w dowolnym momencie, nawet jeśli potok renderowania asynchronicznie używa tego obiektu. Obiekt tekstury można przedefiniować z 2D na 3D. Wymaga to od wszelkich implementacji OpenGL zwiększenia stopnia złożoności wewnętrznego zarządzania obiektami.

W ramach interfejsu API Longs Peak tworzenie obiektów stałoby się atomowe , przy użyciu szablonów do definiowania właściwości obiektu, który zostałby utworzony za pomocą jednego wywołania funkcji. Obiekt może być wtedy natychmiast użyty w wielu wątkach. Obiekty również byłyby niezmienne; jednak ich zawartość może zostać zmieniona i zaktualizowana. Na przykład tekstura może zmienić swój obraz, ale nie można zmienić jej rozmiaru i formatu.

Aby zapewnić kompatybilność wsteczną, stary interfejs API oparty na stanie nadal byłby dostępny, ale żadna nowa funkcja nie byłaby udostępniana za pośrednictwem starego interfejsu API w późniejszych wersjach OpenGL. Pozwoliłoby to na dalsze działanie starszych baz kodu, takich jak większość produktów CAD , podczas gdy inne oprogramowanie mogłoby zostać napisane lub przeniesione do nowego interfejsu API.

Longs Peak początkowo miał zostać sfinalizowany we wrześniu 2007 roku pod nazwą OpenGL 3.0, ale grupa Khronos ogłosiła 30 października, że ​​napotkała kilka problemów, którymi chciała się zająć przed opublikowaniem specyfikacji. W rezultacie specyfikacja została opóźniona, a Khronos Group popadła w zaciemnienie mediów do czasu wydania ostatecznej specyfikacji OpenGL 3.0.

Ostateczna specyfikacja okazała się znacznie mniej rewolucyjna niż propozycja Longs Peak. Zamiast usuwać wszystkie tryby natychmiastowe i stałe funkcje (tryb bez cieniowania), specyfikacja zawierała je jako przestarzałe funkcje. Zaproponowany model obiektu nie został uwzględniony i nie ogłoszono planów włączenia go do jakichkolwiek przyszłych poprawek. W rezultacie interfejs API pozostał w dużej mierze taki sam, a kilka istniejących rozszerzeń zostało promowanych do podstawowej funkcjonalności.

Wśród niektórych grup programistów decyzja ta wywołała pewne zamieszanie, a wielu programistów twierdziło, że w proteście przejdą na DirectX . Większość skarg dotyczyła braku komunikacji Khronosa ze społecznością programistyczną i odrzucenia wielu funkcji, które przez wielu były postrzegane przychylnie. Inne frustracje obejmowały wymaganie sprzętu na poziomie DirectX 10 do korzystania z OpenGL 3.0 oraz brak shaderów geometrii i renderowania instancyjnego jako podstawowych funkcji.

Inne źródła podały, że reakcja społeczności nie była tak dotkliwa, jak pierwotnie przedstawiono, a wielu dostawców wspierało aktualizację.

OpenGL 3.0

Data wydania : 11 sierpnia 2008 r.

OpenGL 3.0 wprowadził mechanizm deprecjacji, aby uprościć przyszłe wersje API. Niektóre funkcje, oznaczone jako przestarzałe, można całkowicie wyłączyć, żądając od systemu okienkowego kontekstu zgodnego z przekazywaniem dalej . Funkcje OpenGL 3.0 nadal mogą być dostępne wraz z tymi przestarzałymi funkcjami, jednak prosząc o pełny kontekst .

Przestarzałe funkcje obejmują:

  • Wszystkie przetwarzanie wierzchołków i fragmentów o stałej funkcji
  • Renderowanie w trybie bezpośrednim przy użyciu glBegin i glEnd
  • Wyświetl listy
  • Obiekty docelowe renderowania indeksowanych kolorów
  • Język cieniowania OpenGL w wersjach 1.10 i 1.20

OpenGL 3.1

Data wydania : 24 marca 2009 r.

OpenGL 3.1 całkowicie usunął wszystkie funkcje, które zostały przestarzałe w wersji 3.0, z wyjątkiem szerokich linii. Od tej wersji nie jest możliwy dostęp do nowych funkcji przy użyciu pełnego kontekstu ani nieaktualnych funkcji przy użyciu kontekstu zgodnego do przodu . Wyjątek od poprzedniej reguły jest tworzony, jeśli implementacja obsługuje rozszerzenie ARB_compatibility , ale nie jest to gwarantowane.

Sprzęt: Mesa obsługuje ARM Panfrost w wersji 21.0.

OpenGL 3.2

Data wydania : 3 sierpnia 2009 r.

OpenGL 3.2 dalej opiera się na mechanizmach deprecjacji wprowadzonych przez OpenGL 3.0, dzieląc specyfikację na profil podstawowy i profil zgodności . Konteksty zgodności obejmują wcześniej usunięte interfejsy API o stałych funkcjach, odpowiadające rozszerzeniu ARB_compatibility wydanemu wraz z OpenGL 3.1, podczas gdy konteksty podstawowe nie. OpenGL 3.2 zawierał również aktualizację do wersji GLSL 1.50.

OpenGL 3.3

Data wydania: 11 marca 2010

Mesa obsługuje oprogramowanie Driver SWR, softpipe i starsze karty Nvidia z NV50. D3D12 to nowa emulacja rozszerzenia Microsoft WSL do korzystania z Direct 12.

OpenGL 4.0

Data wydania : 11 marca 2010

OpenGL 4.0 został wydany wraz z wersją 3.3. Został zaprojektowany dla sprzętu obsługującego Direct3D 11.

Podobnie jak w OpenGL 3.0, ta wersja OpenGL zawiera dużą liczbę dość nieistotnych rozszerzeń, zaprojektowanych w celu dokładnego ujawnienia możliwości sprzętu klasy Direct3D 11. Poniżej wymieniono tylko najbardziej wpływowe rozszerzenia.

Obsługa sprzętu: Nvidia GeForce z serii 400 i nowsze, AMD Radeon HD z serii 5000 i nowsze (shadery FP64 zaimplementowane przez emulację na niektórych GPU TeraScale), grafika Intel HD w procesorach Intel Ivy Bridge i nowsze.

OpenGL 4.1

Data wydania : 26 lipca 2010

Obsługa sprzętu: Nvidia GeForce z serii 400 i nowsze, AMD Radeon HD z serii 5000 i nowsze (shadery FP64 zaimplementowane przez emulację na niektórych GPU TeraScale), grafika Intel HD w procesorach Intel Ivy Bridge i nowsze.

  • Minimalny „maksymalny rozmiar tekstury” to 16 384 × 16 384 dla GPU implementujących tę specyfikację.

OpenGL 4.2

Data wydania: 8 sierpnia 2011

  • Obsługa shaderów z licznikami atomowymi i operacjami load-store-atomic read-modify-write do jednego poziomu tekstury
  • Rysowanie wielu wystąpień danych przechwyconych z przetwarzania wierzchołków GPU (w tym teselacji), aby umożliwić wydajną zmianę położenia i replikację złożonych obiektów
  • Obsługa modyfikowania dowolnego podzbioru skompresowanej tekstury bez konieczności ponownego pobierania całej tekstury na GPU w celu znacznej poprawy wydajności

Obsługa sprzętu: Nvidia GeForce z serii 400 i nowsze, AMD Radeon HD z serii 5000 i nowsze (shadery FP64 zaimplementowane przez emulację na niektórych procesorach graficznych TeraScale) oraz Intel HD Graphics w procesorach Intel Haswell i nowszych. (Linux Mesa: Ivy Bridge i nowsze)

OpenGL 4.3

Data wydania: 6 sierpnia 2012

  • Obliczenia shaderów wykorzystujące równoległość GPU w kontekście potoku graficznego
  • Obiekty bufora pamięci Shadera, umożliwiające shaderom odczytywanie i zapisywanie obiektów bufora, takich jak ładowanie/zapisywanie obrazów z wersji 4.2, ale za pośrednictwem języka, a nie wywołań funkcji.
  • Zapytania dotyczące parametrów formatu obrazu
  • Kompresja tekstur ETC2/EAC w standardzie
  • Pełna kompatybilność z interfejsami API OpenGL ES 3.0
  • Możliwość debugowania do odbierania komunikatów debugowania podczas tworzenia aplikacji
  • Widoki tekstur umożliwiające interpretację tekstur na różne sposoby bez replikacji danych
  • Zwiększone bezpieczeństwo pamięci i odporność na wiele aplikacji

Obsługa sprzętu: AMD Radeon HD 5000 Series i nowsze (shadery FP64 zaimplementowane przez emulację na niektórych procesorach graficznych TeraScale), grafika Intel HD w procesorach Intel Haswell i nowsze. (Linux Mesa: Ivy Bridge bez teksturowania szablonu, Haswell i nowsze), Nvidia GeForce z serii 400 i nowsze. Emulacja VIRGL dla maszyn wirtualnych obsługuje wersję 4.3+ z Mesa 20.

OpenGL 4.4

Data wydania: 22 lipca 2013 r.

  • Wymuszone kontrole użycia obiektów bufora
  • Zapytania asynchroniczne do obiektów buforowych
  • Ekspresja większej liczby kontrolek układu zmiennych interfejsu w shaderach
  • Wydajne wiązanie wielu obiektów jednocześnie

Obsługa sprzętu: AMD Radeon HD z serii 5000 i nowsze (shadery FP64 zaimplementowane przez emulację na niektórych procesorach graficznych TeraScale), Intel HD Graphics w procesorach Intel Broadwell i nowsze (Linux Mesa: Haswell i nowsze), Nvidia GeForce z serii 400 i nowsze, Tegra K1 .

OpenGL 4,5

Data wydania: 11 sierpnia 2014

  • Direct State Access (DSA) — metody dostępu do obiektów umożliwiają odpytywanie i modyfikowanie stanu bez wiązania obiektów z kontekstami, co zwiększa wydajność i elastyczność aplikacji i oprogramowania pośredniczącego.
  • Kontrola opróżniania — aplikacje mogą kontrolować opróżnianie oczekujących poleceń przed przełączeniem kontekstu — umożliwiając wysokowydajne aplikacje wielowątkowe;
  • Solidność — zapewnia bezpieczną platformę dla aplikacji, takich jak przeglądarki WebGL, w tym zapobieganie resetowaniu GPU mającemu wpływ na inne uruchomione aplikacje;
  • OpenGL ES 3.1 API i kompatybilność z shaderami – aby umożliwić łatwe tworzenie i uruchamianie najnowszych aplikacji OpenGL ES na komputerach stacjonarnych.

Obsługa sprzętu: AMD Radeon HD 5000 Series i nowsze (shadery FP64 zaimplementowane przez emulację na niektórych GPU TeraScale), Intel HD Graphics w procesorach Intel Broadwell i nowsze (Linux Mesa: Haswell i nowsze), Nvidia GeForce 400 seria i nowsze, Tegra K1 , i Tegra X1.

OpenGL 4.6

Data wydania: 31 lipca 2017 r.

Obsługa sprzętu: AMD Radeon HD 7000 Series i nowsze (shadery FP64 zaimplementowane przez emulację na niektórych procesorach graficznych TeraScale), Intel Haswell i nowsze, Nvidia GeForce z serii 400 i nowsze.

Wsparcie kierowcy:

  • Mesa 19.2 w systemie Linux obsługuje OpenGL 4.6 dla Intel Broadwell i nowszych. Mesa 20.0 obsługuje procesory graficzne AMD Radeon, podczas gdy obsługa Nvidia Kepler+ jest w toku. Zink jako Emulation Driver z 21.1 i sterownikiem programowym LLVMpipe również obsługuje Mesa 21.0.
  • Sterownik graficzny AMD Adrenalin 18.4.1 dla systemu Windows 7 SP1 , 10 wersja 1803 (aktualizacja z kwietnia 2018 r.) dla AMD Radeon™ HD 7700+, HD 8500+ i nowszych. Wydany w kwietniu 2018 r.
  • Sterownik graficzny Intel 26.20.100.6861 w systemie Windows 10 . Wydany w maju 2019 r.
  • Sterownik graficzny NVIDIA GeForce 397,31 tylko w systemie Windows 7 , 8 , 10 x86-64- bit, brak obsługi 32-bitów . Wydany w kwietniu 2018

Wdrożenia alternatywne

Apple wycofał OpenGL w iOS 12 i macOS 10.14 Mojave na rzecz Metal , ale nadal jest dostępny od macOS 11 Big Sur (w tym urządzeń krzemowych Apple ). Najnowsza wersja obsługiwana przez OpenGL to 4.1 z 2011 roku. Zastrzeżona biblioteka Molten – autorów MoltenVK – o nazwie MoltenGL, może tłumaczyć wywołania OpenGL na Metal.

Istnieje kilka projektów, które próbują zaimplementować OpenGL na Vulkan. Backend Vulkan dla Google ANGLE osiągnął zgodność z OpenGL ES 3.1 w lipcu 2020 r. Projekt Mesa3D zawiera również taki sterownik o nazwie Zink .

Przyszłość OpenGL

W czerwcu 2018 r. firma Apple wycofała interfejsy API OpenGL na wszystkich swoich platformach ( iOS , macOS i tvOS ), mocno zachęcając programistów do korzystania z ich zastrzeżonego interfejsu Metal API , który został wprowadzony w 2014 r.

Systemy operacyjne Fuchsia i Stadia obsługują tylko Vulkan

17 września 2021 Valve usunął OpenGL z Dota 2

Wszystkie nowe gry z 2016 roku oparte na silniku ID Tech 6 Game wykorzystują Vulkan

Silnik gier ID Tech 7 obsługuje tylko Vulkan

Atypical Games, przy wsparciu Samsunga, podjęło się zadania implementacji obsługi Vulkan w swoim silniku. W końcu stało się jasne, że wdrożenie Vulkan faktycznie zastąpi OpenGL na wszystkich platformach innych niż Apple.

Vulkan

Vulkan, poprzednio nazywany „Inicjatywą OpenGL nowej generacji” (glNext), to od podstaw próba przeprojektowania mająca na celu ujednolicenie OpenGL i OpenGL ES w jeden wspólny interfejs API, który nie będzie wstecznie kompatybilny z istniejącymi wersjami OpenGL.

Pierwsza wersja Vulkan API została wydana 16 lutego 2016 r.

Zobacz też

Bibliografia

Dalsza lektura

Zewnętrzne linki