PDA

View Full Version : Separate sampler state from texture state



Stephen A
09-11-2009, 07:53 AM
An oft requested feature since OpenGL 2.1. Right now, OpenGL treats sampler state as part of the texture object. This is *not* how the hardware works and makes specific algorithms inefficient (those that require different sampling states for the same texture).

Potential API:


// 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:


// Following current OpenGL naming conventions:
glTexUnitParameter(GL_TEXTURE_UNIT0, GL_TEXTURE_MAG_FILTER, ...);
glTexUnitTexture(GL_TEXTURE_UNIT0, tex_id);
glGetTexUnitParameter(GL_TEXTURE_UNIT0, ...);


glActiveTexture and glTexParameter tokens that set sampler state will be deprecated.

Backwards compatibility can be maintained:
1. using a new version profile
2. specifying that glTexParameter will be ignored when the relevant texture is bound to a sampler with glSamplerTexture. Old applications (using glActiveTexture) will continue to use glTexParameter and ignore glSamplerParameter.

Questions:
1. "Sampler" or "TexUnit"? My personal preference is the latter, as it follows existing OpenGL naming conventions.

2. Use bind-to-edit semantics? ActiveTexture is not bind-to-edit, so it would be best to define the new API to *not* use bind-to-edit.

3. "TexUnitTexture" function - the name is ugly. We could reuse the ActiveTexture entry point but this is going to be nasty both for driver developers and users (backwards compatibility).

Other thoughts, questions, ideas? Any chance we will see something like this in OpenGL 3.3?

V-man
09-11-2009, 08:34 AM
This sounds reasonable.
glSamplerParameter(GL_SAMPLER0, GL_SAMPLER_MAG_FILTER, ...);

1. The name should be very different. This is a good thing.
2. no more bind to edit in the next API revision
3. or TextureImageUnit but Sampler sounds simpler.
4. What is the risk of this becoming obsolete? Will samplers become programmable one day? Will we have to do this instead one day?
loc=glGetUniformLocation(program, "MagFilter");
glUseProgram(X);
glUniform(loc, GL_LINEAR);

elFarto
09-11-2009, 10:21 AM
You should just need these 2 functions (plus some matching Get functions):

glUniformSamplerParameter{i,f,...}(GLint location, GLenum parameter, {GLint,GLfloat,...} value);

glUniformSamplerTexture(GLint location, GLint texture);

(where location is the result from glGetUniformLocation)

They've got ugly names, but they get the job done.

Regards
elFarto

Alfonse Reinheart
09-11-2009, 11:34 AM
Why not put these in the shader? Or at least optionally have these parameters be defined in the shader (external setting of params before link would override them)?

Stephen A
09-11-2009, 12:46 PM
This has been suggested before and met furious resistance by both IHVs and users... so no, defining sampler state in the shader is probably not an option. :)

Alfonse Reinheart
09-11-2009, 01:21 PM
If you are going to separate sampler state from textures, then there should be sampler objects that encapsulate that state. That way, you only need one function to set the sampler state on a uniform.

Jan
09-11-2009, 02:11 PM
"This has been suggested before and met furious resistance by both IHVs and users..."

What? I have never seen any IHV make a comment about that, at all, and i have not seen any user complain about the idea. I myself have suggested it several times and no one ever complained.

If there is any in/official statement from the ARB or an IHV about it, i would like to see.

Jan.

Brolingstanz
09-11-2009, 02:30 PM
If you are going to separate sampler state from textures, then there should be sampler objects that encapsulate that state. That way, you only need one function to set the sampler state on a uniform.

Have to agree. The original LP designs called for an (immutable) object along these lines, no? If you're going to change things - and we now have a deprecation mechanism in place to facilitate the emergence of new approaches - why not head in the general LP direction. Seems to me it's not too late to climb that peak (or the twin peaks of Kilimanjaro :-))...

Stephen A
09-11-2009, 02:36 PM
"This has been suggested before and met furious resistance by both IHVs and users..."

What? I have never seen any IHV make a comment about that, at all, and i have not seen any user complain about the idea. I myself have suggested it several times and no one ever complained.

If there is any in/official statement from the ARB or an IHV about it, i would like to see.

Jan.

I don't recall the name but I distinctly remember a member of the ARB saying that this feature was discussed and turned down. I'll post a link if I find the relevant statements.

Edit: either my search-fu or the search function of this forum sucks. No matter what keywords I specify, it returns about every single post from the "suggestions" and "items of importance" forums...

Jan
09-11-2009, 04:06 PM
Yeah, the search sucks, had the same problem several times. That is why i didn't even bother to search about this myself ;-)

Jan.

Chris Lux
09-11-2009, 05:44 PM
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:



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

Brolingstanz
09-11-2009, 05:57 PM
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.

Alfonse Reinheart
09-11-2009, 06:04 PM
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.

ScottManDeath
09-12-2009, 12:25 AM
Well, DX10 supports it, so it would be reasonable to assume that there is hw support for it...

Stephen A
09-12-2009, 04:00 AM
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?


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!

Demirug
09-12-2009, 04:49 AM
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.

Groovounet
09-12-2009, 10:26 AM
Potential API:


// 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:


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

Ilian Dinev
09-12-2009, 11:05 AM
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.

Stephen A
09-12-2009, 12:05 PM
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.


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?

Alfonse Reinheart
09-12-2009, 12:48 PM
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.

Ilian Dinev
09-12-2009, 12:51 PM
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.

Ilian Dinev
09-12-2009, 12:53 PM
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.

Alfonse Reinheart
09-12-2009, 12:55 PM
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.

Ilian Dinev
09-12-2009, 01:06 PM
>> 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.

Ilian Dinev
09-12-2009, 01:40 PM
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.

glfreak
09-14-2009, 11:37 AM
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. :)

Eosie
09-15-2009, 07:31 AM
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.

V-man
09-15-2009, 09:22 AM
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.

