Struct ocl::builders::BufferMapCmd[][src]

#[must_use = "commands do nothing unless enqueued"]
pub struct BufferMapCmd<'c, T> where
    T: 'c + OclPrm
{ /* fields omitted */ }

A command builder used to enqueue a map command.

Enqueuing a map command will map a region of a buffer into the host address space and return a MemMap or FutureMemMap, allowing access to this mapped region. Accessing memory via a MemMap is exactly like using a slice.

See SDK docs for more details.

Methods

impl<'c, T> BufferMapCmd<'c, T> where
    T: OclPrm
[src]

Specifies the flags to be used for this map command.

Flags can also be specified using the ::read, ::write, and ::write_invalidate methods instead.

See SDK docs for more details.

Specifies that the memory object is being mapped for reading.

Sets the flag to be used for this map command to [CL_]MAP_READ.

This is the fastest way to move data from device to host for many use cases when used with buffers created with the MEM_ALLOC_HOST_PTR or MEM_USE_HOST_PTR flags.

Specifies that the memory object is being mapped for writing.

Sets the flag to be used for this map command to [CL_]MAP_WRITE.

This is not the most efficient method of transferring data from host to device due to the memory being synchronized beforehand. Prefer ::write_invalidate unless you need the memory region to be updated (e.g. if you are only writing to particular portions of the data, and will not be overwriting the entire contents, etc.). Use this with buffers created with the MEM_ALLOC_HOST_PTR or MEM_USE_HOST_PTR flags for best performance.

Specifies that the memory object is being mapped for writing and that the local (host) memory region may contain stale data that must be completely overwritten before unmapping.

Sets the flag to be used for this map command to [CL_]MAP_WRITE_INVALIDATE_REGION.

This option may provide a substantial performance improvement when writing and is the fastest method for moving data in bulk from host to device memory when used with buffers created with the MEM_ALLOC_HOST_PTR or MEM_USE_HOST_PTR flags. Only use this when you will be overwriting the entire contents of the mapped region otherwise you will send stale or junk data to the device.

Specifies the length of the region to map.

If unspecified the entire buffer will be mapped.

Specifies a queue to use for this call only.

Overrides the buffer's default queue if one is set. If no default queue is set, this method must be called before enqueuing the command.

Sets the linear offset for an operation.

Panics

The 'shape' may not have already been set to rectangular by the ::rect function.

Specifies an event or list of events to wait on before the command will run.

When events generated using the ::enew method of other, previously enqueued commands are passed here (either individually or as part of an EventList), this command will not execute until those commands have completed.

Using events can compliment the use of queues to order commands by creating temporal dependencies between them (where commands in one queue must wait for the completion of commands in another). Events can also supplant queues altogether when, for example, using out-of-order queues.

Example

This example is not tested
// Create an event list:
let mut event_list = EventList::new();
// Enqueue a kernel on `queue_1`, creating an event representing the kernel
// command in our list:
kernel.cmd().queue(&queue_1).enew(&mut event_list).enq()?;
// Map a buffer using `queue_2`, ensuring the map does not begin until
// after the kernel command has completed:
buffer.map().queue(&queue_2).ewait(&event_list).enq_async()?;

Specifies the destination to store a new, optionally created event associated with this command.

The destination can be a mutable reference to an empty event (created using Event::empty) or a mutable reference to an event list.

After this command is enqueued, the event in the destination can be passed to the ::ewait method of another command. Doing so will cause the other command to wait until this command has completed before executing.

Using events can compliment the use of queues to order commands by creating temporal dependencies between them (where commands in one queue must wait for the completion of commands in another). Events can also supplant queues altogether when, for example, using out-of-order queues.

Example

This example is not tested
// Create an event list:
let mut event = Event::empty();
// Enqueue a kernel on `queue_1`, creating an event representing the kernel
// command in our list:
kernel.cmd().queue(&queue_1).enew(&mut event).enq()?;
// Map a buffer using `queue_2`, ensuring the map does not begin until
// after the kernel command has completed:
buffer.map().queue(&queue_2).ewait(&event).enq_async()?;

Enqueues a map command, blocking the current thread until it completes and returns a reference to the mapped memory.

Safety

The caller must ensure that either only one mapping of a buffer exists at a time or that, if simultaneously mapping for the purposes of sub-region access or whole-buffer aliasing, no two mappings will allow writes to the same memory region at the same time. Use atomics or some other synchronization mechanism to ensure this.

Enqueues a map command and returns a future representing the completion of that map command.

The returned future will resolve to a reference to the mapped memory.

Safety

The caller must ensure that either only one mapping of a buffer exists at a time or that, if simultaneously mapping for the purposes of sub-region access or whole-buffer aliasing, no two mappings will allow writes to the same memory region at the same time. Use atomics or some other synchronization mechanism to ensure this.

Auto Trait Implementations

impl<'c, T> !Send for BufferMapCmd<'c, T>

impl<'c, T> !Sync for BufferMapCmd<'c, T>