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 7 of 8 FirstFirst ... 5678 LastLast
Results 61 to 70 of 80

Thread: Separate sampler state from texture state

  1. #61
    Senior Member OpenGL Guru
    Join Date
    May 2009
    Posts
    4,948

    Re: Separate sampler state from texture state

    And I want only use what can already make the hardware when it decode an MPEG video streams into a window ... but want that the decoding is directly make into one OpenGL texture and not in a window ... it's really as difficult as this to understand ???
    But this is already doable. Just write the shader code for it. That's the whole point of having shaders to begin with; you can do almost anything you want with them. It means that you aren't limited by the capabilities of the hardware.

    There is no reason for them to add hardcoded features for things that you can do with shaders unless they are generally useful and are performance bottlenecks for most users.

  2. #62
    Junior Member Regular Contributor
    Join Date
    Nov 2009
    Location
    French
    Posts
    117

    Re: Separate sampler state from texture state

    I'm have begin with OpenGL a lot of years before this century with Linux and the first 3Dfx Vodoo card but this is only since the last year that I have begin to handle video textures in OpenGL shaders.
    (my first video projet was a .FLI reader in the last century with a 386 and some asm)

    OpenGL shaders are only standardised in 2004 (but this was very limited for a long time and with a lot of incompatibles versions)
    => this is relatively new compared to the opengl story that really begin in 1992

    Certainly because a day a guy have say something like "why not to have shaders such as RenderMan but in OpenGL ?"

    You can force the world to reuse the good old abacus if you want, but personnaly I prefer use a calculator for to make more speedly exactely the same thing and spend time after for to explain how to use this calculator to a lot of persons because I have win a lot of time with the use of this calculator
    (cf. loose some time before for to win a lot of time after and to have the possibility to share it)

    This remember me a personnal story about f(x) fonctions where I was asses often the only guy in the school class to have systematicaly the goods curves
    => I have spend two days for to make a program that display and print the f(x) fonction that I want/invent
    ==> this was amortised in only some weeks and this has really render service to me for some years
    (I was the first in my school class that can explain to others what is really the sinus and cosinus fonctions for example, a long time before the teatcher enter the subject in class of course ... or teach mathematics to persons that really don't like this before, but with the visual and graphics support they suddently begin to like it )


    @+
    Yannoo
    @+
    Yannoo

  3. #63
    Junior Member Regular Contributor
    Join Date
    Nov 2009
    Location
    French
    Posts
    117

    Re: Separate sampler state from texture state

    "Just write the shader code for it"

    In this case, why you don't simply send the shader code in this thread if this is as simple as this ?

    Personnaly, I have already send my YCbCr 4:2:0 shader that use only one texture handle since somes weeks ...

    In case of someone have a doubt, it's here :

    fragment shader :

    uniform sampler2D tex;

    void main(void)
    {
    float nx, ny, r, g, b, y, u, v;
    float u1,u2,v1,v2;

    nx = gl_TexCoord[0].x;
    ny = gl_TexCoord[0].y;

    y = texture2D(tex, vec2( (nx), (ny)*(4.0/6.0) )).r;
    u1 = texture2D(tex, vec2( (nx/2.0), (ny+4.0)/6.0 )).r;
    u2 = texture2D(tex, vec2( (nx/2.0)+0.5, (ny+4.0)/6.0 )).r;
    v1 = texture2D(tex, vec2( (nx/2.0), (ny+5.0)/6.0 )).r;
    v2 = texture2D(tex, vec2( (nx/2.0)+0.5, (ny+5.0)/6.0 )).r;

    y = 1.1643 * (y - 0.0625);
    u = (u1+u2)/2.0 - 0.5;
    v = (v1+v2)/2.0 - 0.5;

    r = y + 1.5958 * v;
    g = y - 0.39173 * u - 0.8129 * v;
    b = y + 2.017 * u;

    gl_FragColor=vec4(b,g,r,1.0);
    }

    vertex shader :

    void main()
    {
    gl_FrontColor = gl_Color;
    gl_TexCoord[0] = gl_MultiTexCoord0;
    gl_Position = ftransform();
    }

    and the texture binding :

    glBindTexture(GL_TEXTURE_2D, texID);
    glTexImage2D(GL_TEXTURE_2D, 0, GL_LUMINANCE, w, (h*3/2), 0, GL_LUMINANCE, GL_UNSIGNED_BYTE, data);


    => it's your turn now to send the MPEG decoder shaders and the glTexImage2D call because it's for you as simple as this


    @+
    Yannoo
    @+
    Yannoo

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

    Re: Separate sampler state from texture state

    OK, seriously: enough with your nonsense. You're derailing the actual topic of this thread and trying to hijack it into talking about stuff that interests and matters to you.

    If you want to talk about MPEG decompression or whatever, please do it in another thread. This thread is about separating sampler state, not allowing you to bind more textures than the hardware supports, nor alternate binding schemes to associate textures with programs, nor MPEG decompression in hardware. Stay on topic or stop posting in this thread.

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

    Re: Separate sampler state from texture state

    It's you that are derailling here ...

    What I want is to have SEPARATE SAMPLER STATE FOR TEXTURE STATE for the y, u et v sampling :


    y = texture2D(tex, vec2( (nx), (ny)*(4.0/6.0) )).r;
    u1 = texture2D(tex, vec2( (nx/2.0), (ny+4.0)/6.0 )).r;
    u2 = texture2D(tex, vec2( (nx/2.0)+0.5, (ny+4.0)/6.0 )).r;
    v1 = texture2D(tex, vec2( (nx/2.0), (ny+5.0)/6.0 )).r;
    v2 = texture2D(tex, vec2( (nx/2.0)+0.5, (ny+5.0)/6.0 )).r;

    For to can handle something like DXT or MPEG decompression directly in this fragment shader ...

    Now it's clear, you are a professional .... but a professionnal troll
    (147 post in the last 30 day => no, you are not a troll ...)

    The top troll from alls forums in www.opengl.org :

    Alfonse Reinheart 147
    ZbuffeR 101
    Dark Photon 60
    marshats 44
    Ilian Dinev 43
    Brolingstanz 43
    Stephen A 41
    Iulian B 38
    Yann LE PETITCORPS 31
    Kip Warner 28
    Aleksandar 25
    skynet 25
    Pierre 23
    Abdallah DIB 23
    devdept 21
    DarkShadow44 20
    Irena 20
    strattonbrazil 17
    Vadim 17
    AGL_Music 16

    Personnaly, I write in this forum about "Suggestions for the next release of OpenGL", certainly not for to be the best troll

    @+
    Yannoo
    @+
    Yannoo

  6. #66
    Junior Member Regular Contributor
    Join Date
    Nov 2009
    Location
    French
    Posts
    117

    Re: Separate sampler state from texture state

    Note that one interpolation is already make here :

    u = (u1+u2)/2.0 - 0.5;
    v = (v1+v2)/2.0 - 0.5;

    The -0.5 is for handle the 0..255 to -128..127 YCbCr->YUV conversion

    I want to interpole the y, u and v parts into 2, 4 or 8 differents intensities for each component and to have the possibility to have the preindexed data already in the texture input in a sort of DXT 4x4 blocs
    (that mix colors that have to be interpoladed and indices that cannot be interpoled in the same bloc ...)

    A DXT1 bloc is for 4x4 pixels :

    RGB1 (a RGB 5:6:5 16 bitscolor) => have to be interpolated
    RGB2 (a RGB 5:6:5 16 bits color) => have to be interpolated
    indices (4 bytes of 4x2 bits = 16 indices of 2 bits) => cannot be interpolated

    => it's here that is the problem of "Separate sampler state from texture state" ...

    My idea is to work directly in one YCbCr space (cf. YCbCr 6:5:5) and not in one RGB space (cf. RGB 5:6:5) and to interpole RGB0 and RGB1 from an IPBB chunk
    (for a have a very better compression ratio that the basic DXT1 method by divide the size of the DXT bloc by two)

    For me, it's something like a "mathematical explanation"
    => can you "troll more mathematically" please ???

    @+
    Yannoo
    @+
    Yannoo

  7. #67
    Senior Member OpenGL Guru
    Join Date
    May 2009
    Posts
    4,948

    Re: Separate sampler state from texture state

    => it's here that is the problem of "Separate sampler state from texture state" ...
    No, it isn't. Sampler state refers to things like GL_TEXTURE_MAG_FILTER, GL_TEXTURE_WRAP_S and such that are currently part of the texture object's state.

    What you're talking about is a new compression internal format. These are two completely different things.

    Now it's clear, you are a professional .... but a professionnal troll smile
    (147 post in the last 30 day => no, you are not a troll ...)
    Kindly take your bile elsewhere.

  8. #68
    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

    Now it's clear, you are a professional .... but a professionnal troll smile
    (147 post in the last 30 day => no, you are not a troll ...)
    If you bothered to check, those are 140 helpful pieces of advice to different users on a wide variety of subjects, and 7 attempts to correct your misunderstandings of how HW works. . Things like the "80 texture units" ^^'

    Find what the HW actually can do, use it smartly. It'll become obvious to you that future HW having specialized circuitry for MPEG/etc will probably not beat pure shader calcs in performance and usefulness.

  9. #69
    Advanced Member Frequent Contributor
    Join Date
    Apr 2003
    Posts
    666

    Re: Separate sampler state from texture state

    Just to get back on topic a bit...

    Would it be useful/possible/wise to include normalized/non-normalized sampling for integer textures into the sampler state, too? I imagine that this is indeed not a property of the image data, but how the hardware (sampler) is interpreting the data.

  10. #70
    Member Regular Contributor
    Join Date
    Aug 2008
    Posts
    456

    Re: Separate sampler state from texture state

    OpenCL has separate samplers + images, it's samplers use 3 "fields":

    normalized-mode: CLK_NORMALIZED_COORDS_{TRUE/FALSE}
    filter-mode: CLK_FILTER_{NEAREST/LINEAR}
    address-mode: CLK_ADDRESS_{REPEAT/CLAMP_TO_EDGE/CLAMP/NONE}

    They can then be declared in the CL program source, with:
    const sampler_t sampler1 =
    CLK_NORMALIZED_COORDS_TRUE | CLK_FILTER_LINEAR | CLK_ADDRESS_REPEAT

    Or created in the app + passed to kernel as an argument:

    cl_sampler newSampler;
    newSampler = clCreateSampler(context, CL_TRUE, CLK_ADDRESS_REPEAT, CLK_FILTER_LINEAR, &errCode);

    clSetKernelArg(kernel, 0, sizeof(newSampler), &newSampler);

    In the kernel, the image is read using:

    float4 color;
    color = read_imagef(image1, sampler1, (int2)(X,Y));

    This is pretty nice + hopefully something like this appears soon in OpenGL, I hope it doesn't restrict you to providing all the parameters to the creation function in the same way as clCreateSampler though, since there's no way to extend in future without changing clCreateSampler, could be better with a more flexible approach, such as propery name/value pairs:

    cl_sampler_properties properties[] = {CL_SAMPLER_FILTER_MODE, (cl_sampler_properties)CL_FILTER_LINEAR,
    CL_SAMPLER_NORMALIZED_COORDS,
    (cl_sampler_properties)CL_TRUE, 0 };

    // clCreateSampler could look like this instead:
    sampler1 = clCreateSampler(context, properties, &errCode);

    or allowing you to change the parameters later, eg. with an invented "clSetSamplerParameter" function:

    clSetSamplerParameter(sampler1, CL_SAMPLER_FILTER_MODE, CLK_FILTER_LINEAR);

Posting Permissions

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