OpenGL 4.2
Wprowadzenie
Janusz Ganczarski
www.januszg.hg.pl
Wstęp
W tym odcinku kursu poznamy niezbędne wiadomości wstępne dotyczące historii oraz
podstaw budowy i działania biblioteki OpenGL. Czytelnik znajdzie tutaj także uzasadnienie do
konwencji przyjętej w dalszej części kursu.
Historia OpenGL
Specyfikacja pierwszej wersji biblioteki OpenGL (ang. Open Graphics Library) została
opublikowana 1 czerwca 1992 roku na bazie języka GL opracowanego przez firmę Silicon Graphics
Inc. (SGI) na potrzeby stacji graficznych IRIS. Początkiem sukcesu OpenGL stała się jednak dopiero
wersja 1.1, opublikowana 4 marca 1997 roku, którą zaimplementowano m.in. w systemach z rodziny
Microsoft Windows. Kolejne wersje biblioteki (1.2, 1.3, 1.4, 1.5, 2.0, 2.1, 3.0, 3.1, 3.2, 3.3, 4.0, 4.1 i
najnowsza 4.2 z 8 sierpnia 2011 roku) są znakomitą ilustracją rozwoju sprzętu graficznego i tendencji
w programowym generowaniu grafiki.
Przez tych kilkadziesiąt lat jedną z głównych idei twórców OpenGL była zgodność wstecz
biblioteki. W praktyce programy przygotowane dla wcześniejszych wersji biblioteki działały
prawidłowo także na jej najnowszych implementacjach. Drugą zasadą OpenGL jest jej
wieloplatformowość  programy z niej korzystające działają praktycznie na wszystkich współczesnych
systemach operacyjnych. Cechy te są miarą sukcesu OpenGL, która jest obecnie podstawową
niskopoziomowÄ… bibliotekÄ… graficznÄ… 3D, standardem powszechnie wykorzystywanym przez
producentów oprogramowania użytkowego i gier.
Od początku rozwojem OpenGL zajmowała się ARB (ang. Architecture Review Board), w skład
której wchodzili przedstawiciele najważniejszych firm z branży komputerowej. Taki sposób
wprowadzania zmian w bibliotece zapewnia OpenGL zachowanie niezależności od jednej platformy
sprzętowej lub programowej przy jednoczesnym uwzględnieniu najnowszych osiągnięć w dziedzinie
grafiki komputerowej. Oczywiście współpraca wielu firm, o często sprzecznych interesach, nie zawsze
przebiegała idealnie. Producenci sprzętu graficznego promowali własne rozwiązania,
niekompatybilne z rozwiązaniami konkurencji, a spory wewnątrz ARB powodowały opóz
nienia w
przygotowywaniu nowych wersji specyfikacji.
Od 2006 roku rolę opiekuna OpenGL przejął Khronos Group, który rozwija także inne otwarte
standardy programistyczne. Początkowo krytykowany za opóz
nienia, Khronos Group w drugiej
połowie 2008 roku wprowadził specyfikację wersji 3.0 i krótko po tym opublikowane zostały kolejne
wersje OpenGL oznaczone numerami 3.1 i 3.2. EwolucjÄ™ OpenGL zaproponowanÄ… przez Khronos
Group opiszemy nieco dalej, z kilkuletniej perspektywy wydaje się jednak, że zmiana ta wywarła
pozytywny wpływ na tempo i kierunek rozwoju biblioteki. Tempo zmian widać także na przykładzie
szybkości dalszego rozwoju OpenGL. Wersje 3.3 i 4.0 opublikowano, po raz pierwszy w historii
OpenGL, w tym samym czasie  11 marca 2010 roku. Krótko potem pojawiła się wersja 4.1 biblioteki.
Natomiast na kolejną i obecnie najnowszą wersję OpenGL 4.2 trzeba było czekać ponad rok.
Rozszerzenia
Jednym z najczęściej dyskutowanych mechanizmów OpenGL są rozszerzenia. Rozszerzenia
określają dodatkowe możliwości implementacji biblioteki i mogą dotyczyć najróżnorodniejszych jej
elementów. Zaletą tego mechanizmu jest dostępność z poziomu OpenGL najnowszych możliwości
sprzętu graficznego, ale jest jednocześnie to także wada. Rozszerzenia proponowane przez niektóre
firmy nie były implementowane przez inne (czasami wynikało to jednak z braku możliwości
technicznych), co czyniło rozszerzenia mechanizmem niepewnym w zastosowaniach komercyjnych.
Mimo tych wad rozszerzenia na trwałe wpisały się w bibliotekę OpenGL i stanowią ważny mechanizm
wspomagający jej rozwój.
OpenGL 3.0 - rewolucja przez ewolucjÄ™
Wspomniana wcześniej wersja 3.0 biblioteki OpenGL zapoczątkowała zupełnie nowe
podejście do dotychczas obowiązujących zasad. Twórcy standardu zauważyli bowiem, że dalsze
utrzymywanie tak rozbudowanej i w znacznej części przestarzałej funkcjonalności nie znajduje
praktycznego uzasadnienie. Wyodrębniono liczną grupę tzw. funkcji przestarzałych, która została
wytypowana do usunięcia w przyszłych wersjach specyfikacji. Wskazuje to na generalną tendencję
ewolucji OpenGL  stopniowe usuwanie przestarzałych jej elementów i zastępowanie ich
nowoczesnymi programowalnymi mechanizmami.
Kolejną nowością w bibliotece OpenGL 3.0 jest wymuszenie na twórcach systemów
okienkowych utworzenia funkcji obsługujących nowy kontekst renderingu. Związane jest to z
zupełnie nową w bibliotece OpenGL koncepcją profilowania kontekstów renderingu oraz
planowanym cyklem usuwania z biblioteki przestarzałych mechanizmów. W przyszłości planowane są
profile przeznaczone do rozrywki, tworzenia dokumentów i stron WWW, obsługi aplikacji
desktopowych, czy też dedykowane do urządzeń mobilnych. Warto zauważyć, że ARB zastrzegła
sobie wyłączność do tworzenia profili OpenGL. Sposób obsługi nowego kontekstu renderingu musi
umożliwiać aplikacji wskazanie konkretnego profilu niezbędnego do działania programu. Zauważmy,
że brak nowego kontekstu renderingu przy redukcji funkcjonalności OpenGL, mógłby doprowadzić w
przyszłości do błędów przy uruchamianiu starszych programów.
Początkowo wersja 3.0 OpenGL spotkała się z dość chłodnym przyjęciem ze strony
środowiska programistycznego. Wśród głównych zarzutów pojawiały się tezy o braku pełnej
rezygnacji z przestarzałych funkcji oraz braku modelu obiektowego. Wszystko to było związane z
oczekiwaniami na zupełnie nowe API biblioteki. Całkiem słusznie niezadowolenie wzbudzało także
wielomiesięczne opóz
nienie w prezentacji specyfikacji biblioteki.
Analiza decyzji Khronos Group wskazuje jednak, że podjęto bardzo racjonalne decyzje. Na
obecnym etapie rozwoju biblioteki nie była możliwa rezygnacja z całej jej dotychczasowej
funkcjonalności. Zbyt dużo jest bowiem na rynku oprogramowania z tego korzystającego  w grę
wchodzą choćby niezwykle skomplikowane aplikacje inżynierskie i naukowe. Wprowadzenie nowego
kontekstu renderingu, mechanizmu profili oraz redukcji funkcjonalności ułatwi stopniowe
przechodzenie do przyszłych wersji biblioteki.
OpenGL 3.1  dalszy etap rewolucji przez ewolucjÄ™
Kolejna odsłona biblioteki OpenGL pojawiła się bardzo szybko (oczywiście w porównaniu do
poprzednich standardów w tym zakresie) i stanowi kolejny istotny krok w jej rozwoju. Zdecydowano
się na usunięcie wszystkich funkcji określonych w wersji 3.0 jako przestarzałe, choć pozostawiono
jeszcze dodatkową furtkę w postaci rozszerzenia GL_ARB_compatibility, które zawiera wszystkie
usunięte funkcje. Dzięki temu API stał się znacznie mniejsze, co widać choćby po objętości
specyfikacji. Pełna jej wersja obejmująca opis funkcji przestarzałych to blisko 500 stron, a właściwa
zajmuje nieco ponad 350 stron.
Usunięcie przestarzałej funkcjonalności znaczne uprościło bibliotekę i jednocześnie ułatwiło
jej stosowanie. Jednak z ułatwień tych w pełni skorzystają jedynie twórcy nowych aplikacji, którzy od
początku zdecydują się korzystanie wyłącznie z nowoczesnych rozwiązań oferowanych przez OpenGL
3.0/3.1.
OpenGL 3.2  szybka ewolucja
OpenGL 3.2 to kolejny etap rewolucji przez ewolucję. Specyfikacja została opublikowana
nieco ponad cztery miesiące po upublicznieniu wersji 3.1 i wnosi szereg nowych możliwości do
biblioteki, w tym: tekstury wielopróbkowania, shadery geometrii, obiekty synchronizacji, restart
prymitywu i wierzchołki główne prymitywów. Jedną z bardziej praktycznych zmian jest zdefiniowanie
dwóch profili: podstawowego, obejmującego tylko nieusuniętą funkcjonalność i kompatybilnego,
zgodnego ze wszystkim poprzednimi wersjami OpenGL. Nie zmieniono przy tym praktycznie
funkcjonalności określonych jako przestarzałe, co wskazuje na pewną stabilizację w dalszym kierunku
rozwoju biblioteki.
OpenGL w wersji 3.2 bez rozszerzeń można w pełni porównywać z ówczesnym jej
odpowiednikiem, tj. bibliotekÄ… DirectX 10.0, a wraz z zaaprobowanymi przez ARB rozszerzeniami:
GL_ARB_draw_buffers_blend, GL_ARB_sample_shading, GL_ARB_texture_cube_map_array,
GL_ARB_texture_gather i GL_ARB_texture_query_lod z bibliotekÄ… DirectX w wersji 10.1.
OpenGL 3.3  ostatnie podejście do zgodności z DirectX 10.0
Specyfikacja biblioteki OpenGL 3.3 to ostatnie spojrzenie na możliwości oferowane prze karty
graficzne zgodne w biblioteką DirectX 10.0. Wprowadzone zamiany, jak bezpośrednia adresacja
atrybutów wierzchołków w języku GLSL, zamiana składowych tekstury przed próbkowaniem, liczniki
czasu, czy też nowe formaty atrybutów wierzchołków i formatów tekstur, służą głownie ułatwieniu
przenoszenia programów pomiędzy DirectX a OpenGL. Znamienna jest także data opublikowania
specyfikacji OpenGL 3.3, która zbiegła się z prezentacją OpenGL 4.0. W ten sposób dokonano
podziału wprowadzonych modyfikacji biblioteki na te obsługiwane przez karty graficzne zgodne z
DirectX 10.0 i te wymagające kart następnej generacji, obsługujących DirectX 11.0.
OpenGL 4.0  obsługa kolejnej generacji sprzętu
Wersja 4.0 biblioteki OpenGL to kolejny duży krok w jej rozwoju. Autorzy nadrobili zaległości
w stosunku do bezpośredniego konkurenta i szybko przedstawili odpowiednik DirectX 11.0, z
najważniejsza nowością: sprzętową teselacją (kafelkowaniem) prymitywów. Wśród innych nowości
można wymienić dodanie pełnej obsługi 64-bitowych typów danych, nowe formaty tekstur
buforowych, nowe formaty kompresji tekstur oraz rozbudowę mechanizmów transformacji
sprzężonych zwrotnie. Jednocześnie odpowiednio zmodyfikowano GLSL dodając dwa nowe rodzaje
programów cieniowania kontrolujące teselację, które operują na ścieżkach (zbiorach) wierzchołków
wraz z ich atrybutami: shader kontroli teselacji (ang. tesselation control shader) i shader ewaluacji
teselacji (ang. tessellation evaluation shader). Równolegle z wprowadzeniem technik dostępnych w
DirectX 11.0 w OpenGL 4.0 dodano mechanizmy znane z DirectX 10.1, m.in. tablice tekstur
sześciennych oraz rozszerzone tryby mieszania kolorów.
OpenGL 4.1  integracja z OpenGL ES 2.0
Wersja 4.1 biblioteki OpenGL została opublikowana w krótkim odstępie po wersji 4.0.
Najważniejsza zmianą jest wprowadzenie kompatybilności z biblioteką OpenGL ES 2.0, czyli wersją
OpenGL przeznaczonÄ… na platformy mobilne. Ten nieco zaskakujÄ…cy kierunek zmian nie jest jednak
przypadkowy  OpenGL ES 2.0 stało się podstawą technologii WebGL udostępniającej trójwymiarowe
API graficzne w przeglądarkach internetowych. Zatem integracja OpenGL ES 2.0 w OpenGL 4.1 ułatwi
zadanie twórcom implementacji WebGL w przeglądarkach internetowych. Ponadto wersja 4.1
OpenGL zawiera m.in. obsługę 64-bitowych danych atrybutów wierzchołków i możliwość
przechowywania shaderów w postaci binarnej.
OpenGL 4.2  szereg nowych funkcjonalności
Najnowsza obecnie wersja biblioteki OpenGL 4.2 została opublikowana nieco ponad rok od
wersji ją poprzedzającej. Wprowadzono w niej kilka istotnych nowości: liczniki atomowe, atomowe
operacje zapisu/odczytu na wybranych elementach określonej warstwy tekstury, rozbudowa
transformacji sprzężonych zwrotnie o możliwość przechwytywania danych wierzchołków po wyjściu z
teselatora, możliwość modyfikacji wybranego podzbioru danych skompresowanej tekstury bez
konieczności jej ponownego ładowania, ładowanie 8- i 16-bitowych danych do 32-bitowych
zmiennych w celu przyspieszenia transferu danych między shaderami, możliwość pobrania
wewnętrznego formatu danych tekstury oraz umożliwienie współpracy shaderów modyfikujących
głębię z wcześniejszym testem głębokości. Całość wprowadzonych zmian została ujęta w
rozszerzenia, których część może być także obsługiwana przez karty graficzne starszej generacji.
GLSL
Język programów cieniowania OpenGL GLSL (ang. OpenGL Shading Language), zwanymi
najczęściej shaderami, został wprowadzony w wersji 2.0 biblioteki, a od wersji 3.1 stanowi
podstawowy element potoku renderingu zarówno na etapie przetwarzania wierzchołków jak i
fragmentów. Sam język GLSL sukcesywnie ewoluował wraz z kolejnymi wersjami OpenGL. Aktualnie
jego najnowszą wersją jest 4.20, która odpowiada możliwościom tzw. Shader Model 5.0 języka HLSL z
biblioteki DirectX 11.0. Profil podstawowy biblioteki OpenGL 4.2 obsługuje także wcześniejsze wersje
GLSL, poczÄ…wszy od wersji 1.40 (OpenGL 3.1).
Język GLSL jest opisany w odrębnej specyfikacji, która tworzy spójną całość ze specyfikacją
podstawowego API biblioteki OpenGL.
PowiÄ…zania z systemami okienkowymi
Biblioteka OpenGL wymaga wsparcia API systemu okienkowego do tworzenia i zarzÄ…dzania
kontekstami graficznymi, renderingu w oknie oraz obsługi innych zasobów. Wszystkie liczące się
współczesne systemy operacyjne posiadają API obsługujące bibliotekę OpenGL. W systemie X
Window, dostępnym głównie pod Unix i Linux, jest to GLX. Warto także wspomnieć, że
implementacje GLX istnieją również w systemach Microsoft Windows, MacOS X i kilku innych
platformach, na których jest dostępny X Serwer. OpenGL w systemach Microsoft Windows
obsługiwany jest przez WGL. Quartz, warstwa graficzna systemu MacOS X, zawiera kilka interfejsów
API obsługujących OpenGL. Są to CGL, AGL i NSGLView. Natomiast na platformy mobilne
przeznaczona jest biblioteka EGL, która współpracuje z OpenGL ES 2.0, ale może także obsłużyć
standardowy OpenGL.
Oczywiście stosowanie rozwiązań specyficznych dla danego systemu operacyjnego powoduje,
że danego programu nie można skompilować i uruchomić w innym systemie operacyjnym bez
dokonania szeregu zmian w kodzie z
ródłowym. Rozwiązanie tego problemu stanowią biblioteki
oferujące jeden, niezależny od systemu operacyjnego, interfejs do obsługi okien i komunikatów.
Pierwszą biblioteką tego typu była biblioteka AUX (ang. Auxiliary Library), jednak bodaj największą
popularność zdobyła biblioteka GLUT (ang. OpenGL Utility Toolkit), opracowana i rozwijana w latach
1994-1998 przez Marka J. Kilgarda. Pomimo sędziwego wieku jest ona ciągle powszechnie stosowana.
Typy danych
Typy danych w obsługiwane przez bibliotekę OpenGL przedstawia Tabela 1. Specyfikacja nie
określa jakiego rodzaju typy danych są użyte w konkretnej implementacji, zawiera jedynie minimalne
wymagania związane z precyzją i wykonywaniem operacji na całkowitych i zmiennoprzecinkowych
typach danych. W szczególności implementacja może używać typów danych o większej ilości bitów
niż minimalne wskazane we wspomnianej wyżej tabeli. Typy GLintptr, GLsizeiptr i GLsync
mają ilość bitów opisaną jako prtbits, co oznacza minimalną ilość bitów niezbędną w danej
implementacji do umieszczenia wskaz
nika. Typy te muszą umożliwić zapamiętanie dowolnego
adresu. Trzeba także wyraz
nie podkreślić, że typy danych OpenGL nie są typami danych
występującymi w języku C (pomimo częściowej zgodności nazw). Zatem przykładowo, typ GLint
niekoniecznie jest równoznaczny z typem int w C. Ponadto, poza wymienionymi typami, funkcje
OpenGL korzystajÄ… z typu pustego GLvoid.
Typ GL Minimalna ilość Opis
bitów
GLboolean
1 lub więcej typ logiczny
GLbyte
8 liczba całkowita ze znakiem w kodzie uzupełnień do 2
GLubyte
8 liczba całkowita bez znaku
GLchar
8 znaki tworzÄ…ce ciÄ…gi
GLshort
16 liczba całkowita ze znakiem w kodzie uzupełnień do 2
GLushort
16 liczba całkowita bez znaku
GLint
32 liczba całkowita ze znakiem w kodzie uzupełnień do 2
GLuint
32 liczba całkowita bez znaku
GLfixed
32
dwie 16-bitowe liczby całkowite ze znakiem w kodzie uzupełnień
do 2 (odpowiednik liczb zmiennoprzecinkowych)
GLint64 64
liczba całkowita ze znakiem w kodzie uzupełnień do 2
GLuint64 64
liczba całkowita bez znaku
GLsizei
32 nieujemna liczba całkowita
GLenum
32 typ wyliczeniowy
GLintptr
ptrbits liczba całkowita ze znakiem w kodzie uzupełnień do 2
GLsizeiptr
ptrbits nieujemna liczba całkowita
GLsync uchwyt obiektu synchronizacji
ptrbits
GLbitfield
32 pole bitowe
GLhalf
16 liczba zmiennoprzecinkowa połówkowej precyzji zakodowana
jako skalar bez znaku
GLfloat
32 liczba zmiennoprzecinkowa
GLclampf
32 liczba zmiennoprzecinkowa ograniczona do przedziału
GLdouble
64 liczba zmiennoprzecinkowa podwójnej precyzji
GLclampd
64 liczba zmiennoprzecinkowa podwójnej precyzji ograniczona do
przedziału
Tabela 1 Typy danych w bibliotece OpenGL.
Arytmetyka zmiennoprzecinkowa
W przypadku liczb zmiennoprzecinkowych (GLfloat i GLdouble) specyfikacja OpenGL nie
określa sposobu ich reprezentacji, zawiera jedynie minimalne wymagania dla implementacji
biblioteki. W szczególności implementacja może stosować arytmetykę zmiennoprzecinkową zgodną
ze standardem IEEE 754. Wymagania nie obejmują obsługi dodatniej i ujemnej nieskończoności
( oraz , oznaczenia matematyczne odpowiednio i ) oraz symboli nieoznaczonych
(ang. not a number), np. . Nieco inaczej sprawa wygląda w przypadku języka GLSL, gdzie
stosowne są liczby zmiennoprzecinkowe zgodne z wymienionym wyżej standardem IEEE 754.
Nieco inaczej sytuacja wygląda w przypadku liczb zmiennoprzecinkowych połówkowej
precyzji (GLhalf), gdzie specyfikacja OpenGL określa format liczb. 16-bitowe liczby
zmiennoprzecinkowe ze znakiem mają 1 bit znaku ( ), 5 bitów wykładnika ( ) oraz 10 bitów mantysy
( ). Wartość takiej liczby jest określana następująco:
Jeżeli liczba typu GLhalf jest interpretowana jako 16-bitowa liczba całkowita bez znaku ,
to wartość znaku, wykładnika i mantysy wynosi odpowiednio:
 Warto także zwrócić uwagę, że niektóre formaty pikseli korzystają z liczb
