cpu & gpu convergence

[MadRat]

I still think it boils down to a left brain - right brain relationship.

What Came Out of the Split Brain Experiments?
The studies demonstrated that the left and right hemispheres are specialized in different tasks. The left side of the brain is normally specialized in taking care of the analytical and verbal tasks. The left side speaks much better than the right side, while the right half takes care of the space perception tasks and music, for example. The right hemisphere is involved when you are making a map or giving directions on how to get to your home from the bus station. The right hemisphere can only produce rudimentary words and phrases, but contributes emotional context to language. Without the help from the right hemisphere, you would be able to read the word "pig" for instance, but you wouldn't be able to imagine what it is.

The CPU (right brain) would theoretically have the the static logic of the core while the GPU (left brain) would have all the abtractive abilities for producing spatial-oriented actions. The GPU would be programmable and flexible to handle non-GPU tasks that the CPU needed help on, for things like extra raw FPU power. The CPU would mostly be concerned otherwise with handling just the program execution.

The huge memory bandwidth of the GPU could be shared by the CPU using a "page cache" buffer as a psuedo-L3 cache for the CPU. The "page cache" could be a reserved memory area of the GPU's memory banks, or the GPU would need to somehow share access to its memory - which the latter would be envious! The CPU would have its own slower main memory connected through its own separate main memory controller. The GPU would have embedded high-speed RAM fed into a multiple-configurations memory controller (allowing 64-, 128-, and 256-bit wide memory accesses) to make the chip commodity material for the mass market. The best quality parts would have 256-bit memory access, which with DDR-II could soon amount to 50GB/sec memory bandwidth or more. The middle of the road parts could use either 256-bit memory controllers and slow memory or fast memory and 128-bit memory access. The lowest quality parts would still be salvageable as 64-bit memory-to-the-GPU parts.

 

[Matthew Daws]

BFG10K,

2D acceleration still blows away any CPU. If you don't think so then set your acceleration slider to "none" or load a standard VGA driver and you'll see how slow your GUI operations will be.

I have to disagree. I've just done this on my (cheap Toshiba) laptop, and am noticing very little difference (only when maximise of minimise a windows really - dragging a window around the screen is surprisingly fast). This could well be because the Intel graphics my laptop uses is pretty poor, or because the shared graphics memory has the odd effect of making it faster to access by the CPU. Anyhow, Windows XP is fine to use without the graphics hardware helping out!

I think hahher was mostly correct when he said 2D games today do not use the hardware much (except for page-flitting or large blit from RAM to the graphics card). This is partly down to most graphics cards not exposing a usable API for 2D type stuff (having dappled a bit in Direct X programming, and games, myself).

My earlier post talked about real-time raytracing. I still think it is perfectly possible that in 10 years time we'll see a CPU doing may graphics related things (or, most likely, a number of CPUs sharing tasks). Look at the design of the XBOX 2: it has 6 CPUS (and they are all fully functional PowerPC like chips) as well as a more conventional ATI graphics card. I bet the CPUs will do a surprising amount of graphics related stuff, once developers get to grips with the system.

Anyway, again, just a few thoughts, --Matt

Edit: Hmm, maybe I shouldn't mention the XBOX2. Apparently the main frame-buffer will be embedded in the GPU to allow massive bandwidth, but presumably poorer bandwidth to the outside world (=CPU). Does make me wonder when those 6 CPU cores will actually be doing...

 

[BenSkywalker]

Processors being able to compete with dedicated hardware will happen at some point, but it won't be until a couple of decades after GPU's are 'perfect' in terms of being able to create fluid realistic worlds. By the time that happens however, GPUs will likely be able to run general purpose code at speed equal to that of a CPU

3d started off based on cpu with software modes.

And they were all point filtered, and this is a very important point. Bilinear, trilinear, anisotropic and anything involving AA slaughter performance on a processor, they are very highly parallel operations that CPUs by nature utterly choke on. Take a basic bilinear filtered pixel and on a processor you have to run all of the operations for a single pixel through the processor five times(four to acquire data fifth to blend). You can pipeline a set of pixels but they still have to all be passed five times limiting processors to one pixel outputted every five clocks roughly. That's just bilinear. Talk about the highest levels of anisotropic supported right now and besides adding the computational overhead of determining which angle you need to sample, you also need to deal with 128 samples per pixel. You would likely be looking at over 150 clock cycles per pixel. That would have that screaming fast P4 3.0GHZ pushing out an amazing 20MPixels- and that's only if it's sole job were basic texture filtering.

Then we start adding some actual workload to the core processor. Geometry transformations in the millions of polys per second range, good enough to drain a 1GHZ P3 of pretty much all of its power on its own. Processors are actually pretty strong here in comparison to the other tasks a GPU handles.

Now we get shading. Vertex Shaders do pretty well on processors and are comparable to Geometry transformation. Pixel shaders OTOH. You can DL MS's SDK and check out refrast versus hardware rendering and see examples of current hardware performing ~1000 times faster then current processors. Not 1000%- we are talking .3 frames per second versus 300FPS. In order to be playable, and we will use the low ball 30FPS as a guideline, processors need to become roughly two orders of magnitude faster then they are today. This is the real big issue with processors versus GPUs- pixel shading. Stanford's HLSL that is supposed to work on processors a lot better should help, but we are dealing with several orders of magnitude comparing GPUs to CPUs now, and today's GPUs are pretty lousy on PS performance themselves(the upcoming generations are going to significantly exceed linear improvement on this front).

Add it all together and you start to get a picture of what CPUs are up against when comparing them to GPUs.

Does make me wonder when those 6 CPU cores will actually be doing...

Cell is going to be a monster for physics. Imagine MS's embarassment if they missed a port because their platform couldn't handle the basic physics code that the PS3 could handle without issue. As of now the PS2's processor obliterates XB's in everything save clockspeed- the biggest problem with their platform going to head to head with the other two in visuals is that they were under the impression that a general purpose processor could compete with dedicated hardware- very clearly wasn't true then and it won't be true for a very long time.

 

[Matthew Daws]

Cell is going to be a monster for physics

Hmm, I hadn't thought of that. A Doom 3 like game where everything falls and breaks and explodes in an entriely correct way. Sweet.

Let me change my arguement a little (good debating tactic). I wasn't suggesting that CPUs will completely replace GPUs (the point about sampling is very well observed: it's easy to do quickly with dedicated, parellel hardware, but very hard for CPUs to do, even with stuff like SSE) but that CPUs might start to do some graphics work again. For example, I think that landscape drawing is pretty tough with polygons. I can imagine two of those cores in XBOX2 being fast enough to, say, draw the base landscape for a airplane sim, while the GPU draws buildings, trees etc. The problem with ploygon landscapes is that close up, you need a load of polygons to make the landscape look realistic, but near the horizon, you need very few. So, perhaps, even if the CPU isn't doing the drawing, it might start to dynamically generate the polygons and send these off to the GPU to be drawn (i.e. dynamic geometry, and geometry in general, being moved back to the CPU). After all, doing physics is somewhat like this anyway.

--Matt

 

[BenSkywalker]

The problem with ploygon landscapes is that close up, you need a load of polygons to make the landscape look realistic, but near the horizon, you need very few.

VS 3.0 GPUs will have dedicated hardware that can create and destroy geometry.