| VirtualGL | |
|---|---|
| Skrivet i | C , C++ , Unix Shell |
| Operativ system | Linux , Unix |
| senaste versionen | 2.6.5 ( 18 november 2020 [1] ) |
| Testversion | 2.6.90 (3.0 beta1) ( 16 juni 2021 ) |
| Licens | GNU General Public License (GPL), wxWindows Library License |
| Hemsida | virtualgl.org |
VirtualGL är fri programvara som omdirigerar 3D-renderingskommandon från Unix- och Linux OpenGL - applikationer till en 3D-hårdvaruaccelerator på en dedikerad server och visar utdata interaktivt med hjälp av en tunn klient som finns någon annanstans i nätverket.
Vanligtvis har tunna klienter , som VNC och andra för Unix och Linux, antingen inte OpenGL- stöd för applikationer eller visas utan att använda OpenGL-hårdvaruacceleration. Fjärrrendering av hårdvaruaccelererade 3D - applikationer kräver traditionellt användning av "indirekt rendering".
Indirekt rendering använder tillägget av X Window System X11" eller "X") för att aktivera OpenGL-kommandon inom protokollen och arkitekturen för X Window System , och skicka dem från applikationen till X-skärmen. Traditionellt körs applikationer på en fjärransluten applikationsserver och X-skärmen körs på användarens dator. I det här fallet exekveras alla OpenGL-kommandon av användaren på datorns skrivbord, så maskinen måste ha en snabb 3D-grafikaccelerator. Detta begränsar typen av maskin som kan fjärrvisa 3D-applikationer med den här metoden.
Indirekt rendering kan användas om nätverket är tillräckligt snabbt (t.ex. Gigabit Ethernet ), om applikationen inte behöver ändra objektgeometrin dynamiskt, om applikationen använder visningslistor och om applikationen inte använder många texturer . Många OpenGL-applikationer uppfyller dock inte dessa kriterier. För att komplicera saken ytterligare fungerar vissa OpenGL-tillägg inte med indirekt rendering. Vissa av dessa tillägg kräver möjligheten att direkt komma åt 3D-hårdvaruacceleratorer och kan därför inte fungera indirekt. I andra fall kanske användare av X-skärmar inte ger stöd för OpenGL-tillägg, eller möjligheten att använda kan förlita sig på specifika hårdvarukonfigurationer som kanske inte finns på användarens dators arbetsstation.
Executive OpenGL-rendering på applikationsservern förbigår problem baserade på indirekt rendering, vilket är fallet för applikationer som för närvarande har snabb och direkt tillgång till hårdvaru -3D- rendering . Om 3D-rendering sker på applikationsservern kommer endast 2D-bilder att skickas till användarens arbetsplats som ett resultat. Bilder kan levereras med vilken bildhastighet som helst, oavsett hur mycket 3D-data som användes för att skapa dem, och all 3D-rendering och effektiva 3D-outputproblem översätts till 2D-visningsproblem. Detta problem uppstår också så snart det finns en ström av 1-2 megapixel grafikdata över ett nätverk med en variabel bildhastighet, till exempel inom teknik ( HDTV ).
VirtualGL använder separation för att överföra OpenGL-rendering till applikationsservern . OpenGL-applikationer för Unix (Linux) skickar vanligtvis båda typerna av GLX X11-kommandon och enkla kommandon till X-skärmen. GLX-kommandon används för att associera en OpenGL-renderingskontext med en kontext för ett specifikt X-fönster , få en lista över färgformat som en X-skärm stöder, etc. VirtualGL använder avancerade funktioner på Unix och Linux för att tillåta "pre-release"-bibliotek att laddas in i en applikation för effektiv avlyssning av vissa funktioner som applikationen kräver, och flyttas vanligtvis till de delade bibliotek som den är länkad till. När VirtualGL ansluter till en Unix- eller Linux OpenGL-applikation, fångar den upp GLX-funktionsanrop från applikationer och skriver om dem så att lämpliga GLX-kommandon skickas av X-skärmen till applikationsservern, som förmodligen har en hårdvaru-3D-accelerator. På detta sätt förhindrar VirtualGL GLX från att skicka kommandon över nätverket till en X-skärmanvändare eller till en virtuell X-skärm ("X -proxy "), såsom VNC, som inte stöder GLX. I processen att skriva om en GLX-begäran omdirigerar VirtualGL även OpenGL-rendering till pixelbuffertar utanför skärmen (Pbuffers). Samtidigt passerar andra funktioner som anropas från applikationer, inklusive de vanliga X11-kommandon som används för att utveckla en applikations användargränssnitt, genom VirtualGL oförändrat.
Den interna VirtualGL-motorn stöder även fönsterkartor för Pbuffers, bindande visuella attribut mellan den tilldelade X-skärmen och X-skärmen på vilken 3D-renderingen kommer att ske, och utför ett antal andra hashfunktioner för att säkerställa smidiga GLX-omdirigeringar. Men i huvudsak, när OpenGL-kontexten är inställd i X-skärmen och applikationsservern, får VirtualGL ett sätt att säkerställa att alla efterföljande OpenGL-kommandon från applikationsservern till 3D-hårdvaran passerar sömlöst. Således kan applikationen automatiskt använda alla OpenGL-funktioner och tillägg som stöds av serverns hårdvara och drivrutiner.
Förutom att sortera GLX- kommandon och hantera dem med vanligtvis genom att övervaka glXSwapBuffers()eller glFinish() , och hanterar sedan renderingen av pixlarna till ett X Window-program med hjälp av vanliga X-bildritningskommandon. VirtualGL omdirigerar GLX-kommandon från en avsedd X-skärm och kan användas för att lägga till 3D-accelerationsstöd till X-proxies (som VNC), såväl som för att förhindra indirekt OpenGL-rendering när en fjärransluten X-skärm används.
Genom att använda VirtualGL i kombination med VNC eller en annan X -proxy kan flera användare köra 3D-applikationer samtidigt på samma applikationsserver och flera klienter för att dela varje session. VNC och liknande program hanterar dock 2D-applikationer med stora områden med enfärgade, få färger och små ytor, medan 3D-applikationer å andra sidan genererar bilder med hög upplösning, komplexa färgmodeller och mycket mindre korrelation mellan på varandra följande ramar. . Att arbeta med i princip samma arbetsbelastning, använda rendering från OpenGL-applikationer i en X Window-miljö, såsom en videospelare, använda tunna klienter från hyllprogramvara, saknar vanligtvis också en tillräckligt snabb bildcodec för att kunna hantera interaktiva ramar.
VirtualGL löser dessa problem på två sätt:
TurboVNC är en gaffel av TightVNC som accelererar den senares Tight- och JPEG-kodningsvägar, delvis genom att dra fördel av inbyggda multimediaprimitiver från Intel och Sun Microsystems . På ett 100 Mbps Ethernet -nätverk kan TurboVNC visa helskärmsbilder (1280x1024 pixlar) med upplevd förlustfri bildkvalitet med över 20 bilder per sekund. TurboVNC inkluderar ytterligare optimeringar som gör att den kan visa helskärmsbilder med 7-10 fps över bredbandskanaler, med en betydande men användbar förlust i bildkvalitet. TurboVNC utökar också TightVNC till att inkludera dubbelbuffring på klientsidan och optimerade binärfiler för Solaris . TurboVNC och VirtualGL används vid UT Austin Computing Center för att tillåta TeraGrid- användare att fjärråtkomst till -klustrets
Med hjälp av VGL Image Transport, komprimerar VirtualGL renderade 3D-bilder i processen med samma JPEG:s optimerade codec som använder TurboVNC. VirtualGL skickar sedan de komprimerade bilderna över det egna TCP-protokollet till VirtualGL Client Application som körs på klientdatorn. VirtualGL-klienten ansvarar för att dekomprimera bilderna och rita in pixlarna i motsvarande X-fönster. Under tiden skickas OpenGL display icke-specifika element i en applikation över nätverket med hjälp av standard X11 fjärrprotokoll och exekveras på klientdatorn.
Detta tillvägagångssätt kräver att X-skärmar finns på klientdatorn, och beroendet av det fjärranslutna X11-protokollet för att göra den andra renderingen innebär att många applikationer kommer att fungera dåligt med VGL Image Transport på nätverk med hög latens. Dessutom stöder VGL Image Transport inte i sig samarbete (flera klienter per session) eftersom bilder placeras på användarnas datorer istället för att flyttas. Men att använda VGL Image Transport ger en helt sömlös applikationsupplevelse, där varje applikationsfönster motsvarar ett enda skrivbordsfönster. VGL Image Transport minskar också serverns CPU - belastning eftersom den andra renderingen sker på klienten, och VGL Image Transport tillåter användning av avancerade funktioner i OpenGL-specifikationen, såsom buffrad fyrbuffrad stereo.
Utvecklarna av VirtualGL introducerar de primära användarna av VGL Image Transport som användare av en bärbar dator med 802,11 g trådlös eller snabb Ethernet-nätverksanslutning med en applikationsserver.
VirtualGL och TurboVNC är kärnkomponenterna i Sun Visualization System- produkten från Sun Microsystems . Två paket med öppen källkod kombinerat med ett plugin med stängd källkod som gör att VirtualGL kan skicka komprimerade bilder till Sun Rays tunna klienter och andra paket med stängd källkod som integrerar VirtualGL med Sun Grid Engine , vilket ger resurshantering och 3D-grafik för fjärrskrivbord. Kombinationen av dessa paket, som kallas "Sun Shared Visualization", kan också laddas ner gratis (Sun tar endast betalt för support.)
Programvaran v2.1 Scalable Visualization Array från HP innehåller också komponenter som integreras med VirtualGL och TurboVNC, vilket gör att du kan skapa 3D-arbetsytor som körs och visas på distans med hjälp av ett visualiseringskluster.
Med tillkomsten av huvudlösa grafikkort för bärbara datorer har VirtualGL använts i projekt som Bumblebee. Summan av kardemumman är att vid tillverkning av kombinerade grafikkort görs ett "inbyggt" fullfjädrat, och det andra är "diskret" utan möjlighet att visa det på skärmen. Samtidigt finns inget drivrutinsstöd från tillverkaren och förväntas inte. VirtualGL, å andra sidan, låter dig köra en applikation på ett "diskret" grafikkort och skicka renderingsresultatet genom en tunnel till det "inbyggda".