[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Public WebGL] NPOT (non-power-of-two) textures
On Jan 16, 2010, at 6:06 PM, Kenneth Russell wrote:
> On Sat, Jan 16, 2010 at 4:15 PM, Chris Marrin <firstname.lastname@example.org> wrote:
>> Ok, I have some new data. Seems that the demos that were falling because I had turned on mipmapping. I used generateMipmap and was using LINEAR_MIPMAP_LINEAR for the minification filter. That's what was causing his hardware to fall back to software. It is the fact that the X1600 hardware can do NPOT textures only when non-mipmapped is what makes it non-compliant with the RB_texture_non_power_of_two extension.
>> So that brings up a similar, but somewhat less serious issue. What should be done in cases like this, where the hardware is "almost" compliant, but not quite. Is the best approach:
>> 1) Disallow this hardware from using WebGL (have it return a null pointer from getContext())?
>> 2) Allow use of this hardware for WebGL, but disallow the use of mipmaps with NPOT textures. Have glError return an error when either calling texImage2D with a NPOT texture and LINEAR_MIPMAP_LINEAR is set, or when setting LINEAR_MIPMAP_LINEAR when a NPOT texture is set.
> These semantics aren't workable. It's a basic expectation that the
> developer is allowed to call texImage2D and texParameteri in any order
> against a given texture object; they shouldn't be required to change
> the default minification filter from LINEAR_MIPMAP_LINEAR before
> uploading NPOT texture data.
>> 3) Allow use of this hardware for WebGL, but replace LINEAR_MIPMAP_LINEAR with LINEAR when an NPOT texture is in use.
> This seems too magical. See below.
>> 4) Do nothing other that add some words in a non-normative spec section warning the author that some older hardware will fall back to software (or fail to work?) when using NPOT with mipmaps.
>> (1) seems pretty harsh for such a minor issue. I would be fine with any of the other 3 choices.
> The OpenGL ES spec is clear about what the behavior should be in this
> case. Section 3.8.2 says that if a two-dimensional sampler is called
> in a fragment shader for a non-power-of-two texture and either the
> wrap mode is not CLAMP_TO_EDGE, or the minification filter is not
> NEAREST or LINEAR, then the sampler returns the color (0, 0, 0, 1).
Ugh, once again the vagaries of the various OpenGL specs bites me in the ass. OpenGL ES does not support the same NPOT capabilities as OpenGL! So this is just a matter of properly simulating the GLES NPOT capability in desktop OpenGL. That makes things much easier. So the changes I made to my demos brings them into WebGL spec compliance. Now we just need to fix the WebKit implementation.
> We can implement this behavior in WebGL running on top of desktop GL
> by swapping out any NPOT textures that are not set up correctly with a
> 1x1 black texture when a draw call is made, and restoring them after
> the draw call. Going forward, there seems to be some discussion of
> convergence between desktop GL and GL ES, so I think we would be wise
> to implement the GL ES semantics rather than invent new ones.
Right. Have you opened a bug in WebKit for this yet?
Vlad, how does your implementation handle this case?
You are currently subscribe to email@example.com.
To unsubscribe, send an email to firstname.lastname@example.org with
the following command in the body of your email: