[Mesa-dev] [RFC] [PATCH 0/4] New coordinate normalization patches with bind flags

[Luca Barbieri]

> I don't like it, imho adds too much interface clutter with little gain
> (for most hardware).
There is a tradeoff here between a clean and general but intrusive
approach (this one), and a minimal but conceptually imperfect approach
(the previous one).
Keith didn't seem to like the previous minimal patchset, so I proposed this one.

> I liked the original idea much better, though I
> don't quite understood why you needed to change the hint in the driver.
For instance, r300 apparently always likes normalized coordinates,
while nv30 needs unnormalized coords for NPOT, so the driver must
provide some information to make this work.

> As for if the internal code should use normalized or unnormalized
> coords, wouldn't it be much easier to add a pipe query like
> "SUPPORTS_NPOT_NORMALIZED" and then use unnormalized based on that and
> the resource hint, otherwise just use always normalized?
I'm not sure I understand this fully: you seem to propose to use
_both_ a resource hint and a global cap.
But if you have a resource hint, then why would you need a global cap as well?
This patchset uses just a resource hint, or more precisely two bits of
hint, so that all 3 states (prefer unnormalized, prefer normalized, no
preference) can be represented.

> It seems there's no hardware which really prefers unnormalized (unless
> it can't do it at all) hence it seems just fine to me to always prefer
> normalized (i965 for instance doesn't support unnormalized coords at all
> for sampling instructions, these are just scaled in the fragment shader).
nv30 apparently only supports unnormalized coordinates on NPOT
textures (due to GL_TEXTURE_RECTANGLE), and thus must prefer
unnormalized in the NPOT case.
The same applies for POT textures with a linear layout.

llvmpipe would probably prefer unnormalized coords at least in some
cases since it saves a multiplication.

> Of course, that doesn't tell you if unnormalized and wrap modes work for
> instance. But there's no need for that currently, and if we have opencl
> support we just have to assume the driver can do it anyway (if it
> supports opencl).
Yes, for this PIPE_CAP_NPOT_TEXTURES should be essentially OK for now,
and we can add other caps when needed.
This patchset however theoretically allows to use is_format_supported
to formulate such queries, and allows to have different support
depending on format.