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 >
