DirectX 10 = DirectX 9 for Vista

[JHoxley]

I've implemented DirectX 9 in software, so yeah I know what an API is.

heh, sorry! So you worked on SwiftShader then? Nice bit of work that

Why would it be any significant effort to implement DirectX 10 on the XPDM? As far as I know the API is totally orthogonal to the driver model.

Well I suppose this is probably my argument - they aren't seperate orthogonal entities. A lot of improvements in D3D10 (okay, these wouldn't all count as features) are due to improvements in the underlying architecture which is owned by the driver/WDDM stack.

Could you give an example of that, even hypothetical if you have to?

I think the resource model is probably the best example. Hardware requirements like format support and guaranteed operation precision (the functional spec goes into a lot of detail on the casting/conversion/precision rules) could be implemented in a "DDI10-for-XPDM," but the interactions between resources - e.g. the "GPU as a shared resource" (memory virtualization to cross-device sharing). From my understanding of XPDM it would be a hell of a lot of work to get functionality included - and many aspects of the D3D10 API expose, albeit subtle (e.g. resource views allowing casting and binding almost any resource to any I/O plug on the pipeline), parts of the resource model such that you'd have difficulty getting D3D10 to run on XPDM in the same way.

I can see why that's true for cutting-edge games, but for games that only use DX9-class features throught DX10, why not run it on XP? Ok, I'm not saying this is preferred or that Microsoft should provide this possibility, but I do believe some form of 'hack' can work quite well for a certain class of games.

Okay, here's one way I see it:

Yes, some games will use only D3D9-era features via the D3D10 API - but I think these will just be the initial overlap/transition period. Those people that still write a D3D9 engine to run on XP and then have a slightly beefed up SM3+ version that runs on Vista/D3D10. Why would you bother here as you can already play the game via D3D9 and probably not losing all that much.

By the other class, do you mean the more casual/mass-market titles? Say 'The Sims' for example? If so, I'd be surprised if developers of those titles would even use D3D10 - given that we have D3D9Ex as a first-class citizen on Vista and that exposes enough of the features for a 'The Sims'-like title as well as keeping the target market open enough (think laptops and other low-end family PC's that can run Vista but aren't really gaming-oriented).

I suppose I'm querying whether there will ever be a "low end D3D10" game that is EXCLUSIVE (that is, no D3D9/D3D9Ex/XP port exists) to D3D10 that could class as this "only using D3D9 features through the D3D10 interfaces".

I've seen my share of games abusing the API. But as long as you're able to behave exactly the same as the real runtime this can be fixed. Game developers interested in a 'hack' to run their DX10 game on XP just have to do some QA rounds again.

By the way, developers shouldn't rely on DX10 to be completely invariant on every platform supporting it. Some driver bugs can still go uncaught in the WHQL tests. And there are still things that cause undefined behaviour, which can create the expected effect on one machine but cause trouble on another. DX10 has a lot less of these potential dangers, but you can't rely on it blindly. QA on different systems remains necessary.

I see where you're coming from here - my whole scenario about differences between implementation behaviours is pure speculation - if's, but's and maybe's. But likewise, you say "as long as you're able to behave exactly the same" which I'd see as being an absolutely huge IF :smile:

So you believe the new driver model and all the incompatibility it causes wasn't primarily Microsoft's decision, 3-5 years ago?

Yes.

Of course they would have been significant in pushing it through, but in one of our chats with the DX team over in Seattle it was mentioned that the stakeholders were well aware of the problems it would cause but that it was a "lesser of two evils" decision - tidy up the API and take the hit we're discussing now, or have a D3D9+1 API that has all of the caps-induced horrors we've learnt to 'love'...

I think Microsoft is interested in stability more than performance and this was their first motivation to change the driver model and clean up the API. Supporting DX10 on XP would be a step back in stability and this is why I think they won't support it, not performance.

Stability is going to have been a big motivation, but I wouldn't discount performance like you do. The whole "batch, batch, batch" talk and the draw call overheads were having a serious impact on the capabilities of the applications - quite genuinely: performance was a big problem.

Look back over archives in DirectXDev and you'll see a huge number of discussions solely around how to optimally design your D3D9 architecture to minimize state changes and get optimal batching etc..etc.. There isn't so much discussion of the new all singing all dancing shiny effects because that is, within reason, one of the easier parts of D3D9 programming

So unless anyone can convince me of the contrary I believe it's not a big technical issue to support DX10 on XP. It's just a hard decision they made to make the future of computer graphics brighter.

Back-porting WDDM and/or D3D10 to XP is technically possible - Microsoft has a huge number of extremely talented SDE's that would be capable of such a task.

