Avoid sampling at the texture Edge?

I tried creating a soft shadow using FBO (Frame buffer object) and vertex Shader. I first render the shadow and capture it with FBO and attach it to a texture. Because the glTexImage2D method require a n power of 2 width and height so I created an image larger than the screen size and later using the glTexCoord2d to specify the portion of texture that is exactly the same size of my current screen. After that, the texture will be render with the vertex shader to produce a blur effect(sampling).

glUniform1fARB(m_glslSampleDist, fSampleDist);
glUniform1iARB(m_glslFrameBufferTexture, 0);
glBindTexture(GL_TEXTURE_2D, uiFrameBufferTexture);

Everything looks fine except the border or edge of the texture also get affected by the sampling effect and create a Re-sampling artifacts at the edge. I then called the following method

The left edge and bottom edge of the texture is no longer get affected by the sampling effect but the top edge and right edge of the texture still get affecting by the sampling effect. Is there a way to get rid of this problem? Please Advise! Thanks in advance!

Not quite sure if I understand your problem.
Anyway, you should first try using CLAMP_TO_EDGE instead of CLAMP.

Because the glTexImage2D method require a n power of 2 width and height

This is not true anymore. Check extension ARB_texture_non_power_of_two. If you have FBO, then I am almost sure that you have this extension as well.

If you have FBO, then I am almost sure that you have this extension as well.

Not necessarily. The first generation of Shader Model 2.0 GPUs (Radeon 9500+, GeForce FX) did have FBO support but did not support NPOT textures as specified by ARB_texture_non_power_of_two. However, they support ARB_texture_rectangle which has several limitations compared to generic NPOT textures but these shouldn’t be an issue unless you need mipmaps for your texture (which I doubt based on the technique you presented).

My memory of the GeForce FX series (of which my usage was thankfully short-lived) was that they actually did export ARB_texture_non_power_of_two in their extension string, but dropped back to software emulation if you used it. Nasty.

But that’s irrelevant; unless you have a very specific reason to target hardware this old it should be quite safe to work on the basis that NPOT support is a given.

How to know whether my machine support NPOT or not? Is there a way to query the machine?

Check your extensions string for "GL_ARB_texture_non_power_of_two ", although personally I’d use something like GLEW, and would also check for a higher-level extension (something from 3.x) too, just to have a higher chance that it really is supported in hardware. I’d also create a dummy texture and do a glGetError on it to be absolutely certain.

Thanks! I will check it.