USM spec should have a reasons why SVM is broken

[airlied]

I've read the USM spec and I think it really needs a small section (unless I missed it) stating why the current SVM APIs aren't suitable and what this allows that they don't.

[bashbaug]

Sure, good idea, I'll add this. Here is a brief summary before the spec is updated. In short, USM provides a different mix of features and control that we believe matches the needs of implementations and applications better than SVM:

• USM provides explicit control over host allocations with wide visibility, devices allocations with best performance, and shared allocations that can migrate. SVM doesn't provide nearly as much control (basically just the clSVMAlloc flags), and any control is implicit. In particular, SVM has no ability to associate an allocation with a specific device, only to associate an allocation with a context.

• USM never requires an application to map and unmap an allocation. Coarse grain SVM (what most implementations support) still requires mapping and unmapping.

• An application may indicate that a kernel may access USM allocations indirectly, without passing a set of all indirectly accessed USM allocations to the kernel. The similar SVM capability requires system SVM (CL_KERNEL_EXEC_INFO_SVM_FINE_GRAIN_SYSTEM). This is a big usability and driver overhead performance benefit for kernels that access large numbers of USM or SVM allocations.

• The matrix of USM capabilities is far more expressive than the relatively small set of SVM capabilities.

• USM adds the clGetMemAllocInfo query function, and the clEnqueueMemAdvise function to provide memory advice for an allocation. To be fair, it would be straightforward to add these for SVM, but they're currently missing.

Do note though that USM and SVM can coexist and implementations and applications can support both. I've also been able to demonstrate limited support for USM on top of SVM using the Intercept Layer for OpenCL Applications - I still need to clean it up a bit, but I could put it in a branch if there is interest.

Thanks!

[bader]

@airlied, did #1315 address your concern?

[airlied]

Sorry was off for a few days, but yes this addresses what I wanted to see. Thanks.