OpenCL: Reworked SVM support #61
Open
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
The SVM code in
masterassumes SVM support is only available when the major version is two, and assumes fine-grained capabilities (notably by using host memcpy to implement all copies). This seems to be a legacy quick and dirty hack to support Intel integrated GPUs.Intel's OpenCL drivers now support version 3, and the dedicated GPUs don't advertise fine-grained SVM (on my test setup anyway). Moreover, there are now other drivers, such as Mesa's
rusticl, which support coarse-grained SVM.Even coarse-grained SVM has big advantages over OpenCL 1.x memory objects: because we obtain actual pointers, we can perform pointer arithmetic on the host and get correct behavior.
This PR also adds a couple of experimental interfaces to map/unmap SVM regions. I'm not sure about these interfaces. I'm also not sure about what to do wrt host versus device copies. Finally, I'd like to add Vulkan runtime support next, and while Vulkan doesn't support SVM, it does support
buffer_device_addresswhich has similar utility wrt pointer arithmetic. It might be a good time to re-think how the runtime API works.