Eosie
09-15-2009, 10:15 AM
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.

zeoverlord
09-15-2009, 10:21 AM
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.

Alfonse Reinheart
09-15-2009, 11:30 AM
FWIW the ARB would not incorporate something into OpenGL that cannot be done easily.

GLSL. Nothing about this is easy.

Groovounet
09-16-2009, 05:53 AM
Need wise

Where I expect to have such feature being really great it's for depth of field and other blurry things!

Sharpe area: ANISO 16X
Blurred area: maybe down to nearest!

In a single pass, according how sharpe a fragment is supose to but, select in the fragment shader the right sample.

With transparency / fog, it could be great as well...
A scenario for example would be a terrain with parts underwater. The water is transparent but when it's depth enough we don't see the terrain anymore:
For terrain fragments over the water "plan" trilinear aniso 16x.
For terrain fragments under the water "plan" trilinear / bilinear.

For fog, the anisotropic filtering could be progressive.

"Programmable filtering" could be the future: texelFetch & textureQueryLOD would make is possible be still not as efficiently as fixed pipeline filtering. Plus it requires D10.1 level hardware when I guest a sampler object would works up to D3D9 level hardware. (GeForce 5 / Radeon 9***).

For reflexion/reflaction/mirrors/environment map it would be interesting to study the idea of having a single image and being able to switch between sampler.

One other big topic with sampler objects, it's texture alias. Being able to use different filtering for different part of a the texture would be nice even if I don't really know how this would should be done to be wise. But typically, a character texture with the hair, the skin, the cloth (the various material on the cloth!)

Well, and so on an so on!

API wise

Do you think guys that glUniformi(Uniform, 0) is really required for some reason? And why? When I see the binding slots of the uniform block API, I think that maybe it is ... alls.

Instead of sampler I will use "filter" because of GLSL "sampler".

Hop, just for fun: the API of GL_COMMINUTY_filter_object extension: :D

Following uniform block API it give us:


glBindFilter(0, FilterName)
glUniformFilter(ProgramName, Uniform, 0);


The filter object will include:
GL_TEXTURE_MIN_FILTER, GL_TEXTURE_MAG_FILTER, GL_TEXTURE_MIN_LOD, GL_TEXTURE_MAX_LOD, GL_TEXTURE_WRAP_S, GL_TEXTURE_WRAP_T, GL_TEXTURE_WRAP_R, GL_TEXTURE_BORDER_COLOR

And the following could stay exclusively in glTexParameter.
GL_TEXTURE_BASE_LEVEL, GL_TEXTURE_MAX_LEVEL, GL_TEXTURE_COMPARE_MODE, GL_TEXTURE_COMPARE_FUNC, GL_DEPTH_TEXTURE_MODE, or GL_GENERATE_MIPMAP.

This filter object may just be an "alternative" so that we could still use the glTexParameter way by default but also use custom samplers on top of that which would make the easier the feature integration and interaction with other feature. No change on the framebuffer object API or any feature using textures.

On OpenGL API side it could look like this:


void GenFilters(sizei n, uint *filters)
void DeleteFilters(sizei n, uint *filters)
void BindFilter(enum target, uint index, uint filter)
void UniformFilter(uint program, uint filterIndex, uint uniformFilterBinding)
void FilterParameterf(enum target, enum pname, float param)
void FilterParameteri(enum target, enum pname, int param)


with pname being:


GL_TEXTURE_MIN_FILTER, GL_TEXTURE_MAG_FILTER, GL_TEXTURE_MIN_LOD, GL_TEXTURE_MAX_LOD, GL_TEXTURE_WRAP_S, GL_TEXTURE_WRAP_T, GL_TEXTURE_WRAP_R, GL_TEXTURE_BORDER_COLOR.


On GLSL side it more complicated but still:

I'm actually not sure about weither of not the filter*Shadow are really making sens ... Actually, now I believe that it doesn't.

New types:


filter1D, filter2D, filter3D,
filter2DRect, filterCube
filter1DShadow, filter2DShadow, filter2DRectShadow, filterCubeShadow
filter1DArray, filter2DArray, filter1DArrayShadow, filter2DArrayShadow,


New functions:


gvec4 textureFilter (gsampler1D sampler, filter1D filter, float P [, float bias] )
gvec4 textureFilter (gsampler2D sampler, filter2D filter, vec2 P [, float bias] )
gvec4 textureFilter (gsampler3D sampler, filter3D filter, vec3 P [, float bias] )
gvec4 textureFilter (gsamplerCube sampler, filterCube filter, vec3 P [, float bias] )
float textureFilter (sampler1DShadow sampler, filter1DShadow filter, vec3 P [, float bias] )
float textureFilter (sampler2DShadow sampler, filter2DShadow filter, vec3 P [, float bias] )
float textureFilter (samplerCubeShadow sampler, filterCubeShadow filter, vec4 P [, float bias] )
gvec4 textureFilter (gsampler1DArray sampler, filter1DArray filter, vec2 P [, float bias] )
gvec4 textureFilter (gsampler2DArray sampler, filter2DArray filter, vec3 P [, float bias] )
float textureFilter (sampler1DArrayShadow sampler, filter1DArrayShadow filter, vec3 P [, float bias] )
float textureFilter (sampler2DArrayShadow sampler, filter2DArrayShadow filter, vec4 P)
gvec4 textureFilter (gsampler2DRect sampler, filter2DRect filter, vec2 P)
float textureFilter (sampler2DRectShadow sampler, filter2DRectShadow filter, vec3 P)
gvec4 textureFilterProj (gsampler1D sampler, filter1D filter, vec2 P [, float bias] )
gvec4 textureFilterProj (gsampler1D sampler, filter1D filter, vec4 P [, float bias] )
gvec4 textureFilterProj (gsampler2D sampler, filter2D filter, vec3 P [, float bias] )
gvec4 textureFilterProj (gsampler2D sampler, filter2D filter, vec4 P [, float bias] )
gvec4 textureFilterProj (gsampler3D sampler, filter3D filter, vec4 P [, float bias] )
float textureFilterProj (sampler1DShadow sampler, filter1DShadow filter, vec4 P [, float bias] )
float textureFilterProj (sampler2DShadow sampler, filter2DShadow filter, vec4 P [, float bias] )
gvec4 textureFilterProj (gsampler2DRect sampler, filterRect filter, vec3 P)
gvec4 textureFilterProj (gsampler2DRect sampler, filterRect filter, vec4 P)
float textureFilterProj (sampler2DRectShadow sampler, filter2DRectShadow filter, vec4 P)

