Possible solutions
As Direct3D 10 is only
a software system intended to control specific classes of hardware there is no technical reason preventing an implementation on OSes other than Windows Vista. On the following pages we
will analyze some different approaches to getting Direct3D 10 applications running on
Windows XP. We will explore which participants are needed to get them running and how
much work is required. Additionally, we will take a look at the
compatibility of these various solutions.
Back porting Direct3D
10 to Windows XP
As Microsoft owns both Windows XP and Vista, many people believe it should be relatively easy for them to take the necessary parts of
Direct3D 10 and deliver them to Windows XP with a redistribution package or a service
pack, as has been done with various DirectX versions in the past. However, for these previous
versions such a process was relatively simple because the packages contained only a new runtime that worked with the same driver model as the previous versions they were replacing. As the Direct3D versions in these
packages were able to work with older drivers too (Direct3D 9 requires only a
Direct3D 7 driver to work) there was no need to update the driver at
the same time. As the Direct3D 10 runtime requires the new driver model, a
simple redistribution would not work. A service pack that updates the kernel would be required.
In addition to the considerable work that would be needed to bring the Vista graphic
kernel subsystem into the Windows XP kernel, there is another aspect that needs to
be considered. Updating a main
component in an operating system that is over five years old could easily break compatibility
with some existing applications. Customers would not be pleased if this happened. This
is especially true for those who don’t own Direct3D 10 hardware at all. This makes a full back port by Microsoft technically possible but very expensive and somewhat
risky.
Adding Direct3D 10 commands to the
Windows 2000/XP driver model
Since a full back port of D3D 10 as it currently exists in Vista is risky, then what about the possibility of adding D3D 10 command compatibility to XP without updating the kernel? The old driver model
for Direct3D was built in such a way as to allow supporting multiple Direct3D
versions with a single driver. A typical driver for Direct3D 9 qualified
hardware can handle commands from previous Direct3D versions too. Such
flexibility should make it easy to simply add a bunch of new commands for
Direct3D 10 to this model.
But such an approach would only be the first step.
Microsoft would also have to update their current Direct3D runtime to accept this second
alternative, and the IHVs would have to add support for all these new commands to their Windows XP drivers. If we look at the current state
of Direct3D 10 drivers, it becomes readily apparent that adding the requirement to write a second one for Windows XP
would probably not improve the situation. Another problem with such an approach
is the old driver model itself. It would
cause such a XP Direct3D 10 to behave somewhat differently than the original version on
Windows Vista. Additionally, writing a Direct3D 10 driver for such a design would
be more work because services like the virtual video memory manager are not
available on Windows XP and would need to be implemented in the driver itself.
Therefore the work for the driver teams increases even more. Also, presumably the original goal of reducing API overhead would be lost in such an approach, causing Direct3D 10 performance on Windows XP to be significantly worse than Direct3D 10 performance on Vista.
Using the Win2K/XP OpenGL driver model to add Direct3D 10
Unlike the Windows 9x line of operating systems, Windows NT-based OSes contain official support for OpenGL. The ICDs that contain much of the driver code for this always run in the user space, just like Direct3D drivers on Vista. As communication between the user mode and kernel mode is not based on a Microsoft-defined protocol, it was always possible for an OpenGL driver to support additional features of the hardware that are not part of the Direct3D specification. Therefore an OpenGL driver is able to use the Direct3D 10-specific functions of a GPU even on Windows XP. Taking all this together it would be possible for Microsoft to use nearly the same Direct3D 10 runtime to talk to a Windows XP user mode driver. Such a driver would be similar to the Vista version but would need to talk over the same channels that are used by OpenGL ICDs on XP instead of the new ones that are only available on Vista. But like the previous solution, this one would require the IHVs' driver teams to implement all the relevant services of the Windows Vista graphics kernel subsystem in their own drivers.
