VirtualGL

VirtualGL
Wersja stabilna
2.6.5 / 18 listopada 2020 r . ; 2 lata temu ( 2020-11-18 )
Wersja podglądu
2.6.90 (3.0 beta1) / 16 czerwca 2021 r .; 20 miesięcy temu ( 2021-06-16 )
Napisane w C , C++ , Unix Shell
Licencja Powszechna licencja publiczna GNU (GPL), licencja biblioteki wxWindows
Strona internetowa www .virtualgl .org

VirtualGL to pakiet oprogramowania typu open source , który przekierowuje polecenia renderowania 3D z aplikacji Unix i Linux OpenGL do sprzętu akceleratora 3D na dedykowanym serwerze i wysyła wyrenderowane dane wyjściowe do ( cienkiego ) klienta znajdującego się w innym miejscu w sieci. Po stronie serwera VirtualGL składa się z biblioteki obsługującej przekierowanie oraz programu opakowującego, który instruuje aplikacje, aby korzystały z tej biblioteki. Klienci mogą łączyć się z serwerem za pomocą zdalnego połączenia X11 lub za pomocą serwera proxy X11, takiego jak Serwer VNC . W przypadku połączenia X11 potrzebne jest również oprogramowanie VirtualGL po stronie klienta, aby odbierać wyrenderowaną grafikę niezależnie od strumienia X11. W przypadku połączenia VNC nie jest potrzebne żadne specjalne oprogramowanie po stronie klienta poza samym klientem VNC.

Problem

Wydajność aplikacji OpenGL można znacznie poprawić, renderując grafikę na dedykowanych akceleratorach sprzętowych, które są zwykle obecne w GPU . Procesory graficzne stały się tak powszechne, że aplikacje zaczęły na nich polegać, jeśli chodzi o akceptowalną wydajność. Ale VNC i inne środowiska cienkiego klienta dla systemów Unix i Linux nie mają dostępu do takiego sprzętu po stronie serwera. Dlatego albo w ogóle nie obsługują aplikacji OpenGL , albo uciekają się do wolniejszych metod, takich jak renderowanie na kliencie lub w oprogramowaniu na serwerze.

Zdalne wyświetlanie aplikacji 3D z akceleracją sprzętową tradycyjnie wymagało użycia „renderowania pośredniego”. Renderowanie pośrednie wykorzystuje GLX do systemu X Window („X11” lub „X”) do hermetyzacji poleceń OpenGL wewnątrz strumienia protokołu X11 i przesłać je z aplikacji do wyświetlacza X. Tradycyjnie aplikacja działa na zdalnym serwerze aplikacji, a wyświetlacz X działa na pulpicie użytkownika. W tym scenariuszu wszystkie polecenia OpenGL są wykonywane przez komputer stacjonarny użytkownika, więc komputer ten musi mieć szybki akcelerator grafiki 3D. Ogranicza to typ maszyny, która może zdalnie wyświetlać aplikację 3D przy użyciu tej metody.

Renderowanie pośrednie może działać dobrze, jeśli sieć jest wystarczająco szybka ( na przykład Gigabit Ethernet ), jeśli aplikacja nie modyfikuje dynamicznie geometrii renderowanego obiektu, jeśli aplikacja korzysta z list wyświetlania i jeśli aplikacja nie używa dużego sprawa mapowania tekstur . Jednak wiele aplikacji OpenGL nie spełnia tych kryteriów. Aby jeszcze bardziej skomplikować sprawę, niektóre rozszerzenia OpenGL nie działają w środowisku renderowania pośredniego. Niektóre z tych rozszerzeń wymagają możliwości bezpośredniego dostępu do sprzętu grafiki 3D, dlatego nigdy nie można ich zmusić do działania pośredniego. W innych przypadkach wyświetlacz X użytkownika może nie zapewniać wyraźnej obsługi potrzebnego rozszerzenia OpenGL lub rozszerzenie może polegać na określonej konfiguracji sprzętowej, której nie ma na komputerze stacjonarnym użytkownika.