gvec4 textureFilterLod (gsampler1D sampler, filter1D filter, float P, float lod)
gvec4 textureFilterLod (gsampler2D sampler, filter2D filter, vec2 P, float lod)
gvec4 textureFilterLod (gsampler3D sampler, filter3D filter, vec3 P, float lod)
gvec4 textureFilterLod (gsamplerCube sampler, filterCube filter, vec3 P, float lod)
float textureFilterLod (sampler1DShadow sampler, filter1DShadow filter, vec3 P, float lod)
float textureFilterLod (sampler2DShadow sampler, filter2DShadow filter, vec3 P, float lod)
gvec4 textureFilterLod (gsampler1DArray sampler, filter1DArray filter, vec2 P, float lod)
gvec4 textureFilterLod (gsampler2DArray sampler, filter2DArray filter, vec3 P, float lod)
float textureFilterLod (sampler1DArrayShadow sampler, filter1DArrayShadow filter, vec3 P,
float lod)

gvec4 textureFilterOffset (gsampler1D sampler, filter1D filter, float P, int offset [, float bias] )
gvec4 textureFilterOffset (gsampler2D sampler, filter2D filter, vec2 P, ivec2 offset [, float bias] )
gvec4 textureFilterOffset (gsampler3D sampler, filter3D filter, vec3 P, ivec3 offset [, float bias] )
gvec4 textureFilterOffset (gsampler2DRect sampler, filter2DRect filter, vec2 P, ivec2 offset )
float textureFilterOffset (sampler2DRectShadow sampler, filter2DRectShadow filter, vec3 P, ivec2 offset )
float textureFilterOffset (sampler1DShadow sampler, filter1DShadow filter, vec3 P, int offset [, float bias] )
float textureFilterOffset (sampler2DShadow sampler, filter2DShadow filter, vec3 P, ivec2 offset [, float bias] )
gvec4 textureFilterOffset (gsampler1DArray sampler, filter1DArray filter, vec2 P, int offset [, float bias] )
gvec4 textureFilterOffset (gsampler2DArray sampler, filter2DArray filter, vec3 P, ivec2 offset [, float bias] )
float textureFilterOffset (sampler1DArrayShadow sampler, filter1DArrayShadow filter, vec3 P, int offset [, float bias] )

