[Mesa-dev] Merging translate and unnormalized-coords-hint?
jakob at vmware.com
Mon Aug 16 06:59:56 PDT 2010
On 16 aug 2010, at 14.29, Keith Whitwell wrote:
> 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
>> 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
>> 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
>> 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
> 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
> 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
> is via a new channel we haven't used for queries in the past - ie
> on the driver modifying some of the values in the create-resource
> 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
> 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
> and one for unnormalized, such that OpenCL could set (NORMALIZED |
> Would that work for your needs?
I thought that the discussion pretty much came down to add
Looking at it we have two users of unnormalized coords GL texture rect
and OpenCL. From what I can tell it would require a lot more then just
a normalization hint to support OpenCL properly. And as was stated
even r600 hardware will have some problem supporting unnormalized with
different edge cases. So just creating a new RECT target that matches
what GL wants and then add a cap bit for advanced OpenCL sampling
later on, when we know exactly what OpenCL wants, might be the best
Just my 2 cents.
PS: I know that DX9 requires cards to support a rectangular,
last_level 1 texture with normalized coordinates. But the drivers for
DX9 level hw in Gallium have no user that cares about that case so can
it can be ignored.
More information about the mesa-dev