I need to have support for a hardware renderer and a software renderer. This isn't for a game, but I need software 3D support for some virtualization platforms (e.g., VMware). So my question is what is the standard pattern for this? Should I define an abstract rendering interface Renderer, and then derive two classes: D3DRenderer, SWRenderer and do something like: if( no 3d hardware ) myRenderer = new SWRenderer(); else myRenderer = new D3DRenderer(); This way I can at least avoid if/else code littered throughout my project. However, what should be the interface for Renderer? I don't want to wrap every Direct3D function. Is it typical to just put higher level constructs in the renderer?

Decide what your program will need to draw, and then provide the required functions for the program to do that. Then implement these functions.

When implementing these functions, you'll notice a lot of API-independent functionality being repeated. Group that functionality into API-independent helper functions or objects.

Abstracting the rendering interface is the way to go.
Not only is it typical to place higher level functionality in the renderer, it's actually recommended and more efficient.

The classic way of doing this is to abstract the functionality into groups, so that's things like:
- (De)Initialisation
- VB/IB buffers
- Textures
- Shaders/Effects

Overall this approach tends to work quite well, though certainly you can go higher if you wish.

The problem of producing a rendering interface before you implement the systems that will be using it is a very time consuming ordeal, because you don't know what your requirements are. ToohrVyk's method of refacting the API indpendant stuff last is usually better as you're requirements will be more solidly defined by this point.