China 
Africa 
Explore chapters and articles related to this topic
Stream Processing Programming with CUDA, OpenCL, and OpenACC
Published in Vivek Kale, Parallel Computing Architectures and APIs, 2019
As a first step in developing OpenCL applications, users need to understand six fundamental data structures: platform, device, context, program, kernel, and command queue. Platform—defines the environment in which computations will take place. Specifically, a host may have one or more compute devices installed.Device—refers to a particular computing component on which computations will be executed. Each compute device consists of compute units, which in turn include processing elements. Compared to the CUDA terminology, compute device corresponds to device in CUDA; compute unit to streaming multi-processor, and processing element to streaming processor in CUDA.Context—defines a space in which kernels can be executed, and where it is possible to manage data and synchronize processing. It includes and refers to one or more devices.Program—an object representing a program that can be defined using source code. A program is created within a specified context.Kernel—defines a function code that can be executed in parallel by work items. The function is defined within a program that must have been created earlier.Command queue—represents a component that allows the submission of operations to a particular device for which the command queue is created. By default, commands submitted to a given queue will be performed in order. However, it is possible to specify out-of-order execution of commands. Commands submitted to a queue include launching a kernel (processing), writing and reading memory objects (such as for initialization of input data before processing on a device and fetching results), as well as synchronization of operations.Memory object—typically, in the context of GPGPU, buffers will be used for representation of data (either input, intermediate, or output) on which kernel functions will operate.Event—can be used for synchronization of invocations of OpenCL functions.
Programming cobots by voice: a pragmatic, web-based approach
Published in International Journal of Computer Integrated Manufacturing, 2023
Tudor B. Ionescu, Sebastian Schlund
The HMI object uses the same means as the operator to interact with the machine at the human-machine interface, for example, pointer devices, keyboard inputs, or tapping. One condition change detected by the condition monitor can lead to one or several interactions being automatically performed by the HMI object. The HMI object is similar to a Page Object (Leotta et al. 2013), which is used in the UI testing domain. In addition to the Page Object, which provides page or panel wrappers, the HMI object provides a concurrent command queue to prevent concurrent access to the input devices if commands are received from the condition monitor and the command interface at the same time. The HMI object wraps the HMI with an application-specific API, which allows clients to manipulate the HMI without explicitly issuing click, type, and other low-level input commands. The wrapper provides interaction methods that correspond to commands received from the condition monitor or through the command interface. The scope of the interaction methods should be small enough to facilitate reusability and broad enough to encompass a number of cohesive interactions (i.e. click on a button, then input some numbers, and then click ok to finalize the interaction). The interaction methods provided by the HMI object are atomic in the sense that they either complete successfully or they rollback the state of the HMI before issuing an error. Ensuring atomicity and handling errors are responsibilities of the HMI object.
Fast and cross-vendor OpenCL-based implementation for voxelization of triangular mesh models
Published in Computer-Aided Design and Applications, 2018
Mohammadreza Faieghi, O. Remus Tutunea-Fatan, Roy Eagleson
As discussed above, the number of work-items required to complete voxelization is equal to the number of mesh triangles . Since OpenCL requires that global size is a multiple of the local size, the program has to determine first the maximum local size that is available in the device such that it can set the global size to the appropriate value that is greater than or equal to . Evidently, OpenCL buffers and pointers will pass further all the variables and arrays required by the kernel. Once the entire data is passed to the device memory and kernel work-items are configured, the command queue will launch the kernel. Following the start of the kernel, a write-only buffer operation is used to pass the voxel data to the host. OpenCL allows two primary modes of device to host memory transfer: i) clEnqueueReadBuffer = reading from the buffer and ii) clEnqueueMapBuffer = mapping device to host memory. The direct comparison of the two options – illustrated in Fig. 7 – implies that memory mapping consistently outperforms the read buffer approach.
Toward Brain-Actuated Mobile Platform
Published in International Journal of Human–Computer Interaction, 2019
Jingsheng Tang, Yadong Liu, Jun Jiang, Yang Yu, Dewen Hu, Zongtan Zhou
In this study, the sequential-MI BCI was employed to recognize six distinct human intents for driving the mobile system. This method was first proposed in our previous work (Jiang et al., 2015; Yu et al., 2016) and successfully applied in robot and car system. It is based on recognition of the three basic MI states (left-hand movement imagination, right-hand movement imagination and idle state), by coding basic MI units in time-domain, multiple MI states are recognized. In particular, during the experiment, the ongoing EEG signals were divided into 2000 ms Epochs with 100 ms intervals. These Epochs were first processed by the common spatial pattern (CSP) to extract spatial patterns. Subsequently, in the trained spatial feature space, the power of the motor-related rhythms banded from 8–20 Hz was extracted. Next, a linear discrimination analysis classifier was used to classify features into left/right or idle states. To further recognize the sequential MI tasks, the validity of the command was detected. In particular, a command is verified as valid as long as this command (left/right) is maintained for more than 2-seconds and ends with an idle state. A valid command will be pushed into a two-length queue; after one valid command is pushed into the queue, a 2-second window period is set for waiting for the next command. If no command is detected, the one length sequential command is confirmed. On the other hand, if the second valid command is detected, the two lengths of sequential command is confirmed. After a sequential command is detected, the command queue is cleared and the system awaits a new command. In this way, six sequential MI tasks can be recognized.