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: Bitwise Logic texture lookup with filtering

  1. #1
    Junior Member Regular Contributor
    Join Date
    Mar 2009
    Location
    California
    Posts
    190

    Bitwise Logic texture lookup with filtering

    It would be nice if we could do bitwise logical texture lookups in a fragment shader. This would be useful for terrain. Most terrain algorithms store four terrain layers in the channels of an RGBA texture, so you're using 8 bytes per pixel. If each byte was a bitwise value, you could store 32 texture layers in an RGBA texture, instead of just 4. Each pixel would just have a "true" or "false" value for each terrain layer, but that's a tradeoff I would be happy making given the memory savings.

    Code :
    //Check if texture contains flag '8':
    float alpha = textureAnd(texture0,texcoords,8);

    When using linear filtering, it would return a value between 0.0 and 1.0, depending on what the results from the closest pixels were. (I tried doing this in a fragment shader with my own logic but it was too slow to be practical.)

  2. #2
    Senior Member OpenGL Guru
    Join Date
    May 2009
    Posts
    4,948
    Each pixel would just have a "true" or "false" value for each terrain layer, but that's a tradeoff I would be happy making given the memory savings.
    Um... how? If you're using these to blend between different textures to produce an appropriate color, I fail to see how a boolean value is an acceptable value for this process. Generally, people want subtle gradations between different layers, not hard on/off boundaries.

    I tried doing this in a fragment shader with my own logic but it was too slow to be practical.
    1: That rather depends on your hardware. And how you implemented it. Did you properly use `textureGather` when doing your filtering?

    2: Why do you think that a hardware implementation will be any faster? Especially since that probably no existing hardware fetching and filtering logic currently can do it. Indeed, nowadays a lot of the texture filtering logic is handled by shaders.

  3. #3
    Senior Member OpenGL Pro
    Join Date
    Apr 2010
    Location
    Germany
    Posts
    1,128
    I would be happy making given the memory savings.
    Often you cannot ask for speed and memory savings at the same time. You can already do bitwise logic in the shader and I'm with Alfonse on this, there is no guarantee that a hardware implementation will be faster.

    What are you doing in your shader? Also, looking outdoors, when do you ever have up to 32 different kinds of matter in one place? And what about compressed layers? Did you check that and compare the decompression overhead to your bitwise logic? Also, what are your target plaforms? Do you have a tiling terrain algorithm or just one big chunk? Did you have a look at the assembly code generated by, at least, AMD's and NVIDIA's compilers?

    There are a lot of places to look to and optimize before introducing a new hardware and language feature.

  4. #4
    Junior Member Regular Contributor
    Join Date
    Mar 2009
    Location
    California
    Posts
    190
    I've tried this with just linear filtering between "on" and "off" values and the results look good. The feature reminded me of Shadow2D lookups.

  5. #5
    Senior Member OpenGL Pro
    Join Date
    Apr 2010
    Location
    Germany
    Posts
    1,128
    [quite]The feature reminded me of Shadow2D lookups.[/quote]

    You mean the free 4-tap PCF?

  6. #6
    Junior Member Regular Contributor
    Join Date
    Mar 2009
    Location
    California
    Posts
    190
    Yes, the texture compare function is another kind of logic with linear filtering.

Posting Permissions

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