Wykonywanie renderowania OpenGL na serwerze aplikacji pozwala uniknąć problemów związanych z renderowaniem pośrednim, ponieważ aplikacja ma teraz szybką i bezpośrednią ścieżkę do sprzętu renderującego 3D. Jeśli renderowanie 3D odbywa się na serwerze aplikacji, do klienta należy wysłać tylko wynikowe obrazy 2D. Obrazy mogą być dostarczane z tą samą szybkością klatek, niezależnie od tego, jak duże były dane 3D użyte do ich wygenerowania, więc renderowanie 3D na serwerze aplikacji skutecznie przekształca problem z wydajnością 3D w problem z wydajnością 2D. Problem staje się wtedy, jak przesyłać strumieniowo 1-2 megapiksele danych obrazu przez sieć z interaktywną liczbą klatek na sekundę, ale popularne technologie ( żeby wymienić tylko HDTV ) już rozwiązują ten problem.

Rozwiązanie VirtualGL

VirtualGL używa „rozwidlenia GLX” do renderowania OpenGL na serwerze aplikacji. Aplikacje Unix i Linux OpenGL zwykle wysyłają zarówno polecenia GLX, jak i zwykłe polecenia X11 do tego samego wyświetlacza X. Polecenia GLX są używane do wiązania kontekstów renderowania OpenGL z określonym oknem X, uzyskiwania listy formatów pikseli obsługiwanych przez wyświetlacz X itp. VirtualGL wykorzystuje funkcję w systemach Unix i Linux, która pozwala na „wstępne załadowanie” biblioteki do aplikacja, skutecznie przechwytująca (AKA „wstawiająca”) pewne wywołania funkcji, które aplikacja normalnie wykonywałaby w bibliotekach współdzielonych z którym jest powiązany. Gdy VirtualGL zostanie wstępnie załadowany do aplikacji Unix lub Linux OpenGL, przechwytuje wywołania funkcji GLX z aplikacji i przepisuje je w taki sposób, że odpowiednie polecenia GLX są wysyłane do wyświetlacza X serwera aplikacji („3D X Server”), który prawdopodobnie ma dołączony akcelerator sprzętowy 3D. W ten sposób VirtualGL zapobiega wysyłaniu poleceń GLX przez sieć do wyświetlacza X użytkownika lub do wirtualnego wyświetlacza X („X proxy”), takiego jak VNC, który nie obsługuje GLX. W procesie przepisywania wywołań GLX VirtualGL przekierowuje również renderowanie OpenGL do pozaekranowych buforów pikseli („Pbuffers”). Tymczasem reszta wywołań funkcji z aplikacji, w tym zwykłe polecenia X11 używane do rysowania użytkownika aplikacji interfejs, mogą przechodzić przez VirtualGL bez modyfikacji.

Wewnętrznie silnik interposera VirtualGL utrzymuje również mapę okien w buforach Pbuffer, dopasowuje atrybuty wizualne między docelowym wyświetlaczem X („serwerem 2D X”) a serwerem X 3D oraz wykonuje szereg innych funkcji haszujących, aby zapewnić, że przekierowanie GLX jest bez szwu. Ale zasadniczo, gdy kontekst OpenGL zostanie ustanowiony na wyświetlaczu X serwera aplikacji, VirtualGL usunie się z drogi i pozwoli wszystkim kolejnym poleceniom OpenGL przejść bez przeszkód do sprzętu 3D serwera aplikacji. Dzięki temu aplikacja może automatycznie korzystać z dowolnych funkcji i rozszerzeń OpenGL udostępnianych przez sprzęt i sterowniki serwera aplikacji.

