Separate sampler state from texture state

[Chris Lux]

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]

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]

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]

Well, DX10 supports it, so it would be reasonable to assume that there is hw support for it...

[Stephen A]

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]

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]

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]

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]

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]

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.