clover: implement CL_DEVICE_SVM_CAPABILITIES
authorKarol Herbst <kherbst@redhat.com>
Mon, 21 May 2018 10:19:42 +0000 (12:19 +0200)
committerMarge Bot <eric+marge@anholt.net>
Wed, 15 Apr 2020 11:08:13 +0000 (11:08 +0000)
v2: without supporting userptrs SVM can't be implemented as it's impossible
    to ensure memory consistency with HOST_PTR buffers
v3: fix comment style
v4: fixes typo in comment

Signed-off-by: Karol Herbst <kherbst@redhat.com>
Reviewed-by: Pierre Moreau <dev@pmoreau.org>
Reviewed-by: Francisco Jerez <currojerez@riseup.net>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/2076>

src/gallium/state_trackers/clover/api/device.cpp
src/gallium/state_trackers/clover/core/device.cpp
src/gallium/state_trackers/clover/core/device.hpp

index ca6b90ba271c07047672d778780ba29e71745539..d1c37b96aebdfe769770e3d825fa8edfbdae797e 100644 (file)
@@ -405,6 +405,10 @@ clGetDeviceInfo(cl_device_id d_dev, cl_device_info param,
       buf.as_scalar<cl_uint>() = 1;
       break;
 
+   case CL_DEVICE_SVM_CAPABILITIES:
+      buf.as_scalar<cl_device_svm_capabilities>() = dev.svm_support();
+      break;
+
    default:
       throw error(CL_INVALID_VALUE);
    }
index 298cde278b4717f1c850dcdfe383540f658de6b0..e05dc5621899eb95f52bc850e5d3c510aa511548 100644 (file)
@@ -220,6 +220,29 @@ device::mem_base_addr_align() const {
    return sysconf(_SC_PAGESIZE);
 }
 
+cl_device_svm_capabilities
+device::svm_support() const {
+   // Without CAP_RESOURCE_FROM_USER_MEMORY SVM and CL_MEM_USE_HOST_PTR
+   // interactions won't work according to spec as clover manages a GPU side
+   // copy of the host data.
+   //
+   // The biggest problem are memory buffers created with CL_MEM_USE_HOST_PTR,
+   // but the application and/or the kernel updates the memory via SVM and not
+   // the cl_mem buffer.
+   // We can't even do proper tracking on what memory might have been accessed
+   // as the host ptr to the buffer could be within a SVM region, where through
+   // the CL API there is no reliable way of knowing if a certain cl_mem buffer
+   // was accessed by a kernel or not and the runtime can't reliably know from
+   // which side the GPU buffer content needs to be updated.
+   //
+   // Another unsolvable scenario is a cl_mem object passed by cl_mem reference
+   // and SVM pointer into the same kernel at the same time.
+   if (pipe->get_param(pipe, PIPE_CAP_RESOURCE_FROM_USER_MEMORY) &&
+       pipe->get_param(pipe, PIPE_CAP_SYSTEM_SVM))
+      return CL_DEVICE_SVM_FINE_GRAIN_SYSTEM;
+   return 0;
+}
+
 std::vector<size_t>
 device::max_block_size() const {
    auto v = get_compute_param<uint64_t>(pipe, ir_format(),
index 828dfaa65e6f89584541b0698ac548fbdd135ca3..dc9064bb6384072e25f949360b4afd293497f7f5 100644 (file)
@@ -71,6 +71,7 @@ namespace clover {
       bool has_int64_atomics() const;
       bool has_unified_memory() const;
       cl_uint mem_base_addr_align() const;
+      cl_device_svm_capabilities svm_support() const;
 
       std::vector<size_t> max_block_size() const;
       cl_uint subgroup_size() const;