1
\$\begingroup\$

I am doing post processing by drawing to an FBO and then applying a certain fragment shader when drawing the FBO's texture to the screen. I want to use a look-up table texture to apply color grading. Since I am targeting OpenGL ES 2.0 and possibly older PCs, I cannot use 3D textures. Instead I can use a 2D texture as an atlas of the layers of my 3D look-up table.

What I'm concerned about is correctness and performance when the texture lookup is performed. My look-up texture needs to have linear filtering so I don't have to have a full 256^3 sized look-up table to cover all hues.

My fragment shader would look something like this: Round B up and down to get the two regions of the texture to sample from, add offsets accordingly to R/G and sample the texture twice with the two offset .rg values. And finally linearly interpolate based on B.

But I as I understand it, the when the GPU encounters a texture2D call on a texture with linear filtering, it will be calculating the input coordinates for those calls for neighboring pixels in parallel to get a derivative. This derivative is used to determine how to sample the texture pixels.

Since this is a post process, I don't want two neighboring pixels to influence each other. It could be a black pixel from the edge of a sprite next to a bright blue sky pixel. In the look-up table, these two would need to sample distant points. So is the GPU going to decide the derivative is huge (minification) and try to linearly sample and involve all the random in-between texels on my look-up table?

Is there a way to get my linear filter to ignore neighboring pixels and only interpolate from the 4 nearest texels? Sort of like treating everything as magnification?

The problem is similar to this question that was asked in regards to HLSL, but I'm targeting OpenGL 3.0 and OpenGL ES 2.0: Color grading, shaders and 3d textures

\$\endgroup\$
  • \$\begingroup\$ Maybe you could just use point filtering and do the interpolation yourself? \$\endgroup\$ – Lasse Jan 19 '17 at 23:10
  • \$\begingroup\$ @Lasse That should work, but it's 8 calls to texture2D and to mix instead of 1 call to texture2D. I know the resulting math is the same, but will it be as optimized on the GPU? And examples I've seen don't even mention this issue, so I guess part of my question is whether I even need to worry about it. (one example: youtu.be/rfQ8rKGTVlg?t=26m50s) \$\endgroup\$ – TenFour04 Jan 19 '17 at 23:21
1
\$\begingroup\$

That derivative is only used to select which mipmap out the the set to sample.

If mipmaps are disabled either by selecting GL_LINEAR as the minimizing texture sampler interpolation or by setting the mipmap level limit to 0 then the GPU will do a simple linear interpolation.

| improve this answer | |
\$\endgroup\$
  • \$\begingroup\$ So that linear interpolation is limited to the 4 neighboring texels? I've remember in explanations of mip maps that they help with performance because they avoid the need for sampling many texels and averaging them. But I guess that's theoretical because GPUs don't actually attempt that behind the scenes? The actual issue with linear minimization in practice is moire patterns from undersampling, right? \$\endgroup\$ – TenFour04 Jan 19 '17 at 23:51
  • \$\begingroup\$ The reason mipmaps improve performance is that if for example the GPU is sampling every 4 texels the GPU cache still has to load an entire chunk of 4x4 texels (generally speaking) for each due to the way the texture cache and/or texture compression works. Using a mipmaps makes sure the GPU will be loading the reduced version and not waste cache space and memory bandwidth with unused texels. \$\endgroup\$ – Stephane Hockenhull Jan 20 '17 at 0:02
  • \$\begingroup\$ I'm more familiar with hlsl syntax, where we have tex2DLOD and tex2DGrad variants of the texture sampling function which let us control how the mipmap sampling occurs. I've used these in the past to avoid undesired blurring at sharp discontinuities, without losing the performance and aliasing benefits of mipmapping completely. If you have analogues in the OpenGL version you're targeting, those may also be an option. \$\endgroup\$ – DMGregory Jan 20 '17 at 13:45

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.