Which parts of pipelines are done using CPU and which are done using GPU?
Reading Wikipedia on Graphics Pipeline, maybe my question does not precisely represent what I am asking.
Referring to this question, which "steps" are done in CPU and which are done in GPU?
Edit:
My question is more into which parts of logical high level steps needed to display terrain+3D models [from files] are using CPU/GPU instead of which functions.
The answer depends on what GPU (since they differ in HW capabilities, specially in integrated ones), but on modern non-integrated GPUs, the entire pipeline is implemented in HW. This includes culling, z-sort and occlusion.
Integrated chipsets, such as Intel's, have less HW features, for example, they usually do tranformation & lighting using software.
It depends a lot on the system configuration, at least the CPU has to issue the commands to the GPU (send vertices lists, upload textures, etc.), and the GPU usually does all the geometric transformations, texture mappings, lighting, etc.
But in many cases, part of the work that the GPU should be doing might be done by the CPU if the hardware doesn't support certain features.
If you're using a 3D engine, it might also do some pre-optimizations on the CPU to alleviate the number of triangles that the GPU has to process, like discarding beforehand parts of the geometry that are known to be hidden (by using BSP's like IdTech engines or Portals like Unreal Engine, for example).
Things like moving and rotating the meshes of the models (e.g. the walking animations) are usually done in the CPU, but nowadays I guess the trend would be to HW accelerate them too.
Regarding the wikipedia link, all the steps mentioned there are usually done in the GPU, but is up to the software running in the CPU to decide what polygons are going to be sent for processing (even if they are discarded by the GPU later on because they're hidden or out of the viewing frustrum).
Which parts of pipelines are done using CPU and which are done using GPU?
As far as I know...
It depends entirely on the hardware, driver and opengl implementation.
Everything you can do in OpenGL, works, but you can't be 100% sure where processing happens - it is conveniently hidden from you (it is actually one of OpenGL benefits).
There are full-software OpenGL emulators, for example - mesa3d (non-certified).
Put such opengl32.dll (if you're on windows) into your program folder, and everything will be running on CPU.
Typically, rasterization (last stage of pipeline - alpha-blend, putting pixel, ztest) is done in hardware. Get old videocard, and it is possible that the rest of functionality will run on CPU. Vertex transformations, vertex manipulations, and even standard lighting can be done on CPU (and they were done on CPU for a long time) - depending on videocard. However, I must admit that that videocards without hardware TL (transform and lighting) support are quite old. AFAIK, transformation and lighting is always performed on CPU if card only supports full hardware acceleration of DirectX 7 (windows-platform specific).
There may be platform dependent way to get videocard capabilities in openGL, though..
Side note: DirectX gives you more information about card capabilities, and a ways to control what happens where (i.e. you can choose software T&L even if videocard supports hardware acceleration - in some cases this may be necessarry). This comes with penalty - DirectX is less flexible than OpenGL, harder to use, harder to experiment with, it is available on less platforms than OpenGL, and worrying about which feature is supported and which isn't takes development time.