View Full Version : floating point pbuffer problem, ATI specific

05-23-2006, 06:40 AM
I have met a strange problem, which seems specific to ATI hardware.

My config is X800 PRO/GTO, Catalyst 6.4.

I create a pbuffer, WGL_TYPE_RGBA_FLOAT_ATI, using only 32 bits in WGL_RED_BITS_ARB (hence, I get pixel format no 70: OGL, 32 bits R, 24+8 z/s, pbuffer, swap undef, ICD).

I simply clear the buffer with a float value and when I read it back using a glReadPixels, I don't get that value: I get a strange interpolation between 0.5f and 2.0f, otherwise I get a black screen (same result if I go through a render texture and then display it).

If I create the pbuffer using 32 bits per component (pixel format no 66: OGL, 32 RGBA, 24+8s, pbuffer, swap undef, ICD), I get the correct floating point values reading back pixels.

The floating point buffer operations work on NV hardware, using WGL_FLOAT_COMPONENTS_NV. So, I'm wondering whether there's something that I missed specifically for that buffer or not, or may this be a driver bug ?

Anyone an idea ?

05-28-2006, 03:29 PM
Humus or anyone else from ATI, any thought on this problem ?

05-28-2006, 04:09 PM
I would have liked to make a suggestion but since I'm not Humus neither form ATI... :D

05-30-2006, 09:08 AM
Use the GL_FRAMEBUFFER_EXT, it replaces completely to old PBuffer. See old topics in this forum about the "render to texture".

Jens Scheddin
06-01-2006, 05:49 AM
Doe's ATI support floating point buffers with only one channel? I don't think so.
Haven't take a look at pbuffers for a long time, so feel free to prove me wrong ;)

06-01-2006, 08:15 AM
I didn't think we did either, but now that I tested I see that we apparently do, however, as CoinCoin noticed, it's not working properly. I haven't nailed down what's really going on here, but it appears that some part of the driver is treating the R32F asn RGBA8. I'll let you know when I know more, there's been a lot of work recently.

06-03-2006, 08:29 AM
Thanks for these answers !

06-09-2006, 03:29 PM
I've filed a bug report on this issue. Indeed R32F was interpreted as RGBA8 and RG32F as RGBA16.