Z wyjątkiem OpenGL, nigdy nie korzystałem z tych bibliotek, ale spróbuję zgadnąć, czytając strony wikipedii, tak jak ty.
Masz rację co do Mesy. Oto dodatkowe informacje, które mamy:
„System X Window to system oprogramowania komputerowego i protokół sieciowy, które zapewniają podstawowe interfejsy GUI dla komputerów w sieci. Tworzy warstwę abstrakcji sprzętowej”.
„GLX umożliwia programom, które chcą używać OpenGL, robić to w oknie zapewnianym przez X Window System.
GLX składa się z trzech części:
- API, który zapewnia funkcje OpenGL.
- Rozszerzenie protokołu X, który pozwala klientowi wysyłać 3D polecenia renderowania - rozszerzenie serwera X, który odbiera polecenia renderowania od klienta i przekazuje je do zainstalowanej biblioteki OpenGL.
Jeśli klient i serwer działają na tym samym komputerze i dostępna jest przyspieszona karta graficzna 3D, poprzednie dwa komponenty mogą być pomijane przez DRI. Następnie program kliencki może uzyskać bezpośredni dostęp do sprzętu graficznego. ”
„Infrastruktura bezpośredniego renderowania (DRI) to interfejs używany w systemie X Window, umożliwiający aplikacjom dostęp do sprzętu wideo bez konieczności przesyłania danych przez serwer X.”
„Open Inventor to API grafiki 3D C ++ zaprojektowane, aby zapewnić wyższą warstwę programowania dla OpenGL”
Aby uprościć sprawę, wyobraźmy sobie uproszczony przepływ danych (i poleceń), który ma miejsce przy wejściach i wyjściach każdego z tych interfejsów API. Na samym początku mamy Twój program aplikacyjny (skompilowany kod), który uruchamiasz ze swojego komputera. Na koniec mamy obrazy, które są wyświetlane na ekranie.
Istnieje kilka przypadków, które ograniczę się do odpowiedzi na te pytania:
-Czy twój komputer ma kartę graficzną (GPU) lub tylko procesor do przetwarzania funkcji graficznych?
-Czy Twoja aplikacja jest osadzona w oknie systemu X-Window?
- jeśli korzystasz z systemu x Window, czy „x serwer” działa na twoim komputerze lub na innym komputerze w sieci?
Zakładam, że masz sterowniki do swojego GPU, jeśli go masz, i że masz Mesa do renderowania oprogramowania).
Pierwszy scenariusz: uruchamiasz aplikację graficzną napisaną za pomocą OpenInventor, bez korzystania z systemu X Window, i nie masz karty graficznej. Przebieg programu byłby podobny do:
Your application
↓ (uses functions of)
OpenInventor
↓ (calls functions declared by)
OpenGL
↓ (redirects function calls to implementation defined by)
Mesa
↓ (implemented OpenGL functions to be run on the CPU)
[Probably] Operating System rendering API
↓
3D Images on your screen
To, co się tutaj dzieje, nazywa się „renderowaniem oprogramowania”: polecenie graficzne nie jest obsługiwane przez żaden sprzęt graficzny, ale zamiast zwykłego procesora, procesora, który zazwyczaj uruchamia oprogramowanie.
Drugi scenariusz: wyobraź sobie teraz, że przy takich samych warunkach jak powyżej masz kartę graficzną. Przepływ wyglądałby bardziej tak:
Your application
↓ (uses functions of)
OpenInventor
↓ (calls functions declared by)
OpenGL
↓ (redirects function calls to implementation defined by)
Proprietary Drivers
↓ (converts OpenGL commands to GPU commands)
Graphic Card
↓
3D Images on your screen
To, co dzieje się teraz, nazywa się „przyspieszaniem sprzętowym”, zwykle szybszym niż pierwszy scenariusz.
Trzeci scenariusz: teraz przedstawmy przepływ X Window System, a przynajmniej tak mi się wydaje, w oparciu o kilka przeczytanych wierszy z Wikipedii.
Na chwilę zapomnijmy o sprzęcie graficznym i interfejsie API. Przepływ powinien wyglądać następująco:
Your application (X Window System sees it as an "X Client")
↓ (sends requests defined by the X Window System Core Protocol)
X Server
↓ (convert your request to graphic commands)
[Probably] Operating System rendering API
↓
Windows or 2D images on your screen
Należy pamiętać, że podczas korzystania z systemu X Window ekran i komputer, z którego uruchamiana jest aplikacja, mogą nie być „bezpośrednio” podłączone, ale mogą być połączone przez sieć.
Czwarty scenariusz: załóżmy, że chcesz dodać fantazyjne renderingi 3D do aplikacji X Client z poprzedniego przykładu. Wydaje mi się, że X Window System początkowo nie jest w stanie tego zrobić, a przynajmniej wymagałoby znacznie bardziej skomplikowanego kodu do wykonania odpowiednika funkcji API OpenGL.
Na szczęście możesz użyć GLX, aby dodać obsługę poleceń OpenGL do systemu. Teraz masz:
Your application
↓ (sends graphic requests defined by the "GLX extension to the X Protocol")
X Server with the GLX extension
↓ (convert your request to OpenGL commands)
OpenGL
↓ (redirects function calls to implementation defined by)
...
Teraz możesz ponownie połączyć ostatnią strzałkę ze strzałką po „OpenGL” w pierwszym scenariuszu: możesz wyświetlać obrazy 3D na ekranie!
Wreszcie o tym, co myślę o DRI:
Wydaje się, że pozwala Mesa na dostęp do GPU, co zmodyfikuje przebieg naszego pierwszego scenariusza w:
...
↓
Mesa
↓ (forwards OpenGL commands)
DRI
↓ (converts OpenGL commands to GPU commands)
Graphic Card
↓
3D Images on your screen
Wydaje się również, że powoduje zwarcie przepływu podczas korzystania z GLX, pod warunkiem, że jego serwer i klient znajdują się na tym samym komputerze i że masz procesor graficzny. W takim przypadku wykres naszego czwartego scenariusza stałby się po prostu:
Your application
↓ (sends graphic requests defined by the "GLX extension to the X Protocol")
DRI
↓ ("catches" OpenGL commands and converts them to GPU commands)
Graphic Card
↓
3D Images on your screen
Otóż to !
Teraz pamiętaj, że nie jestem ekspertem w środowiskach uniksowych, więc moją najlepszą radą jest przestudiowanie dokumentacji każdego z tych interfejsów API, aby dokładnie wiedzieć, co mogą zrobić.
Połączenie poprzedniego wykresu w jeden może ułatwić zrozumienie. Pozwalam ci to ćwiczyć!