But ultimately it will have been a financial and resourcing decision - the cost involved in it (and not just developing it but maintaining it as well) and the amount of effort involved (time=money of course ) just didn't balance the books. Then factor in the stakeholders - Microsoft aren't the only ones that would take a hit by having such a big change to the landscape.

Consider that, even with MS's seemingly bottomless bank account, they invest the time and resources into doing what you (+others) seem to want (D3D10 on XP) and you'd probably find we'd get XPDM+0.5 and D3D9.5 instead of WDDM and D3D10. Things would have gotten dropped because you're no longer working with a clean slate, you've got a mountain more work to do in the same time frame with (probably) the same number of engineers...

I'd like to think of myself as a proper 'techie' - I like to solve the problems in the best way I know how. But ultimately we're in a business world where books have to be balanced, money has to be made and shareholders kept happy and this has a knock-on effect with what can and can't be achieved...

Risk vs Reward and Cost vs Benefit

You already list a huge number of reasons that made it hard to make it happen but only hard not impossible.

Compared to the challenge to run console games on a PC getting D3D10 games running on Windows XP is easier.

Yes, I concur - hard but not impossible. I'm ready to be proven wrong - as I said earlier, I feel there's a good chance you, if anyone, might


Cheers,
Jack

 

[Nick]

Well I suppose this is probably my argument - they aren't seperate orthogonal entities. A lot of improvements in D3D10 (okay, these wouldn't all count as features) are due to improvements in the underlying architecture which is owned by the driver/WDDM stack.

Sorry, I'm not really following with that. The improvements to the API would also be improvements in XP, as long as you have DX10 hardware. You wouldn't get all of the efficiency benefits but I don't know of any API feature that can't be implemented without WDDM. The application is completely shielded from any driver details, so why wouldn't the API be implementable with the XPDM? Unless I'm missing something...

...but the interactions between resources - e.g. the "GPU as a shared resource"...

You need that for Vista Aero, but not on XP as far as I know. I mean, this isn't exposed in the API, is it?

Yes, some games will use only D3D9-era features via the D3D10 API - but I think these will just be the initial overlap/transition period.

Definitely. It's just this transition period I'm talking about.

If so, I'd be surprised if developers of those titles would even use D3D10...

They won't, given the current situation, but I believe they would if it was supported on XP. It's just a nicer API. I realize that doesn't take away the fact that a DX10 card is needed though.

I suppose I'm querying whether there will ever be a "low end D3D10" game that is EXCLUSIVE (that is, no D3D9/D3D9Ex/XP port exists) to D3D10 that could class as this "only using D3D9 features through the D3D10 interfaces".

Sooner or later there will be DX10 only applications, and people wanting to run them on XP. And a fraction of these could run efficiently enough on XP with a DX10 card. Anyway, that shouldn't be regarded as the norm of course. I just believe it's technically possible.

But likewise, you say "as long as you're able to behave exactly the same" which I'd see as being an absolutely huge IF :smile:

It's not that bad, assuming of course there's really a DX10 card. It also depends on what software layers you have control over. If you're Microsoft, I really doubt it's hard to support the DX10 API on XP, as long as you can convince the IHVs to write a driver for it.

The whole "batch, batch, batch" talk and the draw call overheads were having a serious impact on the capabilities of the applications - quite genuinely: performance was a big problem.

Does DX10 really make "batch, batch, batch" less necessary?

Look back over archives in DirectXDev and you'll see a huge number of discussions solely around how to optimally design your D3D9 architecture to minimize state changes...

Isn't this mainly fixed by using state objects, which is an API-level feature instead of a driver model feature? Or is it really not possible to support them with the XPDM?

Back-porting WDDM and/or D3D10 to XP is technically possible - Microsoft has a huge number of extremely talented SDE's that would be capable of such a task.

That's my point, but I don't think back-porting all of WDDM is necessary. Really just a DDI10 extension should do it I believe. But a certain performance impact is unavoidable then...

Honestly I don't know all the low-level details, I'm just combining all the bits and peices of information I currently have. Again though, I'm not saying they should have taken this road. As you say it requires considerable investments and all it does is keep a small fraction of XP users happy.

Anyway, I don't really concern myself with it that much. I was primarily looking for simple arguments why people shouldn't blame Microsoft. The house+foundations analogy is excellent.

 

[armchair_architect]

You need that for Vista Aero, but not on XP as far as I know. I mean, this isn't exposed in the API, is it?