gvec4 textureFilterProjOffset (gsampler1D sampler, filter1D filter, vec2 P, int offset [, float bias] )
gvec4 textureFilterProjOffset (gsampler1D sampler, filter1D filter, vec4 P, int offset [, float bias] )
gvec4 textureFilterProjOffset (gsampler2D sampler, filter2D filter, vec3 P, ivec2 offset [, float bias] )
gvec4 textureFilterProjOffset (gsampler2D sampler, filter2D filter, vec4 P, ivec2 offset [, float bias] )
gvec4 textureFilterProjOffset (gsampler3D sampler, filter3D filter, vec4 P, ivec3 offset [, float bias] )
gvec4 textureFilterProjOffset (gsampler2DRect sampler, filter2DRect filter, vec3 P, ivec2 offset )
gvec4 textureFilterProjOffset (gsampler2DRect sampler, filter2DRect filter, vec4 P, ivec2 offset )
float textureFilterProjOffset (sampler2DRectShadow sampler, filter2DRectShadow filter, vec4 P, ivec2 offset )
float textureFilterProjOffset (sampler1DShadow sampler, filter1DShadow filter, vec4 P, int offset [, float bias] )
float textureFilterProjOffset (sampler2DShadow sampler, filter2Dshadow filter, vec4 P, ivec2

gvec4 textureFilterLodOffset (gsampler1D sampler, filter1D filter, float P, float lod, int offset)
gvec4 textureFilterLodOffset (gsampler2D sampler, filter2D filter, vec2 P, float lod, ivec2 offset)
gvec4 textureFilterLodOffset (gsampler3D sampler, filter3D filter, vec3 P, float lod, ivec3 offset)
float textureFilterLodOffset (sampler1DShadow sampler, filter1DShadow filter, vec3 P, float lod, int offset)
float textureFilterLodOffset (sampler2DShadow sampler, filter2DShadow filter, vec3 P, float lod, ivec2 offset)
gvec4 textureFilterLodOffset (gsampler1DArray sampler, filter1DArray filter, vec2 P, float lod, int offset)
gvec4 textureFilterLodOffset (gsampler2DArray sampler, filter2DArray filter, vec3 P, float lod, ivec2 offset)
float textureFilterLodOffset (sampler1DArrayShadow sampler, filter1DArrayShadow filter, vec3 P, float lod, int offset)

gvec4 textureFilterProjLod (gsampler1D sampler, filter1D filter, vec2 P, float lod)
gvec4 textureFilterProjLod (gsampler1D sampler, filter1D filter, vec4 P, float lod)
gvec4 textureFilterProjLod (gsampler2D sampler, filter2D filter, vec3 P, float lod)
gvec4 textureFilterProjLod (gsampler2D sampler, filter2D filter, vec4 P, float lod)
gvec4 textureFilterProjLod (gsampler3D sampler, filter3D filter, vec4 P, float lod)
float textureFilterProjLod (sampler1DShadow sampler, filter1DShadow filter, vec4 P, float lod)
float textureFilterProjLod (sampler2DShadow sampler, filter2DShadow filter, vec4 P, float lod)

gvec4 textureFilterProjLodOffset (gsampler1D sampler, filter1D filter, vec2 P, float lod, int offset)
gvec4 textureFilterProjLodOffset (gsampler1D sampler, filter1D filter, vec4 P, float lod, int offset)
gvec4 textureFilterProjLodOffset (gsampler2D sampler, filter2D filter, vec3 P, float lod, ivec2 offset)
gvec4 textureFilterProjLodOffset (gsampler2D sampler, filter2D filter, vec4 P, float lod, ivec2 offset)
gvec4 textureFilterProjLodOffset (gsampler3D sampler, filter3D filter, vec4 P, float lod, ivec3 offset)
float textureFilterProjLodOffset (sampler1DShadow sampler, filter1DShadow filter, vec4 P, float lod, int offset)
float textureFilterProjLodOffset (sampler2DShadow sampler, filter2DShadow filter, vec4 P, float lod, int offset)

gvec4 textureFilterGrad (gsampler1D sampler, filter1D filter, float P, float dPdx, float dPdy)
gvec4 textureFilterGrad (gsampler2D sampler, filter2D filter, vec2 P, vec2 dPdx, vec2 dPdy)
gvec4 textureFilterGrad (gsampler3D sampler, filter3D filter, vec3 P, vec3 dPdx, vec3 dPdy)
gvec4 textureFilterGrad (gsamplerCube sampler, filterCube filter, vec3 P, vec3 dPdx, vec3 dPdy)
gvec4 textureFilterGrad (gsampler2DRect sampler, filter2DRect filter, vec2 P, vec2 dPdx, vec2 dPdy)
float textureFilterGrad (sampler2DRectShadow sampler, filter2DRectShadow filter, vec3 P, vec2 dPdx, vec2 dPdy)
float textureFilterGrad (sampler1DShadow sampler, filter1DShadow filter, vec3 P, float dPdx, float dPdy)
float textureFilterGrad (sampler2DShadow sampler, filter2DShadow filter, vec3 P, vec2 dPdx, vec2 dPdy)
float textureFilterGrad (samplerCubeShadow sampler, filterCubeShadow filter, vec4 P, vec3 dPdx, vec3 dPdy)
gvec4 textureFilterGrad (gsampler1DArray sampler, filter1DArray filter, vec2 P, float dPdx, float dPdy)
gvec4 textureFilterGrad (gsampler2DArray sampler, filter2DArray filter, vec3 P, vec2 dPdx, vec2 dPdy)
float textureFilterGrad (sampler1DArrayShadow sampler, filter1DArrayShadow filter, vec3 P, float dPdx, float dPdy)
float textureFilterGrad (sampler2DArrayShadow sampler, filter2DArrayShadow filter, vec4 P, float dPdx, float dPdy)

gvec4 textureFilterGradOffset (gsampler1D sampler, filter1D filter, float P, float dPdx, float dPdy, int offset)
gvec4 textureFilterGradOffset (gsampler2D sampler, filter2D filter, vec2 P, vec2 dPdx, vec2 dPdy, ivec2 offset)
gvec4 textureFilterGradOffset (gsampler3D sampler, filter3D filter, vec3 P, vec3 dPdx, vec3 dPdy, ivec3 offset)
gvec4 textureFilterGradOffset (gsampler2DRect sampler, filter2DRect filter, vec2 P, vec2 dPdx, vec2 dPdy, ivec2 offset)
float textureFilterGradOffset (sampler2DRectShadow sampler, filter2DrectShadow filter, vec3 P, vec2 dPdx, vec2 dPdy, ivec2 offset)
float textureFilterGradOffset (sampler1DShadow sampler, filter1DShadow filter, vec3 P, float dPdx, float dPdy, int offset )
float textureFilterGradOffset (sampler2DShadow sampler, filter2DShadow filter, vec3 P, vec2 dPdx, vec2 dPdy, ivec2 offset)
float textureFilterGradOffset (samplerCubeShadow sampler, filterCubeShadow filter, vec4 P, vec3 dPdx, vec3 dPdy, ivec2 offset)
gvec4 textureFilterGradOffset (gsampler1DArray sampler, filter1DArray filter, vec2 P, float dPdx, float dPdy, int offset)
gvec4 textureFilterGradOffset (gsampler2DArray sampler, filter2DArray filter, vec3 P, vec2 dPdx, vec2 dPdy, ivec2 offset)
float textureFilterGradOffset (sampler1DArrayShadow sampler, filter1DArrayShadow filter, vec3 P, float dPdx, float dPdy, int offset)
float textureFilterGradOffset (sampler2DArrayShadow sampler, filter2DArrayShadow filter, vec4 P, vec2 dPdx, vec2 dPdy, ivec2 offset)

gvec4 textureFilterProjGrad (gsampler1D sampler, filter1D filter, vec2 P, float dPdx, float dPdy)
gvec4 textureFilterProjGrad (gsampler1D sampler, filter1D filter, vec4 P, float dPdx, float dPdy)
gvec4 textureFilterProjGrad (gsampler2D sampler, filter2D filter, vec3 P, vec2 dPdx, vec2 dPdy)
gvec4 textureFilterProjGrad (gsampler2D sampler, filter2D filter, vec4 P, vec2 dPdx, vec2 dPdy)
gvec4 textureFilterProjGrad (gsampler3D sampler, filter3D filter, vec4 P, vec3 dPdx, vec3 dPdy)
gvec4 textureFilterProjGrad (gsampler2DRect sampler, filter2DRect filter, vec3 P, vec2 dPdx, vec2 dPdy)
gvec4 textureFilterProjGrad (gsampler2DRect sampler, filter2DRect filter, vec4 P, vec2 dPdx, vec2 dPdy)
float textureFilterProjGrad (sampler2DRectShadow sampler, filter2DRectShadow filter, vec4 P, vec2 dPdx, vec2 dPdy)
float textureFilterProjGrad (sampler1DShadow sampler, filter1DShadow filter, vec4 P, float dPdx, float dPdy)
float textureFilterProjGrad (sampler2DShadow sampler, filter2DShadow filter, vec4 P, vec2 dPdx, vec2 dPdy)

gvec4 textureFilterProjGradOffset (gsampler1D sampler, filter1D filter, vec2 P, float dPdx, float dPdy, int offset)
gvec4 textureFilterProjGradOffset (gsampler1D sampler, filter1D filter, vec4 P, float dPdx, float dPdy, int offset)
gvec4 textureFilterProjGradOffset (gsampler2D sampler, filter2D filter, vec3 P, vec2 dPdx, vec2 dPdy, vec2 offset)
gvec4 textureFilterProjGradOffset (gsampler2D sampler, filter2D filter, vec4 P, vec2 dPdx, vec2 dPdy, vec2 offset)
gvec4 textureFilterProjGradOffset (gsampler2DRect sampler, filter2DRect filter, vec3 P, vec2 dPdx, vec2 dPdy, ivec2 offset)
gvec4 textureFilterProjGradOffset (gsampler2DRect sampler, filter2DRect filter, vec4 P, vec2 dPdx, vec2 dPdy, ivec2 offset)
float textureFilterProjGradOffset (sampler2DRectShadow sampler, filter2DrectShadow filter, vec4 P,
vec2 dPdx, vec2 dPdy, ivec2 offset)
gvec4 textureFilterProjGradOffset (gsampler3D sampler, filter3D filter, vec4 P, vec3 dPdx, vec3 dPdy, vec3 offset)
float textureFilterProjGradOffset (sampler1DShadow sampler, filter1DShadow filter, vec4 P, float dPdx, float dPdy, int offset)
float textureFilterProjGradOffset (sampler2DShadow sampler, filter2DShadow filter, vec4 P, vec2 dPdx, vec2 dPdy, vec2 offset)


@Ilian Dinev



By the way, I'm only "opposing" it, so that we as a community discuss this to finest detail


Is this reply to your expectations? :D
More comments are obviously welcome!

Ilian Dinev
09-16-2009, 08:24 AM
Yes, keep it up guys ! I'm happy to see a lot of constructive ideas and new important patterns-of-use.

Alfonse Reinheart
09-16-2009, 11:48 AM
New functions:

This is so beyond necessary. Filters should be attached to samplers. You use a function to set a filter on a sampler, and you're done, or the sampler constructor simply has filter parameters. That's it.

The multiplicative explosion of texturing functions in GLSL is already huge. We don't need another dimension of texture access when we can just set it on the sampler itself.

Groovounet
09-16-2009, 05:28 PM
On OpenGL API side, there is no such thing called sampler... Do you mean a texture object? You attach the filter object to the texture object? How do you expect to add multiple filter to a single texture object then? And how do you expect to expose these multiple filter on GLSL side?

If the idea goes back to just create a sampler/filter object and being allowed to attach a single filter per texture, I think such feature have no point.

I completely agree that GLSL texture function count explosion is an issue.

I guest I finally see what you mean ...


glActiveTexture(GL_TEXTURE0);
glBindTexture(GL_TEXTURE_2D, TextureName);
glBindSampler(GL_TEXTURE_2D, SamplerName0);

glActiveTexture(GL_TEXTURE1);
glBindTexture(GL_TEXTURE_2D, TextureName);
glBindSampler(GL_TEXTURE_2D, SamplerName1);

Would actually do the trick!

However it doesn't fix the 32 textures limitation which would actually really become an issue with such feature!

Alfonse Reinheart
09-16-2009, 06:38 PM
On OpenGL API side, there is no such thing called sampler...

I'm talking about the GLSL functions. You can simply do this:



sampler2D myTexture1(filer params);
sampler2D myTexture2(filer params);


You don't need to pass a filter object in to texture functions. All that does is needlessly create more texture functions.


However it doesn't fix the 32 textures limitation which would actually really become an issue with such feature!

That's a different issue. That's the issue of how you attach a texture object to a program object.

Groovounet
09-17-2009, 02:44 AM
"params" to GLSL sampler ... nice I like such idea!
I actually wonder if such idea would be possible but it sound great!

Alfonse Reinheart
02-03-2010, 02:13 PM
One question that hasn't been dealt with in this discussion is this: what state is appropriate for the sampler objects and what state is not?

It clearly makes sense for the Mag/Min filter state to be in the sampler. Just as clearly, it does not make sense for the Base Level/Max Level for mipmaps settings to be there; those are a fundamental part of the texture object itself.

However, what about these:

1: Wrap S/T/R

2: Max/Min LOD (different from the base/max level)

3: Lod Bias

skynet
02-03-2010, 03:51 PM
I'm for all of them (filter, wrap, lod) as sampler state.

Samplers are kind of a role (from the view of a shader), the textures are actors that 'play' this role. The same texture should be able to be used differently with each sampler.

LOD settings seem to be a corner case, though. I did not use min/max lod at all in the recent years, lod bias very rare. Former extension specs offered a lod bias per texture unit and per texture object (they were added together). Maybe it is useful to keep this(?). On the other hand, we can already 'emulate' per-sampler-state-lod-bias by providing lod-bias to the various textureXYZ() functions, so another bias in the sampler itself is not really needed.

Yann LE PETITCORPS
02-05-2010, 02:48 PM
I like the idea about to have the possibilty to use different samplers on the same texture unit :)

