Given the constraints of the game engine, would even be practical to have the DLL use a graphics card for massive parallelization?
It would only be feasible for VERY constrained and localized parts, which is why I suggested property propagation. Frankly it was more a curiosity/interesting learning experience thing, than a truly useful in C2C thing.
I only had some limited exposure to CUDA but not OpenCL.
That kind of algorithm would definitely map well except for three issues:
- The properties are currently not stored in a way that would be easily transferrable to graphics memory.
- Property Manipulators can get a dependency on a lot of other game state information via expressions.
- I am not sure how good OpenCL will get along with the Civ4 graphics engine while both attempt to use the graphics card.
The expressions are probably a bit of a killer issue, except perhaps for handling some really common special cases (disease or crime adjacency tile propagation for example), but the overhead of having to translate to/from a suitable simple representation (simple 2 d, or perhaps 3d (property type) array most likely) to pass to the GPU would probably wipe out most of the benefit in the C2C context.
As to the sharing of the GPU, it could be set to only use a secondary GPU. The thing that drive my interest was the growth of APUs. People with IVB, Haswell, or recent AMD processors likely have unused GPUs on package, since most gamers (even Civ) likely have a discrete graphics card also (desktops anyway).
This is actually more interesting in the context of AXXXE, where we talked about everything being a fairly ample (at base level semantics) entity-property system. It may well be that a small set of common property manipulators operating a that level cold be quite CUDA/openCL friendly, and useful to compose higher level semantics.
Not really proposing anything concrete, just musing...