On 17.08.2010 16:53, Keith Whitwell wrote: > ----------------- > 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. >
Yes, this is pretty much the same throughout - if you have a resource unnormalized hint or just use a different target is pretty equivalent too (except the former allows drivers to completely ignore it). Though I guess there are the finer subtleties of "normal" GL 2.0 npot textures - e.g. maybe you'd want to fix coords in the generated fragment shader for hw which can't handle npot+normalized (if you pretend to support GL 2.0), but you'd still wanted the internal blit code to use unnormalized coords for such textures. Though if we'd allow the driver to change the template hint (or the target type but that seems a little less clean) that wouldn't be a problem. Hmm that's all a mess. And if there's some case where we'd prefer unnormalized coordinates even when the hw can do normalized, we can't really express that here - for that the other proposal is better suited. Roland _______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
