> Date: Tue, 31 Oct 2000 13:06:32 +0300 (MSK)
> From: Sintsov Dmitri <[EMAIL PROTECTED]>
> Subject: plex86 video proposal
>
>
> Greetings,
>
>
> Here's my thoughts on the possible way of video implementation in plex86:
>
>
> General idea of plex86 is virtualization, not emulation. Running multiple
> virtual PC's at the same PC hardware. Thus it means to emulate as less of
> CPU as possible to allow virtualization to run at maximum speed. Thus I
> believe it makes sense to use the same approach for virtualization of the
> rest of hardware (because we are virtualizing PC archtecture, not just
> x86).
> Virtual and real hardware matches, so when it's possible to access some
> particular hardware exclusively (eg. video when running full-screen
> guest so no other host tasks accesses it simultaneously), it should be
> possible to allow full-screen guest to access video hardware directly (in
> the similar way windows uses full-screen VGA in VDM's, but extending it to
> SVGA and 2D/3D-specific hardware of modern accelerators). Benefits could
> be the fastest possible video access for guest, including 2d/3d
> acceleration not having to write an additional layer to host os
> drivers (x/ogl/directx etc). However I realize that windowed guest is also
> required, but it doesn't prevent from implementing a faster technique for
> full-screen mode. Another problem I can think of, is that some of modern
> accelerators have a lot of on-board RAM, 64MB could be a lot to
> save/restore when switching from full-screen guest to another task and
> back, however it maybe possible to optimize this code. Also, the question
> is, could the code of initializing/saving/restoring the state of specific
> video chip be obtained freely. Also, SDL is a good approach of portable
> video, however is it worth to write additional layer of 2d/3d
> acceleration, which could cause slow-downs and compatibility problems,
> when the guest hardware matches the host hardware. But I understand that
> for bochs, being a cross-platform using portable library is the only
> possible approach (also probably for windowed guest of plex86).
> Uhus
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!
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.
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.
That's all for now, I'll post further ideas as they emerge.
