This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
Home Products Support Community News


Re: [Xen-devel] virtualGraphicCards

To: Anthony Liguori <aliguori@xxxxxxxxxx>
Subject: Re: [Xen-devel] virtualGraphicCards
From: Mark Williamson <mark.williamson@xxxxxxxxxxxx>
Date: Thu, 8 Sep 2005 01:19:59 +0100
Cc: "Retzki, Sascha \[Xplain\]" <sascha.retzki@xxxxxxxxx>, xen-devel@xxxxxxxxxxxxxxxxxxx, Daniel Hulme <dh286@xxxxxxxxx>
Delivery-date: Thu, 08 Sep 2005 00:18:34 +0000
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <431F5862.30207@xxxxxxxxxx>
List-help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-id: Xen developer discussion <xen-devel.lists.xensource.com>
List-post: <mailto:xen-devel@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
References: <3AF26F5605627543BEC429636A5222900B72C6@xxxxxxxxxxxxxxxxxxxxxxx> <200509071655.02183.mark.williamson@xxxxxxxxxxxx> <431F5862.30207@xxxxxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
User-agent: KMail/1.8
> >I'd be inclined to implement the Xen video device in the guest kernel,
> > then get X to use that (as it can for existing framebuffer drivers).
> The problem with framebuffers is that you lose higher level primatives
> (like blitting, rect fills, moves).  Modern remote display protocols
> (NX, VNC) are optimized to take advantage of these higher level primatives.

Yep, true.  We'd talked about having a "side channel" that could be used to 
relay accelerated operations to speed up blitting, etc.  This could also 
describe what areas of the framebuffer to rescan...

A nice idea might be to have the kernel framebuffer device, which could be 
used successfully by X (and svgalib, framebuffer console, etc) at some 
performance cost.  An optional X11 module would allow X to also use the 
explicit sidechannel in order to get maximum performance.

That said, I think the NX protocol you mentioned is really slick: it uses 
various round trip suppression mechanisms to combat network latency - I 
imagine they'd work to limit the hit from context switching in the Xen 


> The thing that really gets you is that modern environments draw software
> cursors a lot.  Paying a round trip for every cursor movement makes the
> mouse visibly laggy.  Even qemu has this problem (when you export it's
> display over VNC) as the cirrus hardware cursor is not often used (as
> it's only black and white and fixed size).
> I'm becoming fonder of the idea of virtualizing at a much higher level
> (perhaps even at the OpenGL level).  I'm not sure how we bridge this
> effectively to fully virtualized domains either.
> Regards,
> Anthony Liguori
> >Cheers,
> >Mark
> >
> >_______________________________________________
> >Xen-devel mailing list
> >Xen-devel@xxxxxxxxxxxxxxxxxxx
> >http://lists.xensource.com/xen-devel

Xen-devel mailing list

<Prev in Thread] Current Thread [Next in Thread>