A "dependent texture read" is when return values from one texture lookup (or other in-shader computations) are used to determine WHERE to look up from a second texture. An important implication is that the texture coordinates (where you look up from) is not determined until the middle of execution of the shader... there's no kind of static analysis you can do on the shader (even knowing the values of all parameters) that will tell you what the coordinates will be ahead of time. It also strictly orders the two texture reads and limits how much the execution order could be changed by optimizations in the driver, etc.

On older graphics cards, there used to be quite a few limitations on this kind of thing. For example, at one point (IIRC) you could look up from multiple textures but only with a small number of distinct texture coordinates. The hardware was actually implemented in a way that certain types of dependent texture reads were either impossible or very inefficient.

In the latest generation or two of cards, you shouldn't have to worry about this. But you may be reading books or articles from a couple years ago when you really did have to pay close attention to such things.

All About OpenGL Objects

The standard model for OpenGL objects is as follows.

Objects have state. Think of them as a struct. So you might have an object defined like this:

struct Object
{
    int count;
    float opacity;
    char *name;
};

The object has certain values stored in it and it has state. OpenGL objects have state too.

Changing State

In C/C++, if you have an instance of type Object, you would change its state as follows: obj.count = 5; You would directly reference an instance of the object, get the particular piece of state you want to change, and shove a value into it.

In OpenGL, you don't do this.

For legacy reasons better left unexplained, to change the state of an OpenGL object, you must first bind it to the context. This is done with some from of glBind* call.

The C/C++ equivalent to this is as follows:

Object *g_objs[MAX_LOCATIONS] = {NULL};    
void BindObject(int loc, Object *obj)
{
  g_objs[loc] = obj;
}

Textures are interesting; they represent a special case of binding. Many glBind* calls have a "target" parameter. This represents different locations in the OpenGL context where objects of that type can be bound. For example, you can bind a framebuffer object for reading (GL_READ_FRAMEBUFFER) or for writing (GL_DRAW_FRAMEBUFFER). This affects how OpenGL uses the buffer. This is what the loc parameter above represents.

Textures are special because when you first bind them to a target, they get special information. When you first bind a texture as a GL_TEXTURE_2D, you are actually setting special state in the texture. You are saying that this texture is a 2D texture. And it will always be a 2D texture; this state cannot be changed ever. If you have a texture that was first bound as a GL_TEXTURE_2D, you must always bind it as a GL_TEXTURE_2D; attempting to bind it as GL_TEXTURE_1D will give rise to an error (while run-time).

Once the object is bound, its state can be changed. This is done via generic functions specific to that object. They too take a location that represents which object to modify.

In C/C++, this looks like:

void ObjectParameteri(int loc, ObjectParameters eParam, int value)
{
  if(g_objs[loc] == NULL)
    return;

  switch(eParam)
  {
    case OBJECT_COUNT:
      g_objs[loc]->count = value;
      break;
    case OBJECT_OPACITY:
      g_objs[loc]->opacity = (float)value;
      break;
    default:
      //INVALID_ENUM error
      break;
  }
}

Notice how this function sets whatever happens to be in currently bound loc value.

For texture objects, the main texture state changing functions are glTexParameter. The only other functions that change texture state are the glTexImage functions and their variations (glCompressedTexImage, glCopyTexImage, the recent glTexStorage). The various SubImage versions change the contents of the texture, but they do not technically change its state. The Image functions allocate texture storage and set the texture's format; the SubImage functions just copy pixels around. That is not considered the texture's state.

Allow me to repeat: these are the only functions that modify texture state. glTexEnv modifies environment state; it doesn't affect anything stored in texture objects.

Active Texture

The situation for textures is more complex, again for legacy reasons best left undisclosed. This is where glActiveTexture comes in.

For textures, there aren't just targets (GL_TEXTURE_1D, GL_TEXTURE_CUBE_MAP, etc). There are also texture units. In terms of our C/C++ example, what we have is this:

Object *g_objs[MAX_OBJECTS][MAX_LOCATIONS] = {NULL};
int g_currObject = 0;

void BindObject(int loc, Object *obj)
{
  g_objs[g_currObject][loc] = obj;
}

void ActiveObject(int currObject)
{
  g_currObject = currObject;
}

Notice that now, we not only have a 2D list of Objects, but we also have the concept of a current object. We have a function to set the current object, we have the concept of a maximum number of current objects, and all of our object manipulation functions are adjusted to select from the current object.

When you change the currently active object, you change the entire set of target locations. So you can bind something that goes into current object 0, switch to current object 4, and will be modifying a completely different object.

This analogy with texture objects is perfect... almost.

See, glActiveTexture does not take an integer; it takes an enumerator. Which in theory means that it can take anything from GL_TEXTURE0 to GL_TEXTURE31. But there's one thing you must understand:

THIS IS FALSE!

The actual range that glActiveTexture can take is governed by GL_MAX_COMBINED_TEXTURE_IMAGE_UNITS. That is the maximum number of simultaneous multitextures that an implementation allows. These are each divided up into different groupings for different shader stages. For example, on GL 3.x class hardware, you get 16 vertex shader textures, 16 fragment shader textures, and 16 geometry shader textures. Therefore, GL_MAX_COMBINED_TEXTURE_IMAGE_UNITS will be 48.

But there aren't 48 enumerators. Which is why glActiveTexture doesn't really take enumerators. The correct way to call glActiveTexture is as follows:

glActiveTexture(GL_TEXTURE0 + i);

where i is a number between 0 and GL_MAX_COMBINED_TEXTURE_IMAGE_UNITS.

Rendering

So what does all of this have to do with rendering?

When using shaders, you set your sampler uniforms to a texture image unit (glUniform1i(samplerLoc, i), where i is the image unit). That represents the number you used with glActiveTexture. The sampler will pick the target based on the sampler type. So a sampler2D will pick from the GL_TEXTURE_2D target. This is one reason why samplers have different types.

Now this sounds suspiciously like you can have two GLSL samplers, with different types that use the same texture image unit. But you can't; OpenGL forbids this and will give you an error when you attempt to render.