> > I just read through parts of the mailing list archive, the parts dealing
> > with graphics in particular since I'm interested in that kind of stuff.
> > I've seen a couple of ideas tossed around and I wanted to comment on
some
> > of them:
> >
> > * Dual head
> > Personally I think the dual head idea is quite cool. On the other hand,
> > it might be very hard to get working in the real world since most modern
> > graphics card use both interrupts and direct memory access regularly.
> > I don't think it would be trivial to virtualize DMA on a PC...
> > (If you really want to virtualize DMA you should probably take a look
> > at the GART though.) I've heard that Matrox uses DMA to transfer
> > 2d-commands to their cards in Windows. I don't know about any other
> > manufacturers but it wouldn't surprise me much if they use DMA for 2d as
> > well. 3d is another matter, I think all modern cards use DMA in that
case.
> >
Yes, it is a bit more complicated than it first looked, but I don't think
its too bad. The biggest challange is finding the time to actually work on
it! :-( (Still have a firewall to create, configure and wire in for the
wife). Matrox shouldn't be too dificult, if we stick to PCI first. The Gx00
series use bus-mastered DMA, driven from the card, so all we have to arrange
is that the source memory is locked down and contiguous, and the guest can
get the actual physical address. Not trivial, but not too difficult. GART is
an AGP issue, so a PCI card would skirt the issue. If you double-head one of
the cards has to be PCI, so this isn't that big a restriction. Another issue
is mapping PCI memory and I/O correctly. This may be a little tricky, as we
have to coordinate two OSes that weren't written with any knowledge of each
other. Should be fun to try, though. If nothing else, we can re-map the host
if the guest chooses a conflicting address space.
> > There is one exception to this though, the Voodoo1 and Voodoo2. They
don't
> > use DMA and they don't use interrupts as far as I know. It is just one
> > big memory region that you can map into your virtual memory.
> > I think this would be a very nice option to have and I don't think it
would
> > be very difficult to implement. You would have to live with the fact
that
> > users having direct access to the card could crash the machine though.
> > You would also have to make sure that you don't try to run two
applications
> > accessing the vodoo card directly simultaneously :)
> >
Only one OS could access a card at a time. We could control this via the PCI
spoofing, causing Plex86 to abort if the required resources were already in
use, or we could just trust the user (Trust the user? Sucker...)
> > * Emulating an entire card.
> > This could very well be doable for some older cards that don't have any
> > acceleration. Emulating a newer card is also certainly possible, but I
don't
> > think it is a good starting point due to the complexity.
> > One point that haven't been raised before is the legal one. I think you
> > would risk upsetting the legal division of a manufacturer if you
implement
> > an emulation of their cards...
> >
I have to admit that I have a gut-level bad feel about this option. Its
inelligant, inefficient and using someone else's driver without using their
hardware is more than a little dubious in my view (I write device drivers
for a living, mind). There is also the legal issue. Still, it is an option
that should be considered. On older cards, the manufacturer may simply not
care anymore.
> > * VESA emulation
> > This is probably a quite good idea if you want to have more advanced
> > graphics while running Linux inside plex86. (Think vesafb.)
> > Not sure about other OSs though. Anyone know wether there is a VESA
display
> > driver for Windows/FreeBSD/BeOS/etc?
> >
Not my area, no comment.
> > * Making a native driver of some sort.
> > This would probably be the best solution if you could find people
willing to
> > write it on all or most of the operating system you would like to run
through
> > plex86. People have talked about ways of transferring commands from
> > the hosted OS to the host. One way that hasn't been brought up is the
GLX
> > protocol. It could only send OpenGL commands of course, but it might be
> > almost ideal if you want OpenGL support on the hosted OS.
> > Another way would be to port the DRI drivers to the hosted operating
> > system and allow them to access the kernel module you are already using.
> > You would have to do some serious hacking for this to happen though.
This
> > would probably be the fastest solution though.
Ideally, we would have a solution everywhere, but let's face it, windows is
the real problem. Most everywhere else will be X/OpenGL or something similar
based and the drivers should be pretty similar. The real performance issue
is probably Windows games, so we only really need to do real meaty work
three times (Win9x, Win2k - can't run games on earlier NT versions - and
everything else. Note that NT and 9x have different Display Driver Models
that don't have a lot in common).
> >
> >
> >
> > regards
> > Andreas Ehliar
Thanks for the input, it gave another useful perspective on the issue.
Cheers, Colin
