- February 28, 2013 at 10:19 am #31167
Here is what I am doing.
1) render to normals/depth frame buffer of a lower texture resolution(lx, ly) using glViewport
2) switch to default frame buffer (which is of screen size) and clear color and depth and set to screensize with glViewport
If depth write is off -> full screen of texture preview is fine and textures are not corrupted (normal and depth textures of 1). But rendering of 3D objects is not possible as depth write is off
If depth write is on-> 3D objects can be rendered, but now the textures are corrupted and is visible on the 3D objects using normal and depth as textures and also in the preview
Previously I was rendering the final scene also in a FBO of lower texture resolution(lx, ly) and after it is done, I render to default FBO as a full screen quad with depth write off. This never manifested the problem as seen in the above scenario with depth write off.
This problem is experienced only on my Galaxy S1 (I-9000) driver 1.6, and not in my PC emulation. Can you suggest if this is a driver bug ? In my previous post, it was confirmed that I cannot use single FBO and multiple attachments and was a driver issue (since by openGL standards, this should work !!). Is this related to the same issue ? Is this driver planned for any update any time soon ?February 28, 2013 at 11:00 am #36758
Are you using precision modifiers in your shaders? Can you try to force everything to highp when running on your target device?
Our PVRVFrame emulator will promote all calculations to highp, so the issues you are seeing may be to do with the target device honouring the lower precisions.
When you say multiple attachments, do you mean multiple colour attachments? Multiple Render Targets are an OpenGL ES 3.0 feature – they are not supported in OpenGL ES 2.0 (unless your target has an extension for this functionality).
JoeFebruary 28, 2013 at 1:09 pm #36759
>Are you using precision modifiers in your shaders?
I am using mediump as standard. But either ways, if the same shader is used without changes how can it work in one instance and viceversa as I mentioned above ?
>do you mean multiple colour attachments?
I meant, using a single FBO and changing the attachment which is the recommended practice instead of using separate FBO for each color target/attachment.March 19, 2013 at 12:27 pm #36760
According to the GLSL ES spec, a given platform can either honour the precision you’ve requested (mediump in your case), or it can promote the calculation to a higher precision. Our PC emulation always promotes calculations to highp precision, whereas our drivers tend to honour the requested precision.
This can lead to artefacts when a lowp or mediump precision have incorrectly been used in shader calculations that require higher precision.
Our recommendation is to use an FBO per-attachment. Using a single FBO and frequently changing the colour buffers attached to it will increase the driver overhead, which in turn could impact performance.
JoeMarch 19, 2013 at 3:31 pm #36761
I have changed to using FBO per attachment after a previous suggestion made in a thread I raised some time back.
That solved the problem I had. After that something changed in my code which I am yet to track that caused this bug to resurface. It could be that I changed precision in shader or what I don’t know. But it is extremely subtle to figure it out.
Thanks for your suggestion, I will scan and once I solve it i will post my findings.