Skip to content

Parallelize the entire code early #574

@IAmNotHanni

Description

@IAmNotHanni

Is your feature request related to a problem?

Parallelization is something that is extremely hard to introduce into a codebase in retrospect, meaning that if you have a code base which is not designed to run in parallel, it's almost impossible to make it run in parallel in later stages of the project. We therefore should introduce parallel design early, and strictly.

Description

We can use taskflow library with its amazing threadpool and work-stealing queue, allowing us to reach maximum performance on the cpu side. In general, the hardest part of writing parallel code is proper synchronization. With respect to Vulkan API, this gets even more complex beause we not only have to account for proper synchronization on the cpu (between threads), but we also need to account for cpu-gpu and gpu-gpu synchronization.

The synchronization on the cpu side should be somewhat easy if we assume that we can use taskflow's dependency system to declare which tasks need to finish before other tasks can be worked on. Assuming that there should be only little dependency between render modules (like ImGui should not depend that much on octree data for example), synchronization should be easy to introduce early on.

A harder aspect is this: Is it always true that we can automatically double or triple buffer all gpu resources (buffers or textures) through rendergraph, but only need to have one instance of each data on cpu side required to generate this rendering data? I mean for example if we have only one ImGui wrapper instance, we can generate the vertices and indices for rendering a frame, then submit it to frame A in the double/triple buffered rendering system, and continue with the data for frame B without having to duplicate the ImGui data? This is because there should be no dependency from the rendering into the ImGui data other than the data for rendering, which - again - is double or triple buffered. I think this assumption holds true in general.

Otherwise, we would have to double or triple buffer all ImGui (or other) resources for rendering as well, which would be tedious and error-prone.

Also, by assuming this is not required, we drastically simplify our rendering, because programmers don't need to worry about any double/triple buffering at all. It is all done in the rendergraph automatically.

Alternatives

Not using parallelization will cause the application to be cpu-bottlenecked. An ideal renderer should be gpu-bottlenecked.

Affected Code

The entire code

Operating System

All

Additional Context

None

Metadata

Metadata

Assignees

Projects

Status

Todo

Milestone

No milestone

Relationships

None yet

Development

No branches or pull requests

Issue actions