Есть люди, которые писали на OpenCL 2.0?

cl_context уже привязан к конкретной видеокарте. Если это метаустройство, которое под собой несколько карт держит - оно само разберется что где выделять.

Что-то я не могу понять как там обмен идёт. Для того чтобы забрать данные в память процессора я должен выделять для него выделять clSVMAlloc или malloc?

Что-то я не могу понять как там обмен идёт. Для того чтобы забрать данные в память процессора я должен выделять для него выделять clSVMAlloc или malloc?

Читал главу 3.3.3 Memory Model: Shared Virtual Memory спецификации OpenCL 2.0 (с архиважной табличкой в конце) и главу 6.2 Shared Virtual Memory (SVM) в AMD OpenCL User Guide?

Зависит от устройства. Если нет поддержки Fine-Grained system SVM, т.е. в CL_DEVICE_SVM_CAPABILITIES не стоит бит CL_DEVICE_SVM_FINE_GRAIN_SYSTEM то работать так называемые «системные» указатели от malloc'а не будут. По стандарту в clSetKernelArgSVMPointer() можно передать только

The SVM pointer value specified as the argument value can be the pointer returned by clSVMAlloc or can be a pointer + offset into the SVM region.

Т.е. похоже что системные указатели предполагается что передают через обычный clSetKernelArg - к сожалению, не было устройств с такими возможностями потыкать-проверить.

SVM - это, как следует из названия, общая виртуальная память. Когда на хосте страница виртуальной памяти свопится на диск, а когда нет - решает операционная система. Когда она одна на несколько процессов - решает тоже ОС. Тут принцип тот же - ты выделяешь виртуальную память, а дальше реализация OpenCL 2.0+ разберётся, где эта память будет физически лежать и как её обновлять, дублировать, синхронизировать. Раньше надо было самому туда-сюда буферы гонять или мапить, сейчас может быть у устройств физически общая память - можно устроить им специальную общую виртуальную память с валидными и на хосте, и на устройствах одинаковыми указателями - прогресс. А можно вообще с устройства использовать виртуальные указатели хоста, если устройство так умеет - вообще будущее сегодня. Но так как стандарт один, а устройств много - надо отталкиваться от своей платформы. «Грубые» SVM указатели для всех OpenCL 2.0+ устройств, «точные» указатели SVM aka системные указатели от malloc - для некоторых.

Вкратце ответ на первое сообщение - нельзя.

Зависит от устройства. Если нет поддержки Fine-Grained system SVM, т.е. в CL_DEVICE_SVM_CAPABILITIES не стоит бит CL_DEVICE_SVM_FINE_GRAIN_SYSTEM то работать так называемые «системные» указатели от malloc'а не будут. По стандарту в clSetKernelArgSVMPointer() можно передать только

У меня система полностью соответствует требованиям OpenCL 2.0: IOMMUv2, PCIev3, PCIe Atomics, CRAT table support, ну и дрова конечно.

Надо смотреть clGetDeviceInfo(device, CL_DEVICE_SVM_CAPABILITIES, ...); - установлен ли бит CL_DEVICE_SVM_FINE_GRAIN_SYSTEM. Как говорит документация,

Coarse-grain SVM allocations are required to be supported by all OpenCL 2.0 devices.

А остальное (в том числе системные указатели) - надо сначала проверять.

Совершенно случайно наткнулся на функцию clEnqueSVMMigrateMem, которая как раз даёт контроль над тем, куда деть SVM. На какое-то устройство либо на хост. Так что ответ будет - можно, но только начиная с OpenCL 2.1. Про работающие реализации 2.1 пока что не слышно.

Жду видеокарту пока, amd radeon vega. Натяну ROCm и напишу, что там поддерживается.

Собственно вот часть инфы:

https://github.com/RadeonOpenCompute/ROCm

clEnqueSVMMigrateMem

Странно, гугль вообще о ней ничего не находит.

clEnqueSVMMigrateMem

Странно, гугль вообще о ней ничего не находит.

Потому что, очевидно, она называется clEnqueueSVMMigrateMem

FFFUUUU, Гугль не нашел SVMMigrateMem, да ну этот ИИ нафиг.

У меня такое подозрение, что я хочу решается с помощью HCC. Но блин видюха еще не приехала.

В общем так себе поддержка:

clinfo 
LoadLib(libhsa-amd-aqlprofile64.so.1) failed: libhsa-amd-aqlprofile64.so.1: cannot open shared object file: No such file or directory
Number of platforms:				 1
  Platform Profile:				 FULL_PROFILE
  Platform Version:				 OpenCL 2.0 AMD-APP.internal (2545.0)
  Platform Name:				 AMD Accelerated Parallel Processing
  Platform Vendor:				 Advanced Micro Devices, Inc.
  Platform Extensions:				 cl_khr_icd cl_amd_object_metadata cl_amd_event_callback 


  Platform Name:				 AMD Accelerated Parallel Processing
