• [开发环境] 【开发环境】【类型】没有免费的CPU、GPU选项
    【功能模块】ModelArts 开发环境 创建Notebook实例时没有免费的CPU、GPU可选。【操作步骤&问题现象】1、没有创建Notebook实例2、但是没有免费的CPU、GPU可选【截图信息】【日志信息】(可选,上传日志内容或者附件)
  • [技术干货] 【转载】大V博文系列之PLDI 2021论文分析(三):DeepCuts-针对GPU的深度学习优化框架
    小伙伴们最近分析PLDI一篇很有意思的论文《DeepCuts: A Deep Learning Optimization Framework for Versatile GPU Workloads》,给大家分享一下。PLDI页面:https://pldi21.sigplan.org/details/pldi-2021-papers/13/DeepCuts-A-Deep-Learning-Optimization-Framework-for-Versatile-GPU-Workloads论文作者:Wookeun Jung, Thanh Tuan Dao, Jaejin Lee论文下载链接:https://dl.acm.org/doi/10.1145/3453483.3454038背景GPU是目前运行深度学习相关应用的标准后端硬件。目前绝大多数深度学习框架都是使用cuDNN原生高性能库对在GPU上进行的计算做加速优化。然而随着深度学习领域的快速发展,基于cuDNN的框架在GPU优化上并不总能给出最优解。论文给出两个原因:多变的workloads。cuDNN对于非卷积类神经网络支持不足且无法完美支持所有batch size的输入数据。cuDNN有限的算子融合能力。其只支持少数几种pattern如多个卷积的融合、卷积与biasAdd和ReLU的后向融合,不足以覆盖越来越多样的DL patterns针对这些限制,一系列深度学习框架(TVM,TensorFlow XLA,TensorRT等)进行了优化并且在部分场景下性能媲美甚至超越cuDNN,但它们仍然无法在各类DL workloads下保持全面稳定的加速效果。其主要原因是获取GPU kernel优化所需信息的难度较大。为提升某个算子在GPU上的运行速度,必须找到使其性能最优的参数组合,包括使用线程块的多少、输入数据的切分大小等。但碍于庞大的搜索空间,想基于所有参数组合去生成代码、评估性能几乎是不可能的。DeepCuts概述因此论文作者提出了DeepCuts,一个专为解决深度学习应用中越来越多样的workloads而设计的深度学习框架。其不同于上述其他框架的两个重要创新点:直接使用GPU硬件参数不实际评估每个参数组合的性能,而是通过估计性能上界去筛除理论计算结果较差的参数组合,缩小范围。对于一个给定的深度学习模型中的计算操作,DeepCuts会搜索产生最优性能GPU kernel的参数组合,并在搜索过程中尝试算子融合,并使用具有后端架构感知的性能估计模型对“definitely-low”的参数组合进行剪枝。基于选中的参数组合,生成数据流图并进一步生成GPU kernel。最后执行这些kernel并为每个算子或融合算子选出使其性能最优的。主要贡献有:DeepCuts在多样的深度学习workload上提供了比cuDNN更具竞争力的性能,且能覆盖小批量推理、大批量推理和训练的场景。作者认为DeepCuts是第一个同时实现高性能和多功能性的框架。DeepCuts提出了一种由性能评估模型驱动的代码生成算法,该算法同时考虑了性能优化中的两个关键因素:算子融合和参数搜索。该算法能在相对较短的时间内搜索到使性能最佳的算子融合方式及实现参数。与cuDNN(封闭代码库)不同,DeepCuts在保证性能的同时,算法更加简单易且不依赖任何人工调优。DeepCuts评估了其在常用DNN模型包括CNN、RNN、Transformer-based MLP的不同batch size下的推理和训练,及常用硬件后端NVIDIA V100和RTX 2080 GPU上的表现。对比CuDNN,其在小批量推理中分别实现了1.70和1.89倍加速,在大批量推理中分别实现了2.06和2.52倍的加速,在训练中分别实现了1.09和1.10的加速。DeepCuts还与TVM、TensorFlow XLA和TensorRT三种现有优化框架进行了比较。其代码生成时间比TVM缩短了13.53×,并且对比三种框架分别实现了1.25、1.48和1.36倍的加速。相关工作DeepCuts将主流框架分为两类,并分析了其优缺点。Hand-tuned kernels relied的TensorFlow XLA和TensorRT只在特定算子和规定pattern下能得到较优性能,ML based的TVM (autoTVM) 和 Tensor Comprehensions代码生成策略灵活但是性能不及手写优化。Table 1对比了DeepCuts与目前较为主流的三大框架并借此表明其在所支持的模型类型、所覆盖的workload类型、涵盖的卷积算法以及性能等多方面的优势。DeepCuts总体结构与PyTorch和TensorFlow相似,其输入为描述计算与数据流的无环图,图中的点(node)表示张量计算操作,边(edge)表示数据流向。输出为一系列GPU kernel代码。四个组成部分:候选者生成器(candidate generator), 性能评估器(performance estimator), 代码生成器(code generator)以及代码选择器(code selector)。首先,候选者生成器将给定workload中的一系列代表张量操作的node拆分为多个非空子集。为每个子集生成单独的GPU kernel(一个子集中的所有单个kernel也会被融合成一个大的kernel)。生成器会生成多种拆分,进行评估并确定性能最优的拆分策略。剩下的三个组成部分,性能评估器(performance estimator), 代码生成器(code generator)以及代码选择器(code selector)所组成的Evaluate(P)过程既是为了完成每种拆分方式中的每个子集的性能评估。对于P中的每个子集S,性能评估器会使用性能评估模型找到性能位于top T%的执行参数组合。对于搜索到的每组参数,代码生成器生成相应GPU kernel代码。代码选择器会执行代码,记录运行时间,选出性能最佳的kernel并更新P的总运行时间。分割算法:基于当前拆分仍有加速潜力的前提下,DeepCuts增量地生成更多拆分,直至没有新的拆分可生成。尽管无法枚举所有可能的候选拆分,DeepCuts的作者认为其拆分算法可以枚举绝大多数对性能有提升的拆分方案。举例来说,对于X, Y, Z三个连续子集,只有当融合其中的两个子集能够获得性能收益时,此算法才会将三者融合成一个。因为当X+Y和Y+Z都会导致性能劣化时,X+Y+Z的融合几乎不会获得性能提升。Table 2列出了DeepCuts所能覆盖处理的节点类型,分为复杂操作(计算密集且耗时的操作如卷积和矩阵乘法)和简单操作(计算复杂度和输入数据大小成正比的操作)。后面会介绍DeepCuts基于不同算子类型给出的融合策略。性能评估模型1、kernel的实现参数Table 3和Table 4列出了DeepCuts的性能评估模型中涉及到的实现参数。Table 3以卷积操作为例,给出了由输入tensor定义的固定参数。Table 4则给出了变量参数,DeepCuts在优化过程中需要找到的能够给出较优性能的参数组合中的参数就是这些变量参数。DeepCuts将生成的代码分为取数据和计算两个阶段。为缩小搜索空间,DeepCuts将这些实现参数限制为:每个线程计算的各维度上数据为2的指数幂,每个线程块处理的则是每个线程处理的对应维度数据的整数倍。2、性能限制因素DeepCuts给出四个主要限制kernel性能且与GPU架构相关的因素,并设计了四个相对应的metric值( , , , )。通过计算这些值的上界,对理论上不可能有较优性能的kernel进行剪枝。相关参数列在Table 5到8中。下面对这四个因素逐个阐述:全局内存带宽global memory bandwidth(涉及变量见Table 6, 8)一个线程块的计算密集程度(the operational intensity of a thread block):并计算出该因素相应的度量值:当前OI和理论峰值的比值,若GMRatio=1,表明全局内存带宽并不是限制性能的瓶颈。共享内存延迟shared memory latency(涉及变量见Table 6, 7)DeepCuts根据一个线程内计算操作次数与共享内存加载操作次数的比值去估算共享内存的延迟。其中COEFbc代表共享内存中产生bank conflicts的程度,可根据共享内存中每个线程束(warp)访问的数据地址计算得到。举例,若一个线程在每次共享内存加载数据的时间内能进行10次浮点数运算,且已知共享内存延迟为20个cycles并且不存在bank conflicts,那么可以得到每20个cycles中有10个cycle可被隐藏,则SMRatio=0.5;若能进行20次浮点数运算,则SMRatio=1,表明共享内存延迟也不是限制性能的因素。流处理器间工作负荷的不平衡workload imbalance between streaming multiprocessors (SMs) (涉及变量见Table 4, 5)若每个线程块所处理的数据个数相同,则线程块间不存在工作负载不均。但当每个线程块所处理的数据不是SM个数的整数倍时,这种不平衡就会显现。使用的线程块数量以及相应的度量值计算如下:硬件资源限制limitation of hardware resources(涉及变量见Table 4, 5)这项指标是为了筛除那些所需资源超出现有可用硬件资源导致生成代码无法运行的kernel。不同于以上三个因素的度量值都是处于0到1之间的变化值,COEFr只有0和1两种取值。3、估算性能上界根据上述四个度量值,DeepCuts给出一个总的度量值PUL,来估算一个张量操作的性能上界:PUL表示对于目标GPU,当前张量操作的最高性能与理论峰值的比值。DeepCuts会计算每个可能出现的参数组合的PUL,只选取结果在前1%的组合去进行下一步的代码生成。对较为常用的张量操作进行了大量参数组合的实验后(ResNet中的3*3卷积及BERT中的矩阵乘法,实验大于十万组参数),测试结果证明性能评估模型没有错误地筛除掉任何性能最优的参数组合。4、共享内存层级与寄存器层级的融合寄存器层级融合:两个简单算子融合成一个简单算子(element-wise OP + ReLU),或一个简单算子和一个复杂算子融合成一个复杂算子(convolution + bias add)。其PUL的计算遵循如下规则:共享内存层级融合:当后向算子的多个线程都需要使用前向算子中一个线程的计算结果(convolution + convolution)。其PUL计算限制如下:数据流图生成生成数据流图(data-flow- graph, DFG)包含以下三个部分:基本DFG生成 baseline DFG generation:表示一个线程块中的计算。当给出这样一组参数S,基本DFG生成如下图Figure 3:当C轴需要被切分(即C input < C)时,代码生成器会生成包含取数据与计算交替的循环,称为looped complex operation。此时DeepCuts会生成两个不同的DFG,一个表示循环体内的操作,另一个表示退出循环时的操作(如将计算结果存储到共享内存中)。DFG拼接 DFG concatenationFigure 4展示了基于共享内存层级和寄存器层级的两种融合方式下产生的不同DFG。每个线程的子图提取subgraph extraction for a GPU threadDeepCuts将DFG中最后一个共享内存的存储操作切分为多个等量的数据块,并分配给不同的线程,然后顺着图中的边(edge)回溯地标记所有访问到的点。到达没有前向节点的节点后,山区所有未被标记的节点即可获得每个线程的sub-DFG。GPU-kernel代码生成DeepCuts基于每个线程的sub-DFG生成kernel代码。首先发射kernel函数头文件和线程/线程块ID的获取,然后根据性能评估器中选定的参数生成从全局内存到共享内存的取数据代码。最后对于计算部分,根据反向逆序遍历sub-DFG然后为每个节点发射代码。对于looped complex operation, 代码生成器也会生成循环结构,以及循环体内的取数据与计算两块代码。常见的优化手段,双缓冲区或称为数据预取,也是在这一步实现,生成器会生成normal和prefetch两块代码,prefetch就是用于隐藏全局内存的加载延迟。DeepCuts还进行了如下对于共享内存的优化:基于内存的索引函数Memory-based index function:由于CUDA代码的SPMD形式,为使得每个线程以数据并行的形式正确访问到其相应数据元素,用thread ID表示该线程在数据中访问的索引。索引函数使用两种计算方式:Computation-based方式是在线程访问相应数据元素时计算索引,memory-base则是在host侧提前计算好并储存在共享内存中。向量化I/O指令:Exploiting vector I/O instructions:即同时从共享内存中加载多位数据如常见的128-bit load,可通过减少加载的指令个数而提高性能。数据补齐减少存储体冲突Bank-conflict aware padding: 通过对输入数据的补零使数据分布对齐从而减少共享内存中的存储体冲突。评估GPU架构:NVIDIA Volta (V100) 和Turing (RTX 2080)Benchmark模型:评估方式:包含每个benchmark模型中训练和推理的workload。对于非CNN模型:记录1个epoch的执行时间,评估不同batch size下1个训练和4个推理共20种workload;对于CNN模型:记录100个mini-batch的执行时间,评估不同batch size下1个训练和2个推理共12种workload。排除了文件I/O及CPU-GPU间数据传输的影响。评估框架:DeepCuts-no-fusion, DeepCuts-fusion, DeepCuts-mixed(cuDNN/cuBLAS与DeepCuts生成的kernel同时使用)。对比框架:TVM-default, TVM-autotvm; TensorFlow, TensorFlow-XLA, TensorRT-integrated TensorFlow; PyTorch.从Table 11和12中看出,在32个workload中的大部分DeepCuts-mixed都能获得最好性能,平均性能优于其余框架。DeepCuts-fused在不适用cuDNN原生库的情况下,也能在其中9个workload中打败其他框架。论文中还强调,DeepCuts-mixed中只有25%的算子使用的是cuDNN/cuBLAS原生库,其余75%仍是框架自主生成的代码。根据Figure 5可分析得出,DeepCuts在不同的benchmark模型场景下的表现也略有不同,但总体都能达到比其他框架更优的性能。Figure 6拆分了不同种类算子的执行时间并进行了不同框架下的对比。得益于DeepCuts在卷积和矩阵乘法等复杂算子上较优的代码生成,以及在简单算子上的融合优化,其总执行时间是相对较短的。Figure 7则给出了代码生成的时间。TVM-autotvm的代码生成时间很慢且波动较大。TensorFlow-XLA和TensorRT使用已有的cuDNN/cuBLAS原生库或事先写好的kernel因此代码生成几乎不费时间,生成速度是DeepCuts的1058倍和652倍。DeepCuts的生成速度是TVM-autotvm的13.53倍,不过其代码生成时间与batch增大引起的搜索空间增大成正比增长。未来工作支持算子多样性:DeepCuts尝试为Shift-Conv-Shift-Conv和Octave Convolution(需拆分为两个kernel)这两种不常见的算子进行kernel代码生成。未来希望通过实现水平融合进一步提高性能。支持GPU后端多样性:目前DeepCuts只支持NVIDIA GPU作为后端。未来希望拓展给予Open-CL的DeepCuts至支持AMD GPUs以及更多移动端侧设备。结论本文介绍了DeepCuts,一个用于多样化GPU工作负载的深度学习优化框架。其主体流程如下:对于给定DL workload中的一系列计算操作,DeepCuts在考虑算子融合的同时,搜索对于每个算子能给出最佳性能的实现参数组合,并使用性能估计模型对会导致“绝对慢”的case进行剪枝。然后,它使用选定的参数组合生成数据流图并生成GPU kernel,通过执行kernel并对比执行时间,为当前workload中的每个算子或融合算子确定使其性能最佳的执行参数。实验评估表明,对于DL工作负载,对于CNN、RNN和Transformer-based MLP的训练和推理,DeepCuts的性能与cuDNN相当甚至有所超越。当DeepCuts在kernel选择过程中同时包括cuDNN原语和自生成代码时(即DeepCuts-mixed):在NVIDIA V100 GPU上,它比cuDNN和PyTorch有1.13和1.46倍的加速;它在推理上与TVM相比实现1.24倍加速(TVM不支持训练),且代码生成时间减少了13.53×;它与支持训练的TensorFlow-XLA相比实现了1.38倍的加速;DeepCuts在与NVIDIA V100体系结构不同的NVIDIA RTX 2080 GPU上也实现了良好的性能。作者还表示DeepCuts的代码也将开源。点评DeepCuts作为新生的深度学习优化框架,其大体流程如数据流图生成、算子融合、融合后的代码生成及生成过程中的代码优化等环节,与其他框架或算子库,包括TVM,TensorFlow, TensorRT以及MindSpore的图算融合&AKG,是类似的。其值得借鉴的两大思路,一个是将我们常见的tuning思路扩展至整个框架上,包括算子融合方式和执行参数选择(目前tuning多用于仅仅选择参数),并且是结合了先剪枝、后逐个执行的策略,以在相对短的时间内获得较优性能。另一个是DeepCuts针对GPU后端会对性能产生限制的四个因素设计了简洁明确的metric value及相应计算公式,以计算出每套执行参数的性能上界并帮助选择。其对GPU后端参数的直接使用(可应对硬件型号调整),清晰的评估逻辑以及对各因素影响的系统性量化,这些特点是值得借鉴的。从另一方面来说,DeepCuts也具有一定局限性。DeepCuts选择最终融合策略与执行参数的方式仍然是通过逐个遍历执行(尽管进行过剪枝),因此其在大batch场景下算子生成时间仍然较长。另外论文中给出的各部分算法较为简单,覆盖场景较少。首先其partition算法只考虑将多个单算子融合成一个大算子(主要适用于简单算子),而没有考虑将单个复杂算子拆分成多个算子再重新融合的场景;其次,文中给出的性能评估metrics所能应对的场景也有所局限,比如对于融合算子,其只能处理将相邻算子纵向拼接的简单融合,同时还对前后向算子shape有一定要求;同时,整篇文章只提及单精度计算操作,而没有对半精度的计算场景做优化,也就意味它没有使能NVIDIA GPU专为半精度和混合精度计算设计的Tensor Cores加速单元。可能DeepCuts目前还难以处理应用Tensor Cores带来的更大的参数搜索空间,和更复杂的代码生成流程。总的来说,DeepCuts的框架实现思路能够为深度学习框架后续发展带来不少启发,不过有些部分的算法还有待丰富,可以期待一下代码的开源。注:文章中所有图片均来自论文《DeepCuts: A Deep Learning Optimization Framework for Versatile GPU Workloads》。转自文章链接:https://zhuanlan.zhihu.com/p/393460585感谢作者的努力与分享,侵权立删!
  • [技术干货] mindspore 1.3.0版本GPU环境下源码编译的正式工作——完整的编译过程
    编译之前需要完成依赖环境的安装,具体请看:https://bbs.huaweicloud.com/forum/forum.php?mod=viewthread&tid=143084编译前之前的工作这里不再叙述。本文原文地址:https://www.cnblogs.com/devilmaycry812839668/p/15060119.html-------------------------------------------------------------------------------------------------------正文内容:必要环境已经全部安装好,开始编译工作,源代码下载:git clone https://gitee.com/mindspore/mindspore.git -b r1.3  源代码下载好以后我们先不进行源码编译,因为源代码中有部分bug没有修复,如果我们直接进行编译的话则会报错。具体信息见:https://www.cnblogs.com/devilmaycry812839668/p/15042017.htmlhttps://www.cnblogs.com/devilmaycry812839668/p/15054624.htmlhttps://www.cnblogs.com/devilmaycry812839668/p/15059000.html   由文章:https://www.cnblogs.com/devilmaycry812839668/p/15059000.html中给出的bug修复方式我们进行修改。 修改mindspore源代码  分支:r1.3 下对应的文件:cmake/external_libs/ompi.cmake 修改后的完整内容:if(ENABLE_GITEE) set(REQ_URL "https://download.open-mpi.org/release/open-mpi/v4.0/openmpi-4.0.3.tar.gz") set(MD5 "f4be54a4358a536ec2cdc694c7200f0b")else() set(REQ_URL "https://download.open-mpi.org/release/open-mpi/v4.0/openmpi-4.0.3.tar.gz") set(MD5 "f4be54a4358a536ec2cdc694c7200f0b")endif()set(ompi_CXXFLAGS "-D_FORTIFY_SOURCE=2 -O2")mindspore_add_pkg(ompi VER 4.0.3 LIBS mpi URL ${REQ_URL} MD5 ${MD5} PRE_CONFIGURE_COMMAND ./configure CONFIGURE_COMMAND ./configure)include_directories(${ompi_INC})add_library(mindspore::ompi ALIAS ompi::mpi)    使用help参数来查看编译时参数的设置:bash build.sh -h---------------- MindSpore: build start ----------------Usage:bash build.sh [-d] [-r] [-v] [-c on|off] [-t ut|st] [-g on|off] [-h] [-b ge] [-m infer|train] \ [-a on|off] [-p on|off] [-i] [-R] [-D on|off] [-j[n]] [-e gpu|ascend|cpu] \ [-P on|off] [-z [on|off]] [-M on|off] [-V 10.1|11.1|310|910] [-I arm64|arm32|x86_64] [-K] \ [-B on|off] [-E] [-l on|off] [-n full|lite|off] [-H on|off] \ [-A on|off] [-S on|off] [-k on|off] [-W sse|neon|avx|avx512|off] \ [-L Tensor-RT path] \Options: -d Debug mode -r Release mode, default mode -v Display build command -c Enable code coverage, default off -t Run testcases, default off -g Use glog to output log, default on -h Print usage -b Select other backend, available: \ ge:graph engine -m Select graph engine backend mode, available: infer, train, default is infer -a Enable ASAN, default off -p Enable pipeline profile, print to stdout, default off -R Enable pipeline profile, record to json, default off -i Enable increment building, default off -j[n] Set the threads when building (Default: -j8) -e Use cpu, gpu or ascend -s Enable security, default off -P Enable dump anf graph to file in ProtoBuffer format, default on -D Enable dumping of function graph ir, default on -z Compile dataset & mindrecord, default on -n Compile minddata with mindspore lite, available: off, lite, full, lite_cv, full mode in lite train and lite_cv, wrapper mode in lite predict -M Enable MPI and NCCL for GPU training, gpu default on -V Specify the device version, if -e gpu, default CUDA 10.1, if -e ascend, default Ascend 910 -I Enable compiling mindspore lite for arm64, arm32 or x86_64, default disable mindspore lite compilation -A Enable compiling mindspore lite aar package, option: on/off, default: off -K Compile with AKG, default on -B Enable debugger, default on -E Enable IBVERBS for parameter server, default off -l Compile with python dependency, default on -S Enable enable download cmake compile dependency from gitee , default off -k Enable make clean, clean up compilation generated cache -W Enable x86_64 SSE or AVX instruction set, use [sse|neon|avx|avx512|off], default off for lite and avx for CPU -H Enable hidden -L Link and specify Tensor-RT library path, default disable Tensor-RT lib linking    启动前文安装的Python环境:conda activate ms  从帮助信息中(-S Enable enable download cmake compile dependency from gitee , default off)我们可以知道在编译时我们可以选择使用gitee源的地址,这样会大大提供编译时依赖文件的下载速度,因此完整的编译命令如下:bash build.sh -e gpu -S on  发现编译报错:make: *** [all] Error 2 ---------------------------------------------------------------------------------- (可忽略部分开始:)这部分内容为定位error并修正,实际安装时不需要这一步骤:修改编译命令,进行编译错误定位:(默认是多线程编译,即-j8,可以快速的进行依赖文件下载和编译,但是不利于error定位,我们先使用默认的方式编译可以快速的进行依赖文件下载和部分编译)bash build.sh -e gpu -S on -j1  提示出具体的报错信息:[100%] Linking CXX shared library libmindspore.so[100%] Built target mindspore_shared_lib[100%] Linking CXX shared library _c_dataengine.cpython-37m-x86_64-linux-gnu.so[100%] Built target _c_dataengineConsolidate compiler generated dependencies of target engine-cache-server[100%] Building CXX object mindspore/ccsrc/minddata/dataset/engine/cache/CMakeFiles/engine-cache-server.dir/cache_hw.cc.o/tmp/mindspore/mindspore/ccsrc/minddata/dataset/engine/cache/cache_hw.cc: 在构造函数‘mindspore::dataset::CacheServerHW::CacheServerHW()’中:/tmp/mindspore/mindspore/ccsrc/minddata/dataset/engine/cache/cache_hw.cc:42:45: 错误:从类型‘int64_t* {aka long int*}’到类型‘long long int*’的转换无效 [-fpermissive] int64_t mem_avail = numa_node_size(i, &free_avail); ^~~~~~~~~~~In file included from /tmp/mindspore/mindspore/ccsrc/minddata/dataset/engine/cache/cache_hw.h:20:0, from /tmp/mindspore/mindspore/ccsrc/minddata/dataset/engine/cache/cache_hw.cc:16:/usr/local/include/numa.h:146:11: 附注: 初始化‘long long int numa_node_size(int, long long int*)’的实参 2 long long numa_node_size(int node, long long *freep); ^~~~~~~~~~~~~~在全局域:cc1plus: 错误:unrecognized command line option ‘-Wno-stringop-truncation’ [-Werror]cc1plus: 错误:unrecognized command line option ‘-Wno-class-memaccess’ [-Werror]cc1plus:所有的警告都被当作是错误mindspore/ccsrc/minddata/dataset/engine/cache/CMakeFiles/engine-cache-server.dir/build.make:148: recipe for target 'mindspore/ccsrc/minddata/dataset/engine/cache/CMakeFiles/engine-cache-server.dir/cache_hw.cc.o' failedmake[2]: *** [mindspore/ccsrc/minddata/dataset/engine/cache/CMakeFiles/engine-cache-server.dir/cache_hw.cc.o] Error 1CMakeFiles/Makefile2:3127: recipe for target 'mindspore/ccsrc/minddata/dataset/engine/cache/CMakeFiles/engine-cache-server.dir/all' failedmake[1]: *** [mindspore/ccsrc/minddata/dataset/engine/cache/CMakeFiles/engine-cache-server.dir/all] Error 2Makefile:155: recipe for target 'all' failedmake: *** [all] Error 2错误定位的文件位置:mindspore/mindspore/ccsrc/minddata/dataset/engine/cache/cache_hw.cc:42:45 错误信息:从类型‘int64_t* {aka long int*}’到类型‘long long int*’的转换无效 [-fpermissive]       int64_t mem_avail = numa_node_size(i, &free_avail); 从该定位到的错误可以知道是编译过程中生成的代码中存在类型转换错误,于是进行修改:将报错语句修改为:       int64_t mem_avail = numa_node_size(i, reinterpret_cast <long long int *>(&free_avail)); 然后重新进行编译即可。   (可忽略部分结束。)----------------------------------------------------------------------------------  我们可以直接跨过上面的可忽略部分中的错误定位(即,bash build.sh -e gpu -S on -j1)直接对文件进行修改,然后重新编译:bash build.sh -e gpu -S on 成功编译:    编译完成后生成的MindSpore WHL安装包路径为: build/package/mindspore_gpu-1.3.0-cp37-cp37m-linux_x86_64.whl;  将我们编译好的文件拷贝出来,在我们激活的Python环境下进行安装即可:pip install mindspore_gpu-1.3.0-cp37-cp37m-linux_x86_64.whl  运行官网中的测试代码:import numpy as npfrom mindspore import Tensorimport mindspore.ops as opsimport mindspore.context as contextcontext.set_context(device_target="GPU")x = Tensor(np.ones([1,3,3,4]).astype(np.float32))y = Tensor(np.ones([1,3,3,4]).astype(np.float32))print(ops.tensor_add(x, y))   成功运行:     证明我们编译后的最终文件可以成功安装并运行,编译工作成功完成。 
  • [技术干货] mindspore 1.3.0版本GPU环境下源码编译前的准备工作——依赖环境的安装
    原文地址:国产计算框架mindspore在gpu环境下编译分支r1.3,使用suod权限成功编译并安装,成功运行——(修复部分bug,给出具体编译和安装过程)链接:https://www.cnblogs.com/devilmaycry812839668/p/15059089.html=====================================================================国产计算框架MindSpore的r1.3分支源代码存在部分bug,导致无法从源码方式进行gpu环境下的编译。具体参看:https://www.cnblogs.com/devilmaycry812839668/p/15059000.htmlhttps://www.cnblogs.com/devilmaycry812839668/p/15054624.html  本文给出对r1.3分支存在的部分bug就行修正,然后成功进行编译,并验证编译后的文件可以正常运行,证明本文方式可以成功解决r1.3分支无法在gpu环境下进行编译的问题。本文给出具体的安装步骤及具体bug的修改方式。   计算框架mindspore的官网:https://www.mindspore.cn/install r1.3是当下最新发布的版本,因此这里选择对该版本下的gpu环境下进行编译。      需要的依赖软件:    ========================================================== 经过验证如果不使用sudo权限的话需要对mindspore的源码中的cmake文件进行大幅度修改,因此本文都是在具有sudo权限下进行的。操作系统:Ubuntu18.04CPU:i7 9700kGPU:   RTX 2060SUPER  依赖环境的安装: 1.  安装CUDA11.1.0 和 cuDNN 8.0.X版本:下载cuda源码并安装:wget https://developer.download.nvidia.com/compute/cuda/11.1.0/local_installers/cuda_11.1.0_455.23.05_linux.runsudo sh ./cuda_11.1.0_455.23.05_linux.run --toolkit --silent  cuDnn下载并安装:  下载地址:https://developer.nvidia.com/compute/machine-learning/cudnn/secure/8.0.5/11.1_20201106/cudnn-11.1-linux-x64-v8.0.5.39.tgz   解压文件:              tar -zxvf cudnn-11.1-linux-x64-v8.0.5.39.tgz  拷贝解压后的文件到cuda安装目录内: sudo cp cuda/include/* /usr/local/cuda-11.1/include sudo cp cuda/lib64/* /usr/local/cuda-11.1/lib64  配置环境变量:修改  .bashrc  文件export PATH=/usr/local/cuda-11.1/bin:$PATHexport LD_LIBRARY_PATH=/usr/local/cuda-11.1/lib64:$LD_LIBRARY_PATH  重新载入  .bashrc 文件:source ~/.bashrc       2. GCC的安装:下载gcc 7.3.0版本安装包,执行以下命令:              wget  http://ftp.gnu.org/gnu/gcc/gcc-7.3.0/gcc-7.3.0.tar.gz 执行tar -xzf gcc-7.3.0.tar.gz解压源码包。 执行cd gcc-7.3.0,进入到源码包目录。 继续下面操作前清空系统内的环境变量:export LIBRARY_PATH=export LD_LIBRARY_PATH=export C_INCLUDE_PATH=export CPLUS_INCLUDE_PATH=   运行以下命令,进行安装前的配置。安装依赖环境:./contrib/download_prerequisites  配置环境:./configure --enable-bootstrap -enable-threads=posix --enable-checking=release --enable-languages=c,c++ --disable-multilib    编译安装:make -j8 && sudo make install      3.   m4  下载安装:下载:wget   http://ftp.gnu.org/gnu/m4/m4-1.4.16.tar.bz2 解压:               tar -jxvf m4-1.4.16.tar.bz2   修改m4_1.4.16下源文件中代码:(https://blog.csdn.net/weixin_34168880/article/details/91842744)vi lib/stdio.in.h查找字段:gets is a security hole注释:将_GL_WARN_ON_USE (gets, "gets is a security hole - use fgets instead"); 字段和他之前的注释 /* 一块注释掉,如下/* It is very rare that the developer ever has full control of stdin, so any use of gets warrants an unconditional warning. Assume it is always declared, since it is required by C89.#undef gets_GL_WARN_ON_USE (gets, "gets is a security hole - use fgets instead"); */ 再添加如下内容: #if defined(__GLIBC__) && !defined(__UCLIBC__) && !__GLIBC_PREREQ(2, 16) _GL_WARN_ON_USE (gets, "gets is a security hole - use fgets instead"); #endif  配置:./configure  编译安装make &&sudo make install      4.    安装gmp 6.1.2 下载gmp 6.1.2源码包:            wget https://gmplib.org/download/gmp/gmp-6.1.2.tar.xz  解压到当前文件夹:           tar -xvf  gmp-6.1.2.tar.xz    配置: ./configure  --enable-cxx  编译安装:make && sudo make install   测试 gmp 是否安装并配置成功:(声明:测试部分内容源于:https://blog.csdn.net/just_h/article/details/82667787)代码:# test.cpp 文件#include <gmpxx.h>#include <iostream>#include <stdio.h>using namespace std;int main(){ mpz_t a,b,c; mpz_init(a); mpz_init(b); mpz_init(c); gmp_scanf("%Zd%Zd",a,b); mpz_add(c,a,b); gmp_printf("c= %Zd\n",c); return 0;}  编译:g++ test.cpp -o test -lgmp 运行:         5.   openssl 的安装:下载地址:https://www.openssl.org/source/openssl-1.1.1k.tar.gz 解压:tar -zxvf openssl-1.1.1k  配置:./config  编译并安装:make -j8&& sudo make install  配置系统环境:  修改  .bashrc  文件,添加内容:# opensslexport OPENSSL_ROOT_DIR=/usr/local/lib64  重新载入  .bashrc 文件:source ~/.bashrc    说明:  前5步的依赖环境的安装足够使用pip安装的方式安装mindspore1.3.0版本,具体参看:https://www.cnblogs.com/devilmaycry812839668/p/15055035.html        6.   CMAKE的安装  (前面几步操作make的时候都是使用系统自带的旧版本cmake,这里的cmake安装是为编译mindspore用的)下载文件:wget    https://github.com/Kitware/CMake/releases/download/v3.21.0/cmake-3.21.0.tar.gz  解压:tar -zxvf cmake-3.21.0.tar.gz  配置:./configure   编译并安装:make -j8&& sudo make install    配置系统环境:  修改  .bashrc  文件,添加内容:(为cmake指定调用何处的gcc与g++,否则可能会调用系统中以前版本的gcc与g++)# CCexport CC=/usr/local/bin/gccexport CXX=/usr/local/bin/g++   重新载入  .bashrc 文件:source ~/.bashrc     7.  patch 的安装:下载文件:wget  https://ftp.gnu.org/gnu/patch/patch-2.7.6.tar.gz  解压:tar -zxvf patch-2.7.6.tar.gz  配置:./configure    编译并安装:make -j8&& sudo make install       8.  安装Autoconf下载文件:wget https://ftp.gnu.org/gnu/autoconf/autoconf-2.71.tar.gz   解压: tar -zxvf autoconf-2.71.tar.gz  配置:./configure   编译并安装:make -j8&& sudo make install      9.    安装   libtool   下载地址:wget https://ftpmirror.gnu.org/libtool/libtool-2.4.6.tar.gz   解压:tar -zxvf libtool-2.4.6.tar.gz 配置:./configure  编译并安装:make -j8&& sudo make install       10.   安装automake下载:wget https://ftp.gnu.org/gnu/automake/automake-1.16.3.tar.gz  解压:tar -zxvf automake-1.16.3.tar.gz 配置:./configure    编译并安装:make -j8&& sudo make install         11.   安装flex下载文件:wget https://github.com/westes/flex/files/981163/flex-2.6.4.tar.gz 解压:tar -zxvf flex-2.6.4.tar.gz 配置:./configure  编译并安装:make -j8&& sudo make install       12.   安装NUMA官网建议安装方式:apt-get install libnuma-dev 这里给出个人的安装方式,本人并没有使用官方的安装方式:首先卸载系统中的numa环境:sudo apt-get remove libnuma-dev  手动安装numa:下载:wget https://github.com/numactl/numactl/releases/download/v2.0.14/numactl-2.0.14.tar.gz 解压:tar -zxvf numactl-2.0.14.tar.gz 配置:./configure   编译并安装:make -j8&& sudo make install      13.   确认安装git工具(一般系统里都有git,这一步基本可以忽略)如果未安装,使用如下命令下载安装:sudo apt-get install git     以上为依赖环境的安装(除Python外)。 =====================================================================  安装运行mindspore的Python环境,这里为方便直接选择用anaconda方式创建:Python环境3.7.5, 为anaconda创建,命令:conda create -n ms python=3.7.5   激活Python环境:conda activate ms   注意: anaconda创建的Python环境自带wheel,因此这里不用再手动安装wheel。如果Python环境下没有wheel需要手动安装,方式如下:安装wheel:pip install wheel    ==========================================================     本文参考:https://www.mindspore.cn/news/newschildren?id=401 
  • [技术干货] Mindspore1.3.0 gpu源代码中的cmake文件存在问题(bug),openmpi的url错误,导致不能正常编译
    mindspore1.3 gpu版本无法从源代码方式进行编译,具体参看:https://www.cnblogs.com/devilmaycry812839668/p/15054624.html编译时会报错,提示就是使用cmake自动编译mindspore-r1.3-gpu版本时openmpi的源代码中存在语法错误,经过检查发现是其中给出的openmpi地址对应的openmpi源代码中存在bug,即使是单独编译该地址下的openmpi源代码也会同样报错。mindspore源代码  分支:r1.3 下对应的文件:cmake/external_libs/ompi.cmake该文件中的完整代码如下:if(ENABLE_GITEE) set(REQ_URL "https://gitee.com/mirrors/ompi/repository/archive/v4.0.3.tar.gz") set(MD5 "f76abc92ae870feff186d790f40ae762")else() set(REQ_URL "https://github.com/open-mpi/ompi/archive/v4.0.3.tar.gz") set(MD5 "86cb724e8fe71741ad3be4e7927928a2")endif()set(ompi_CXXFLAGS "-D_FORTIFY_SOURCE=2 -O2")mindspore_add_pkg(ompi VER 4.0.3 LIBS mpi URL ${REQ_URL} MD5 ${MD5} PRE_CONFIGURE_COMMAND ./autogen.pl CONFIGURE_COMMAND ./configure)include_directories(${ompi_INC})add_library(mindspore::ompi ALIAS ompi::mpi)个人修改后的文件:cmake/external_libs/ompi.cmake完整内容:if(ENABLE_GITEE) set(REQ_URL "https://download.open-mpi.org/release/open-mpi/v4.0/openmpi-4.0.3.tar.gz") set(MD5 "f4be54a4358a536ec2cdc694c7200f0b")else() set(REQ_URL "https://download.open-mpi.org/release/open-mpi/v4.0/openmpi-4.0.3.tar.gz") set(MD5 "f4be54a4358a536ec2cdc694c7200f0b")endif()set(ompi_CXXFLAGS "-D_FORTIFY_SOURCE=2 -O2")mindspore_add_pkg(ompi VER 4.0.3 LIBS mpi URL ${REQ_URL} MD5 ${MD5} PRE_CONFIGURE_COMMAND ./configure CONFIGURE_COMMAND ./configure)include_directories(${ompi_INC})add_library(mindspore::ompi ALIAS ompi::mpi)该文件如此修改后经过个人验证,可以成功在gpu环境下编译mindspore r1.3分支。该bug已经提交PR给官网:PR地址:https://gitee.com/mindspore/mindspore/pulls/20824
  • [安装] 【Mindspore-GPU】【编译过程】使用源码编译过程中报错
    【功能模块】我使用源码编译的时候提示如图所示的错误,我是Ubuntu20.04版本,CUDA11.0,cuDNN8.0【操作步骤&问题现象】1、我使用源码编译的时候提示如图所示的错误,我是Ubuntu20.04版本,CUDA11.0,cuDNN8.0,然后大概到78%的时候显示make【】error,想问一下能不能解决,怎么解决【截图信息】【日志信息】(可选,上传日志内容或者附件)
  • [问题求助] 【昇腾910平台】【Tensorflow算法迁移】算法从GPU迁移至昇腾NPU报错
    【功能模块】昇腾910TensorFlow1.15【操作步骤&问题现象】1、原算法可在GPU跑通2、原算法可在昇腾平台CPU跑通,即AICore占用为03、按照迁移指导(自动和手动)完成修改后,报错,无法在NPU运行【截图信息】【日志信息】(可选,上传日志内容或者附件)见附件
  • [问题求助] 【昇腾910】TensorFlow算法从GPU迁移至昇腾NPU报错
    【功能模块】昇腾910TensorFlow 1.15【操作步骤&问题现象】1、算法代码可在GPU跑通2、算法代码修改前可在昇腾平台运行,AICore占用0%3、根据迁移指导书修改代码后,报错,无法运行【截图信息】【日志信息】(可选,上传日志内容或者附件)
  • [问题求助] 【昇腾910】TensorFlow算法从GPU迁移至昇腾NPU报错
    【功能模块】昇腾910TensorFlow 1.15【操作步骤&问题现象】1、算法代码可在GPU跑通2、算法代码修改前可在昇腾平台运行,AICore占用0%3、根据迁移指导书修改代码后,报错,无法运行【截图信息】【日志信息】(可选,上传日志内容或者附件)见附件
  • [问题求助] 【MindSpore】【GPU训练】TypeError: 'NoneType' is not callable
    【功能模块】使用GPU训练Faster rcnn模型【操作步骤&问题现象】1、使用GPU训练Faster rcnn模型时出现如下错误【截图信息】日志链接:https://paste.ubuntu.com/p/GVyhCCwD3m/【日志信息】(可选,上传日志内容或者附件)
  • [分布式] docker1.2.1-gpu报错:Failed to init nccl communicator for group
    【功能模块】from mindspore.communication.management import initfrom mindspore.context import ParallelMode【操作步骤&问题现象】1、docker-1.2.1-gpu 版本下运行分布式代码:from mindspore import contextfrom mindspore.communication.management import initcontext.set_context(mode=context.GRAPH_MODE, device_target="GPU")init()import numpy as npfrom mindspore import dataset as dsfrom mindspore import nn, Tensor, Modelimport timefrom mindspore.train.callback import Callback, LossMonitor, ModelCheckpoint, CheckpointConfigfrom mindspore.context import ParallelModeimport mindspore as msms.common.set_seed(0)start_time = time.time()def get_data(num, a=2.0, b=3.0, c=5.0): for _ in range(num): x = np.random.uniform(-1.0, 1.0) y = np.random.uniform(-1.0, 1.0) noise = np.random.normal(0, 0.03) z = a * x ** 2 + b * y ** 3 + c + noise yield np.array([[x**2], [y**3]],dtype=np.float32).reshape(1,2), np.array([z]).astype(np.float32)def create_dataset(num_data, batch_size=16, repeat_size=1): input_data = ds.GeneratorDataset(list(get_data(num_data)), column_names=['xy','z']) input_data = input_data.batch(batch_size) input_data = input_data.repeat(repeat_size) return input_datadata_number = 1600batch_number = 64 repeat_number = 20context.set_auto_parallel_context(parallel_mode=ParallelMode.DATA_PARALLEL)ds_train = create_dataset(data_number, batch_size=batch_number, repeat_size=repeat_number)dict_datasets = next(ds_train.create_dict_iterator())class LinearNet(nn.Cell): def __init__(self): super(LinearNet, self).__init__() self.fc = nn.Dense(2, 1, 0.02, 0.02) def construct(self, x): x = self.fc(x) return xnet = LinearNet()model_params = net.trainable_params()print ('Param Shape is: {}'.format(len(model_params)))for net_param in net.trainable_params(): print(net_param, net_param.asnumpy())net_loss = nn.loss.MSELoss()optim = nn.Momentum(net.trainable_params(), learning_rate=0.01, momentum=0.6)ckpt_config = CheckpointConfig()ckpt_callback = ModelCheckpoint(prefix='data_parallel', config=ckpt_config)model = Model(net, net_loss, optim)epoch = 1000#model.train(epoch, ds_train, dataset_sink_mode=True)#model.train(epoch, ds_train, callbacks=[ckpt_callback], dataset_sink_mode=True)model.train(epoch, ds_train, callbacks=[LossMonitor(500)], dataset_sink_mode=True)for net_param in net.trainable_params(): print(net_param, net_param.asnumpy())print ('The total time cost is: {}s'.format(time.time() - start_time))代码原地址:https://www.cnblogs.com/dechinphy/p/dms.html2、运行命令:mpirun -n 4 python ./test_nonlinear.py软硬件:运行环境:硬件:Intel CPU, 4卡泰坦软件:Ubuntu18.04宿主机,docker容器运行MindSpore-gpu-1.2.1-docker版本【截图信息】【日志信息】(可选,上传日志内容或者附件)Failed to init nccl communicator for group init nccl communicator for group nccl_world_group
  • [技术干货] 鲲鹏服务器安装NV显卡报Unable to determine the device handle for GPU错误解决方法
    【问题描述】鲲鹏服务器安装NVIDIA 2080 Ti显卡,安装NVIDIA-Linux-aarch64-460.73.01.run驱动后执行nvidia-smi 后报Unable to determine the device handle for GPU 0000:82:00.0: Unknown Error错误【定位过程】从上面到报错信息无法看出问题原因,浏览器搜索也没有找到详细原因;安装cuda_11.1.0_455.23.05_linux_sbsa.run驱动自带到455.23.05驱动,再次执行nvidia-smi报如下错误:Unable to determine the device handle for GPU 0000:82:00.0: Unable to communicate with GPU because it is insufficiently powered. This may be because not all required external power cables are attached, or the attached cables are not seated properly.从报错信息可以看出原因是NVIDIA卡供电不足导致。【解决方法】下电鲲鹏服务器,根据GPU卡电源接口情况连接GPU电源线到Riser卡,然后重新上电安装NVIDIA-Linux-aarch64-460.73.01.run驱动后,此时执行nvidia-smi即可正常显示:注:2080 Ti卡及30系到NV显卡都需要连接GPU电源线才能让GPU正常工作。
  • [安装] gpu版本安装验证错误
    >>> import numpy as np>>> from mindspore import Tensor>>> import mindspore.ops as ops>>> import mindspore.context as context>>> >>> context.set_context(device_target="GPU")>>> x = Tensor(np.ones([1,3,3,4]).astype(np.float32))>>> y = Tensor(np.ones([1,3,3,4]).astype(np.float32))>>> print(ops.add(x, y))[[[[0. 0. 0. 0.]   [0. 0. 0. 0.]   [0. 0. 0. 0.]]  [[0. 0. 0. 0.]   [0. 0. 0. 0.]   [0. 0. 0. 0.]]  [[0. 0. 0. 0.]   [0. 0. 0. 0.]   [0. 0. 0. 0.]]]]>>> 环境是ubuntu18.04,cuda10.1,显卡是Geforce Titan X
  • [其他] “华为云杯”2021人工智能应用创新大赛的测评机器是CPU还是GPU运行的?
    “华为云杯”2021人工智能应用创新大赛的测评机器是CPU还是GPU运行的?
  • [技术干货] 基于Docker安装的MindSpore-1.2 GPU版本
    技术背景在前面一篇博客中,我们介绍过MindSpore-CPU版本的Docker部署以及简单的案例测试,当时官方还不支持GPU版本的Docker容器化部署。经过MindSpore团队的努力,1.2.0版本的MindSpore-GPU终于推出了Docker版本的安装解决方案:在本文中我们将针对这一方案进行直接的测试,并补充其中一些很有可能被忽略的细节,接下来直接上手。更换华为云镜像源在华为云官方提供的镜像源仓库中找到适配自己系统的源,然后按照其中的指导进行配置。这里我们本地使用的是Ubuntu 20.04版本,可以按照如下的方法更新apt的源:root@ubuntu2004:~# cp -a /etc/apt/sources.list /etc/apt/sources.list.bakroot@ubuntu2004:~# sed -i "s@http://.*archive.ubuntu.com@http://repo.huaweicloud.com@g" /etc/apt/sources.listroot@ubuntu2004:~# sed -i "s@http://.*security.ubuntu.com@http://repo.huaweicloud.com@g" /etc/apt/sources.listroot@ubuntu2004:~# apt-get update更新镜像源会需要一定的时间,等待即可,这一步一般不会出什么问题。MindSpore-GPU-Docker的安装这里可以参考MindSpore官方的指导文档一步步的进行操作,其中遇到一些非常规问题时我们再看看解决的策略:root@ubuntu2004:~# DISTRIBUTION=$(. /etc/os-release; echo $ID$VERSION_ID)root@ubuntu2004:~# curl -s -L https://nvidia.github.io/nvidia-docker/gpgkey | apt-key add -gpg: 找不到有效的 OpenPGP 数据。第二步的操作时非常容易出问题的地方,因为本地的主机列表无法解析这个链接的ip地址。一开始我跟参考链接1的作者类似的,以为是需要上Google才能够解决此类的问题,但是后来尝试了一下参考链接1中的解决方案,发现是可以生效的,这里直接演示解决的方法:root@ubuntu2004:~# vi /etc/hosts # 在文档的最后面加上下面的四行ip地址与域名相对照的列表root@ubuntu2004:~# cat /etc/hosts | grep nvidia # 查询修改情况185.199.108.153 nvidia.github.io185.199.109.153 nvidia.github.io185.199.110.153 nvidia.github.io185.199.111.153 nvidia.github.io经过上述的简单配置之后,继续MindSpore-GPU-Docker的安装步骤:root@ubuntu2004:~# curl -s -L https://nvidia.github.io/nvidia-docker/gpgkey | apt-key add -OKroot@ubuntu2004:~# curl -s -L https://nvidia.github.io/nvidia-docker/$DISTRIBUTION/nvidia-docker.list | tee /etc/apt/sources.list.d/nvidia-docker.listdeb https://nvidia.github.io/libnvidia-container/stable/ubuntu18.04/$(ARCH) /#deb https://nvidia.github.io/libnvidia-container/experimental/ubuntu18.04/$(ARCH) /deb https://nvidia.github.io/nvidia-container-runtime/stable/ubuntu18.04/$(ARCH) /#deb https://nvidia.github.io/nvidia-container-runtime/experimental/ubuntu18.04/$(ARCH) /deb https://nvidia.github.io/nvidia-docker/ubuntu18.04/$(ARCH) /root@ubuntu2004:~# apt-get update && sudo apt-get install -y nvidia-container-toolkit nvidia-docker2root@ubuntu2004:~# systemctl restart docker到这里所需要的依赖就已经安装完成了,最后还有一步是需要修改docker的配置文件,使得MindSpore可以使用Docker的nvidia-container-runtime:root@ubuntu2004:~# vi /etc/docker/daemon.json # 修改成如下所示的配置root@ubuntu2004:~# cat /etc/docker/daemon.json {    "runtimes": {        "nvidia": {            "path": "nvidia-container-runtime",            "runtimeArgs": []        }    }} root@ubuntu2004:~# systemctl daemon-reload # 重新加载配置root@ubuntu2004:~# systemctl restart docker # 重启Docker上述配置都完成之后,终于到了最后一步,使用Docker来拉取MindSpore的官方镜像:root@ubuntu2004:~# docker pull swr.cn-south-1.myhuaweicloud.com/mindspore/mindspore-gpu:1.2.01.2.0: Pulling from mindspore/mindspore-gpu6e0aa5e7af40: Pull complete d47239a868b3: Pull complete 49cbb10cca85: Pull complete 4450dd082e0f: Pull complete b4bc5dc4c4f3: Pull complete 5353957e2ca6: Pull complete f91e05a16062: Pull complete 7a841761f52f: Pull complete 698198ce2872: Pull complete 05a2da03249e: Pull complete b1761864f72a: Pull complete 29479e68065f: Pull complete 4bf6be16ed12: Pull complete c429d95fc15b: Pull complete 48c41c211021: Pull complete 349cae3c1ede: Pull complete 768237cdcd4d: Pull complete 2fd2faf6c353: Pull complete 268f4496a02c: Pull complete e962d4980323: Pull complete f1d280968a28: Pull complete bc3e02707e81: Pull complete Digest: sha256:3318c68d63cfe110e85d7ed93398b308f8458624dc96aad9a4d31bc6d345daa7Status: Downloaded newer image for swr.cn-south-1.myhuaweicloud.com/mindspore/mindspore-gpu:1.2.0swr.cn-south-1.myhuaweicloud.com/mindspore/mindspore-gpu:1.2.0关于Docker这里要多说两点:Docker在Ubuntu20.04上面的安装不是apt-get install docker,而是apt-get install docker.io关于更多Docker的使用示例,可以参考这些以往的博客(博客1,博客2,博客3,博客4,博客5)。MindSpore-GPU的测试测试用例同样也来自于MindSpore的官方文档,这里只是额外补充了一个本地的目录映射,将测试目录/home/dechin/projects/mindspore/test/映射为MindSpore容器中的/home目录,这样在容器内操作所导致的文件变更都会在本地测试目录下同步。需要注意的是,这里的目录映射只能采用绝对路径而不能采用相对路径:dechin@ubuntu2004:~/projects/mindspore/test$ sudo docker run -it -v /dev/shm:/dev/shm -v /home/dechin/projects/mindspore/test/:/home --runtime=nvidia --privileged=true swr.cn-south-1.myhuaweicloud.com/mindspore/mindspore-gpu:1.2.0 /bin/bash[sudo] dechin 的密码: root@0b44a5a66fca:/# cd /home/root@0b44a5a66fca:/home# vim mindspore_test.py # python文件的具体内容在后面root@0b44a5a66fca:/home# python mindspore_test.py [[[[2. 2. 2. 2.]   [2. 2. 2. 2.]   [2. 2. 2. 2.]]   [[2. 2. 2. 2.]   [2. 2. 2. 2.]   [2. 2. 2. 2.]]   [[2. 2. 2. 2.]   [2. 2. 2. 2.]   [2. 2. 2. 2.]]]]如下所示是刚才在容器中用于测试的python代码:# mindspore_test.py import numpy as npimport mindspore.context as contextimport mindspore.ops as opsfrom mindspore import Tensor context.set_context(mode=context.PYNATIVE_MODE, device_target="GPU") x = Tensor(np.ones([1,3,3,4]).astype(np.float32))y = Tensor(np.ones([1,3,3,4]).astype(np.float32))print(ops.add(x, y))我们可以看到最终是成功的运行了,说明MindSpore-GPU的Docker容器化环境部署成功。总结概要继上一篇文章介绍了MindSpore的CPU版本的Docker容器化部署之后,MindSpore官方团队推出了MindSpore的GPU版本的Docker容器化部署方案,本文针对这一方案进行了安装测试,并且对于其中一些安装的时候可以遇到的问题的细节进行了处理。之所以采用容器化的解决方案,主要是为了做到SDK环境与编程环境的隔离,释放本地环境配置与部署的压力。当然,也使得本地的开发环境更加的“干净”。————————————————原文链接:https://blog.csdn.net/baidu_37157624/article/details/117315758
总条数:182 到第
上滑加载中