On Wed, Aug 18, 2010 at 8:50 AM, Luca Barbieri <l...@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 <mostawesomed...@gmail.com> _______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
