Part of the Khronos Group
OpenGL.org

The Industry's Foundation for High Performance Graphics

from games to virtual reality, mobile phones to supercomputers

Page 2 of 8 FirstFirst 1234 ... LastLast
Results 11 to 20 of 80

Thread: Separate sampler state from texture state

  1. #11
    Member Regular Contributor
    Join Date
    Nov 2003
    Location
    Germany
    Posts
    293

    Re: Separate sampler state from texture state

    i think the thread starters suggestion is very cumbersome. why should i attach the sampler state to a texture before the use in the shader? this way it makes no sense to me to separate these states. just create a sampler state objects (i would like it in the shader too) and bind it to a uniform. then in the shader decide what sampler state to use and do something like this:

    Code :
    vec4 c = texture(_sampler, _sampler_state, tex_coord);

    whats the harm? flexibility!

    i am thinking about something like volume rendering pre- and post classification based on the _sampler_state uniform etc..

  2. #12
    Senior Member OpenGL Pro
    Join Date
    Sep 2004
    Location
    Prombaatu
    Posts
    1,386

    Re: Separate sampler state from texture state

    A clean separation of objects would be nice - a separation that allows for a flexible mix & match configuration from within the shader rather than at the outermost API level.

    Would also mirror the way things work in dx10 and I'd consider that a bonus going forward.

  3. #13
    Senior Member OpenGL Guru
    Join Date
    May 2009
    Posts
    4,948

    Re: Separate sampler state from texture state

    just create a sampler state objects (i would like it in the shader too) and bind it to a uniform. then in the shader decide what sampler state to use and do something like this:
    Whatever we suggest must be GL 3.x hardware compatible. So having the shader decide how to combine sampler state and textures is not allowed. The shader can statically associate sampler state, as this can just internally be implemented as a default sampler state object. But the ability to arbitrarily combine textures and sampler state in GLSL itself may not be feasible on 3.x hardware.

    All we really need is the ability to have sampler state objects and to bind them to sampler uniforms. There is no need to complicate this by having a separation of sampler states and texture bind points in the actual shader.

  4. #14
    Member Regular Contributor
    Join Date
    Mar 2001
    Posts
    469

    Re: Separate sampler state from texture state

    Well, DX10 supports it, so it would be reasonable to assume that there is hw support for it...

  5. #15
    Member Regular Contributor
    Join Date
    Oct 2006
    Posts
    353

    Re: Separate sampler state from texture state

    Well, DX10 supports it, so it would be reasonable to assume that there is hw support for it...
    I am not familiar with DX10, can you please give an example of how this works?

    For example, can you change the sampler state inside a branch?
    Code :
    vec4 texel;
    if (condition)
        texel = tex2d(texture, coordinates, sampler_state_foo);
    else
        texel = tex2d(texture, coordinates, sampler_state_bar);
    (Frankly, I cannot see how this could work on the hardware level).

    All we really need is the ability to have sampler state objects and to bind them to sampler uniforms. There is no need to complicate this by having a separation of sampler states and texture bind points in the actual shader.
    Absolutely agreed!
    [The Open Toolkit library: C# OpenGL 4.4, OpenGL ES 3.1, OpenAL 1.1 for Mono/.Net]

  6. #16
    Intern Contributor
    Join Date
    May 2007
    Location
    Germany
    Posts
    50

    Re: Separate sampler state from texture state

    Yes you can. The actual syntax for a sample operation is:

    DXGI_FORMAT Object.Sample( sampler_state S, floatx Location [, int Offset]);

    You can combine every sampler state object with every texture object that is defined as a shader variable.

    On the hardware level this is pretty easy to do. As hardware supports more logical textures and sampler states as there are physical units the shader code needs to tell this units what logical entity should be used. If you want to separate textures and samplers you need to move two logical ids instead of one.

  7. #17
    Super Moderator Frequent Contributor Groovounet's Avatar
    Join Date
    Jul 2004
    Posts
    935

    Re: Separate sampler state from texture state

    Quote Originally Posted by Stephen A
    Potential API:
    Code :
    // Preferred
    glSamplerParameter(GL_SAMPLER0, GL_SAMPLER_MAG_FILTER, ...);
    glSamplerTexture(GL_SAMPLER0, tex_id);
    glGetSamplerParameter(GL_SAMPLER0, ...);
     
    // following current bind-to-edit semantics (worse):
    glBindSampler(GL_SAMPLER0);
    glSamplerParameter(...);
    glSamplerTexture(tex_id);
    glGetSamplerParamater(GL_SAMPLER_MAG_FILTER, ...);
    glBindSampler(0);

    Alternatively, replace Sampler by TexUnit and SAMPLERi by the existing TEXTURE_UNITi tokens:
    Code :
    // Following current OpenGL naming conventions:
    glTexUnitParameter(GL_TEXTURE_UNIT0, GL_TEXTURE_MAG_FILTER, ...);
    glTexUnitTexture(GL_TEXTURE_UNIT0, tex_id);
    glGetTexUnitParameter(GL_TEXTURE_UNIT0, ...);
    I'm sorry to say that but I think that you just propose some syntax sugar ...

    The purpose of separated image and sampler is more flexibility and probably removing the MAX_TEXTURE < 32 limitation. It would allows to use several samplers per image or several images per sampler.

    I'm personally imagine a "sampler object", binds like uniforms replacing glUniformi ... No more TexUnit concept.

  8. #18
    Senior Member OpenGL Pro Ilian Dinev's Avatar
    Join Date
    Jan 2008
    Location
    Watford, UK
    Posts
    1,290

    Re: Separate sampler state from texture state

    Wait, doesn't the slew of texture-lookup GLSL functions already provide in-shader selectable filtering? texture() vs textureLod() vs texelFetch() . Or if you mean to provide a user-modifiable anisotropic-filtering value for a large range of textures, can't you just keep a vector of those textures and set the param accordingly.

  9. #19
    Member Regular Contributor
    Join Date
    Oct 2006
    Posts
    353

    Re: Separate sampler state from texture state

    Quote Originally Posted by Groovounet
    I'm sorry to say that but I think that you just propose some syntax sugar ...

    The purpose of separated image and sampler is more flexibility and probably removing the MAX_TEXTURE < 32 limitation. It would allows to use several samplers per image or several images per sampler.

    I'm personally imagine a "sampler object", binds like uniforms replacing glUniformi ... No more TexUnit concept.
    I agree 100%. The code in the OP was just meant as a starting point for the discussion.

    Quote Originally Posted by Ilian Dinev
    Wait, doesn't the slew of texture-lookup GLSL functions already provide in-shader selectable filtering? texture() vs textureLod() vs texelFetch() . Or if you mean to provide a user-modifiable anisotropic-filtering value for a large range of textures, can't you just keep a vector of those textures and set the param accordingly.
    Yes you can, but this workaround wastes texture memory and is far from ideal. Why copy texture data just to change sampling modes?
    [The Open Toolkit library: C# OpenGL 4.4, OpenGL ES 3.1, OpenAL 1.1 for Mono/.Net]

  10. #20
    Senior Member OpenGL Guru
    Join Date
    May 2009
    Posts
    4,948

    Re: Separate sampler state from texture state

    As an alternative, if sampler objects are just too different for OpenGL, you could have the ability to build a texture object from another texture object. They would share certain information (the texture data itself, internal format, etc), but they would have their own instance data (sampler state).

    Wait, doesn't the slew of texture-lookup GLSL functions already provide in-shader selectable filtering? texture() vs textureLod() vs texelFetch()
    These do not change the filtering alone. These are different functions with different behaviors. For example, texelFetch expects the texture coordinates to be integer pixel values, not normalized floating-point.

Posting Permissions

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