Could DX10 hardware possibly run DX9 apps?

[Demirug]

Maybe they „secret“ behind our approach is that at first anything that contains data is defines as a “data resourceâ€￾. The description format and the API than allows to bind “data resourceâ€￾ to any consumer point. It is possible that the engine inside decide that it store the same data in two different buffer with different formats. There are some usage hints at creation time to make such decision easier. Bit we can limit the binding in the effect description and as we generate object classes from the description we can check this even at compile time. If the engine is in edit mode we use generic objects. This is necessary to make sure that we can reload parts without restart the whole system. Can be very funny if you work with the global data set and someone change some textures there and at the same moment they change in your life environment.

We even have done some very promising experiments with an API neutral shader system. We build the shader with any .Net language and let it compile to MSIL. Then we use a MSIL reader that parse the code and spilt it to the different shader stages (pre shader, vertex, pixel). Even some simple automatic multi pass splits were working. There are some limits as you can not make use of MSIL features like exceptions etc.

 

[davepermen]

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.

hm. the new macbooks and imacs are simply intel platforms to code for. they run windows, and as such, can be programmed like any other hardware you know in the windows world.

of course, if you program for mac os x, you'll use special tools and libraries etc. but the hw now is just another pc.


(oh, you can run linux on it, of course, too )

 

[KimB]

Not really. As far as the programming is concerned, the majority of the difference between the Mac and the PC has always been in the standard API's that ship with the OS. Only some assembly-language things and a few small details of how things work will have changed with the switch to Intel processors.

There just aren't many programs that do much of any programming in assembly any longer. That's mostly left up to the compiler.

 

[Fox5]

Not really. As far as the programming is concerned, the majority of the difference between the Mac and the PC has always been in the standard API's that ship with the OS. Only some assembly-language things and a few small details of how things work will have changed with the switch to Intel processors.

There just aren't many programs that do much of any programming in assembly any longer. That's mostly left up to the compiler.

Hey, someone had to make the compiler.

I remember hearing that the G5s had some serious performance issues with context switching that PC cpus don't have. (I hope I got that right, hopefully context switching doesn't refer to hyperthreading or something) Actually, if it was done for security reasons, I wouldn't be surprised if all PowerPC cpus had the same performance issue in it.

 

[poly-gone]

hm. the new macbooks and imacs are simply intel platforms to code for. they run windows, and as such, can be programmed like any other hardware you know in the windows world. of course, if you program for mac os x, you'll use special tools and libraries etc. but the hw now is just another pc. (oh, you can run linux on it, of course, too )

I was thinking along the lines of whether the gamer base would opt for a $3500 iMac instead of a rad Alienware gaming machine... Obviously the sensible ones would pick the latter . So as long as you can't run the MacOS on "just any PC", it wouldn't be a worthy target for game developers, IMHO.

 

[KimB]

Hey, someone had to make the compiler.

Right, but that's somebody, not most programmers.

I remember hearing that the G5s had some serious performance issues with context switching that PC cpus don't have. (I hope I got that right, hopefully context switching doesn't refer to hyperthreading or something) Actually, if it was done for security reasons, I wouldn't be surprised if all PowerPC cpus had the same performance issue in it.

Performance issues are a very, very minor concern. The vast majority of code that is written is not performance-sensitive. Yes, even within a program that is performance-sensitive.

 

[DmitryKo]

Actually, things are looking very interesting for D3D9, D3D10 and OpenGL!

First, Vista will support 3 different driver models:
1) Windows 2000/XP - D3D 9.0c only, no Aero Glass, XP-like Aero Express (it's not clear if DDI9 is a requirement)
2) LDDM basic - D3D 9.L aka WGF 1.0: new DDI, provides resource virtualisation, isolation of graphical states, valudation of command streams, scheduling access to hardware. Runs Aero Glass, requires SM2.0 hardware
3) LDDM advanced - resource validation in hardware, supports paging of active graphics memory

