Separate sampler state from texture state

[skynet]

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]

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]

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]

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]

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]

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]

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]

So... it's settled then; we definately need a separation of sampler and texture.

[Chris Lux]

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

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