Re: [Xen-devel] [RFC] Xen Virtual Framebuffer

[Jacob Gorm Hansen <jacobg@xxxxxxx>]

On 12/16/05, Jon Smirl <jonsmirl@xxxxxxxxx> wrote:
> On 12/16/05, Jacob Gorm Hansen <jacobg@xxxxxxx> wrote:
> > On 12/11/05, Jon Smirl <jonsmirl@xxxxxxxxx> wrote:
> >
> > > You don't have to run the X server in dom0. You can run it in any
> > > domain that has sole control of the graphics hardware.  The core
> > > problem is that only one domain can have control of the video
> > > hardware, there is no realistic way to virtualize a 3D engine.
> >
> > Even if it is impossible, I am currently attempting to do just that.
> > At http://www.diku.dk/~jacobg/gfx you can see a screen shot of 3 Xen
> > VM's displaying hardware-accelerated OpenGL to a shared server in
> > dom0.
>
> You can virtualize a single vendor's card. You can't really virtualize
> 3D in general because the cards are so different, there is no common
> 3D interface to virtualize. If you are going to design a common
> virtual 3D interface you might as well use the exiting OpenGL/GLX
> protocol rather than design something new. You'll find that GLX is
> more communications efficient than virtualizing at the low level.

My software so far runs on top of pure OpenGL, though this far I have
only gotten the ATI drivers running under Xen (mostly a case of
changing virt_to_phys() into virt_to_bus() a few random places in the
open source wrapper).

Though I was inspired by GLX I have opted not to base my work on it,
because I would prefer not to rely on anything X11-related, and
because it is a wire protocol which seems inefficient compared to a
shared memory protocol, especially when sending large objects such as
textures.

Jacob

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