By setting the [array::cpu_access_type Data Member](reference/array-class.md#array__cpu_access_type) property of an `array` explicitly, you can exercise fine-grained control over how shared memory is used, so that you can optimize the app for the hardware’s performance characteristics, based on the memory access patterns of its computation kernels. An `array_view` reflects the same `cpu_access_type` as the `array` that it’s associated with; or, if the array_view is constructed without a data source, its `access_type` reflects the environment that first causes it to allocate storage. That is, if it’s first accessed by the host (CPU), then it behaves as if it were created over a CPU data source and shares the `access_type` of the `accelerator_view` associated by capture; however, if it's first accessed by an `accelerator_view`, then it behaves as if it were created over an `array` created on that `accelerator_view` and shares the `array`’s `access_type`.

You can read from a `texture` object by using [texture::operator\[\]](reference/texture-class.md#texture__operator_at), [texture::operator() Operator](reference/texture-class.md#texture__operator_call), or [texture::get Method](reference/texture-class.md#texture__get). [texture::operatorOperator](reference/texture-class.md#texture__operator.md) and [texture::operator() Operator](reference/texture-class.md#texture__operator\(\)%20Operator.md) return a value, not a reference. Therefore, you cannot write to a `texture` object by using `texture::operator\[\]`.

Texture views whose elements are based on floating-point types—for example, float, float_2, or float_4—can also be read by using texture sampling to take advantage of hardware support for various filtering modes and addressing modes. C++ AMP supports the two filtering modes that are most common in compute scenarios—point-filtering (nearest-neighbor) and linear-filtering (weighted average)—and four addressing modes—wrapped, mirrored, clamped, and border. For more information about filtering modes, see [filter_mode Enumeration](reference/concurrency-namespace-enums-amp.md#filter_mode); for more information about addressing modes, see [address_mode Enumeration](reference/concurrency-namespace-enums-amp.md#address_mode_enumeration).

|[accelerator::get_default_cpu_access_type Method](#accelerator__get_default_cpu_access_type_method)|Returns the default [access_type](../../../parallel/concrt/reference/concurrency-namespace-enums.md#access_type_enumeration) for buffers created on this accelerator.|

|[accelerator::set_default_cpu_access_type Method](#accelerator__set_default_cpu_access_type_method)|Sets the default CPU [access_type](../../../parallel/concrt/reference/concurrency-namespace-enums.md#access_type_enumeration) for arrays and implicit memory allocations made on this `accelerator`.|

|[accelerator::default_cpu_access_type Data Member](#accelerator__default_cpu_access_type_data_member)|Gets or sets the default CPU [access_type](../../../parallel/concrt/reference/concurrency-namespace-enums.md#access_type_enumeration) for arrays and implicit memory allocations made on this `accelerator`.|

The default cpu [access_type](../../../parallel/concrt/reference/concurrency-namespace-enums.md#access_type_enumeration) for arrays and implicit memory allocations made on this this `accelerator`.

|[accelerator_view::get_is_auto_selection Method](#accelerator_view__get_is_auto_selection_method)|Returns a Boolean value that indicates whether the runtime will automatically select an appropriate accelerator when the `accelerator_view` object is passed to a [parallel_for_each](concurrency-namespace-functions-amp.md#parallel_for_each_function).|

|[accelerator_view::is_auto_selection Data Member](#accelerator_view__is_auto_selection_data_member)|Gets a Boolean value that indicates whether the runtime will automatically select an appropriate accelerator when the `accelerator_view` object is passed to a [parallel_for_each](concurrency-namespace-functions-amp.md#parallel_for_each_function).|

An `accelerator_view` object can have one of two [queuing_mode Enumeration](concurrency-namespace-enums-amp.md#queuing-mode-enumeration) states. If the queuing mode is `immediate`, commands like `copy` and `parallel_for_each` are sent to the corresponding accelerator device as soon as they return to the caller. If the queuing mode is `deferred`, such commands are queued up on a command queue that corresponds to the `accelerator_view` object. Commands are not actually sent to the device until `flush()` is called.