The Unified SVM specification currently includes a capability to indicate that this type of SVM has a "single address space" capability: CL_SVM_CAPABILITY_SINGLE_ADDRESS_SPACE_KHR. This capability indicate that SVM allocations are from the same address space as the host process, meaning that an SVM allocation (allocated via clSVMAlloc or the new clSVMAllocWithPropertiesKHR) will never alias a host allocation (allocated via malloc, or new, or some other host allocator).
I think we should consider removing this capability, because the way the SVM APIs are currently setup effectively requires this property. Specifically, the clEnqueueSVMMemcpy doesn't include any notion of the memcpy "direction", and hence relies on knowledge of the source and destionation pointers to determine when a memcpy is a host-to-SVM memcpy, an SVM-to-host memcpy, or an SVM-to-SVM memcpy. If host and SVM pointers were allowed to alias, the implementation would not be able to make this determination, and information about the memcpy "direction" would need to be provided using some other mechanism.
If a future extension decides to add an additional SVM type with some other form of memcpy "direction" then it could add a "single address space" capability at this time, as part of the same extension.
The main disadvantage if we were to remove the single address space capability for now, and add it in a future extension, is that all of the code written prior to the extension wouldn't know to check for the (initially non-existent) capability. Perhaps this is a reason to keep the capablity for now, even if it's effectively required by all types of SVM currently?
Or, perhaps, do we need to provide guideance or some other mechanism to ignore or filter out new capabilities that are added by layered extensions?
The Unified SVM specification currently includes a capability to indicate that this type of SVM has a "single address space" capability:
CL_SVM_CAPABILITY_SINGLE_ADDRESS_SPACE_KHR. This capability indicate that SVM allocations are from the same address space as the host process, meaning that an SVM allocation (allocated viaclSVMAllocor the newclSVMAllocWithPropertiesKHR) will never alias a host allocation (allocated via malloc, or new, or some other host allocator).I think we should consider removing this capability, because the way the SVM APIs are currently setup effectively requires this property. Specifically, the
clEnqueueSVMMemcpydoesn't include any notion of the memcpy "direction", and hence relies on knowledge of the source and destionation pointers to determine when a memcpy is a host-to-SVM memcpy, an SVM-to-host memcpy, or an SVM-to-SVM memcpy. If host and SVM pointers were allowed to alias, the implementation would not be able to make this determination, and information about the memcpy "direction" would need to be provided using some other mechanism.If a future extension decides to add an additional SVM type with some other form of memcpy "direction" then it could add a "single address space" capability at this time, as part of the same extension.
The main disadvantage if we were to remove the single address space capability for now, and add it in a future extension, is that all of the code written prior to the extension wouldn't know to check for the (initially non-existent) capability. Perhaps this is a reason to keep the capablity for now, even if it's effectively required by all types of SVM currently?
Or, perhaps, do we need to provide guideance or some other mechanism to ignore or filter out new capabilities that are added by layered extensions?