floating point pbuffer problem, ATI specific

OpenGL OpenGL: Advanced Coding
#1

Hello,
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 ?
Thanks,

#2

Humus or anyone else from ATI, any thought on this problem ?

#3

I would have liked to make a suggestion but since I’m not Humus neither form ATI… :smiley:

#4

Use the GL_FRAMEBUFFER_EXT, it replaces completely to old PBuffer. See old topics in this forum about the “render to texture”.

#5

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 :wink:

#6

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.

#7

Thanks for these answers !

#8

I’ve filed a bug report on this issue. Indeed R32F was interpreted as RGBA8 and RG32F as RGBA16.