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 6 of 6

Thread: right way to check for hardware accelerated floating point blending

  1. #1
    Intern Contributor
    Join Date
    Oct 2004
    Location
    Germany
    Posts
    91

    right way to check for hardware accelerated floating point blending

    Hi,

    what's the right way to check if a given hardware can do accelerated 16 bit floating point blending?

    AFAIK there is no extension I could query to check for that, right? So, shouldn't glEnable(GL_BLEND) set an error if it isn't HW-supported? (or does that trigger a software fallback)?

    The nvidia 62xx don't support, the 66xx and 68xx do support as far as I know. Is it safe to check the GL_RENDERER string? I don't consider that a good option since that will fail for future unknown RENDERERS.

  2. #2
    Junior Member Newbie
    Join Date
    Mar 2005
    Posts
    4

    Re: right way to check for hardware accelerated floating point blending

    We had a thread on this a couple of weeks ago, I'm in the same position of having to do a renderer id check, since there doesn't seem to be a way to access this info. Here's the thread:

    Float blending thread

    Though the spec doesn't mention blending and bilinear, and so by omission they're required to work, the lack of any conformant hardware (even the 6800 only handles these in 16 bit float, not 32) makes me think this is a bug in the spec.

    I'd love to be able to do
    glGetIntegerv(GL_MAX_FLOAT_BILINEAR_DEPTH_EXT, &maxFloatBilinearDepth);
    glGetIntegerv(GL_MAX_FLOAT_BLENDING_DEPTH_EXT, &maxFloatBlendingDepth);

    Pete

  3. #3
    Senior Member OpenGL Guru Humus's Avatar
    Join Date
    Mar 2000
    Location
    Stockholm, Sweden
    Posts
    2,345

    Re: right way to check for hardware accelerated floating point blending

    Your only option is to make a small test on startup and see what performance you get. If it's not good enough, you can choose your non-blending path.

  4. #4
    Junior Member Regular Contributor
    Join Date
    Jun 2004
    Location
    Slovakia Europe
    Posts
    109

    Re: right way to check for hardware accelerated floating point blending

    another way is to dont use floating point blending, instead draw to texture(rectangle) and then read in on current position in the last pass and do the blending on your own in fragment program. If you want you can do full 32bit blending and I think it isnt slower than blending(or is?). This way you could do float blending on NV3x HW.

  5. #5
    Intern Contributor
    Join Date
    Oct 2004
    Location
    Germany
    Posts
    91

    Re: right way to check for hardware accelerated floating point blending

    Matt,

    I think your approach would be slower than native float16 blending. But I don't know how much. You'll always get an additional texture (the last pass output) as input to your shader that has to be read (otherwise the framebuffer has to be read, so that's not really a disadvantage). But if you render to float32 targets you'll cause double the bandwidth than rendering to float16 target framebuffers even without blending.

    Did anybody do detailed benchmarks? It would be very interesting how much the difference is.

  6. #6
    Junior Member Regular Contributor
    Join Date
    Jun 2004
    Location
    Slovakia Europe
    Posts
    109

    Re: right way to check for hardware accelerated floating point blending

    mlb,
    A few day before I worked on a HDR rendering of scene to float16 buffer on GF FX HW. I made it through FBO, rectangle textures and so on. One disadvantage of float buffers I think is the restriction with using shader instead a very simple ambient pass. In my program I had a three lights with full ambient, diffuse, specular and attenuation withch isnt so fast with normal rendering; with float16 buffer without the last tonemaping was about 25% slower. The blending is ofcourse slower, when you make full 32bit blending instead of 16bit. Someone on this board posted that the blending operation is computed in memory controler, which can be true. I do it instead in fragment program which costs extra performance.

Posting Permissions

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