D3D10 has no fixed-function pipeline, so it will be much harder, unless you are doing everything in your D3D9 code with shaders.

I'm not entirely sure, but I would think if you abstracted your renderer enough, you could replace the fixed-function calls with calls to set up shaders.

In my experience with 10 (which is MUCH faster, by the way, if you can port your code over to it, and you have DX10 hardware, and your client is running Vista), it's not worth porting to it yet. However, in the event that you do, there's not *too* much of a programming difference between D3D9 and D3D10 other than (as the above posters mentioned) the removal of the fixed-function pipeline (you have to write shaders to do everything now), and the complete re-write of the initialization process for Direct3D.

You can find the slides from a GDC presetion about porting from D3D9 to D3D10 over at nvdia: GDC 2007

It's not a huge change for most things, but cleanly supporting it in a way that lets you take advantage of its performance improvements will depend on how agile your existing codebase is.

Performance-wise, you'll get the best results if you start to group your states the way that D3D10 does, and treat them as lockable hardware resources, then create and sort them in whatever manner fits in with your existing material/scene sorting methodology. Modifying a state object while it is in use does appear to incur a penalty, from some very sloppy PIX runs I did, so you'll want to avoid that unless there's no alternative. If you do need modifiable states, then I'd recommend using a pool of states and an async query to work as a sort of frame fence. When that fence is hit, then you can mark the range of states that were in use for that frame as available, eliminating the cpu->gpu penalty at the expense of a little cpu legwork.

The switch from vertex declarations to input layouts is a tricky one as well since they now need the input signature of a vertex shader in order to be created. I never came up with what I felt was a great solution for this.

What I ended up doing was to defer layout creation time to draw time and embed layout info in my stream resources. At draw time, since the shaders and all streams would be bound, I would assemble a full layout from all bound streams, and check for the existence of a matching layout in a cache. If it didn't exist, I would create the layout resource and insert it into my cache, removing the least recently used layout (respecting the frame fence to avoid stalls) if I had gone over my fixed resource limit. Again, this forces a little more work on the cpu for the benefit of eliminating stalls. This fit in well with the 'legacy' DX8/9 paths, since in FF the vertex stream also contains its layout/FVF, and in DX9 it was simple enough to just create the vertex declaration based on the bound streams, caching it like in DX10, and not having to bother validating it against the shader.

Other than that, I don't recall any big gotchas. DX10 is really much faster when you use it properly, I've been impressed so far.