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 
> 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 
Also, spice doesn't let the guest touch the framebuffer, unless it explicitly
asks for it (printscreen). So most of the time the 2d operations (like you
said, they are basically the gdi lexicon) are passed to the server and from it
to the client, which actually performs them. If you do a printscreen the server
also has to perform them to provide the updated framebuffer to the guest. The
guest however doesn't write to the framebuffers.

> doesn't count), or for doing 3D.
> 
> - 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
>