I know that this can be easily handle with multiples textures, but it's true that the possiblility to limit the number of used textures/texture units can be very important
=> I have already encounter the problem when I have wanted the possibility to blend two YCbCr textures on 4:2:0 format with an hardware that can only handle two textures units ...
==> now, I use only two textures units and the 4:2:0 and planar formats are directly and easily handle into the shader :)

But I have problem for handle something that is near to the DXT format and that use YUV data (that can and have to be interpolated) and indices data (that cannot be interpolated) into the same (tiled) texture.
=> I have to use 4 texture units for this (only two if I want only handle one texture but four if I want blend two textures together)
==> but want only use two texture units for the blending of two textures :)
(cf. use two "logicals textures" per "physical texture" seem logic for to blend two texture together, but not four "logicals textures" ... :) )

And about the wrapping, cannot this to be easily handled by something like (x%width,y%height) into shaders ?


@+
Yannoo

skynet
02-05-2010, 03:08 PM
I like the idea about to have the possibilty to use different samplers on the same texture unit

Don't mix up texture and texture units. What has been called "texture unit" in former days are "samplers" today. Even with fixed functionality, it was well possible to bind the same texture to multiple texture units.

What we want is achieve is to sample the same series of image data in a different way with each sampler accessing it.
For instance, I'd like to access a certain texture twice in a shader, once with GL_REPEAT and once with GL_CLAMP_TO_EDGE. Today this is only possible if I create two distinct texture objects (thereby replicating the image data, doubling the VRAM usage).


