This question is specific to GPU programming. It's not primarily about the game idea.
However, to better understand the question i will detail what it is i want to achieve in my game.

Development will happen with an NVidia GeForce GTX 980, no AMD/ATI specific hardware is available, in case it matters.

I haven't written a single line of code yet but i would do so in C# using one of the DirectX libraries in existence for .NET, such as SharpDX.
I don't possess all the required knowledge on the subjects i am about to ask about, please forgive my ignorance and/or incorrect nomenclature.
Also, please bare in mind that while I am not educated on the subject, i am absolutely willing to learn. I am merely considering/researching my idea at this time.

The basic idea (the game)

The "game" won't be graphically intensive, instead it will be computationally intensive running a "simulated world" running hundreds or even thousands of small programs on the GPU.
Each program is independent from each other except for basic intercommunication, which is detailed below.

The only "heavy" graphics i can think of right now is displaying each virtual machine and possibly some blinky lights as they communicate and/or runs instructions. Drawing lines between machines that are "physically" connected to each other. Sort of like a map of the world.
As well as drawing the command line of course. But nothing fancy, most computation time would be dedicated to the simulation.

My basic idea is to have a network of computers in a sandbox like "game" controlled from a command line. The command line that the player uses is a separate "computer", the one where the player is sitting at in the "game" world.
This is the game interface, it has the power to create computers in the simulated (on GPU) network, as well as "physically" interacting with the simulated network, such as powering on/off computers (Terminating GPU threads and starting new ones), uploading programs to run on a specific computer, "plugging in" network cables and altering the computers hardware.

The players computer would run on the CPU.

The network should all be capable of communication between each computer, as well as the players computer.

I want each computer to run a CPU architecture, such as x86. Obviously x86 may be too ambitious, i would be fine with the most basic architecture.
IF an architecture, any in existence, would "too much" then a scripting language would be fine as well but optimally, a compiler would be used. Such as a C compiler for the architecture emulated.

Each computer would have ONE compiled program running each. That program would have to take care of everything that computer does, including IO, network communications, bla bla.
As i've pointed out already, speed isn't important. Each machine could run at 20 Hz (IPS, Instructions Per Second) each, higher speeds would of course be better.

Each machine would have it's own memory, storage medium and CPU and would be upgradable, so each machine could be different in speed, memory capacity and storage capacity.
The storage should be saved between game sessions, optimally the storage would be saved on the real world (physical) storage of the computer's hard drive, in case the game stops unexpectedly then each machines "physical" storage would survive... Even if a corruption would occur because a write operation never finished. /details...


  1. Is this viable/possible?
    • Is there a specific approach that is more viable than all others? Why?
    • Which approach is easier? Taking into account my lack of knowledge on the subject of writing CPU emulators.
    • GPU/CPU intercommunications, especially where each machines storage is concerned... Is it a good/bad idea?
  2. Networking... Can several CUDA/OpenCL threads communicate with each other as a network?
    • Taking CPU emulation into account, is communication still possible? If my compiled program running on a machine writes to a specific memory address in the emulation, can that then be transmitted to another GPU thread for reading in emulated memory?
    • Buffering... Suppose several machines "send" packets to one machine, is it possible to have a stack? I "know" how to approach the problem in C#/.NET but i've never actually written a GPU program besides the most simple of things, such as Game of Life type deals and it was quite a while ago.
  3. Is there something within this idea that isn't possible?
  4. On a scale from 1 to 10, how difficult would it be to do this GPU side vs keeping it CPU side? (That is, comparatively speaking if i had the knowledge to do it on the CPU)
  5. Should i continue researching/implementing my idea or do you think i am wasting my time?

Thank you for your time.

  • \$\begingroup\$ I'm far from an expert but my understanding is that a GPU requires that every core is doing the same thing (but on different data). For this reason I don't think this will work (the real CPU would probably do a much better job). To put this into context in a GPU program if statements are very expensive because all the cores going one way on the branch must wait for the ones going the other way because all the cores must remain in lock-step \$\endgroup\$ Commented Apr 13, 2015 at 20:06
  • \$\begingroup\$ What problem are you actually having, or is this just theorycrafting? \$\endgroup\$ Commented Apr 14, 2015 at 4:53
  • \$\begingroup\$ @TrevorPowell I was just theorycrafting. \$\endgroup\$
    – Cadde
    Commented Apr 26, 2015 at 21:47

2 Answers 2


That is not what the GPU is for. You will be facing a lot of pain, and won't get much in result.

As others have pointed out, the GPU is designed to run the exact same program on multiple sets of data at the same time, and get the results when they finish.

As so, the GPU is not designed for branching, inter-thread communication and so on.

Do this in the CPU instead, where this kind of stuff is much easier to implement. You will probably even be wasting a lot of CPU cycles preparing data for your GPU program, possibly even much more than what the actual program will consume.

I understand that you may consider your GPU wasted since you're not using it for this task. However, remember that the GPU is a special purpose hardware, which is designed for that specific purpose. There are other processors, such as the BIOS, and the sound card processor that you're not using, yet you don't see that as a problem.

If you're worried about creating many threads, and thread thrashing, consider using fibers or coroutines if your language supports them, to run all those processes in one thread (or as many threads as cores your CPU has)

  • \$\begingroup\$ Alright, makes sense. Of course i did search on the subject but didn't come up with a reason as to why not. Your answer covers the core problem, that i can't use each core separately. \$\endgroup\$
    – Cadde
    Commented Apr 14, 2015 at 14:14
  • \$\begingroup\$ But this game is doing the same thing massively in parallel. Running a million interpreters in lockstep is parallel although not quite as parallel as an ideal GPU algorithm, still pretty parallel. Of a million computers, probably ten thousand of them are running the same kind of instruction. \$\endgroup\$ Commented May 3, 2022 at 10:02

As with every "Will it be fast enough" question, the proper answer is: Profile it.

Below is my speculation on your case.

I have no experience with CPU emulation, I will base my performance guesses on the performance of Lua, which is said to be the fastest scripting language.

First off, I think using the GPU is not suitable. Your usage defeats what the GPUs are made for: One program running on a lot of threads. Also GPUs don't support intercommunication and conditionals very well.

But your expectations are quite low. 20Hz for lets say 10 000 computers. Nowadays you can count with a 3GHz CPU, with multiple cores. For simplicity lets assume you only have a single thread for this virtual simulation. I am also going to assume that the Lua code(or the one of your choice) is 10 times slower, than compiled C/++ code(Can be improved with LuaJIT, but will be worse due to constant switching between computers and cache misses, etc.).

20 * 10 000 * 10 = 2 000 000 Hz needed to simulate your virtual computers. or 2 000kHz. or 2 MHz. And you can safely assume a computer with a ~3GHz core.

Please bear in mind that due to cache misses, memory operations, and because you probably underestimated your instruction needs you will need much more than 2MHz, but you are safe as long as you don't need more than ~1500 times more power.

I think this idea is viable performance-wise. I would recommend using Lua, so you don't have to reinvent the wheel, and have a solid base to build on. Its also easier to program for starters(if you want your players to program them).

This is pure speculation. If you want a real answer, profile it.

As to whether you should research further or not, you should create a simple prototype(throwaway), which will test both if your game is fun and if its viable performance-wise.

  • \$\begingroup\$ Thanks for the answer, it's not primarily about performance but about the viability of running emulation GPU side where performance per simulated machine isn't of the utmost importance. I have mixed signals on emulating several processors on a CPU, there is definitely some overhead in emulation. It's not just a 1:1 relationship. Yes you can possibly run 1,000 or even 2,000 virtual CPU's at 20 Hz on my processor. But i want to offload as much power as possible to the GPU to take advantage of both the CPU and GPU in this "game". As the "game" won't be graphically intensive the GPU would idle... \$\endgroup\$
    – Cadde
    Commented Apr 13, 2015 at 18:18
  • \$\begingroup\$ @Cadde You shouldn't complicate things when there is a simpler solution. GPU is good for parallel processing, but yours(because of communication and different programflows) is not. Don't try to force a CPU into a GPU, its not what it is designed for. \$\endgroup\$
    – akaltar
    Commented Apr 13, 2015 at 18:29
  • \$\begingroup\$ But that's the whole point of my question. GPU's are fast because they are parallel, you can have as many threads as there are cores on the GPU. Right? Sure, the CPU is faster clock for clock but that would leave my GPU idle in a "game" like this. I never asked "will it be fast enough", i asked "is it possible/viable" and "how would i approach the problem". You are basically answering something completely irrelevant to my question. \$\endgroup\$
    – Cadde
    Commented Apr 13, 2015 at 22:29
  • \$\begingroup\$ Oh and if you are saying "it's impossible to emulate a full instruction set" then my question becomes "what is possible"? Can a very limited number of instructions be emulated GPU side, which ones? If conditionals are the problem, can i circumvent that somehow? \$\endgroup\$
    – Cadde
    Commented Apr 13, 2015 at 22:32
  • 2
    \$\begingroup\$ @akaltar is correct, the GPU is unsuited for this kind of work. It works best when you have the same execution path but different data per "stream". If all your computers were doing the exact same operations in the same order, it would be good, but not in your case. \$\endgroup\$
    – jmegaffin
    Commented Apr 14, 2015 at 11:01

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .