18
\$\begingroup\$

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?
\$\endgroup\$
  • 1
    \$\begingroup\$ You could write a test case and see... \$\endgroup\$ – ThorinII Nov 28 '13 at 0:15
  • 1
    \$\begingroup\$ Have you forgotten to mark an answer as accepted, or is this still an open issue? \$\endgroup\$ – Anko Jan 1 '15 at 18:12
23
\$\begingroup\$

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).

\$\endgroup\$
  • 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 Nov 28 '13 at 6:10
  • \$\begingroup\$ Is there a difference in performance? \$\endgroup\$ – Lenar Hoyt Nov 3 '14 at 12:19
  • 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\$ – Sean Middleditch Jun 14 '15 at 16:51
  • 3
    \$\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 Jun 14 '15 at 22:45
  • \$\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\$ – Sean Middleditch Jun 15 '15 at 19:57
6
\$\begingroup\$

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)
\$\endgroup\$

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.