Hi there,

our group is working on a open source solution for a virtualized high speed 
glaphics
driver. Gallium3D seems to offer a very smart platform to start from and could 
allow
us to constantly update the virtual driver with "physical" support for the 
latest GPUs.

>From a high level view our concept may look promising, but there is a number 
>of open
questions about Gallium3D internals we can not answer.

Maybe someone with deeper knowledge of the Gallium concept and implementation
can help us on this topic.


> Carsten Weinhold wrote:
> as we discussed on the phone recently, I wanted to compile a list of questions
> that we can ask the Gallium developers. See below.


Context
-------

We want to use Gallium to virtualize a graphics card such that it can be
shared among multiple concurrently running virtual machines (VMs). We plan to
move the Gallium pipe driver into the hypervisor layer with a very simple
state tracker managing GPU command streams coming from multiple VMs running
on top of it. This simple VM state tracker is only responsible for allowing
concurrent access of multiple 'real' state tracker instances in the VMs
(e.g., DirectX/OpenGL in Windows/Linux VMs, respectively). Those 'real' state
trackers talk to the Gallium pipe driver running on top of the hypervisor
using some kind of passthrough pipe driver (mainly an API wrapper running
locally in their VMs). The winsys layer is supposed to be virtualized in a
similar way.

a rough illustration of the concept:
http://wweidner.cycas.org/virtual_driver_concept.pdf


Open questions:
---------------

1) Can the concept of contexts already provided by the Gallium pipe driver API
be used to isolate rendering contexts of multiple VMs? That is, can two VMs
each have a number of contexts that are effectively provided and maintained
by the Gallium pipe driver running on top of the hypervisor?

2) What kind of isolation do the contexts provide? Is it possible for client
VM A to mess with contexts/surfaces belonging to VM B? This scenario is
actually not much different from multiple applications running in the same
OS, I guess. The real question here is, whether the driver can enforce
resource isolation or is this the sole responsibility of the state tracker
running on top of it. If it is the job of the state tracker, is it feasible
to enforce isolation in the simple VM state tracker, which we want to receive
lowlevel pipe driver requests only?

3) The winsys API is used to allocate and free surfaces. Does winsys only
operate on physical video memory or is it able to 'virtualize' video memory
and swap surfaces from/to system memory transparently?

4) Recently, GPU vendors introduced parallel GPU rendering contexts and video
memory virtualization (Intel X3000: MI_SET_CONTEXT instruction, AMD RV670).
The prototype driver for the i915 chip probably cannot support this, but does
Gallium in general allow for this kind of hardware support or is it planned
to suuport it?


Best Regards,
Wolfgang Weidner
HP Laboratories Bristol -UK

OpenTC - Open trusted computing
www.opentc.net

-------------------------------------------------------------------------
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services for
just about anything Open Source.
http://sourceforge.net/services/buy/index.php
--
_______________________________________________
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel

Reply via email to