Part of the Khronos Group
OpenGL.org

The Industry's Foundation for High Performance Graphics

from games to virtual reality, mobile phones to supercomputers

Results 1 to 8 of 8

Thread: What ever happened to 16bit float pbuffers?

  1. #1
    Junior Member Newbie
    Join Date
    Jun 2012
    Posts
    14

    What ever happened to 16bit float pbuffers?

    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

  2. #2
    Junior Member Newbie
    Join Date
    Jun 2012
    Posts
    14
    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

  3. #3
    Member Regular Contributor
    Join Date
    Dec 2007
    Posts
    251
    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.

  4. #4
    Junior Member Newbie
    Join Date
    Jun 2012
    Posts
    14
    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

  5. #5
    Advanced Member Frequent Contributor
    Join Date
    Dec 2007
    Location
    Hungary
    Posts
    985
    Quote Originally Posted by vhammer View Post
    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.
    Disclaimer: This is my personal profile. Whatever I write here is my personal opinion and none of my statements or speculations are anyhow related to my employer and as such should not be treated as accurate or valid and in no case should those be considered to represent the opinions of my employer.
    Technical Blog: http://www.rastergrid.com/blog/

  6. #6
    Junior Member Newbie
    Join Date
    Jun 2012
    Posts
    14
    Quote Originally Posted by aqnuep View Post
    [...]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?

  7. #7
    Advanced Member Frequent Contributor
    Join Date
    Dec 2007
    Location
    Hungary
    Posts
    985
    Quote Originally Posted by vhammer View Post
    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.
    Disclaimer: This is my personal profile. Whatever I write here is my personal opinion and none of my statements or speculations are anyhow related to my employer and as such should not be treated as accurate or valid and in no case should those be considered to represent the opinions of my employer.
    Technical Blog: http://www.rastergrid.com/blog/

  8. #8
    Junior Member Newbie
    Join Date
    Jun 2012
    Posts
    14
    Quote Originally Posted by aqnuep View Post
    I think you've misunderstood: PBO stands for pixel buffer objects, not pbuffers.
    Ah... you are correct... that is exactly my misunderstanding! Thanks!!

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •