> 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.
I think this is essentially equivalent to my latest patchset in the following sense: - Your PIPE_TEXTURE_RECT is equivalent to my PIPE_BIND_SAMPLER_VIEW_UNNORMALIZED_CLAMP - Your PIPE_TEXTURE_2D is equivalent to my PIPE_BIND_SAMPLER_VIEW_NORMALIZED I think a bind flag is the more appropriate way to represent this, because: 1. If we don't ever create a sampler view (e.g. render target) this doesn't a matter 2. Most checks for PIPE_TEXTURE_2D don't care about this, but only about the physical dimensions. Drivers that have multiple layouts already have internal flags for them. > b) Adding a pipe cap to determine hardware preference for state-tracker > generated rendering (prefer TEXTURE_RECT vs TEXTURE_2D). For API I think a single global cap is insufficient: - r300g and i965 always prefer normalized coordinates for internal drawing (since they emulate unnormalized with a multiply) even for GL_TEXTURE_RECTANGLE - llvmpipe might perhaps always prefer unnormalized for internal drawing - nv30 requires normalized or requires unnormalized depending on texture layout Hence, you at least need two global caps: one for the preference related to TEXTURE_RECT/BIND_UNNORMALIZED_CLAMP, and one for the preference related to TEXTURE_2D/BIND_NORMALIZED. However, the state tracker itself has multiple preferences (it either wants unnormalized to avoid CPU divides if it uses a subrectangle, or it wants normalized to use 0, 1 constants if it uses the whole textures), so the driver ideally should be able to specify "no preference". Thus, we need 4 bits of global caps at least. IMHO using global caps leads to a messier situation that is instead cleanly avoid with per-resource caps. Are there any downsides to per-resource "caps"? _______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
