So far, we have already talked about how to construct textures, and moreover, how to construct textures by specifying the bits_per_scalar_element property. Further, we explained how to read from and write to textures in restrict(amp) code. In this post, I’m going to cover how to copy data to and from texture objects, and between texture objects.
Copy-in during construction
First, let’s review how to copy data into a texture during its construction. There are two kinds of constructors that can initialize a texture<T, N> object with data from host memory: passing iterators and passing a raw pointer.
By passing two iterators you can specify the range of input data that you wish to copy to texture memory. Here is an example:
Note that you are not allowed to specify bits_per_scalar_element, so the default bits_per_scalar_element is used. Also note that these constructors are not available if the element type T is norm, unorm, or norm/unorm-based short vector types (because such types do not have a default bits_per_scalar_element).
You can also construct a texture object by passing a raw pointer (void *) to the host data, the size of host data in bytes, and the bits_per_scalar_element. The pointer and the size specify the range of the input data. For example,
For both kinds of constructors, if the amount of input data is not adequate to initialize the texture, a runtime exception will be thrown.
Copy between host data and texture using global copy functions
We have talked about a rich set of copy functions (in concurrency namespace) to accomplish data transfer which involves array or array_view. For texture, we also provide several global copy functions in concurrency::graphics namespace. They provide the functionality for copying host data to texture, and vice versa. You can copy from host data to texture by specifying the range of input data with a pointer and the size.
You can also copy to a writeonly_texture_view. The data is copied to the texture object that the view was created upon.
For both, if the amount of source data is not sufficient to fill the texture, a runtime exception will be thrown.
You can also copy the data out from the texture by specifying the range of output host memory with a pointer and the size.
If the data_length of the source texture is larger than dest_byte_size, a runtime exception will be thrown.
Naturally, there is no ability to copy from a writeonly_texture_view, since the view is write-only. However, you can always copy from the underlying texture, upon which the writeonly_texture_view was created. Note the global copy functions are the only way to copy data from a texture to the host memory.
Below are some examples of copy-in and copy-out using global copy functions.
For each copy function, there is a corresponding copy_async function that performs copy asynchronously. The copy_async function returns a future object that you can wait later. For example,
Copy_to member method
The texture<T, N> class has two member methods called copy_to:
They can be used to copy from this texture object to another texture object. The two textures could be created on different accelerator_views. When copying to a writeonly_texture_view, the data is copied to the texture object that the view was created upon.
It’s required that the bits_per_scalar_element’s must be the same, and that the source and destination texture objects have exactly the same extents. If those requirements are not met, a runtime exception will be thrown.
In this post, I showed that
- you can copy from host data to a texture either at the time of construction or using the global copy function later;
- you can copy data from a texture to host memory using the global copy function;
- you can copy from one texture to another using the copy_to member method of the source texture object.
As always, your feedback is welcome below or in our MSDN Forum.