This PR adds FIELD_BUFFER container data-structures to manage packed storage of fields. Data offload of the same location in memory can now be managed either via the buffer, or via the constituent fields. Therefore an important aspect of this PR is the mechanism to ensure FIELD%ISTATUS coherency between a buffer and its children. The approach I have settled for is aimed at keeping the overall amount of memory transfers at a minimum.
Whenever we call data movement methods on the buffer, a check is performed to see if any of the children fields have a different status to the buffer. If the statuses are all the same, then it is safe to do data transfers on a per buffer granularity. If any of the children have a different status to the buffer, then BUFFER%GET_DEVICE/HOST_DATA resorts to per field copies. This is also explained in the README.
Calling CHILD%GET_VIEW, CHILD%GET_HOST/DEVICE_DATA_RDWR or CHILD%SYNC_HOST/DEVICE_RDWR before calling the equivalent method on the buffer, can therefore cause the buffer and children statuses to fall out of sync. They can then be re-synchronised by calls to BUFFER%GET_VIEW, BUFFER%GET_HOST/DEVICE_DATA_RDWR or BUFFER%SYNC_HOST/DEVICE_RDWR.
The advantage this approach has over always keeping the statuses of the children and buffer synchronised is that it allows fewer data transfers if needed. For example, if we had to keep the buffer and child status always synchronised, we would have to copy the entire buffer to device even if we only wanted to use a single child field.
An addition in this PR that wasn't discussed in our call is the CONTIG_FIELDS option. This is a switch that allows the default (...,NBLKS,NFIELDS) layout of the buffer to be switched to (...,NFIELDS,NBLKS) thus making the individual children contiguous in memory. This is not essential by any means, and was just included as a "would be nice to have" option. If there are strong objections to it then I am happy to remove it.
This PR adds
FIELD_BUFFERcontainer data-structures to manage packed storage of fields. Data offload of the same location in memory can now be managed either via the buffer, or via the constituent fields. Therefore an important aspect of this PR is the mechanism to ensureFIELD%ISTATUScoherency between a buffer and its children. The approach I have settled for is aimed at keeping the overall amount of memory transfers at a minimum.Whenever we call data movement methods on the buffer, a check is performed to see if any of the children fields have a different status to the buffer. If the statuses are all the same, then it is safe to do data transfers on a per buffer granularity. If any of the children have a different status to the buffer, then
BUFFER%GET_DEVICE/HOST_DATAresorts to per field copies. This is also explained in the README.Calling
CHILD%GET_VIEW,CHILD%GET_HOST/DEVICE_DATA_RDWRorCHILD%SYNC_HOST/DEVICE_RDWRbefore calling the equivalent method on the buffer, can therefore cause the buffer and children statuses to fall out of sync. They can then be re-synchronised by calls toBUFFER%GET_VIEW,BUFFER%GET_HOST/DEVICE_DATA_RDWRorBUFFER%SYNC_HOST/DEVICE_RDWR.The advantage this approach has over always keeping the statuses of the children and buffer synchronised is that it allows fewer data transfers if needed. For example, if we had to keep the buffer and child status always synchronised, we would have to copy the entire buffer to device even if we only wanted to use a single child field.
An addition in this PR that wasn't discussed in our call is the
CONTIG_FIELDSoption. This is a switch that allows the default(...,NBLKS,NFIELDS)layout of the buffer to be switched to(...,NFIELDS,NBLKS)thus making the individual children contiguous in memory. This is not essential by any means, and was just included as a "would be nice to have" option. If there are strong objections to it then I am happy to remove it.