# Framebuffer Object - proper support

**URL:** <https://community.khronos.org/t/framebuffer-object-proper-support/57934>\
**Category:** OpenGL\
**Created:** [July 1, 2009, 5:36am UTC](https://community.khronos.org/t/framebuffer-object-proper-support/57934 "2009-07-01T05:36:15Z")\
**Posts on this page:** 11\
**Page:** 1

<div class="post-metadata">

**Author:** ![BionicBytes](https://community.khronos.org/user_avatar/community.khronos.org/bionicbytes/32/137_2.png) [@BionicBytes](https://community.khronos.org/u/BionicBytes)\
**Post date:** [July 1, 2009, 5:36am UTC](https://community.khronos.org/t/framebuffer-object-proper-support/57934/1 "2009-07-01T05:36:15Z")

</div>

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.

---

<div class="post-metadata">

**Author:** ![martinsm](https://community.khronos.org/user_avatar/community.khronos.org/martinsm/32/4123_2.png) [@martinsm](https://community.khronos.org/u/martinsm)\
**Post date:** [July 1, 2009, 6:28am UTC](https://community.khronos.org/t/framebuffer-object-proper-support/57934/2 "2009-07-01T06:28:01Z")

</div>

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.

---

<div class="post-metadata">

**Author:** ![Alfonse\_Reinheart](https://community.khronos.org/user_avatar/community.khronos.org/alfonse_reinheart/32/4357_2.png) [@Alfonse\_Reinheart](https://community.khronos.org/u/Alfonse_Reinheart)\
**Post date:** [July 1, 2009, 10:40am UTC](https://community.khronos.org/t/framebuffer-object-proper-support/57934/3 "2009-07-01T10:40:46Z")

</div>

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

---

<div class="post-metadata">

**Author:** ![awhig](https://community.khronos.org/letter_avatar_proxy/v4/letter/a/f08c70/32.png) [@awhig](https://community.khronos.org/u/awhig)\
**Post date:** [July 1, 2009, 10:45am UTC](https://community.khronos.org/t/framebuffer-object-proper-support/57934/4 "2009-07-01T10:45:35Z")

</div>

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.

---

<div class="post-metadata">

**Author:** ![Alfonse\_Reinheart](https://community.khronos.org/user_avatar/community.khronos.org/alfonse_reinheart/32/4357_2.png) [@Alfonse\_Reinheart](https://community.khronos.org/u/Alfonse_Reinheart)\
**Post date:** [July 1, 2009, 11:05am UTC](https://community.khronos.org/t/framebuffer-object-proper-support/57934/5 "2009-07-01T11:05:31Z")

</div>

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

---

<div class="post-metadata">

**Author:** ![Heiko](https://community.khronos.org/user_avatar/community.khronos.org/heiko/32/127_2.png) [@Heiko](https://community.khronos.org/u/Heiko)\
**Post date:** [July 3, 2009, 12:40am UTC](https://community.khronos.org/t/framebuffer-object-proper-support/57934/6 "2009-07-03T00:40:15Z")

</div>

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

---

<div class="post-metadata">

**Author:** ![awhig](https://community.khronos.org/letter_avatar_proxy/v4/letter/a/f08c70/32.png) [@awhig](https://community.khronos.org/u/awhig)\
**Post date:** [July 4, 2009, 10:46am UTC](https://community.khronos.org/t/framebuffer-object-proper-support/57934/7 "2009-07-04T10:46:28Z")

</div>

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.

---

<div class="post-metadata">

**Author:** ![system](https://community.khronos.org/uploads/default/original/2X/b/ba89cb49313a0e869198c8be354afde8bcae027e.png) [@system](https://community.khronos.org/u/system)\
**Post date:** [July 6, 2009, 9:47pm UTC](https://community.khronos.org/t/framebuffer-object-proper-support/57934/8 "2009-07-06T21:47:01Z")

</div>

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.

---

<div class="post-metadata">

**Author:** ![BionicBytes](https://community.khronos.org/user_avatar/community.khronos.org/bionicbytes/32/137_2.png) [@BionicBytes](https://community.khronos.org/u/BionicBytes)\
**Post date:** [July 20, 2009, 7:37am UTC](https://community.khronos.org/t/framebuffer-object-proper-support/57934/9 "2009-07-20T07:37:58Z")

</div>

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

---

<div class="post-metadata">

**Author:** ![The\_Fiddler](https://community.khronos.org/letter_avatar_proxy/v4/letter/t/71e660/32.png) [@The\_Fiddler](https://community.khronos.org/u/The_Fiddler)\
**Post date:** [July 21, 2009, 11:58am UTC](https://community.khronos.org/t/framebuffer-object-proper-support/57934/10 "2009-07-21T11:58:20Z")

</div>

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

Amen to that!

---

<div class="post-metadata">

**Author:** ![Brolingstanz](https://community.khronos.org/letter_avatar_proxy/v4/letter/b/41988e/32.png) [@Brolingstanz](https://community.khronos.org/u/Brolingstanz)\
**Post date:** [July 27, 2009, 2:38pm UTC](https://community.khronos.org/t/framebuffer-object-proper-support/57934/11 "2009-07-27T14:38:47Z")

</div>

Rightfully so, though the value in terms of shadow buffer target goodness is lessened a bit if you’re generating linear/multiple depths for say VSM and friends.
