On Thu, 2009-10-01 at 11:50 -0400, Younes Manton wrote:
> 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.
EXA will call the PrepareAccess hook before and the FinishAccess hook
after every operation on a pixmap, even if it only modifies a single
pixel (or even none, for the source pixmaps).
Now consider the case where the driver can't map the texture storage
directly, e.g. because it needs to (un)tile on recent nVidia GPUs, or
swap bytes with radeon KMS on big endian machines, or because the
storage is simply not accessible in the CPU address space. The
straightforward implementation of these hooks incurs an expensive
transfer from/to the real texture storage every time. For the driver to
minimize the transfers, it would need to grow a complicated damage
tracking logic such as the one already present in EXA. I think it's more
in the spirit of Gallium to let the higher levels deal with it.
--
Earthling Michel Dänzer | http://www.vmware.com
Libre software enthusiast | Debian, X and DRI developer
------------------------------------------------------------------------------
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