Oprócz kierowania komend GLX i zarządzania buforami Pbuffer, VirtualGL odczytuje również wyrenderowane piksele w odpowiednim czasie (zwykle poprzez monitorowanie funkcji glXSwapBuffers() lub glFinish() ), a następnie rysuje te piksele w oknie X aplikacji za pomocą standardowych poleceń rysowania obrazu X. Ponieważ VirtualGL przekierowuje polecenia GLX z dala od 2D X Server, można go użyć do dodania przyspieszonej obsługi 3D do serwerów proxy X (takich jak VNC), a także do zapobiegania występowaniu pośredniego renderowania OpenGL podczas korzystania ze zdalnego wyświetlacza X.

Podczas korzystania z X11 Transport z serwerem proxy X, zarówno renderowanie 3D, jak i 2D odbywa się na serwerze aplikacji. VirtualGL przekierowuje polecenia 3D z aplikacji do akceleratora 3D, odczytuje renderowane obrazy i rysuje je jako serię nieskompresowanych map bitowych do serwera proxy X (VNC lub podobnego systemu). Tymczasem polecenia rysowania 2D (polecenia X11 ) z aplikacji są wysyłane bezpośrednio do serwera proxy X. Serwer proxy X jest wyłącznie odpowiedzialny za kompresję obrazów i wysyłanie ich do zdalnych klientów.

Korzystanie z VirtualGL w porozumieniu z VNC lub innym serwerem proxy X umożliwia wielu użytkownikom jednoczesne uruchamianie aplikacji 3D na jednym serwerze aplikacji i wielu klientom współdzielenie każdej sesji. Jednak VNC i jemu podobni są dostrojeni do obsługi aplikacji 2D z dużymi obszarami jednolitego koloru, kilkoma kolorami i kilkoma różnicami między klatkami. Z kolei aplikacje 3D generują obrazy o drobnoziarnistej, złożonej kolorystyce i znacznie mniejszej korelacji między kolejnymi klatkami. Obciążenie generowane przez rysowanie wyrenderowanych obrazów z aplikacji OpenGL w oknie X jest zasadniczo takie samo jak w przypadku odtwarzacza wideo, a gotowe oprogramowanie typu cienki klient zwykle nie ma wystarczająco szybkiego obrazu kodeków , aby móc poradzić sobie z tym obciążeniem przy interaktywnych szybkościach klatek.

VirtualGL rozwiązuje ten problem na dwa sposoby:

  1. TurboVNC
  2. Transport VGL

TurboVNC i TigerVNC

TurboVNC i TigerVNC to odgałęzienia TightVNC , które przyspieszają kodowanie Tight i JPEG, częściowo za pomocą libjpeg-turbo, wersji libjpeg z akceleracją SIMD . Oba projekty udostępniają serwery VNC oraz aplikacje klienckie.

TurboVNC został opracowany przez ten sam zespół co VirtualGL. W Ethernet o przepustowości 100 megabitów może wyświetlać ponad 50 megapikseli na sekundę z percepcyjnie bezstratną jakością obrazu. TurboVNC zawiera dalsze optymalizacje, które pozwalają mu wyświetlać 10–12 megapikseli na sekundę przez łącze szerokopasmowe 5 megabitów, z zauważalnie niższą, ale użyteczną jakością obrazu. TurboVNC rozszerza również TightVNC o podwójne buforowanie po stronie klienta i inne funkcje przeznaczone dla aplikacji 3D, takie jak możliwość wysyłania bezstratnej kopii obrazu ekranu w okresach bezczynności. TurboVNC i VirtualGL są używane przez Texas Advanced Computing Center na University of Texas w Austin, aby umożliwić użytkownikom TeraGrid zdalny dostęp do możliwości renderowania 3D Stampede Visualization Cluster.

TigerVNC to nowszy rozwidlenie TightVNC, które zapewnia taką samą wydajność jak TurboVNC, ale działa lepiej w innych aspektach.


Transport VGL

