Comment utiliser efficacement la 3D via une connexion à distance?


11

J'ai un PC faible (client) mais avec des performances 3D acceptables, et un PC fort (serveur) qui devrait être capable d'exécuter une application en utilisant OpenGL deux fois, c'est-à-dire une fois localement et une fois à distance pour le client. Actuellement, j'y suis ssh -X, mais la sortie de la console du client indique que le rendu logiciel est utilisé et je n'obtiens que 3 images par seconde (fps). En fait, le chiffrement de ssh n'est pas nécessaire car c'est sur un LAN, mais c'est ce que je sais déjà pour les applications distantes ...

Alors, comment augmenter les performances du client? Mes idées sont

  • utiliser l'accélération matérielle, mais celle du serveur ou du client et comment?
  • utiliser quelque chose de différent de ssh

Je sais qu'en pleine résolution et sans compression sophistiquée, un LAN à 100 Mbit / s ne fera pas plus de fps, mais c'est une application fenêtrée de ca. 800x450, donc théoriquement jusqu'à 12 ips (à 24 bits / pixel) devrait être possible en utilisant des données graphiques non compressées. Et peut-être que quelque chose de mieux est possible en utilisant le propre GPU du client ou une compression intelligente.

-

edit Il s'avère que ce que je veux est essentiellement une version locale de ce que proposent par exemple onlive et gaikai . Existe-t-il quelque chose comme ça pour Linux (et éventuellement gratuit)?

-

edit2 VirtualGL ressemble à la meilleure solution (bien qu'il ne fonctionne pas actuellement pour moi), mais je me demande s'il est également possible de faire du rendu matériel sur le client



Suivi puisque les PC sont de toute façon côte à côte et je me demande pourquoi ne pas utiliser un PC pour deux utilisateurs: un PC peut-il être utilisé par deux utilisateurs en même temps via un double moniteur?
Tobias Kienzler

Réponses:


6

Vous pouvez vérifier VirtualGL avec TurboVNC devrait vous fournir 20fps @ 1280x1024 sur 100 Mbit ( voir wikipedia ).

Notez qu'il peut ne pas fonctionner avec toutes les applications, cela dépend de la façon dont elles utilisent OpenGL.


+1 ce son ressemble exactement à ce que je recherche, merci! (J'accepterai la réponse après (espérons-le) des tests réussis)
Tobias Kienzler


J'ai maintenant un nouveau PC qui prend en charge pbuffer, mais malheureusement vglrun segfaults maintenant. Serait-ce parce que le serveur fonctionne sur 64 bits alors que le client est sur 32 bits?
Tobias Kienzler

(accepté car la réponse est correcte et la faute de segmentation est une question distincte)
Tobias Kienzler

1

C'est une vieille question mais elle est toujours d'actualité. Il y a un manuel étape par étape sur la façon de configurer et de dépanner le rendu 3D X11 de l'application distante sur le matériel local: Accélération matérielle OpenGL via une connexion ssh x11 distante

Le jeu Chromium BSU est utilisé dans l'article comme exemple. Il fonctionne avec 5-8 FPS avec rendu logiciel par défaut via une connexion SSH, 30 FPS avec rendu matériel indirect et> 30 FPS avec connexion TCP X11 non chiffrée. Notez que cela ne fonctionne que pour certaines applications.

Bref résumé de l'article

Le rendu indirect et les connexions TCP sont désactivés dans la configuration du serveur X11 par défaut. +iglx and -listen tcples paramètres les permettent. Il existe également une LIBGL_ALWAYS_INDIRECT=1variable qui force le rendu indirect sur le client X11.


Merci pour votre réponse. Il est grandement apprécié de noter l'essentiel des articles de blog liés ici au cas où le lien disparaîtrait jamais (même si par exemple vous indiquez simplement "utiliser lightdmavec iglx" tel). Actuellement, je n'en ai plus besoin, mais je vais l'essayer la prochaine fois;) Peut-être que quelqu'un d'autre trouve également vos conclusions utiles.
Tobias Kienzler

Bon point. J'ai ajouté les principaux détails de l'article.
evpo

0

Cela pourrait être vrai si vous avez deux PC de bureau. Mais si vous avez un ancien ordinateur portable WiFi utilisable n'importe où à la maison (par exemple Ti5600 avec Ubuntu 10.04 comme client, et un PC de bureau avec une carte GTX avec un routeur Wi-Fi de rechange, avoir un client OpenGL distant semble une bonne idée.

Le problème est d'obtenir un contexte OpenGL distant (côté serveur). Vous pouvez exécuter ssh -X sur votre client. Mais si vous exécutez glxinfo sur le système distant, vous obtenez votre client local, ce qui vous ramène là où vous avez commencé. Vous pouvez définir votre variable d'environnement DISPLAY sur cet hôte distant, et vous pouvez utiliser cet écran comme deuxième moniteur, ce qui n'aide toujours pas.

Une autre solution consiste à écrire vos applications de bureau afin qu'elles puissent utiliser un contexte GLX distant:

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


Je vous remercie. Existe-t-il une alternative pour que le protocole X transmette la 3D? Désolé, j'aurais dû mettre le serveur et le client entre guillemets, je voulais seulement avoir des mots plus courts pour le PC fort et faible - les deux PC devraient être utilisés comme frontaux en même temps que s'ils étaient des PC de bureau mais avec tout le travail du CPU et l'accès à la RAM effectué par le meilleur PC. Le PC faible n'a pas assez de puissance CPU et de RAM pour exécuter l'application elle
Tobias Kienzler

Pas que je sache. Le type de 3D auquel vous pensez nécessite BEAUCOUP de bande passante.
Keith

c'est vrai :( OTOH , onlive , gaikai et d'autres prétendent que c'est même possible pour les jeux sur Internet ...
Tobias Kienzler

Ok, j'ai jeté un coup d'œil. Je ne pense pas non plus qu'ils transmettent les trames de cette façon. Ils téléchargent et exécutent localement, et ne transmettent que les informations de contrôle et de mise à jour, tout comme les jeux en ligne existants.
Keith

D'après ce que je comprends, ils exécutent le jeu à distance et transmettent simplement un flux HD de la vidéo tout en recevant les événements du clavier et de la souris. Mais bien sûr, on ne pouvait pas transmettre 30 fps en HD sur Internet sans aucune compression ...
Tobias Kienzler
En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.