Windows Remote over OpenGLの現状と解決策
OpenGLとWindows Remoteはうまく機能しません。
これに対する解決策はユースケースに依存しており、答えはネットの広大な深さにわたって断片化されています。これは、コーダーと非コーダーの両方のためにこれを研究し始めたときに私が存在したいと思っている記事です。
問題：
WindowsのRDPセッションは、少なくとも直接にはグラフィックスカードを公開しません。たとえば、デスクトップの解像度を変更することはできず、GraphicsCardドライバーは通常、設定メニューを無効にするだけです。このため、v1.1以降のOpenGLコンテキストを開始すると失敗します。特にサポートIRCで、「WindowsRemoteを使用しない」は多くの場合残念ながらオプションではないことがしばしば提案されています。多くの企業環境では、Windows Remoteは常に使用されるツールであり、アプリもそこで機能する必要があります。
コーデック以外の回避策
OpenGLプログラムを起動して、グラフィックカードを表示し、openglコンテキストを作成して、WindowsRemote経由で接続することができます。 Windowsリモートはウィンドウのコンテンツを転送するだけなので、これは常に機能します。これは次の方法で実現できます。
- セッションを閉じてプログラムを開始するバッチスクリプト。これにより、すでに実行中のプログラムに接続できます。 （ ソース ）
- VNCまたはその他を使用してマシンにリモートでアクセスし、プログラムを起動して、Windowsリモートに切り替えます。 （ シンプルなVNCプログラム 、 ポータブルクライアント も使用）
コーダーの回避策
（OpenGL ESのみ）OpenGLをDirectXに変換します。 DirectXは、Windowsリモートの欠陥の下で動作し、何かが失敗した場合、DX11に組み込まれたソフトウェアレンダリングフォールバックさえあります。
フォールバックとしてソフトウェアレンダリングに切り替えます。いくつかのCAD 3dsMaxのようなソフトウェアは、例えばこれを行います：
- SDL2では、SDL_CreateSoftwareRenderer（ Source ）を使用できます。
- GLFWバージョン3.3では、OSMesa（Mesaのオフスクリーンレンダリング）がリリースされますが、当面は-DGLFW_USE_OSMESA = TRUEを使用してGithubバージョンをビルドできますが、私はまだそれを実行するのに苦労しています（ Source ）
- MesaのLLVMパイプを直接使用して、高速なOpenGL実装を実現します。 （ ソース ）
その他：
- OpenGL 1.1の使用：Windowsには、OpenGL 1.1以前の組み込みの実装があります。一部のゲームエンジンは、これにフォールバックが組み込まれているため、Windowsリモートで動作します。
- どうやらミドルウェアがあり、Windows Remoteを介したOpenGL 4も可能ですが、それはより大きなパッケージの一部であり、商用ソリューションです。 （ ソース ）
その他の解決策や修正は大歓迎です。
Windowsリモートデスクトップがリモートセッションを開きます。少なくともNVIDIAに関して言えば、リモートセッションサポートを備えているのは、プロフェッショナル（Quadro）ワークステーションカード用のドライバーだけです（ただし、これを自分でテストしたことはありません）。通常のGeForceドライバーは（私の経験では）リモートセッションでは機能しません。これはOpenGLに影響するだけではありません。私が覚えている限り、例えば、CUDAはリモートセッションでも機能しません。
個人的には、GPUを使用しているものをリモートで操作する必要がある場合は、 TeamViewer または [〜＃〜] vnc [〜＃〜] をお勧めします。おそらくより多くの帯域幅が必要ですが、リモートセッションではなくローカルの対話型セッションをリモートコントロールするだけなので、マシンの前に座っている場合と同様にすべてが機能します。知っておくべきことの1つは、TeamViewer/VNCを使用すると、もちろん、マシンの前に実際に座っている人を妨害することです...
OpenGLは、仮想マシンやRemoteFXのようなものがなくても、プロのNvidiaカードを使用したRDPでうまく機能します。 Quadro（Quadro 4000テスト済み）の場合、ドライバー377.xxが必要です。 M60の場合は、同じドライバーを使用できます。 M60で最後のドライバーを使用する場合は、ドライバーモードをWDDMモードに変更する必要があります（c：\ Program Files\NVIDIA Corporation\NVSMI\nvidia-smi.1.pdfを参照）。この最後のケースでは、ライセンスに問題がある可能性があります。
https://stackoverflow.com/a/45723167/3245 または、ネイティブハードウェアでスケジューラーを使用する場合は、「tscon.exe」の使用を推奨する人もいます https： //stackoverflow.com/a/41839102/3245 またはグループポリシーの作成： https://community.esri.com/thread/225251-enabling-gpu-rendering-on-windows-server- 2016-windows-10-rdp
多分opengl32.dll（またはopengl64.dll）を実行可能ファイルのディレクトリにコピーします： https://blender.stackexchange.com/a/73014 とdllの新しいバージョン： https：/ /fdossena.com/?p=mesa/index.frag
リモートデスクトップとOpenGLはうまく再生されません。 Windowsボックスに接続すると、OpenGLドライバーがアンロードされ、OpenGLのソフトウェアエミュレーションが作成されます。
Windowsボックスから切断すると、OpenGLドライバーは再ロードされません。これは、ドライバーをリセットするためにマシンに物理的にログインする必要があるため、マシンでテストを実行しているときに問題を引き起こします。
私が最終的に使用した解決策は次のとおりでした：
- リモートデスクトップを無効にします。
- リモートデスクトップアクセス用の他のすべてのソフトウェアを削除します。リモートでのログインに使用すると、現在ロードされているドライバのセットがめちゃくちゃになる可能性があるためです。
- NoMachineをインストールする
NoMachineは、いくつかの理由で（再生できない場合）私の個人的なお気に入りです。
- 圧縮のハードウェアアクセラレーション（デスクトップのビデオ）。
- WindowsおよびLinuxで動作します。
- 特にクライアントとサーバーにデータストリームの圧縮に必要なハードウェアがある場合、低帯域幅接続でうまく機能します。
- Linuxでは、マシンの前に座っていたときにデスクトップを最後に離れたときにデスクトップが表示されます。
- Windowsでは、OpenGLには影響しません。
- 現在、個人使用および商用使用は無料です。ライセンスが変更されている場合は、ライセンスを確認してください。
NoMachineが再生されると、CPUを占有しますが、これはまれにしか発生しません。しかしそれは活発に開発中です
その他の考慮事項：
- TurboVNC
- TightVNC
- TeamWare-個人使用のみ無料。