État actuel et solutions pour OpenGL sur Windows Remote
OpenGL et Windows Remote ne fonctionnent pas bien.
Les solutions pour cela dépendent du cas d'utilisation et les réponses sont fragmentées à travers les vastes profondeurs du réseau. Ceci est un article que j'aurais aimé avoir quand j'ai commencé à faire des recherches à ce sujet, à la fois pour les codeurs et les non-codeurs.
Problème:
Une session RDP de Windows n'expose pas la carte graphique, du moins pas directement. Par exemple, vous ne pouvez pas modifier la résolution du bureau et les pilotes de carte graphique désactivent généralement leurs menus de configuration. Le démarrage d'un contexte OpenGL supérieur à v1.1 échoue pour cette raison. Le, en particulier dans les IRC de support, a souvent suggéré que "Ne pas utiliser WindowsRemote" n'est malheureusement pas une option pour beaucoup. Dans de nombreux environnements d'entreprise, Windows Remote est un outil constamment utilisé et une application doit également y fonctionner.
Solutions de contournement non codeur
Vous pouvez démarrer le programme OpenGL, lui permettant de voir la carte graphique, créer un contexte opengl puis se connecter via WindowsRemote. Cela fonctionne toujours, car la télécommande Windows transfère simplement le contenu de la fenêtre. Cela peut être accompli par:
- Un script batch, qui ferme la session et démarre le programme, vous permettant de vous connecter au programme déjà en cours d'exécution. ( Source )
- En utilisant VNC ou autre pour vous connecter à distance à la machine, démarrez le programme, puis basculez vers Windows Remote. ( programme VNC simple , également avec client portable )
Solutions de contournement du codeur
(Uniquement pour OpenGL ES) Traduisez OpenGL en DirectX. DirectX fonctionne correctement sous Windows Remote et a même un repli de rendu logiciel intégré dans DX11 si quelque chose échoue.
- Utilisez le projet ANGLE pour le faire au moment de l'exécution. C'est ce que vous faites QT suggère officiellement et comment Chrome et Firefox implémentent WebGL. ( Source )
Passez au rendu logiciel comme solution de rechange. Certains logiciels CAD comme 3dsMax le font par exemple:
- Sous SDL2, vous pouvez utiliser SDL_CreateSoftwareRenderer ( Source )
- Sous GLFW, la version 3.3 publiera OSMesa (le rendu hors écran de Mesa), en attendant, vous pouvez créer la version Github avec -DGLFW_USE_OSMESA = TRUE, mais j'ai du mal à le faire fonctionner ( Source )
- Utilisez directement le canal LLVM de Mesa pour une implémentation OpenGL rapide. ( Source )
Divers:
- Utilisez OpenGL 1.1: Windows a une implémentation intégrée d'OpenGL 1.1 et versions antérieures. Certains moteurs de jeu ont une fonction intégrée pour cela et fonctionnent donc sous Windows Remote.
- Apparemment, il existe un middleware, qui permet même OpenGL 4 sur Windows Remote, mais il fait partie d'un package plus important et est une solution commerciale. ( Source )
Toute autre solution ou correction est grandement appréciée.
Windows Remote Desktop ouvrira une session à distance. Je pense que, du moins en ce qui concerne NVIDIA, seuls les pilotes des cartes de station de travail professionnelles (Quadro) ont un support de session à distance (je n'ai jamais testé cela moi-même cependant). Les pilotes GeForce normaux ne fonctionnent pas dans une session à distance (d'après mon expérience). Cela n'affecte pas seulement OpenGL. Pour autant que je m'en souvienne, par exemple, CUDA ne fonctionnera pas non plus dans une session à distance.
Personnellement, si vous devez travailler à distance sur des choses qui utilisent le GPU, je recommanderais TeamViewer ou VNC . Ils ont probablement besoin de plus de bande passante, mais comme ils contrôleront simplement à distance la session interactive locale plutôt que de travailler dans une session à distance, tout fonctionnera comme si vous étiez assis devant la machine. Une chose à savoir, c'est que l'utilisation de TeamViewer/VNC va, bien sûr, interférer avec quiconque est réellement assis devant la machine…
OpenGL fonctionne très bien par RDP avec des cartes Nvidia professionnelles sans rien comme les machines virtuelles et RemoteFX. Pour Quadro (testé Quadro 4000), vous avez besoin du pilote 377.xx. Pour M60, vous pouvez utiliser le même pilote. Si vous souhaitez utiliser le dernier pilote avec M60, vous devez changer le mode du pilote en mode WDDM (voir c:\Program Files\NVIDIA Corporation\NVSMI\nvidia-smi.1.pdf). Il est possible qu'il y ait des problèmes de licence dans ce dernier cas.
Certaines personnes recommandent d'utiliser "tscon.exe" si vous le pouvez: https://stackoverflow.com/a/45723167/3245 ou d'utiliser un planificateur pour le faire sur du matériel natif: https: //stackoverflow.com/a/41839102/3245 ou création d'une stratégie de groupe: https://community.esri.com/thread/225251-enabling-gpu-rendering-on-windows-server- 2016-windows-10-rdp
peut-être copier opengl32.dll (ou opengl64.dll) dans le répertoire de votre exécutable: https://blender.stackexchange.com/a/73014 et une version plus récente de la dll: https://fdossena.com/?p=mesa/index.frag
Remote Desktop et OpenGL ne fonctionnent pas très bien. Lorsque vous vous connectez à une boîte Windows, le pilote OpenGL est déchargé et vous vous retrouvez avec une émulation logicielle d'OpenGL.
Lorsque vous vous déconnectez de la boîte Windows, le pilote OpenGL n'est pas rechargé. Cela provoque des problèmes lorsque vous exécutez des tests sur la machine car vous devez vous connecter physiquement à la machine pour réinitialiser les pilotes.
La solution que j'ai finalement utilisée était de:
- Désactivez le Bureau à distance.
- Supprimez tous les autres logiciels pour l'accès au bureau à distance. Parce que s'il est utilisé pour se connecter à distance, l'ensemble actuel des pilotes chargés peut être gâché.
- Installer NoMachine
NoMachine est mon préféré (lorsqu'il ne joue pas) pour plusieurs raisons:
- Accélération matérielle de la compression (vidéo du bureau).
- Fonctionne sur Windows et Linux.
- Fonctionne bien sur les connexions à faible bande passante, surtout si le client et le serveur ont le matériel nécessaire pour la compression du flux de données.
- Sous Linux, vous obtenez votre bureau tel que vous l'avez laissé lorsque vous étiez assis devant la machine.
- Sous Windows, cela n'affecte pas OpenGL.
- actuellement gratuit pour un usage personnel et commercial. Vérifiez la licence au cas où elle serait modifiée.
Lorsque NoMachine joue, il monopolise le processeur, mais cela se produit rarement. Elle est cependant en développement actif
D'autres à considérer:
- TurboVNC
- TightVNC
- TeamWare - uniquement gratuit pour un usage personnel.