You can create a shared resource by setting D3D10_RESOURCE_MISC_SHARED in the MiscFlags member of the D3D10_TEXTURE2D_DESC struct you pass to ID3D10Device::CreateTexture2D().

You can open a shared resource created on a different device using ID3D10Device::OpenSharedResource().

 

[Nick]

You can create a shared resource by setting D3D10_RESOURCE_MISC_SHARED in the MiscFlags member of the D3D10_TEXTURE2D_DESC struct you pass to ID3D10Device::CreateTexture2D().

You can open a shared resource created on a different device using ID3D10Device::OpenSharedResource().

Thanks for pointing that out!

Not that it matters much, but couldn't this be implemented with AGP memory mapping? Performance might be low, but this isn't a feature that I expect to be used a lot.

 

[JHoxley]

The improvements to the API would also be improvements in XP, as long as you have DX10 hardware.

Well a lot of the VRAM-MMU is implemented at the WDDM level rather than the hardware/driver level. Look up the WinHEC '06 slides - ISTR it's not until WDDM2.x (or maybe even 3.0) that the hardware (and by implication drivers) take substantial control of this functionality.

Sure, it's not a completely black-and-white case but my point is that some the WDDM does actually implement things that the hardware/driver doesn't.

...but the interactions between resources - e.g. the "GPU as a shared resource"...

You need that for Vista Aero, but not on XP as far as I know. I mean, this isn't exposed in the API, is it?

I see your point - a lot of it isn't explicitly exposed to the API (except Demirugs' example of inter-device resource sharing which CANNOT be done under existing D3D9c and is a routinely asked for feature) but the resource model is generally a lot more flexible under D3D10 than it is in D3D9 (temporarily ignoring anything outside of the API that us developers see).

That is, the characteristics of the new WDDM have allowed a more flexible resource model and implicitly shaped the API sitting on top of it. From what I know of XPDM you'd need some almost unholy hacks to implement it on XP - you'd probably need to write a whole new resource manager layer to get equivalent functionality.

I believe they would if it was supported on XP. It's just a nicer API. I realize that doesn't take away the fact that a DX10 card is needed though.

I wish, as a developer, I could use the technology that I enjoy using but sadly that isn't the case. If the architect says we must support SM2 level hardware then we have to use the API that corresponds to this requirement. I don't really buy the idea that developers would use D3D10 if it were cross-OS unless you also loosened up the hardware requirements (which you're saying they wouldn't need to do).

As a side-track... in my day job I almost had to start doing Symbian/C++ mobile applications because of Nokia's huge market-share of handsets. Customers and architects wanted to use this hardware so we had no choice but to use the horrific software surrounding Symbian. Thankfully for me I got out of this one and my team have stuck with Windows Mobile which is really nice for us developers

Does DX10 really make "batch, batch, batch" less necessary?

Yes, but its due to WDDM rather than the API.

The single-batch overhead which caused so much pain under D3D9 was all due to the architecture of XPDM and the way it caused lots of kernel/context switching. WDDM pretty much eliminates this (I understand this is due to the KM and UM driver partitioning). I'm not aware of anything in the API, drivers or hardware that is involved here - this would be a case where WDDM stomps all over XPDM

Isn't this mainly fixed by using state objects, which is an API-level feature instead of a driver model feature? Or is it really not possible to support them with the XPDM?

I'd prefer Demirug to comment here as he's more familiar with the DDK side of things.

The D3D9 API has a very high granularity with making changes to the pipeline configuration. This is reflected via XPDM in that it communicates between the Application<->Driver through an equally granular interface. I understand that the drivers will compile 'state objects' for upload to the actual hardware and that the D3D9 API has state blocks to help with the API<->Application layer, but there is still this weak link in the middle that you can't get past.

This feeds back into the whole idea that you want to cross the App<->API<->XPDM<->driver<->GPU boundary as few times as possible, yet the granularity means you have little choice.

Really just a DDI10 extension should do it I believe. But a certain performance impact is unavoidable then...

I'm sceptical in that this performance impact might well negate any features you manage to map back. If, at some point, you still have the old driver stack under you then you'll pick up some of these performance problems inherant in D3D9.

OpenGL under XP doesn't seem to suffer the same problems, so maybe a remapping layer as previously mentioned might well work... but I'm putting my money against it still - but I'm happy to be proven wrong

As you say it requires considerable investments and all it does is keep a small fraction of XP users happy.

Maybe it's a little worse this time around, but for the most part there's always been a few months or a year of grumpy people who're happy with what they've got and will do anything they can to resist upgrading... yet sooner or later they probably will... then the next OS comes along and we repeat the exact same cycle

