Re: The future of CPU based computing, mini clusters.

In article <ggtgp-3E9E33.21404826102009@xxxxxxxxxxxxxxxxxxx>,
Brett Davis <ggtgp@xxxxxxxxx> wrote:
In article <il1hr6-hck.ln1@xxxxxxxxxxxxxxxxxxx>,
Morten Reistad <first@xxxxxxxxx> wrote:

The huge benefit is that you only need one MMU/L1/L2 per cluster. The
MMU is a huge piece of die real estate, (and heat) as is the L1 and L2.

But you still get process isolation, right?

I am fairly indifferent about process isolation inside a cluster.
I figure that generally you are running the same code on 1000 items.
So a programmer gets a cluster sand box that is all his property.
The OS would wait for all threads to finish before reseting the sandbox
and giving the cluster to another process group.

I am thinking about the possibility to take this one step further;
and look into if it is possible to run _all_ of the system inside
the GPU. If each cluster is on the order of a Via C3 in processing
power this should be perfectly feasible.

Using a few handfuls of clusters as the "main cpu". To have any
hope of running "modern" code like, say QNX, or Version 7 unix,
we need a minimal MMU. Not fancy demand paging; simple process
isolation with base+offset registers does nicely; the 80286 ran
both of these well.

So, basic process isolation 286-style is a basic requirement.

One could argue that this wastes CPUs, but thats antiquated thinking,
you have THOUSANDS of these wimpy CPUs, in HUNDREDS of clusters, the
last thing you want is some irresponsible memory thrashing process
trying to "share" your CPU cluster with you. That would FAIL.

To pull this off you need KISS at all levels, the OS would not care
about individual CPUs, the OS only cares about clusters, and with
hundreds of clusters it has its hands full as it is.

In my world, this OS would be a hypervisor for something resembling
netbsd, where the BSD sees a few scores of processors.

Why not take an OS that runs _only_ in the gpu clusters, and
let whatever stuff is sold with the machine handle the "main" cpu?
This is a stellar chance to migrate "below the radar".

GPUs do not run real code, they run code fragments on pixels/data.
Your CPU runs the ATI OS code to manage the ATI GPU.

Seems memory is an issue.

Exactly how tight is memory in the GPU?


A "logarithmical" layout, 16 cpus, 4 L1, 1 L2 may be a way to
go.

I like this.

In the game industry we are running out of things we can hand off to the
GPU, even if that GPU is relatively bright.

Is this because of need for serial speed ("big" cpus), memory footprint,
or organisational issues where you simply do not have an os and scheduler
for running the gpu units as if they were a large set of normal cpus?

Legacy issues of old spaghetti code designed a decade ago, and grown
into a modern Godzilla nightmare. And I have it easy compared to the
poor losers at EA who are using code two decades old, that was never
actually "designed" to begin with...

Well, perhaps we can get KLH up and running.

-- mrr
.

Relevant Pages