[Mesa-dev] Merging translate and unnormalized-coords-hint?

[Keith Whitwell]

On Mon, 2010-08-16 at 04:54 -0700, Luca Barbieri wrote:
> I added the two patchsets I posted to the list to the two branches
> named in the subject.
> 
> The version pushed contain slight changes over the ones sent to the ML:
> 1. In translate, Win64 support has been further fixed to use the
> proper macro (_WIN64) and properly preserve xmm registers
> 2. unnormalized-coords-hint has been changed to add support for
> unnormalized coordinates in st_Bitmap
> 
> There seemed to be no fundamental opposition to the changes, and I
> fixed the issues raised.
> 
> The translate branch can be tested with
> src/gallium/tests/unit/translate_test and the piglit draw-vertices and
> draw-elements test with softpipe.
> The unnormalized-coords-hint branch can be partially tested with
> softpipe and has otherwise been tested as part of work on the nv30
> driver.
> 
> Should I merge them?

I'm very happy to merge the translate code, providing you're satisfied
that the remaining win64 discussion has been concluded.  Also, please
delete the feature branch once it's been merged.


In terms of the unnormalized change, I think I'd like to go over it one
more time.

It looks like there are a few things happening at once:

a) The state tracker is informing the driver whether it will use
normalized texcoords, unnormalized texcoords or both for a given
texture.

b) There is a query from the state tracker to the driver to find out
which it prefers (normalized vs unnormalized) for a given texture.

These two usages seem somewhat disjoint, and the mechanism for the query
is via a new channel we haven't used for queries in the past - ie based
on the driver modifying some of the values in the create-resource
template.

Is this a fair summary of the intentions of the change?  If so, my
request would be to divorce the two meanings of this flag -- keep the
PIPE_RESOURCE_FLAG for state_tracker->driver communications, ie. (a),
and use an explicit query for driver->state_tracker communications, ie
(b).

In this model, the state tracker would query the driver explicitly to
find out what normalization to use for internal rendering, and pass
through the API constraints otherwise.  

To represent all possibilities you'd need two flags, one for normalized
and one for unnormalized, such that OpenCL could set (NORMALIZED |
UNNORMALIZED).

Would that work for your needs?

Keith