1. 20 10月, 2021 1 次提交
  2. 06 8月, 2021 1 次提交
  3. 23 7月, 2021 2 次提交
  4. 19 6月, 2021 1 次提交
  5. 16 6月, 2021 1 次提交
    • F
      drm/amdkfd: Disable SVM per GPU, not per process · 5a75ea56
      Felix Kuehling 提交于
      When some GPUs don't support SVM, don't disabe it for the entire process.
      That would be inconsistent with the information the process got from the
      topology, which indicates SVM support per GPU.
      
      Instead disable SVM support only for the unsupported GPUs. This is done
      by checking any per-device attributes against the bitmap of supported
      GPUs. Also use the supported GPU bitmap to initialize access bitmaps for
      new SVM address ranges.
      
      Don't handle recoverable page faults from unsupported GPUs. (I don't
      think there will be unsupported GPUs that can generate recoverable page
      faults. But better safe than sorry.)
      Signed-off-by: NFelix Kuehling <Felix.Kuehling@amd.com>
      Reviewed-by: NPhilip Yang <philip.yang@amd.com>
      Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>
      5a75ea56
  6. 05 6月, 2021 1 次提交
  7. 20 5月, 2021 1 次提交
  8. 11 5月, 2021 3 次提交
  9. 21 4月, 2021 1 次提交
  10. 10 3月, 2021 1 次提交
  11. 10 2月, 2021 1 次提交
    • K
      drm/amdkfd: Get unique_id dynamically v2 · 11964258
      Kent Russell 提交于
      Instead of caching the value during amdgpu_device_init, just call the
      function directly. This avoids issues where the unique_id hasn't been
      saved by the time that KFD's topology snapshot is done (e.g. Arcturus).
      
      KFD's topology information from the amdgpu_device was initially cached
      at KFD initialization due to amdkfd and amdgpu being separate modules.
      Now that they are combined together, we can directly call the functions
      that we need and avoid this unnecessary duplication and complexity.
      
      As a side-effect of this change, we also remove unique_id=0 for CPUs,
      which is obviously not unique.
      
      v2: Drop previous patch printing unique_id in hex
      Signed-off-by: NKent Russell <kent.russell@amd.com>
      Reviewed-by: NFelix Kuehling <Felix.Kuehling@amd.com>
      Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>
      11964258
  12. 30 10月, 2020 1 次提交
  13. 13 10月, 2020 1 次提交
  14. 06 10月, 2020 1 次提交
  15. 27 8月, 2020 2 次提交
  16. 16 7月, 2020 1 次提交
  17. 01 7月, 2020 2 次提交
  18. 29 5月, 2020 1 次提交
  19. 01 5月, 2020 1 次提交
  20. 29 4月, 2020 1 次提交
  21. 28 4月, 2020 1 次提交
  22. 23 4月, 2020 1 次提交
  23. 05 3月, 2020 1 次提交
  24. 27 2月, 2020 2 次提交
  25. 19 12月, 2019 2 次提交
  26. 08 10月, 2019 1 次提交
    • H
      drm/amdkfd: Check against device cgroup · 6b855f7b
      Harish Kasiviswanathan 提交于
      Participate in device cgroup. All kfd devices are exposed via /dev/kfd.
      So use /dev/dri/renderN node.
      
      Before exposing the device to a task check if it has permission to
      access it. If the task (based on its cgroup) can access /dev/dri/renderN
      then expose the device via kfd node.
      
      If the task cannot access /dev/dri/renderN then process device data
      (pdd) is not created. This will ensure that task cannot use the device.
      
      In sysfs topology, all device nodes are visible irrespective of the task
      cgroup. The sysfs node directories are created at driver load time and
      cannot be changed dynamically. However, access to information inside
      nodes is controlled based on the task's cgroup permissions.
      Signed-off-by: NHarish Kasiviswanathan <Harish.Kasiviswanathan@amd.com>
      Reviewed-by: NFelix Kuehling <Felix.Kuehling@amd.com>
      Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>
      6b855f7b
  27. 03 10月, 2019 2 次提交
  28. 16 9月, 2019 2 次提交
  29. 22 8月, 2019 1 次提交
  30. 19 7月, 2019 1 次提交
  31. 22 6月, 2019 1 次提交