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
cogl_texture_2d and cogl_texture_rectangle instead of talking directly
to the _cogl_texture_driver layer. (I would expect this to be the meat
of the work, but hopefully it's more deleting code than writing code
since it should just be passing work to the cogl_texture_2d/rectangle
code instead of handling it directly.)
* Adapt _cogl_texture_2d_sliced_ensure_mipmaps so that if
_cogl_texture_2d_ensure_mipmaps fails then it should slice the texture
up into POT textures and then try again.
* Do the same for _cogl_texture_2d_sliced_set_wrap_mode_parameters.
In the end this will result in Cogl automatically slicing the texture
into POT textures when you ask for mipmapping or want repeating.
I don't think there's anything too tricky there, though I imagine it
might seem a bit overwhelming if not familiar with Cogl code. The big
bits of work; "Adapt cogl-texture-2d-sliced.c to be implemented in terms of
cogl_texture_2d" and "Add a cogl-texture-rectangle backend" are actually
things we are planning on doing - hopefully soon - anyway so then the
remaining bits should be quite trivial to do afterwards.
If you want to take a stab at adapting sliced textures to be implemented
in terms of 2d textures the basic objective is to be storing CoglHandles
in the sliced_texture->slice_gl_handles array instead of GLuint texture
object names and it would be a case of looking for _cogl_texture_driver_
calls and figuring out how to rework them in terms of
cogl_texture_2d/cogl_texture_rectangle calls instead.
A simpler but more limited approach that won't do automatic slicing if
you enable mipmapping/enable repeating would be to just do this:
* patch the texture_2d backend with some #ifdef HAVE_COGL_GLES2 guards:
* so that the ensure_mipmaps vfunc is a NOP
* so the set_wrap_mode_parameters vfunc is a NOP for anything but
CLAMP_TO_EDGE.
* Add some cogl feature flags to determine if the texture-2d backend
supports mipmapping/repeating for NPOT textures.
Then we can then consider making the cogl_texture_2d_* API public
(something we were alway planning on doing at some point anyway) so that
you can directly construct cogl_texture_2d objects in your application
and it's then your responsibility to understand how they are limited.
I hope that help,
kind regards,
- Robert
>
> Thanks,
> Brian
>
> P.S. Either way, I'd have to add the relevant support to clutter to
> make it work, right?
--
Robert Bragg, Intel Open Source Technology Center
--
To unsubscribe send a mail to clutter+unsubscr...@o-hand.com