Podczas korzystania z transportu VGL renderowanie 3D odbywa się na serwerze aplikacji, ale renderowanie 2D odbywa się na komputerze klienckim. VirtualGL kompresuje wyrenderowane obrazy z aplikacji 3D i wysyła je jako strumień wideo do klienta, który dekompresuje i wyświetla strumień wideo w czasie rzeczywistym.

Podczas korzystania z VGL Transport, VirtualGL kompresuje renderowane obrazy 3D w procesie przy użyciu tego samego zoptymalizowanego kodeka JPEG, którego używa TurboVNC. Następnie VirtualGL wysyła skompresowane obrazy przez dedykowane gniazdo TCP do aplikacji klienckiej VirtualGL uruchomionej na komputerze klienckim. Klient VirtualGL jest odpowiedzialny za dekompresję obrazów i rysowanie pikseli w odpowiednim oknie X. Tymczasem elementy wyświetlania aplikacji inne niż OpenGL są przesyłane przez sieć przy użyciu standardowego zdalnego protokołu X11 i renderowane na komputerze klienckim.

Takie podejście wymaga obecności wyświetlacza X na komputerze klienckim, a poleganie na zdalnym protokole X11 do wykonywania renderowania 2D oznacza, że ​​wiele aplikacji będzie działać słabo podczas korzystania z transportu VGL w sieciach o dużych opóźnieniach. Ponadto VGL Transport z natury nie obsługuje współpracy (wielu klientów na sesję), ponieważ obrazy są przesyłane do maszyn użytkowników, a nie pobierane. Jednak korzystanie z transportu VGL zapewnia całkowicie bezproblemową obsługę aplikacji, w której każde okno aplikacji odpowiada pojedynczemu oknu pulpitu. Transport VGL zmniejsza również obciążenie procesora serwera korzystanie z zaawansowanych funkcji OpenGL, takich jak czterobuforowane stereo .

Twórcy VirtualGL przewidują, że głównymi użytkownikami VGL Transport będą użytkownicy laptopów z bezprzewodowym połączeniem 802.11g lub szybkim Ethernetem do serwera aplikacji.

Produkty komercyjne wykorzystujące VirtualGL

VirtualGL i TurboVNC były podstawowymi składnikami produktu Sun Visualization System firmy Sun Microsystems , który został wycofany w kwietniu 2009 r. Dwa pakiety open source zostały połączone z wtyczką o zamkniętym kodzie źródłowym , która umożliwiła VirtualGL wysyłanie skompresowanych obrazów do cienkich klientów Sun Ray i innych zamkniętych pakiet źródłowy, który integrował VirtualGL z Sun Grid Engine , zapewniając zarządzanie zasobami i planowanie zdalnych zadań 3D. Połączenie tych pakietów, nazwane „Sun Shared Visualization”, było dostępne do bezpłatnego pobrania. Firma Sun pobiera opłatę za wsparcie.

Wersja 4.xx NoMachine obsługuje VirtualGL, aby umożliwić użytkownikom uruchamianie aplikacji 3D w sesjach pulpitu NoMachine.

Wersja 2.1 oprogramowania Scalable Visualization Array firmy HP zawiera komponenty, które integrują się z VirtualGL i TurboVNC, umożliwiając planowanie zadań 3D i zdalne wyświetlanie ich z klastra wizualizacji.

Wersja 3.0.0 ThinLinc została zaprojektowana do pracy w połączeniu z VirtualGL.

Wersja 2010 EnginFrame Views obsługuje VirtualGL jako jedną z opcji protokołu zdalnego.

Produkty Exceed onDemand i Exceed Freedom firmy OpenText używają kodu z VirtualGL do implementacji renderowania po stronie serwera.

Zobacz też

przypisy

Ogólne odniesienia

Linki zewnętrzne

Pobrano z „ https://en.wikipedia.org/w/index.php?title=VirtualGL&oldid=1047384324 ”