Re: [Qemu-devel] GSoC 2011: S3 Trio, AHCI

[Alon Levy <alevy@redhat.com>]

On Wed, Apr 06, 2011 at 11:54:47PM +0100, Paul Brook wrote:
> > > Last year, I was also interested in working on S3 Trio emulation. This
> > > year, the same idea is on the ideas list. The hardware is pretty
> > > thoroughly documented through source code and textual documentation, and
> > > I'm already familiar with adding PCI devices to Qemu, so I do see a
> > > rough outline of how I would implement it.
> > > 
> > > However, last year, Paul Brook commented [1] that he wasn't convinced
> > > about the usefulness of emulating an S3 Trio or Virge card, because of
> > > performance reasons. He suggested that accelerating the 2D engine would
> > > be tricky because the framebuffer is exposed to the guest. This might be
> > > just me not fully understanding his point, but isn't this also the case
> > > with the Cirrus Logic GD5446 card?
> > > 
> > > He also suggested paravirtualization for 3D acceleration. Do you think
> > > it would make a good summer project?
> > 
> > I can't comment on these issues, CC'ing Paul, Anthony and Stefan.
> 
> My understanding is that Cirrus logic cards also have 2D acceleration.  We 
> implement this in qemu, but not in a way that's likely to be fast.  I don't 
> really know either card in detail, but they're both a similar age, so I'd 
> expect the functionality to be fairly similar.
> 
> The 2D engines you're talking about are of questionable benefit.  IIUC They're 
> basically a memcpy engine with some weird bitmasking operations that line up 
> with the windows 3 GDI raster ops.  While accelerating this maybe made sense 
> on a 386, it's not worth the effort on modern CPUs.  The latency and overhead 
> of setting up and syncronising with the async blit engine is greater than the 
> cost of just doing it in software.  In practice modern desktop environments 
> just use the 3D engine.
> 
> IMO emulating useful 'real' 3D hardware is not feasible.  In theory you could 
> emulate an old card, however these are also of limited practical benefit.  For 
> the S3 cards the 3D engine is so crippled that even when new it wasn't worth 
> using.  You could maybe implement an old fixed-function card like, e.g. an 
> i810 or 3dfx card, however drivers for these are also getting hard to come by, 
> and the functionality is still limited.  You basically get raster offloading, 
> and everything else is done in software.  Emulation overhead may be greater 
> than useful offloaded work.
> 
> For good 3D support you're looking at something shader based.  Emulating real 
> hardware is not going to happen.  With real hardware the interface qemu needs 
> to emulate is directly tied to the implementation details of that particular 
> chipset.  The guest driver generally uses intimate knowledge of these 
> implementation details (e.g. vram layout, shader ISA).  Different 
> implementations may provide the same high-level functionality, however the 
> low-level implementations are very different.  Reconstructing high-level 
> operations from the low-level stream is extremely hard, probably harder than 
> the main CPU emulation that qemu does.
> 
> IMO a good rule of thumb is that the output of the render pipeline should not 
> be guest visible.  Anything where the guest can observe/manipulate the output 
> or intermediate results makes it very hard to isolate the guest from the 
> implementation details (i.e. whatever hardware acceleration the host 
> provides).
> 
> There are already a handful of different paravirtual graphics drivers, of 
> varying quality and openness.  This includes:
> 
> - Several OpenGL passthrough drivers.  These are effectively just re-
> implementing GLX, often badly.  I suspect that given a decent virtual network, 
> remote X (including 3D via GLX) already works pretty well.
> 
> - SPICE. IIUC this is an ugly hack that maps directly onto legacy Windows/GDI 
Hey, take that back! ;) except for the ugly and hack parts, yes. Also has grown
surfaces support to map better to how X works.
> operations.  I'm not aware of any substantive plan for making this work well 
> in other environments (using the subset that's basically a dumb framebuffer 
> doesn't count), or for doing 3D.
We are planning 3D support, based on shaders (basically, vgallium), feature
page is http://spice-space.org/page/Features/Spice3D

> 
> - Whatever VMware uses.
> 
> - Whatever VirtualBox uses.
> 
> - At least two gallium3D based projects.  I think this includes Xen, and 
> possibly VirtualBox.  Given the whole point of Gallium3D is to provide a 
> common abstraction layer between the application API and the hardware this 
> would be my choice.
> 
> Paul
>