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

[Roland Scheidegger]

On 17.08.2010 09:09, Luca Barbieri wrote:
> This is a new approach to the coordinate normalization issue.
> I only compile tested this, and posted it to find out if I'm on the right
> track, and will do more testing if so.
> 
> On the state tracker -> driver front, I no longer have any resource flags and
> instead split PIPE_BIND_SAMPLER_VIEW into 4 separate flags.
> 
> Those are:
> PIPE_BIND_SAMPLER_VIEW_ANY: asks for a normalization of the driver's choice
> PIPE_BIND_SAMPLER_VIEW_NORMALIZED: asks for normalized, any wrap mode
> PIPE_BIND_SAMPLER_VIEW_UNNORMALIZED_CLAMP: asks for unnormalized, clamp mode
> PIPE_BIND_SAMPLER_VIEW_UNNORMALIZED_NON_CLAMP: asks for unnormalized, non-clamp
> 
> And PIPE_BIND_SAMPLER_VIEW_ALL which is an OR of them all.
> All of these imply PIPE_BIND_SAMPLER_VIEW_ANY.
> 
> I think this is the conceptually cleanest approach, even though it requires
> to modify all instances of PIPE_BIND_SAMPLER_VIEW (hence the long diffstat).
> 
> 
> On the driver -> state tracker front, I split the flag into two flags.
> This allows the driver to either express no preference, or express any of the
> two preferences.
> 
> I haven't (yet?) replaced them with a query, since Keith hasn't elaborated
> on his idea yet, and I don't like all the ways of adding a query I can think
> of myself very much (less CPU-efficient, more driver code, no apparent gain).
> 
> What do you think? Is this the right thing?

I don't like it, imho adds too much interface clutter with little gain
(for most hardware). I liked the original idea much better, though I
don't quite understood why you needed to change the hint in the driver.
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?
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).
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).

Roland