What ever happened to 16bit float pbuffers?

[vhammer]

OK I've been off doing other things for several years and I've dusted off some old shader code that processes 16bit per channel images using a pbuffer. As it turns I can not obtain a pbuffer setting the channel bits to anything other than 8?? Uhmm 7 or 8 years ago this was not an issue....

So what's the way to render to a 16bit (or even 32bit) per channel target these days?

WGL_FLOAT_COMPONENTS_NV, 1
WGL_RED_BITS_ARB, 16
WGL_GREEN_BITS_ARB, 16
WGL_BLUE_BITS_ARB, 16
WGL_ALPHA_BITS_ARB, 16

Thx,

Vhammer

[vhammer]

OK I guess FBO's are the way to go these days.

So can I do threaded data transfers to FBO's as is described with PBO's here:
http://developer.download.nvidia.com...-Transfers.pdf

[dukey]

The worst part about pbuffers is, the buffer is on a separate opengl context, which is less than ideal. Means you have to set up display list sharing or some other features to make it work. FBO's really are the way to go.

[vhammer]

Yes but with that you may be answering my followup question:
Perhaps since pbuffers have their own context they can run in a separate thread and you can do non-blocking transfers.... but if 16 & 32 bit per channel data formats are not supported for pbuffers then that would be a real shame as it's those formats we eat up the most transfer time.

The display list sharing is trivial it's just a parameter to wglCreateContextAttribsARB

I'll be playing around with this today to see if there is a way to do non blocking transfers with FBO's

[aqnuep]

Yes but with that you may be answering my followup question:
Perhaps since pbuffers have their own context they can run in a separate thread and you can do non-blocking transfers.... but if 16 & 32 bit per channel data formats are not supported for pbuffers then that would be a real shame as it's those formats we eat up the most transfer time.

If you have only a single GPU then your draw commands will be anyhow serialized more or less.
Also, most GL commands are non-blocking, and even most of those that are blocking by default (like TexImage, TexSubImage, etc.), if you use PBOs then you can make them non-blocking.

[vhammer]

[...]even most of those that are blocking by default (like TexImage, TexSubImage, etc.), if you use PBOs then you can make them non-blocking.

Yes that's what I'm after but where I'm stuck is how can I transfer my 16bit per channel float textures to a PBO (without losing precision) if the PBO only supports 8bit per channel?

[aqnuep]

Yes that's what I'm after but where I'm stuck is how can I transfer my 16bit per channel float textures to a PBO (without losing precision) if the PBO only supports 8bit per channel?

What? PBOs are simple buffer objects that can store raw (i.e. arbitrary) data. PBOs are not limited to any format, bits per channel or whatever. You can have the exact same possibilities like with regular, blocking Tex[Sub]Image calls.

I think you've misunderstood: PBO stands for pixel buffer objects, not pbuffers.

[vhammer]

I think you've misunderstood: PBO stands for pixel buffer objects, not pbuffers.

Ah... you are correct... that is exactly my misunderstanding! Thanks!!