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 8 of 8 FirstFirst ... 678
Results 71 to 80 of 80

Thread: Separate sampler state from texture state

  1. #71
    Junior Member Regular Contributor
    Join Date
    Nov 2009
    Location
    French
    Posts
    117

    Re: Separate sampler state from texture state

    Another way is to always use GL_NEAREST, get the 4 surrounding texels at (u,v), (u+1,v) , (u,v+1), (u+1,v+1) in integers positions, and compute ourself the various interpolations that we want into the vertex shader.
    (cf. emulate into the vertex shader a part of what make the texture unit in hardware)

    I don't think that this is really the better way but with this we haven't the explosion of the number of textures/states when we want differents interpolations with the same texture/data ...


    @+
    Yannoo

    @+
    Yannoo

  2. #72
    Member Regular Contributor
    Join Date
    Apr 2006
    Location
    Irvine CA
    Posts
    299

    Re: Separate sampler state from texture state

    Implemented.

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

    Re: Separate sampler state from texture state

    "Implemented" is perhaps not the correct word to use. At least, until we can get drivers that actually implement it

  4. #74
    Member Regular Contributor
    Join Date
    Oct 2006
    Posts
    352

    Re: Separate sampler state from texture state

    Awesome!
    [The Open Toolkit library: C# OpenGL 4.4, OpenGL ES 3.1, OpenAL 1.1 for Mono/.Net]

  5. #75
    Junior Member Regular Contributor
    Join Date
    Nov 2009
    Location
    French
    Posts
    117

    Re: Separate sampler state from texture state

    A lot of thanks for this precision Alfonse

    I have found a method where the YCbCr 4:2:0 format is converted to a format that is very more friendly for the hardware interpolation units.

    I place the Cb plane in the bottom left and the Cr plane in the bottom right (and not each after the other at the bottom as on the standard 4:2:0 format)

    This have totaly resolved my problem about even/odd lines into Cb/Cr planes where the line size in the Cb and Cr planes is only the half of the Y line size.

    With this, I haven't now the need of separates samplers states from texture state because alls planes can now use exactely the same sampler that the others, so only one texture state has to be handled.
    => "there are no problems, there are only solutions"

    I'm really happy because this give me a more short and speed vertex shader (cf. the u1/u2 and v1/v2 interpolations are now really make by the hardware texture unit and not by interpolations into the vertex shader as before).

    So now, I can begin to look/hope about using the textureLod fonctionnality with this new format

    But this only resolve my little problem with the standard video YCbCr 4:2:0 format ... not the very more general/generic problem of 'Separate sampler state from texture state'

    Can something like texture2Dext(texID, texpos, typeofsample) to be added (if this isn't already make of course) into vertex shader specs and implemented into drivers ?
    (where typeofsample is 0 or negative, the sampler state stored into the texture state can be used for to maintain a compatibility with the original texture2D call)


    @+
    Yannoo
    @+
    Yannoo

  6. #76
    Senior Member OpenGL Guru
    Join Date
    May 2009
    Posts
    4,948

    Re: Separate sampler state from texture state

    I checked the Wikipedia entry on the HD-5000 line and the NVIDIA Fermi (NVIDIA's DX11 part). Both of them decided to dump hardware texture filtering. That's right; both of these cards convert a "texture" instruction into a textureGather call followed by software texture filtering based on the texture's filtering mode.

    That suggests that texture filtering state belongs more in the shader than anywhere else. And that using a program with one sampler object in one place and another sampler object in another place is going to require at least some patching of the program object. Hopefully this is fast, but I wonder if this wasn't a missed opportunity.

    Can something like texture2Dext(texID, texpos, typeofsample) to be added (if this isn't already make of course) into vertex shader specs and implemented into drivers ?
    (where typeofsample is 0 or negative, the sampler state stored into the texture state can be used for to maintain a compatibility with the original texture2D call)
    And what does the "0 or negative" value of "typeofsample" mean?

  7. #77
    Member Regular Contributor
    Join Date
    Apr 2006
    Location
    Irvine CA
    Posts
    299

    Re: Separate sampler state from texture state

    Quote Originally Posted by Alfonse Reinheart
    I checked the Wikipedia entry on the HD-5000 line and the NVIDIA Fermi (NVIDIA's DX11 part). Both of them decided to dump hardware texture filtering. That's right; both of these cards convert a "texture" instruction into a textureGather call followed by software texture filtering based on the texture's filtering mode.

    That suggests that texture filtering state belongs more in the shader than anywhere else. And that using a program with one sampler object in one place and another sampler object in another place is going to require at least some patching of the program object. Hopefully this is fast, but I wonder if this wasn't a missed opportunity.
    If the ability to express sampling setup separately from texture objects was a capability being delivered only for those class of parts, you might have a point. This turns out not to be the case.

  8. #78
    Junior Member Regular Contributor
    Join Date
    Nov 2009
    Location
    French
    Posts
    117

    Re: Separate sampler state from texture state

    The null or negative value of typeofsample indicate that we have to use the sampler type stored into the texture state.

    => with this, the compatibility with the actual texture2D call is respected if we want to use the texture sampler state by default ...

    PS : if all is make into shaders, how futures OpenGL's versions can handle the compatibility and orthogonality with previous OpenGL versions ???

    @+
    Yannoo
    @+
    Yannoo

  9. #79
    Senior Member OpenGL Guru
    Join Date
    May 2009
    Posts
    4,948

    Re: Separate sampler state from texture state

    The null or negative value of typeofsample indicate that we have to use the sampler type stored into the texture state.
    So what is it when it is not zero or negative?

  10. #80
    Junior Member Regular Contributor
    Join Date
    Nov 2009
    Location
    French
    Posts
    117

    Re: Separate sampler state from texture state

    GL_LINEAR or GL_NEAREST of course

    But now I see that for mipmapping, we have another typeofsample parameter to use for the magnification (cf GL_*_MIPMAP_*) , so this form seem me more usable/clear :

    texture2Dext(texID, texpos, minification, magnification)

    But ok, I see already a lot of people to say "why to make something simple when this can be complex ?"

    GL_CENTROID, ripmaps and others can perhaps to be added too ...

    And with this, texture units aren't limited to work in a serial manner, they can really work in //
    @+
    Yannoo

Posting Permissions

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