----------------- In terms of the unnormalized change, I think I'd like to go over it one more time.
It looks like there are a few things happening at once: a) The state tracker is informing the driver whether it will use normalized texcoords, unnormalized texcoords or both for a given texture. b) There is a query from the state tracker to the driver to find out which it prefers (normalized vs unnormalized) for a given texture. These two usages seem somewhat disjoint, and the mechanism for the query is via a new channel we haven't used for queries in the past - ie based on the driver modifying some of the values in the create-resource template. Is this a fair summary of the intentions of the change? ------------------ On Mon, 2010-08-16 at 07:20 -0700, Luca Barbieri wrote: > > Is this a fair summary of the intentions of the change? > It's an excellent summary. (Just adding it back in...) What's wrong with addressing these needs respectively by: a) Adding a new pipe_texture_target enum PIPE_TEXTURE_RECT to capture the GL usage (unnormalized, clamp). Think about CL later. b) Adding a pipe cap to determine hardware preference for state-tracker generated rendering (prefer TEXTURE_RECT vs TEXTURE_2D). For API rendering (ie non-state-tracker-generated), pass through exactly what the API asks for. Roland suggested an alternate mechanism for b: adding a cap for whether the hw supports NPOT + normalized, which would also be fine for me. Keith _______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
