[patch] Forcing a copy for run-time external data access.

[Jules Bergmann]

This patch adds support for a SYNC_IN_NOPRESERVE flag with Rt_ext_data. 
  It requires the block to be synchronized with the external data when 
the Rt_ext_data is created, and it requires that changes made to the 
external data are not reflected in the original block.  In short, it 
forces data to be copied, even if the block already has the requested 
layout.

The intention is to support FFT backends like SAL that need to 
reorganize data in-place for packing before performing real-to-complex 
FFTs.  The backend would communicate that it requires the input data to 
be copied so that it can pack as necessary.

Applying this to the earlier example:

     operator()(
       const_Vector<T, Block0> in,
       Vector<T, Block1> out)
     {

       // First, determine layout of blocks:
       Rt_layout<1> rtl_in  = block_layout(in.block());
       Rt_layout<1> rtl_out = block_layout(out.block());

       // Second, queury the backend about what layout
       // it can support.
       // Backend will modify rtl_in and rtl_out.
       //
       // For example, it might:
       //  - set strides to unit-stride if it only supports
       //    unit-stride,
       //  - set complex formats to match,
       //  - set dimension-ordering ,
       //  - etc.
       backend_->query_layout(rtl_in, rtl_out);

       // Determine if backend needs to modify the input data
       // (for example, if performing a real-to-complex FFT requires
       // a special packing format).
       //
       // If backend does need to modify it, we'll use SYNC_IN_NOPRESEVE
       // which effectively forces a copy.
       sync_action_type in_sync = backend_->requires_copy(rtl_in)
                                ? SYNC_IN_NOPRESERVE
                                : SYNC_IN;

       // Thrid, create run-time Ext_data objects
       Rt_ext_data<Block0, 1> ext_in (in.block(),  rtl_in,  in_sync);
       Rt_ext_data<Block1, 1> ext_out(out.block(), rtl_out, SYNC_OUT);

       // Fourth, call functions in backend.
       //
       // Some knowledge may get encoded here.  In particular,
       // because split- and interleaved- complex have
       // different types, we need to call the appropriate
       // backend function.  The backends could do this dispatch
       // too.

       // backends don't have functions with mixed split/interleaved
       // arguments.
       assert(rtl_in.complex == rtl_out.complex);
       if (rtl_in.complex == cmplx_inter_fmt)
       {
         backend_->doit(rtl_in.data().as_inter(),
                        rtl_in.stride(0),
                        rtl_out.data().as_inter(),
                        rtl_out.stride(0),
                        out.size());
       }
       else // (rtl_in.complex == cmplx_split_fmt)
       {
         backend_->doit(rtl_in.data().as_split(),
                        rtl_in.stride(0),
                        rtl_out.data().as_split(),
                        rtl_out.stride(0),
                        out.size());
       }
     }

Stefan, this is a bit different than adding the 'force_copy' field to 
the Rt_layout that I was suggesting before.  However, it seems cleaner 
in that the 'force_copy' is not really a property of the layout.  Do you 
think this will work OK?


				-- Jules

-- 
Jules Bergmann
CodeSourcery
jules at codesourcery.com
(650) 331-3385 x705
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: rtex3.diff
URL: <http://sourcerytools.com/pipermail/vsipl++/attachments/20060507/c91bb30f/attachment.ksh>