Timothy Lochner

Not skepticism but I’d love to see ways for defining scheduled work. The ones I’ve seen haven’t felt that great so far. BTW, in rendering, the concept of render graphs / frame graphs is really similar to dod but for graphics/gpu. It’s uncannily similar, very weird.

When i hear about multithreading stuff the questions i have are: Do you have a dynamic model (spawning tasks at runtime?). Do you use a fork-join model? Do you do task stealing? Do you do partitioning? Do you have task dependencies? If yes what do you do about deadlocks?

Partitioning: I am not sure what this refers to.

There is 1 thread per core (or fewer threads than cores, configurable via .ini). All tasks are put into a queue and picked up by workers. There is no main thread, per se. main thread gets stuff going then just becomes a worker.

If enabled, each worker has an affinity set to a core #. So the third worker will always run on the third core. You can set groups of tasks to only run on certain cores (ie, async tasks never run on “frame reserved” cores.)

Thank you for the explanation. The model looks to me like Cilk's model ( https://en.wikipedia.org/wiki/Cilk  ) which i liked a lot, but ultimately failed. IMHO, in the end all that matters is if the part of the model that depends on certain programmer abilities, can be satisfied or not.