Привет
Русскоязычный информационно-болтологический форум
RDP server and OpenGL
RDP server and OpenGL
Post by DropAndDrag » Wed Jun 17, 2015 8:17 pm
Microsoft удивил снова и как чаще случается — неприятно!
В связи с тем, что 10 Gb сетевое оборудование в пределах комнаты стало недорогим, то появилась мысля, как упростить жизнь народу, у которого большие объемы данных, невзирая на вой сетевого гуру (сеть между зданиями 10 Gb). Мысля заключалась в следующем — сделать небольшой 10 Gb островок в здании. Несколько генераторов больших данных, файл-сервер и несколько мощных серверов на основе Windows Server 2012R2, который поддерживает SMB 3, будут включены в этот островок. А народ будет подключаться через RDP к этим серверам через 1 Gb сеть в здании.
Но была еще одна не задача — некоторые программы, которые как раз закусывают большиит объемами данных, не дружили с RDP. Не то чтобы совсем, но некоторые графики не показывались никак — черное окно! Сам я с этим не разбирался, народ, отплевываясь стал использовавть еще и VNC — запустит под VNC это чертово окно, а потом с RDP c ним возится 
Наконец-то вчера IT радостно сообщило — Windows Server 2012R2 притащен и установлен к вашему удовольствию. Вы еще и администратор! Вчера установил программу — установилась, но она требует USB donkey за тысяч так 20 
Сегодня договорился, взял ключик, программа заработала, загружаю файлик и говорю — показывай! А в ответ — черное окно 
Стал разбираться. Нашел лог программы — там много чего, но глаз зацепился за OpenGL. Порылся в Гугле и народ действительно ругается. Скачал тестовую программу — так и есть — пока сижу за компом -все ОК. Захожу через RDP — не работает.
На сайте OpenGL — народ пишет, что пипец. Надо толкать OpenGL окошки через что-то другое и как пример предлагается TeamView. Поискал на Microsoft — ни хрена не нашел, но нашел, что супер-пупер RemoteFX поддерживает карты с аппаратным OpenGL, но API поддерживает.
Может быть кто-то разбирался?
Re: RDP server and OpenGL
Post by Medium-rare » Fri Jun 19, 2015 8:23 am
Проблема в том, что высокопроизводительная графика на базе OpenGL оперирует напрямую памятью видеоадаптера. Вы хотите, чтобы Windows, которую обходят, дала вам картинку по сети. Для того есть RemoteFX, да, который «подглядывает», сильно упрощая, в картинку, и передаёт её вам по сети через RDP. Но тут RemoteFX надо уметь правильно «подглядывать» в *разные* видеоадаптеры, в хардвер, пишут вам о том.
IMHO, разрешимо через стандартизацию видеоадаптеров по стандартам MS, если почему-то производители тормозят с аппаратным OpenGL. Вы этого хотите? Вы же свободные умные в-микрософт-плюющие всё отлично понимающие люди.
Конкуренты MS как-то лучше разрулили проблему?
Re: RDP server and OpenGL
Post by StrangerR » Fri Jun 19, 2015 2:18 pm
Простите, а при чем тут видеоадаптер? При работе с консоли система работает с адапретом железным. При удаленной работе везде, кроме этих чудаков, система работает с так сказать виртуальным видеоадаптером (Frame Buffer в терминах X11). И какого черта винда этого не понимает?
Хотя это проблема не винды а OpenGL. Потому что да, идея работать с адаптером неплоха. только эта работа должна быть не там где программа а там где дисплей стоит, что на сегодня совпадает пожалуй только в случае ноутбука.
Re: RDP server and OpenGL
Post by Medium-rare » Fri Jun 19, 2015 2:34 pm
StrangerR wrote: Простите, а при чем тут видеоадаптер? .
Хотя это проблема не винды а OpenGL. Потому что да, идея работать с адаптером неплоха.
Re: RDP server and OpenGL
Post by DropAndDrag » Fri Jun 19, 2015 6:54 pm
Medium-rare wrote: Проблема в том, что высокопроизводительная графика на базе OpenGL оперирует напрямую памятью видеоадаптера. Вы хотите, чтобы Windows, которую обходят, дала вам картинку по сети. Для того есть RemoteFX, да, который «подглядывает», сильно упрощая, в картинку, и передаёт её вам по сети через RDP. Но тут RemoteFX надо уметь правильно «подглядывать» в *разные* видеоадаптеры, в хардвер, пишут вам о том.
IMHO, разрешимо через стандартизацию видеоадаптеров по стандартам MS, если почему-то производители тормозят с аппаратным OpenGL. Вы этого хотите? Вы же свободные умные в-микрософт-плюющие всё отлично понимающие люди.
Конкуренты MS как-то лучше разрулили проблему?
конкуренты — не интересны! есть проблема и интересно получить решение, и без заморочек!
RemoteFX был попробован моим коллегой на Windows 2008 Server пару лет назад — не получилось, но тогда он не добрался, что проблема с OpenGL. А теперь найдя в чем проблема очень удивительно, что Майкрософт ее до сих пор вроде бы не решил.
Если спросят мое ИМХО, то надо вырабатывать стандарт видеокард (при участии разработчиков ОС), а не следовать пожеланиям только Майкросовта. Все-таки много программ используют OpenGL и по идеи Майкрософту надо бы напрячься и сделать все путем или хотя бы написать wrapper OpenGLToDirectX.
Windows 2008 r2 opengl
The following forum(s) have migrated to Microsoft Q&A: All English Windows Server forums!
Visit Microsoft Q&A to post new questions.
Answered by:
Question
We have OpenGL application working on a server computer. If later we connect via RDP to this server, OpenGL application continues to function without any problems. Obviously RDP just transfers image from server to remote computer.
If we start the same OpenGL application on the same server from RDP session, it runs OpenGL not on server but on the remote computer. Application crashes on operations that require OpenGL 2.0 or higher.
Is there any way to force RDP to run OpenGL code always on server no matter how it was started, directly on server or from remote computer?
Answers
In your batch file make sure you reconnect your session to the physical console before attempting to launch the CAD app. Here is the command:
tscon 1 /dest:console
I am thinking your batch file only needs two lines, something like:
tscon 1 /dest:console
start «C:\Program Files\SolidWorks Corp\SolidWorks\sldworks.exe»
The first line will disconnect your remote PC and connect the session to the physical keyboard/video/mouse, then the second line will launch the CAD program (substitute your CAD software). After that you wait several seconds for the software to start and then reconnect to the session from your home PC.
You should have the batch file Run as administrator. I made an assumption above that the current session id is 1. Your session id may be different—you can use query session at a command prompt to find your session id.
All replies
Can you please elaborate? I can’t tell the difference in the way you are starting the app (what is the app?).
Scenario 1: start RDP session, log into the terminal server/RD Session Host server, and start the app. Is this right?
Scenario 2: Can you elablorate here on the steps you go through?
Are you using RemoteApp or full desktop sessions?
What server OS and client OS are you running?
SUPER BIG fan of the Remote Desktop Virtualization Team. )
Can you please elaborate? I can’t tell the difference in the way you are starting the app (what is the app?).
Scenario 1: start RDP session, log into the terminal server/RD Session Host server, and start the app. Is this right?
Scenario 2: Can you elablorate here on the steps you go through?
Are you using RemoteApp or full desktop sessions?
What server OS and client OS are you running?
Host (office computer) — Windows 7 x64.
Clients (remote home computers) — various types and Windows releases (XP, Vista, 7)
Application — CAD software based on OpenGL. In fact there are even two versions of the same CAD software. Old release uses OpenGL 1 and new release uses OpenGL 2
Being in the office and sitting by the host computer we start Old CAD and New CAD.
Then we go home and connect via VPN and Remote Desktop to this host from our home computers.
Both Old CAD and New CAD work fine in this case. List of OpenGL context options that we can get in the special command of the CAD application corresponds to GPU of the host machine. As I understand RDP in this scenario just transfers bitmap of OpenGL window from host to client.
From home computer we connect via VPN and Remote Desktop to the office host. Only after that we start Old CAD and New CAD. Old CAD based on OpenGL 1 works fine. New CAD that uses OpenGL 2 does not work. The list of OpenGL context modes that may be used for initializing OpenGL shows that they correpond to GPU of the home computer, not host computer. This means that OpenGL is actually running on the client computer.
From this behaviour we made conclusion that RDP uses different schemes depending on how OpenGL software was started. I heard that RDP does not support OpenGL on client machines higher than 1.1. Besides, client machines may not support OpenGL 2. So the solution for the 2nd scenario may be RDP option to run OpenGL on host instead of running it on client.
So the question is how to force RDP to run OpenGL on host computer in scenario 2 so that it works the same as in scenario 1.
Thank you in advance!
In essence, you are using RDP to remote into a physical desktop PC. So host (office PC) and client (home PC) are both workstation OSes. Now you want to use OpenGL apps in such a scenario.
When you start the OpenGL apps on the office PC using the physically attached monitor and keyboard, the graphics card may be checked by OpenGL — there are some OpenGL apps that require physical hardware support and other OenGL apps that are happy with rendering OpenGL in software. Both checks are successful in this scenario and both flavors of OpenGL run properly. Now you go to your home PC and establish a remote connection to this user session. During the connection process, the capabilities of the home PC’s graphics card is sent to the host PC in order to optimize the graphics output. This is required to do some rendering on the receiver side rather than on the sender side. This is done for GDI graphics primitives, but not for openGL primitives. In your «remoting into existing user session» scenario the OpenGL output on the host is sent to the client pixel by pixel.
When you establish a new connection from a home PC to an office PC, the home PC’s graphics capabilities are relevant for the user session. Such a remote session does not support OpenGL in hardware — in other words, there is no 3D hardware graphics support. This is why only the software OpenGL app starts, but not the hardware OpenGL app. So your system works as designed even if it sounds weird.
Note: In both scenarios all applications run on the office PC. In the second scenario the graphics options are a little bit different due to the OpenGL app already launched in the existing user session. Actually, I’m surprised that it works at all. I would have expected that the hardware OpenGL app throws an error when remoting into the existing session.
I’m afraid that there’s not much can do about this behaviour if you don’t want to invest into Citrix (HDX Pro) or VMware/Teradici (PCoIP in HW) which supports 3D graphics acceleration in hardware from workstation to workstation. Another option is to run your OpenGL apps in Win7 virtual desktops hosted on Windows Server 2008 R2 SP1 Hyper-V and use the RemoteFX extension of the RDP protocol. This option also supports OpenGL in hardware if the appropriate graphics adapter is installed on the Hyper-V server.
Windows 2008 r2 opengl
The following forum(s) have migrated to Microsoft Q&A: All English Windows Server forums!
Visit Microsoft Q&A to post new questions.
Answered by:
Question
We have OpenGL application working on a server computer. If later we connect via RDP to this server, OpenGL application continues to function without any problems. Obviously RDP just transfers image from server to remote computer.
If we start the same OpenGL application on the same server from RDP session, it runs OpenGL not on server but on the remote computer. Application crashes on operations that require OpenGL 2.0 or higher.
Is there any way to force RDP to run OpenGL code always on server no matter how it was started, directly on server or from remote computer?
Answers
In your batch file make sure you reconnect your session to the physical console before attempting to launch the CAD app. Here is the command:
tscon 1 /dest:console
I am thinking your batch file only needs two lines, something like:
tscon 1 /dest:console
start «C:\Program Files\SolidWorks Corp\SolidWorks\sldworks.exe»
The first line will disconnect your remote PC and connect the session to the physical keyboard/video/mouse, then the second line will launch the CAD program (substitute your CAD software). After that you wait several seconds for the software to start and then reconnect to the session from your home PC.
You should have the batch file Run as administrator. I made an assumption above that the current session id is 1. Your session id may be different—you can use query session at a command prompt to find your session id.
All replies
Can you please elaborate? I can’t tell the difference in the way you are starting the app (what is the app?).
Scenario 1: start RDP session, log into the terminal server/RD Session Host server, and start the app. Is this right?
Scenario 2: Can you elablorate here on the steps you go through?
Are you using RemoteApp or full desktop sessions?
What server OS and client OS are you running?
SUPER BIG fan of the Remote Desktop Virtualization Team. )
Can you please elaborate? I can’t tell the difference in the way you are starting the app (what is the app?).
Scenario 1: start RDP session, log into the terminal server/RD Session Host server, and start the app. Is this right?
Scenario 2: Can you elablorate here on the steps you go through?
Are you using RemoteApp or full desktop sessions?
What server OS and client OS are you running?
Host (office computer) — Windows 7 x64.
Clients (remote home computers) — various types and Windows releases (XP, Vista, 7)
Application — CAD software based on OpenGL. In fact there are even two versions of the same CAD software. Old release uses OpenGL 1 and new release uses OpenGL 2
Being in the office and sitting by the host computer we start Old CAD and New CAD.
Then we go home and connect via VPN and Remote Desktop to this host from our home computers.
Both Old CAD and New CAD work fine in this case. List of OpenGL context options that we can get in the special command of the CAD application corresponds to GPU of the host machine. As I understand RDP in this scenario just transfers bitmap of OpenGL window from host to client.
From home computer we connect via VPN and Remote Desktop to the office host. Only after that we start Old CAD and New CAD. Old CAD based on OpenGL 1 works fine. New CAD that uses OpenGL 2 does not work. The list of OpenGL context modes that may be used for initializing OpenGL shows that they correpond to GPU of the home computer, not host computer. This means that OpenGL is actually running on the client computer.
From this behaviour we made conclusion that RDP uses different schemes depending on how OpenGL software was started. I heard that RDP does not support OpenGL on client machines higher than 1.1. Besides, client machines may not support OpenGL 2. So the solution for the 2nd scenario may be RDP option to run OpenGL on host instead of running it on client.
So the question is how to force RDP to run OpenGL on host computer in scenario 2 so that it works the same as in scenario 1.
Thank you in advance!
In essence, you are using RDP to remote into a physical desktop PC. So host (office PC) and client (home PC) are both workstation OSes. Now you want to use OpenGL apps in such a scenario.
When you start the OpenGL apps on the office PC using the physically attached monitor and keyboard, the graphics card may be checked by OpenGL — there are some OpenGL apps that require physical hardware support and other OenGL apps that are happy with rendering OpenGL in software. Both checks are successful in this scenario and both flavors of OpenGL run properly. Now you go to your home PC and establish a remote connection to this user session. During the connection process, the capabilities of the home PC’s graphics card is sent to the host PC in order to optimize the graphics output. This is required to do some rendering on the receiver side rather than on the sender side. This is done for GDI graphics primitives, but not for openGL primitives. In your «remoting into existing user session» scenario the OpenGL output on the host is sent to the client pixel by pixel.
When you establish a new connection from a home PC to an office PC, the home PC’s graphics capabilities are relevant for the user session. Such a remote session does not support OpenGL in hardware — in other words, there is no 3D hardware graphics support. This is why only the software OpenGL app starts, but not the hardware OpenGL app. So your system works as designed even if it sounds weird.
Note: In both scenarios all applications run on the office PC. In the second scenario the graphics options are a little bit different due to the OpenGL app already launched in the existing user session. Actually, I’m surprised that it works at all. I would have expected that the hardware OpenGL app throws an error when remoting into the existing session.
I’m afraid that there’s not much can do about this behaviour if you don’t want to invest into Citrix (HDX Pro) or VMware/Teradici (PCoIP in HW) which supports 3D graphics acceleration in hardware from workstation to workstation. Another option is to run your OpenGL apps in Win7 virtual desktops hosted on Windows Server 2008 R2 SP1 Hyper-V and use the RemoteFX extension of the RDP protocol. This option also supports OpenGL in hardware if the appropriate graphics adapter is installed on the Hyper-V server.