I understand the main differences between texelFetch and texture, but have some questions about the details:

  • Does texelFetch involve a performance penalty? Such as not using a cache or such?
  • Are texelFetch and texture interchangeable when using GL_NEAREST?
  • 1
    \$\begingroup\$ You could write a test case and see... \$\endgroup\$
    – ThorinII
    Commented Nov 28, 2013 at 0:15
  • \$\begingroup\$ @ThorinII As with many things related to GPUs, these things are highly variable across hardware vendors, GPU models, and even driver versions. Writing a test case and running it on your own machine doesn't give you the full picture. \$\endgroup\$
    – Tara
    Commented Jan 16, 2022 at 1:37

2 Answers 2


texelFetch is quite different from texture.

texture is your usual texture access function which handles filtering and normalized ([0,1]) texture coordinates. texelFetch directly accesses a texel in the texture (no filtering) using unnormalized coordinates (e.g. (64,64) in the middle-ish texel in a 128x128 texture vs (.5,.5) in normalized coordinates).

  • 4
    \$\begingroup\$ +1 I would like to add that texelFetch is meant for data access when the texture is not particularly meant to be displayed as an image, but other type of data, unlike texture which accesses the texels when they are meant to be used as images, that's why it uses filtering etc. – \$\endgroup\$
    – concept3d
    Commented Nov 28, 2013 at 6:10
  • 1
    \$\begingroup\$ @mcb: maybe, but I wouldn't expect it to be very large, and it will probably vary a lot by hardware vendor. Performance is the absolutely wrong metric to use when deciding which of these functions to invoke: use the one that is correct for your situation (you either need the hardware's filtering and so must use texture or you need the hardware to not do filtering and so must use texelFetch). \$\endgroup\$ Commented Jun 14, 2015 at 16:51
  • 6
    \$\begingroup\$ @SeanMiddleditch How is performance the wrong metric in this case? If texelFetch is faster, and nearest neighbor filtering suffices, you can't change the context to NN filtering for whatever reason, it would be reasonable to prefer it over texture. \$\endgroup\$
    – Lenar Hoyt
    Commented Jun 14, 2015 at 22:45
  • 1
    \$\begingroup\$ @mcb: texelFetch and texture work differently in fundamental ways. See also the inputs: texture coordinates vs normalized coordinates. They serve different purposes. The one is not just an optimization of the other. \$\endgroup\$ Commented Jun 15, 2015 at 19:57
  • 1
    \$\begingroup\$ @SeanMiddleditch I'm aware of that, however, one could assume that texelFetch has an advantage in that it doesn't interpolate, and that texel has an advantage in that the graphics pipeline is highly optimized for interpolation. One disadvantage might be that texelFetch is a newer command and hence perhaps less optimized. So, it's hard to tell which one is faster or whether they are dead even. Of course, one could simply test it, but I don't have a modern graphics at hand. \$\endgroup\$
    – Lenar Hoyt
    Commented Jun 15, 2015 at 23:49

Since there's no accepted answer I add some info, I wanted just to add things not already said by Sean in his answer.

TexelFetch treats the texture as a Image, so you can access exactly the content of pixels. You usually do that when you need exactly that content, which is in few but usefull occasions:

  • Certain post processing filters (Guassian blur exploits texture sample interpolation and so it cannot use TexelFetch)
  • When vertices needs to read data from textures and that is a operation dependent on 2 coordinates

Tex2D treat the texture as a texture. You don't want the exact content of a pixel, but you want the most realistic result. A standard texture read is a very complex operation and it involves reading interpolated data from one or more mipmap levels and then it interpolates again. All those expensive operations are to avoid visual artifacts.

GL_NEAREST will not work the same because on farest polygons you are reading data in the smaller mipmap level, wich is not the same exact data you would read from a texel fetch.

There is one case where Tex2D (almost) work the same of TexelFetch:

  1. filter is GL_NEAREST
  2. you are using a incomplete mipmap pyramid with 1 level
  3. your UVs are not normalized vertex components (but you have to normalize them in the shader)

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .