Re: [Xen-devel] virtualGraphicCards

[Mark Williamson <mark.williamson@xxxxxxxxxxxx>]

> >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 
environment.

Cheers,
Mark

> 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
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel