From erappleman at gmail.com Tue Oct 4 05:11:34 2011 From: erappleman at gmail.com (Eric Appleman) Date: Tue, 04 Oct 2011 00:11:34 -0400 Subject: [winswitch] Using Xpra on multi-GPU laptops Message-ID: <4E8A8776.20208@gmail.com> Hi, I've been fiddling around with Xpra as a replacement to the Bumblebee Project's[1] VirtualGL backend. Bumblebee permits access to the Nvidia GPU on Optimus laptops. By using the X server it creates, we can start applications on the invisible Nvidia screen. I want Xpra to replace VirtualGL as the transport method, but I need the screen to display at a normal framerate. I've included a demonstration that compares rendering through Xpra and without it. Feel free to drop by #bumblebee-dev on Freenode if you have ideas or questions. Thanks. - Eric [1] https://github.com/Bumblebee-Project/Bumblebee Example: http://www.youtube.com/watch?v=IN8heIMqTa8 1. Start Bumblebee X server on :8 optirun glxinfo 2.Start Xpra server xpra start :8 3. Attach :8 to :0, the Intel screen xpra attach :8 4. Start applications on Nvidia screen DISPLAY=:8 glxgears 5. Repeat step 4 as necessary From antoine at nagafix.co.uk Tue Oct 4 15:57:24 2011 From: antoine at nagafix.co.uk (Antoine Martin) Date: Tue, 04 Oct 2011 21:57:24 +0700 Subject: [winswitch] Using Xpra on multi-GPU laptops In-Reply-To: <4E8A8776.20208@gmail.com> References: <4E8A8776.20208@gmail.com> Message-ID: <4E8B1ED4.6000701@nagafix.co.uk> On 04/10/11 11:11, Eric Appleman wrote: > Hi, I've been fiddling around with Xpra as a replacement to the > Bumblebee Project's[1] VirtualGL backend. Bumblebee permits access to > the Nvidia GPU on Optimus laptops. By using the X server it creates, > we can start applications on the invisible Nvidia screen. > > I want Xpra to replace VirtualGL as the transport method, but I need > the screen to display at a normal framerate. Just out of curiosity, what makes you prefer Xpra over VirtualGL. At first I thought VirtualGL would be a more natural fit, but.. maybe it isn't? > > I've included a demonstration that compares rendering through Xpra and > without it. Feel free to drop by #bumblebee-dev on Freenode if you > have ideas or questions. I've looked at the video and it certainly looks interesting and challenging for Xpra... You haven't specified which command line options you have used or which version of Xpra you are using (trunk?). I would suggest you try with trunk, turn compression off, try with all 3 screen encoding options (rgb24, jpeg and png), with jpeg you may want to try different quality settings. It is a little bit strange how the screen updates seem a little disjointed, but I guess that is because it is falling too far behind the real screen? If we can come up with a test case to reproduce this (one that does not involve me buying a new laptop preferably!), then I am sure there are improvements that can be made. For example, there are also some real issues with the python networking code which make it less than optimal... Maybe tackling those would already make a noticeable difference. Is the refresh rate and artifacts very different from using Xpra with Xvfb/Xdummy? I've tried running glxgears in xpra, and although it's not super smooth, it looks ok-ish... I have recently added to trunk some code to rate-limit screen updates at 20ups, maybe you hit this limit? Are you CPU bound? I don't really understand the architecture of bumblebee, do you get a secondary X11 display which is not actually bound to any video ports? Cheers Antoine > > Thanks. > > - Eric > > [1] https://github.com/Bumblebee-Project/Bumblebee > > Example: > http://www.youtube.com/watch?v=IN8heIMqTa8 > > 1. Start Bumblebee X server on :8 > optirun glxinfo > > 2.Start Xpra server > xpra start :8 > > 3. Attach :8 to :0, the Intel screen > xpra attach :8 > > 4. Start applications on Nvidia screen > DISPLAY=:8 glxgears > > 5. Repeat step 4 as necessary > _______________________________________________ > shifter-users mailing list > shifter-users at lists.devloop.org.uk > http://lists.devloop.org.uk/mailman/listinfo/shifter-users From erappleman at gmail.com Tue Oct 4 19:49:55 2011 From: erappleman at gmail.com (Eric Appleman) Date: Tue, 04 Oct 2011 14:49:55 -0400 Subject: [winswitch] Using Xpra on multi-GPU laptops In-Reply-To: <4E8B1ED4.6000701@nagafix.co.uk> References: <4E8A8776.20208@gmail.com> <4E8B1ED4.6000701@nagafix.co.uk> Message-ID: <4E8B5553.4060601@gmail.com> * VirtualGL doesn't expose the Nvidia hardware the way we'd like because VDPAU and NV17 are not accessible as video output. Furthermore, there is a significant performance penalty that we discovered is not present in more direct solutions such as hybrid-windump and Xpra. * I tried r202 last night with the following commands: xpra start --encoding=rgb24 -z 0 :8 xpra attach --encoding=rgb24 -z 0 :8 Is it correct? I still had the screen update problem with PNG and RGB24. * I'm not familiar with Xvfb/Xdummy. Can you explain how to use it the relation to Xpra? * glxgears is not the best visual test. Try glxspheres or mplayer2/smplayer through Xpra. The latter is pretty much unusable. * The process using Xpra (and sometimes Xpra itself) is taking up a lot of CPU resources. I have 4 cores and 8 threads (i7-2630QM). It's taking up an entire core at times. I'm not sure what you mean by CPU-bound. * The second Xserver has no physical video output. Some Optimus laptops have the HDMI ports wired directly to the Nvidia GPU, but we are not targeting these exceptions as a default case. Kind regards, Eric On 10/04/2011 10:57 AM, Antoine Martin wrote: > On 04/10/11 11:11, Eric Appleman wrote: >> Hi, I've been fiddling around with Xpra as a replacement to the >> Bumblebee Project's[1] VirtualGL backend. Bumblebee permits access to >> the Nvidia GPU on Optimus laptops. By using the X server it creates, >> we can start applications on the invisible Nvidia screen. >> >> I want Xpra to replace VirtualGL as the transport method, but I need >> the screen to display at a normal framerate. > Just out of curiosity, what makes you prefer Xpra over VirtualGL. At > first I thought VirtualGL would be a more natural fit, but.. maybe it isn't? >> I've included a demonstration that compares rendering through Xpra and >> without it. Feel free to drop by #bumblebee-dev on Freenode if you >> have ideas or questions. > I've looked at the video and it certainly looks interesting and > challenging for Xpra... > > You haven't specified which command line options you have used or which > version of Xpra you are using (trunk?). > I would suggest you try with trunk, turn compression off, try with all 3 > screen encoding options (rgb24, jpeg and png), with jpeg you may want to > try different quality settings. > > It is a little bit strange how the screen updates seem a little > disjointed, but I guess that is because it is falling too far behind the > real screen? > If we can come up with a test case to reproduce this (one that does not > involve me buying a new laptop preferably!), then I am sure there are > improvements that can be made. For example, there are also some real > issues with the python networking code which make it less than > optimal... Maybe tackling those would already make a noticeable > difference. Is the refresh rate and artifacts very different from using > Xpra with Xvfb/Xdummy? > I've tried running glxgears in xpra, and although it's not super smooth, > it looks ok-ish... > > I have recently added to trunk some code to rate-limit screen updates at > 20ups, maybe you hit this limit? > Are you CPU bound? I don't really understand the architecture of > bumblebee, do you get a secondary X11 display which is not actually > bound to any video ports? > > Cheers > Antoine > > >> Thanks. >> >> - Eric >> >> [1]https://github.com/Bumblebee-Project/Bumblebee >> >> Example: >> http://www.youtube.com/watch?v=IN8heIMqTa8 >> >> 1. Start Bumblebee X server on :8 >> optirun glxinfo >> >> 2.Start Xpra server >> xpra start :8 >> >> 3. Attach :8 to :0, the Intel screen >> xpra attach :8 >> >> 4. Start applications on Nvidia screen >> DISPLAY=:8 glxgears >> >> 5. Repeat step 4 as necessary >> _______________________________________________ >> shifter-users mailing list >> shifter-users at lists.devloop.org.uk >> http://lists.devloop.org.uk/mailman/listinfo/shifter-users > _______________________________________________ > shifter-users mailing list > shifter-users at lists.devloop.org.uk > http://lists.devloop.org.uk/mailman/listinfo/shifter-users From antoine at nagafix.co.uk Wed Oct 5 06:59:43 2011 From: antoine at nagafix.co.uk (Antoine Martin) Date: Wed, 05 Oct 2011 12:59:43 +0700 Subject: [winswitch] Using Xpra on multi-GPU laptops In-Reply-To: <4E8B5553.4060601@gmail.com> References: <4E8A8776.20208@gmail.com> <4E8B1ED4.6000701@nagafix.co.uk> <4E8B5553.4060601@gmail.com> Message-ID: <4E8BF24F.70404@nagafix.co.uk> On 05/10/11 01:49, Eric Appleman wrote: > * VirtualGL doesn't expose the Nvidia hardware the way we'd like > because VDPAU and NV17 are not accessible as video output. > Furthermore, there is a significant performance penalty that we > discovered is not present in more direct solutions such as > hybrid-windump and Xpra. > > * I tried r202 last night with the following commands: > xpra start --encoding=rgb24 -z 0 :8 > xpra attach --encoding=rgb24 -z 0 :8 That's right (setting encoding and compression when "start"ing is not strictly necessary if you do specify it when "attach"ing as this takes precedence) > Is it correct? I still had the screen update problem with PNG and RGB24. OK, that's good to know as it means that the encoding performance is probably not causing the problem. > * I'm not familiar with Xvfb/Xdummy. Can you explain how to use it the > relation to Xpra? When you start Xpra the way you did above it will normally start an Xvfb server, not a real X11 display, which will not allow you to take advantage of hardware acceleration. If you have an existing accelerated X display, you should use the "--use-display" switch. I guess that ":8" is your accelerated display? Which means starting the Xvfb failed and xpra should have terminated with an error - will fix that.. Xdummy is just an alternative (probably not useful in your case since you run against something else), you can find all about it here: http://xpra.org/trac/ticket/10 > * glxgears is not the best visual test. Try glxspheres or > mplayer2/smplayer through Xpra. The latter is pretty much unusable. I've just tried glxspheres and I don't get any artifacts with either Xvfb or Xdummy. But it does render very very slowly (~5fps on a core2duo). Watching a video with mplayer works well enough though. Since I can't reproduce your problems, I have added a switch to turn off all damage update batching (since I suspect your hardware does more than 20fps) and upped the batching to not trigger until 30fps: http://xpra.org/trac/changeset/203 Please try this, also with "BATCH_EVENTS = False" as well as increasing the MAX_EVENTS and decreasing the BATCH_DELAY. Hopefully, we can find more optimal settings for your hardware. > * The process using Xpra (and sometimes Xpra itself) is taking up a > lot of CPU resources. I have 4 cores and 8 threads (i7-2630QM). It's > taking up an entire core at times. I'm not sure what you mean by > CPU-bound. There should be 2 processes, one for the client and one for the server, which one is the bottleneck? By CPU-bound I mean that CPU is the limiting factor. It would also be interesting to know how much bandwidth is being used, you should be able to work that out by using the tcp socket mode ("--bind-tcp="). > * The second Xserver has no physical video output. Some Optimus > laptops have the HDMI ports wired directly to the Nvidia GPU, but we > are not targeting these exceptions as a default case. ok. Antoine > > Kind regards, > Eric > > On 10/04/2011 10:57 AM, Antoine Martin wrote: >> On 04/10/11 11:11, Eric Appleman wrote: >>> Hi, I've been fiddling around with Xpra as a replacement to the >>> Bumblebee Project's[1] VirtualGL backend. Bumblebee permits access to >>> the Nvidia GPU on Optimus laptops. By using the X server it creates, >>> we can start applications on the invisible Nvidia screen. >>> >>> I want Xpra to replace VirtualGL as the transport method, but I need >>> the screen to display at a normal framerate. >> Just out of curiosity, what makes you prefer Xpra over VirtualGL. At >> first I thought VirtualGL would be a more natural fit, but.. maybe it >> isn't? >>> I've included a demonstration that compares rendering through Xpra and >>> without it. Feel free to drop by #bumblebee-dev on Freenode if you >>> have ideas or questions. >> I've looked at the video and it certainly looks interesting and >> challenging for Xpra... >> >> You haven't specified which command line options you have used or which >> version of Xpra you are using (trunk?). >> I would suggest you try with trunk, turn compression off, try with all 3 >> screen encoding options (rgb24, jpeg and png), with jpeg you may want to >> try different quality settings. >> >> It is a little bit strange how the screen updates seem a little >> disjointed, but I guess that is because it is falling too far behind the >> real screen? >> If we can come up with a test case to reproduce this (one that does not >> involve me buying a new laptop preferably!), then I am sure there are >> improvements that can be made. For example, there are also some real >> issues with the python networking code which make it less than >> optimal... Maybe tackling those would already make a noticeable >> difference. Is the refresh rate and artifacts very different from using >> Xpra with Xvfb/Xdummy? >> I've tried running glxgears in xpra, and although it's not super smooth, >> it looks ok-ish... >> >> I have recently added to trunk some code to rate-limit screen updates at >> 20ups, maybe you hit this limit? >> Are you CPU bound? I don't really understand the architecture of >> bumblebee, do you get a secondary X11 display which is not actually >> bound to any video ports? >> >> Cheers >> Antoine >> >> >>> Thanks. >>> >>> - Eric >>> >>> [1]https://github.com/Bumblebee-Project/Bumblebee >>> >>> Example: >>> http://www.youtube.com/watch?v=IN8heIMqTa8 >>> >>> 1. Start Bumblebee X server on :8 >>> optirun glxinfo >>> >>> 2.Start Xpra server >>> xpra start :8 >>> >>> 3. Attach :8 to :0, the Intel screen >>> xpra attach :8 >>> >>> 4. Start applications on Nvidia screen >>> DISPLAY=:8 glxgears >>> >>> 5. Repeat step 4 as necessary >>> _______________________________________________ >>> shifter-users mailing list >>> shifter-users at lists.devloop.org.uk >>> http://lists.devloop.org.uk/mailman/listinfo/shifter-users >> _______________________________________________ >> shifter-users mailing list >> shifter-users at lists.devloop.org.uk >> http://lists.devloop.org.uk/mailman/listinfo/shifter-users > > _______________________________________________ > shifter-users mailing list > shifter-users at lists.devloop.org.uk > http://lists.devloop.org.uk/mailman/listinfo/shifter-users From erappleman at gmail.com Wed Oct 5 07:57:35 2011 From: erappleman at gmail.com (Eric Appleman) Date: Wed, 05 Oct 2011 02:57:35 -0400 Subject: [winswitch] Using Xpra on multi-GPU laptops In-Reply-To: <4E8BF24F.70404@nagafix.co.uk> References: <4E8A8776.20208@gmail.com> <4E8B1ED4.6000701@nagafix.co.uk> <4E8B5553.4060601@gmail.com> <4E8BF24F.70404@nagafix.co.uk> Message-ID: <4E8BFFDF.8090304@gmail.com> Setting BATCH_EVENTS to False and adjusting those other settins didn't help. I didn't tinker too much since I'm not sure what they do. Is it possible that the problem boils down one of the Xpra processes taking 96% of my CPU in gnome-system-monitor. The second Xpra process uses 8% and mplayer2 uses an expected 24%. Here's a screenshot: http://i.imgur.com/EGJx2.png If I run another mplayer2 process on the Intel screen without Xpra, it renders fine. On 10/05/2011 01:59 AM, Antoine Martin wrote: > On 05/10/11 01:49, Eric Appleman wrote: >> * VirtualGL doesn't expose the Nvidia hardware the way we'd like >> because VDPAU and NV17 are not accessible as video output. >> Furthermore, there is a significant performance penalty that we >> discovered is not present in more direct solutions such as >> hybrid-windump and Xpra. >> >> * I tried r202 last night with the following commands: >> xpra start --encoding=rgb24 -z 0 :8 >> xpra attach --encoding=rgb24 -z 0 :8 > That's right > (setting encoding and compression when "start"ing is not strictly > necessary if you do specify it when "attach"ing as this takes precedence) >> Is it correct? I still had the screen update problem with PNG and RGB24. > OK, that's good to know as it means that the encoding performance is > probably not causing the problem. >> * I'm not familiar with Xvfb/Xdummy. Can you explain how to use it the >> relation to Xpra? > When you start Xpra the way you did above it will normally start an Xvfb > server, not a real X11 display, which will not allow you to take > advantage of hardware acceleration. If you have an existing accelerated > X display, you should use the "--use-display" switch. I guess that ":8" > is your accelerated display? Which means starting the Xvfb failed and > xpra should have terminated with an error - will fix that.. > Xdummy is just an alternative (probably not useful in your case since > you run against something else), you can find all about it here: > http://xpra.org/trac/ticket/10 >> * glxgears is not the best visual test. Try glxspheres or >> mplayer2/smplayer through Xpra. The latter is pretty much unusable. > I've just tried glxspheres and I don't get any artifacts with either > Xvfb or Xdummy. > But it does render very very slowly (~5fps on a core2duo). > Watching a video with mplayer works well enough though. > Since I can't reproduce your problems, I have added a switch to turn off > all damage update batching (since I suspect your hardware does more than > 20fps) and upped the batching to not trigger until 30fps: > http://xpra.org/trac/changeset/203 > Please try this, also with "BATCH_EVENTS = False" as well as increasing > the MAX_EVENTS and decreasing the BATCH_DELAY. Hopefully, we can find > more optimal settings for your hardware. >> * The process using Xpra (and sometimes Xpra itself) is taking up a >> lot of CPU resources. I have 4 cores and 8 threads (i7-2630QM). It's >> taking up an entire core at times. I'm not sure what you mean by >> CPU-bound. > There should be 2 processes, one for the client and one for the server, > which one is the bottleneck? > By CPU-bound I mean that CPU is the limiting factor. > It would also be interesting to know how much bandwidth is being used, > you should be able to work that out by using the tcp socket mode > ("--bind-tcp="). >> * The second Xserver has no physical video output. Some Optimus >> laptops have the HDMI ports wired directly to the Nvidia GPU, but we >> are not targeting these exceptions as a default case. > ok. > > Antoine >> Kind regards, >> Eric >> >> On 10/04/2011 10:57 AM, Antoine Martin wrote: >>> On 04/10/11 11:11, Eric Appleman wrote: >>>> Hi, I've been fiddling around with Xpra as a replacement to the >>>> Bumblebee Project's[1] VirtualGL backend. Bumblebee permits access to >>>> the Nvidia GPU on Optimus laptops. By using the X server it creates, >>>> we can start applications on the invisible Nvidia screen. >>>> >>>> I want Xpra to replace VirtualGL as the transport method, but I need >>>> the screen to display at a normal framerate. >>> Just out of curiosity, what makes you prefer Xpra over VirtualGL. At >>> first I thought VirtualGL would be a more natural fit, but.. maybe it >>> isn't? >>>> I've included a demonstration that compares rendering through Xpra and >>>> without it. Feel free to drop by #bumblebee-dev on Freenode if you >>>> have ideas or questions. >>> I've looked at the video and it certainly looks interesting and >>> challenging for Xpra... >>> >>> You haven't specified which command line options you have used or which >>> version of Xpra you are using (trunk?). >>> I would suggest you try with trunk, turn compression off, try with all 3 >>> screen encoding options (rgb24, jpeg and png), with jpeg you may want to >>> try different quality settings. >>> >>> It is a little bit strange how the screen updates seem a little >>> disjointed, but I guess that is because it is falling too far behind the >>> real screen? >>> If we can come up with a test case to reproduce this (one that does not >>> involve me buying a new laptop preferably!), then I am sure there are >>> improvements that can be made. For example, there are also some real >>> issues with the python networking code which make it less than >>> optimal... Maybe tackling those would already make a noticeable >>> difference. Is the refresh rate and artifacts very different from using >>> Xpra with Xvfb/Xdummy? >>> I've tried running glxgears in xpra, and although it's not super smooth, >>> it looks ok-ish... >>> >>> I have recently added to trunk some code to rate-limit screen updates at >>> 20ups, maybe you hit this limit? >>> Are you CPU bound? I don't really understand the architecture of >>> bumblebee, do you get a secondary X11 display which is not actually >>> bound to any video ports? >>> >>> Cheers >>> Antoine >>> >>> >>>> Thanks. >>>> >>>> - Eric >>>> >>>> [1]https://github.com/Bumblebee-Project/Bumblebee >>>> >>>> Example: >>>> http://www.youtube.com/watch?v=IN8heIMqTa8 >>>> >>>> 1. Start Bumblebee X server on :8 >>>> optirun glxinfo >>>> >>>> 2.Start Xpra server >>>> xpra start :8 >>>> >>>> 3. Attach :8 to :0, the Intel screen >>>> xpra attach :8 >>>> >>>> 4. Start applications on Nvidia screen >>>> DISPLAY=:8 glxgears >>>> >>>> 5. Repeat step 4 as necessary >>>> _______________________________________________ >>>> shifter-users mailing list >>>> shifter-users at lists.devloop.org.uk >>>> http://lists.devloop.org.uk/mailman/listinfo/shifter-users >>> _______________________________________________ >>> shifter-users mailing list >>> shifter-users at lists.devloop.org.uk >>> http://lists.devloop.org.uk/mailman/listinfo/shifter-users >> _______________________________________________ >> shifter-users mailing list >> shifter-users at lists.devloop.org.uk >> http://lists.devloop.org.uk/mailman/listinfo/shifter-users > _______________________________________________ > shifter-users mailing list > shifter-users at lists.devloop.org.uk > http://lists.devloop.org.uk/mailman/listinfo/shifter-users From antoine at nagafix.co.uk Wed Oct 5 08:14:36 2011 From: antoine at nagafix.co.uk (Antoine Martin) Date: Wed, 05 Oct 2011 14:14:36 +0700 Subject: [winswitch] Using Xpra on multi-GPU laptops In-Reply-To: <4E8BFFDF.8090304@gmail.com> References: <4E8A8776.20208@gmail.com> <4E8B1ED4.6000701@nagafix.co.uk> <4E8B5553.4060601@gmail.com> <4E8BF24F.70404@nagafix.co.uk> <4E8BFFDF.8090304@gmail.com> Message-ID: <4E8C03DC.5080505@nagafix.co.uk> On 05/10/11 13:57, Eric Appleman wrote: > Setting BATCH_EVENTS to False and adjusting those other settins didn't > help. I didn't tinker too much since I'm not sure what they do. > > Is it possible that the problem boils down one of the Xpra processes > taking 96% of my CPU in gnome-system-monitor. The second Xpra process > uses 8% and mplayer2 uses an expected 24%. Yes, clearly it is CPU bound. Can you please tell us which one it is, client or server? I am really not sure why I can run mplayer without problems using Xvfb, can you try that too? Antoine > > Here's a screenshot: http://i.imgur.com/EGJx2.png > > If I run another mplayer2 process on the Intel screen without Xpra, it > renders fine. > > On 10/05/2011 01:59 AM, Antoine Martin wrote: >> On 05/10/11 01:49, Eric Appleman wrote: >>> * VirtualGL doesn't expose the Nvidia hardware the way we'd like >>> because VDPAU and NV17 are not accessible as video output. >>> Furthermore, there is a significant performance penalty that we >>> discovered is not present in more direct solutions such as >>> hybrid-windump and Xpra. >>> >>> * I tried r202 last night with the following commands: >>> xpra start --encoding=rgb24 -z 0 :8 >>> xpra attach --encoding=rgb24 -z 0 :8 >> That's right >> (setting encoding and compression when "start"ing is not strictly >> necessary if you do specify it when "attach"ing as this takes >> precedence) >>> Is it correct? I still had the screen update problem with PNG and >>> RGB24. >> OK, that's good to know as it means that the encoding performance is >> probably not causing the problem. >>> * I'm not familiar with Xvfb/Xdummy. Can you explain how to use it the >>> relation to Xpra? >> When you start Xpra the way you did above it will normally start an Xvfb >> server, not a real X11 display, which will not allow you to take >> advantage of hardware acceleration. If you have an existing accelerated >> X display, you should use the "--use-display" switch. I guess that ":8" >> is your accelerated display? Which means starting the Xvfb failed and >> xpra should have terminated with an error - will fix that.. >> Xdummy is just an alternative (probably not useful in your case since >> you run against something else), you can find all about it here: >> http://xpra.org/trac/ticket/10 >>> * glxgears is not the best visual test. Try glxspheres or >>> mplayer2/smplayer through Xpra. The latter is pretty much unusable. >> I've just tried glxspheres and I don't get any artifacts with either >> Xvfb or Xdummy. >> But it does render very very slowly (~5fps on a core2duo). >> Watching a video with mplayer works well enough though. >> Since I can't reproduce your problems, I have added a switch to turn off >> all damage update batching (since I suspect your hardware does more than >> 20fps) and upped the batching to not trigger until 30fps: >> http://xpra.org/trac/changeset/203 >> Please try this, also with "BATCH_EVENTS = False" as well as increasing >> the MAX_EVENTS and decreasing the BATCH_DELAY. Hopefully, we can find >> more optimal settings for your hardware. >>> * The process using Xpra (and sometimes Xpra itself) is taking up a >>> lot of CPU resources. I have 4 cores and 8 threads (i7-2630QM). It's >>> taking up an entire core at times. I'm not sure what you mean by >>> CPU-bound. >> There should be 2 processes, one for the client and one for the server, >> which one is the bottleneck? >> By CPU-bound I mean that CPU is the limiting factor. >> It would also be interesting to know how much bandwidth is being used, >> you should be able to work that out by using the tcp socket mode >> ("--bind-tcp="). >>> * The second Xserver has no physical video output. Some Optimus >>> laptops have the HDMI ports wired directly to the Nvidia GPU, but we >>> are not targeting these exceptions as a default case. >> ok. >> >> Antoine >>> Kind regards, >>> Eric >>> >>> On 10/04/2011 10:57 AM, Antoine Martin wrote: >>>> On 04/10/11 11:11, Eric Appleman wrote: >>>>> Hi, I've been fiddling around with Xpra as a replacement to the >>>>> Bumblebee Project's[1] VirtualGL backend. Bumblebee permits access to >>>>> the Nvidia GPU on Optimus laptops. By using the X server it creates, >>>>> we can start applications on the invisible Nvidia screen. >>>>> >>>>> I want Xpra to replace VirtualGL as the transport method, but I need >>>>> the screen to display at a normal framerate. >>>> Just out of curiosity, what makes you prefer Xpra over VirtualGL. At >>>> first I thought VirtualGL would be a more natural fit, but.. maybe it >>>> isn't? >>>>> I've included a demonstration that compares rendering through Xpra >>>>> and >>>>> without it. Feel free to drop by #bumblebee-dev on Freenode if you >>>>> have ideas or questions. >>>> I've looked at the video and it certainly looks interesting and >>>> challenging for Xpra... >>>> >>>> You haven't specified which command line options you have used or >>>> which >>>> version of Xpra you are using (trunk?). >>>> I would suggest you try with trunk, turn compression off, try with >>>> all 3 >>>> screen encoding options (rgb24, jpeg and png), with jpeg you may >>>> want to >>>> try different quality settings. >>>> >>>> It is a little bit strange how the screen updates seem a little >>>> disjointed, but I guess that is because it is falling too far >>>> behind the >>>> real screen? >>>> If we can come up with a test case to reproduce this (one that does >>>> not >>>> involve me buying a new laptop preferably!), then I am sure there are >>>> improvements that can be made. For example, there are also some real >>>> issues with the python networking code which make it less than >>>> optimal... Maybe tackling those would already make a noticeable >>>> difference. Is the refresh rate and artifacts very different from >>>> using >>>> Xpra with Xvfb/Xdummy? >>>> I've tried running glxgears in xpra, and although it's not super >>>> smooth, >>>> it looks ok-ish... >>>> >>>> I have recently added to trunk some code to rate-limit screen >>>> updates at >>>> 20ups, maybe you hit this limit? >>>> Are you CPU bound? I don't really understand the architecture of >>>> bumblebee, do you get a secondary X11 display which is not actually >>>> bound to any video ports? >>>> >>>> Cheers >>>> Antoine >>>> >>>> >>>>> Thanks. >>>>> >>>>> - Eric >>>>> >>>>> [1]https://github.com/Bumblebee-Project/Bumblebee >>>>> >>>>> Example: >>>>> http://www.youtube.com/watch?v=IN8heIMqTa8 >>>>> >>>>> 1. Start Bumblebee X server on :8 >>>>> optirun glxinfo >>>>> >>>>> 2.Start Xpra server >>>>> xpra start :8 >>>>> >>>>> 3. Attach :8 to :0, the Intel screen >>>>> xpra attach :8 >>>>> >>>>> 4. Start applications on Nvidia screen >>>>> DISPLAY=:8 glxgears >>>>> >>>>> 5. Repeat step 4 as necessary >>>>> _______________________________________________ >>>>> shifter-users mailing list >>>>> shifter-users at lists.devloop.org.uk >>>>> http://lists.devloop.org.uk/mailman/listinfo/shifter-users >>>> _______________________________________________ >>>> shifter-users mailing list >>>> shifter-users at lists.devloop.org.uk >>>> http://lists.devloop.org.uk/mailman/listinfo/shifter-users >>> _______________________________________________ >>> shifter-users mailing list >>> shifter-users at lists.devloop.org.uk >>> http://lists.devloop.org.uk/mailman/listinfo/shifter-users >> _______________________________________________ >> shifter-users mailing list >> shifter-users at lists.devloop.org.uk >> http://lists.devloop.org.uk/mailman/listinfo/shifter-users > > _______________________________________________ > shifter-users mailing list > shifter-users at lists.devloop.org.uk > http://lists.devloop.org.uk/mailman/listinfo/shifter-users From erappleman at gmail.com Wed Oct 5 14:13:41 2011 From: erappleman at gmail.com (Eric Appleman) Date: Wed, 05 Oct 2011 09:13:41 -0400 Subject: [winswitch] Using Xpra on multi-GPU laptops In-Reply-To: <4E8C03DC.5080505@nagafix.co.uk> References: <4E8A8776.20208@gmail.com> <4E8B1ED4.6000701@nagafix.co.uk> <4E8B5553.4060601@gmail.com> <4E8BF24F.70404@nagafix.co.uk> <4E8BFFDF.8090304@gmail.com> <4E8C03DC.5080505@nagafix.co.uk> Message-ID: <4E8C5805.7050502@gmail.com> The bottleneck is the client process. As for Xvfb, it's really hard to say. When the window (mplayer X11 output) is displayed over VNC (is there a better way?), it's a slideshow. When run through Xpra, the process is CPU-bound and performs no better than the real hardware X server. On 10/05/2011 03:14 AM, Antoine Martin wrote: > On 05/10/11 13:57, Eric Appleman wrote: >> Setting BATCH_EVENTS to False and adjusting those other settins didn't >> help. I didn't tinker too much since I'm not sure what they do. >> >> Is it possible that the problem boils down one of the Xpra processes >> taking 96% of my CPU in gnome-system-monitor. The second Xpra process >> uses 8% and mplayer2 uses an expected 24%. > Yes, clearly it is CPU bound. Can you please tell us which one it is, > client or server? > > I am really not sure why I can run mplayer without problems using Xvfb, > can you try that too? > > Antoine > >> Here's a screenshot: http://i.imgur.com/EGJx2.png >> >> If I run another mplayer2 process on the Intel screen without Xpra, it >> renders fine. >> >> On 10/05/2011 01:59 AM, Antoine Martin wrote: >>> On 05/10/11 01:49, Eric Appleman wrote: >>>> * VirtualGL doesn't expose the Nvidia hardware the way we'd like >>>> because VDPAU and NV17 are not accessible as video output. >>>> Furthermore, there is a significant performance penalty that we >>>> discovered is not present in more direct solutions such as >>>> hybrid-windump and Xpra. >>>> >>>> * I tried r202 last night with the following commands: >>>> xpra start --encoding=rgb24 -z 0 :8 >>>> xpra attach --encoding=rgb24 -z 0 :8 >>> That's right >>> (setting encoding and compression when "start"ing is not strictly >>> necessary if you do specify it when "attach"ing as this takes >>> precedence) >>>> Is it correct? I still had the screen update problem with PNG and >>>> RGB24. >>> OK, that's good to know as it means that the encoding performance is >>> probably not causing the problem. >>>> * I'm not familiar with Xvfb/Xdummy. Can you explain how to use it the >>>> relation to Xpra? >>> When you start Xpra the way you did above it will normally start an Xvfb >>> server, not a real X11 display, which will not allow you to take >>> advantage of hardware acceleration. If you have an existing accelerated >>> X display, you should use the "--use-display" switch. I guess that ":8" >>> is your accelerated display? Which means starting the Xvfb failed and >>> xpra should have terminated with an error - will fix that.. >>> Xdummy is just an alternative (probably not useful in your case since >>> you run against something else), you can find all about it here: >>> http://xpra.org/trac/ticket/10 >>>> * glxgears is not the best visual test. Try glxspheres or >>>> mplayer2/smplayer through Xpra. The latter is pretty much unusable. >>> I've just tried glxspheres and I don't get any artifacts with either >>> Xvfb or Xdummy. >>> But it does render very very slowly (~5fps on a core2duo). >>> Watching a video with mplayer works well enough though. >>> Since I can't reproduce your problems, I have added a switch to turn off >>> all damage update batching (since I suspect your hardware does more than >>> 20fps) and upped the batching to not trigger until 30fps: >>> http://xpra.org/trac/changeset/203 >>> Please try this, also with "BATCH_EVENTS = False" as well as increasing >>> the MAX_EVENTS and decreasing the BATCH_DELAY. Hopefully, we can find >>> more optimal settings for your hardware. >>>> * The process using Xpra (and sometimes Xpra itself) is taking up a >>>> lot of CPU resources. I have 4 cores and 8 threads (i7-2630QM). It's >>>> taking up an entire core at times. I'm not sure what you mean by >>>> CPU-bound. >>> There should be 2 processes, one for the client and one for the server, >>> which one is the bottleneck? >>> By CPU-bound I mean that CPU is the limiting factor. >>> It would also be interesting to know how much bandwidth is being used, >>> you should be able to work that out by using the tcp socket mode >>> ("--bind-tcp="). >>>> * The second Xserver has no physical video output. Some Optimus >>>> laptops have the HDMI ports wired directly to the Nvidia GPU, but we >>>> are not targeting these exceptions as a default case. >>> ok. >>> >>> Antoine >>>> Kind regards, >>>> Eric >>>> >>>> On 10/04/2011 10:57 AM, Antoine Martin wrote: >>>>> On 04/10/11 11:11, Eric Appleman wrote: >>>>>> Hi, I've been fiddling around with Xpra as a replacement to the >>>>>> Bumblebee Project's[1] VirtualGL backend. Bumblebee permits access to >>>>>> the Nvidia GPU on Optimus laptops. By using the X server it creates, >>>>>> we can start applications on the invisible Nvidia screen. >>>>>> >>>>>> I want Xpra to replace VirtualGL as the transport method, but I need >>>>>> the screen to display at a normal framerate. >>>>> Just out of curiosity, what makes you prefer Xpra over VirtualGL. At >>>>> first I thought VirtualGL would be a more natural fit, but.. maybe it >>>>> isn't? >>>>>> I've included a demonstration that compares rendering through Xpra >>>>>> and >>>>>> without it. Feel free to drop by #bumblebee-dev on Freenode if you >>>>>> have ideas or questions. >>>>> I've looked at the video and it certainly looks interesting and >>>>> challenging for Xpra... >>>>> >>>>> You haven't specified which command line options you have used or >>>>> which >>>>> version of Xpra you are using (trunk?). >>>>> I would suggest you try with trunk, turn compression off, try with >>>>> all 3 >>>>> screen encoding options (rgb24, jpeg and png), with jpeg you may >>>>> want to >>>>> try different quality settings. >>>>> >>>>> It is a little bit strange how the screen updates seem a little >>>>> disjointed, but I guess that is because it is falling too far >>>>> behind the >>>>> real screen? >>>>> If we can come up with a test case to reproduce this (one that does >>>>> not >>>>> involve me buying a new laptop preferably!), then I am sure there are >>>>> improvements that can be made. For example, there are also some real >>>>> issues with the python networking code which make it less than >>>>> optimal... Maybe tackling those would already make a noticeable >>>>> difference. Is the refresh rate and artifacts very different from >>>>> using >>>>> Xpra with Xvfb/Xdummy? >>>>> I've tried running glxgears in xpra, and although it's not super >>>>> smooth, >>>>> it looks ok-ish... >>>>> >>>>> I have recently added to trunk some code to rate-limit screen >>>>> updates at >>>>> 20ups, maybe you hit this limit? >>>>> Are you CPU bound? I don't really understand the architecture of >>>>> bumblebee, do you get a secondary X11 display which is not actually >>>>> bound to any video ports? >>>>> >>>>> Cheers >>>>> Antoine >>>>> >>>>> >>>>>> Thanks. >>>>>> >>>>>> - Eric >>>>>> >>>>>> [1]https://github.com/Bumblebee-Project/Bumblebee >>>>>> >>>>>> Example: >>>>>> http://www.youtube.com/watch?v=IN8heIMqTa8 >>>>>> >>>>>> 1. Start Bumblebee X server on :8 >>>>>> optirun glxinfo >>>>>> >>>>>> 2.Start Xpra server >>>>>> xpra start :8 >>>>>> >>>>>> 3. Attach :8 to :0, the Intel screen >>>>>> xpra attach :8 >>>>>> >>>>>> 4. Start applications on Nvidia screen >>>>>> DISPLAY=:8 glxgears >>>>>> >>>>>> 5. Repeat step 4 as necessary >>>>>> _______________________________________________ >>>>>> shifter-users mailing list >>>>>> shifter-users at lists.devloop.org.uk >>>>>> http://lists.devloop.org.uk/mailman/listinfo/shifter-users >>>>> _______________________________________________ >>>>> shifter-users mailing list >>>>> shifter-users at lists.devloop.org.uk >>>>> http://lists.devloop.org.uk/mailman/listinfo/shifter-users >>>> _______________________________________________ >>>> shifter-users mailing list >>>> shifter-users at lists.devloop.org.uk >>>> http://lists.devloop.org.uk/mailman/listinfo/shifter-users >>> _______________________________________________ >>> shifter-users mailing list >>> shifter-users at lists.devloop.org.uk >>> http://lists.devloop.org.uk/mailman/listinfo/shifter-users >> _______________________________________________ >> shifter-users mailing list >> shifter-users at lists.devloop.org.uk >> http://lists.devloop.org.uk/mailman/listinfo/shifter-users > _______________________________________________ > shifter-users mailing list > shifter-users at lists.devloop.org.uk > http://lists.devloop.org.uk/mailman/listinfo/shifter-users From antoine at nagafix.co.uk Wed Oct 5 15:35:20 2011 From: antoine at nagafix.co.uk (Antoine Martin) Date: Wed, 05 Oct 2011 21:35:20 +0700 Subject: [winswitch] Using Xpra on multi-GPU laptops In-Reply-To: <4E8C5805.7050502@gmail.com> References: <4E8A8776.20208@gmail.com> <4E8B1ED4.6000701@nagafix.co.uk> <4E8B5553.4060601@gmail.com> <4E8BF24F.70404@nagafix.co.uk> <4E8BFFDF.8090304@gmail.com> <4E8C03DC.5080505@nagafix.co.uk> <4E8C5805.7050502@gmail.com> Message-ID: <4E8C6B28.80404@nagafix.co.uk> On 05/10/11 20:13, Eric Appleman wrote: > The bottleneck is the client process. I'll try to stress it a bit and see what can be done to optimize it. > > As for Xvfb, it's really hard to say. When the window (mplayer X11 > output) is displayed over VNC (is there a better way?), it's a slideshow. I am confused, what do you need VNC for here? > When run through Xpra, the process is CPU-bound and performs no better > than the real hardware X server. OK, let me try to recap things: * mplayer via xpra is (almost?) watchable, right? (albeit CPU-bound and no faster than the onboard non-nvidia/slow graphics adapter - I think this is what you called "real hardware X server"?) * glxspheres via xpra shows lots of artifacts (as can be seen on your youtube video) I think that modern hardware should be able to cope with copying a screen region from one card to the other at 30fps: 1024*1024*32bit*30fps = 120MB/s So I may just add a manual refresh mode just to test this hypothesis (and it may be useful for stressing the client too), then if this works ok we will know that the artifacts issue can be solved one way or another... Looking ahead though, it seems to me that for your use case having a full network stack and copying screen regions to and from python structures is very inefficient. Things would be a hell of a lot faster using direct memory access (shared memory) - are there any constraints with your hardware on that front? Antoine > On 10/05/2011 03:14 AM, Antoine Martin wrote: >> On 05/10/11 13:57, Eric Appleman wrote: >>> Setting BATCH_EVENTS to False and adjusting those other settins didn't >>> help. I didn't tinker too much since I'm not sure what they do. >>> >>> Is it possible that the problem boils down one of the Xpra processes >>> taking 96% of my CPU in gnome-system-monitor. The second Xpra process >>> uses 8% and mplayer2 uses an expected 24%. >> Yes, clearly it is CPU bound. Can you please tell us which one it is, >> client or server? >> >> I am really not sure why I can run mplayer without problems using Xvfb, >> can you try that too? >> >> Antoine >> >>> Here's a screenshot: http://i.imgur.com/EGJx2.png >>> >>> If I run another mplayer2 process on the Intel screen without Xpra, it >>> renders fine. >>> >>> On 10/05/2011 01:59 AM, Antoine Martin wrote: >>>> On 05/10/11 01:49, Eric Appleman wrote: >>>>> * VirtualGL doesn't expose the Nvidia hardware the way we'd like >>>>> because VDPAU and NV17 are not accessible as video output. >>>>> Furthermore, there is a significant performance penalty that we >>>>> discovered is not present in more direct solutions such as >>>>> hybrid-windump and Xpra. >>>>> >>>>> * I tried r202 last night with the following commands: >>>>> xpra start --encoding=rgb24 -z 0 :8 >>>>> xpra attach --encoding=rgb24 -z 0 :8 >>>> That's right >>>> (setting encoding and compression when "start"ing is not strictly >>>> necessary if you do specify it when "attach"ing as this takes >>>> precedence) >>>>> Is it correct? I still had the screen update problem with PNG and >>>>> RGB24. >>>> OK, that's good to know as it means that the encoding performance is >>>> probably not causing the problem. >>>>> * I'm not familiar with Xvfb/Xdummy. Can you explain how to use it >>>>> the >>>>> relation to Xpra? >>>> When you start Xpra the way you did above it will normally start an >>>> Xvfb >>>> server, not a real X11 display, which will not allow you to take >>>> advantage of hardware acceleration. If you have an existing >>>> accelerated >>>> X display, you should use the "--use-display" switch. I guess that >>>> ":8" >>>> is your accelerated display? Which means starting the Xvfb failed and >>>> xpra should have terminated with an error - will fix that.. >>>> Xdummy is just an alternative (probably not useful in your case since >>>> you run against something else), you can find all about it here: >>>> http://xpra.org/trac/ticket/10 >>>>> * glxgears is not the best visual test. Try glxspheres or >>>>> mplayer2/smplayer through Xpra. The latter is pretty much unusable. >>>> I've just tried glxspheres and I don't get any artifacts with either >>>> Xvfb or Xdummy. >>>> But it does render very very slowly (~5fps on a core2duo). >>>> Watching a video with mplayer works well enough though. >>>> Since I can't reproduce your problems, I have added a switch to >>>> turn off >>>> all damage update batching (since I suspect your hardware does more >>>> than >>>> 20fps) and upped the batching to not trigger until 30fps: >>>> http://xpra.org/trac/changeset/203 >>>> Please try this, also with "BATCH_EVENTS = False" as well as >>>> increasing >>>> the MAX_EVENTS and decreasing the BATCH_DELAY. Hopefully, we can find >>>> more optimal settings for your hardware. >>>>> * The process using Xpra (and sometimes Xpra itself) is taking up a >>>>> lot of CPU resources. I have 4 cores and 8 threads (i7-2630QM). It's >>>>> taking up an entire core at times. I'm not sure what you mean by >>>>> CPU-bound. >>>> There should be 2 processes, one for the client and one for the >>>> server, >>>> which one is the bottleneck? >>>> By CPU-bound I mean that CPU is the limiting factor. >>>> It would also be interesting to know how much bandwidth is being used, >>>> you should be able to work that out by using the tcp socket mode >>>> ("--bind-tcp="). >>>>> * The second Xserver has no physical video output. Some Optimus >>>>> laptops have the HDMI ports wired directly to the Nvidia GPU, but we >>>>> are not targeting these exceptions as a default case. >>>> ok. >>>> >>>> Antoine >>>>> Kind regards, >>>>> Eric >>>>> >>>>> On 10/04/2011 10:57 AM, Antoine Martin wrote: >>>>>> On 04/10/11 11:11, Eric Appleman wrote: >>>>>>> Hi, I've been fiddling around with Xpra as a replacement to the >>>>>>> Bumblebee Project's[1] VirtualGL backend. Bumblebee permits >>>>>>> access to >>>>>>> the Nvidia GPU on Optimus laptops. By using the X server it >>>>>>> creates, >>>>>>> we can start applications on the invisible Nvidia screen. >>>>>>> >>>>>>> I want Xpra to replace VirtualGL as the transport method, but I >>>>>>> need >>>>>>> the screen to display at a normal framerate. >>>>>> Just out of curiosity, what makes you prefer Xpra over VirtualGL. At >>>>>> first I thought VirtualGL would be a more natural fit, but.. >>>>>> maybe it >>>>>> isn't? >>>>>>> I've included a demonstration that compares rendering through Xpra >>>>>>> and >>>>>>> without it. Feel free to drop by #bumblebee-dev on Freenode if you >>>>>>> have ideas or questions. >>>>>> I've looked at the video and it certainly looks interesting and >>>>>> challenging for Xpra... >>>>>> >>>>>> You haven't specified which command line options you have used or >>>>>> which >>>>>> version of Xpra you are using (trunk?). >>>>>> I would suggest you try with trunk, turn compression off, try with >>>>>> all 3 >>>>>> screen encoding options (rgb24, jpeg and png), with jpeg you may >>>>>> want to >>>>>> try different quality settings. >>>>>> >>>>>> It is a little bit strange how the screen updates seem a little >>>>>> disjointed, but I guess that is because it is falling too far >>>>>> behind the >>>>>> real screen? >>>>>> If we can come up with a test case to reproduce this (one that does >>>>>> not >>>>>> involve me buying a new laptop preferably!), then I am sure there >>>>>> are >>>>>> improvements that can be made. For example, there are also some real >>>>>> issues with the python networking code which make it less than >>>>>> optimal... Maybe tackling those would already make a noticeable >>>>>> difference. Is the refresh rate and artifacts very different from >>>>>> using >>>>>> Xpra with Xvfb/Xdummy? >>>>>> I've tried running glxgears in xpra, and although it's not super >>>>>> smooth, >>>>>> it looks ok-ish... >>>>>> >>>>>> I have recently added to trunk some code to rate-limit screen >>>>>> updates at >>>>>> 20ups, maybe you hit this limit? >>>>>> Are you CPU bound? I don't really understand the architecture of >>>>>> bumblebee, do you get a secondary X11 display which is not actually >>>>>> bound to any video ports? >>>>>> >>>>>> Cheers >>>>>> Antoine >>>>>> >>>>>> >>>>>>> Thanks. >>>>>>> >>>>>>> - Eric >>>>>>> >>>>>>> [1]https://github.com/Bumblebee-Project/Bumblebee >>>>>>> >>>>>>> Example: >>>>>>> http://www.youtube.com/watch?v=IN8heIMqTa8 >>>>>>> >>>>>>> 1. Start Bumblebee X server on :8 >>>>>>> optirun glxinfo >>>>>>> >>>>>>> 2.Start Xpra server >>>>>>> xpra start :8 >>>>>>> >>>>>>> 3. Attach :8 to :0, the Intel screen >>>>>>> xpra attach :8 >>>>>>> >>>>>>> 4. Start applications on Nvidia screen >>>>>>> DISPLAY=:8 glxgears >>>>>>> >>>>>>> 5. Repeat step 4 as necessary >>>>>>> _______________________________________________ From erappleman at gmail.com Thu Oct 6 06:03:27 2011 From: erappleman at gmail.com (Eric Appleman) Date: Thu, 06 Oct 2011 01:03:27 -0400 Subject: [winswitch] Using Xpra on multi-GPU laptops In-Reply-To: <4E8C6B28.80404@nagafix.co.uk> References: <4E8A8776.20208@gmail.com> <4E8B1ED4.6000701@nagafix.co.uk> <4E8B5553.4060601@gmail.com> <4E8BF24F.70404@nagafix.co.uk> <4E8BFFDF.8090304@gmail.com> <4E8C03DC.5080505@nagafix.co.uk> <4E8C5805.7050502@gmail.com> <4E8C6B28.80404@nagafix.co.uk> Message-ID: <4E8D369F.1040602@gmail.com> For Xvfb, I couldn't figure out how to get the window to render unless I used it with Xpra. At the very minimum, I think transport would need to cope with 1920x1080x32 at 60 Hz for vsync. Given this, an XShm solution that is similar to hybrid-windump (https://github.com/harp1n/hybrid-windump) would probably be needed. The problem is that isn't as complete or elegant as Xpra. For an Optimus notebook, the expectation is very good hardware. CPU will be an Intel Arrandale (1st Gen Core i) or Sandy Bridge (2nd Gen Core i) and memory should be at least 2GB. - Eric From erappleman at gmail.com Fri Oct 7 21:13:21 2011 From: erappleman at gmail.com (Eric Appleman) Date: Fri, 07 Oct 2011 16:13:21 -0400 Subject: [winswitch] Using Xpra on multi-GPU laptops In-Reply-To: <4E8C6B28.80404@nagafix.co.uk> References: <4E8A8776.20208@gmail.com> <4E8B1ED4.6000701@nagafix.co.uk> <4E8B5553.4060601@gmail.com> <4E8BF24F.70404@nagafix.co.uk> <4E8BFFDF.8090304@gmail.com> <4E8C03DC.5080505@nagafix.co.uk> <4E8C5805.7050502@gmail.com> <4E8C6B28.80404@nagafix.co.uk> Message-ID: <4E8F5D61.4090804@gmail.com> I'm somewhat comfortable with my Python and would like examine the windowing code for the Xpra client. Is client.py the right file to examine? I'd like to get a sense of what libraries you guys are using and how they are used. - Eric From antoine at nagafix.co.uk Tue Oct 18 10:49:48 2011 From: antoine at nagafix.co.uk (Antoine Martin) Date: Tue, 18 Oct 2011 16:49:48 +0700 Subject: [winswitch] [ANNOUNCE] xpra 0.0.7.28 Message-ID: <4E9D4BBC.9090401@nagafix.co.uk> Hi, Xpra version 0.0.7.28 is now available, in source form here: http://xpra.org/src/ Or as binary packages here: http://winswitch.org/downloads/ This is a major update adding a number of significant enhancements: * much more efficient and backwards compatible network code, prevents a CPU bottleneck on the client * forwarding of system notifications, system bell and custom cursors * system tray menu to make it easier to change settings and disconnect * automatically resize Xdummy to match the client's screen size whenever it changes * PNG image compression support * JPEG and PNG compression are now optional, only available if the Python Imaging Library is installed * scale window icons before sending if they are too big * fixed keyboard mapping for OSX and MS Windows clients * compensate for line jitter causing keys to repeat * fixed cython warnings, unused variables, etc Since I failed to post announcements for the previous releases of Xpra (they were kind of bundled and implied in the winswitch announcements), here is a copy of the release notes for the past few releases: v0.0.7.27 (2011-09-20) * compatibility fix for python 2.4 (remove "with" statement) * slow down updates from windows that refresh continuously v0.0.7.26 (2011-09-20) * minor changes to support the Android client (work in progress) * allow keyboard shortcuts to be specified, default is meta+shift+F4 to quit (disconnects client) * clear modifiers when applying new keymaps to prevent timeouts * reduce context switching in the network read loop code * try harder to close connections cleanly * removed some unused code, fixed some old test code v0.0.7.25 (2011-08-31) * Proper keymap and modifiers support v0.0.7.24 (2011-08-15) * Use raw keycodes whenever possible, should fix keymapping issues for all Unix-like clients * Keyboard fixes for AltGr and special keys for non Unix-like clients v0.0.7.23-2 (2011-07-27) * More keymap fixes.. v0.0.7.23 (2011-07-20) * Try to use setxkbmap before xkbcomp to setup the matching keyboard layout * Handle keyval level (shifted keys) explicitly, should fix missing key mappings * More generic option for setting window titles * Exit if the server dies v0.0.7.22 (2011-06-02) * minor fixes: jpeg, man page, etc (...) Cheers Antoine From antoine at nagafix.co.uk Tue Oct 18 10:52:31 2011 From: antoine at nagafix.co.uk (Antoine Martin) Date: Tue, 18 Oct 2011 16:52:31 +0700 Subject: [winswitch] [ANNOUNCE] version 0.12.6 Message-ID: <4E9D4C5F.5030600@nagafix.co.uk> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi, Version 0.12.6 is now available: http://winswitch.org/downloads/ This version only contains a small number of changes and bugfixes: * support for ssh agent * display server fingerprint as a picture using Vash (if Java is installed) * support for Xpra-Xdummy combination, patched X11 server packages are available * support for latest xpra 0.0.7.28 and its new options (system tray icon, etc) * turn off xpra compression over fast links * reduce lag of GStreamer display shadowing over fast links Cheers Antoine -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk6dTF8ACgkQGK2zHPGK1rvhsgCfYoK83pWTkdaLnezwEAVTxFKF 9+QAn1IW/GKJo1IjXoJXnaL1csfyRS9X =gSaD -----END PGP SIGNATURE----- From erappleman at gmail.com Wed Oct 19 06:55:08 2011 From: erappleman at gmail.com (Eric Appleman) Date: Wed, 19 Oct 2011 01:55:08 -0400 Subject: [winswitch] [ANNOUNCE] xpra 0.0.7.28 In-Reply-To: <4E9D4BBC.9090401@nagafix.co.uk> References: <4E9D4BBC.9090401@nagafix.co.uk> Message-ID: <4E9E663C.4070600@gmail.com> Great job on the release. My only problem is that the tray icon is a bit finicky. Sometimes it'll flicker and only work if I use my arrow keys of hold down my click. It's also not very obvious when settings take effect. I am also still curious about a direct shared memory method for communication between real X servers. Something like Xen's VGA passthrough but without the network or virtualization infrastructure. - Eric On 10/18/2011 05:49 AM, Antoine Martin wrote: > Hi, > > Xpra version 0.0.7.28 is now available, in source form here: > http://xpra.org/src/ > Or as binary packages here: > http://winswitch.org/downloads/ > > This is a major update adding a number of significant enhancements: > * much more efficient and backwards compatible network code, prevents a > CPU bottleneck on the client > * forwarding of system notifications, system bell and custom cursors > * system tray menu to make it easier to change settings and disconnect > * automatically resize Xdummy to match the client's screen size whenever > it changes > * PNG image compression support > * JPEG and PNG compression are now optional, only available if the > Python Imaging Library is installed > * scale window icons before sending if they are too big > * fixed keyboard mapping for OSX and MS Windows clients > * compensate for line jitter causing keys to repeat > * fixed cython warnings, unused variables, etc > > Since I failed to post announcements for the previous releases of Xpra > (they were kind of bundled and implied in the winswitch announcements), > here is a copy of the release notes for the past few releases: > > v0.0.7.27 (2011-09-20) > * compatibility fix for python 2.4 (remove "with" statement) > * slow down updates from windows that refresh continuously > v0.0.7.26 (2011-09-20) > * minor changes to support the Android client (work in progress) > * allow keyboard shortcuts to be specified, default is meta+shift+F4 to > quit (disconnects client) > * clear modifiers when applying new keymaps to prevent timeouts > * reduce context switching in the network read loop code > * try harder to close connections cleanly > * removed some unused code, fixed some old test code > v0.0.7.25 (2011-08-31) > * Proper keymap and modifiers support > v0.0.7.24 (2011-08-15) > * Use raw keycodes whenever possible, should fix keymapping issues for > all Unix-like clients > * Keyboard fixes for AltGr and special keys for non Unix-like clients > v0.0.7.23-2 (2011-07-27) > * More keymap fixes.. > v0.0.7.23 (2011-07-20) > * Try to use setxkbmap before xkbcomp to setup the matching keyboard layout > * Handle keyval level (shifted keys) explicitly, should fix missing key > mappings > * More generic option for setting window titles > * Exit if the server dies > v0.0.7.22 (2011-06-02) > * minor fixes: jpeg, man page, etc > (...) > > Cheers > Antoine > _______________________________________________ > shifter-users mailing list > shifter-users at lists.devloop.org.uk > http://lists.devloop.org.uk/mailman/listinfo/shifter-users From antoine at nagafix.co.uk Tue Oct 25 21:06:33 2011 From: antoine at nagafix.co.uk (Antoine Martin) Date: Wed, 26 Oct 2011 03:06:33 +0700 Subject: [winswitch] [ANNOUNCE] xpra 0.0.7.29 Message-ID: <4EA716C9.2090600@nagafix.co.uk> Hi, Due to a serious bug causing connections to drop at random, I am releasing 0.0.7.29 as an emergency fix. As usual, the source can be found here: http://xpra.org/src/ And the binaries here: http://winswitch.org/downloads/ Apart from the aforementioned bug, there are a few relatively minor items also included in this release: * clipboard support on MS Windows * support ubuntu's appindicator (yet another system tray implementation) * improve disconnection diagnostic messages * scale cursor down to the client's default size * better handling of right click on system tray icon * posix: detect when there is no DISPLAY and error out * remove harmless warnings about missing properties on startup Since winswitch binaries include xpra on MS Windows and OS X, they have been re-generated. (the OS X versions also include the latest pycrypto 2.4) Cheers Antoine From antoine at nagafix.co.uk Sat Oct 29 09:41:43 2011 From: antoine at nagafix.co.uk (Antoine Martin) Date: Sat, 29 Oct 2011 15:41:43 +0700 Subject: [winswitch] Using Xpra on multi-GPU laptops In-Reply-To: <4E8F5D61.4090804@gmail.com> References: <4E8A8776.20208@gmail.com> <4E8B1ED4.6000701@nagafix.co.uk> <4E8B5553.4060601@gmail.com> <4E8BF24F.70404@nagafix.co.uk> <4E8BFFDF.8090304@gmail.com> <4E8C03DC.5080505@nagafix.co.uk> <4E8C5805.7050502@gmail.com> <4E8C6B28.80404@nagafix.co.uk> <4E8F5D61.4090804@gmail.com> Message-ID: <4EABBC47.2010808@nagafix.co.uk> On 10/08/2011 03:13 AM, Eric Appleman wrote: > I'm somewhat comfortable with my Python and would like examine the > windowing code for the Xpra client. > > Is client.py the right file to examine? I'd like to get a sense of what > libraries you guys are using and how they are used. Yes, the client code is pretty much limited to client.py and some platform code (in xpra/xposix/ for Linux) It should be safe to ignore the bencoder and most of protocol.py The rest, and there is quite a lot there, is plain gtk/gdk. You may want to try svn r260 or later as I have just fixed a screen corruption bug. glxspheres now runs quite smoothly here. Antoine PS: Sorry for the slow reply, looks like I missed this message. > - Eric From erappleman at gmail.com Sat Oct 29 11:09:26 2011 From: erappleman at gmail.com (Eric Appleman) Date: Sat, 29 Oct 2011 06:09:26 -0400 Subject: [winswitch] Using Xpra on multi-GPU laptops In-Reply-To: <4EABBC47.2010808@nagafix.co.uk> References: <4E8A8776.20208@gmail.com> <4E8B1ED4.6000701@nagafix.co.uk> <4E8B5553.4060601@gmail.com> <4E8BF24F.70404@nagafix.co.uk> <4E8BFFDF.8090304@gmail.com> <4E8C03DC.5080505@nagafix.co.uk> <4E8C5805.7050502@gmail.com> <4E8C6B28.80404@nagafix.co.uk> <4E8F5D61.4090804@gmail.com> <4EABBC47.2010808@nagafix.co.uk> Message-ID: <4EABD0D6.8030206@gmail.com> I just tried the new commits and it doesn't solve the screen update issue. I'm also having problems using xpra+ssh normally on machines within my WLAN. The local hostnames aren't recognized. - Eric