Package: veda
VEDA (VE Driver API) and VERA (VE Runtime API)VEDA and VERA are a CUDA Driver and Runtime API-like APIs for programming the
NEC SX-Aurora. It is based onAVEO. Most of
the functionality is identical to theCUDA Driver
APIandCUDA Runtime
API.Sitemap:Release NotesDifferences between VEDA and CUDA Driver APIDifferences between VERA and CUDA Runtime APIVEDA/VERA Unique FeaturesDelayed Memory AllocationOMP Threads vs Streams (experimental)Advanced VEDA C++ PtrVEDA-NEC MPI integrationNUMA SupportVEDA-smiProfiling APIC++ API(Experimental!)Error HandlingFetching a Device handleLoading ModulesMemory Buffer ObjectsFetching FunctionsLimitations/Known ProblemsHow to buildHow to useVEDA Hybrid OffloadingVE Native applicationsVE Native InjectionRelease NotesVersionCommentv2.0.2Fixed detection of i64 cblas library.v2.0.2Fixed CMake to correct find 64Bit BLAS librariesv2.0.1Bugfixes.Merged changes of VEOS VEDA.Extended Profiler API.v2.0.0Breaking C-ABI changesAdded Experimental C++ APIAdded VEDA profiling APIv1.4.0Overhauled HMEM APISwitched to new AVEO async mallocFixed bug in CMake setting correct C++ standard flagsv1.3.5Bugfix forvedaArgsSet(...)to again acceptVEDAptrv1.3.4Fixed RPM and LOCAL dist types.Automatically downloading Illyrian and Tungl in VEOS and LOCAL builds.Fixed DType issues with in cppvedaLaunchKernel(...)v1.3.3Removed pollutingVEDA_ERROR_UNKNOWN_CONTEXTlog message.Fixed possible memleak when VPTR is already allocated.Fixed possible memleak when usingvedaMemAllocOverrideOnce.Synchronizing TUNGL timer with VH.v1.3.2AddedvedaMemAllocOverrideOnceto preventvedaMemAllocto allocate new memory and instead return the override value once. This is not meant to be used except when you want to circumvent unncessary memory allocations in opaque data structures that you don't have access to.Fixed RPATH for veda-smi in Python releasesv1.3.1Added compile guard to preventvedaArgsSet<bool>becauseboolis defined as 1B on VH and 4B on VE.Merged changes fromVEOS 2.11.1 release.Compatibility Bugfix forveda/omp.hNCC ≥ v3.4v1.3.0changed definition ofVEDAdeviceptrto prevent segfaults when passing them tostd::ostreamadded__global__for device codeimprovedveda_device_omp.himplementationsrenamedFIND_PACKAGE(VE ...)toFIND_PACKAGE(VEDA ...)added checks forREQUIREDand min versions toFIND_PACKAGE(VEDA ...)renamedVEDA_INCLUDEStoVEDA_INCLUDE_DIRSto comply with CMake standardmovedCMakeLists.txtinto project rootVEDA_CXX will now obeyCMAKE_CXX_STANDARDwhenCMAKE_CXX_STANDARD_REQUIREDis set.added device-side support forTunglv1.2.0replacedbool checkResultwithint64_t* resultinvedaLaunchKernelExto receive return value of kerneladded C++ version ofvedaLaunchKernelExaddedvedaLaunchHostFuncExthat can return the return value of the functionv1.1.2changed behavior ofVE_NODE_NUMBERto be only used when_VENODELISTANDVEDA_VISIBLE_DEVICESare not set.v1.1.1Added support for AVEO's_VENODELISTenv to ensure correct behavior in cluster environments.Changed behavior ofVEDA_VISIBLE_DEVICESin case of NUMA nodes. It now accepts the direct hardware id in the format of[AVEO_ID].[NUMA_ID]v1.1.0addedvedaMemSwapfunction to swap the underlying memory buffer between twoVEDAdeviceptr.v1.0.0First stable release.Improved memset performance, especially for D8 and D16 (up to 150x faster now!).AddedvedaMemsetD128andvedaMemsetD2D128API.AddedASL_FFTW_LIBRARIESto ASL CMake.Added device codevedaMemset. Enabled to usevedaMemsetD*in device code.Added C++ wrapper to allow directly signed integer and floating point values forvedaMemsetD*functions.v0.10.6Maintenance release that fixes SegFaults when context has been destroyed before freeing memory.vedaMemFreeignores calls if the context for the particular pointer has already been freed. BugFix forVEDA_CONTEXT_MODE_SCALARifVE_OMP_NUM_THREADSis not set.v0.10.5addedveda_omp_simd_reduce. MemTrace only get printed when env varVEDA_MEM_TRACE=1is set. VEDA no longer overrides VEORUN_BIN if already been set by user. Added LICENSE to installation target.v0.10.4Fixed Identification of VE model.v0.10.3Filtering negative values fromVEDA_VISIBLE_DEVICES.v0.10.2Correct veda-smi RPATH to work without setting LD_LIBRARY_PATH.v0.10.1Addedaveorun-ftrace. Can be activated usingVEDA_FTRACE=1env var. Renamed RPM packages to only include major version in package name, i.e.veda-0.10.v0.10.0Renamed and improvedVEDAmpiptrtoVEDAptr. RemovedVEDAdeviceptr->Xfunctions, as they are now part ofVEDAptr. Addedveda-smiexecutable.v0.10.0rc5Added boundary checks for Memcopy and MemSet. AddedvedaArgsSetHMEM. Addedveda_device_omp.hparallelization primitives for C++. Added experimentalVEDAmpiptrfor easier usage with VE-MPI. Added/corrected some of the sensor readings, i.e. LLC Cache, Total Device Memory, ...v0.10.0rc4Increased VEDA offset limit to 128GB. AddedVEDAdeviceptr->Xfunctions in C++. RenamedvedaArgsSetPtrtovedaArgsSetVPtr. AddedvedaArgsSetPtrto automatically translateVEDAdeviceptrtovoid*. Fixed VEDA_VISIBLE_DEVICES to obey NUMA mode.v0.10.0rc3Added AVEO symlinks. Fixed wrong include.v0.10.0rc2Fixed problem in veda_types.h when compiling with C. Linking against shared AVEO instead of static.v0.10.0rc1Fixed 0°C core temperatures. Added NUMA support. Each NUMA node becomes a separate VEDAdevice. AddedvedaDeviceDistance(float**, VEDAdevice, VEDAdevice)to determine the relationship between two VEDAdevices (0.0 == same device, 0.5 == same physical device but different NUMA node, 1.0 == different physical device). AddedvedaMemGetHMEMPointer(void**, VEDAdeviceptr)to translate VEDA pointer to HMEM pointer.v0.9.5.2Bugfixesv0.9.5.1Bugfixesv0.9.5Bugfixesv0.9.4Bugfixesv0.9.3Bugfixesv0.9.2Added FindMPI. Set all CMake vars as advanced.v0.9.1Added FindBLAS, FindLAPACK, FindASL and FindNCL to CMake.v0.9Enhanced VEDA CMake Scripts, to also support native NCC compilation.v0.8.1updated AVEO. Using VE_NODE_NUMBER as fallback if VEDA_VISIBLE_DEVICES is not set.v0.8Implemented multi-stream support (experimental). Automatic setting of required env vars.v0.7.1Bugfix releasev0.7initial VERA releasev0.6initial VEDA releaseDifferences between VEDA and CUDA Driver API:[VEDA] Additionally tovedaInit(0)in the beginning,vedaExit()needs to be called at the end of the application, to ensure that no dead device processes stay alive.All function calls start with: [VEDA]veda*instead ofcu*and [VERA]vera*instead ofcuda*Objects start with [VEDA]VEDA*instead ofCU*andvera*instead ofcuda*VEDA supports asynchronous malloc and free:
VEDA supports asynchronousvedaMemAllocAsyncandvedaMemFreeAsync. They can be used like the synchronous calls, but don't need to synchronize the execution between device and host.vedaDeviceGetPower(float* power, VEDAdevice dev)andvedaDeviceGetTemp(float* tempC, const int coreIdx, VEDAdevice dev)allow to fetch the power consumption (in W) and temperature (in C).As the programming model of the SX-Aurora differs from NVIDIA GPUs, launching kernels looks different:// Device Code -------------------------------------------------------------extern"C"voidmy_function(floatmyFloat,uint8_tmyUnsignedChar,float*array){...}// C -----------------------------------------------------------------------floatmyFloat;uint8_tmyUnsignedChar;VEDAargsargs;vedaArgsCreate(&args);// Scheme: vedaArgsSet[TYPE](&args, [PARAM_INDEX], [VARIABLE]);vedaArgsSetF32(args,0,myFloat);vedaArgsSetU8(args,1,myUnsignedChar);// Copy entire arrays as function parameterfloatarray[32];vedaArgsSetStack(args,2,array,VEDA_ARGS_INTENT_INOUT,sizeof(array));VEDAmodulemod;VEDAfunctionfunc;vedaModuleLoad(&mod,"mylib.vso");vedaModuleGetFunction(&func,mod,"my_function");// Kernel Call Version 1: allows to reuse VEDAargs objectVEDAstreamstream=0;vedaLaunchKernel(func,stream,args);// args are not allowed to be destroyed before synchronizing!vedaStreamSynchronize(stream);vedaArgsDestroy(&args);// Kernel Call Version 2: automatically destroys VEDAargs object after execution (can't be reused for other calls!)vedaLaunchKernelEx(func,stream,args,1,0);// CPP ---------------------------------------------------------------------vedaLaunchKernel(func,stream,myFloat,myUnsignedChar,VEDAstack(array,VEDA_ARGS_INTENT_INOUT,sizeof(array)));VEDAdeviceptr need to be dereferenced first on device side:// Host Code ---------------------------------------------------------------VEDAdeviceptrptr;vedaMemAllocAsync(&ptr,sizeof(float)*cnt);vedaLaunchKernel(func,0,ptr,cnt);vedaMemFreeAsync(ptr);// Device Code -------------------------------------------------------------voidmykernel(VEDAdeviceptrvptr,size_tcnt){float*ptr;vedaMemPtr(&ptr,vptr);for(size_ti=0;i<cnt;i++)ptr[cnt]=...;}VEDA streams differ from CUDA streams. See chapter "OMP Threads vs Streams" for more details.VEDA uses the env varVEDA_VISIBLE_DEVICESin contrast toCUDA_VISIBLE_DEVICES. The behavior ofVEDA_VISIBLE_DEVICESis slightly different:VEDA_VISIBLE_DEVICES=enables all devices,CUDA_VISIBLE_DEVICES=disables all devices.For enabling VE's in NUMA mode, use{ID}.0and{ID}.1.VEDA_VISIBLE_DEVICESids correspond to VE hardware ids,CUDA_VISIBLE_DEVICEScorresponds to the CUDA specific ids.Differences between VERA and CUDA Runtime API:All function calls start withvera*instead ofcuda*Objects start withvera*instead ofcuda*VERA supports asynchronous malloc and free, see VEDA.
VEDA supports asynchronousvedaMemAllocAsyncandvedaMemFreeAsync. They can be used like the synchronous calls, but don't need to synchronize the execution between device and host.vedaDeviceGetPower(float* power, VEDAdevice dev)andvedaDeviceGetTemp(float* tempC, const int coreIdx, VEDAdevice dev)allow to fetch the power consumption (in W) and temperature (in C).As the programming model of the SX-Aurora differs from NVIDIA GPUs, launching kernels looks different.Similar to CUDA Runtime API, calls from VEDA and VERA can be mixed!VEDA/VERA Unique Features:Delayed Memory AllocationVEDA does not need to allocate memory from the host, but can do that directly from the device. For this, the host only needs to create an empty VEDAdeviceptr.// Host Code ---------------------------------------------------------------VEDAdeviceptrvptr;vedaMemAllocAsync(&vptr,0,0);vedaLaunchKernel(func,0,vptr,cnt);vedaMemcpyDtoHAsync(host,vptr,sizeof(float)*cnt,0);vedaMemFreeAsync(vptr,0);// Device Code -------------------------------------------------------------voidmykernel(VEDAdeviceptrvptr,size_tcnt){float*ptr;vedaMemAllocPtr((void**)&ptr,vptr,cnt*sizeof(float));for(size_ti=0;i<cnt;i++)ptr[cnt]=...;}OMP Threads vs Streams (experimental):In CUDA streams can be used to create different execution queues, to overlap
compute with memcopy. VEDA supports two stream modes which differ from the CUDA
behavior. These can be defined byvedaCtxCreate(&ctx, MODE, device).VEDA_CONTEXT_MODE_OMP(default): All cores will be assigned to the default stream (=0). This mode only supports a single stream.VEDA_CONTEXT_MODE_SCALAR: Every core gets assigned to a different
stream. This mode allows to use each core independently with different
streams. Use the functionvedaCtxStreamCnt(&streamCnt)to determine how
many streams are available.Both methods use the env varVE_OMP_NUM_THREADSto determine the maximal
number of cores that get use for either mode. If the env var is not set, VEDA
uses all available cores of the hardware.Advanced VEDA C++ PtrWhen you use C++, you can use theVEDAptr<typename>that gives you more
directly control over theVEDAdeviceptr, i.e. you can usevptr.size(),vptr.device(), ... . Thetypenameis used to
automatically determine the correct offsets when executingvptr += offset;.VEDA-NEC MPI integrationThe VEO-aware NEC MPI (https://www.hpc.nec/forums/topic?id=pgmcA8) enables to
much easier implement hybrid VE applications. For this, so called HMEM pointers
have been introduced in VEO. Starting with v1.4.0 VEDA introduced a new HMEM
API:vedaHMEM*. See following example:VEDAhmemptrhmem;vedaHMemAlloc(&hmem,size);vedaHMemcpy(hmem,host_ptr,size);mpi_send(hmem,...);NUMA SupportVEDA supports VE NUMA nodes since v0.10. To enable NUMA on your system you need
to execute (set-N ?to specific device index):VCMD="sudo /opt/nec/ve/bin/vecmd -N ?"$VCMDvconfigsetpartitioning_modeon$VCMDstatesetoff$VCMDstatesetmnt$VCMDresetcardVEDA then recognizes each NUMA node as a separate device, i.e. with 2 physical
devices in NUMA mode, VEDA would show 4 devices. You can useVEDAresult vedaDeviceDistance(float* distance, VEDAdevice devA, VEDAdevice devB)to
determine the relationship of two VEDAdevices.distance == 0.0; // same device
distance == 0.5; // same physical device, different NUMA node
distance == 1.0; // differeny physical deviceVEDA-smiThe executableveda-smidisplays available VEDA devices in your system. It
uses theVEDA_VISIBLE_DEVICESenv var and therefore only shows the devices
that your VEDA application would be able to use. UseVEDA_VISIBLE_DEVICES= veda-smito ensure that you see all installed devices.╔ veda-smi ═════════════════════════════════════════════════════════════════════╗
║ VEDA Version: 0.10.0     AVEO Version: 0.9.15                                 ║
╚═══════════════════════════════════════════════════════════════════════════════╝

┌── #0  NEC SX-Aurora Tsubasa VE10B ────────────────────────────────────────────┐
  ┌ Physical: 1.0
  ├ AVEO:     0.0
  ├ Clock:    current: 1400 MHz, base: 800 MHz, memory: 1600 MHz
  ├ Firmware: 5399
  ├ Memory:   49152 MiB
  ├ Cache:    LLC: 8192kB, L2: 256kB, L1d: 32kB, L1i: 32kB
  ├ Temp:     56.4°C 56.4°C 57.0°C 56.1°C
  └ Power:    18.0W (11.9V, 1.5A)
└───────────────────────────────────────────────────────────────────────────────┘

┌── #1  NEC SX-Aurora Tsubasa VE10B ────────────────────────────────────────────┐
  ┌ Physical: 1.1
  ├ AVEO:     0.1
  ├ Clock:    current: 1400 MHz, base: 800 MHz, memory: 1600 MHz
  ├ Firmware: 5399
  ├ Memory:   49152 MiB
  ├ Cache:    LLC: 8192kB, L2: 256kB, L1d: 32kB, L1i: 32kB
  ├ Temp:     56.1°C 56.4°C 55.9°C 56.0°C
  └ Power:    18.0W (11.9V, 1.5A)
└───────────────────────────────────────────────────────────────────────────────┘

┌── #2  NEC SX-Aurora Tsubasa VE10B ────────────────────────────────────────────┐
  ┌ Physical: 0.0
  ├ AVEO:     1.0
  ├ Clock:    current: 1400 MHz, base: 800 MHz, memory: 1600 MHz
  ├ Firmware: 5399
  ├ Memory:   49152 MiB
  ├ Cache:    LLC: 16384kB, L2: 256kB, L1d: 32kB, L1i: 32kB
  ├ Temp:     53.8°C 53.5°C 54.1°C 53.8°C 53.8°C 54.1°C 53.2°C 53.5°C
  └ Power:    36.3W (11.9V, 3.1A)
└───────────────────────────────────────────────────────────────────────────────┘Profiling APISince v1.5.0 VEDA supports to add a profiling callback usingvedaProfilerSetCallback(...). The callback needs to have the signaturevoid (*)(VEDAprofiler_data* data, int enter). Ifenteris non-zero, the callback
got called right before issuing the command. If it's zero, it just ended.The data provides the following fields:type: An enum that identifies which kind function got called (kernel, memcpy, ...)device_id: VEDA device idstream_id: VEDA stream idreq_id: ID of the requestuser_data:void*that allows to store data betweenenterandexitof
the event. This should be deleted by the user whenenter==0to prevent
memleaks.Depending on thetype, you can cast thedatato one of the following data
types to get access to further information.type in [VEDA_PROFILER_MEM_ALLOC, VEDA_PROFILER_HMEM_ALLOC]:VEDAprofiler_vedaMemAllocbytes: number of bytes to be allocatedtype in [VEDA_PROFILER_MEM_FREE, VEDA_PROFILER_HMEM_FREE]:VEDAprofiler_vedaMemFreeptr: pointer to be freedtype in [VEDA_PROFILER_MEM_CPY_HTOD, VEDA_PROFILER_MEM_CPY_DTOH, VEDA_PROFILER_HMEM_CPY]:VEDAprofiler_vedaMemcpydst: destination pointersrc: source pointerbytes: number of bytes transferedtype == VEDA_PROFILER_LAUNCH_KERNEL:VEDAprofiler_vedaLaunchKernelfunc: function pointer that gets calledkernel: name of the kernel that gets calledtype == VEDA_PROFILER_LAUNCH_HOST:VEDAprofiler_vedaLaunchHostFuncfunc: function pointer that gets calledtype == VEDA_PROFILER_SYNC:VEDAprofiler_dataC++ API(Experimental!)Starting with v1.5.0 we introduce a new experimental and lightweight C++ API.
This API aims for easier usage of VEDA, with much more comfort in C++
applications.To include the new API just use#include <veda/cpp/api.h>.Error HandlingInstead of the C-API, the C++ API uses exceptions, which can be used like this:try{...}catch(constveda::Exception&e){std::cerr<<e.what()<<" @ "<<e.file()<<" ("<<e.line()<<")";}Fetching a Device handleTo get a handle to a device, just create an instance using:veda::Devicedevice(0);In contrast to the C-API, theveda::Deviceincorporates theVEDAdeviceandVEDAcontextinto a single object. We use a lazy scheme, which will not boot up
the device context until you allocate memory, load a model, or similar.The device provides the following attributes and metrics:isActive, current, currentEdge, distance, power, temp, voltage, voltageEdge, abi, aveoId, cacheL1d, cacheL1i, cacheL2, cacheLLC, clockBase, clockMemory, clockRate, cores, firmware, model, numaId, physicalId, singleToDoublePerfRatio, streamCnt, vedaId, totalMem, usedMem.If your application requires to do the CUDA-style programming, where you bind
the device to a specific thread, you can usedevice.pushCurrent(),device.setCurrent()andauto device = Device::getCurrent()orauto device = Device::popCurrent().To synchronize the execution usedevice.sync()ordevice.sync(stream).Loading ModulesJust do:automod=dev.load("libmymodule.vso");Memory Buffer ObjectsThe new C++ API uses buffer objects instead of raw pointers. These can be
allocated usingdev.alloc<float>(cnt), which will allocatesizeof(T) * cntbytes of memory.If you want to use a different stream, just usedev.alloc<float>(cnt, stream).To allocate HMEM memory, usedev.alloc<float, veda::HMEM>(size).To copy data between different Buffers, or the host and the VE, just use:autoVE=dev.alloc<float>(cnt);autoVH=malloc(sizeof(float)*cnt);VE.to(VH);// copies all items from VE to VHVE.to(VH,1);// copies the first item from VE to VHVE[4].to(VH+4,1);// copies the 5th item from VE to VHVE.from(VH);// copies all items from VH to VEautoV2=dev.alloc<float>(cnt);V2.to(VE);// copies all items from V2 to VEVE.from(V2);// copies all items from V2 to VETo memset data use:VE.memset(3.1415);// set all itemsVE[5].memset(3.1415);// set all items starting the 6thVE[5].memset(3.1415,1);// set only the 6th itemTo cast a buffer object to another type:autoFloat=dev.alloc<float>(cnt);autoInt32=Float.cast<int32_t>();// Float.cnt() == Int32.cnt()autoInt16=Float.cast<int16_t>();// Float.cnt() == Int16.cnt()*2All buffer objects use shared pointer semantics. When all objects using the same
source pointer are destroyed, it will be automatically freed.To pass on pointers between methods just pass on the buffer object:veda::Ptr<VEDA,float>func(...){...autoptr=dev.alloc<float>(cnt);...returnptr;}Fetching FunctionsFor fetching functions we provide three helper functions.C-style orextern "C"functions:// VEextern"C"intname(int,float,VEDAdeviceptr);// VHusingnamespaceveda;autofunc=CFunction::Return<int>(mod,"name");autoresult=func(0,3.14f,ptr);printf("%i\n",int(result));TheCFunction::Return<int>returns you an executable object to an
C-function on the VE. Whenever you callfunc(...)it issues a kernel
call. By default we use the stream #0, but you can usefunc[stream](...)to define the stream yourself.resultis a future object. When you callresult.wait()or fetch the
result using(TYPE)resultorresult.get(), it will synchronize the
execution and provide the return value.The::Return<...>can be omitted when no return value is expected.C++-style functions:// VEintname(int,float,VEDAdeviceptr);// VHusingnamespaceveda;autofunc=Function::Return<int>::Args<int,float,VEDAdeviceptr>(mod,"name");autoresult=func(0,3.14f,ptr);printf("%i\n",int(result));For C++-style functions useFunctioninstead ofCFunction. In this
case you also need to provide the types of all arguments usingArgs<...>.Again::Return<...>can be omitted when no return value is expected.Also struct types can be used as arguments:// VE + VHnamespacewhatever{template<typenameT>structcomplex{Tx,y;};}// VEvoidname(VEDAdeviceptr,whatever::complex<float>);// VHautofunc=Function::Args<VEDAdeviceptr,whatever::complex<float>>(mod,"name");whatever::complex<float>x={3.0f,4.0f};func(ptr,x);Template functions:// VEtemplate<typenameT,typenameD>Tname(T,float,D);templateintname<int,VEDAdeviceptr>(int,float,VEDAdeviceptr);// VHusingnamespaceveda;autofunc=Template<int,VEDAdeviceptr>::Return<_0>::Args<_0,float,_1>(mod,"name");Last, we also support to fetch templated functions. Here it is
important, that in the VE code, the template gets explicitly
instantiated using thetemplate ... name<...>(...);syntax. Otherwise
the compiler will not generate this specific templated function.On the VH, we first define the template parameters usingTemplate<...>. Next, as before the return type. If it is::Return<void>, it can be omitted. And last the arguments, similar as
before for theFunction.In the code above you seeveda::_0andveda::_1. These correspond to
the template parameters,_0is the 0th,_1the 1st, and so on. It is
necessary to use these template placeholders withinReturn<...>andArgs<...>at the same locations as within the C++ code.If your template uses literals, such as:template<inti,typenameT>Tname(Ta){returna+i;}templatefloatname<0>(float);templatefloatname<5>(float);templateintname<5>(int);You can to use the following code on VH:autoname_f0=Template<Literal<0>,float>::Return<_1>::Args<_1>(...);autoname_f5=Template<Literal<5>,float>::Return<_1>::Args<_1>(...);autoname_i0=Template<Literal<5>,int>::Return<_1>::Args<_1>(...);It's important that the data type you pass toLiteral<...>matches the
data type you use in yourtemplate<...>. I.e., if you usetemplate<char...>, then you need to useLiteral('x')orLiteral(char(15)).Only integer-like types (char, short, ...) can be used as template
literals.For all function fetching methods it's important, that function arguments match
exactly the ones you use in your VE C++ code. Otherwise fetching the function
will fail at runtime!Limitations/Known Problems:VEDA only supports oneVEDAcontextper device.No unified memory space (yet).VEDA by default uses the current workdirectory for loading modules. This
behavior can be changed by using the env varVE_LD_LIBRARY_PATH.Due to compiler incompatibilities it can be necessary to adjust the CMake
variable${AVEO_NFORT}to another compiler.The C++ API can only return fundamental (void, int, short, ...) values.The C++ API cannot compile...::Args<void>. Use...:::Args<>instead.How to build:gitclonehttps://github.com/SX-Aurora/veda/
mkdirveda/buildcdveda/build# Build Option 1: Local installation (default: /usr/local/ve (use -DCMAKE_INSTALL_PREFIX=... for other path))cmake3-DVEDA_DIST_TYPE=LOCAL..
cmake3--build.--targetinstall# Build Option 2: VEOS installationcmake3-DVEDA_DIST_TYPE=VEOS..
cmake3--build.--targetinstall# Build Option 3: Python packagepip3installillyriantungl
illyriancmake3-DVEDA_DIST_TYPE=PYTHON..
cmake3--build.--targetdistHow to use:VEDA has an own CMake find script. This supports 3 modes. The script uses the compilers installed in/opt/nec/ve/bin. You can modify theCMAKE_[LANG]_COMPILERflags to change that behavior. See the Hello World examples in theExamples Folder1. VEDA Hybrid Offloading:This mode is necessary for VEDA offloading applications. It enables to compile host and device code within the same CMake project. For this it is necessary to use different file extensions for the VE code. All*.vcfiles get compiled using NCC,*.vcppusing NC++ and*.vfwith NFORT.SET(CMAKE_MODULE_PATH/usr/local/ve/veda/cmake/opt/nec/ve/share/veda/cmake)FIND_PACKAGE(VEDA)ENABLE_LANGUAGE(VEDA_CVEDA_CXX)INCLUDE_DIRECTORIES(${VEDA_INCLUDE_DIRS})ADD_EXECUTABLE(myAppmycode.vcmycode.vcpp)TARGET_LINK_LIBRARIES(myApp${VEDA_LIBRARY})2. VE Native applications:This mode enables to compile VE native applications.SET(CMAKE_MODULE_PATH/usr/local/ve/veda/cmake/opt/nec/ve/share/veda/cmake)FIND_PACKAGE(VEDA)ENABLE_LANGUAGE(VEDA_CVEDA_CXX)ADD_EXECUTABLE(myAppmycode.cmycode.cpp)3. VE Native Injection:If you have a CPU application and you don't want to modify the CMake script you can build your project using:cmake -C /usr/local/ve/veda/cmake/InjectVE.cmake /path/to/your/sourceIt will replace the CPUC,CXXandFortrancompilers with NCC.