chavvdarrr
Veteran
all hail DX10 ?!
- Thread starter chavvdarrr
- Start date
I'm not sure I like that bit.
*COUGH*bullshit *COUGH*
MS themselves are putting around suggestions of a 10x performance increase as a result of solving the small batch geometry issues; somehow I doubt those numbers will make it to fruition at that level, but there could be a genuine case for higher geometry detail with DX10 apps.
While im sure we would all like dx to be faster, for free as it were, i find it hard to believe that they would willingly cripple so many peoples computers by emulating their own software. Wouldnt it be possible to just have a seperate dx10 api (or what ever it is called) and leave the dx9 legacy one as it is? Like having dx and opengl in fact?
DOGMA1138 said:
What he's suggesting is that DX10 will exist natively in the OS. Video card vendors will only provide drivers for DX10.
Legacy compatability with DX7/8/9 will be provided by layering them ontop of DX10. Since DX10 is a superset of 7/8/9 they will be functionally complete but there will be a performance penalty because of the thunking layer. Given that I wouldn't expect radical departures from DX9 in the API I doubt it will be much of an issue, since most calls will thunk through and one of the design tennets of DX10 is to reduce the API overhead.
MS needed to do this at somepoint, there is just too much legacy in the existing driver model. Pretty much the limiting performance factor in DX9 on any decent video card is the number of times you call DrawIndexedPrim.
ERP, the base for all old DX Version is DX9.L aka WGF 1.0. AS MS need to rewrite all old DX runtimes to the new interface i would not call this thunking. They don't add an additional layer. Because of this a performance penalty is not compellingly. But maybe we will see some compatibility problems.
WGF 2.0 (aka D3D 10) is at least in the driver not nessary a strict superset of DX9.L. The new LDDM make it possible to use complete different methods for both. But the currennt interface documentation did not contain the details about D3D10. Because of this it is still possible to all D3D9.L Function are in the D3D10 interface. But IMHO this will not happend.
DOGMA1138, as I write before it looks like that Fuad did not get all details. MS changed the compatibility procedure with the new drivermodel.
With the XP Model the compatibility is guaranteed at driver level. With every new DX version they add some new methods to the driverinterface but they never removed any. Because of this an old runtime (like DX7) still works with a new driver (DX9). The advantage for MS with this model is that they don't need to change the old runtimes. They problem with this model is that driver interface became more and more complex with every new version. Because of this we even have some redundancys in the interface.
For Vista they have build a new driver model (LDDM = Longhorn device driver model). This model contains for all old and current D3D APIs (include WGF 1.0) only one driver interface. This means that they can't used any of the old runtimes because the driver is not longer compatibility to this old runtimes. They have to changed all old runtimes in a way that they use the new driverinterface. This is they software layer that is fuad talking about. But in the DX model there was allways a layer between game and driver called the runtime. This is not changed.
To remain full truth at least there is a new thunk layer in the LDDM. In the case that the hardware supports SM2.0 or higher the common base contains some functions that translate all fixed function vertex and pixel processing to shaders. This will make it easier to write drivers. It reduce the overheade between runtime and driver, too. Because of this I don't expect a performance penalty from this translation. If a game don't use any fixed function processing at all this thunk is not used anyway. The use of fixed functions processing is not longer recommend even for XP and the XBOX 360 API don't support it at all.
There are some more little details but if you don't write drivers for this new model you don't need to care much.
WGF 2.0 (aka D3D 10) is at least in the driver not nessary a strict superset of DX9.L. The new LDDM make it possible to use complete different methods for both. But the currennt interface documentation did not contain the details about D3D10. Because of this it is still possible to all D3D9.L Function are in the D3D10 interface. But IMHO this will not happend.
DOGMA1138, as I write before it looks like that Fuad did not get all details. MS changed the compatibility procedure with the new drivermodel.
With the XP Model the compatibility is guaranteed at driver level. With every new DX version they add some new methods to the driverinterface but they never removed any. Because of this an old runtime (like DX7) still works with a new driver (DX9). The advantage for MS with this model is that they don't need to change the old runtimes. They problem with this model is that driver interface became more and more complex with every new version. Because of this we even have some redundancys in the interface.
For Vista they have build a new driver model (LDDM = Longhorn device driver model). This model contains for all old and current D3D APIs (include WGF 1.0) only one driver interface. This means that they can't used any of the old runtimes because the driver is not longer compatibility to this old runtimes. They have to changed all old runtimes in a way that they use the new driverinterface. This is they software layer that is fuad talking about. But in the DX model there was allways a layer between game and driver called the runtime. This is not changed.
To remain full truth at least there is a new thunk layer in the LDDM. In the case that the hardware supports SM2.0 or higher the common base contains some functions that translate all fixed function vertex and pixel processing to shaders. This will make it easier to write drivers. It reduce the overheade between runtime and driver, too. Because of this I don't expect a performance penalty from this translation. If a game don't use any fixed function processing at all this thunk is not used anyway. The use of fixed functions processing is not longer recommend even for XP and the XBOX 360 API don't support it at all.
There are some more little details but if you don't write drivers for this new model you don't need to care much.
Thanks Demirug!
Could you either elaborate or dumb this down just a touch, I don't quite get it.Demirug said:
memberSince97
Newcomer
Thanks DR...
digitalwanderer, fixed function vertex and pixel processing is anything before shader processing. In the case of vertex processing this the Hardware T&L part and for the pixel processing the old multitexture interface. DX9 still supports this programming model. If you look at the API fixed function processing works different than shader processing. For fixed functions you need to config the unit with many calls to tell the driver what you want. With the shader model you only select the shader you have create before. Maybe you will set some variables for this shader. Anyway the shadermodel need much less calls to work. If you have a modern GPU the driver will convert the fixed function setup internal to a shader because the vertex und pixel part of the chips works this way anyway.
To make driver development more simple (= less errors) MS have add an additional function to the part of the runtime that is used for all DX versions. This part will convert a fixed function setup in a shader (vertex or pixel). Because of this the driver will never see any fixed function calls. This convert generate Shadermodel 2.0 Shader. If your Hardware don't support Shadermodel 2.0 your driver still need to handle fixed function code. If your hardware have SM2 support the driver need no code for fixed functions.
This whole point don't change anything for the application developers or already written programms. Only driver developers need to take care about. But if one of your old games don't run well anymore with Vista it can be an error in this new fixed function to shader translation code. IMHO compatibility testing with old games will be one of the main jobs for the graphics team during Vista tests. I would not surprised if the questionnaire for the vista beta will contain a question about the games that have been played with the beta.
To make driver development more simple (= less errors) MS have add an additional function to the part of the runtime that is used for all DX versions. This part will convert a fixed function setup in a shader (vertex or pixel). Because of this the driver will never see any fixed function calls. This convert generate Shadermodel 2.0 Shader. If your Hardware don't support Shadermodel 2.0 your driver still need to handle fixed function code. If your hardware have SM2 support the driver need no code for fixed functions.
This whole point don't change anything for the application developers or already written programms. Only driver developers need to take care about. But if one of your old games don't run well anymore with Vista it can be an error in this new fixed function to shader translation code. IMHO compatibility testing with old games will be one of the main jobs for the graphics team during Vista tests. I would not surprised if the questionnaire for the vista beta will contain a question about the games that have been played with the beta.
Thanks Demirug, I don't quite get it but I'm still drinking my coffee....a few hours of pondering it/waking up should bring clarity.
Again, thank you.
Again, thank you.
digitalwanderer said:Thanks Demirug, I don't quite get it but I'm still drinking my coffee....a few hours of pondering it/waking up should bring clarity.
Again, thank you.
As I get it, DX9 still supports fixed function T&L like on the first generation GeForce cards (which are not freely programmable) and DX10 will translate all that code into code for the HW which _is_ programmable (non-fixed function) like for example current high-end DX9 cards.
_xxx_ said:
I am sorry. It seems that what I have written is misleading.
This have nothing to do with DX10 (WGF 2.0) this is only for DX9 or older version.
All DX APIs (uo to WGF 1.0) still support fixed functions. With the XP driver model the driver have to support fixed functions too. In the case you have "programmable" hardware the driver need to convert the fixed function calls to the programmable hardware. This is changed with the new driver model. If the runtime detect that the hardware supports SM2 it will convert the fixed functions to shadercode. In this case the runtime will never call a driver function for fixed functions. This means if you are write a driver for the new model and your hardware already supports SM2 you don't need to write code to support old fixed functions. But if your hardware don't support SM2 you still need to write fixed function code for your drivers.
This will make it easier to write Vista driver for newer hardware.
Similar threads
- Sticky
