Will Direct3D 10 ever come to Windows XP?
- Thread starter B3D News
- Start date
Demirug alludes to it in the article. There are two things involved there. One is the market forces. XP users were probably as big a universe as they ever were going to be in January of 2007. After that point they begin shrinking as new PCs ship with Vista. This is a progressive truth. That's one point.
The other is that actually doing such a port, because of what you'd need to do to XP on the memory side and particularly the kernel, is both a non-trivial investment of time and resources to accomplish, but is also almost certainly going to require an extended beta period of multiple iterations. You don't muck about with the kernel on an OS lightly. As they found quite vividly in adding Win9x compatibility to WinXP, there are all kinds of naughty programmers out there doing unimaginable stuff that is undocumented and unsupported and that goes "Boing!" when you jiggle the kernel. Add the two together, and I'd guess from start to finish it takes you at least one year and possibly as much as two to get that done with anywhere near the stability of DX10 on Vista. All the while your "market" of XP users is dwindling away as they buy new Dells, Gateways, HPs, etc.
So if MS were going to put DX10 on XP, for it to make sense they should have started at least two years ago, IMHO. They didn't. The opportunity to do it in a way that makes sense has already been missed.
Do you know how MS does hotfixes on demand for large customers? Which probably become part of a hotfix downloaded by all if the results are positive?
They simply ask a programmer to write one, and email it to the customer. Which he will do in a matter of hours, or days at the most.
That's about the same as what all software companies do.
Such a hotfix can be something like enabling some user-space thingy to write or read to memory or a device that is located in kernel space. Or negociate better. Or whatever. But it definitely crosses the user/kernel-space boundary.
What do you think an OS does all the time? That there is no interaction at all between user and kernel space? The OS is there to enable that interaction. It's what it does best. It's absolutely trivial for the OS makers. There is nothing hard to it whatsoever. It's why that OS exists in the first place.
Are you serious? You cannot conceptualize the difference between a "hotfix" and a quarter of a kernel rewrite? I don't know if it's a quarter or not, but I do know that it's far, FAR from a "hotfix" in scope. This isn't a few lines of trivial code that you need to plug a hole in, or redirect to a seperate memory address region...
This is the entire interface structure of how ALL drivers plug into the kernel, and how the kernel handles memory management and virtualization. And then it's also entirely new drivers to use that new interface.
Edit:
And about your first reply to me, that was almost entirely flamebait. Why would you otherwise even suggest that MS somehow "lost their sourcecode" or "doesn't know how". I can tell you why, because you're no longer talking logic -- you're talking emotional fanboy-isms.
I never said it couldn't be done, EVER. Point me to where I said MS is incapable of doing it -- in fact, I mentioned more than a few times what would happen if MS actually did: the exact same thing you're seeing now in Vista, which is driver unavailability and instability, performance degredation due to the vendors having to start writing to the new interface, and general unhappiness with all the XP lovers out there because their beloved OS just got tanked by a new driver model.
You are so far into left field with your wild speculation that it's no longer even bordering on plausible. Drivers have nothing to do with an OS kernel? That memory virtualization and moving the entire driver subsystem into a completely seperate ring level is as simple as a hotfix?
You've seemingly jumped yourself off a cliff of absurdity.
Last edited by a moderator:
Ok. We both look at this in a different way. You say, that DX10 on XP cannot be done because they rewrote the entire kernel and driver model, and they would have to do the same for XP to make it work. I would agree that doing that would definitely be non-trivial.
But I say, that they don't need to do that. Even more so: the D3D subsystem has always consisted of different parts. And nothing changes for Vista: part of it, like integrating the memory management into the kernel isn't running in user space. For XP they can write an XP driver that does that part. No need to change the kernel for that, or at most add a startup routine that adds that adress range to the VM tables.
The other part, running the rest of the driver in user memory to prevent costly context switches, can easily be done on XP. Parts of the XP subsystems already run in user space. No problem there.
Windows XP already has a hybrid kernel, in which parts run in kernel and others in user space. With NT3.5, the window manager and graphics subsystem ran in user mode. With NT4.0 they moved that to kernel mode, without changing the driver model. And with Vista, they move it back to user space. It's arbitrary. Marketing wants faster and prettier graphics, and they move the graphics subsystem around to where it's fastest at that moment.
So, in other words: no, I don't think they need to rewrite or patch the XP kernel to be able to run DX10 on it. I see no reason why they would have to do that.
So, it would depend on your definition of the DX10 subsystem: is it a kernel subsystem, a user subsystem, a hybrid, a driver, a service or does it consist of multiple, different parts? And do they confirm to the rules Microsoft sets for those things? Most of the time, the subsystems build by Microsoft don't confirm to those rules; they simply do it the easiest way. Afterwards, you can try and classify it.
But I say, that they don't need to do that. Even more so: the D3D subsystem has always consisted of different parts. And nothing changes for Vista: part of it, like integrating the memory management into the kernel isn't running in user space. For XP they can write an XP driver that does that part. No need to change the kernel for that, or at most add a startup routine that adds that adress range to the VM tables.
The other part, running the rest of the driver in user memory to prevent costly context switches, can easily be done on XP. Parts of the XP subsystems already run in user space. No problem there.
Windows XP already has a hybrid kernel, in which parts run in kernel and others in user space. With NT3.5, the window manager and graphics subsystem ran in user mode. With NT4.0 they moved that to kernel mode, without changing the driver model. And with Vista, they move it back to user space. It's arbitrary. Marketing wants faster and prettier graphics, and they move the graphics subsystem around to where it's fastest at that moment.
So, in other words: no, I don't think they need to rewrite or patch the XP kernel to be able to run DX10 on it. I see no reason why they would have to do that.
So, it would depend on your definition of the DX10 subsystem: is it a kernel subsystem, a user subsystem, a hybrid, a driver, a service or does it consist of multiple, different parts? And do they confirm to the rules Microsoft sets for those things? Most of the time, the subsystems build by Microsoft don't confirm to those rules; they simply do it the easiest way. Afterwards, you can try and classify it.
While on the merits I'm much closer to your position than Frank's, please back off the intensity knob by a notch or two. :smile:
Ok, so there's a start...
Ok, but think about what you're asking... It's not just as simple as adding an address region. Virtualizing video memory so that it can be shared within multiple instances, processes or applications isn't just about address space -- you have contention, priority, and update coherence to consider. That's not a new address range to type in, that's several thousand lines of code.
You really believe so? There are certainly subsystems that run in user space to be sure. But not drivers; drivers within XP are written to have immediate access (direct) to the hardware. By shoving it into a non-ring level 0 state, they no longer have direct access to the hardware in the same way. Which means they must queue their data requests and pass them through the kernel. What entry point in the XP kernel is going to allow for that? Here's a hint: there isn't one. One must be written. ANd this isn't another case of a few extra lines of code to point it to a region -- this is another hunk of tens of thousands of lines of code.
You know what? They don't have to. You can keep your OS kernel 100% intact, along with your driver model, and still move DX10 over to XP. Not a problem at all.
But, not only are you not going to get the performance enhancements available with Vista, you are going to get performance detrminents due to the massive amount of shoehorning you'd have to do to juggle data in eleventy-billion ways to get around having to patch the kernel and completely redesign the driver model.
Last edited by a moderator:
And a new round of conspiracy theories that they "purposely crippled DX10 performance on XP" to sell more Vista. Count on it.
Tho if you don't hit the kernel you do probably shorten the beta cycle I talked about. So maybe it's "only" a 6mo to a year process at that point.
There is only one VM subsystem. And that automatically takes care of all those issues. Because, those things need to be done for each and every device that is part of the logical adress range.
If you want to add a new device to the VM subsystem, you need to write a driver that implements the basic stuff as specified in the API, like reading and writing to it, and hook it up. From that moment on, the VM subsystem can take care of all those other issues.
Well, the code that does the direct access already exists, and it has to run in kernel space in any case, with XP as well as with Vista. But to be able to interact with applications that run in user space, it also needs a part that runs in user space. That's called a hybrid model.
The Windows Driver Foundation (WDF) model that Microsoft designed to make that possible, is supported under windows XP as well as Vista.
Of course, as they changed the API with Vista, you need either two versions of that driver, or one that calls the right API functions depending on the OS it runs on. And under Vista, the driver needs to be able to terminate and restart on demand.
That's about it. I don't see tens of thousands of lines of new code to be written here.
Well, they can reuse more than 90% of the code in any case, they only need to change the interface and a few low-level functions.
Depending on how they do it, it might run (slightly) slower, true. But obviously, they didn't think that was enough motivation for people to go out and buy Vista. So, they simply removed it altogether.
Writing drivers is always a question of juggling stuff around, seeing where the interaction between the API and your driver breaks down and shoehorning it into something that is useable and fast. The API is never as you would want it. The documentation is never good enough. But you have to make do.
And in this case, the people who write the D3D subsystem have access to the source code of everything they fancy, and they can even ask the authors for advice. Because they all work for the same company.
Again, if it cannot be done or would be too expensive, it is because they don't want to do it and there is no budget for it at all. There is no technical reason for it, and it wouldn't be very expensive.
Btw, writing 10,000 lines of code is something you can do in a few weeks, by yourself.
Frank the virtual video memory system is much more complicated as the CPU virtual memory system. You can read all about this stuff in the WDK http://msdn2.microsoft.com/en-us/library/aa973510.aspx
So, you have the kernel driver, dkgkrnl.sys, and the user mode interface, gdi32.dll.
How hard would it be to port those two to XP? What are the problematic functions? DxgkCbMapMemory and DxgkCbUnmapMemory?
If you change these two components in XP you have to change anything else that involves graphics too. Every single DirectDraw/3D runtime. The whole GDI subsystem. Well you could use the Vista versions but there are already some reported compatibility issues with programs that use older DD or D3D versions. People would not very happy if Microsoft kills the compatibility with a service pack.
Compatibility was always a big problem. XP contains a huge count of special runtime patches that make different functions of system DLLs act like Windows 98 or 2000. You normally don’t see this as this happens when a process is started but there are some tools to read and modify the database that is used for this.
If you wanted me to agree with you, you would have given me $10M to do so.
Presumably you do want me to agree with you, but your desire in the matter is limited at a point this side of $10M (tho if you offer $9M, I'll seriously consider it).
I don't know anyone who has said it was impossible for MS to do, so I don't really see the utility of the observation. If anything, a crappy performing DX10 on XP would be *more* of a marketing boon to MS. "See, you absolutely have to have Vista in order to get good performance because its so uber better elite and stuff". That they didn't go that route ought to be a pretty good indication that the cost involved was too substantial to even make that marketing plus a win compared to what they would have had to spend.
Along the same lines, why didn't MS put DirectX9 on the Win9x platform? I mean, since we don't have to alter the kernel, it could've been done. Regardless of performance implications, or stability implications, or the huge video driver overhaul that would have to take place.
The reason is simple: it doesn't make sense.
The reason is simple: it doesn't make sense.
OpenGL guy
Veteran
I'm pretty sure DX9a was compatible with Win9x. Or at least, MS eventually made it so.
OpenGL guy
Veteran
The driver changes required between D3D8 and D3D9 were minimal from the DDI side so porting D3D9 back to Win9x would have been pretty painless. The changes between D3D9 and D3D10 are much more dramatic.I'm pretty sure it was too.
You're both mostly right. I should've been more specific. Win95 doesn't have support for Dx9. Not sure why though...
OpenGL guy
Veteran
Even getting AGP working on Win95 was tough, I can't imagine DX9 being much use