[Mesa-dev] gallium & texture rectangles

Luca Barbieri luca at luca-barbieri.com
Wed Aug 18 08:50:15 PDT 2010


> For instance use 2D/normalized for internal rendering iff the driver
> advertises CAP_2D_NPOT, otherwise use RECT/non-normalized.

Yes, indeed that makes more sense than adding a new cap for that.

> Hmm - my intention was that TEXTURE_RECT implies non-normalized
> coordinates -- so this doesn't look like it works.

This must not be an absolute rule, because clCreateFromGLTexture2D
can be passed GL_TEXTURE_RECTANGLE textures, that OpenCL can
subsequently sample with any normalization and wrap mode.

Hence, I propose to make this dependent on the hypotetical
PIPE_CAP_FLEXIBLE_SAMPLING cap that would be added when OpenCL
is implemented.

nVidia also has some OpenGL/DirectX interoperability extensions that
might have the same issue.

> I like (1) for reasons of interface simplicity.  If there was an option
> zero, that would be better still...

I'm not sure this is a good idea, because it will cause a (slight)
performance regression in r300g, that doesn't support unnormalized
coordinates and emulates them with a multiply.
In particular, all util_blitter operations on GL_TEXTURE_RECTANGLE
would now require an extra per-pixel multiply on r300g.
In practice it may have no significant effect on performance, but
allowing the driver to express a normalization preference should also
have no significant effect on the complexity of the codebase.


More information about the mesa-dev mailing list