Mir on vmwgfx

[Jakob Bornecrantz]

----- Original Message -----
> On Tue, Nov 05, 2013 at 08:22:28AM +0100, Thomas Hellstrom wrote:
> > Hi!
> >
> > I'm new to this list and I'm trying to get Mir running in a VMware
> > virtual machine on top of the vmwgfx driver stack.
> > The idea is to first get "mir_demo_server_basic" running with demo
> > clients and then move on to Xmir, patching up our drivers as
> > necessary.

Also new to this list, I work with Thomas but the mail address probably
made obvious.

> 
> Hi Thomas, thanks for looking into this. Feel free to also join
> #ubuntu-mir on freenode if you need more direct information.

I'm on there, nick Prf_Jakob[1].

[SNIP]

> 
> Note that the Mesa codebase we are using has some changes in the GBM code
> (experimental, not upstream yet). Notably:
>   * we allow creation of "dumb" drm buffers of arbitrary size (not just
>     64x64) when using GBM_BO_USE_WRITE

There is no technical limit on this.

>   * gbm buffers backed by a "dumb" DRM buffer also get a DRIimage

This will be a problem, at least to my knowledge DRIimages are backed
by a gallium resource/texture, in SVGA this is backed by a surface,
while dumb drm buffers would be backed by a dma-buffer (I think as
of right now vmwgfx does not support the dumb interface).

Taking a step back here, SVGA have two types of resources: a surface
which is in simplified terms a opaque handle to a GL texture on the
host side, which can not be mapped; and dma-buffers which are regions
of memory both the guest and the host and used for transferring data
to and from surfaces.

> 
> We have found that the major hardware drivers support these changes.
> Do they pose a problem for the VMware driver?

See above, and adding too that, if you are doing software a approach we
would like the storage to be a dma-buffer and not to be backed by a surface
(to avoid unnecessary data transfers and resource overhead). On the other
hand the way that the current vmwgfx xorg driver works is that it tries to
keep everything in software until the moment that the compositor asks for
the data and then transfers it to the host so the compositor can use 3D.
Basically per window shadowfb (for those familiar with X), finding a way
for mir to work like this (on vmwgfx) would be the best for us.

> 
> See http://github.com/RAOF/mesa/ for the changed code base. It's still
> based on the Mesa version shipped in Ubuntu 13.10, but we plan to rebase
> on a more recent version.

Cheers, Jakob.

[1] Not really a professor