zmiennoprzecinkowych bez znaku korzystające z 11 lub 10 bitów. Formaty te opiszemy bliżej w
odcinku kursu OpenGL poświęconemu teksturom.
Składnia poleceń
Polecenia OpenGL są funkcjami lub procedurami. Różne grupy poleceń wykonują tę samą
operację, lecz różnią się sposobem w jaki dostarczane są do nich argumenty. Ogólnie rzecz biorąc,
deklaracja polecenia posiada formÄ™:
rtype Name{1|2|3|4}{b|s|i|i64|f|d|ub|us|ui|ui64}{v}( [args ,] T arg1, & ,
T argN [, args] );
Polecenia OpenGL są zbudowane z nazwy, po której następuje, w zależności od konkretnego
przypadku, maksymalnie do 4 znaków. rtype jest typem zwracanym przez funkcję. Nawiasy {}
dołączają szereg znaków (lub zestawów znaków), z których tylko jeden jest używany. Pierwszy znak
{1|2|3|4} oznacza liczbę wartości wskazanego typu, które muszą być przedstawione do
polecenia. Drugi znak lub zestaw znaków {b|s|i|i64|f|d|ub|us|ui|ui64} wskazuje
konkretne rodzaje argumentów: 8-bitowe liczby całkowite, 16-bitowe liczby całkowite, 32-bitowe
liczby całkowite, 64-bitowe liczby całkowite, liczby zmiennoprzecinkowe pojedynczej precyzji lub
liczby zmiennoprzecinkowe podwójnej precyzji  patrz Tabela 2. Zauważmy, że wskazując na typ bez
znaku dodajemy literę u na początku tego nazwy typu (na przykład unsigned byte jest skracany
do ubyte). Ostatni znak {v}, jeśli jest obecny, wskazuje, że polecenie zawiera wskaz
nik do tablicy
(wektora) wartości, a nie serię poszczególnych argumentów.
Litera OdpowiadajÄ…cy typ OpenGL
b GLbyte
s GLshort
i GLint
GLint64
i64
f GLfloat
d GLdouble
ub GLubyte
us GLushort
ui GLuint
ui64 GLuint64
Tabela 2 Powiązanie sufiksów poleceń OpenGL z typami argumentów. Patrz Tabela 1 z definicjami typów OpenGL.
Argumenty poleceń umieszczone w nawiasach [args ,] i [, args] mogą, ale nie muszą
być obecne. N argumentów od arg1 do argN ma typ T, który odpowiada jednemu ze znaków lub
parze znaków wskazanych w Tabela 2. Jeśli ostatnim znakiem nie jest v, to N jest podane przez znaki
{1|2|3|4} (jeśli ich nie ma, to liczba argumentów jest ustalona). Jeśli ostatnim znakiem jest v, to
jest obecny tylko argument arg1 i jest nim tablica N wartości wskazanego typu. Argumenty, których
typ jest stały (tzn. nie wskazany przez sufiks polecenia) są jednym z typów danych OpenGL zawartych
w Tabela 1 lub wskaz
nikami do jednego z tych typów.
Przykładowo grupa funkcji glUniform* w specyfikacji OpenGL jest opisywana następująco:
void Uniform{1234}{if}( int location, T value );
co wskazuje osiem deklaracji funkcji, przedstawionych poniżej w notacji ANSI C:
void Uniform1i( int location, int value );
void Uniform1f( int location, float value );
void Uniform2i( int location, int v0, int v1 );
void Uniform2f( int location, float v0, float v1 );
void Uniform3i( int location, int v0, int v1, int v2 );
void Uniform3f( int location, float v0, float v2, float v2 );
void Uniform4i( int location, int v0, int v1, int v2, int v3 );
void Uniform4f( int location, float v0, float v1, float v2,
float v3 );
W dalszej części kursu będziemy używać pełnych deklaracji funkcji w języku ANSI C, jednak
prezentacja zasad budowy poleceń OpenGL ułatwi Czytelnikowi samodzielne zgłębianie specyfikacji
biblioteki.
Obsługa błędów
Biblioteka OpenGL zawiera mechanizmy obsługi błędów. Jednak z założenia wykrywanych
jest tylko część sytuacji spośród zbioru warunków, które mogłyby być uważane za błędy. Stanowi to
kompromis na rzecz efektywności, ponieważ w wielu przypadkach kontrola błędów miałby
niekorzystny wpływ na wydajność programu wolnego od błędów.
Informację o kodzie bieżącego błędu zwraca funkcja:
GLenum glGetError( void );
Zestawienie zwracanych kodów błędów zawiera Tabela 3. Działanie OpenGL jest
niezdefiniowane tylko w przypadku wystąpienia błędu o kodzie GL_OUT_OF_MEMORY. W
pozostałych przypadkach błąd nie powoduje przerwania wykonywania programu, nie jest
wykonywana jedynie funkcja odpowiedzialna za jego powstanie. Polecenie takie na ma wpływu na
stan OpenGL lub zawartość bufora ramki. Jeśli polecenie generujące błąd zwraca wartości, zwracana
jest wartość zero. Jeśli polecenie generujące błąd zmienia wartości poprzez wskaz
nik do argumentu,
nie są dokonywane zmiany tych wartości.
Kod błędu Opis Czy błędne polecenie
jest ignorowane?
GL_INVALID_ENUM
Argument GLenum Tak
poza zakresem
GL_INVALID_VALUE
Argument liczbowy poza Tak
zakresem
GL_INVALID_OPERATION
Nielegalna operacja w Tak
bieżącym stanie
GL_INVALID_FRAMEBUFFER_OPERATION
Niekompletny obiekt Tak
bufora ramki
GL_OUT_OF_MEMORY
Brak pamięci do Nieokreślone
wykonania polecenia
GL_NO_ERROR
Brak błędu -
Tabela 3 Zestawienie kodów błędów OpenGL.
Kiedy błąd zostanie wykryty, ustawiana jest flaga błędu i rejestrowany jest jego kod. Jeżeli
występują kolejne błędy nie wpływają one na ten zarejestrowany kod. Dopiero, gdy wywołana jest
funkcja glGetError, zwracany jest kod błędu i czyszczona jest flaga tak, aby kolejny błąd mógł być
zarejestrowany. Jeżeli glGetError zwraca GL_NO_ERROR oznacza to, że od ostatniego
wywołania glGetError (lub od kiedy GL został zainicjowany) nie był wykryty żaden błąd.
Implementacja może przechowywać więcej niż jedną informację o błędzie. W takim przypadku
wywołanie glGetError zwraca kody kolejnych zarejestrowanych błędów, tak długo aż nie zostanie
zwrócona wartość GL_NO_ERROR.
Typowy kod odczytujący błędy zgłaszane przez bibliotekę OpenGL ma postać poniższej pętli:
GLenum error;
while( ( error = glGetError() ) != GL_NO_ERROR )
{
// obsługa błędu
}
Ogólne warunki generowania błędów przedstawione są poniżej:
·ð JeÅ›li polecenie wymagajÄ…ce wartoÅ›ci wyliczeniowej okreÅ›lonej, jako staÅ‚a symboliczna
otrzymuje wartość, która nie należy do dopuszczalnych dla tego polecenia, generowany jest
błąd GL_INVALID_ENUM.
·ð JeÅ›li przekazywana jest ujemna liczba, a typ argumentu jest okreÅ›lony, jako GLsizei lub
GLsizeiptr, zostanie wygenerowany błąd GL_INVALID_VALUE.
·ð JeÅ›li ubocznym efektem wykonania polecenia jest wyczerpanie pamiÄ™ci, może być
wygenerowany błąd GL_OUT_OF_MEMORY.
W innych wypadkach, błędy generowane są tylko na warunkach, które są wyraz
nie opisane w
specyfikacji biblioteki OpenGL.
Operacje OpenGL i potok renderingu
OpenGL koncentruje się jedynie na renderingu do bufora ramki oraz czytaniu wartości
zapisanych w tym buforze. Biblioteka nie ma wsparcia dla innych urządzeń, takich jak myszy i
klawiatury, stąd trzeba używać innych mechanizmów w celu przetworzenia informacji
wprowadzanych przez użytkownika.
Rysunek 1 przedstawia schemat działania OpenGL. Z lewej strony diagramu wprowadzane są
polecenia OpenGL. Niektóre z nich określają obiekty geometryczne, które mają zostać narysowane,
inne kontrolują obsługę obiektów przez różne etapy renderingu. Polecenia zawsze są przetwarzane w
kolejności, w jakiej zostały przekazane do OpenGL, a ewentualne opóz
nienie realizacji skutków
danego polecenia nie mogą mieć wpływu na wyniki póz
niejszych poleceń. To samo dotyczy operacji
pobierania zmiennych stanu zapytania i odczytu pikseli, które zwracają stan odpowiadający
kompletnemu wykonaniu wszystkich wcześniej wywoływanych poleceń OpenGL (poza przypadkami
wyraz
nie określonymi w specyfikacji). OpenGL wiąże dane w chwili wywoływania polecenia, a
wszelkie póz
niejsze zmiany danych nie mają wpływu na jego wynik.
Rysunek 1 Diagram blokowy potoku renderingu OpenGL (z
ródło: specyfikacja OpenGL).
 Pierwszy etap potoku renderingu operuje na prymitywach geometrycznych: punktach,
