> The idea of full-speed graphics on a guest system sure is nice, but there
> are some
> really tough issues here. First off, its really important to understand that
> there
> is no such thing as an SVGA standard. SVGA is anything which supports VGA
> fully and
> offers extensions - typically 2D and 3D accelerations and higher modes and
> deeper
> colour depths than VGA supports. Everyone makes up their own interface.
> To make sure this important point is understood, there IS a VGA standard -
> the IO
> registers and memory locations used are fixed, as is the meaning of all the
> possible
> commands. This means that VGA code that works on one adapter will work on
> all (S)VGA
> adapters. On an SVGA card, just to switch modes, you may have to set a pixel
> clock,
> horizontal blanking timing, the line pixel width, the horizontal and
> vertical blanking
> interval timings, the number of scan lines per frame (including those in the
> VBI) and
> possibly more esoteric values. The registers to do this may be memory
> mapped, I/O mapped (unlikely, but not unknown), directly or indirectly
> addressed, DMA accessible and read/write or write only or one of many
> combinations of the above. Their
> location is defined by the manufacturer, not by a standard. The same applies
> to 2D
> (Blt) engines, 3D-renderers (for instance, most 3D engines render triangles,
> but at
> least card type one only renders Quads, and to draw a triangle, you have to
> draw a
> Quad with one side length 0). The locations, readability and access methods
> for the
> controlling registers are all manufacturer specific.
> To let the graphics simply rip when full screen, you have to be able to
> capture the
> current state of the adapter, so that you can restore it when you switch out
> of
> full-screen (bear in mind that Windows and X can both change the display
> mode on the
> fly). The state can include bitmaps and fonts mapped into offscreen memory.
> It can
> also include vertex registers and other state registers that are not
> necessarily
> visible, so have to be recorded as they are written. All this adds up to an
> driver-
> like piece of software for each supported adapter, requiring intimate
> knowledge of
> each adapter - yuck!
Yes, I know there's no such thing as SVGA standard.. But, to make the
saving/restoring of the state of the video hardware to work properly
we don't need a "full-blown" video driver. Sure, saving/restoring of
the state is a typical part of driver, but it has to implement a lot
more of drawing and rendering related fuctions which we don't need to
implement because guest will be accessing this particular SVGA
directly and exclusively in full-screen mode, using his, guests native
driver. Also, is it possible to use the existing host OS's video
driver for purpose of saving/restoring the state not having to
duplicate this function?
> I don't know the best solution, but some randoms thoughts that I have had
> include:
> 1) Dual head. Have two adapters, one controlled by the host OS and one by
> the guest
> OS. Requires two adapters, two monitors and probably spoofing code to hide
> the other
> adapter. For the host, what this means will probably depend on the OS. For
> the Guest,
> it would mean Plex86 monitoring PCI/AGP bus accesses and lying to the
> requestor when
> it tries to find the adapter. Not desirable in all situations, but I can
> imagine
> some power users would like it. It would also be comparitively fast to
> implement.
Sounds like really cool idea, though you're right that it's not for
everyone.
> 2) Create a standard psuedo-device for each Guest OS, then punt the actual
> drawing to
> the Host. For windows this would mean creating a DirectX to Host 3D - OGL,
> usually -
> (something I personally guarantee Microsoft will not like) translation. Of
> course,
> this would go out of date quite regularly, but DirectX support legacy
> drivers quite
> well. This psuedo-device would be installed like a real device, perhaps
> spoofing the
> PCI reads to give the impression of a device by setting the Manufacturer and
> Device
> IDs to our choice. This is non-trivial (!) but could be reasonably fast
> (even in
> windowed mode) with accelerated X/OGL as in XFree86 4.0.
This surely will be required for windowed guests, or to use Jeffrey B.
Siegal's idea, which also sounds great! I personally can't choose
which idea is better!
> That's all for now, I'll post further ideas as they emerge.
If you have such experience with writing system level video code I
hope you can contribute to the project (I am not experienced beyond
old VGA and currently don't have enough free time).
Uhus
