Unified SVM Concurrent Access Atom Size

[bashbaug]

This issue is to track discussion regarding adding a "concurrent access atom size" to the unified SVM extension. Specifically, this is a proposed resolution to the issue recorded in the document:

Is there a minimum supported granularity for concurrent access? For example, might it be possible to concurrently access different pages of an allocation, but not different bytes within the same page?

The current proposed resolution is to add a device query for CL_DEVICE_SVM_CONCURRENT_ACCESS_ATOM_SIZE_KHR. The proposed description for this query is:

Queries the size and alignment in bytes that bound concurrent access to SVM allocations. The returned value must be zero or a power of two.

If the device does not support concurrent access to SVM allocations, then the query must return 0, indicating that concurrent access is not supported. If the query for CL_DEVICE_SVM_CAPABILITIES includes CL_DEVICE_SVM_FINE_GRAIN_BUFFER or CL_DEVICE_SVM_FINE_GRAIN_SYSTEM, then the query must return one, indicating that concurrent access occurs at the granularity of individual bytes within allocations.

Some of the open questions recorded in the doc are:

1. Do we want to distinguish between host concurrent access and device concurrent access, even if the only query we define for now is for host concurrent access?

2. Are we OK with a single query for all types of SVM, or do we need a separate query for each SVM type?

3. Is this only for concurrent access without atomic access?

We agreed in the memory subgroup call on September 9th that the query should return a size_t, even though it seems exceedingly unlikely that the concurrent access atom size will not be representable in 32 bits.

Noting for reference: the name and idea behind a "concurrent access atom size" was borrowed from Vulkan, see VkPhysicalDeviceLimits::nonCoherentAtomSize.