Could DX10 hardware possibly run DX9 apps?

[JHoxley]

There is no doubt that this XP->Vista transition is going to be challenging. I've spoken to quite a few developers who aren't looking forward to it. All of them agree that the end result is worth it, but that doesn't mean that the journey will be fun

There's lots of choices to be made - turbo charged SM3/D3D9, dual D3D9-D3D10, D3D10-OGL... and as with lots of graphics related thing, you can have some awesome code and features, but if the next guy makes you look "old school" then you're screwed.

Jack

 

[Demirug]

I'd imagine it more hinges on the drivers exposing a set of D3D9 (8,7,6..) compatable devices rather than the runtime. D3D10 has started with a clean slate - it has no backwards compatability built in. The various D3D9 (etc..) runtimes will just remap to D3D10 code (which is conveniently a super set).

You are sure about this? The last driver slides I am checked say that every runtime up to D3D9EX will use the D3D9 interface and D3D10 will use the new D3D10 Interface. Maybe an interesting side node is that a D3D9 driver that supports shadermodel 2 does not need to support fixed function calls. The runtime will convert anything to shaders.

From an application point of view, i'm expecting it to run pretty much the same. I'm unclear on D3D9Ex right now, but from a programmers POV it's looking like the magic is performed under the covers and we don't have to worry about it

hth
Jack

D3D9EX looks like a very small improvement over D3D9. Mainly functions for the new window manager and WPF.

 

[Cypher]

You are sure about this? The last driver slides I am checked say that every runtime up to D3D9EX will use the D3D9 interface and D3D10 will use the new D3D10 Interface. Maybe an interesting side node is that a D3D9 driver that supports shadermodel 2 does not need to support fixed function calls. The runtime will convert anything to shaders.

I think Hoxley was mainly referring to how the D3D10 _featureset_ is a superset of D3D9's and that when running under Vista, D3D9/8/7 and OGL will all be essentially calling D3D10 functions (in fact, I'm pretty sure that a misunderstanding of how that'll be working is what was behind the guys at opengl.org running around like their hair was on fire, thinking that OGL would suffer a big drop in perf on Vista).

D3D9EX looks like a very small improvement over D3D9. Mainly functions for the new window manager and WPF.

I thought that D3D9Ex was baiscally D3D9, but with some advantages of D3D10, e.g. zero stall material/RT/shader switching.