Number of devices:				 1
  Device Type:					 CL_DEVICE_TYPE_GPU
  Vendor ID:					 1002h
  Board name:					 Vega 10 XT [Radeon RX Vega 64]
  Device Topology:				 PCI[ B#12, D#0, F#0 ]
  Max compute units:				 64
  Max work items dimensions:			 3
    Max work items[0]:				 1024
    Max work items[1]:				 1024
    Max work items[2]:				 1024
  Max work group size:				 256
  Preferred vector width char:			 4
  Preferred vector width short:			 2
  Preferred vector width int:			 1
  Preferred vector width long:			 1
  Preferred vector width float:			 1
  Preferred vector width double:		 1
  Native vector width char:			 4
  Native vector width short:			 2
  Native vector width int:			 1
  Native vector width long:			 1
  Native vector width float:			 1
  Native vector width double:			 1
  Max clock frequency:				 1630Mhz
  Address bits:					 64
  Max memory allocation:			 7287183769
  Image support:				 Yes
  Max number of images read arguments:		 128
  Max number of images write arguments:		 8
  Max image 2D width:				 16384
  Max image 2D height:				 16384
  Max image 3D width:				 2048
  Max image 3D height:				 2048
  Max image 3D depth:				 2048
  Max samplers within kernel:			 26751
  Max size of kernel argument:			 1024
  Alignment (bits) of base address:		 1024
  Minimum alignment (bytes) for any datatype:	 128
  Single precision floating point capability
    Denorms:					 Yes
    Quiet NaNs:					 Yes
    Round to nearest even:			 Yes
    Round to zero:				 Yes
    Round to +ve and infinity:			 Yes
    IEEE754-2008 fused multiply-add:		 Yes
  Cache type:					 Read/Write
  Cache line size:				 64
  Cache size:					 16384
  Global memory size:				 8573157376
  Constant buffer size:				 7287183769
  Max number of constant args:			 8
  Local memory type:				 Scratchpad
  Local memory size:				 65536
  Max pipe arguments:				 16
  Max pipe active reservations:			 16
  Max pipe packet size:				 2992216473
  Max global variable size:			 7287183769
  Max global variable preferred total size:	 8573157376
  Max read/write image args:			 64
  Max on device events:				 0
  Queue on device max size:			 0
  Max on device queues:				 0
  Queue on device preferred size:		 0
  SVM capabilities:				 
    Coarse grain buffer:			 Yes
    Fine grain buffer:				 Yes
    Fine grain system:				 No
    Atomics:					 No
  Preferred platform atomic alignment:		 0
  Preferred global atomic alignment:		 0
  Preferred local atomic alignment:		 0
  Kernel Preferred work group size multiple:	 64
  Error correction support:			 0
  Unified memory for Host and Device:		 0
  Profiling timer resolution:			 1
  Device endianess:				 Little
  Available:					 Yes
  Compiler available:				 Yes
  Execution capabilities:				 
    Execute OpenCL kernels:			 Yes
    Execute native function:			 No
  Queue on Host properties:				 
    Out-of-Order:				 No
    Profiling :					 Yes
  Queue on Device properties:				 
    Out-of-Order:				 No
    Profiling :					 No
  Platform ID:					 0x7f4f5df5c1b0
  Name:						 gfx900
  Vendor:					 Advanced Micro Devices, Inc.
  Device OpenCL C version:			 OpenCL C 2.0 
  Driver version:				 2545.0 (HSA1.1,LC)
  Profile:					 FULL_PROFILE
  Version:					 OpenCL 1.2 
  Extensions:					 cl_khr_fp64 cl_khr_global_int32_base_atomics cl_khr_global_int32_extended_atomics cl_khr_local_int32_base_atomics cl_khr_local_int32_extended_atomics cl_khr_int64_base_atomics cl_khr_int64_extended_atomics cl_khr_3d_image_writes cl_khr_byte_addressable_store cl_khr_fp16 cl_khr_gl_sharing cl_amd_device_attribute_query cl_amd_media_ops cl_amd_media_ops2 cl_khr_subgroups cl_khr_depth_images cl_amd_copy_buffer_p2p 

Бред какой-то, нахрен ему тогда нужен atomic и iommu от материнки?

А еще для хваленой веговской производительности в вычислениях нужен HBCC, а его нет в линуксе. Зато в венде есть HBCC, но opencl 2.0 там для галочки.

xakepp35

I know, what you feel bro... У меня работал OpenCL 2.0 (R9 380) на fglrx блобе, а потом бац - и в amdgpu-pro и меня уже только OpenCL 1.2, а ROCm не поддерживает мою карту потому что, видите ли, там в карточном биосе чего-то не хватает для OpenL 2.0 (Но раньше он же работал! И в оффтопике работает!). По поводу данного случая - то что что работают Coarse+Fine grain buffer - это отлично, можно использовать SVM. Как пишут в АМД-шных доках,

Fine-grained buffer memory has the same virtual address for all devices it is
allocated on. In the AMD implementation, the physical memory is allocated
on the Device-Visible Host Memory.

Системные указатели есть, видимо, только в APU. Может быть Intel уже запилил у себя поддержку - у них OpenCL пилится и развивается семимильными шагами, в отличие от остальных двух вендоров. Так что с SVM для меня сюрпризов не было. А вот что меня поначалу сильно удивило - это CL_DEVICE_VERSION 1.2 при CL_DEVICE_OPENCL_C_VERSION 2.0, это нарушает стандарты как OpenCL 1.2, так и OpenCL 2.0. Но потом я вспомнил, что они упоротые и это, видимо, тот самый

OpenCL 2.0 compatible kernel language support with OpenCL 1.2 compatible runtime

из release notes ROCm 1.7.

В общем хоть какой-то SVM есть - уже можно жить. Но такого что «ух ты, я вчера узнал про какой-то новый API к крутой апаратной фиче а сегодня выяснилось что в OpenCL стэке он уже везде поддержан» с AMD давно не было.

Когда рынку нужны были встраиваемые решения и ноутбуки - AMD вкладывалось в десктопные процессоры. Когда рынку нужна была высокая скорость fp16 для нейросетей AMD вкладывалось в производительную графику для приставок. Когда рынку нужно майнить эфир AMD вкладывается в перенос программ с CUDA на HIP.

Умудрились настолько забить при этом на OpenCL, что рабочую реализацию OpenCL 2.1 первой выкатила Intel.

У меня и с HCC что-то не то, вроде с линковкой всё нормально, а собранная программа выплевывает:

No suitable runtime detected. Fall back to CPU!

	linux-vdso.so.1 (0x00007ffc77fc0000)
	libdl.so.2 => /usr/lib/libdl.so.2 (0x00007f5305cb0000)
	libm.so.6 => /usr/lib/libm.so.6 (0x00007f5305964000)
	libpthread.so.0 => /usr/lib/libpthread.so.0 (0x00007f5305746000)
	libunwind.so.8 => /usr/lib/libunwind.so.8 (0x00007f530552c000)
	libhc_am.so => /opt/rocm/hcc-1.2/bin/../lib/libhc_am.so (0x00007f53052c4000)
	libstdc++.so.6 => /usr/lib/libstdc++.so.6 (0x00007f5304f3d000)
	libgcc_s.so.1 => /usr/lib/libgcc_s.so.1 (0x00007f5304d26000)
	libc.so.6 => /usr/lib/libc.so.6 (0x00007f530496e000)
	/lib64/ld-linux-x86-64.so.2 => /usr/lib64/ld-linux-x86-64.so.2 (0x00007f5305eb4000)
	liblzma.so.5 => /usr/lib/liblzma.so.5 (0x00007f5304748000)
	libhsa-runtime64.so.1 => /opt/rocm/hsa/lib/libhsa-runtime64.so.1 (0x00007f5304416000)
	libhsakmt.so.1 => /opt/rocm/libhsakmt/lib/libhsakmt.so.1 (0x00007f53041f7000)
	libelf.so.1 => /usr/lib/libelf.so.1 (0x00007f5303fdf000)
	librt.so.1 => /usr/lib/librt.so.1 (0x00007f5303dd7000)
	libnuma.so.1 => /usr/lib/libnuma.so.1 (0x00007f5303bcb000)
	libpci.so.3 => /usr/lib/libpci.so.3 (0x00007f53039be000)
	libz.so.1 => /usr/lib/libz.so.1 (0x00007f53037a7000)
	libresolv.so.2 => /usr/lib/libresolv.so.2 (0x00007f5303590000)
	libudev.so.1 => /usr/lib/libudev.so.1 (0x00007f5303372000)

У них раньше в документации было написано:

Verify Installation
To verify that the ROCm stack completed successfully you can execute to HSA vectory_copy sample application:

cd /opt/rocm/hsa/sample
make
./vector_copy

Сейчас такой пример ещё есть? Это, если что, отсюда, версия из истории.

Какой процессор? Возможно, чтобы разобраться, придётся дебажить - или открыть у них на гитхабе issue.

там вся штука в том, что memremap очень сильно наказывает на производительность. поэтому делают один БЛОБ памяти и из него аллокачат

А есть аналог clinfo для hsa?

Так как у меня ROCm даже согласно их документации не должен был завестись, я его предметно не тыкал и не знаю. Судя по их гитхабу - запустить пример с вектором это рекомендуемый и пока единственный способ понять, завелось или нет. Создай им issue - хочу тулзу как clinfo и чтобы было сразу понятно, почему не работает (процессор не тот, GPU не тот, биос не тот?). В крайнем случае тыкнут в готовую тулзу, если она есть.

Но учитывая фантастически низкий процент систем, на которых HSA работает подумай ещё раз, стоит ли с ним связываться =) Для меня фантазии использовать его (через HIP) в продакшене закончились в тот момент, когда выяснилось что поддержки оффтопика вообще нет.