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