I was wondering whether next-generation DX10 hardware would possibly run DX9 apps. Since DX10 completely gets rid of the fixed-function pipeline, it wouldn't make sense to have extra transistors on the chip to take the fixed-function path. But then this would mean that people with DX10 hardware wouldn't be able to play older (DX9-) games. So the IHVs will perhaps release drivers that will emulate fixed-function rendering via shaders. Any thoughts on this?
Could DX10 hardware possibly run DX9 apps?
- Thread starter poly-gone
- Start date
arjan de lumens
Veteran
I expect the exact same thing to happen as with all previous DirectX version increments: Microsoft makes a wrapper that does the necessary conversions to support legacy API versions. So the DX9 app will ask for a DX9 interface, and the DirectX runtime will do all the dirty behind-the-scenes-work before presenting DX10-type calls to the actual driver.
There is no DirectX 10 (yet) - it's Direct3D 10 
What makes you think that current hardware has a specific FFP pipeline? I suppose I'll leave that thought to you guys to discuss - but a lot of info we get from IHV's is that the FFP gets directly translated to shaders by the driver, thus the hardware only sees shader-based code.
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).
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
What makes you think that current hardware has a specific FFP pipeline? I suppose I'll leave that thought to you guys to discuss - but a lot of info we get from IHV's is that the FFP gets directly translated to shaders by the driver, thus the hardware only sees shader-based code.
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).
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
I should've guessed that atleast the 2nd generation DX9 hardware would've got rid of the FF pipeline internally altogetherJHoxley said:
.I'd love to simply skip D3D9 code and start off clean with D3D10, but unfortunately it will be a long time before the whole gaming world upgrades to D3D10 hardware. So, from a programmer's POV, one would still have to work with both D3D9 and D3D10 for a while, so this "scaling across hardware" would continue to exist for a while.JHoxley said: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
.arjan de lumens
Veteran
The only GPUs I know about with both fixed-function and shader hardware parts were Geforce3 and perhaps Radeon8500 (for fixed T&L and vertex shading).
It's really quite easy to make a "compiler" that takes as input a block of fixed-function state and returns an equivalent-functioning shader program out (much easier than making e.g. a Cg/HLSL/GLSL compiler); once you have such a compiler, there is no reason to have both fixed-function and shader hardware present in the pipeline anymore. (shameless plug: One such compiler, implemented as a school project, is described in http://www.idi.ntnu.no/grupper/su/sif8094-reports/2002/p10.pdf )
It's really quite easy to make a "compiler" that takes as input a block of fixed-function state and returns an equivalent-functioning shader program out (much easier than making e.g. a Cg/HLSL/GLSL compiler); once you have such a compiler, there is no reason to have both fixed-function and shader hardware present in the pipeline anymore. (shameless plug: One such compiler, implemented as a school project, is described in http://www.idi.ntnu.no/grupper/su/sif8094-reports/2002/p10.pdf )
Last edited by a moderator:
Unknown Soldier
Veteran
Asking a question. Will the emulator, MS write for DX9, seperate the PS/VS shaders and then insert it into the unified shader pipe as a unified precess? Since the DX9 process atm is seperate either a VS/PS shader gets done by it's own pipe/ALU before the next process gets accepted. Unlike the DX10 unified method where PS/VS shaders can get done through the same pipe/ALU.
US
US
The shaders in D3D10 are still separate (though they offer the same base functionality), you still have a separate vertex shader and a separate pixel shader (and a separate goemetry shader). It's just that the hardware treats them as the same (execution wise, I mean) and runs them through a single pipe.Unknown Soldier said:
arjan de lumens
Veteran
Vertex and pixel shaders are still separate logical stages in the rendering pipeline; their feature sets have been unified, but there is no meaningful way for DX10 itself to check or enforce that the driver uses the same physical hardware path for the two functions, any more than it can check or enforce e.g. the number of ALUs or texture units per pipeline.
Exactly... and in many respects, it's not what D3D is there for :smile:arjan de lumens said:
Direct3D (as with OpenGL) is an abstraction of the underlying hardware - it allows us software developers to write code for a specific API and have it work across a number of different chipsets from a number of different companies.
I don't much care how the hardware is implemented - I just want to know that when I'm writing my {g|p|v}s_4_0 shaders that they share a common functionality and featureset. Whether that translates into ATI having implementation A and Nvidia having implementation B is irrelevant.
Well, okay, thats an idealistic point of view
arjan de lumens
Veteran
Possibly; there was a considerable amount of confusion about what the actual hardware resources of the GeForceFX'es were - I have been unable to find any official confirmation on the presence of such a fixed-function T&L unit, although there are a whole bunch of benchmarks suggesting its presence in at least some of the GFFXes.Mordenkainen said:
poly-gone said:I should've guessed that atleast the 2nd generation DX9 hardware would've got rid of the FF pipeline internally altogether
I'd love to simply skip D3D9 code and start off clean with D3D10, but unfortunately it will be a long time before the whole gaming world upgrades to D3D10 hardware. So, from a programmer's POV, one would still have to work with both D3D9 and D3D10 for a while, so this "scaling across hardware" would continue to exist for a while.
Didn't DX8 gen hardware get rid of fixed function? If FF wasn't gone with the geforce 3 for nvidia, then I'd imagine it was gone by the FX series, and I'm pretty sure that the R300 didn't have FF. (though the 8500 did, and could use them at the same time as the more general purpose pipelines)
I seem to recall that it included a dx8, dx8.1, and a dx9 pipeline, but I'm probably wrong. I remember that given as an explanation of why its dx8 performance was so good, but dx8.1 lackluster, and dx9 horribly crippled, then with the 5900 I think the dx8 pipeline was fully converted to dx8.1. I don't know if it would have included fixed function.
Blazkowicz
Legend
Fox5 said:
I think the FX 5800 pixel pipeline had the PS 2.0 stuff and a PS 1.4 ALU next to it (hence all the cheating stuff about replacing" FP32 shaders" by "FX12 shaders"), and on FX 5900 the 1.4 ALU was replaced by a 2.0 one ? (bringing 50% more PS 2.0 shader power, which still sucks.)
as far as I know I think the 5900 still had the fixed TnL stuff too.
There was never any "fixed" T&L stuff in the first place. Its programmability just wasn't exposed through APIs until it reached VS1.1 feature level.
What NVidia did, I believe, is to add an instruction to accelerate a vector-matrix multiplication so it can be done in 3 clocks instead of 4 when certain conditions are met.
What NVidia did, I believe, is to add an instruction to accelerate a vector-matrix multiplication so it can be done in 3 clocks instead of 4 when certain conditions are met.
Blazkowicz
Legend
Aren't ROPs and TMU still fixed function? (or mostly fixed function).
I get confused, will "fixed rendering" in DX10 consist of some rather dumb pixel shaders such as "get those two texels from the TMU, blend them and fill the pixel into the ROP" (crude understanding from me, I hope you get the point)
Or will the DX10 part have to do everything on pixel shader (stupid stuff : do all your bilinear filtering with PS ALUs which should be quite costly isn't it?)
I get confused, will "fixed rendering" in DX10 consist of some rather dumb pixel shaders such as "get those two texels from the TMU, blend them and fill the pixel into the ROP" (crude understanding from me, I hope you get the point)
Or will the DX10 part have to do everything on pixel shader (stupid stuff : do all your bilinear filtering with PS ALUs which should be quite costly isn't it?)
Well, the lines are often blurred between what is meant between fixed-function and programmable when it comes to graphics hardware. I'd venture to guess tha the truth is that all components of modern graphics hardware are programmable to some extent. The ROP's, for instance, will behave differently depending upon what sort of output is being done (blending or not, color writes or not, FSAA or not, etc.). But they're still fixed-function in that they don't execute any instructions defined by the user: they just give the desired operation when specific state commands are set.
In the end, it really doesn't matter how programmable a chip is on a fundamental level. All that matters in the end is performance, and the amount of programmability that is exposed to the programmer. As such, the specific implementation details of things like ROP's, texture reads, triangle setup, and so on, really aren't important. Only the final performance is important. Many differences that one could imagine between different implementations of these units may well differ only in die size.
In the end, it really doesn't matter how programmable a chip is on a fundamental level. All that matters in the end is performance, and the amount of programmability that is exposed to the programmer. As such, the specific implementation details of things like ROP's, texture reads, triangle setup, and so on, really aren't important. Only the final performance is important. Many differences that one could imagine between different implementations of these units may well differ only in die size.
Effectively yes. With the current FFP you can call a number of API functions (about 10-20 lines of code) and it'll handle fetching two texels and compositing them together and passing them on to the frame buffer blender.Blazkowicz_ said:
With Direct3D 10 you'd have to write your own pixel shader to do this. Although, your example is pretty damn trivial so it doesn't actually make for much extra code (possibly less).
However, there is *no* fixed rendering. Its the wrong term to use - and if you're confused already, I'd avoid it
Texture filtering is done outside of the shaders. You don't have to implement your own filtering algorithms. Given the fixed-caps nature of D3D10 you should be able to receive filtered input from any texure-based resource.Blazkowicz_ said:
Currently, the only case where you'd want to implement your own filtering is if you're using HDRI and your running on hardware that doesn't natively support it (e.g. I implemented bilinear filtering for FP16/FP32 on ATI hardware in a PS).
hth
Jack
poly-gone said:I should've guessed that atleast the 2nd generation DX9 hardware would've got rid of the FF pipeline internally altogether
I'd love to simply skip D3D9 code and start off clean with D3D10, but unfortunately it will be a long time before the whole gaming world upgrades to D3D10 hardware. So, from a programmer's POV, one would still have to work with both D3D9 and D3D10 for a while, so this "scaling across hardware" would continue to exist for a while.
I am willing to bet that conversion will come around the time Vista owns a much larger portion of the desktop market than XP.
This may take years.
Similar threads
