Excerpts from Brian J. Tarricone's message of Wed Apr 21 09:59:34 +0100 2010:
Hi Robert,
On 04/20/2010 04:11 PM, Robert Bragg wrote:
It might be worth investigating if your GLES platform supports this
extension:
http://www.khronos.org/registry/gles/extensions/OES/OES_texture_npot.txt
I'm a bit new to OpenGL (and GLES), so please bear with me if what I'm
asking is silly/obvious.
I'm working on an embedded platform that has EGL and GLES 2.0. Our
driver reports it supports GL_ARB_texture_rectangle. I know cogl's GL
backend will make use of texture_rectangle, but, when I was poking into
cogl's GLES backend (during the 1.0.x time frame), it looked like there
wasn't support for texture_rectangle.
Oh interesting I haven't seen a GLES driver with the
ARB_texture_rectangle extension but it's plausible that your hardware
isn't capable of supporting all the features of texture_npot but it does
have enough for texture_rectangle.
I'm not really sure what the texture_rectangle extension gives you
beyond what core GLES 2.0 requires anyway. Core GLES 2.0 supports NPOT
textures but not mipmapping and limited repeat modes. (I think just
CLAMP_TO_EDGE) The texture_rectangle extension also doesn't support
mipmapping and has limited repeat modes. The big difference with
texture rectangle that might explain why they added the extension is
that you don't use normalized texture coordinates to sample from them.
Normal TEXTURE_2D textures have coordinates in the range [0,1] but
TEXTURE_RECTANGLE textures use coordinates in the range
[0,texture_width/height].
It can sometimes be convenient to use TEXTURE_RECTANGLE textures in
shaders since it's simpler to use them as lookup tables. Using
TEXTURE_2D textures involves calculating a floating point delta to allow
indexing of specific texels in your texture.
Is it a mistake that our GPU vendor is supporting texture_rectangle on
GLES? Should we ask them to support OES_texture_npot instead or in
addition? (It looks like texture_npot has fewer restrictions than
texture_rectangle, anyway, which is nice.) Or is it normal and accepted
to sometimes see texture_rectangle on GLES implementations?
I don't know if it's a mistake; but unless you want a texture that
doesn't use normalized texture coordinates I don't think it buys you
anything over the basic support for NPOT textures that GLES 2 already
comes with.
The Cogl OpenGL backend doesn't really support texture_rectangle it just
allows you to use cogl_texture_new_from_foreign with TEXTURE_RECTANGLE
and it understands that they don't have normalized coordinates. I would
expect for GLES 2.0 you could also use cogl_texture_new_from_foreign to
create NPOT TEXTURE_2D textures and avoid having to use
texture_rectangle. The problems would be that you can't enable mipmaping
for such textures or use anything but the CLAMP_TO_EDGE repeat mode.
(Note: if you aren't using Clutter master though you don't have explicit
control over the repeat modes so you would need to patch Cogl to work
around this.)
Getting the same level of support for texture_rectangle as we have for
OpenGL should be easy if you want to experiment with it, since most of
the CoglTexture code is shared between GL and GLES. You can search for
#if HAVE_COGL_GL guards in cogl-texture-2d-slice.c; remove them; tweak
_cogl_texture_driver_allows_foreign_gl_target to allow the
COGL_TEXTURE_RECTANGLE_ARB target and then you'll have to use
cogl_texture_new_from_foreign, which means you have to create the
texture manually with raw GL calls and you have to be very careful to
restore any GL state you modify while creating the texture so you don't
confuse any state caching Cogl does internally. The only reason we have
texture_rectangle support for OpenGL is to support texture_from_pixmap
on some limited GPUs.
If possible I would ask the vendor if they can support OES_texture_npot
since that would make your life *much* easier. It's very possible though
that your hardware can't support the extension though.
Adding better support for the limited NPOT textures that GLES 2 exposes to
Cogl could be done something like this:
* Make the ensure_mipmaps vfunc for all texture backends return a boolean
status so it may fail.
* Make the set_wrap_mode_parameters vfunc for all texture backends
return a boolean status so it may fail.
* patch the texture_2d backend with some #ifdef HAVE_COGL_GLES2 guards:
* so that it always returns FALSE in the ensure_mipmaps vfunc.
* so it returns FALSE in set_wrap_mode_parameters for anything but
CLAMP_TO_EDGE.
* patch cogl_texture_new_from_bitmap and cogl_texture_new_with_size
with some #ifdef HAVE_COGL_GLES2 guards so we never try and create
and return a _cogl_texture_2d directly.
* Add a cogl-texture-rectangle backend. This should basically be a copy
of cogl-texture-2d.c backend except replace occurrences of TEXTURE_2D
with TEXTURE_RECTANGLE.
* Adapt cogl-texture-2d-sliced.c to be implemented in terms of
