When creating a system abstraction is better to have the platform different APIs hidden by a common interface at the lowest level that makes sense.
Taking in account the different modern (with no fixed function pipeline) native graphics APIs: OpenGLES 2.0+, OpengGL 3.0+, DirectX 10.0+, Xbox DirectX 9, LibGCM
If one was to create a stateless low level graphic API to sit on top of them all, what would be the best way to go to make it as thin and as fast as possible?
The lowest level that makes sense from my point of view is something that talks about the resources involved in rendering - vb/ib, render surfaces, textures, shaders, state blocks, etc.
The problem here is that some of these need to be in different formats, depending on the API - that's where it gets a bit tricky. The easiest way around it is to pre-process static resources for the respective API. For dynamic ones, use only shaders to generate them - that makes it fairly straightforward to stay in native formats.
All you then do on the higher level is set up pipelines with attached resources and hand them to the GPU. You'll find that not everything can be abstracted out nicely in that way, especially if you take advantage of hardware-specific tricks. But it's a good start.
(Sidenote: if you treat platform-specific tricks as a special kind of resource, you can push this whole concept quite far. )
So in a way, you'll create two things: A hardware resource manager, plus a toolkit to set up a DAG of these resources.
Given the broad range of APIs you wish to cover, the typical wrapping approach is likely to be inefficient and prone to difficulty in mapping API concepts across several other APIs which may or may not support particular functions to varying degrees.
As a result, the most sensible approach would be to create a feature-centric API. While this approach prevents the API user from utilizing all available functionality, it greatly simplifies the implementation of each backend, and enables backend-specific optimizations that would not otherwise be possible.
It also greatly simplifies management of unsupported functionality for the API user; they no longer have to check if function X exists, and determine which features are affected, but instead need only query the feature itself to see if it is supported with the current configuration. Even if you support partial or limited modes for features, the context provided makes it much easier to manage.
In terms of creating a stateless (also known as submission-based) renderer, typically a 64bit key is used to pack and submit commands for rendering. From that point there is a great deal of flexibility in terms of how to execute commands and what information to submit depending on what features and capabilities you want to support.
To start with, each API does things differently so it should go without saying that wrapping all of the above APIs would be difficult. That said, it is sometimes necessary to do so: at some point a game simply needs to run on more than one platform regardless of how hard it is to do so.
I think the best way to go about doing this is to come up with the functionality that can be implemented on all of the underlying API's and abstract that and only that. If you are developing a multiplatform game, you wouldn't implement every obscure piece of functionality that each API supports, you would only implement what you need. This also helps to keep the API small and fast.
To avoid the clutter of each different API's implementation being packed into the output, compiling should be done with platform neutral header files and platform specific code files. Then, the code file specific to the target platform would be the only one compiled keeping the API small.
There is an article on GPU Pro about this, by Emil Persson (Humus)
http://gpupro.blogspot.com/2009/12/making-it-large-beautiful-fast-and.html
A cross-platform interface for rendering. The advantages of having one, and how we crammed DX10 into a common interface with DX9 consoles and maintained good performance.
You might want to check out the SDL library or Allegro. Both of them are low level, highly-portable game libraries, which have a way to plug them in an OpenGL context so you can render your graphics there. SDL has the fame of being used by he defunct Loki Games to port some popular games from the 2000s to Linux, and Allegro has a lot of time running on and has a great community of amateur game developers.
