[winswitch] Using Xpra on multi-GPU laptops
erappleman at gmail.com
Tue Oct 4 19:49:55 BST 2011
* 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.
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 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?
>> - Eric
>> 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
> shifter-users mailing list
> shifter-users at lists.devloop.org.uk
More information about the shifter-users