I was primarily looking for simple arguments why people shouldn't blame Microsoft

I think the main bit the "common gamer" has wrong is that they assume its evil M$ throwing their monopoly around and trying to stomp on the little guy just because they can. Or something like that. If they took the time to understand the business reasons and how the technological problems feed back into business justification they'd realise it's just a genuine tough decision (back to my 'lesser of two evils' comment) and chances are no one was going to be completely happy...

Cheers,
Jack

 

[Reverend]

I'm actually asking all this because I regularly visit other forums where Microsoft is bashed for not offering DX10 for XP. I think Microsoft is doing the right thing, but I'm looking for a one-liner to explain this to the masses. The title of this thread is an attempt but not a very good one...

http://www.gameinformer.com/News/Story/200701/N07.0109.1737.15034.htm

Relevant bit :

It’s a tough thing for Microsoft, where, essentially, Windows XP was a just fine operating system. Before that, there were horrible problems with Windows. But once they got there, it did everything an operating system is supposed to do. Nothing is going to help a new game by going to a new operating system. There were some clear wins going from Windows 95 to Windows XP for games, but there really aren’t any for Vista. They’re artificially doing that by tying DX10 so close it, which is really nothing about the OS. It’s a hardware-interface spec. It’s an artificial thing that they’re doing there. They’re really grasping at straws for reasons to upgrade the operating system. I suspect I could run XP for a great many more years without having a problem with it.

No, not exactly a one-liner but maybe this is relevant?

 

[Nick]

No, not exactly a one-liner but maybe this is relevant?

It's certainly interesting to hear such opinion from one of the most respected game developers.

Lately I've also noticed that in reviews where they compare DX9 and DX10 images, there's a huge difference between the two. Not just improved shaders, but totally new textures as well (for no apparent reason). This gives a lot of people the idea that DX10 is way more revolutionary than it is...

 

[Superpig]

Performance might be low, but this isn't a feature that I expect to be used a lot.

Maybe, but already it's an instance of the XPD3D10 failing to match the behaviour of VistaD3D10 (in performance terms at least). You may feel that it's not used often but all D3D10 applications that make use of the feature may be now unusable because of this performance drop.

I'm fairly sure there are other features that would run into similar problems, so how many D3D10 applications would have to fail to work correctly before you'd consider it to be an unsuitable/insufficient implementation?

 

[JHoxley]

No, not exactly a one-liner but maybe this is relevant?

It's certainly interesting to hear such opinion from one of the most respected game developers.

Agreed - that's an interesting comment from John Carmack. Can't say it'll change my stance on the issue though

Jack

 

[Frank]

I agree with John Carmac. There is no technical reason why it couldn't be done, or why it would be very hard.

The "driver" actually consists of multiple, separate parts: the hardware interface, the compiler and runtime (like a mini-OS for the GPU), and the interface with the Windows API (creating windows, reading and writing data, reading keypresses and mouse movement, playing sound and all that).

If you have the source code, it should be pretty easy to hook it up to the different API, use the old driver model for the hardware interface and recompile.

 

[Reverend]

Lately I've also noticed that in reviews where they compare DX9 and DX10 images, there's a huge difference between the two. Not just improved shaders, but totally new textures as well (for no apparent reason). This gives a lot of people the idea that DX10 is way more revolutionary than it is...

Do you have the links for these reviews?

 

[armchair_architect]

There is no technical reason why it couldn't be done, or why it would be very hard.

While I agree it can be done, I think you're underestimating how hard it is. They didn't just change the interfaces slightly, they fundamentally changed which components of the OS/driver are responsible for which parts of the system. An architecture where the driver is all one piece and responsible for the entire system (API->HW translation, memory management, scheduling, etc.) is very different from an architecture where the driver is in multiple pieces with limited/expensive communication between them and the OS handles all memory management and scheduling. These aren't the sorts of differences you can hide behind abstractions at the edges of the driver .. they have significant ripple effects throughout the entire design.

So think of it this way: both MS and the IHVs have finite resources. D3D10 has many very pervasive changes, I think it's the biggest change in D3D since they got rid of retained mode. Would you rather they were less ambitious and just delivered an incremental "9.1" on both XP and Vista? Or that they had delayed it by X months beyond the Vista launch? I'm sure some people would pick one of those two options, but I'm just trying to point out that an XP version is not free, so you have to consider what you'd be willing to give up in order to have it.

 

[Nick]

Do you have the links for these reviews?

