It sounds like you are trying to design an application framework, which is distinct from a renderer. In general, you have to have a basic interface to your application class which can be manipulated by the main loop. That can be as simple as having an initialize, update, and shutdown set of methods. Then you can overload each of those methods to do whatever additional calls you want.

Basically I want to have a default graphics class which will do all the minimum required stuff for directx and then I have sub classes which will inherit from this class so I can use functions like onrender etc.

You really don't want that. It's an abuse of inheritance and poor object structure. Keep a single class that wraps your graphics device and do not ever inherit from it. To support different graphics APIs, you can make an interface that abstracts the graphics device operations (create buffer, create texture, submit geometry, etc.) and have your concrete implementation derive from that.

Derivation is explicitly an extension of a type and shouldn't be used for other purposes (sans some C++-specific inheritance tricks you almost never need to worry about in application code).

Types represent a single idea and should not try to represent multiple ideas. This is called the Single Responsibility Principle, which is one of the lessons taught in the SOLID. In this case, your graphics device should do only one thing - abstract access to the graphics hardware. Everything else (window management, high-level rendering, resource management, etc.) should be handled by different classes without any inheritance.

Higher-level types that need to use the graphics device should contain a reference/pointer to the graphics device (a has-a relationship) and never inherit from the graphics device (an is-a relationship). You should always prefer aggregation (has-a) over inheritance (is-a) when building your classes.

You might have an application base class that you can extend with your own OnRender method or the like in order to contain and abstract away the basics of window management, input management, etc. This base class might contain a unique_ptr<IGraphicsDevice>, but it will not inherit from the graphics device.

This is where I've got an issue... I'm not sure how to make it so I can create my subclasses and inherit these functions easily without adding their onrender functions etc to the programs main loop in order for them to be called. I hope this makes sense...

There's two pieces to this, if I'm understanding you correctly.

First, provide default implementations of your virtual functions. The Application base might have a virtual DoRender() method with an empty body. A derived application class can then optionally implement the DoRender method.

Second, don't put any base class logic in a virtual method. If your interface is not pure-abstract (e.g. it has logic in it), then all of its virtual methods should be protected and not public. The public methods should do all the mandatory logic and then delegate to the protected virtual methods. Something like:

class Application {
protected:
  // override this in a base
  // protected because this is an implementation detail and not a public interface
  virtual void DoRender() {}

public:
  // public call to perform the Something action
  void OnRender() {
    // do special things we always need to do before derived class's extensions
    BeginFramge();

    // invoke the derived class's extensions, if any
    DoRender();

    // so special things we always need to do after derived class's extensions
    EndFrame();
  }
};

class MyApp final : public Application {
protected:
  void DoRender() override {
    // do all your special app-specific rendering here
    DrawBackground();
    DrawScenery();
    DrawCharacters();
    DrawEffects();
  }
};