Open GL will be mapped to D3D and upgraded to 1.4, which is targeted for D3D-only hardware (although I can't recall any current D3D-only offers ). Open GL ICD is still supported - XP-style ICD will continue to work with XP drivers, LDDM will require new ICD.

Pre-D3D9 calls are translated into a subset of D3d 9.L when LDDM is enabled.

And the most interesting thing is that the actual driver will be moved out of the kernel mode, and a new kernel-mode library, DXG kernel, will now abstract actual hardware for both OpenGL and D3D9/D3D10! This component will be common to all future versions of Direct3D and will just be updated to support new features.

Here's a slide taken from WINHEC 2005 session TWPR05007, Windows Graphics Overview

(courtesy http://www.activewin.com/winvista/thestateofvista.shtml)


A thorough feature preview is available at Digit-Life:
Longhorn: Microsoft improves graphics by 55%

 

[DmitryKo]

And to the author of the topic: YES, Direct3D10 hardware will be able to run DirectX9 applications!

It's not entirely clear how Vista basic DDM is related with advanced DDM in regard to supporting D3D9 and D3D10, but it's safe to assume that advanced model will only be employed by D3D10-level hardware....

 

[Geo]

I'd very much like to see benches of DX9-class hardware on Vista in current high-end games like FEAR. Do the agreements for Vista beta prevent this?

 

[DemoCoder]

OGL is not really a first class Vista citizen tho. No OGL1.5/2.0, no direct binding (mapping to D3D calls will result in suboptimal performance), and finally, no OGL in a window simultaneously coexistent with Aero Glass apps. (atleast, that's what someone said before)

 

[KimB]

OGL is not really a first class Vista citizen tho. No OGL1.5/2.0, no direct binding (mapping to D3D calls will result in suboptimal performance), and finally, no OGL in a window simultaneously coexistent with Aero Glass apps. (atleast, that's what someone said before)

Er, I think you're mixing up the two. There's no direct OGL in a window simultaneously with Aero Glass. There is, apparently, direct OpenGL for full-screen apps, but windowed apps will need to go through a D3D translation layer.

 

[Demirug]

Er, I think you're mixing up the two. There's no direct OGL in a window simultaneously with Aero Glass. There is, apparently, direct OpenGL for full-screen apps, but windowed apps will need to go through a D3D translation layer.

If you have an OpenGL ICD windowed apps can use it too. With Vista every app can chose if it want to use the software renderer, the OpenGL to D3D wrapper or if there any the OpenGL ICD. There is an OpenGL AERO problem because OpenGL contains function that give you access to the front buffer. But every app that use functions that allows direct access to the front buffer will have the same AERO problem. This includes even old DirectDraw and Direct3D games. There is no easy workaround for this. I have try to port an old game (DX 6.1) to a D3D 9.0 but to my horror the game use DirectDraw and the GDI at the same time to build the menu direct in the front buffer. D3D 9.0 does not allow this anymore.

 

[JHoxley]

I'd very much like to see benches of DX9-class hardware on Vista in current high-end games like FEAR. Do the agreements for Vista beta prevent this?

Yeah, I'd imagine the beta licence would be against that... and I forget the finer points, but theres a clause in my MSDN subscription about benchmarking/profiling - so the 'regular' CTP's might also be out.

Anyway, regardless of that - it'd be pointless at the moment. Vista doesn't seem to have started its big drive for performance/optimization yet. Sure, it will, but the build I'm using still seems to be a bit rough/slow still

Benchmarking an optimized XP platform against an unoptimized beta Vista is just asking for trouble...

Jack

 

[Geo]

Benchmarking an optimized XP platform against an unoptimized beta Vista is just asking for trouble...

Yeah, I do agree with that. No point in creating a panic unnecessarily and inappropriately. When's the next beta tho? It also doesn't feel too appropriate if MS is going to suggest it isn't anywhere near final speed until launch day when it magically is.

 

[JHoxley]

No point in creating a panic unnecessarily and inappropriately.

I think it'd just be perfect ammunition for the "M$ is teh suxxor" and slashdot'ers

When's the next beta tho?

They're keeping very quiet on that one - even the beta testers aren't told that sort of thing... My personal guess is sometime around the end of 1Q or start of 2Q.

It also doesn't feel too appropriate if MS is going to suggest it isn't anywhere near final speed until launch day when it magically is.

If you read some of the MSDN blogs and pick up the occasional bit here-n-there it seems that they (unsurprisingly) get things feature-complete and committed to the builds and then go at the optimization with a fine toothcomb. I forget which blog I was reading, but whomever commented that several other departments had finished their feature-commit stage and were now on to bug fixing and optimization only...

It's also quite possible that the currently available builds have a lot more debugging code kicking around that won't even be compiled into the final build(s)...

Jack