[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.
- To: "Gregg Tavares (wrk)" <firstname.lastname@example.org>
- Subject: Re: [Public WebGL] More driver bugs: Getting FRAMEBUFFER_INCOMPLETE for a texture that is not "texture complete" on some cards.
- From: Kenneth Russell <email@example.com>
- Date: Thu, 16 Dec 2010 15:17:41 -0800
- Cc: public webgl <firstname.lastname@example.org>
- Dkim-signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1292541463; bh=cEOkEVrG0XUWNMaBEZnvlH/KzwA=; h=MIME-Version:In-Reply-To:References:Date:Message-ID:Subject:From: To:Cc:Content-Type:Content-Transfer-Encoding; b=ILVd1mW1l8mt2io0XR4dMad2aiFIzKP0rtIFwM/L7EEk0zrr43DpzU4Ecv/5cifdl GtPpSpkHLeLzxArWBwd/Q==
- Dkim-signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=beta; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=xzlqcg+cILvjqpXYoS7AlDRqJ/mOQdTjxGFd54oc7OA=; b=M2KhUz7QR9uqfYIA2XVSPLBcuYG76rCZI3pWc+UFoIwQUUGG/x/UoR0sPMZMdutMGU XVIUq5WnpCryEK5u/rUQ==
- Domainkey-signature: a=rsa-sha1; c=nofws; d=google.com; s=beta; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=bSWoGXKyrrGNcqgDQ/4zGOIdS23vVrCdVUuabU6mU7KCf5Cxeh7csn2VXfBnlhaDa9 sjp8vr4dj8GsGPtJCHDw==
- In-reply-to: <AANLkTi=EgmwtvovtsYRmCox2ZBxKD0A-1R_pw3YBb1DB@mail.gmail.com>
- List-id: Public WebGL Mailing List <public_webgl.khronos.org>
- References: <AANLkTi=EgmwtvovtsYRmCox2ZBxKD0A-1R_pw3YBb1DB@mail.gmail.com>
- Sender: email@example.com
On Thu, Dec 16, 2010 at 3:09 PM, Gregg Tavares (wrk) <firstname.lastname@example.org> 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 return
> 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);
> ASSERT(status == gl.FRAMEBUFFER_COMPLETE);
> 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
> 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
> 3) Change the WebGL spec to have the same requirements so the failure is
> 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_INVALID_FRAMEBUFFER_OPERATION
> on top of GL_FRAMEBUFFER_INCOMPLETE on checkFramebufferStatus.
> 4) ?
Personal preference: (1) (I have seen this issue for a long time in
many products, not just WebGL, and didn't think it was that big a deal
to just set up the texture properly before binding it to an FBO)
followed by (2). I don't support changing the WebGL spec to codify
this incorrect behavior.
You are currently subscribed to email@example.com.
To unsubscribe, send an email to firstname.lastname@example.org with
the following command in the body of your email: