frame buffer textures are getting corrupted after rendering to default frame buffer with depth write

PowerVR Insider
,
1

Hi,



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 ?






2

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).



Thanks,

Joe

3

Hi Joe,



>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.

4

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.



Thanks,

Joe

5

Hi Joe,



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.


6

Hi,



Do you think your change has caused your code to no longer use an FBO per-attachment? I’d suggest using PVRTrace to record and analyse your API calls. This should make it easier to spot the error :slight_smile:



Thanks,

Joe