Re: [Xen-users] Xen handling of graphics card

[Anthony Liguori <aliguori@xxxxxxxxxx>]

Petersson, Mats wrote:

> There's two distinct possibilities for graphics improvement using the
> VNC model:
>
>  
<snip>

> 2. A more intelligent and modern form of graphics commands.
QEMU currently does not utilitize any of the cirrus 2d graphics 
acceleration operations for VNC.  This could be a pretty big performance 
improvement for VNC since cirrus supports blt operations (VNC CopyRect) 
and fill operations (various subtypes of hextile, tight, or zrle 
encodings).  CopyRect has a pretty noticable performance improvement 
since window dragging becomes noticably better.
The biggest performance enhancement for VNC (IMO) is cursor offloading 
and unfortunately, cirrus doesn't help us much here.  It only provides 
acceleration for a black/white cursor of a finite size.
Upgrading the VGA driver to a newer chipset might help here except that 
that's probably an awful lot of work.
> A non-VNC model:
> You could also, conceivably, have a situation where the graphics
> controller is directly handled by either Dom0 or the Guest, using a
> "para-virtualized" driver, where the driver is Xen-aware, and has some
> sort of "agreement" of how to share the hardware.
http://wiki.xensource.com/xenwiki/VirtualFramebuffer

I currently only have a Linux domU driver (no Windows support).  I don't 
know much at all about Windows but a Windows driver shouldn't be that 
much more difficult than the Linux one was.
The Linux paravirtualization side is pretty interesting here.  
Currently, I'm able to use the X fbdev driver.  I have some local 
(hacky) patches that add a ARGB cursor to the fbdev driver which would 
solve the VNC cursor problem pretty well (at least for Linux).
I'm still working on integrating a write-trapping update idea from Gerd 
Knorr although a patch should show up very soon that includes that.
Regards,

Anthony Liguoir

> This would require a
> hypervisor level locking/sharing mechanism so that the driver of one
> guest can do the necessary hardware access without being "disturbed" by
> some other guest trying to access some shared resource. 
>
> This is however, a BIG job, even for a pretty simple graphics card,
> there'd need to be quite a lot of work. For COMPLEX graphics cards, the
> driver is HUGE, and although the actual accesses to the hardware are
> probably few and pretty centralized, the work to understand the driver,
> modify it in a safe way, and getting it to work reliably (and
> effectively) across multiple OS architectures is not easy. 
>
> --
> Mats
>
>
>
>
>
>
>
> _______________________________________________
> Xen-users mailing list
> Xen-users@xxxxxxxxxxxxxxxxxxx
> http://lists.xensource.com/xen-users
>
>  

_______________________________________________
Xen-users mailing list
Xen-users@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-users