Jak efektywnie korzystać z 3D za pomocą połączenia zdalnego?

12

Mam jeden słaby komputer (klient), ale z akceptowalną wydajnością 3D i jeden mocny komputer (serwer), który powinien być zdolny do uruchamiania aplikacji przy użyciu OpenGL dwa razy, tj. Raz lokalnie i raz zdalnie dla klienta. Obecnie się ssh -Xw to włączam, ale używane są oprogramowanie renderujące konsolę wyjściową klienta i otrzymuję tylko 3 klatki na sekundę (fps). W rzeczywistości szyfrowanie ssh nie jest konieczne, ponieważ jest w sieci LAN, ale to już wiem o zdalnych aplikacjach ...

Jak więc zwiększyć wydajność klienta? Moje pomysły są

  • użyć przyspieszenia sprzętowego, ale serwerowego lub klienta i jak?
  • użyj czegoś innego niż ssh

Wiem, że w pełnej rozdzielczości i bez wyrafinowanej kompresji sieć LAN 100 Mbit / s nie osiągnie więcej fps, ale jest to aplikacja ok. 800 x 450, więc teoretycznie do 12 fps (przy 24 bitach / piksel) powinno być możliwe przy użyciu nieskompresowanych danych graficznych. A może możliwe jest coś lepszego przy użyciu własnego procesora graficznego klienta lub inteligentnej kompresji.

-

edytuj Okazuje się, że to, co chcę, to w zasadzie lokalna wersja tego, co oferuje np. onlive i gaikai . Czy jest coś takiego dla Linuksa (i być może za darmo)?

-

edit2 VirtualGL wygląda na najlepsze rozwiązanie (choć obecnie nie działa dla mnie), ale zastanawiam się, czy możliwe jest również renderowanie sprzętowe na kliencie

Tobias Kienzler
źródło
Kontynuacja, ponieważ komputery i tak są obok siebie i zastanawiam się, dlaczego nie używać jednego komputera dla dwóch użytkowników: Czy z jednego komputera może korzystać jednocześnie dwóch użytkowników za pośrednictwem podwójnego monitora?
Tobias Kienzler,

Odpowiedzi:

7

Można sprawdzić VirtualGL wraz z TurboVNC powinien dostarczyć 20fps @ 1280x1024 na 100 Mbit ( patrz wikipedia ).

Pamiętaj, że może nie działać ze wszystkimi aplikacjami, zależy to od tego, jak korzystają z OpenGL.

Gert
źródło
Daj +1 temu dźwiękowi dokładnie tak, jak szukam, dziękuję! (Przyjmę odpowiedź po (miejmy nadzieję) udanych testach)
Tobias Kienzler
aww, mój Radeon wydaje się nie obsługiwać bufora, który jest wymagany :(
Tobias Kienzler
Mam teraz nowy komputer, który obsługuje pbuffer, ale niestety teraz Vglrun segfaults . Czy może tak być, ponieważ serwer działa w wersji 64-bitowej, a klient w wersji 32-bitowej?
Tobias Kienzler,
(przyjęte, ponieważ odpowiedź jest poprawna, a segfault jest oddzielna kwestia)
Tobias Kienzler
2

To stare pytanie, ale wciąż aktualne. Istnieje instrukcja krok po kroku dotycząca konfiguracji i rozwiązywania problemów z renderowaniem 3D X11 zdalnej aplikacji na lokalnym sprzęcie: przyspieszenie sprzętowe OpenGL poprzez zdalne połączenie xsh ssh

W artykule wykorzystano grę Chromium BSU. Działa z 5-8 FPS z domyślnym renderowaniem oprogramowania przez połączenie SSH, 30 FPS z pośrednim renderowaniem sprzętowym i> 30 FPS z niezaszyfrowanym połączeniem TCP X11. Pamiętaj, że działa tylko w przypadku niektórych aplikacji.

Krótkie streszczenie artykułu

Renderowanie pośrednie i połączenia TCP są wyłączone w domyślnej konfiguracji serwera X11. +iglx and -listen tcpparametry je umożliwiają. Istnieje również LIBGL_ALWAYS_INDIRECT=1zmienna, która wymusza renderowanie pośrednie na kliencie X11.

evpo
źródło
Dziękuję za odpowiedź. Bardzo doceniamy istotę linkowanych postów na blogu tutaj na wypadek, gdyby link kiedykolwiek wyginął (nawet jeśli np. Po prostu powiesz „używanie za lightdmpomocą iglx” takiego). Obecnie nie potrzebuję tego więcej, ale spróbuję to następnym razem;) Może ktoś inny również uzna twoje ustalenia za pomocne.
Tobias Kienzler,
Słuszna uwaga. Dodałem główne szczegóły artykułu.
evpo,
0

To może być prawda, jeśli masz dwa komputery stacjonarne. Ale jeśli masz stary laptop WiFi, z którego można korzystać w dowolnym miejscu w domu (np. Ti5600 z Ubuntu 10.04 jako klientem, i komputer stacjonarny z płytą GTX wraz z zapasowym routerem Wi-Fi, zdalny klient OpenGL wydaje się dobrym pomysłem.

Problemem jest uzyskanie zdalnego kontekstu OpenGL (po stronie serwera). Możesz uruchomić ssh -X na swoim kliencie. Ale jeśli uruchomisz glxinfo na zdalnym systemie, otrzymasz lokalnego klienta, który przeniesie Cię z powrotem do miejsca, w którym zacząłeś. Możesz ustawić zmienną środowiskową DISPLAY na ten zdalny host i możesz użyć tego ekranu jako drugiego monitora, co nadal nie pomaga.

Innym rozwiązaniem jest napisanie aplikacji komputerowych, aby mogły korzystać ze zdalnego kontekstu GLX:

http://arrayfire.com/remote-off-screen-rendering-with-opengl/

Keith
źródło
Dziękuję Ci. Czy istnieje więc alternatywa dla protokołu X do przesyłania 3D? Przepraszam, powinienem umieścić w cudzysłowie serwer i klienta, chciałem tylko mieć krótsze słowa na określenie mocnego i słabego komputera - oba komputery powinny być używane jako interfejsy w tym samym czasie, jakby były komputerami stacjonarnymi, ale z całą pracą procesora i dostęp do pamięci RAM przez lepszy komputer. Słaby komputer nie ma wystarczającej mocy procesora i pamięci RAM, aby uruchomić samą aplikację
Tobias Kienzler,
Nie, że jestem tego świadomy. Rodzaj 3D, o którym myślisz, wymaga dużej przepustowości.
Keith
to prawda :( OTOH, onlive , gaikai i inni twierdzą, że jest to nawet możliwe w przypadku gier przez Internet ...
Tobias Kienzler
Ok, spojrzałem. Nie sądzę też, żeby przesyłali ramki w ten sposób. Pobierają i działają lokalnie, a jedynie przekazują informacje o kontroli i aktualizacji, podobnie jak istniejące gry online. Nawet gdyby tak było, musiałaby mieć niską rozdzielczość dla wysokiej kompresji.
Keith
Z tego, co rozumiem, uruchamiają grę zdalnie i po prostu transmitują strumień wideo HD podczas odbierania zdarzeń z klawiatury i myszy. Ale oczywiście nie można przesyłać 30 klatek na sekundę w jakości HD przez Internet bez kompresji ...
Tobias Kienzler