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ć!
OpenGL jest niezależny od platformy; oznacza to, że OpenGL API jest niezależny od platformy.
Stany i bufory OpenGL są gromadzone przez obiekt abstrakcyjny, zwany potocznie kontekstem.
Platforma hostingowa jest odpowiedzialna za dostarczenie API do stworzenia kontekstu OpenGL dla platformy bazowej. W systemie Windows są procedury wgl * (Windows dla GL), w systemie Unix są procedury glX * (GL dla X).
Rzeczywiście GLX to nic innego jak interfejs API, który pozwala aplikacji na tworzenie kontekstu OpenGL w celu korzystania z interfejsu API OpenGL.
Typowe operacje WGL / GLX to tworzenie okna, tworzenie bufora poza ekranem, uaktywnianie kontekstu OpenGL w wątku, zamiana buforów rysowania ...
Zamiast tego DRI jest warstwą jądra, która pozwala na bezpośrednią komunikację z kartą graficzną, omijając XServer, faktycznie przyspieszając aplikację przy użyciu procedur OpenGL.
źródło
http://www.bitwiz.org.uk/s/how-dri-and-drm-work.html
Infrastruktura bezpośredniego renderowania, znana również jako DRI, stanowi platformę umożliwiającą bezpośredni dostęp do sprzętu graficznego w systemie X Window w bezpieczny i wydajny sposób. Obejmuje zmiany w serwerze X, kilku bibliotekach klienckich i jądrze (DRM, Direct Rendering Manager). Najważniejszym zastosowaniem DRI jest tworzenie szybkich implementacji OpenGL zapewniających przyspieszenie sprzętowe dla Mesa. Kilka sterowników akcelerowanych 3D zostało napisanych zgodnie ze specyfikacją DRI, w tym sterowniki dla chipsetów produkowanych przez 3DFX, AMD (wcześniej ATI), Intel i Matrox.
źródło
Krótko mówiąc, OpenGL jest typem i specyfikacją biblioteki graficznej. Mesa jest wszczepieniem podstawowym. DRI to sprzętowy system interfejsu.
Mesa w zasadzie odnosi się do całego frameworka. Zakładam jednak, że mówisz o sterowniku sprzętowym Mesa.
DRI jest w zasadzie interfejsem jądra do obsługi sprzętu. Technicznie można go używać do innych rzeczy, ale został stworzony dla Mesa i jest głównie używany do Mesa.
GLX jest jak to wszystko łączy się z X !!
Aby zrozumieć, co to jest każda część, musisz wiedzieć, jak do siebie pasuje.
Program przeznaczony jest do współpracy z dowolną biblioteką OpenGL.
GLX to sposób na połączenie OpenGL z X11 lub przez X11. W zależności od tego, czy masz interfejs „Bezpośredni” czy „Pośredni”, zależy od tego, czy Twój program będzie się tym martwić.
libGL to w zasadzie interfejs dla nich. Zazwyczaj zapewnia to Mesa, jeśli używasz sterownika Mesa.
W konfiguracji pośredniej wygląda to następująco: Framework aplikacji (tj. Aplikacja napisana na sztywno, silnik lub interfejs API abstrakcji) | LibGL | Mesa Driver | DRI | Sprzęt komputerowy
W tej konfiguracji GLX jest po prostu używany z boku do obsługi interfejsu między użytkowaniem GL twojego programu a innymi programami. Inne niż specyficzne wywołania GLX używane do wykonywania zadań wymagających komunikacji stos X11 i jego programy pomocnicze (takie jak Window Managers) GLX jest w dużej mierze nietknięty. w tym układzie.
Ponadto przekazywanie poleceń i pamięć współdzielona mogą służyć do dalszej optymalizacji warstw w tym systemie. To wszystko zmniejsza opóźnienia i poprawia szybkość dostępu do sprzętu. Tego zwykle chcesz.
Dla pośredniego jest to Twoja struktura aplikacji | LibGL (strona użytkownika) | LibGLX | LibGL (strona X11) | Sterownik sprzętowy Mesa | DRI | Sprzęt komputerowy
Zaletą tego jest to, że nie potrzebujesz bezpośredniego bufora pamięci współdzielonej ze sprzętem, aby korzystać z tej konfiguracji. (Umożliwiając klientom sieci, a także większą niezawodność i bezpieczniejszą konfigurację).
Ta konfiguracja może działać na wielu maszynach wirtualnych współużytkujących jedną kartę wideo lub nawet uzyskując dostęp do sieci z tego powodu. Niektóre formy pamięci współdzielonej lub wirtualnej wspólnej „sklonowanej” pamięci mogą być używane ze względu na nowsze rozszerzenia, ale nie jest to bezpośredni dostęp do pamięci wideo w trybie bezpośredniego renderowania.
Wadą jest to, że użycie rur lub gniazd sieciowych do interfejsu z X11 może być powolne, przynajmniej wprowadzając opóźnienia w dobrze zoptymalizowanych programach, aw najgorszym, drastycznie zmniejszając liczbę klatek na słabo zoptymalizowanych programach.
Tego rodzaju konfiguracja jest lepsza dla klientów sieciowych, konfiguracje wymagające bardziej niezawodnych zabezpieczeń oraz konfiguracje, w których wiele systemów operacyjnych musi współdzielić sprzęt, uruchamiając ten sam stos GL. Jest daleki od optymalnego, ale zapewnia pewne przyspieszenie sprzętowe.
źródło