GLSL samplers as structs

OpenGL
1

It’d be very handy if texture attributes (size, format and so on) were visible to GLSL shaders. Eg:

sampler2D tex;
some_vec2 /= tex.size.xy;
some_other_vec2 += tex.reciprocal_size.xy;

The resolution-independance that normalised texcoords provide is mostly nice, but there are times when you want to work in texel-units, perhaps the language could accomodate this a bit better.

Even nicer (but probably tricker to implement) would be the ability to give textures arbitrary properties. Eg:

sampler2D tex;
gl_FragColor = texture2D(tex,gl_TexCoord[0])*tex.scale + tex.bias;
2

  • This is almost a good idea. Having the texture dimensions is not bad since some code needs it.

  • What will you do with the texture foramt?

  • Texel access is possible now.

  • What is better is to create your own struct in your GLSL.

  • and finally, I think for the most part, this feature would go unused by coders.

3

Originally posted by V-man:

  • This is almost a good idea. Having the texture dimensions is not bad since some code needs it.
  • What will you do with the texture foramt?
    Erm, actually I just threw that one in without thinking about it; texture-size and one-over-texture-size is what I’d want most. I can imagine a few scenarios where texture-format might be useful but nothing I’ve ever actually needed myself.
  • Texel access is possible now.
    Aha, how do I do this? It doesn’t seem like I can get (eg) the immediate neigbours of a texel, given a texcoord but not the textures size.
  • What is better is to create your own struct in your GLSL.
    But I’m lazy, and would prefer not to have to update uniforms every time I switch texture or shader.
4

What scenario would need to know the texture format?

Texel access (single texel) can be done with no filtering (mag = nearest, min = nearest), or with mipmaps (mag = nearest, min = nearest_mipmap_nearest) using lod to select a mipmap. Actually, I think selecting mipmap is not possible in fs and this might be a reasonable request to make TODAY.

5

Originally posted by V-man:
What scenario would need to know the texture format?
Like I said, I didn’t think about it very hard and you’re right, it probably wouldn’t see much use. But here’s a (slightly dubious) example anyway:

Texel access (single texel) can be done with no filtering (mag = nearest, min = nearest), or with mipmaps (mag = nearest, min = nearest_mipmap_nearest) using lod to select a mipmap. Actually, I think selecting mipmap is not possible in fs and this might be a reasonable request to make TODAY.
Ah, what I meant was addressing the texture in texel-sized units, not just accessing discrete texels without filtering.

I want to be able to say “the texel three along and one down from this one” without having to worry about keeping uniforms in sync for multiple shaders, each of which may use multiple textures.

6

Originally posted by mikef:
[QUOTE]I want to be able to say “the texel three along and one down from this one” without having to worry about keeping uniforms in sync for multiple shaders, each of which may use multiple textures.
Try RECT textures. Maybe that’s closer to what you are looking for.

7

I think there is many situations where you would like to know the real size of the texture. I have a lot of shaders dealing with imagefilters and i have to sen the real width and height of the texture each time to ensure the result.

I know the limitations and i understand that is would be a bit ambiguous when you use mipmapping but call it baselevelsize and youre out of that problem.

I know its pretty easy to make a framework that automatically sends the information when you bind a texture and a program, but it would be easier for the developer to not hassle with that, and it would make it easier to create pixelcorrect imagefilters that works for everyone ( instead of having them use the special framework)

btw. RECT doenst work if you want 3 pixels from the bottom :slight_smile:

8

Originally posted by V-man:
[quote]Originally posted by mikef:
[QUOTE]I want to be able to say “the texel three along and one down from this one” without having to worry about keeping uniforms in sync for multiple shaders, each of which may use multiple textures.
Try RECT textures. Maybe that’s closer to what you are looking for.[/QUOTE]I know the various ways to get around this, I’m just suggesting that things could be made a little more convenient. All the reasons for tracking transform state in GLSL apply here also.

I wouldn’ touch RECT textures with a bargepole anyway - ATI and nVidia support two different specs, the nVidia (ARB) spec being riddled with bugs and the ATI (EXT) one having no GLSL support at all.

Ok, enough ranting; this isn’t a big deal, it just seems like an odd omission and it would make it possible to write slightly more modular shaders.

9

Originally posted by mikef:
[b] [quote]Originally posted by V-man:
[quote]Originally posted by mikef:
[QUOTE]I want to be able to say “the texel three along and one down from this one” without having to worry about keeping uniforms in sync for multiple shaders, each of which may use multiple textures.
Try RECT textures. Maybe that’s closer to what you are looking for.[/QUOTE]I know the various ways to get around this, I’m just suggesting that things could be made a little more convenient. All the reasons for tracking transform state in GLSL apply here also.

I wouldn’ touch RECT textures with a bargepole anyway - ATI and nVidia support two different specs, the nVidia (ARB) spec being riddled with bugs and the ATI (EXT) one having no GLSL support at all.

Ok, enough ranting; this isn’t a big deal, it just seems like an odd omission and it would make it possible to write slightly more modular shaders.[/b][/QUOTE]It’s not an odd omission because texture dimensions are not GL states.
I don’t strongly oppose your suggestion.

RECT doenst work if you want 3 pixels from the bottom
Well, my face is red. I don’t know why that would be. Why can’t you sample a RECT texture 3 times?

10

If you dont know the size of the texture ( thats the origin of this thread) how would know what the ‘bottom’ of the texture is in a RECT texture?

11

on the face of things this actually sounds pretty cool. i would be curious about the implications though, performace or otherwise. implementors might prefer a good clubbing over having to make the internal modifications necessary to do this.

v-man pointed out that you can already accomplish this very thing with passed parameters, so convenience aside there’s not much at stake here, unless a measureable performance boost could be demonstrated against a wide body of usage. i don’t know, but i suspect the arb is not big on convenience, unless it’s fairly massive or it’s relatively convenient for them too, spec-wise and/or implementation-wise :wink:

but all things being equal, this might just come in handy.

regards,
bonehead