Hello,
Is there any possibility to use GL_RGB10_A2 with FBO’s and render-to-texture?
I managed to create a (‘complete’) FBO with 3 attached textures (using GL_RGB10_A2) as internal format. But it looks like the textures get “degraded” to GL_RGBA8.
Also, I like to ask, if it is possible to create FBO´s with mixed texture-formats (as long as the bit-depth is identical). This question already has been asked recently but was not fully answered.
[edit] I forgot to mention the hardware: GF7900GTX
Originally posted by skynet:
[b] Hello,
Is there any possibility to use GL_RGB10_A2 with FBO’s and render-to-texture?
I managed to create a (‘complete’) FBO with 3 attached textures (using GL_RGB10_A2) as internal format. But it looks like the textures get “degraded” to GL_RGBA8.
[edit] I forgot to mention the hardware: GF7900GTX [/b]
It depends on your hardware, a useful source of information is available on NVIDIA website.
It confirms what you’ve experienced : RGBA10_A2 is not natively supported on any NVIDIA hardware and is replaced by RGBA8.
I believe 10_10_10_2 is supported by ATI cards, but it may or may not actually be exposed in OpenGL drivers.
MRT with mixed texture formats will be very hardware dependent.
Section 4.4.4.2 of the FBO spec deals with the format issue.
On the one hand, it states:
- All images attached to the attachment points
COLOR_ATTACHMENT0_EXT through COLOR_ATTACHMENTn_EXT must have
the same internal format.
{ FRAMEBUFFER_INCOMPLETE_FORMATS_EXT }
And then further down the list it adds:
- The combination of internal formats of the attached
images does not violate an implementation-dependent set of
restrictions.
{ FRAMEBUFFER_UNSUPPORTED_EXT }
Now, framebuffer completeness is contingent upon all conditions being met, but this seems to me like an either/or proposition.
What’s the correct interpretation here?
Cheers
Yep, I allow RGBA16F and GL_RGB10_A2 for HDR.
RGBA16F works on SM3.0 hardware.
On SM2.0 hardware I request RGB10_A2, which is supported by radeon X1k series only. On other GPU’s I get RGBA8.
I use <0.0;4.0> color range, so I’m getting precision equivalent to RGB6 on hardware not supporting RGB10_A2.
In my opinion it’s ok to use RGB10_A2 everywhere. You get the same color range - just different precision.
I mainly tried RGB10_A2 in a deferred renderer because of the normals. They just don´t look good if you get close at RGBA8. Using RGBA16F for all buffers is a waste, but I don´get around it because of the precision needed for the normals.
I use <0.0;4.0> color range
Um, RGB10_A2 doesn’t work that way. It’s still a [0,1] range; it just has more color precision.
Flavious, those two conditions are not exclusive.
The first condition is that the internal format of all color attachments is identical. That means you can not mix i.e. RGBA8 and L16A16.
The second condition is there so that a driver can reject a framebuffer configuration for any reason. One example is attaching a 16 bit depth buffer and a 32 bit color buffer; some hardware (nvidia) can not deal with this. Another example is attaching a 3D texture slice; some hardware (again, nvidia) can not deal with this.
Originally posted by Korval:
Um, RGB10_A2 doesn’t work that way. It’s still a [0,1] range; it just has more color precision.
You can easily make it [0, 4] by multiplying with 0.25 before writing though and 4.0 after reading, which I assume he’s doing given his “RGB6” comment.
Yes Arekkusu, that seems like the most reasonable interpretation, if depth buffers or any other non-color targets are taken together (I should have reckoned that was the case).
Hmmm… I just noticed EXTX_framebuffer_mixed_formats in my extension string (GL 2.1.1, Forceware 101.41), but I don’t see anything in the registry about it yet. I imagine this will loosen things up a bit for the color targets.
Cheers
You can easily make it [0, 4] by multiplying with 0.25 before writing though and 4.0 after reading, which I assume he’s doing given his “RGB6” comment.
Yep. 0.25 it is. Texture is just a storage - it’s up to application to decide how values should be interpreted.
As for normals I’m affraid you have no alternative on GeForce 7. Partially because of inability to mix formats in FBO. There are lots of new formats on GeForce 8.
Try storing only 2 components of normal vector - you could put some extra information in remaining 2 components.