Framebuffer Object - proper support

[BionicBytes]

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.

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

[Alfonse Reinheart]

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.

[awhig]

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.

[Alfonse Reinheart]

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.

[Heiko]

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.

[awhig]

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.

[V-man]

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.

[BionicBytes]

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

[Stephen A]

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

Amen to that!