WARNING - OLD ARCHIVES

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/
   
 
 
Xen 
 
Home Products Support Community News
 
   
 

xen-devel

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

To: Jacob Gorm Hansen <jacobg@xxxxxxx>
Subject: Re: [Xen-devel] [RFC] Xen Virtual Framebuffer
From: Jon Smirl <jonsmirl@xxxxxxxxx>
Date: Mon, 19 Dec 2005 10:01:55 -0500
Cc: xen-devel@xxxxxxxxxxxxxxxxxxx
Delivery-date: Mon, 19 Dec 2005 15:04:37 +0000
Domainkey-signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=DefkJ4DBHnhqvR4N3J1z2Ppf72mefuHzw4UPIcwqU/ytArztq8NPuU4J9psP+84YwLtgwrVIAr9rZqTgvgXm0VSEJfP6lZQOQsyMqizjC/nFOM0NbNFxdu4/M5nZJw7FXg8n8AQFnE11XNzTrsXjsJjOiZwyxi90YGgAr1ftzd4=
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <e08041f30512190232p19fe98b8yd8a037db6596bd@xxxxxxxxxxxxxx>
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: <4394C683.1070000@xxxxxxxxxx> <4394D888.3080200@xxxxxxxxxx> <9e4733910512051635j9df6469g44aeb3e379d25430@xxxxxxxxxxxxxx> <4399FD03.8080405@xxxxxxxxxxxxxxxxxxxxx> <9e4733910512101827s3fc14bdfhad3e8d4c587c5a67@xxxxxxxxxxxxxx> <e08041f30512160414o10f409ay14611575106c325@xxxxxxxxxxxxxx> <9e4733910512160748ud07db3ficb5cba7675856028@xxxxxxxxxxxxxx> <e08041f30512190232p19fe98b8yd8a037db6596bd@xxxxxxxxxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
On 12/19/05, Jacob Gorm Hansen <jacobg@xxxxxxx> wrote:
> 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).

Are you aware of the EGL API proposal?
http://www.freedesktop.org/wiki/EGL

There has also been a lot of discussion around writing an new display
server centered around OpenGL instead of X.  It is discussed at the
bottom of this article:
http://www.freedesktop.org/~jonsmirl/graphics.html

A standalone X server could still use the GLX protocol. If you look at
the mesa source code you will find that it is all automatically
generated. It is certainly possible to build a new OpenGL only server
that reuses the GLX code.

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

X uses the same base protocol on the wire as local. But the protocol
can be extended and parts of it overridden, for example the shared
memory extension is used to avoid the texture copies.

The advantage to this scheme is that any pair of machines can always
communicate using the base protocol. It the client/server are both
local they will be able to negotiate the shared memory extension and
upgrade their communications.

>
> Jacob
>


--
Jon Smirl
jonsmirl@xxxxxxxxx

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