Is the D3DXFragmentLinker going away?

I have been hearing talk about this feature going away in D3D10 and that uber shaders will be preferred instead. So just to confirm, is this true?

[339 byte] By [Kharmak] at [2008-1-21]
# 1

Correct, the fragment linker as it exists today will not be on D3D10. Static branching is currently a better way to get better performance than the fragment linker can offer due to its combination of low optimization and overhead in the driver during Create*Shader. You can get similar behavior with HLSL by using includes or #defines to control shader generation. The main difference being the overhead for each compile vs the overhead of few optimizations during a link phase. The driver Create*Shader overhead is the same in both scenarios.

Methods of adding more linking type programming. I.e. setting up a set of functions to call rather than a set of bools, is possible in a later release. The goal is to minimize the overhead that uber shaders can have due to registers being needed for the worst of all paths.

Craig Peeper

Microsoft, Direct3D

CraigPeeper at 2007-8-30 > top of Msdn Tech,Game Technologies: DirectX, XNA, XACT, etc.,Direct3D 10...
# 2

Hello,

I am a developer who has been using the fragment linker quite extensively recently and this news saddens me a bit but also raises my curiosity. I was wondering if you can provide more detail on the optimizations that take place in the effect interface that dont when linking at run time with the fragment linker. I would also be curious in the level of optimization (is it really that much more expensive?) Currently i use the fragment linker for a material editor where the user can select differnt pixel and vertex shader modules to combine into one "effect" so to speak. This flexability is not possible with the effect interface. Currently everything is set up so that materials in the editor can be easily loaded in a game engine with all of the same interfaces / managers etc. I would hate to have to do a rewrite for the engine for optimization and use a totally different system for the editor. You also mention overhead in the driver during create shader. This overhead is on the device regardless right? If the overhead is expensive why not cache handles to the created shader object to use for each material of effect and store them in a manager of some sort? Anyways i hope this question isnt too large ;) but any more details would be greatly appreciated. - Richard Becker

Richard3D at 2007-8-30 > top of Msdn Tech,Game Technologies: DirectX, XNA, XACT, etc.,Direct3D 10...