Modern CPUs have multiple cores, thread and resource management and context switching in ways that were nearly unimaginable in the old days. But they still excel at running serial, sequential programs. GPUs, NPUs and other massively parallel processors are far better at concurrency, simultaneous processing of many small computations across large chunks of data, parallel work flows. This is completely novel, as in the old days, serial computing could only emulate parallel execution through brute force illusion, rasterization of work flows and time division. The constant requirement of loading small sections of code and data, running some processes serially and storing the result, then loading the next section created unacceptable delays when applied to very large data sets. In the biological model, processing is not separate from data, they are in fact the exact same thing. Rather, the data becomes simply the current state of an active process. This can be extracted and modeled on the parallel side. Data becomes a record of the current state of the vexel unit, where each unit’s primary definition is of function, simple math dealing with a small field of stored state conditions. The engine is inherent in the element.
On the CPU side, the role is to provide external transforms, visualization for the designer, data flow into and out of the GPU, and coordination of workflow. This can be sub-divided as a main control loop, which loads vexels into the GPU and initiates parallel processing, receives a completion signal from the GPU and then decides whether to run another pass or to take some other action. Other functions such as variable setting, snapshots for visualization, and struct size adjustment are included in the main executable, but should be cleanly separated from the parallel processing coordinator. Much of the time, the main function simply tells the GPU to begin another pass.