(Btw, hey there jollyjeffers! I didn't know that you came to this forum too)

 

[Fox5]

I think Hoxley was mainly referring to how the D3D10 _featureset_ is a superset of D3D9's and that when running under Vista, D3D9/8/7 and OGL will all be essentially calling D3D10 functions (in fact, I'm pretty sure that a misunderstanding of how that'll be working is what was behind the guys at opengl.org running around like their hair was on fire, thinking that OGL would suffer a big drop in perf on Vista).



I thought that D3D9Ex was baiscally D3D9, but with some advantages of D3D10, e.g. zero stall material/RT/shader switching.

(Btw, hey there jollyjeffers! I didn't know that you came to this forum too)

What's the point of programming in OpenGL if it just uses a DX10 wrapper? If a seperate opengl driver isn't possible, then there's no performance or feature benefit to using OpenGL.

 

[poly-gone]

There is no doubt that this XP->Vista transition is going to be challenging. I've spoken to quite a few developers who aren't looking forward to it. All of them agree that the end result is worth it, but that doesn't mean that the journey will be fun

Not to mention the whole multithreading/multicore crap .

There's lots of choices to be made - turbo charged SM3/D3D9, dual D3D9-D3D10, D3D10-OGL... and as with lots of graphics related thing, you can have some awesome code and features, but if the next guy makes you look "old school" then you're screwed.

I think an "easy" implementation would be to run D3D9 on current generation cards with XP and pure D3D10 on next gen cards with Vista, almost like a binary solution. That way you just have to deal with 2 drivers in your engine. But of course, scaling your graphics features across the 2 API is where the challenge lies...

 

[Cypher]

What's the point of programming in OpenGL if it just uses a DX10 wrapper? If a seperate opengl driver isn't possible, then there's no performance or feature benefit to using OpenGL.

The fact that you still get Mac and sub-Vista support?

 

[poly-gone]

In an ideal situation, it would be great to scale your engine across all platforms out there. But in reality, most of the gaming happens on consoles, and Windows. I'd only go as far as Linux (if I plan to go cross-platform). MacOS and the Power-PC architecture is not worth, IMHO.

 

[Reverend]

I was wondering whether next-generation DX10 hardware would possibly run DX9 apps.

Most definitely.

The game developers would be pissed otherwise.

 

[Fodder]

MacOS and the Power-PC architecture is not worth, IMHO.

As of yesterday PowerPC is no longer part of the equation.

 

[poly-gone]

So I see... But can this Core Duo MacOS version run on general Intel PCs (the way Windows and Linux do)? Otherwise, one would still have to program for a specific platform.

 

[Kaotik]

What's the point of programming in OpenGL if it just uses a DX10 wrapper? If a seperate opengl driver isn't possible, then there's no performance or feature benefit to using OpenGL.

Maybe it's just me, but the way I understood it OpenGL can function just like it always used, to with it's own full ICD, driver, whatever, as long as you unload Aero upon launching the opengl game/app.

 

[Fox5]

Maybe it's just me, but the way I understood it OpenGL can function just like it always used, to with it's own full ICD, driver, whatever, as long as you unload Aero upon launching the opengl game/app.

Wouldn't you want to unload aero anyhow, just to maximize performance?

 

[Demirug]

Most definitely.

The game developers would be pissed otherwise.

The gamers even more. With the right system I can have up to 4 different cards in my developer system but you can not expect something like this from a gamer.

 

[Demirug]

Wouldn't you want to unload aero anyhow, just to maximize performance?

If you play in fullscreen you don't need to care about aero. If you are in"desktop mode" you have plenty of performance to waste.

 

[Demirug]

I think an "easy" implementation would be to run D3D9 on current generation cards with XP and pure D3D10 on next gen cards with Vista, almost like a binary solution. That way you just have to deal with 2 drivers in your engine. But of course, scaling your graphics features across the 2 API is where the challenge lies...

Developers always have to scale the features. As there is no fixed D3D9 feature set you have to build more than one way to do a effect.

 

[KimB]

Developers always have to scale the features. As there is no fixed D3D9 feature set you have to build more than one way to do a effect.

Sure. But there's quite a bit more difference between D3D9 and D3D10 than there is between SM2 and SM3 within D3D9.

 

[Demirug]

Sure. But there's quite a bit more difference between D3D9 and D3D10 than there is between SM2 and SM3 within D3D9.

A good effect framework will hide this.

 

[JHoxley]

A good effect framework will hide this.

A VERY good framework I might add.

FF->SM1->SM2->SM3 are, from an application point of view, sharing a fairly similar base. You have some geometry that you get the T&L pipe or your VS to work on, and you have some textures that you get your PS to work with. Okay, it's not trivial, but it is possible to abstract out a base from those 4 platforms.

With D3D10, we have an additional unit, and it's much more flexible for resource allocation/usage. Whilst it'll probably stay the same for a while, the concept of "Vertex data for Vertex shaders" and "Texture data for pixel shaders" is no longer a clear-cut division.

I've been working with D3D10 for months now and I know that I'd rather not be the one tasked with implementing such a system

Jack

 

[Demirug]

A VERY good framework I might add.

FF->SM1->SM2->SM3 are, from an application point of view, sharing a fairly similar base. You have some geometry that you get the T&L pipe or your VS to work on, and you have some textures that you get your PS to work with. Okay, it's not trivial, but it is possible to abstract out a base from those 4 platforms.

With D3D10, we have an additional unit, and it's much more flexible for resource allocation/usage. Whilst it'll probably stay the same for a while, the concept of "Vertex data for Vertex shaders" and "Texture data for pixel shaders" is no longer a clear-cut division.

I've been working with D3D10 for months now and I know that I'd rather not be the one tasked with implementing such a system

Jack

Maybe we talk about different things but the framework I am working on can handle this. I have not start to implement the D3D10 part yet but I don’t see any show stopper after reading the documentation. I must confess that we have build a large abstraction between the API and the “userâ€￾. You don’t see any D3D on the top level anymore. We even use our own complex description types for texture formats and such stuff. The whole description format and the API is flexible so we have no problem with new stages in the API.

 

[JHoxley]

Maybe we talk about different things but the framework I am working on can handle this. I have not start to implement the D3D10 part yet but I don’t see any show stopper after reading the documentation. I must confess that we have build a large abstraction between the API and the “userâ€￾. You don’t see any D3D on the top level anymore. We even use our own complex description types for texture formats and such stuff. The whole description format and the API is flexible so we have no problem with new stages in the API.

Interesting...

I don't doubt it can (and will) be done, but it does still strike me as a big change. Resources, effects and scene graphs can be greatly simplified by following what I said about textures-for-ps and vertices-for-vs route. That's all shaken up as it almost becomes resources-for-stage...

It's one of the things I'm looking into at the moment in the (occasional) bit of spare time I have. I've only considered it from a very high-level so far, so it might well be more trivial once I get to some actual code or formal design.

Cheers,
Jack