And about the wrapping, cannot this to be easily handled by something like (x%with,y%height) into shaders ?

No, you cannot easily emulate this in a shader, because you also need to consider that one texture sample might tap the texture multiple times! Each tap needs to be wrapped independently.
The hardware does this very fast and efficient today.

Alfonse Reinheart
02-05-2010, 03:28 PM
I have already encounter the problem when I have wanted the possibility to blend two YCbCr textures on 4:2:0 format with an hardware that can only handle two textures units ...

To add to what Skynet has said, if your hardware can only handle two texture accesses in one pass, then it can only handle two texture accesses in one pass.

What's being discussed here is essentially API cleanup. It won't magically allow hardware to do something that it could not before. But it will make it easier and more intuitive for the user to communicate their intentions to OpenGL.

Yann LE PETITCORPS
02-05-2010, 03:28 PM
Thanks, Skynet for your response

It's about the possibility of multiples samplers into the same texture unit that I have wanted to speak. (it's true that I make often the mistake :( )

But technicaly, why two texture units cannot access to the same texture data ?
(cf. replicating the data)

@+
Yannoo

Yann LE PETITCORPS
02-05-2010, 03:42 PM
Yes, Alphonse it's true.

I have only found this problem with very old hardware :)
(and that cannot handle shaders, so I have resolved this at the source with a YCbCr to RGB conversion in software => this is more slow but this work :) )

But it's not because we have now more texture units that in the past that we are in the obligation to use alls :)


@+
Yannoo

Yann LE PETITCORPS
02-05-2010, 04:14 PM
I have reread this thread :

glActiveTexture(GL_TEXTURE0);
glBindTexture(GL_TEXTURE_2D, TextureName);
glBindSampler(GL_TEXTURE_2D, SamplerName0);

seem me good .. but it cannot handle more that only one sampler per texture unit :(

I have see a day something about centroids texels in GLSL

http://www.opengl.org/pipeline/article/vol003_6/

=> cannot the idea to be extended for to handle multiples sampler states directly in the shader with something like this ?

nearest/linear/bilinear/centroid clamped/wrapped sampler2D texsample;

And when we haven't the nearest/linear/.. clamped/wrapped prefixed states in the shader , it use the texture states as default ...

@+
Yannoo

Alfonse Reinheart
02-05-2010, 05:08 PM
it cannot handle more that only one sampler per texture unit

Right. Because the concept makes no sense. A sampler is a texture unit. It represents access to a specific texture with a specific set of parameters.


nearest/linear/bilinear/centroid clamped/wrapped sampler2D texsample;

And what does "bilinear" mean (especially for a 1D or 3D texture), and how does it differ from "linear"? And which directions are "clamped"?

Filter parameters in the shader should look like this:



sampler2D diffuseTexture(mag = linear, min = linear_mipmap_linear, wrap_s = repeat, wrap_t = clamp, max_aniso_ext = 4.0);

Yann LE PETITCORPS
02-05-2010, 05:21 PM
Thanks Alphonse, I have now **really** understand that a sampler and a texture unit is exactely the same thing :)
(I understand quickly but it must sometimes explain to me a long time :) )

For a sampler2D, it's true that it's only GL_LINEAR :)

And of course

sampler2D diffuseTexture(mag = linear, min = linear_mipmap_linear, wrap_s = repeat, wrap_t = clamp, max_aniso_ext = 4.0);

is really very far better, simple to work with ... and a very good response to the subject of this thread :)

But what about to share the same texel data between multiples samplers
=> it's technicaly possible or not ?

It's for to use with one interleaved and tiled texture where the half of data (cf. RGB/YUV data) have to be interpolated, when the other half of data (cf. indices) cannot be interpolated
(something like a "multi-picture DXT" that individualy interpolate each RGB/YUV component in a 4x4 or 8x8 bloc, and not only a line between two colors in a 4x4 bloc as in DXTn)
=> I have to use multiples samplers/texture units for to handle inter-picture interpolations
==> and I want use this for to reduce the memory used, so have multiples copy of the same data isn't really what I want :(

I can separe the texture in multiples parts before via the CPU but I find that this spend %CPU for nothing and this generate two parts per image x4 ("IPBB semi-compressed GOP")
=> 8 textures parts
==> 8 textures units/samplers ... :(
===> but on other side, it's true that I can too assemble similar data chunks for to use only two 3D samplers/texture units for my GOP of 4 pictures, :)
(cf. one GL_LINEAR YCbCr 3D texture for the color data and one GL_NEAREST unsigned byte 3D texture for indices)
====> so, I have finaly no need of "separate sampler state from textures states" for to handle this (only two 3D textures but with one different sampler for each) ... but I'm sure that this can really be a very good extension :) :)




@+
Yannoo

Brolingstanz
02-06-2010, 08:45 AM
So... it's settled then; we definately need a separation of sampler and texture.

Chris Lux
02-07-2010, 10:48 AM
...and while at it, get rid of the texture unit nonsense. it is ridiculous to be forced to keep track of what texture was bound to which unit when all i want to do is bind the texture object to a sampler in a shader!

Yann LE PETITCORPS
02-12-2010, 01:11 PM
Yes, Chris I think exactely the same thing :)

