You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
A "vector" (an ADL wrapper over OpenCL memory buffers) has two "sides": Host-side and Device-side. The host side is unit; in other words, there's a single one in the model. It potentially shares state, or communicates with, one or more devices through this buffer.
By OpenCL's definition, coherency is guaranteed as long as the devices are in the same context. Provided the library will manage the context (and allow the user to create one with more than one device), that leaves us to only worry about how to keep the buffer synchronized between operators' executions, both in the host and in devices.
A vector will have a cache/coherency state for each side of the model: one for the host, and one or more for the devices. The states will be managed per-scheduler (just not sure where it'll be stored exactly, perhaps in the vector itself, in a map). These are the states:
clean
dirty
flusing
For now, the focus is on OpenCL, but for a future CUDA or Vulkan implementation, the OpenCL coherency argument won't hold. The intention is to provide a model that allows the user to reuse the same API for multiple backends.
The text was updated successfully, but these errors were encountered:
A "vector" (an ADL wrapper over OpenCL memory buffers) has two "sides": Host-side and Device-side. The host side is unit; in other words, there's a single one in the model. It potentially shares state, or communicates with, one or more devices through this buffer.
By OpenCL's definition, coherency is guaranteed as long as the devices are in the same context. Provided the library will manage the context (and allow the user to create one with more than one device), that leaves us to only worry about how to keep the buffer synchronized between operators' executions, both in the host and in devices.
A vector will have a cache/coherency state for each side of the model: one for the host, and one or more for the devices. The states will be managed per-scheduler (just not sure where it'll be stored exactly, perhaps in the vector itself, in a map). These are the states:
clean
dirty
flusing
For now, the focus is on OpenCL, but for a future CUDA or Vulkan implementation, the OpenCL coherency argument won't hold. The intention is to provide a model that allows the user to reuse the same API for multiple backends.
The text was updated successfully, but these errors were encountered: