Separate sampler state from texture state

[Alfonse Reinheart]

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.

[Yann LE PETITCORPS]

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

[Yann LE PETITCORPS]

"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

[Alfonse Reinheart]

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.

[Yann LE PETITCORPS]

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

[Yann LE PETITCORPS]

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

[Alfonse Reinheart]

=> 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.

[Ilian Dinev]

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.

[skynet]

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.

[Dan Bartlett]

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);