基于GPU的低成本物联网板的潜力

沙特国王大学学报释放低成本物联网板的隐藏力量：基于GPU的寓教于乐案例研究马尔瓦湾Elteira，Shaimaa Lazema，Mohamed Azaba，b科学研究和技术应用城，埃及b美国弗吉尼亚州列克星敦弗吉尼亚军事学院计算机与信息科学系阿提奇莱因福奥文章历史记录：收到2019年2019年12月19日修订2020年2月2日接受在线预订2020年关键词：教育娱乐树莓派嵌入式GPU VideoCoreGPU OpenGL-ESA B S T R A C T由低成本、通用、小尺寸、强大的计算平台的最近发展实现的无处不在的互连智能设备设计了术语物联网（IoT），其贯穿我们现代生活的许多领域。物联网应用超越了简单的传感和驱动，而是复杂的本地化处理和决策。嵌入式系统的最新进展产生了一长串配备强大中央处理单元（CPU）和图形处理单元（GPU）的物联网板。不幸的是，即使这些GPU的能耗有限且处理能力很高，CPU通常也是托管应用程序使用的唯一计算元件，从而阻碍了整个主板的功能。这主要是由于基于GPU的编程的复杂性。在本文中，我们将介绍一个案例研究，展示将延迟敏感的教育游戏的计算密集型部分卸载到低成本Raspberry Pi的GPU上的效果主要依赖于板CPU显示非常长的交互延迟，即，4.82 S.通过有效地利用强大的处理器，视频核心GPU，我们能够显着改善交互延迟到几分之一秒，使游戏方便地玩。©2020作者（S）。由爱思唯尔公司出版代表沙特国王大学这是一个开放的访问CC BY-NC-ND许可证下的文章（http://creativecommons.org/licenses/by-nc-nd/4.0/）。1. 介绍物联网（IoT）设备的采用预计将从2017年的270亿增长到2025年的730亿（Louis，2018）。物联网的快速增长和交换大量数据的大量互连设备对当前的实时数据处理和电信技术提出了新的严峻挑战取决于云后端是数据分析算法的主要主机，繁重的计算带来了主要成本，即，通信成本和在数据传输中浪费的大量能量，特别是对于功率关键型IoT设备。如果能在计算量很大的情况下，*通讯作者。电子邮件地址：maelteir@vt.edu（M.K.Elteir），slazem@srtacity.sci.eg（美国）Lazem），mazab@vt.edu，azabmm@vmi.edu（M. Azab）。沙特国王大学负责同行审查制作和主办：Elsevier在IoT板上本地完成。这些挑战迫使范式转向边缘/雾计算，从而实现家 庭 数 据 处 理 （ Satyanarayanan ， 2017; Shi 和 Dustdar ，2016;Maher，2015）。主要的问题是低成本单板计算机（SBC）或物联网板是否可以托管后感测或预致动计算密集型任务，并仍按预期运行。目前，包括Raspberry Pi设备，Neo，Udoo，PINE 64，Odroid（Hardkernel-Odroid，2019; Bolt，2019;PINE 64，2019）在内的许多IOT板然而，这些板托管的大多数应用程序主要依赖于CPU来处理所有任务，几乎没有使用附加的强大GPU（这主要回到GPU编程的复杂性以及大多数嵌入式GPU的架构设计与传统PC中常见的离散GPU之间的差异。对于没有经验的程序员来说，构建GPU可执行代码并不容易。在本文中，我们提出了一个案例研究，在低成本的物联网板Rasp- berry Pi上托管计算密集型教育游戏我们开发了一个基于计算机视觉界面的游戏，交互式垫子https://doi.org/10.1016/j.jksuci.2020.02.0011319-1578/©2020作者。由爱思唯尔公司出版代表沙特国王大学这是一篇基于CC BY-NC-ND许可证的开放获取文章（http://creativecommons.org/licenses/by-nc-nd/4.0/）。可在ScienceDirect上获得目录列表沙特国王大学学报杂志首页：www.sciencedirect.com748米K. Elteir等人 /Journal of King Saud University- Computer and Information Sciences 34（2022）747- 756（Lazem和Jad，2017），允许学生与教育Java游戏进行物理互动垫可以部署在教室和/或计算机实验室安装一个便宜的跟踪摄像头在天花板上，并使用厚纸作为游乐场垫。教育游戏包含许多组件，但计算最密集的是游戏引擎和位置跟踪组件。这两个组件都是CPU绑定的。研究表明，这是几乎不可能的板提供一个可玩的性能，而只工作在ARM处理器嵌入在板。然而，依靠主板GPU来解决争用，并处理游戏中计算最密集的组件，同一块主板可以托管游戏，并提供方便的可玩体验，因为跟踪延迟减少了5倍至几分之一秒。值得注意的是，尽管我们将Raspberry Pi作为部署游戏的目标，但我们认为，最新优化版本的游戏可移植到许多其他物联网平台，因为我们为CPU和GPU采用了平台独立的编程语言，即，Java和OpenGL-ES我们的贡献可归纳如下。首先，我们描述了一个样本教育游戏的性能，乘法事实游戏，它采用了树莓派上的交互式垫子。该表征提供了对游戏和垫接口的软件组件的计算性质的进一步理解。这种理解用于更好地利用架构性能。据我们所知，这是第一次研究RaspberryPi上基于视觉的游戏的计算需求。其次，我们提出并应用了几种优化技术来提高游戏的性能，包括设计一个更有效的软件架构，采用ARM感知优化，并利用适当的Java虚拟机。第三，我们将游戏中计算密集度最高的组件卸载到Raspberry Pi中嵌入的VideoCore GPU上，以使所提议的游戏的性能在如此有限的设备上被接受。由于我们采用了平台独立的编程语言，即，OpenGL-ES利用GPU，所学到的知识和见解仍然可以移植到具有类似架构的移动电话或低成本设备中的其他嵌入式GPU。本文的其余部分组织如下。相关工作总结-在第二节中。教育游戏的硬件和软件组件在第3节中描述。在第4节和第5节中，我们解释了我们在Raspberry Pi上表征和优化基于视觉的游戏性能的方法。第6节和第7节分别详述了实验设计和结果。第9节概述了结论和未来的工作。2. 相关工作这项工作遵循了在IOT板本身上托管计算密集型任务的新趋势，即，边缘计算（Satyanarayanan，2017），而不是依赖云后端进行远程处理。一些研究考虑了第二种趋势，并引入了一种框架，以便于将计算密集型任务卸载到功能强大的远程GPU。JCUDA（Yan等人， 2009年）是早期的框架之一，目标是在Linux系统中运行的Java应用程序。 Montella等人（2017）还提出了一个框架RAPID，该框架支持并促进将计算密集型任务卸载到远程高端CUDA 支持的GPU 。 它 支 持 Android 设 备 的 GPGPU 卸 载 和 Linux 设 备 的JavaMontella等人（2018）演示了使用RAPID GPGPU虚拟化框架进行海洋测深处理。2.1. 物联网/移动设备像Raspberry Pi这样的低成本物联网板以前用于发展中国家的教育 项 目 ， 并 受 到 萌 芽 状 态 的 限 制 （ Heeks 和 Robinson ， 2013;Cuomo等人，2013; Azman等人，2013; Ali等人， 2013年）。Raspberry Pi之所以吸引人，是因为它的低价格，高效的功耗和开放的设计。据我们所知，很少有人致力于将游戏（Chambers，2019）或OpenCV（Rosebrock，2017）等计算机视觉库移植到Raspberry Pi上。然而，对于由游戏和基于视觉的组件（即，在Raspberry Pi上的视觉游戏。Srinivasan等人（2009年）分析了手持计算平台上移动增强现实应用程序的工作负载。他们分析了应用程序主要功能组件（兴趣点检测、描述符生成器和数据库文件匹配）的工作负载和架构特征，以确定主导应用程序响应时间的热点功能。此外，他们还实现并分析了几个软件优化（例如，矢量化和多线程），以提高应用程序的性能，在执行时间上达到3倍的性能改进。Clemons和Zhu（2011）介绍了嵌入式设备上视觉算法的基准。该基准测试旨在了解移动应用中常用视觉算法的微架构性能（例如，面部检测和对象跟踪）。他们分析了算法的单线程和多线程实现的性能提出了性能改进和指导架构决策的见解Gutierrez和Dreslinski（2011）描述了多种智能手机应用程序（ 包 括 音 频 、 视 频 和 交 互 式 游 戏 ） 的 微 架 构 行 为 他 们 推 出 了BBench，这是浏览器性能评估的基准分析表明，最先进的CPU基准测试和移动交互式应用程序之间存在显着差异。交互式智能手机应用程序的指令缓存、转换后备缓冲区未命中统计和分支误预测率更差。结果归因于大量使用共享库和操作系统服务。Lee等人（2012）为运行AndriodOS的移动设备引入了多媒体基准测试。该基准测试包括六个应用程序，涵盖了四个基本的多媒体功能（播放，压缩，计算和渲染）。两个平板电脑和两个智能手机进行了评估，使用拟议的基准。Fernández等人（2012）描述了不同手机的协作增强现实标记跟踪性能，以确定进一步改进的耗时应用阶段。分析表明，标记跟踪和图像采集分别是最耗时的阶段。2.2. 利用GPU实现计算机视觉加速研究界做出了很大的努力来使用图形处理单元加速计算密集型计算机视觉功能。这些早期的努力之一是GPUCV（Allusse等人，2008年发布的一个库，使用OpenGL和CUDA加速OpenCV中的几个模块。 OpenCV库本身提供了一些使用通用编程模型的加速函数，即，OpenCL（OpenCL，2019）和CUDA（CUDA，2019）。其他 复 杂 的 深 度 学 习 框 架 ， 如 Caffee （ Jia et al. ， 2014 ） 和TensorFlow（Abadi et al.，××M. K. Elteir等人/Journal of King Saud University- Computer and Information Sciences 34（2022）747-7567492016）通过支持OpenCL和CUDA提供对GPU设备上运行的支持嵌入式/物联网设备上的计算机视觉也在发展（Bordallo López等人，2011; Nitsche和De Cristóforis，2012;Cavus等人，2014; Lee等人， 2016年），支持通用编程模型的嵌入式GPU。然而，据我们所知，没有像Raspberry Pi 这样的嵌入式设备的通用解决方案（Brahmbhatt，2013）。因此，我们提出了自己的解决方案，以便使用唯一支持的面向图形的编程接口，即，OpenGL-es2.0.我们的解决方案使用并扩展了开源C++ API，该API使用RaspberryPi的GPU加速了一些图像处理功能3. 教育游戏这个游戏的目的是帮助低年级学生记忆乘法表.学生和游戏之间的互动是通过互动垫进行的。它是一种低成本的物理交互技术，整个身体用于为Lazem（2019）首次引入的计算机应用程序提供输入。图1描绘了交互式垫子的硬件组件的示意图。该技术包括计算机（例如，Raspberry Pi在我们的实验中）运行游戏，一个地板垫和一个便宜的网络摄像头。地垫代表游戏场地或输入物理空间。它的结构是一个低成本厚纸的九块网格（3 3）。摄像机安装在天花板上，地板垫封闭在摄像机的视野内学生在垫子上的位置由摄像机跟踪并映射到九个块中的一个玩过的游戏被投影在学生面前的墙上。游戏从登录屏幕开始，学生输入她的用户名和密码。成功登录后，游戏屏幕出现在学生面前，如图2所示。屏幕上出现一个问题，该问题有九个可能的答案，对应于交互式垫子的九个块。当学生站在某个块上后，位置跟踪组件将块号发送到游戏。学生所在的区块中的字体变为红色，并出现一个进度条，指示提交答案之前的剩余时间。我们使用6秒作为超时值。如果学生在超时之前更改了块，超时计算将重新开始，进度条将显示新的剩余时间值。在提交图二. 从乘法事实游戏的快照。答案，一个视觉反馈，Tarazan字符动画从屏幕的左边到右边，出现在学生显示她的答案是正确还是错误。屏幕上有几个动画动物和水果，它们以预定义的模式移动.图3示出了所设计的教育游戏的软件架构。位置跟踪组件使用Java包装器开源计算机视觉库（OpenCV）（OpenCV，2019）的一部分，以跟踪学生在垫子上的位置。位置信息用于确定学生站立的块。区块号被发送到Java游戏服务器。游戏连接到数据库服务器，以存储学生的信息、游戏问题和学生的游戏记录，以供教师进一步分析。在我们的实现中，这两个组件驻留在同一台机器上。位置跟踪组件由一个无限循环组成，该无限循环从安装在天花板上的网络摄像头捕获视频帧。摄像头分辨率为640 480像素。每个帧都从蓝-绿-红颜色空间转换为灰度。第一帧是参考帧，通常在任何学生踏上交互式垫子之前捕获。后续帧的处理如下。计算当前捕获的帧和参考帧之间的差。使用模糊函数对差帧进行平滑。阈函数用于分割平滑的差帧。 计算分割图像中所得到的斑点的矩。面积和一阶矩用于计算斑点的重心，并相应地计算学生站立的块数。区块编号依次发送到游戏。图1.一、交互式垫子的示意图：运行游戏的计算机连接到一个商品摄像头，用于位置跟踪和数据显示，以将游戏投影到墙上。该图复制自Lazem（2019）。海拔750米K. Elteir等人 /Journal of King Saud University- Computer and Information Sciences 34（2022）747- 756图3.第三章。基于Java教育视觉的游戏的初始软件架构4. 方法本节描述了在移植后用于表征和优化游戏性能的方法。4.1. 应用程序分析最初将带有位置跟踪功能的游戏移植到Raspberry Pi的过程表明，与PC上的性能相比，游戏在游戏启动时间、游戏对用户输入的响应以及动画的流畅度方面存在严重的性能下降。如表1所示，出现第一个屏幕需要24.8秒，以便在屏幕上反映新的位置（交互延迟）。这些漏洞使得最初的移植游戏无法运行。为了确定主要的瓶颈，我们仔细分析了游戏不同组件的性能，使用系统指标和用户体验指标。第7节中的所有实验。我们的初步结果表明，位置跟踪组件需要198.296毫秒来检测球员在垫子上的位置。这个延迟明显小于玩游戏时经历的延迟，即4，815ms。我们将延迟增加归因于游戏的不同组件之间的竞争，即，游戏服务器、数据库服务器和跟踪组件都在Raspberry Pi的有限资源在下面 的小节中， 我们将重新 审视游戏的 软件架构， 以应对Raspberry Pi的功能4.2. 重新审视软件架构虽然Java编程语言是PC游戏开发的好选择，但对于Raspberry Pi这样的除了使用Java的开销之外，如图3所示的位置跟踪模块的JavaCV的使用引入了额外的开销。JavaCV使用JavaCPP作为在运行时访问本机OpenCV库的包装器，导致在执行任何OpenCV组件时产生额外的延迟。我们建议直接使用C代码，即，OpenCV而不是JavaCV的位置跟踪模块，并将其移动到一个单独的进程，该进程使用套接字编程与Java游戏通信，如果表1带有位置跟踪的初始Java游戏的性能。启动时间交互延迟每秒渲染帧数（FPS）24，794 ms 4，815ms 34图四、重新审视基于视觉的Java游戏的软件架构位置跟踪模块使用OpenCV而不是JavaCV实现，JavaCV使用套接字/管道进程间通信机制与游戏通信。如图4所示，在不同的机器上部署了两个组件。在我们的实现中，我们将所有组件部署在同一台机器上，因此我们使用管道而不是套接字来进行跟踪组件和Java游戏之间的进程内通信，因为管道是一种更有效的通信机制，可以避免通过网络堆栈的所有层虽然使用OpenCV与相应的JavaCV代码相比，跟踪模块的独立性能提高了7.9%，如第7.2节所述，但游戏的不同组件之间对ARM处理器有限幸运的是，Raspberry Pi配备了强大的嵌入式GPU，VideoCoreGPU，因此我们建议将跟踪模块计算卸载到该GPU，如图5所示。这可以减少跟踪组件和所有其他游戏组件之间的争用，从而提高游戏的响应性，如第7.3节所示。在第5节中讨论了对GPU进行封装的细节。除了优化跟踪模块，在下一节中，我们将讨论为进一步提高C和Java代码的性能而采用的优化。图五.重新审视基于视觉的Java游戏的软件架构，使用OpenGL-ES着色将位置跟踪模块卸载到VideoCore GPU语言四分之一;;;M. K. Elteir等人/Journal of King Saud University- Computer and Information Sciences 34（2022）747-7567515. 使用VideoCore GPU5.1. GPU架构嵌 入 Raspberry Pi （ Broadcom ， 2019 ） 中 的 VideoCore IVGPU是一款功能强大的嵌入式GPU，包含16个称为四处理器单元（QPU）的特殊浮点着色处理器实例这些QPU被组织成四个切片的组，其共享公共资源，诸如指令高速缓存、特殊功能单元（SFU）以及一个或多个纹理和存储器查找单元。每个纹理单元都有一个小的L1缓存，所有纹理单元之间共享一个每一个QPU是一个4路SIMD处理器复用到16路，使其适合于处理四倍像素它有两个向量浮点ALU，每个周期执行一次加法和乘法，并对32位数据（或4位向量）进行操作被配置为将其输出写入纹理存储器而不是帧缓冲存储器，这是一种称为渲染到纹理的技术，以避免GPU和主机处理器之间昂贵的通信因此，初始和当前视频帧的数据作为纹理缓冲区传输到GPU一次，并且在一系列片段着色器内核调用结束时，结果被传输回CPU。通过正确选择数据类型和矢量化，可以直接实现前四个模块的片段着色器内核，如图6所示。我们的实验表明，使用单精度浮点数据类型是足够的准确跟踪站在网格中的位置。第五个模块，计算原始图像矩，是最复杂的一个，需要明智的决定，以有效地卸载到嵌入式GPU。该模块旨在计算M00、M01和M10，其中Mij使用以下公式计算：8位数据）。该GPU的关键特性之一是支持基于平铺的Mij ¼XXxi×yj×Ix;y1Xy像素渲染而不是即时模式渲染，降低了帧缓冲器带宽要求。标准瓦片缓冲区大小为64× 64个样本。5.2. 将跟踪模块映射到GPU图6示出了如何将位置跟踪模块卸载到GPU。相机输出帧最初存储在纹理存储器中作为2D纹理缓冲区。跟踪计算被实现为由QPU执行的片段着色器内核每个内核使用一个或两个2D纹理缓冲区作为输入，并仅写入一个vec4输出，即，gl_FragColor。如第3节所述，跟踪计算涉及五个模块。我们已经实现了每个模块作为片段着色器。图像模糊的片段着色器是从Cummings（2013）移植的。这些着色器按顺序运行。每个着色器其中x，y是像素坐标，I（x，y）是像素的强度。我们不是让三个片段着色器内核计算每个时刻的分量，而是只实现一个内核，称为时刻分量内核，它计算三个时刻的分量，并将每个分量写入vec4 gl_FragColor输出中的通道，如等式2所示。（二）、gl FragColorEC 4强度 gl FragCoord： xgl FragCoord： y1纹理宽度纹理高度ð2Þgl_FragCoord.x和gl_FragCoord.y坐标必须分别除以纹理宽度和纹理高度，以避免在累积这些值以计算矩时出现任何溢出。为了计算矩，必须沿x和y方向减少矩分量核见图6。 位置跟踪模块到VideoCore GPU的映射示意图。ðÞ半- ]×¼× × × × × × ×××××××× ××××ðÞ×ðÞðÞΣ5752米K. Elteir等人 /Journal of King Saud University- Computer and Information Sciences 34（2022）747- 756如Eq. （一）.我们已经研究了两种技术来执行这种并行还原。第一种是执行logb nreduce内核的传统方法，其中b表示每个线程减少的值的数量即，块大小n表示要减少的元素的总数。我们的实验表明，最大可能的块大小是54. 使 用 较 大 的 大 小 时 ， 片 段 着 色 器 无 法 执 行 并 产 生GL_OUT_OF_MEMORY错误。我们将其与纹理存储器查找操作允许的数量的约束联系起来可以在片段着色器中使用。我们选择了b1/4来达到平衡使用范围0中的整数纹理元素索引;纹理维度1。唯一支持的纹理元素提取函数是纹理2D，它使用范围[0，1]内的规范化浮点纹理坐标。我们已经生成了下面的方程，以获得归一化的纹理坐标;其中i是要检索的纹理的索引。在水平缩小的情况下，x是x坐标，而在垂直缩小的情况下，y是y坐标。Chunk Size表示每个线程要减少的值的数量GL FragCoord：x×块大小之间的水平的并行性和的number内核发射这种方法的主要缺点是，它遭受了启动几个内核的开销（10个内核用于4： 0浮式升降机0： 5×2： 0纹理宽度512 512纹理）并发出大量纹理存储器读和写。yglFragCoord：y×Chunk Size块大小浮动块大小0： 5块纹理高度ð6Þ另 一 种 并 行 缩 减 技 术 取 决 于 mipmap （ Munshi 等 人 ， 2008年）。Mipmap是预先计算的图像序列，每个图像的分辨率都低于前一个图像。mipmap中特定级别的每个图像的高度和宽度比前一级别小2的幂。例如，大小为512 512的纹理具有以下维度的9个图像的mipmap：256 256; 128一百二十八、六十四六十四、三十二三十二;十六16; 88; 44; 22和11。为了应用这种技术，通过适当设置GL纹理最小过滤器和GL纹理MAG过滤器，创建由矩组件内核生成的输出纹理MC纹理参数如下：glTexParameter f第二代纹理关键的设计决策之一是保存相机帧的纹理缓冲区的大小我们测试了三种可能的尺寸：1024 1024; 512 512和256 256。我们的实验表明，在性能，检测精度和支持的网格尺寸方面，是512512.1024 1024显着增加内核执行时间，而256 256不支持足够的检测精度。正确选择视口的尺寸对于实现的正确性至关重要。我们发现，使用一个尺寸等于输入纹理尺寸的视口会导致每次内核启动后渲染输出的大小以2的幂要生成正确的渲染输出，视口尺寸必须等于GL纹理滤波器线性MIPMAP最近点;glTexParameter f第二代纹理GL纹理MAG过滤器;GL floatð3Þð4Þ输入纹理的尺寸。6. 实验设计我们做了三个实验。实验一研究的Java游戏服务器的性能单独没有互动的跟踪模块。实验二研究的性能的位置跟踪模块单独没有互动的Java游戏。实验三研究了整个博弈和然后，在执行矩组件内核之后，生成MC纹理，通过调用OpenGL ES 2.0支持的glGenerateMipmap GLTEXTURE2D没有直接的方法从片段着色器读取生成的mipmap，因为VideoCore GPU的OpenGL ES 2.0实现不支持Texture2DLod扩展。因此，在生成mipmap之后，我们启动了另一个内核，的数据的的MC纹理并将其写回帧缓冲区。若要强制片段着色器使用特定的mipmap级别，必须适当调整视口。在Chisu（2005）中，Chisu表明累积舍入误差随着mipmap中的每个级别线性增加。我们的实验表明，64 64mipmap级别提供了适当的精度，因此该级别的数据被传输回CPU，CPU完成该级别的缩减6464纹理。与其他技术相比，这种技术只需要启动一个简单的内核。它唯一的缺点是需要CPU干预来降低64 64 mipmap级别。第7.2节更详细地讨论了这两种方法的有效性5.3. 实施决策实现第一种缩减技术的挑战之一是精确计算指定的特素的坐标OpenGL ES 2.0不支持在片段着色器中使用texelfetch函数，该函数使着色器能够访问纹素不同成分之间的交互作用对游戏成绩的影响。本节介绍机器配置和6.1. 机配置实验使用Raspberry Pi Model B+进行，硬件规格如下：ChipBroadcom BCM 2835 SoC全高清多媒体应用处理器、CPU 700MHz低功耗ARM 1176 JZF-S应用处理器、512MB RAM、4个USB2.0端口和一个以太网端口。此外，该芯片还具有VideoCore IV®多媒体协处理器。它被配置为使用128 MB的芯片内存。虽然Raspberry Pi有最新的型号，即Raspberry Pi 3 Model B和B+，但我们有兴趣解决如何有效地将目标教育娱乐应用程序部署到资源有限的低成本板上的挑战，如Raspberry Pi Model 1。成功地将目标应用程序移植到Raspberry Pi的这个模型意味着能够在游戏级别或视觉组件级别将更多复杂的应用程序部署到最新的模型。所有Raspberry Pi型号都具有相同的Videocore GPU，仅支持OpenGL ES 2.0。我们使用金士顿32 GB microSDHC存储卡，并安装Debian WheezyRaspbian操作系统，内核版本3.12.28+和gcc版本4.8.3。软件架构的三个组件（图4）; Java游戏服务器、位置跟踪组件和数据库服务器驻留在同一个Raspberry Pi上。OpenCV版本2.4.9用于跟踪x¼。M. K. Elteir等人/Journal of King Saud University- Computer and Information Sciences 34（2022）747-756753成分对于数据库服务器，我们安装了一个开源数据库（MySQL）（MySQL，2019）。6.2. 用户体验度量我们测量两个指标作为玩游戏的学生的用户体验的指标每秒帧数（fps）是每秒渲染的帧数，作为系统吞吐量的度量。延迟是学生与游戏软件/硬件交互和游戏响应之间的延迟所提出 的系统中 的延迟具有 以下组成 部分。启动延 迟是在Raspberry Pi上启动应用程序和出现游戏登录屏幕之间的时间登录延迟是指从提交登录信息到游戏屏幕出现跟踪延迟是学生站在交互式垫子块上与块号发送到Java游戏之间的网络延迟是发送和接收块号之间的时间游戏延迟是指站在积木上提交答案与首次出现视觉反馈或移动的塔拉赞角色之间的时间交互延迟是跟踪延迟、网络延迟、超时值和游戏延迟值的总和。为了测量跟踪延迟，我们使用Java中支持的currentTimeMillis（）函数。为了准确测量交互延迟，我们测量挂钟从站在一块积木上到答案出现的时间，至少运行10次，然后取平均值。6.3. 系统性能度量为了监控Java游戏的不同组件的性能，即，游戏服务器，数据库，位置跟踪，我们都使用了pidstat工具。它报告这些不同进程的系统统计信息。我们收集反映系统的不同资源的利用的统计数据，即，CPU（利用率百分比）、内存（消耗百分比）和I/O。我们只在第7节中报告最有趣的统计数据。一旦应用程序启动，我们就运行一个监控脚本，该脚本将启动几个pidstat命令，这些命令的数量等于要监控的进程的数量。为了准确地确定用于渲染游戏和操作数据库的资源，我们分别收集了Xorg和MySQL进程的统计数据。7. 实验结果7.1. 实验I该实验主要旨在表征通过键盘而不是交互式垫输入玩家位置的单机游戏服务器的性能。这个版本的游戏作为一个基础版本，以评估在基于跟踪器的游戏版本中发生的竞争。本实验的目的也是研究的Java游戏组件提出的优化效果。7.1.1. 一款性能刻画的键盘版Java游戏表2显示了游戏初始版本在用户体验方面的表现游戏延迟和渲染FPS在可接受的范围内，但启动时间很长，即，超过20 s。如图7所示，在游戏的所有阶段，包括启动阶段和游戏运行阶段，所有组件的CPU利用率为86.5%。CPU资源消耗最多表2键盘版游戏初始版本的用户体验指标启动时间游戏延迟每秒渲染帧数（FPS）20，709.40毫秒382毫秒43见图7。Java游戏的不同组件的资源消耗：CPU和内存。在Java游戏中，79.2%，部分来自Xorg服务，即，百分之七所有模块的内存消耗平均为24.53%;考虑到Raspberry Pi的内存为512 MB，这是一个很小的占用空间。Java游戏是消耗大部分内存的模块。为了进一步了解内存的行为，我们监控了每秒的故障数。如图8所示，大多数故障发生在Java游戏组件启动时7.1.2. 优化Java游戏启动时间游戏的主要瓶颈在于启动阶段，因此我们着重提高了Java游戏启动时的性能。在启动期间，用户界面的所有图像都从磁盘加载到内存。我们采用了两种技术：压缩用户界面的图像和去除发散分支。我们制作了这个游戏的四个版本Original表示没有优化的版本，Comp是 具 有 压 缩 的 版 本 ， NoBrnch 是 去 除 了 发 散 分 支 的 版 本 ，CompNoBrnch表示具有两个优化的游戏版本 如图9.第九条。结合两种 优 化 导 致 启 动 时 间 从 20709.4 ms 减 少 到 15003.7 ms ， 即 ，27.55%，游戏延迟也从382 ms减少到340 ms。7.2. 实验II本实验旨在表征位置跟踪模块的Java版本的性能，并研究所提出的优化的效果。见图8。 Java游戏的不同组件的内存故障（faults/s）。754米K. Elteir等人 /Journal of King Saud University- Computer and Information Sciences 34（2022）747- 756图9.第九条。Java游戏启动时间使用不同优化版本的游戏。表3位置跟踪模块的用户体验和系统指标63.99%的CPU和46.04%的内存具有相对较高的故障数/秒，即，二百八十一点七三对于用户体验指标，FPS为5.043，表示每秒从相机捕获并由跟踪模块处理的帧数跟踪延迟为198.296 ms。虽然根据我们之前在第6.2节中的讨论，可以接受此延迟，但跟踪器的高CPU利用率表明，当它与Java游戏并发运行时，Raspberry Pi的有限CPU资源将出现争用，如第7.3节所示。7.2.2. 优化位置跟踪模块的性能首先，我们研究使用OpenCV而不是JavaCV的有效性然后，我们研究了采用ARM感知编译器和基于ARM的编译标志的效果由于跟踪模块是在OpenCV库上构建的，因此必须使用不同的编译器将模块与OpenCV库一起编译跟踪延迟FPS利用CPU消费内存消耗故障/秒还有旗帜我们生成了四个版本：198.29ms 5.043 63.99% 46.04% 281.73见图10。使用不同的编译器和优化标志的位置跟踪延迟。7.2.1.如表3所示，所收集的系统统计信息表明位置跟踪模块是计算密集型的。它消耗1. 使用通用编译器生成的参考版本，即，枪GCC编译器和无优化标志，即，海合会。2. 使用基于ARM的编译器生成的版本，没有优化标志，即，armcc。3. 使用通用编译器和优化标志生成的版本，即，gcc-opt.4. 使用基于ARM的编译器和优化标志生成的版本，即，armcc-opt.值得注意的是，我们在Raspberry Pi上编译了OpenCV库。我们使用cmake-gui工具，这是一个有效且简单的工具来操作OpenCV编译标志。然后编译位置跟踪模块，并将其统计链接到OpenCV库的不同编译版本我们在网格上运行每个版本三分钟的连续移动，并收集用户体验统计数据和系统统计数据。如图10所示，在位置跟踪延迟方面，ARM感知编译器的性能当强制使用基于ARM的编译标志时，两个编译器的性能几乎相同，即，比参考版本好12%。最佳版本将跟踪延迟从198.29 ms降低到168.71 ms。跟踪模块处理的帧数略有提高，达到6fps。见图11。 不同位置跟踪器的总执行时间（含时间细分）。××M. K. Elteir等人/Journal of King Saud University- Computer and Information Sciences 34（2022）747-756755在资源消耗方面，上述优化将CPU利用率降低到43.33%，并将内存消耗大幅为了避免与Java游戏争用，进一步降低CPU利用率的唯一解决方案是将计算卸载到嵌入式GPU，如第4节所述。图11显示了第4节中讨论的两个版本的GPU跟踪器的性能。这两个版本之间的唯一区别是在计算的时刻。第一个版本需要253.08 ms跟踪位置，比Java版本长30.2%其中67%的时间花在最后的缩减上，以计算力矩。这主要返回到启动和运行多个内核的开销，即，10个减少内核，以减少沿x和y维度的矩分量纹理。虽然这个版本的延迟比JavaCV版本更长，但它成功地将CPU利用率显著降低到7.66%。采用mipmap-ping技术的GPU跟踪器的第二个版本仅需94.07 ms，比JavaCV跟踪器少两倍。在CPU利用率方面，此版本消耗的CPU略多，即，8.5%相比，以前的版本-sion，因为CPU是负责减少8 8由GPU产生的mipmap图像。这两个GPU版本采用Picam而不是网络摄像头来捕获视频帧。这显著地将捕获时间从53.3 ms减少到5.08 ms，即10.53倍的加速，如图所示。 十一岁7.3. 实验III本实验的目的是在集成位置跟踪模块后表征游戏的性能，并研究所提出的优化的效果。7.3.1. 如图12所示，Java游戏与位置跟踪模块的集成导致可用于游戏的不同组件的CPU资源减少游戏和跟踪器的CPU利用率分别从79.2%下降到27.18%和从63.99%下降到29.66%游戏服务器和位置跟踪模块之间对ARMv6处理器的有限处理能力的竞争导致游戏的跟踪延迟显著增加超过22倍，即，从198.296 ms到4，815 ms，如表4所示。在内存消耗方面，由于游戏的所有组件的内存占用都很小，因此集成并不显著影响每个组件使用的内存。见图12。在与跟踪组件集成后，Java游戏的不同组件的资源利用率。表4独立和集成位置跟踪器的延迟（毫秒）。独立综合利用管道集成使用插座JavaCV198.29NA4,815OpenCV168.718,7124,186GPU253.082,3401,182GPU-Mipmap94.071,590972.37.3.2. 优化基于跟踪器的Java游戏为了研究所提出的优化对基于跟踪器的游戏的影响，我们运行了三个版本的游戏;每个版本都集成了上一节中讨论的一个跟踪器我们量化了集成所有组件对用户体验的影响。如表4所示，集成显著影响三个优化版本的跟踪延迟。对于OpenCV版本，集成还将跟踪延迟增加了22倍以上，因此使其达到4，186 ms，这对于交互式游戏来说仍然很长。对于游戏的GPU版本，通过将计算密集型跟踪器卸载到GPU来大大避免争用。因此，积分后的跟踪延迟增加了4.58倍，基本GPU版本和mipmap版本分别为10.34倍。延迟在mip映射版本中增加了更大的系数，因为主机CPU仍然参与8 8 mip映射图像的最终还原，因此与基本GPU版本相比增加了争用。一个有趣的观察是，尽管基本GPU版本的独立跟踪延迟大于JavaCV和OpenCV，如图11所示，但在集成后，该版本的延迟平均显著降低3.81倍，因此达到1，182 ms，如表4所示。集成后的最小延迟仍然是由游戏的mipmap版本完成的它需要几分之一秒的时间来检测玩家972.3ms，使游戏可以在这个低成本的设备上玩。我们研究了两种将跟踪器与游戏集成的机制：第4节中讨论的套接字和管道。虽然我们期望管道比套接字实现更好的性能，因为它避免了通过整个网络堆栈，但我