...Could you say how do you make such layers?
Layered software is a common approach where higher layers use lower layers to do their job, usually provide support for higher layers, but without knowing about layers above self. In the case of graphic rendering the lowest layer is the 3rd party graphics API like OpenGL v4.x or v3.x, OpenGLES v3.x or v2.x, D3D v11 or v10, whatever.
The next higher layer, the one that is the lowest w.r.t. to the own implementation, is an abstraction of said graphics API and is called GraphicDevice in my case. A GraphicDevice abstracts the API and gives it a unified interface. This interface is data driven: A given list of graphic rendering jobs is processed. Each job consists of state setting commands and a draw call (you probably / hopefully knowns of the threads that deal with such a rendering approach).
The next higher level obviously generates such rendering jobs. It does so by processing the scene, determining which objects need to be rendered, requesting the necessary parameter sets, generating mentioned rendering jobs, and pushing the jobs into the current job queue. This layer is actually given mainly in form of a graphic rendering pipeline (i.e. the place where the distinction between forward rendering, deferred rendering and such is implemented; I hope some day it is programmable by a node system, but for now it is modularized but hard coded :) ). On the other hand, this layer of Graphic is coupled to some Services instances. A specific Services is GraphicServices where abstracted graphic rendering resources like rendering targets, "code units" (actually shader script snippets), textures, and similar things are managed. The already mentioned rendering jobs often contain simple indices that refer to an abstraction stored within the GraphicServices. The GraphicDevice then is able to get information about abstracted resources and deal with them as needed for the underlying 3rd party graphic API. Other Services used by the graphic rendering pipeline provide the placement or materials to be used.
One may say that above the graphics pipeline layer there is the producer layer. Its job is to generate resources like meshes for freshly spawned particles or the skinning of skeletons. But that does not fit really good into the pattern, because such a layer would not need the next lower one (the graphic rendering pipeline) to do so. Moreover, from an optimization point of view, generating meshes for objects that are not visible is a waste of time, and culling is done in the layer below, so to say. So producing has not really an own layer in this sense.
From an implementation point of view, layers are a collection of instances that together provide an API for a specific, well defined task. It often uses another layer but this is (mostly) not visible to own clients. The higher a layer the higher is the level of dealing with a problem. E.g. the graphic rendering pipeline layer looks at the scene and picks what to render, but it isn't interested in the details like sorting the jobs by material / script / or whatever.
