Hi, Is it so important to use RDP, why not try VNC ? IMHO this topic covers it:
http://www.opengl.org/discussion_boards/showthread.php/164372-Remote-Desktop On 03/18/2014 01:43 PM, 황석연 wrote: > So using GL acceleration via DISPLAY_DEVICE_PRIMARY_DEVICE within Windows > remoting session is impossible ?? > > > > Or, could you try this ?? > > > > ------- *Original Message* ------- > > *Sender* : Stanislav Vorobiov<[email protected]> Expert > Engineer/SRR-Tizen S/W Group/삼성전자 > > *Date* : 2014-03-18 15:47 (GMT+09:00) > > *Title* : Re: [Dev] [SDK/Emulator] Discuss about remote GL acceleration. > > > > Oh, you mean you launch QEMU itself from withing remoting session and GL caps > test doesn't pass. Yes this is expected. > > Have you tried doing it on linux ? m.b. AIGLX can help in this case. > > And regarding windows RDP, quick googling revealed that you can't have 3D > acceleration in remote sessions, though it's possible, but it's really slow > and this is for DirectX only and I'm not sure if it'll work for OpenGL: > > http://stackoverflow.com/questions/272537/direct3d-over-remote-desktop > > On 03/18/2014 08:03 AM, SeokYeon Hwang wrote: >> I'm not talking about a specific issue. >> >> I'd like to discuss about the possible solutions regarding the auto-test >> issues, and add new functionalities if needed. >> >> Currently, it is possible to use "spice" on Linux host. >> >> However, on Windows host, it is unfeasible to run tests using Spice because >> of the Spice server's inability to support Windows host yet. >> >> So, I suggest running tests using Windows RDP for now. >> >> (I haven't yet found out whether Windows RDP can send screens drawn with GL >> to clients or not. >> >> Even if it can't send the screens, as long as it can be enabled we may use >> it in auto-tests.) >> >> The first issue we encouter is that it cannot pass the GL capability test >> when connected remotely from RDP. >> >> When we run "check-gl.exe" in Tizen SDK, the result becomes false. >> >> It is because of the fact that the display device is >> DISPLAY_DEVICE_MIRRORING_DRIVER. >> >> If we can find a solution to this issue, we can at least solve the auto-test >> issue. >> >> >> >> If you have any other suggestions, please feel free to tell me. >> >> Thanks. >> >> >> >> ------- *Original Message* ------- >> >> *Sender* : Stanislav VorobiovExpert Engineer/SRR-Tizen S/W Group/삼성전자 >> >> *Date* : 2014-03-17 17:40 (GMT+09:00) >> >> *Title* : Re: [Dev] [SDK/Emulator] Discuss about remote GL acceleration. >> >> >> >> Hi, SeokYeon >> >> So, if I understand correctly, you've launched the emulator on one machine >> and >> then try to connect to it from different machine using RDP, right ? >> >> So, RDP basically presents QEMU graphic console contents to the client, i.e. >> GL acceleration >> should happen on server as usual, right ? >> >> How can I reproduce this ? What command line should be used to launch qemu >> in server mode so >> RDP clients are able to connect ? >> >> Do I need some special RDP client or can I use standard window's RDP for >> example ? >> >> On 03/17/2014 12:18 PM, SeokYeon Hwang wrote: >>> Yes, the remote approach is likely to be based on "spice", or any other >>> solution with similar features. >>> >>> When considering remote execution, we have to run the emulator from remote, >>> >>> and bring the screen to us using "spice" or a similar solution. >>> >>> But, there's a problem. >>> >>> When we use Windows Remote Desktop to connect and run GL capability tests, >>> the result is "false". >>> >>> Because the device which Remote Desktop uses does not utilize >>> DISPLAY_DEVICE_PRIMARY_DEVICE which supports GL, but rather >>> DISPLAY_DEVICE_MIRRORING_DRIVER. >>> >>> (http://msdn.microsoft.com/en-us/library/windows/desktop/dd183569%28v=vs.85%29.aspx) >>> >>> While different from Windows, Linux is believed to have limitations in GL >>> acceleration as well. >>> >>> >>> >>> The same thing happens when we run tests using CI tools such as Jenkins, >>> >>> since the Jenkins' master node connects to each of the OS slave nodes and >>> run the tests. >>> >>> >>> >>> Being not an expert about these issues, I'd like to discuss and find >>> solutions together. >>> >>> Thanks. >>> >>> >>> >>> ------- *Original Message* ------- >>> >>> *Sender* : Stanislav VorobiovExpert Engineer/SRR-Tizen S/W Group/삼성전자 >>> >>> *Date* : 2014-03-14 15:36 (GMT+09:00) >>> >>> *Title* : Re: [Dev] [SDK/Emulator] Discuss about remote GL acceleration. >>> >>> >>> >>> Hi, SeokYeon >>> >>> Could you provide more info on the remote approach being used ? It's based >>> on spice, right ? >>> >>> What does "PRIMARY DISPLAY DEVICE" mean in this context ? >>> >>> What does "emulator remote execution" and "emulator GL auto test on CI >>> tool" mean ? >>> >>> These lines: >>> >>>> It does not need to draw screen on "MONITOR SCREEN" connected to remote >>>> host PC. >>>> >>>> In case of "emulator remote execution", the drawing image can get another >>>> way into my "MONITOR SCREEN". >>> >>> Are also not clear to me. Could you give some overview of this so that we >>> could >>> get a better picture of what's going on. >>> >>> Thanks. >>> >>> On 03/14/2014 06:12 AM, 황석연 wrote: >>>> Hi, stanislav and other emulator GL acceleration developer. >>>> >>>> >>>> >>>> When we connect host PC on remote, we can not trun on GL acceleration. >>>> >>>> Because "remote desktop" did not use PRIMARY DISPLAY DEVICE. >>>> >>>> Is there no method to enable GL acceleration on remote ?? >>>> >>>> >>>> >>>> It is related with "emulator remote execution" and "emulator GL auto test >>>> on CI tool". >>>> >>>> How can we use GL acceleration via remote connection ? >>>> >>>> It does not need to draw screen on "MONITOR SCREEN" connected to remote >>>> host PC. >>>> >>>> In case of "emulator remote execution", the drawing image can get another >>>> way into my "MONITOR SCREEN". >>>> >>>> >>>> >>>> Thanks. >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> _______________________________________________ >>>> Dev mailing list >>>> [email protected] >>>> https://lists.tizen.org/listinfo/dev >>>> >>> >>> >>> >>> >>> >>> >>> >> >> >> >> >> >> >> > > > > > > > _______________________________________________ Dev mailing list [email protected] https://lists.tizen.org/listinfo/dev