I was most shocked by the difference in appearance for the mountains at the bottom of this page: http://vr-zone.com/?i=4946&s=3. Here are some more shots with huge differences: http://www.istartedsomething.com/20060817/directx10-fabulous/. Notice the red banner that say these images are faked. Well, that's great, but tons of people actually believe is this "freaking dooping fabulous". It questions who made these images, and why...

 

[Reverend]

I was most shocked by the difference in appearance for the mountains at the bottom of this page: http://vr-zone.com/?i=4946&s=3.

The second-to-last image (the one you're talking about, I think) is just crazy, it could be just down to an artistic change -- I find it hard to believe you can't have the exact same looking DX10 scene using DX9 with the same performance and with probably the same amount of coding/texturing effort and time.

Unless there's something quite obvious not revealed (which is very possible based on the page you linked), maybe the ATi guys can tell us here.

 

[Silent_Buddha]

I was most shocked by the difference in appearance for the mountains at the bottom of this page: http://vr-zone.com/?i=4946&s=3. Here are some more shots with huge differences: http://www.istartedsomething.com/20060817/directx10-fabulous/. Notice the red banner that say these images are faked. Well, that's great, but tons of people actually believe is this "freaking dooping fabulous". It questions who made these images, and why...

I wouldn't be surprised if that fish at the bottom was using the hardware Tesselator in the R600. However, since that isn't a part of DX10 (yet), that would qualify as "fake" in as far as it's not what DX10 can do now. Either that or they are using some other feature in DX10 to do it.

Regarding the CoJ screenies.

In general, I'd imagine it just goes along with the new WDDM driver model + DX10 makes it more efficient, thus you can do more with the same frame rate budget. It's to to both of them and how they interact with each other.

Sure you could do this in DX9, however you'll also take a rather massive frame rate hit I'd imagine.

Considering the already formidable delays and how much trouble Nvidia had making a working Vista Driver for their DX10 hardware...I think it was more of Microsoft having to decide between delaying Vista for another year to get DX10 (as it exists now) working on XP or shipping Vista and cutting XP out.

And just imagine the horror show if Nvidia ALSO had to make a working DX10 driver for XP. It took them 6 months to get a stable fairly well behaved driver for Vista and that's with a driver model that DX10 was designed to work with.

I can only imagine how much more difficult it would have been to make a driver for XP DX10 with a DX10 hacked to work on XP.

Regards,
SB

 

[AlexV]

The second-to-last image (the one you're talking about, I think) is just crazy, it could be just down to an artistic change -- I find it hard to believe you can't have the exact same looking DX10 scene using DX9 with the same performance and with probably the same amount of coding/texturing effort and time.

Unless there's something quite obvious not revealed (which is very possible based on the page you linked), maybe the ATi guys can tell us here.

I think that the approach to DX10 for first wave, patched-up titles will be different from what would normally happen:devs are forced to put something on-screen that makes the users go OMG OMG OMG TEH SAUCE, DX10 ZA KILLAH-they have to pile stuff on to make it significantly different from the DX9 version. As such, I`d doubt that the performance benefits due to increased efficiency that comes with DX10 will be apparent in their case. Most likely, performance will take a nose-dive. Second-tier, ground-up DX10 targeted titles will probably be a different story though, IMHO.

 

[Geo]

I'm actually asking all this because I regularly visit other forums where Microsoft is bashed for not offering DX10 for XP. I think Microsoft is doing the right thing, but I'm looking for a one-liner to explain this to the masses. The title of this thread is an attempt but not a very good one...

We actually have a guest article on this subject in the works. . . don't we, Demirug? :smile:

 

[AlNom]

We actually have a guest article on this subject in the works. . . don't we, Demirug? :smile:

A one line article?

 

[Geo]

No, but it will be a one-line URL to point others at.

 

[JHoxley]

Go Ralf Looking forward to it already...

I think that the approach to DX10 for first wave, patched-up titles will be different from what would normally happen:devs are forced to put something on-screen that makes the users go OMG OMG OMG TEH SAUCE, DX10 ZA KILLAH-they have to pile stuff on to make it significantly different from the DX9 version. As such, I`d doubt that the performance benefits due to increased efficiency that comes with DX10 will be apparent in their case. Most likely, performance will take a nose-dive. Second-tier, ground-up DX10 targeted titles will probably be a different story though, IMHO.

I agree with your statement in general, but I don't think "forced" is quite right. I think a lot of dev's will be more "OMFG look what I can do" and then just use it to show off, rather than actually being poked by a sharp stick from management...

Even if we removed the API and OS, if you suddenly had a way of saying "nothing less than a G80 or R600 plays here" then you could do some amazing things as they are just criminally powerful toys

Jack