segmentach linii i wielokątach, które są opisane przez wierzchołki. W tym etapie wierzchołki są
przekształcane i oświetlane, a prymitywy są obcinane do bryły widoku w celu przygotowania do
następnego etapu, rasteryzacji. Możliwe jest także programowe lub sprzętowe generowanie nowych
prymitywów, a także usuwanie istniejących. Rasteryzator generuje szereg fragmentów - elementów
bufora ramki używanych do dwuwymiarowego opisu punktów, segmentów linii lub wielokątów.
Każdy tak wyprodukowany fragment jest przekazywany do następnego etapu, gdzie wykonywane są
operacje na poszczególnych fragmentach przed finalnym zapisem w buforze ramki. Operacje na
buforze ramki obejmują m.in. obsługę wartości bufora głębokości, mieszanie kolorów oraz
maskowanie i inne operacje logiczne na wartościach fragmentów. Dane bufora ramki mogą być
również odczytywane lub kopiowane pomiędzy różnymi częściami bufora ramki.
OpenGL wykorzystuje dwa rodzaje buforów ramek: domyślny bufor ramki obsługiwany i
kontrolowany wyłącznie przez system okienkowy (np. za pomocą jednej z opisanych wcześniej
bibliotek) oraz obiekty bufora ramki tworzone i kontrolowane przez aplikacje.
Biblioteka OpenGL wykorzystuje model działania klient-serwer. W typowym przypadku
klientem OpenGL jest aplikacja wykorzystujÄ…ca polecenia OpenGL, a serwerem OpenGL aktualnie
używana implementacja biblioteki (np. w sterowniku karty graficznej), przetwarzająca polecenia
przesłane przez klienta. Serwer OpenGL może, ale nie musi działać na tym samym komputerze co
klient OpenGL.
Biblioteka OpenGL została zaprojektowana jako biblioteka wieloplatformowa, z założenia
przeznaczona do obsługi wielu rodzajów sprzętu graficznego. Stąd specyfikacja OpenGL zawiera opis
zalecanych rozwiązań dla określonych poleceń, z wyraz
nie wskazanymi możliwymi od nich
odstępstwami. Wspomniane dopuszczalne wariacje implementacji OpenGL powodują, że
poszczególne implementacje nie muszą być zgodne "piksel do piksela", tzn. ten sam zestaw danych
z
ródłowych i poleceń nie musi w różnych implementacjach dać identycznego końcowego rezultatu w
buforze ramki.
Zmienne stanu i maszyna stanu
Zmienne stanu (ang. state) są ważnym wewnętrznym elementem OpenGL opisującym
ustawienia biblioteki. Wiele zmiennych stanu jest dwustanowych, inne mają wartości całkowite lub
zmiennoprzecinkowe. Wszystkie zmienne stanu tworzą tzw. maszynę stanów (ang. state machine),
która steruje zachowaniem OpenGL.
Wyróżniamy dwa rodzaje zmiennych stanu. Pierwszy typ, zwany zmiennymi serwera OpenGL,
znajduje się w serwerze OpenGL. Większość zmiennych stanu OpenGL wchodzi w skład tej kategorii.
Drugi typ, zwany zmiennymi klienta OpenGL, znajduje się w kliencie OpenGL. Każdy egzemplarz
kontekstu OpenGL zawiera jeden pełny zestaw zmiennych stanu serwera OpenGL. Natomiast każde
połączenie od klienta do serwera zawiera odrębny zbiór zmiennych stanu zarówno klienta jak i
serwera OpenGL.
Specyfikacja przewiduje możliwość współdzielenia niektórych zmiennych stanu w ramach
różnych kontekstów renderingu. Tą tematyką zajmiemy się na końcu kursu przy opisie obsługi wielu
kontekstów renderingu w ramach jednej aplikacji OpenGL.
Zmienne stanu modyfikowane są, w sposób jawny lub nie, przez polecenia biblioteki OpenGL,
które będziemy poznawać w dalszych odcinkach kursu. Natomiast do odczytu zmiennych stanu służy
bardzo liczna grupa funkcji glGet*, z których najbardziej podstawowe są następujące funkcje:
void glGetBooleanv( GLenum pname, GLboolean *params );
void glGetIntegerv( GLenum pname, GLint *params );
void glGetInteger64v( GLenum pname, GLint64 *params );
void glGetFloatv( GLenum pname, GLfloat *params );
void glGetDoublev( GLenum pname, GLdouble *params );
 Parametr pname określa, którą wartość maszyny stanów OpenGL chcemy pobrać (wszystkie
zmienne stanu przedstawiamy w odrębnym odcinku kursu), a params wskaz
nik na zwracanÄ…
wartość. W zależności od rodzaju pobieranej zmiennej tablica params może zawierać pojedynczą
zmienną lub tablicę zmiennych. Program musi zapewnić odpowiednią ilość miejsca w pamięci.
Zauważmy, że rodzaj zwracanej lub zwracanych wartości jednoznacznie określa końcowa część nazwy
funkcji.
Podobna grupa funkcji obsługuje tzw. indeksowane zmienne stanu, których wartości mogą
różnić się dla poszczególnych indeksów zawartych w parametrze index:
void glGetBooleani_v( GLenum target, GLuint index,
GLboolean *data );
void glGetIntegeri_v( GLenum target, GLuint index, GLint *data );
void glGetInteger64i_v( GLenum target, GLuint index,
GLint64 *data );
void glGetFloati_v( GLenum target, GLuint index, GLfloat *data );
void glGetDoublei_v( GLenum target, GLuint index, GLdouble *data );
Dostępne są jeszcze dwie funkcje pobierające informacje o włączeniu lub wyłączeniu danej
właściwości maszyny stanu OpenGL (dwuwartościowe zmienne stanu). Pierwsza z nich obsługuje
pojedyncze właściwość wskazaną w parametrze cap, druga właściwość indeksowaną, której indeks
zawiera parametr index (właściwość może mieć różną wartość dla różnych indeksów).
GLboolean glIsEnabled( GLenum cap );
GLboolean glIsEnabledi( GLenum target, GLuint index );
Włączanie i wyłącznie zmiennych stanu określających dwustanowe właściwości maszyny
stanu umożliwiają poniższe funkcje:
void glDisable( GLenum cap );
void glEnable( GLenum cap );
void glEnablei( GLenum target, GLuint index );
void glDisablei( GLenum target, GLuint index );
które w wersji indeksowej działają na zmiennej o indeksie wskazanym w parametrze index.
Podczas odczytu i zapisu zmiennych stanu OpenGL może zachodzić konieczność dokonania
konwersji (np. zmienna stanu jest typu całkowitego a odczytujemy dane typu
zmiennoprzecinkowego). W takich przypadkach OpenGL dokonuje konwersji stosując następujące
zasady:
·ð dla zmiennej stanu typu GLboolean caÅ‚kowita lub zmiennoprzecinkowa liczba o wartoÅ›ci 0
jest konwertowana na wartość GL_FALSE, a każda niezerowa liczba na wartość GL_TRUE,
·ð dla zmiennej stanu typu caÅ‚kowitego lub typu wyliczeniowego GLenum, wartoÅ›ci logiczne
GL_FALSE i GL_TRUE konwertowane są odpowiednio do wartości 0 i 1; liczby
zmiennoprzecinkowe są zaokrąglane do najbliższej liczby całkowitej,
·ð dla zmiennej stanu typu zmiennoprzecinkowego, wartoÅ›ci logiczne GL_FALSE i GL_TRUE
konwertowane są odpowiednio do wartości 0,0 i 1,0; liczby całkowite są bezpośrednio
konwertowane do liczby zmiennoprzecinkowej.
Wykorzystane w powyższym opisie stałe GL_TRUE i GL_FALSE to odpowiedniki słów
zarezerwowanych true i false z języka C++. Stałe te mają odpowiednio wartość 1 i 0.
Przyjęte w kursie konwencje i zasady
Programy w kursie zasadniczo wymagają dostępności biblioteki OpenGL w wersji 4.2, ale w
wielu przypadkach wystarczy dostępność wersji 4.1 lub 4.0. Przy ich pisaniu wykorzystano nowe
funkcje zarządzające kontekstem OpenGL, co powoduje, że programy nie mogą być bezpośrednio
uruchamiane na starszych niż 3.0 wersjach biblioteki. Jednakże część z nich, po odpowiednich
modyfikacjach, może działać z OpenGL 2.0/2.1. Programy przykładowe przy tworzeniu okien
korzystają bezpośrednio z Motif (systemu UNIX i Linux) oraz API WIN32 (systemy Microsoft
Windows). Fragmenty programu specyficzne dla danego systemu operacyjnego sÄ… oddzielone od
elementów korzystających z biblioteki OpenGL, co ułatwi Czytelnikowi ewentualną migrację
programu na wybranÄ… platformÄ™ systemowÄ… lub programowÄ….
Wszystkie programy napisane są przy użyciu języka C++ i kompilowane za pomocą
kompilatorów: Microsoft Visual C++ 2008 EE i GCC 4.4 w systemie Linux Mandriva 2010. Programy
testowano na karcie graficznej NVidia GeForce GTX 460. W przypadku programów napisanych w
OpenGL ES 2.0 używana jest biblioteka EGL i emulator pochodzący z pakietu PowerVR Insider SDK.
Do kompilacji programów nie są wymagane żadne dodatkowe zewnętrzne biblioteki. Jednak
najczęściej używane funkcje zostały pogrupowane w odrębne pliki, które mogą stanowić przydatną
podręczną bibliotekę.