Hi, i'm using multiview extension(both in vk and gles) to achieve some render thread optimization:
by rendering 2 frame in one logical frame, then i can have a big-little pattern in our rendering\rhi thread to lower the power consumption of cpu while keeping high fps, which is a win-win in theory.
the big frame renders a second frame by using multiview which uses a new mvp calculated by camera movement prediction.
Big frame: mutlview pass: render basepass to texture array copy array 0 to rt, render postprocess using single rt as usual.
Little frame: copy array 1 to rt, render postprocess using single rt as usual.
When implementing this optimization using multiview, i turned every shader in related passes to a multiview supported permutation. It works fine in first person cameras.
But when it comes to third person cameras, that is when the camera follows a main character, problem occurs.
You see in this optimization, we render every thing by using a predicted camera matrix, including the mesh which is linked to camera.
This is where this optimization fails, in theory, i shouldn't predict the main character's movement, because it's not right, it's movement follows the camera, it's special in the 3d scene.
So the easiest solution is to not render main character using mulitview shader, but normal shader. This way we render the character in both big and little frames. Which solves the prediction problem.
I have 2 options then:
Big frame: mutlview pass: render basepass to texture array, copy array 0 to rt, "render basspass again(but only renders main charactor)", render postprocess using single rt as usual.
Little frame: copy array 1 to rt, "render basspass (but only renders main charactor)", render postprocess using single rt as usual.
Big frame: mutlview pass: render basepass(but renders main charactor using normal shader in multiview pass) to texture array, copy array 0 to rt, render postprocess using single rt as usual.
Option A follows the multiview rule, use multiview supported shader in multiview pass. But it's hard to implement on the CPU side. because i have to run 2 basepass in a single frame by using different input.
Option B obeys the multiview rule, because it uses normal shader in some drawcalls in a multiview pass. But it's easier to implement, and more flexible on the CPU side. I can even make more drawcall to use normal shaders(translucent pass for example) to lower the gpu pressure in multiview pass.
Because i'm using multiview in a single frame, it's important to keep the GPU time low down to a budget, or this optimization will turn GPU to the bottleneck in terms of performance.
Okay, finally, here's my question, is it safe to render using normal shader in a multiview setup-ed pass? Is it safe in the driver side? Will it affects the performance of multiview rendering?
Can i using Option B to solve my problem?
Option C: still use multiview shaders in multiview pass, but offset the other views vertex position to cull them to achieve the need of not rendering some drawcall on array index of 1.
I can achieve this by using a uniform buffer branch in vertex shader.
I choose Option C in the end. This sacrifices some performance but is relatively easy to implement.