But I think too that the "bind texture by unit" is good for maintain compatibility with olders versions of OpenGL that use multiples chained textures units for to handle the multitexturing
=> so something this isn't a very bad thing as this ...

On another side, I find too that to have now very limited possibilities because of this into fragments shaders is really ridiculous in 2010 ...

Such as the fact that we haven't now in 2010 a direct JPEG/MPEG support hardware in OpenGL textures ... but this is another story :)
(a PocketPC can very easily compress/decompress JPEG and decompress MPEG files in pure software with a very little processor, so no reasons about to speak power processing problems or others lies)

And when I think that a M(J)PEG video is only successives JPEG pictures (that can be easily handled by chained textures units that can work with the JPEG **standardised** format) ... it's really a nightmare to see all the time loose for nothing since a lot of years ...


@+
Yannoo

Alfonse Reinheart
02-12-2010, 01:23 PM
On another side, I find too that to have now very limited possibilities because of this into fragments shaders is really ridiculous in 2010

How? The hardware cannot use more than X textures, period. So you would gain nothing by having texture binding that does not deal with numbered texture units. Thus, nothing can be considered "very limited possibilities."


(a PocketPC can very easily compress/decompress JPEG and decompress MPEG files in pure software with a very little processor, so no reasons about to speak power processing problems or others lies)

Really? Can they decompress a 4096x4096 texture 100,000 times per frame at 60+ FPS?

I didn't think so.

Yann LE PETITCORPS
02-12-2010, 01:39 PM
A 720x576 MPEG2 (cf. DVD) video texture support at 25/30/50/60 fps can be a good start, no ???

And I'm for a 4096x4096 MPEG4 video texturing at 100 000 fps on another side :)
But after ...

And a NVIDIA GeForce GTX 285 have 80 texture units
(first link visited http://hothardware.com/Articles/NVIDIA-GeForce-GTX-285-Unveiled/)
=> so really more than one second of video if we bind DVD successives MPEG pictures into successives GPU textures units ...
(or 80 separates sampler state from texture state if you prefer ...)

The hardware **IS ALREADY HERE** (and since a lot of years ...)

And this feature **IS REALLY WANTED** by a lot of users ...



@+
Yannoo

skynet
02-12-2010, 02:16 PM
cannot use more than X textures, period. So you would gain nothing by having texture binding that does not deal with numbered texture units.

Assumed, we would bind textures directly to samplers (which seem to be the 'real' texture units today), wouldn't the shader compiler just warn about exceeding the hardware limits, when too many samplers get accessed?

The only advantage of the texture-to-unit-to-sampler indirection I can think of is, that by switching shaders, the currently bound textures 'switch', too. But on the other hand side, I don't mind this indirection. Usually, I set the sampler-uniforms once right after the shader gets created and then leave it that way. The actual binding of texture to shader then happens by binding the texture to its destined unit. So, there's not much of confusion and state-fiddling going on.

The only downside is that when switching to a certain shader, you need to rebind _all_ textures particular to this shader, because in meantime other code parts may have changed the texture-unit bindings. Binding textures to samplers would result in textures being bound to a sampler essentially 'forever', which might be good for samplers that always only access one certain texture (for instance, lookup-textures).

Alfonse Reinheart
02-12-2010, 02:17 PM
A 720x576 MPEG2 (cf. DVD) video texture support at 25/30/50/60 fps can be a good start, no ???

No. Not for someone who's actually interested in 3D rendering, rather than playing movies.


And a NVIDIA GeForce GTX 285 have 80 texture units ...

It also has 240 processor cores. That doesn't mean you get to bind 240 programs and run them all at the same time.

Yann LE PETITCORPS
02-12-2010, 02:26 PM
Not only playing movies ... display/map numerous video streams on numerous 3D shapes
=> this isn't really the same thing ...
(but ok, this can begin with playing/mapping 6 movies in // on a cube for example)

And this need only one IPBB chunk (so 4 linked textures units) per video stream :)
=> so 20 video streams in // with 80 textures units ...

Is for you texturing multiples quads and see a BD the same thing ???
For me, no ...

And it's for a 4D framework (X,Y,Z,T) that can handle/mix various video streams in input (webcams for exemple) into various and distincts animated 3D shapes , not only for a BD or only display individuals 2D movies (I found that libavcodec/ffmpeg handle this very nice for exemple ... I can per example fill the screen on my iMac with about ten video streams in //, each mapped on a 3D rotated cube and on individuals OpenGL glut windows, but the %CPU is near to 100% and I have saccades)

But the subject of this thread is "Separate sampler state from texture state" ...
=> 20 separates quadri-samplers (or 10 octo-samplers) can perhaps to be a good start for beginning :)

I prefer only 80 video textures at 1920x1080 and 60+ FPS (9 953 280 000 texels)
than a cosmologic "4096x4096 texture 100,000 times per frame at 60+ FPS" (100 663 296 000 000 texels)

=> the mathematics confirm that your version is about 10000x bigger that mine :)
==> they are really more than 10000 texture units in a GPU ???? :) :) :)
(I have certainly make somes mistakes in computations but in all cases the factor is a lot of power 10 ... and I have only 5 fingers per hand)


@+
Yannoo

Yann LE PETITCORPS
02-12-2010, 05:24 PM
1920x1080 = 240x135 blocs of 8x8 texels

