PDA

View Full Version : Question regarding the compatibility of multiple color attachments



raga34
05-29-2014, 06:23 AM
Hi.

I'm writing a deferred renderer, targeting OpenGL >= 3.1. Assuming that I stick to the required color-renderable formats given in the spec - is it legal to have several color attachments of different formats? That is, can I create a framebuffer with an RGBA8888 attachment and an RG16F attachment, and expect to be able to render to both buffers without issue?

The spec seems vague on the matter. I've seen people discussing DirectX claiming that it's not doable there, but I've also seen blog posts discussing their own configurations that do seem to have color attachments with multiple formats (without mentioning whether they were referring to DirectX or OpenGL). Assuming that the blog posts aren't outright lies, I assume the DirectX limitation is just a limitation imposed by the specification, and that most hardware built in the last five years or so is capable of doing it?

thokra
05-29-2014, 07:08 AM
Each color attachment may be in any of the required color formats for textures and renderbuffers described in sections 3.8.1 and 4.4.2.

I don't see why not. BTW, just to get my daily nitpicking on, the GL doesn't know the format RGBA8888. It's RGBA8. :)

Also, if you attach multiple images with different base/internal types and the completeness check returns true, the FBO must be usable for rendering. Otherwise it's either an implementation bug in the completeness check or the handling of FBOs.

reto.koradi
05-29-2014, 08:53 AM
I don't think it's excluded by the spec. It can be platform dependent if certain combinations of formats are supported. The key part of the spec is this:

"Although the GL defines a wide variety of internal formats for framebuffer-attachable images, such as texture images and renderbuffer images, some implementations may not support rendering to particular combinations of internal formats. If the combination of formats of the images attached to a framebuffer object are not supported by the implementation, then the framebuffer is not complete under the clause labeled FRAMEBUFFER_UNSUPPORTED."

Maybe DirectX wanted to avoid these kinds of platform dependencies, and only specifies the lowest common denominator?

thokra
05-29-2014, 09:25 AM
Thanks reto, skipped over that.


Maybe DirectX wanted to avoid these kinds of platform dependencies, and only specifies the lowest common denominator?

I'd assume that at least for the most common formats, with RGBA8 and RG16F definitely among them, most if not all vendors support combining them.

Guess you have no choice but to check all platforms you're targetting for one more feature ... but hey, that's been the GL way for a long time now. ;)

raga34
05-29-2014, 12:17 PM
I don't see why not.

This is OpenGL we're talking about, yes? :D


BTW, just to get my daily nitpicking on, the GL doesn't know the format RGBA8888. It's RGBA8. :)

Nitpicking is appreciated!



Also, if you attach multiple images with different base/internal types and the completeness check returns true, the FBO must be usable for rendering. Otherwise it's either an implementation bug in the completeness check or the handling of FBOs.

Yep, that much was already assumed.



Maybe DirectX wanted to avoid these kinds of platform dependencies, and only specifies the lowest common denominator?


That was my thinking too.

Is pretty much why I asked in the first place; the spec says "these specific formats are supported" and then effectively says "there's no guarantee that you can have them in any particular combination" by what it says regarding FRAMEBUFFER_UNSUPPORTED.



Guess you have no choice but to check all platforms you're targetting for one more feature...


Yep, as it always is. :doh:

thokra
05-29-2014, 12:54 PM
This is OpenGL we're talking about, yes? :D

Damn, and there I thought this was a PHP board. O_O All this time wasted ... ;)