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 3 of 8 FirstFirst 12345 ... LastLast
Results 21 to 30 of 80

Thread: Separate sampler state from texture state

  1. #21
    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

    Copy texture data?? Why would that ever be required? You can change the texture's filtering mode/params after creation, you know...
    Just create the mipchain, and then set filtering the way you want it for the current material. It takes a few nanoseconds. You can even put only 1 mip in the rare cases, and set the max_level param - this way the texture will be valid for even gl_linear_mipmap_linear.

  2. #22
    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

    Quote Originally Posted by Alfonse Reinheart
    For example, texelFetch expects the texture coordinates to be integer pixel values, not normalized floating-point.
    Of course, you would also multiply texcoords via textureSize() there.

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

    Re: Separate sampler state from texture state

    You can change the texture's filtering mode/params after creation, you know...
    Yes. But that changes it for that texture. Thus it is not possible to bind the same texture with different filtering modes.

    Also, changing the filtering params involves state changes, which are not the best use of one's performance. Especially if that texture is being rendered with elsewhere.

  4. #24
    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

    >> Thus it is not possible to bind the same texture with different filtering modes.
    Completely agreed on. Though, I can't generally fanthom common-use patterns that can get broken the shader-way. Aniso+bilinear+nearest can easily coexist inside the shader. The unsupportable patterns are:
    - Per-axis different filtering // I don't see artists doing it
    - aniso+trilinear // why ever

    >> changing the filtering params involves state changes, which are not the best use of one's performance.
    IME, you'd be amazed how fast state changes are on modern cards and drivers.

    P.S. measured how fast: when I change filtering-modes on every bind-texture (300+ textures, a non-synthetic benchmark), the two calls to glTexParameteri(..,GL_TEXTURE_MIN/MAG_FILTER) take less than total of 57 cycles. That's 15 nano-seconds on my PC.

  5. #25
    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

    By the way, I'm only "opposing" it, so that we as a community discuss this to finest detail, and give everyone a chance to mention what patterns-of-use are really important to them; while filtering-out the patterns that can easily be made possible+performant with the already existing specs.
    I really like the current performance and caps, so risking to destabilize it a bit imho should be done only for a valid purpose. The reason should never be the premise of false progress, vague ideas and misinformation.

  6. #26
    Advanced Member Frequent Contributor
    Join Date
    May 2001
    Posts
    566

    Re: Separate sampler state from texture state

    First, GL objects are merely a way to organize and encapsulate states, and they have noting to do with how hardware works...

    Direct state access is nice to have feature, but this will further complicate the GL implementation if we have to do both direct and indirect things. thanks to deprecation mode.

  7. #27
    Junior Member Regular Contributor
    Join Date
    Jan 2004
    Location
    Czech Republic, EU
    Posts
    190

    Re: Separate sampler state from texture state

    Don't care about OpenGL implementations. It's IHVs' responsibility to hire experienced enough employees to take care of implementing drivers efficiently and robustly. All issues with OpenGL implementations are mostly due to poor testing. FWIW the ARB would not incorporate something into OpenGL that cannot be done easily. So far, even with plethora of extensions, all implementations can somewhat keep pace with the standard. Even the Mesa open source driver architecture is getting some of GL3.x features and others are being worked on (e.g. geometry shaders), all done just by a handful of people scattered around the world.
    (usually just hobbyist) OpenGL driver developer

  8. #28
    Super Moderator OpenGL Guru
    Join Date
    Feb 2000
    Location
    Montreal, Canada
    Posts
    4,264

    Re: Separate sampler state from texture state

    Why would someone need to change sampler state in a shader? What DX10 offers is great flexibility but I don't need it.

    I agree with what the OP posted because once someone needed to sample the same texture (it was a depth texture) twice in the same shader : 1 with COMPARE_MODE on and 2 with COMPARE_MODE as GL_NONE because he wanted the actual values.
    I don't remember what he intended to do with it.
    Seemed like a legit need.

    Even the Mesa open source driver architecture is getting some of GL3.x features and others are being worked on (e.g. geometry shaders), all done just by a handful of people scattered around the world.
    The features we ask for is simple but since something like nvidia's code or ati's code is so heavy, small changes become a big job. Yes I know, some nvidia guy came here and said he doesn't care and nvidia can handle just about anything we can throw at them.
    ------------------------------
    Sig: http://glhlib.sourceforge.net
    an open source GLU replacement library. Much more modern than GLU.
    float matrix[16], inverse_matrix[16];
    glhLoadIdentityf2(matrix);
    glhTranslatef2(matrix, 0.0, 0.0, 5.0);
    glhRotateAboutXf2(matrix, angleInRadians);
    glhScalef2(matrix, 1.0, 1.0, -1.0);
    glhQuickInvertMatrixf2(matrix, inverse_matrix);
    glUniformMatrix4fv(uniformLocation1, 1, FALSE, matrix);
    glUniformMatrix4fv(uniformLocation2, 1, FALSE, inverse_matrix);

  9. #29
    Junior Member Regular Contributor
    Join Date
    Jan 2004
    Location
    Czech Republic, EU
    Posts
    190

    Re: Separate sampler state from texture state

    However, we won't need a separate sampler state object if it's possible to do the same thing in a shader. In this case, deprecating the glTexParameter* functions is sufficient.
    (usually just hobbyist) OpenGL driver developer

  10. #30
    Advanced Member Frequent Contributor
    Join Date
    Feb 2006
    Location
    Sweden
    Posts
    744

    Re: Separate sampler state from texture state

    Quote Originally Posted by Ilian Dinev
    IME, you'd be amazed how fast state changes are on modern cards and drivers.
    The idea is to allow for per fragment sampler changes, there is a real benefit to be able to select aniso level or filtering method based on depth, importance, visibility, speed and where on the screen it is.

    Like if you where to add a post blur filter to a frame then would you need anything other than GL_NEAREST for objects that are blurred the most.

Posting Permissions

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