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.
_______________________________________________
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
