PDA

View Full Version : FBO's and floating point



Ananth
12-25-2006, 01:29 AM
Hello,
I'm a longtime OpenGL developer, and I just started using FBO's in my application framework.

I am having trouble creating a framebuffer object with a floating point texture attachment. I'm using an x1800 Mobility Radeon on my laptop, and C# with the Tao bindings.

Here's what I use to create a dummy texture to attach to the framebuffer at Gl.GL_COLOR_ATTACHMENT0_EXT

Gl.glTexImage2D(Gl.GL_TEXTURE_2D, 0, Gl.GL_RGBA_FLOAT16_ATI, Width, Height, 0, Gl.GL_RGBA, Gl.GL_FLOAT, dummyData);

The next line, which is

Gl.glGenerateMipmapEXT(Gl.GL_TEXTURE_2D);

fails, however. Cant I generate mipmaps automatically for this (as mentioned below, this works fine for all non-floating point formats)? If I comment this out, the FBO always returns

Gl.GL_FRAMEBUFFER_INCOMPLETE_ATTACHMENTS_EXT

However, ALL of the above code works PERFECTLY for non-floating point formats. What am I doing wrong? Please help.

Thanks in advance

Zengar
12-26-2006, 06:33 AM
ATI has currently no support for floating-point filtering or blending, therefore you can't use mipmapped textures effectively. I guess the mipmap creation for such textures is simply not implemented (It should be :-/).

k_szczech
12-27-2006, 12:04 AM
I'm using an x1800

ATI has currently no support for floating-point filtering or blendingAre you sure X1k series don't support this?
Radeon X didn't, but I thought Radeon X1 series support FLOAT16 filtering/blending. I remember there was something mentioned in description of "Toy shop" demo, that instead of using floating-point they used RGB10A2 to be more memory-efficient. That would suggest they could use FLOAT16 if they chose so.


above code works PERFECTLY for non-floating point formatsThat excludes my suspicions about NPOT+mipmaps.

Matt Zamborsky
12-27-2006, 02:49 AM
only blending is supported. you must do your own filtering in pixel shader.
But I am not realy sure if the blending is supported in OpenGL, it can be the same as antialiasing of floating point buffer and that is supported only in DX.

Zengar
12-27-2006, 03:55 AM
Aye, you are right, X1k supports fp16 blending. Sorry for missinformation :-/ Still, there is no filtering.

Ananth
12-27-2006, 05:22 AM
Thanks for the replies, but if I use a floating point pbuffer with the pbuffer attribs of WGL_PIXEL_TYPE_ARB set to WGL_TYPE_RGBA_FLOAT_ATI, GL_SGIS_generate_mipmap works just fine, and I am able to mipmap, filter and sample the floating point buffers just fine...how is this possible? The hardware surely supports it. Just not for FBO's? Weird.

Also, none of the buffers I am creating are NPOT.

-Ananth

yooyo
12-27-2006, 08:33 AM
From http://www.beyond3d.com/reviews/ati/r520/index.php?p=03
Last paragraph:


Texture processing is achieved in a similar fashion to ATI's previous parts. Although the earlier pipeline diagram indicates a texture sampler array, all the the texture units are not re-allocatable to different pipelines, instead 4 are dedicated to each of the quads. At present ATI see the primary use of float texture sampling as being for lookup data, which only requires point sampling, and so at present haven't put floating point texture filtering in place, instead relying on filtering in the shader if required - at present the developer has to code this, however if they have a demand for it they may roll it up into the driver. The texture address processors can now address texture sizes up to 4096x4096. The texture pipeline still handles S3TC/DXTC and 3Dc normal map compression, although this gets an upgrade to 3Dc+ as it is now able to support single channel textures at a 2:1 compression ratio which can be used on things such as luminance maps, shadow maps, material properties and HDR textures. Finally the texture samplers can handle a new, angle invariant Anisotropic Filter, which we will take a closer look at later.
So... seems that ATI "roll in driver" fp filtering only on pbuffers, but not in FBO.
Humus... any comments?