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

[Jakob Bornecrantz]

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  
>> 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?

I thought that the discussion pretty much came down to add  
PIPE_TEXTURE_RECT?

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  
solution.

Just my 2 cents.

Cheers Jakob.

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.