Reading code in mraphics-core/render/renderer.rs can be frustrating, and the render system is inefficient.
I'm planning a refactor of the render system, but I'm currently focused on adding more functionality and features to Mraphics. So I wrote this to track known issues and any PRs are welcome if you'd like to help improve it.
This is mainly due to the following issues:
1. Poor code organization
Code in renderer.rs is poorly organized. Functions do not follow the single-responsibility principle and their logic is verbose and repetitive.
For instance, the methods Renderer::execute_render_pass and Renderer::execute_compute_pass share mostly the same procedure, and should have their common logic extracted.
2. Hard-coded parts
There are some hard-coded parts in renderer.rs, such as:
a. All storage buffers are read-only during a render pass, and are NOT read-only during a compute pass.
b. Buffers are either visible to vertex and fragment shaders or visible to compute shaders, depending on the pass type they belong to, rather than being determined by actual shader requirements.
3. Numerous and unnecessary pass creation/destruction
Currently, render passes and compute passes are created/destroyed following their declaration order, without any batching, and an individual render pass is created each frame only for clearing the screen. This causes a huge performance cost and is not the recommended way to handle this.
There may be some other issues in the render system. I'll list them in comments if I recall any.🥲
Reading code in
mraphics-core/render/renderer.rscan be frustrating, and the render system is inefficient.I'm planning a refactor of the render system, but I'm currently focused on adding more functionality and features to Mraphics. So I wrote this to track known issues and any PRs are welcome if you'd like to help improve it.
This is mainly due to the following issues:
1. Poor code organization
Code in
renderer.rsis poorly organized. Functions do not follow the single-responsibility principle and their logic is verbose and repetitive.For instance, the methods
Renderer::execute_render_passandRenderer::execute_compute_passshare mostly the same procedure, and should have their common logic extracted.2. Hard-coded parts
There are some hard-coded parts in
renderer.rs, such as:a. All storage buffers are read-only during a render pass, and are NOT read-only during a compute pass.
b. Buffers are either visible to vertex and fragment shaders or visible to compute shaders, depending on the pass type they belong to, rather than being determined by actual shader requirements.
3. Numerous and unnecessary pass creation/destruction
Currently, render passes and compute passes are created/destroyed following their declaration order, without any batching, and an individual render pass is created each frame only for clearing the screen. This causes a huge performance cost and is not the recommended way to handle this.
There may be some other issues in the render system. I'll list them in comments if I recall any.🥲