[Mesa-dev] gallium & texture rectangles

[Corbin Simpson]

On Wed, Aug 18, 2010 at 8:50 AM, Luca Barbieri <luca at luca-barbieri.com> wrote:
>> 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.

I have a feeling that CL performance will not matter that much for
nvfx and r300, compared to nv50 and r600.

> 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.

r300 having to emit a shader instruction unconditionally in this case
really isn't that big of a deal. We don't blit that often, and we're
still coming out far ahead of where we'd be if we were turning on the
2D engine for every blit.

-- 
When the facts change, I change my mind. What do you do, sir? ~ Keynes

Corbin Simpson
<MostAwesomeDude at gmail.com>