Part of the Khronos Group
OpenGL.org

The Industry's Foundation for High Performance Graphics

from games to virtual reality, mobile phones to supercomputers

Page 1 of 2 12 LastLast
Results 1 to 10 of 11

Thread: Framebuffer Object - proper support

  1. #1
    Senior Member OpenGL Pro BionicBytes's Avatar
    Join Date
    Mar 2009
    Location
    UK, London
    Posts
    1,165

    Framebuffer Object - proper support

    Why can't the ARB enforce FBOs to allow mixed formats, dimensions and components - like the EXT_Mixed_FrameBuffer_Formats extension on nVidia Geforce 8. Currently, the ARB_FrameBuffer_Object does not enforce the hw vendors to support mixed formats. ATI Radeon 4850, for example, does not support a FBO with both 16-bit float and 8-bit texture attachments.
    Without this unified approach, we are no better off with ARB_FBO than the older EXT_FBO since we still have a convoluted and fragmented code path with limited choices for FBO targets (aside from the integration of Mipmap generate,blit and multisample).
    I'd like the next release of GL (GL 3.2) to enforce this requiement for next generation h/w such as Geforce 8 onwards. Legacy h/w is really going to be running GL 3.x native apps anyway.

  2. #2
    Junior Member Regular Contributor
    Join Date
    Mar 2007
    Location
    Latvia
    Posts
    225

    Re: Framebuffer Object - proper support

    ARB_FBO states that FBO should support different dimensions and component sizes.
    - Where appropriate, relax some of the constraints expressed by previous
    FBO-related extensions. In particular the requirement of matching
    attachment dimensions and component sizes has been relaxed, to allow
    implementations the freedom to support more flexible usages where
    possible.
    At least for me ATI HD2400 with latest drivers supports different dimension attachements. I've not used it in actual rendering, but just now tried to attach RGBA8 + RGB10A2 and also RGBA8 + RGBA16F - works fine, framebuffer status is reported as complete.

  3. #3
    Senior Member OpenGL Guru
    Join Date
    May 2009
    Posts
    4,948

    Re: Framebuffer Object - proper support

    Why can't the ARB enforce FBOs to allow mixed formats, dimensions and components
    The ARB cannot even enforce compliance to their own specifications. The ARB is not an enforcement organization. Enforcing things takes power; the only power the ARB has is the ability to write words onto paper.

  4. #4
    Junior Member Regular Contributor
    Join Date
    Jun 2009
    Location
    FL , USA
    Posts
    192

    Re: Framebuffer Object - proper support

    How about allowing different texture targets i.e GL_TEXTURE_RECTANGLE_2D and GL_TEXTURE_2D in one FBO? I think it will be useful in matrix multiplication where one is m*n and other as n*n where 'n' need not be POT.

  5. #5
    Senior Member OpenGL Guru
    Join Date
    May 2009
    Posts
    4,948

    Re: Framebuffer Object - proper support

    How about allowing different texture targets i.e GL_TEXTURE_RECTANGLE_2D and GL_TEXTURE_2D in one FBO?
    If you have access to hardware that has ARB_FBO, then you have access to hardware that has ARB_NPOT. You no longer need rectangle textures.

  6. #6
    Junior Member Regular Contributor Heiko's Avatar
    Join Date
    Aug 2008
    Location
    the Netherlands
    Posts
    170

    Re: Framebuffer Object - proper support

    Quote Originally Posted by martinsm
    ARB_FBO states that FBO should support different dimensions and component sizes.
    - Where appropriate, relax some of the constraints expressed by previous
    FBO-related extensions. In particular the requirement of matching
    attachment dimensions and component sizes has been relaxed, to allow
    implementations the freedom to support more flexible usages where
    possible.
    At least for me ATI HD2400 with latest drivers supports different dimension attachements. I've not used it in actual rendering, but just now tried to attach RGBA8 + RGB10A2 and also RGBA8 + RGBA16F - works fine, framebuffer status is reported as complete.
    I tried with a small program that uses a 32 bits depth texture and a 16 bits RGBA texture. While the one is used for depth attachment and the other for a color attachment, this works perfectly fine (Ati 4870, drivers 9.4 and 9.5 at least). Haven't tried attaching multiple different color attachments.

  7. #7
    Junior Member Regular Contributor
    Join Date
    Jun 2009
    Location
    FL , USA
    Posts
    192

    Re: Framebuffer Object - proper support

    I tried two GL_TEXTURE_RECTANGLE_ARB of target type with GL_FLOAT type and one of GL_UNSIGNED_BYTE and different dimensions on GeForce 8800GS -- works fine. This is a big relief as I mentioned with regards to unequally sized matrices.

    and yeah the internal format on one was RGB and other was RGBA.
    Did not try out on every combination.

  8. #8
    Super Moderator OpenGL Guru
    Join Date
    Feb 2000
    Location
    Montreal, Canada
    Posts
    4,264

    Re: Framebuffer Object - proper support

    GL_RGB is just GL_RGB8 and GL_RGBA is GL_RGBA8 and since GL_RGB8 gets promoted to GL_RGBA8, they are both the same.
    ------------------------------
    Sig: http://glhlib.sourceforge.net
    an open source GLU replacement library. Much more modern than GLU.
    float matrix[16], inverse_matrix[16];
    glhLoadIdentityf2(matrix);
    glhTranslatef2(matrix, 0.0, 0.0, 5.0);
    glhRotateAboutXf2(matrix, angleInRadians);
    glhScalef2(matrix, 1.0, 1.0, -1.0);
    glhQuickInvertMatrixf2(matrix, inverse_matrix);
    glUniformMatrix4fv(uniformLocation1, 1, FALSE, matrix);
    glUniformMatrix4fv(uniformLocation2, 1, FALSE, inverse_matrix);

  9. #9
    Senior Member OpenGL Pro BionicBytes's Avatar
    Join Date
    Mar 2009
    Location
    UK, London
    Posts
    1,165

    Re: Framebuffer Object - proper support

    OK, having just updated with more recent drivers, it looks like ATI are now allowing proper ARB FBO compliance - ie allowing mixed dimensions, mixed formats and mixed sizes (16/32 bits).
    Certainly their first set of drivers with ARB Framebuffer did not support this.

    Now if only they could sort out the bugs (eg DepthStencil as a render target).

  10. #10
    Member Regular Contributor
    Join Date
    Oct 2006
    Posts
    352

    Re: Framebuffer Object - proper support

    Now if only they could sort out the bugs (eg DepthStencil as a render target).
    Amen to that!
    [The Open Toolkit library: C# OpenGL 4.4, OpenGL ES 3.1, OpenAL 1.1 for Mono/.Net]

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •