Moje laboratorium badawcze niedawno dodało serwer z mocną kartą graficzną NVIDIA, której chcielibyśmy użyć do obliczeń naukowych. Ponieważ nie jest to stacja robocza, będziemy musieli uruchamiać nasze zadania zdalnie przez połączenie ssh. Większość naszych aplikacji wymaga renderowania OpenGL do bufora ekranowego, a następnie analizy obrazu na wynikach w CUDA.
Moje wstępne dochodzenie sugeruje, że przekazywanie X11 jest złym pomysłem, ponieważ renderowanie opengl nastąpi na komputerze klienckim (a raczej na serwerze X11 - co za myląca konwencja nazewnictwa!) I będzie napotykać wąskie gardła w sieci podczas wysyłania naszych ogromnych tekstur. Nigdy nie będziemy musieli wyświetlać danych wyjściowych, więc wydaje się, że przekazywanie X11 nie powinno być konieczne, ale Opengl potrzebuje $ DISPLAY, aby ustawić coś ważnego, inaczej nasze aplikacje nie będą działać. Jestem pewien, że istnieją farmy renderujące, które to robią, ale jak to osiągnąć? Myślę, że jest to prawdopodobnie prosty problem z konfiguracją X11, ale nie znam go zbyt dobrze, aby wiedzieć, od czego zacząć.
Pracujemy na serwerze Ubuntu 10.04, bez zainstalowanego gdm, gnome itp. Jednak pakiet xserver-xorg jest zainstalowany.
źródło
Odpowiedzi:
Minęło trochę czasu, odkąd zadałem to pytanie, więc pomyślałem, że wspomnę o rozwiązaniu, którego ostatecznie użyliśmy.
Przejęcie lokalnego ekranu X.
W końcu właśnie uruchomiłem zdalne programy opengl na lokalnym ekranie X serwera. Na komputerze działała wersja serwera Ubuntu i domyślnie nie był uruchomiony serwer xserver, więc musiałem skonfigurować serwer Xserver do uruchamiania podczas uruchamiania (właśnie zainstalowałem pakiet Ubuntu-desktop Ubuntu, zabijając komara młotem), a następnie dałem sobie dostęp do ekranu X, używając tych komend jako root: "eksportuj WYŚWIETLACZ =: 0,0; xhost + lokalny:". Następnie mógłbym ssh do komputera, wywołać „eksport DISPLAY =: 0,0”, a następnie uruchomić moje programy opengl jak zwykle. Każdy, kto siedzi na zdalnej maszynie, zobaczy okno wyskakujące i zobaczy, jak mój program działa, ale nie mamy podłączonego monitora, więc to nie był problem.
Ważne jest, aby użyć jakiejś formy renderowania poza ekranem, ponieważ odczyt pikseli bezpośrednio z bufora kolorów na ekranie może spowodować niepotrzebne dane, jeśli okno zostanie zasłonięte przez inne okno. Ponieważ nie widać ekranu X, trudno jest ustalić, czy tak się stało. Renderowanie poza ekranem (np. Obiekty Framebuffer (fbo) lub pbuffers) nie mają tego problemu.
Przejęcie lokalnego Xscreen serwera nie jest idealnym rozwiązaniem, więc oto kilka alternatyw, które znalazłem po drodze:
Wirtualne bufory ramki
Xvfb jest opcją, ale nie działało dla mnie, ponieważ OpenGL nie korzystał z przyspieszania sprzętowego, a obiekty bufora ramki nie były obsługiwane, które są niezbędne do współdziałania CUDA z OpenGL. Niemniej jednak może to być praktyczna opcja, w której przejmowanie lokalnego ekranu jest niedopuszczalne lub gdy użytkownik nie może uzyskać uprawnień xhost.
VirtualGL
Ze strony VirtualGL:
Właśnie tego chcę i wygląda to bardzo obiecująco, ale nie miałem czasu poradzić sobie z nową zależnością od biblioteki, więc jej nie przetestowałem. Domyślam się, że jest to idealne rozwiązanie, gdy tylko mogę je skompilować, zainstalować i skonfigurować. Tego właśnie używa VirtualBox i niektóre serwery VNC do obsługi sprzętowo akcelerowanego 3D.
źródło
możesz uruchomić wirtualny bufor ramki vfb na maszynie, to jest jak obojętny X11. Kiedyś uruchamialiśmy aplikacje, które MUSISZ otworzyć Xwindow, na które nigdy nie patrzyliśmy, po prostu zainstalowałem VFB i wyeksportowaliśmy do niego $ DISPLAY - trochę jak ekran na HTL
źródło