what inside a graphical processor?

Question

Preamble

Due to the super-secret nature of commercial GPU, I didn't find anything interesting yet.
The best thing I can do is asking that to someone which has more experience than me (everyone). It's quite a huge question, I hope it'll fit the rules.
Also because GPU aren't directly related to this network, but there are many others, so I tried.
Because quotes parallel processing and because older GPUs (from retro console and other) uses architectures very different from the modern one, this question is about recent GPUs (the ones supporting GPGPU). To semplify the question, think about NVidia and AMD ones.

Question

My idea of GPU is quite confusing: I know it's a particular piece of hardware, which primary components are tons of cores working parallel, used to elaborate images or general signal, and a quite high amount of RAM used to buffer thing and make elaboration faster
Too much "Wikipedia" for me

These are some of my thesis and information I got (HELP section says to share your research), feel free to confute them:

Point 1: What happens when data send form the CPU enter inside the GPU?

1. You can't write GPU programs in it own assembly: a program written in, for example, Cuda is PTX, an intermediate language that is elaborate (compiled? interpretated?) internally by the GPU. If there is an internal language, a sort of assembly (maybe a microcode like architecture?), it is super-secret
2. There are no official open source drivers. May you want to find something reversing the drivers? Good luck. But there is a good news: some GPU has a quite good doc.

Point 2: Pipeline and shaders

What is a shader? Difficoult to answer. But someone tried. However, shader should be a piece of software that is elaborate by the GPU to render all the beauty 3D scenes. There are more type of shaders, each one is elaborate in a particular step of the GPU pipeline.
But what's that pipeline? Seems to be a sequence of step that goes from receving input from the cpu to the render in output. DirectX and OpenGl should give an astraction of that implementation, but each model/family has a different implementation? Is that a super-secret or it's freely shared with us, poor community? (Or maybe with NDA?)

Point 3: Metaphore

I want to avoid something like "This question is too long. We hate you. Question closed"
Probably you are right, but I still try to save my question.

The faster way to answer this question is making an example: can the GPU look like another piece of hardware? Maybe one not conceptually sophisticated.
In my opinion, it can be viewed partially like an FPGA because of the parallel execution. Many cores = many IP = FPGA? Maybe. But obviously that is a completely different hardware, much more flexible and suitable for different scenarios.

Can you make other examples? Any help is really appreciated from the bottom of my hearth.
If you want, you can also post any resource-book-readings you think it's related to the topic. I really like to go in depth

Answer 1

1) It's not entirely secret: http://docs.nvidia.com/cuda/cuda-binary-utilities/index.html#axzz37R1Qdkjl

There probably isn't a complete documentation of the architecture and some details of the mnemonic->opcode mapping may be obfuscated, but nor is it completely invisible. The invisible part is the supervisory processor on the card which handles transfers in and out of memory and schedules the other processors. That will be running one of the "binary blobs" loaded by the drivers.

Generally manufacturer want to discourage low-level applications because they will break if the manufacturer changes the architecture of the card. Compatibility is bad enough without people targeting specific model numbers of hardware.

The shader processors are best thought of as comparable to MMX or other systems for having one control flow affect an array of registers.

2) "Pipeline" is a concept. Yes, it's made out of software like everything else. The exact division of work between the host CPU and the graphics CPU(s) varies but it's usually set up for stream processing:

• Represent scene as a set of triangles, with various attributes on the triangle and vertex
• Pass each vertex to a vertex shader program (running in parallel on the various units) to produce a modified vertex
• Pass vertexes through "rasterise" to produce a stream of "fragments" (screen location + depth + other attributes like texture and texture coordinates)
• Pass each fragment through a shader program, which may write a colour and depth value to the framebuffer
• Optionally do the whole thing again with different attributes (e.g. shadow stencil rendering)
• Finally hand the entire framebuffer over to the output hardware (streams pixels from RAM). Due to double or triple buffering, this will happen while the next frame is being rendered.