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 10 of 30

Thread: sampler-Variables in Uniform-Blocks

Hybrid View

  1. #1
    Junior Member Regular Contributor
    Join Date
    Nov 2012
    Location
    Bremen, Germany
    Posts
    167

    sampler-Variables in Uniform-Blocks

    I think sampler-variables should be includeable into uniform-blocks/buffers and be mirrored to a C-datatype.
    As things are now sampler-variables require special handling and cannot be set in bulk along with other uniforms.

  2. #2
    Advanced Member Frequent Contributor
    Join Date
    Apr 2009
    Posts
    600
    This has been hashed upon before by the way (but I do not have the link ready).

    There are multiple issues:
    • GLSL samplers embody two things: source of texture data and how to filter from it (nearest, linear, mipmapping, anisotropic, etc)
    • Samples are opaque things, and to place them into a uniform buffer object requires they have a well defined (and cross-platform) size.


    Those issues together make it dicey. However there is this: http://www.opengl.org/registry/specs...ss_texture.txt which is an NVIDIA extension only. In that extension, a sampler variable in GLSL is viewed as a 64-bit handles, and are even construct-able from 64 unsigned ints in GLSL. That extension provides getting (and making resident first is required) such a 64-bit value to feed to GLSL uniforms from a texture or a texture-sampler pair.

    But that extension is NVIDIA only, and NVIDIA Kepler at that. I think it is great and a natural evolution to NVIDIA's extension GL_NV_shader_buffer_load (which is from GeForce 8 series, a GL3/DX10 part). We still have not seen an analogue of GL_NV_shader_buffer_load in GL-core, and I do not think we will because it, analogous to GL_NV_bindless_texture, assumes that a location into a buffer object can be encoded by a 64-bit value.

    They are great extensions though, if you can make NVIDIA optimized path, or are on NVIDIA only you cannot go wrong in using them.

  3. #3
    Junior Member Regular Contributor
    Join Date
    Nov 2012
    Location
    Bremen, Germany
    Posts
    167
    Oh come on. It cannot really be that difficult to implement it. Samplers can be set with uniform1i.If the data associated gets looked up when calling gluniform or when a texture-function gets called in the shader cannot make that alot difference.

  4. #4
    Senior Member OpenGL Guru
    Join Date
    May 2009
    Posts
    4,948
    Samplers can be set with uniform1i.
    You assume that this is doing nothing more than any other glUniform1i call: setting a number to a location.

    In all likelihood, the driver is doing far more under the hood than this. It recognizes that the uniform location you passed is for an opaque type, and then does special stuff for it.

    You should not really think of opaque types as uniforms at all; they're not memory locations or values in the same way as an `int` or `float`. They're special settings in a program that, thanks to 3D Labs's poor GLSL design, we talk to as though they were uniforms.

  5. #5
    Junior Member Regular Contributor
    Join Date
    Nov 2012
    Location
    Bremen, Germany
    Posts
    167
    I do not assume anything except that anything that gets done when setting a single sampler could as well be done when updating an uniform-block.

  6. #6
    Senior Member OpenGL Guru
    Join Date
    May 2009
    Posts
    4,948
    Except that this would be a lot harder. Updating a uniform block is intended to be nothing more than a memcpy. You load some data into a buffer object, and when it comes time for the shader to use it, it copies that data into shader local memory to read from.

    Opaque types are not part of "shader local memory." Even if they were, they would not be an integer as far as the hardware is concerned. They would be some hardware-specific type.

    In order for what you want to be possible, the driver can't simply memcpy data from the buffer into local memory. It must inspect certain bytes (namely, those belonging to opaque types) and change the other settings as appropriate. That's not going to be any faster than calling glUniform1i on the program, and probably will be slower, since it would have to be done via driver logic. So it would have to read the buffer data from the GPU to the CPU, process it, and upload it in the special registers or whatever that the shader needs.

    Personally, my feeling about opaque types is this: you should never be setting them more than once. Sampler X comes from texture unit Y, always and forever. Where available, I would use layout(binding = #) to set it's value and never touch it from code.

Posting Permissions

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