[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: Steve Baker <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: "Mo, Zhenyao" <email@example.com>
- Date: Thu, 16 Dec 2010 20:31:20 -0800
- Cc: "Gregg Tavares (wrk)" <firstname.lastname@example.org>, public webgl <email@example.com>
- Dkim-signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=oz3JAGpTIKBE4JGAQZbJqvgECYrh0ow16YJ7Y21zqYU=; b=j5KQDEDe0KZLDM0d6NH2375NnLomhRcry/ucXqFWwWPNNFgFy1QXCCfOvPa9ByFatX XeguzA8uGe0rKUqmLkrxB5ZuNN3xBWrnmCyIYfPcJgWOmtsbGhipkjjkOihJcWH2b4XI UZMUhotmZIjcAdA1vWk54kTJrNOXnVspHxCt8=
- Domainkey-signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=LZl2Bumf+ANBCzt1L9BtqbGUMrfyxgrI8HUtDFzBdL3HfCLPyGWOC4uQR1pUpqHark aoSAq1x/J/6MuT8qWbUYx6kI2SyZqrWCiHi9la9JPZaVr7iGM23sviBz+cCaoXZ1Or3z 4wwEFWgkBngHfddXoYNi/M+oFpLsc6oX8feUs=
- In-reply-to: <4D0AC7ED.firstname.lastname@example.org>
- List-id: Public WebGL Mailing List <public_webgl.khronos.org>
- References: <AANLkTi=EgmwtvovtsYRmCox2ZBxKD0A-1R_pw3YBb1DB@mail.gmail.com> <4D0AC7ED.email@example.com>
- Sender: firstname.lastname@example.org
On Thu, Dec 16, 2010 at 6:16 PM, Steve Baker <email@example.com> wrote:
> 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
>> return FRAMEBUFFER_UNSUPPORED.
>> 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 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_INVALID_FRAMEBUFFER_OPERATION on top of
>> 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 firstname.lastname@example.org.
> To unsubscribe, send an email to email@example.com with
> the following command in the body of your email:
You are currently subscribed to firstname.lastname@example.org.
To unsubscribe, send an email to email@example.com with
the following command in the body of your email: