> 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. _______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
