Only some of part is rendered when I implementing off screen rendering

This topic contains 3 replies, has 2 voices, and was last updated by  Tobias Hector 4 years, 9 months ago.

Viewing 4 posts - 1 through 4 (of 4 total)
  • Author
    Posts
  • #31170

    jongyun
    Member

    Is there any update for below two issues?
    http://forum.imgtec.com/discussion/2031
    http://forum.imgtec.com/discussion/1666

    I have similar issues for implementing off-screen rendering (render to texture).
    When I tested on SGX540 gpu phone which are Samsung Galaxy S, Nexus S and etc, only for SGX540 gpu phone encountered similar problem.
    Other phones like Samsung Galaxy S2(Mali-400) or HTC Desire(Adreno200) works fine.
    In detail, textures are only rendered some part of whole region or nothing has been captured.

    * My sample source is like:


    //Normally initialize FBO
    glBindFramebuffer(GL_FRAMEBUFFER, _fbo);
    glFramebufferTexture2D(GL_FRAMEBUFFER, GL_COLOR_ATTACHMENT0, GL_TEXTURE_2D, textureID, 0);

    glBindRenderbuffer(GL_RENDERBUFFER, _rb);
    glRenderbufferStorage(GL_RENDERBUFFER, GL_DEPTH_COMPONENT16, texture->getWidth(), texture->getHeight());
    glFramebufferRenderbuffer(GL_FRAMEBUFFER, GL_DEPTH_ATTACHMENT, GL_RENDERBUFFER, _rb);

    glCheckFramebufferStatus(GL_FRAMEBUFFER);

    //renderToTexture
    renderToTexture()

    //finalize the FBO
    glFramebufferRenderbuffer(GL_FRAMEBUFFER, GL_DEPTH_ATTACHMENT, GL_RENDERBUFFER, 0);
    glBindRenderbuffer(GL_RENDERBUFFER, 0);

    glFramebufferTexture2D(GL_FRAMEBUFFER, GL_COLOR_ATTACHMENT0, GL_TEXTURE_2D, 0, 0);
    glBindFramebuffer(GL_FRAMEBUFFER, 0);


    I didn’t delete renderbuffer after that code. I delete all buffers when application has terminated. but It doesn’t change the result.

    * One thing I found strange thing is, texture is rendered fine when I add some code like below:


    glBindFramebuffer(GL_FRAMEBUFFER, _fbo);
    glFramebufferTexture2D(GL_FRAMEBUFFER, GL_COLOR_ATTACHMENT0, GL_TEXTURE_2D, textureID, 0);
    glCheckFramebufferStatus(GL_FRAMEBUFFER);
    glFramebufferTexture2D(GL_FRAMEBUFFER, GL_COLOR_ATTACHMENT0, GL_TEXTURE_2D, 0, 0);
    glBindFramebuffer(GL_FRAMEBUFFER, 0);


    Is this code affect some graphics rendering flow on SGX540?
    It seems renderBuffer with depth attachment may affected, but I’m not sure.

    Please let me know if there are any updates for similar issues or solutions.

    Thank you.

    #36772

    Hi Jongyun,

    Our driver tries to optimise draw calls out if it they aren’t being used, and this is an unfortunate bug in that code which should be fixed in our latest reference drivers, but unfortunately hasn’t been incorporated into the platforms you’ve described.

    The simplest way to guarantee it works is to treat FBOs as static objects, and never change them after the initial setup, and only delete them after you’re done rendering. So in your code, if you were to do essentially the following:

    // This should occur at initialisation time only, not during the render loop.
    Init()
    {
    //Normally initialize FBO
    glBindFramebuffer(GL_FRAMEBUFFER, _fbo);
    glFramebufferTexture2D(GL_FRAMEBUFFER, GL_COLOR_ATTACHMENT0, GL_TEXTURE_2D, textureID, 0);

    glBindRenderbuffer(GL_RENDERBUFFER, _rb);
    glRenderbufferStorage(GL_RENDERBUFFER, GL_DEPTH_COMPONENT16, texture->getWidth(), texture->getHeight());
    glFramebufferRenderbuffer(GL_FRAMEBUFFER, GL_DEPTH_ATTACHMENT, GL_RENDERBUFFER, _rb);

    glCheckFramebufferStatus(GL_FRAMEBUFFER);
    }

    //Note that the only FBO state i'm changing is which FBO is bound.
    RenderLoop()
    {
    //Bind the framebuffer you intend to render to
    glBindFramebuffer(GL_FRAMEBUFFER, _fbo);

    //renderToTexture
    renderToTexture()

    //Unbind the framebuffer object by rebinding the main framebuffer
    glBindFramebuffer(GL_FRAMEBUFFER, 0);
    }

    // This should occur at de-initialisation time only, not during the render loop.
    Deinit()
    {
    glBindFramebuffer(GL_FRAMEBUFFER, _fbo);

    glFramebufferRenderbuffer(GL_FRAMEBUFFER, GL_DEPTH_ATTACHMENT, GL_RENDERBUFFER, 0);
    glBindRenderbuffer(GL_RENDERBUFFER, 0);

    glFramebufferTexture2D(GL_FRAMEBUFFER, GL_COLOR_ATTACHMENT0, GL_TEXTURE_2D, 0, 0);
    glBindFramebuffer(GL_FRAMEBUFFER, 0);
    }

    This is the way that our examples work and with this method you should see the render behaving correctly.
    Please let us know if this works for you!

    Thanks,
    Tobias

    #36773

    jongyun
    Member

    Thank you for your advise.
    It works fine for capturing just one scene.

    However, in our application, I need to capture several scenes(textures) and I tried to capture new scene with second FBO and Render Buffer.
    It looks fine for rendering but this method have memory issues.
    Because It means If I captured 100 scenes, I need 100 FBO and 100 Render Buffers.
    (in the case that captured texture is needed for entire application life cycle)

    To avoid memory issues, I tried to delete the renderBuffer, but the captured texture is no more finely rendered.
    I think renderBuffer can be deleted after associated texture is not used anymore.

    So This method doesn’t meet our requirement.

    To avoid this issue, I just added my crack code after the Deinit Step.


    _rendererName = glGetString(GL_RENDERER);
    if(strcmp(_rendererName, “PowerVR SGX 540”) == 0)
    {
    glBindFramebuffer(GL_FRAMEBUFFER, _fbo);
    glFramebufferTexture2D(GL_FRAMEBUFFER, GL_COLOR_ATTACHMENT0, GL_TEXTURE_2D, textureID, 0);
    glCheckFramebufferStatus(GL_FRAMEBUFFER);
    glFramebufferTexture2D(GL_FRAMEBUFFER, GL_COLOR_ATTACHMENT0, GL_TEXTURE_2D, 0, 0);
    glBindFramebuffer(GL_FRAMEBUFFER, 0);
    }



    And I repeat entire process when I need to capture a new scene.
    (repeat for init-rendertoTexture-deinit-crack)
    It works fine for rendering and has no memory issues.
    In your opinion, Is it right way?

    Now I want to know which driver version fixed this bug.
    Could you please let us know which chipset also has this issues?

    Thank you,
    Jongyun.

    #36774

    Hi Jongyun,

    If it works then that should be perfectly fine as a workaround, there’s no reason this should ever cause any problems.

    This isn’t a hardware issue so there’s no chipset to specify as the buggy one here, it’s purely a driver issue as it’s not kicking the render correctly. It will be in a future version of our drivers, but the issue was only discovered recently and so is still being tested, so I can’t give any meaningful version number at present.

    Thanks,
    Tobias

Viewing 4 posts - 1 through 4 (of 4 total)
You must be logged in to reply to this topic.