[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Public WebGL] More driver bugs: Getting FRAMEBUFFER_INCOMPLETE for a texture that is not "texture complete" on some cards.

On 12/16/2010 05:09 PM, Gregg Tavares (wrk) wrote:
> So we were informed of a new issue.
> If you bind a texture to a framebuffer and that texture is not
> "texture complete" then on some (all?) nvidia drivers it wrongly
> In other words, 
>    // create a 32x32 texture
>    tex = gl.createTexture();
>    gl.bindTexture(gl.TEXTURE_2D, tex);
>    gl.texImage2D(gl.TEXTURE_2D, 0, gl.RGBA, 32, 32, 0, gl.RGBA,
> gl.UNSIGNED_BYTE, null);
>    // attach that texture to a framebuffer
>    fbo = gl.createFramebuffer();
>    gl.bindFramebuffer(gl.FRAMEBUFFER, fbo);
>    gl.framebufferTexture2D(gl.FRAMEBUFFER, gl.COLOR_ATTACHMENT0,
> gl.TEXTURE_2D, tex, 0);
>    // check that it's complete
>    var status = gl.checkFramebufferStatus(gl.FRAMEBUFFER);
> This code will wrongly fail on some nvidia drivers.
> The issue is apparently that bad nvidia drivers require the textures
> to either have all their mips or be set to use filtering that does not
> require mips. 
> The workaround is to add this line
>    // because the default for a texture is gl.NEAREST_MIPMAP_LINEAR
>    // we need to set it to something that doesn't need mips.
>    gl.texParameteriv(gl.TEXTURE_2D, TEXTURE_MIN_FILTER, gl.LINEAR);
> So, for WebGL what if anything should we do?
> 1) Ignore the issue
>     You couldn't render with the texture without setting filtering
>     anyway. Mostly like you just have to re-order your initialization
>     to set the texParameter before setting up your FBO instead of after.
> 2) Try to fix it inside WebGL implementations
>     I think you'd basically have to track if a texture is being used
>     as an fbo. When it is (either on bindFramebuffer or
>     framebufferTexture2D) you'd have to set its filtering to LINEAR or
>     NEAREST while resetting any previously bound framebuffer texture
>     back to it's original user specified filters. You'd also have to
>     wrap texParameteriv and getTexParameter so that they shadowed the
>     settings since if the texture is currently being used as a render
>     target you can neither set or query its parameters and expect to
>     get the correct result.
> 3) Change the WebGL spec to have the same requirements so the failure
> is consistent
>     You'd again have track which textures are currently being rendered
>     too. Before each draw call you'd have to see if the texture being
>     rendered to meets the conditions above. If not generate
>     GL_FRAMEBUFFER_INCOMPLETE on checkFramebufferStatus.
> 4) ? 

4) Create a website where we document the heck out of these
gotcha's...and then ignore them.  Truly - you can't fix every
implementation bug in every OpenGL implementation in every browser...as
a policy, that's going to cause **SO** much grief.  If it's not a
general policy - than what makes this rather obscure bug more important
than any of the others that are out there?  Having an official,
well-publicized, well-supported, comprehensive "gotcha's" site - with
good work-arounds right there - would be worth it's weight in gold.  It
would also serve as a very public way to gently encourage the driver
writers to fix it!

You are currently subscribed to public_webgl@khronos.org.
To unsubscribe, send an email to majordomo@khronos.org with
the following command in the body of your email: