A Cobalt Renderer application normally starts by selecting a renderer plugin with RenderPluginEnumerator. The selected RendererPlugin creates an IGraphicsDeviceEnumerator, the enumerator selects an IGraphicsDevice, and the device creates the IRenderer through CreateRenderer.

The lower-level GetCobaltAPIVersion and GetRendererPlugin exports still exist for applications that manage plugin loading themselves, but the plugin enumerator is the preferred high-level entry point. It handles platform-specific dynamic library loading, checks Cobalt Renderer API compatibility before retrieving renderer plugin records, and keeps the plugin selection code independent from the renderer implementation names.

CreateGraphicsDeviceEnumerator returns an IGraphicsDeviceEnumerator. Keep the RendererPlugin object alive for as long as the enumerator, devices, or renderers created from the plugin are still in use. The plugin object keeps the dynamic library loaded while objects implemented by that library exist.

Most renderer objects are created from the IRenderer interface and returned through unique_ptr aliases with renderer-specific deleters. Destroying the smart pointer calls the corresponding Delete method and removes the object from application ownership.

The renderer uses deferred deletion internally. It is safe to release objects that are still referenced by a frame currently being drawn, because the native graphics resources are retained until the renderer knows they are no longer needed. If the application must know that deferred destruction has completed, call WaitForDeferredDeletionComplete.

Buffer and texture resources are usually configured before memory is allocated. For example, a vertex buffer binds its attributes before AllocateMemory is called, and a texture buffer has its dimensions, format, sample count, and mipmap settings defined before its memory is allocated. Initial data should also be provided before allocation when the resource is created with static contents.

After allocation, the shape of a resource is intentionally more restricted. Existing contents can be updated through the resource update APIs or ITransferBatch, but structural details such as bound attributes, texture dimensions, and allocation formats should be treated as immutable. This keeps the renderer's native resource ownership clear and avoids hidden reallocations in the middle of frame building.