This make less than 15x9 patchs of 16x16 blocs of 8x8 texels

So, "only" 16x16=256 "simples/littles" texture units of 8x8=64 texels each
For handle one video texture chunk of 4 IPBB HD pictures at 1920x1080 ...
(but ok, with 15x9=135 reloads of the 256 textures units)

=> I think this can and have to be incorpored into futurs GPUs ...

And about this thread, this make 15x9(x256?) separate sampler states per texture :)

@+
Yannoo

Alfonse Reinheart
02-12-2010, 05:40 PM
display/map numerous video streams on numerous 3D shapes
=> this isn't really the same thing ...
(but ok, this can begin with playing/mapping 6 movies in // on a cube for example)

And what application does this have to doing quality 3D graphics?


And this need only one IPBB chunk (so 4 linked textures units) per video stream

Or you know, a single array texture.

If you're not going to effectively use the features you currently have, there's no reason to expect that you'll effectively use what more powerful hardware will bring.


But the subject of this thread is "Separate sampler state from texture state" ...
=> 20 separates quadri-samplers (or 10 octo-samplers) can perhaps to be a good start for beginning

No, that has nothing to do with what is being discussed here. That's something you want for your own, very limited needs.

Sampler state means exactly that: the set of state associated with sampling from a texture. It doesn't mean "whatever Yann LE PETITCORPS wants it to mean."


=> the mathematics confirm that your version is about 10000x bigger that mine

And my version is also 100,000 times more generally useful. 100,000 samples per frame is at the low end of the number of samples that are used per frame for any modern game. Most games render a minimum of 800,000 (1024x768) pixels per frame, and each of those pixels requires sampling from at least one texture. Hence a minimum of 800,000 samples per frame.

A texture unit therefore must be fast. Burdening it with nonsense like accessing from 4 separate textures simultaneously just because it's easier for you than using array textures is not conducive to keeping them fast.

Yann LE PETITCORPS
02-12-2010, 06:04 PM
For this time, only for my personnal pleasure :)

If I follow your same confused reasoning, why to have invented the color TV, the VCD/DVD and others blue-rays/VOD inventions when Eadweard Muybridge have already found the idea of cinema in 1878 :)
(http://fr.wikipedia.org/wiki/Histoire_du_cinéma#Origines_et_exp.C3.A9rimentatio ns)

Since millenary, we can alls walks with our foots, but since one or two centuries we can too use train/car or fly per example ...

And this have already a name from a very long time ... the progress of the science :)

And it's true that 800 000 pixels per frame is really a mimimum, because an HD picture at 1920x1080 frame is 2 073 600 pixels :)
(but a HD video use something like 60 textures of 1920x1080 texels per second)


@+
Yannoo

Alfonse Reinheart
02-12-2010, 06:32 PM
If I follow your same confused reasoning, why to have invented the color TV, the VCD/DVD and others blue-rays/VOD inventions when Eadweard Muybridge have already found the idea of cinema in 1878

Um, no. My point is that you are the only one who wants to decode 20 MPEG streams simultaneously and display them as textures in 3D space. It is not something that is generally useful, and therefore it is not something that dedicated hardware should deal with.

All of those things you cite are generally useful, unlike what you're proposing here.

Yann LE PETITCORPS
02-12-2010, 06:35 PM
But it's usefull because this is already usable :)

I think that the telephon was primary used for "théâtrophone" no ?

Now in 2010, we have ADSL with a lot of TV channels arising from this invention for example ...

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 ???
(the hardware have to store the pictures into buffers that are stored in video memory before that this can be converted on video signal for the screen, no ?)

And in the way, I see that a lot of things aren't perfect, is all ...
Such as the fact that we haven't separates samplers states from texture state :(
(the hardware can already make multiple video memory access in // when it handle mipmapping, linear filtering or the DXT decompression, no ?)

Currents GPU use multiples SIMD processors in //, it's clear
=> but can this to be a little "segmented" or not ?
==> something like "contries of numerous SIMD processors"

For example, DXT textures are make of 4x4 blocs of pixels
=> is imaginable that a different DXT method can be used for each differents blocs (or for a more big patch than contain 8x8 or 16x16 similars DXT blocs for examples) ?

For example in this world, we have lots of groups of persons that work together (or not) for the same thing.
But luckily alls persons in this world don't make exactely the same thing in the same time :)

@+
Yannoo

Alfonse Reinheart
02-12-2010, 07:36 PM
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
02-12-2010, 08:37 PM
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
02-12-2010, 09:52 PM
"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
02-12-2010, 11:22 PM
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
02-13-2010, 08:06 AM
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 (http://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
02-13-2010, 09:01 AM
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
02-13-2010, 12:41 PM
=> 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
02-13-2010, 02:03 PM
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
02-18-2010, 04:11 AM
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
02-18-2010, 06:09 AM
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, &amp;errCode);

clSetKernelArg(kernel, 0, sizeof(newSampler), &amp;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, &amp;errCode);

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

clSetSamplerParameter(sampler1, CL_SAMPLER_FILTER_MODE, CLK_FILTER_LINEAR);

Yann LE PETITCORPS
03-07-2010, 07:17 AM
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

Rob Barris
03-11-2010, 07:56 PM
Implemented.

Alfonse Reinheart
03-11-2010, 09:44 PM
"Implemented" is perhaps not the correct word to use. At least, until we can get drivers that actually implement it ;)

Stephen A
03-11-2010, 11:55 PM
Awesome!

Yann LE PETITCORPS
03-14-2010, 12:19 PM
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

Alfonse Reinheart
03-14-2010, 07:43 PM
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?

Rob Barris
03-14-2010, 07:46 PM
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.

Yann LE PETITCORPS
03-15-2010, 04:01 PM
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

Alfonse Reinheart
03-15-2010, 04:39 PM
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?

Yann LE PETITCORPS
03-15-2010, 05:12 PM
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 // :)