[winswitch] Using Xpra on multi-GPU laptops

[Eric Appleman]

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