[Mesa-dev] Merging translate and unnormalized-coords-hint?
luca at luca-barbieri.com
Tue Aug 17 08:22:25 PDT 2010
> 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
- Your PIPE_TEXTURE_RECT is equivalent to my
- 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
- 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
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"?
More information about the mesa-dev