none
OpenGL and Remote Desktop RRS feed

  • 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?

    Friday, January 28, 2011 5:37 PM

Answers

  • Hi,

    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.

    Worth a try.

    -TP

    • Marked as answer by tflex Monday, January 31, 2011 10:54 PM
    Monday, January 31, 2011 7:37 PM
    Moderator

All replies

  • tflex,

    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?


    Hope this helps,

    Kristin L. Griffin

    SUPER BIG fan of the Remote Desktop Virtualization Team!!!) 

    My RDS blog: blog.kristinlgriffin.com

    The new Microsoft Windows Server 2008 R2 Remote Desktop Services Resource Kit is now available!
    Friday, January 28, 2011 7:32 PM
    Moderator
  • tflex,

    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?



    Kristin,

    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

    Scenario 1: 

    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.

    Scenario 2:

    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!

    Friday, January 28, 2011 8:16 PM
  • 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.

    Benny

    • Proposed as answer by M4rc3lv Friday, July 1, 2016 12:47 AM
    Saturday, January 29, 2011 9:32 PM
  • Thank you, Benny!

    Could you please advise on one more thing.

    I tried to resolve this problem with one trick but failed.

    The idea was to launch OpenGL application in some automatic way when there is no remote session attached to the office computer so that OpenGL application would start in hardware mode.  From my home computer I connected to the office computer and launched the special process that had some delay before running CAD application. The delay was enough to abort remote session before the start of the OpenGL application. I tried .bat with "sleep" utility and Windows Task Scheduler but all the time after reconnecting to my office computer I could see my OpenGL application running in this what you say software OpenGL mode.

    What was my mistake and are there any other options for this idea? Or the only option is to have someone phisically in the office and use keyboard/mouse of the host computer to start the OpenGL application?

     

    Sunday, January 30, 2011 12:31 AM
  • This will not work as you are terminating the active user session you are connected to before launching the OenGL app through the Task Scheduler. Because of this the OpenGL app will not start in the right user session (remember, it's terminated) or it will launch in the wrong user session if there is any.

    At this moment I don't know of any way to accomplish what you want to do without someone sitting in front of the physical console and start the user session and the app for you. Sorry.

    Benny

    Monday, January 31, 2011 5:51 PM
  • Hi,

    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.

    Worth a try.

    -TP

    • Marked as answer by tflex Monday, January 31, 2011 10:54 PM
    Monday, January 31, 2011 7:37 PM
    Moderator
  • Cool idea, TP: Scripted disconnect and app launch! I agree, this is worth a try.

    Benny

    Monday, January 31, 2011 10:26 PM
  • Thanks a lot, TP! This works as intented!
    Monday, January 31, 2011 10:54 PM
  • > tscon 1 /dest:console
    > start "C:\Program Files\SolidWorks Corp\SolidWorks\sldworks.exe"

    I am pleased to report that suggested procedure has worked perfectly.

    ----------

    @echo off
    echo.
    echo Remote Desktop will be temporarily disconnected . . . please reconnect after a few seconds.
    echo.
    pause
    @echo on
    tscon.exe %SESSIONNAME% /v /dest:console
    @echo off
    echo.
    echo Starting MyProgram.exe . . .
    @echo on
    start MyProgram.exe
    @echo off
    echo.
    pause

    ----------

    @echo off
    if [%1]==[] goto DISCONTINUE
    echo.
    echo Remote Desktop will be temporarily disconnected . . . please reconnect after a few seconds.
    echo.
    pause
    @echo on
    tscon.exe %1 /v /dest:console
    @echo off
    echo.
    echo Starting MyProgram.exe . . .
    @echo on
    start MyProgram.exe
    @echo off
    echo.
    pause
    goto FINISH

    :DISCONTINUE
    echo.
    echo Please specify Session ID. (Session ID can be found with qwinsta.exe command.)
    echo.

    :FINISH

    Monday, September 1, 2014 7:18 AM
  • this is incredibly annoying.

    i end up using teamviewer to connect ( disconnecting RDP). Then launching the application and then connecting back with remote desktop.

    for me the problem is adobe software doesnt have hardware acceleration, and CUDA apps wont work if they are launched with RDP..

    wierd stuff, works perfectly after i connect back with RDP.. so it should be an easy fix somewhere...

    Tuesday, October 21, 2014 4:20 PM
  • Is this possible on Mac RD Client?
    Sunday, August 2, 2015 7:32 PM

  • @echo off
    if [%1]==[] goto DISCONTINUE
    echo.
    echo Remote Desktop will be temporarily disconnected . . . please reconnect after a few seconds.
    echo.
    pause
    @echo on
    tscon.exe %1 /v /dest:console
    @echo off
    echo.
    echo Starting MyProgram.exe . . .
    @echo on
    start MyProgram.exe
    @echo off
    echo.
    pause
    goto FINISH

    :DISCONTINUE
    echo.
    echo Please specify Session ID. (Session ID can be found with qwinsta.exe command.)
    echo.

    :FINISH

    We can go further, and detect the current active session in the script

    @echo off echo. echo Remote Desktop will be temporarily disconnected . . . please reconnect after a few seconds. echo. pause @echo on

    REM The active session has an arrow as the first character setlocal EnableDelayedExpansion FOR /F %%A in ('qwinsta') do ( set tempSessionName=%%A if "!tempSessionName:~0,1!"==">" ( @echo on tscon.exe !tempSessionName:~1! /v /dest:console @echo off ) ) @echo off echo. echo Starting MyProgram.exe . . . @echo on start MyProgram.exe @echo off echo. pause



    Tuesday, February 28, 2017 11:58 AM
  • 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.

    Benny

    I have read through this (admittedly very old thread) and it is very close to the problem I am having with just some new problems.  I also am trying to avoid any sort of batch file changes like the ones recommended.  Here is my situation:

    -  My host PC runs Windows Server 2016 R2 (professionally maintained by my IT Department and always kept up to date).  I am an admin on this server but I am not a server expert.

    -  On the host PC I run a CAD package (Cura, a 3D printing slicing engine) and it runs very well locally.

    -  The host PC has a GeForce 1080Ti GPU and the problem is absolutely associated with GeForce drivers.  I have confirmed this multiple ways (similar server runs fine remotely with a Quadro GPU and I put a Quadro K1200 in the host PC and the problems goes away).

    -  Problem only occurs when using remote desktop into the server and then loading the CAD package (Cura).  Cura responds with a "Failed to probe OpenGL" error.

    -  We have attempted to enable every RemoteFX option within Windows Server 2012 but none have worked.  

    So bottom line, the problem occurs only when using remote desktop (LAN or VPN) and with a GeForce driver.

    Any help is greatly appreciated.  The entire purpose of this server is to allow remote CAD operations so right now the entire lab is not fully operational.

    Wednesday, September 19, 2018 12:08 AM
  • Dear bwbaker,

    I was wondering if you found an answer yet?
    I used the batch file method, with some succes. But I have to use teamviewer as well, because the start command does not work properly.

    Milo

    Tuesday, November 6, 2018 8:20 AM
  • Actually, the app keeps crashing on the server. Probably because of some opengl error.
    Tuesday, November 6, 2018 10:20 AM
  • I also have this OpenGL/heavy design software problem and I can acknowledge the RDP/OpenGL version/driver conflict. I've solved it until now by changing to a machine not having a (specific) FirePro or GeForce card/driver :-(

    The Quadro card/driver is working ok (until now). What makes it confusing is that I also have a similar Firepro card in a W7 and W10 machine, where one is working ok (W10) and the other not (W7 - defaulting to OpenGL 1.1); incl. different driver versions.

    Btw: talking about Remote Web Access (RDP to the client)

    Thursday, November 8, 2018 12:50 PM
  • Hi,

    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.

    Worth a try.

    -TP

    Hi ... I'm having the similar issue ... I'm getting an Error 87 when trying to launch CAD over RDP.

    I belive the error is becuase the session in nopt connected to local video ... 

    I have tried ..... 

    tscon 1 /dest:console

    start "" "C:\Program Files\Autodesk\AutoCAD 2018\acad.exe"  /product ACAD /language "en-US"

    The user is not a local admin to the remote computer. ... It doesn't work 

    Monday, April 1, 2019 11:30 AM

  • @echo off
    if [%1]==[] goto DISCONTINUE
    echo.
    echo Remote Desktop will be temporarily disconnected . . . please reconnect after a few seconds.
    echo.
    pause
    @echo on
    tscon.exe %1 /v /dest:console
    @echo off
    echo.
    echo Starting MyProgram.exe . . .
    @echo on
    start MyProgram.exe
    @echo off
    echo.
    pause
    goto FINISH

    :DISCONTINUE
    echo.
    echo Please specify Session ID. (Session ID can be found with qwinsta.exe command.)
    echo.

    :FINISH

    We can go further, and detect the current active session in the script

    @echo off echo. echo Remote Desktop will be temporarily disconnected . . . please reconnect after a few seconds. echo. pause @echo on

    REM The active session has an arrow as the first character setlocal EnableDelayedExpansion FOR /F %%A in ('qwinsta') do ( set tempSessionName=%%A if "!tempSessionName:~0,1!"==">" ( @echo on tscon.exe !tempSessionName:~1! /v /dest:console @echo off ) ) @echo off echo. echo Starting MyProgram.exe . . . @echo on start MyProgram.exe @echo off echo. pause



    In my case it worked perfectly. I've just changed 'start' command with 'Call' because it opened another cmd session instead of calling the real exe.

    Good job guys!


    • Edited by Clint-67 Monday, July 29, 2019 7:53 AM
    Monday, July 29, 2019 7:53 AM