From what Ive seen so far of Intel's Larrabee, it may be very useful in AI applications. The chip which allegedly will start being produced late this year is to have 16 or 32 P5 2Ghz CPU cores on it (each with its own L1 cache). Intel plans to initially use them as GPUs, but as each processor is capable of 'atomic' (non-ganged) operations they should be able to run independant programs. AI in games could easily be increased magnitudes to get away from the mannikin-like or limited choreographed scripted NPCs/Monsters/Opponents. Simultaneously running 32 AI scripts would allow more complex/longer/deeper behaviors. Planners and task driven AI methods would be more doable (these often call for alot of evaluation of parallel solutions where only one gets picked as 'best') or doing numerous pattern matchings to classify a changing situation. One limitation may be the memory bandwidth. Some AI solutions search thru large data sets (the AI 'programming' itself is often really just script data). 32 data hungry cores would quickly overwhelm memory processing (even if they go to DDR5...) Trying to retain code in the cache space of each core might be difficult (how small can you fit a byte-code engine ???) Intel is planning to use the Larrabee for graphics (to compete with Nvidia/ATI) so they must have some very high bandwidths, but AI requires much more random access than the typical GPU uses. Physics processing also could make use of many-core architectures no doubt, and maybe with the added versatility there might be more likelyhood that we might have the add-on boards easily available ('cheap') so that they could be common for consumer grade gaming computers.

Quote:Original post by Kylotan
I'm not sure what point you're making. None of this is particularly specific or suited to AI, any more than any other increase in CPU power. Running continuous scripts in parallel is already quite possible but tends not to be done because it's hard to do correctly, rather than being inefficient.

It will be the future of computers... so games (and game programmers) better start addressing its use. Theyve hit the wall in speed on single cpus and the only way to do more is to go parallel. Running parallel scripts simultaneously 32 at a time (not sequentially) will likely just be a start. Its hard to do correctly, yes and we all better start figuring out how to make it easier 'to do correctly'.

AI will (when it actually gets underway properly) will absorb huge amounts of processing resources and the direction Intel is going is but a tiny step.

Quote:Original post by CmpDev
The latest posting on aigamedev may interest you.

Thank you, sir. *polite nod*

Quote:Original post by CmpDev
The latest posting on aigamedev may interest you.

Quote:It will be the future of computers...

Hmm I wonder how the the ps3 cells work? :)

Quote:AI will (when it actually gets underway properly) will absorb huge amounts of processing resources and the direction Intel is going is but a tiny step.

Read the thread posting which is referred to in the above article.

Another website to add to the browse list...

The Cell processor from what Ive seen is a bunch of ALUs tacked onto a memory controller and a General purpose CPU. Its very useful for setting up pipelines of processing things like graphics data (mesh rotations/transformations) but more limited for General Purpose processing (AI can have alot of very random code and data processing, so the Larrabee thing will be more useful for that because there will be 16-32 General purpose CPU cores).

Nvidia and ATI are working on making their GPUs to be split into more independantly programmed components (still doing lock-step parallel data paths of 8 or 16 at time) (See the CUDA stuff from Nvidia http://en.wikipedia.org/wiki/CUDA
http://www.nvidia.com/object/cuda_learn.html to see what direction they are going).

Quote:Original post by wodinoneeye
Another website to add to the browse list...

Ack. You didn't know about AIGameDev?!? 8^o

You could browse through that place for weeks!

Quote:Original post by CmpDev
The latest posting on aigamedev may interest you.

.

Yes, have heard much the same for years about the complications of shared memory multiprocessing (and even distributed non-memory sharing).

I hope that Intel (who arent stupid) will be incorporating in the hardware much more assistance at doing efficient locks and other shared memory niceties.

The programmers will still have to be the ones to decide what parts of their programs have to be linear or parallel. Compilers can obly do so much since their cant extrapolate the larger processing patterns (and the requirements that we want them to meet).

Scripting of individual (independant) objects in parallel would be one of the more likely candidates where parallelism will work well (much more reading of shared data than writing.... message passing with Lockless FIFO , etc..)
The independant nature would allow staying away from fine-grained parallelisms where incessant use of locks becomes too much overhead.
The simulation in a game is usually a lockstep turnwise update-digest-change cycle and its already a given that an 'object' will maintain its own local world representation data.
There are also background processes which can be allocated 'extra' cpu cycles when primary task are quickly completed -- a 'many-core' system gives you even more capability/flexibility to load-level and still keep to a regular cyle.



The main worry I have with an architecture of this kind is -- will it have enough 'fine' memory bandwidth to do the very random memory acesses (a word of attribute data fetched or a tree/link list traversed usually causes a sequence of memory accesses with no close locality -- reading a new cache row constantly with very high cache miss rates...). With 32 CPUs all doing this in paralle Im not sure how well the one main memory controller can keep up.. Even with fast thread switching (waiting on mem reads and doing something else briefly that data IS in the cache for). If the second threads task is similar, now you will have 2X the demand for the memory controller to service.
Maybe with heavy used of fuzzy-logic to add a bit of number crunching to lessen the data accesses... but is it enough to lower cache miss rates and prevent most of the cores from being idle alot of the time??

[Edited by - wodinoneeye on July 26, 2008 8:12:53 PM]