Odpowiedź na to pytanie jest prawie niemożliwa, ponieważ sam OpenGL jest tylko interfejsem API typu front-end i tak długo, jak implementacja jest zgodna ze specyfikacją, a wynik jest zgodny z tym, można to zrobić w dowolny sposób.
Pytanie mogło brzmieć: jak działa sterownik OpenGL na najniższym poziomie. Teraz znowu nie można odpowiedzieć na to ogólnie, ponieważ sterownik jest ściśle powiązany z jakimś sprzętem, który może znowu działać tak, jak zaprojektował go programista.
Zatem pytanie powinno brzmieć: „Jak to średnio wygląda za kulisami OpenGL i systemu graficznego?”. Spójrzmy na to od dołu do góry:
Na najniższym poziomie jest jakieś urządzenie graficzne. W dzisiejszych czasach są to GPU, które zapewniają zestaw rejestrów kontrolujących ich działanie (które dokładnie są zależne od urządzenia), mają trochę pamięci programowej dla shaderów, pamięć masową na dane wejściowe (wierzchołki, tekstury itp.) Oraz kanał I / O dla reszty systemu, przez który odbiera / wysyła strumienie danych i poleceń.
Sterownik karty graficznej śledzi stan procesorów GPU i wszystkie zasoby aplikacji korzystających z GPU. Odpowiada również za konwersję lub jakiekolwiek inne przetwarzanie danych wysyłanych przez aplikacje (konwertowanie tekstur do formatu pikseli obsługiwanego przez GPU, kompilowanie shaderów w kodzie maszynowym GPU). Ponadto zapewnia abstrakcyjny, zależny od sterownika interfejs do programów użytkowych.
Jest też zależna od sterownika biblioteka / sterownik klienta OpenGL. W systemie Windows ładuje się to przez proxy przez opengl32.dll, w systemach Unix znajduje się w dwóch miejscach:
- Moduł X11 GLX i sterownik GLX zależny od sterownika
- a /usr/lib/libGL.so może zawierać pewne elementy zależne od sterownika do bezpośredniego renderowania
W systemie MacOS X jest to „OpenGL Framework”.
To właśnie ta część tłumaczy wywołania OpenGL, jak to robisz, na wywołania funkcji specyficznych dla sterownika w części sterownika opisanej w (2).
Wreszcie aktualna biblioteka API OpenGL, opengl32.dll w systemie Windows i na Unix /usr/lib/libGL.so; to głównie przekazuje polecenia do właściwej implementacji OpenGL.
Jak przebiega faktyczna komunikacja, nie można uogólniać:
W Uniksie połączenie 3 <-> 4 może się odbywać albo przez Sockets (tak, może i przechodzi przez sieć, jeśli chcesz) lub przez Shared Memory. W systemie Windows biblioteka interfejsów i klient sterownika są ładowane do przestrzeni adresowej procesu, więc to nie tyle komunikacja, ile proste wywołania funkcji i przekazywanie zmiennych / wskaźników. W MacOS X jest to podobne do Windows, tyle że nie ma oddzielenia między interfejsem OpenGL a klientem sterownika (to jest powód, dla którego MacOS X tak wolno nadąża za nowymi wersjami OpenGL, zawsze wymaga pełnej aktualizacji systemu operacyjnego, aby dostarczyć nowy struktura).
Komunikacja między 3 <-> 2 może przechodzić przez ioctl, odczytywać / zapisywać lub poprzez mapowanie pewnej pamięci do przestrzeni adresowej procesu i konfigurowanie MMU tak, aby wyzwalała kod sterownika, gdy tylko zmiany w tej pamięci są wykonywane. Jest to dość podobne w każdym systemie operacyjnym, ponieważ zawsze musisz przekroczyć granicę jądra / obszaru użytkownika: Ostatecznie przechodzisz przez wywołanie systemowe.
Komunikacja między systemem a GPU odbywa się za pośrednictwem magistrali peryferyjnej i definiowanych przez nią metod dostępu, czyli PCI, AGP, PCI-E itp., Które działają przez Port-I / O, Memory Mapped I / O, DMA, IRQ.