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

[Roland Scheidegger]

On 17.08.2010 16:12, Luca Barbieri wrote:
>> 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.
Well I don't like drivers changing the hints flag on their own,
overwriting what the state tracker set. Hence the suggestion to just
always use normalized coords unless the driver can't handle it (which
can be a usual global query).

> 
>> 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.
I think I'm missing for what such pot textures are used. Sounds weird
that you have pot textures which need unnormalized coords (that case
indeed couldn't be handled by my proposal, though I guess you could
still do the "hack" that the driver changes the unnormalized hint).

> 
> llvmpipe would probably prefer unnormalized coords at least in some
> cases since it saves a multiplication.
This is possible but I don't think we'd care enough.

> 
>> 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.
Hmm yes that's right. I guess it would be possible some hw would for
instance support unnormalized coords not for compressed formats or
something like that but I don't know if that's really the case for any
hw out there.

Roland