Major design flaw with ms-holographic-experimental

[mlfarrell]

I spent hours today debugging an issue that finally led to my discovery of this flaw:

glClear of the default framebuffer triggers a call to EGLint HolographicSwapChain11::updateHolographicRenderingParameters()

This method inspects the current shader and sets the uHolographicViewProjectionMatrix uniform for THAT shader at THAT time. This totally breaks down when using multiple shaders, since only the last bound shader receives the info, and clearing the framebuffer multiple times per frame isn't a valid solution. This mechanism is going to need to be rethought to ensure that multiple shaders can access the uHolographicViewProjectionMatrix state.

One solution would be to store the matrices in the GL state and allow a glGet(GL_HOLOGRAPHIC_VP_MATRICES_ANGLE, matrices); so I can set them for the shaders myself

[mlfarrell]

Potential solution

mlfarrell@7a858fc

[MikeRiches]

@mlfarrell: I agree that you should be able to get the matrices and apply them to the shader pipeline yourself. This will be better for multi-pass rendering techniques. I will investigate a fix for this in the next update.

[mlfarrell]

Yea. I'm pretty forked from you guys at this point. Feel free to check my fork to see how I tackled this on my end. I'll try to update and sync up to your branch in the future as you guys continue to mature it.

https://github.com/mlfarrell/angle

[bouviervj]

Spend hours before seeing this issue ...
@mlfarrell I have seen your patch, should we implement instead a trigger when calling glUseProgram ? It would be more transparent and less platform dependant.

[mlfarrell]

What I ended up doing was implementing a target I could call from angle to glGet to obtain the holo matrices myself instead of relying on automatic conversion. This allowed me to manage multiple shaders myself. I also have (in my engine) a flag I can check to see whether I'm targeting a stereo FBO or not and act accordingly.