A dependent texture read

graphicsopengl

I've been reading papers on computer graphics, and every so often I come across the term "dependent texture read" or "dependent texture fetch" used in the context of querying textures in shader code. What is a dependent texture read, and what is the difference between this and a "normal" texture read?

Best Answer

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.

Related Solutions

OpenGL 4.0 texture binding

Setting the internal format to GL_RGB/A implies you should be using a sampler2D and not usampler2D, even though the raw image data is initially given as unsigned bytes. EDIT The given data gets converted to the internal format at the call to glTexImage2D (in this case GL_RGBA is 8 bits per channel so not much has to happen). However, for most graphics applications the data is needed with higher accuracy, for example when sampling the texture with non-"nearest" interpolation, which is why it's normally exposed as floats.

To bind multiple textures...

glActiveTexture(GL_TEXTURE0 + firstTextureIndex); //firstTextureIndex should be unique amongst the textures bound for a particular shader
glBindTexture(GL_TEXTURE_2D, myFirstTextureHandle);
glUniform1i(glGetUniformLocation(shaderProgramHandle, "firstSampler"), firstTextureIndex); //note the same index given in the glActiveTexture call. This is also always glUniform1i

and repeat for secondTextureIndex, mySecondTextureHandle, "secondSampler" etc.

If glGetUniformLocation doesn't return a location, double check you actually use it and it affects the shader output (or it gets optimized out completely). Also check for the usual typos or missing "uniform" keyword etc.

Difference between surface and texture (SDL / general)

Basically your assumption "has to do something with GPU?" is right.

SDL_Surface is used in software rendering. With software rendering, as saloomi2012 correctly noticed, you are using regular RAM to store image data. Thus, in most cases you can access data buffer associated with surface directly, modifying its content, i.e. it is using CPU, hence the software name.

SDL_Texture on the other hand, is used in a hardware rendering, textures are stored in VRAM and you don't have access to it directly as with SDL_Surface. The rendering operations are accelerated by GPU, using, internally, either OpenGL or DirectX (available only on Windows) API, which in turn are using your video hardware, hence hardware rendering name.

Needless to say that hardware rendering is by orders of magnitude faster than software rendering and should be always be considered as primary option.

Best Answer

Related Solutions

OpenGL 4.0 texture binding

Difference between surface and texture (SDL / general)

Related Topic