On Thu, Oct 1, 2009 at 11:29 AM, Michel Dänzer <mic...@daenzer.net> wrote:
> On Thu, 2009-10-01 at 16:16 +0100, José Fonseca wrote:
>> On Thu, 2009-10-01 at 07:44 -0700, Michel Dänzer wrote:
>> > From: Michel Dänzer <daen...@vmware.com>
>> >
>> > Asks the driver to map the texture storage directly or return NULL if
>> > that's
>> > not possible.
>> > ---
>> > src/gallium/include/pipe/p_defines.h | 13 ++++++++++++-
>> > 1 files changed, 12 insertions(+), 1 deletions(-)
>> >
>> > diff --git a/src/gallium/include/pipe/p_defines.h
>> > b/src/gallium/include/pipe/p_defines.h
>> > index ad42bef..f8fa1e3 100644
>> > --- a/src/gallium/include/pipe/p_defines.h
>> > +++ b/src/gallium/include/pipe/p_defines.h
>> > @@ -193,7 +193,18 @@ enum pipe_texture_target {
>> > enum pipe_transfer_usage {
>> > PIPE_TRANSFER_READ = (1 << 0),
>> > PIPE_TRANSFER_WRITE = (1 << 1),
>> > - PIPE_TRANSFER_READ_WRITE = PIPE_TRANSFER_READ | PIPE_TRANSFER_WRITE
>> > /**< Read/modify/write */
>> > + /** Read/modify/write */
>> > + PIPE_TRANSFER_READ_WRITE = PIPE_TRANSFER_READ | PIPE_TRANSFER_WRITE,
>> > + /**
>> > + * The transfer should map the texture storage directly. The driver may
>> > + * return NULL if that isn't possible, and the state tracker needs to
>> > cope
>> > + * with that and use an alternative path without this flag.
>> > + *
>> > + * E.g. the state tracker could have a simpler path which maps
>> > textures and
>> > + * does read/modify/write cycles on them directly, and a more
>> > complicated
>> > + * path which uses minimal read and write transfers.
>> > + */
>> > + PIPE_TRANSFER_MAP_DIRECTLY = (1 << 2)
>> > };
>>
>> Michel,
>>
>> To help understand, could you give a concrete example of the "simpler
>> path" and "complicated path"?
>
> See patch 3, and the EXA 'mixed pixmaps' code in xserver >= 1.7. The
> Xorg state tracker uses PIPE_TRANSFER_MAP_DIRECTLY in the EXA
> PrepareAccess hook, as the EXA Prepare/FinishAccess hooks intend a
> direct mapping. If the Gallium driver returns NULL, the Xorg state
> tracker propagates that to EXA, which in turn uses the
> DownloadFrom/UploadToScreen hooks for minimal transfers (with some
> damage tracking overhead).
Just out of curiousity, wouldn't PrepareAccess/DFS/UTS/FinishAccess be
doing whats already done by the driver for pipe transfers in this
case? If in PrepareAccess you create a transfer object does it matter
if it's a direct mapping of your texture or a temp texture? Either way
you'll get mapped access to the contents you want and the driver will
be doing the minimal transfer stuff when the pipe transfer is
created/destroyed. I guess if you want to respect the intentions of
PrepareAccess/DFS/UTS/FinishAccess it makes sense to provide such an
interface, but you could make it all transparent to the Xorg state
tracker and get the same end result no?
------------------------------------------------------------------------------
Come build with us! The BlackBerry® Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay
ahead of the curve. Join us from November 9-12, 2009. Register now!
http://p.sf.net/sfu/devconf
_______________________________________________
Mesa3d-dev mailing list
Mesa3d-dev@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
