Jump to content
  • Advertisement
Sign in to follow this  
tobspr

Why does GLSL use integers for texture fetches?

This topic is 958 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

After reading AMD's presentation about the GCN architecture, which states that integer divisions cost multiple cycles, and unsigned integer divisions are much faster, I changed my data types to "uint" where appropriate, since I do not use negative values in most cases anyways.

 

However, all variants of texelFetch only accept ivec2/ivec3. What is the reason for this? From what I can see, unsigned integers would be much more appropriate. 

 

I do not know about any extensions which has a special handling for negative texture integer coordinate values,

so, is there any reason the texture coordinates are not unsigned?

 

 

 

 

 

Share this post


Link to post
Share on other sites
Advertisement

TBH I thought it was a bad call. And I still think it is.
 
However I found one instance where the fetch being an int was useful instead of being an uint: Clamp to edge emulation.
I needed my fetches to clamp to edge; so typical code would look like this:

ivec2 xy = some_value - another_value;
xy = clamp( xy, 0, textureResolution.xy );
float val = texelFetch( myTex, xy ).x;

This code would not work as intended if "xy" were to be uvec2, because values below 0 would wrap, and hence clamped to textureResolution (the other edge!) instead of clamping to 0. It would be the same as doing xy = min( xy, textureResolution.xy );

However, I'm like Hodgman: I prefer unsigned integers because we're addressing memory here, and negative memory makes no sense, and I prefer assert( x < elemSize ) over assert( x >= 0 && x < elemSize );
This case I talk about (clamp to edge) can simply be solved through explicit casts. IMO ints here have more trouble than benefits.

Share this post


Link to post
Share on other sites
Sign in to follow this  

  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

GameDev.net is your game development community. Create an account for your GameDev Portfolio and participate in the largest developer community in the games industry.

Sign me up!