We have a begin_render_pass and end_render_pass for each draw/clear_attachments call, which isn't a performance wise solution. This PR is a first step to change this.
For now we issue a begin and end in renderer.rs explicitly in places where it's needed. The next step would be one begin and one end call per WR RenderPass.
For this the following needs to be addressed:
[x] Don't break a render pass with copy\blit_image calls (These must be executed outside a render pass, but WR logic inserts them inside render passes).
Possible Solution: We could use a shader for this.
[x] Don't break a render pass if enabling/disabling depth. Changing the depth changes the required Framebuffer attachment for the pass, so we need to start a new one.
Possible Solution: Create new render passes with multiple sub passes for the different cases which can occur during a WR RenderPass. This implies changing our current render pass and Program creation logic. The question is what is the cost of render pass creation? If it's high we can generate a render pass for the worst scenario (all possible sub passes) during Device init and use it for that particular case, with the drawback of having empty sub passes. If it's low we can process a WR RendePass and build up a render pass with the required number of sub passes during the run, without empty render passes.
We have a
begin_render_passandend_render_passfor eachdraw/clear_attachmentscall, which isn't a performance wise solution. This PR is a first step to change this.For now we issue a begin and end in
renderer.rsexplicitly in places where it's needed. The next step would be one begin and one end call per WRRenderPass.For this the following needs to be addressed:
copy\blit_imagecalls (These must be executed outside a render pass, but WR logic inserts them inside render passes). Possible Solution: We could use a shader for this.RenderPass. This implies changing our current render pass andProgramcreation logic. The question is what is the cost of render pass creation? If it's high we can generate a render pass for the worst scenario (all possible sub passes) duringDeviceinit and use it for that particular case, with the drawback of having empty sub passes. If it's low we can process a WRRendePassand build up a render pass with the required number of sub passes during the run, without empty render passes.This change is