[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: Steve Baker <email@example.com>
- Date: Thu, 16 Dec 2010 20:16:13 -0600
- Cc: public webgl <firstname.lastname@example.org>
- Dkim-signature: v=1; a=rsa-sha1; c=relaxed; d=sjbaker.org; h=message-id :date:from:mime-version:to:cc:subject:references:in-reply-to :content-type:content-transfer-encoding; s=sjbaker.org; bh=656M+ 8gd2H/oJtht4CrgRSMJGgQ=; b=bQdkBNqWEwaebgqsoW9A2putUP4U0hwzg01As pNqdHAZcBOW3ruax62RNOki+QmkM6+ZHRuUZvgveDfgnYRDOF34k3blvUzMt/xvc CcOVpqQHlvgYmtRV5ccamTED4AQyIQQRd6GuqsXTQExF+NEms7mPDh5UGdqMtQGn q177oc=
- Domainkey-signature: a=rsa-sha1; c=nofws; d=sjbaker.org; h=message-id:date :from:mime-version:to:cc:subject:references:in-reply-to :content-type:content-transfer-encoding; q=dns; s=sjbaker.org; b=FdijMRha7+YR4qEJaqpjUn8rO2sDueeXvV8qPnGPhv8YCJ4X0J+AOF0Me383l miF73Jd9VqBAI2RxrOeu9XeUHCawFruAVQHt6/0plUZT9rAVZBVP4Wqo5zNZzDCr IaMQr7MgzGkojHvmAN5ODNhyrxWDWLaWMAY3IIsNdRMR0k=
- 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
- User-agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:220.127.116.11) Gecko/20100520 SUSE/3.0.5 Thunderbird/3.0.5
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: