CN114565503B

CN114565503B - Gpu指令数据管理的方法、装置、设备及存储介质

Info

Publication number: CN114565503B
Application number: CN202210476992.XA
Authority: CN
Inventors: 不公告发明人
Original assignee: Muxi Technology Beijing Co ltd
Current assignee: Muxi Technology Beijing Co ltd
Priority date: 2022-05-03
Filing date: 2022-05-03
Publication date: 2022-07-12
Anticipated expiration: 2042-05-03
Also published as: CN114565503A

Abstract

本公开提供了一种GPU指令数据管理的方法、装置、设备及存储介质，属于计算技术领域，能够提高GPU指令的执行效率。具体地，将指令存储、指令读写和指令执行做并行化处理。在Host侧写入指令的同时，芯片就可以启动指令的读取，并存储到本地，然后并行做指令的执行，提高了指令执行效率。同时，当执行完部分指令后，Local会主动发起指针回写，通知Host当前指令执行的情况和位置。从而方便Host侧判断，继续向Host buffer写入或停止写入新的指令，简化了Host侧的操作复杂度，进一步提高了指令执行效率。

Description

GPU指令数据管理的方法、装置、设备及存储介质

技术领域

本公开涉及计算技术领域，具体地涉及用于GPU指令数据管理的方法、装置、设备及存储介质。

背景技术

随着计算需求越来越高，GPU已成为算力基础设施重要的组成部分。GPU芯片可以根据用户的指令做各种操作，例如写数据、数据复制、数据填充等等。因此，指令的存储、读写、执行效率，对芯片性能有着重要的影响，

现有的GPU指令管理系统一般是将指令存储、指令读写和指令执行严格分开。先在Host侧做指令存储，将一个完整的指令存储完成后，再通知Local进行指令读写。一方面，各个单元串行操作，每次指令都是先存储完成、才能做指令读取，最后做指令执行。同时每一步之间存在延时，会导致指令执行时间长，效率低；另一方面，Host需要做的操作比较复杂，除了正常的写入指令，还需要去判断指令是否被读走、是否被执行完成，以上这些判断，增加Host的操作复杂度。

发明内容

本公开的目的在于，针对现有技术中存在的问题，提供一种GPU指令数据管理的方法、装置、设备及存储介质，提高指令执行效率。

根据本公开的一个方面，提出一种GPU指令数据管理方法，

响应于Host buffer写入指令数据，根据写入的指令数据长度更新Host侧HWPTR，并将更新后的HWPTR写入Local侧，

其中所述Host buffer用于缓存写入Host侧的指令数据，所述HWPTR表示当前指令数据写入所述Host buffer的位置的指针，

响应于Local侧中的HWPTR和HRPTR不相等，从所述Host侧读指令数据写入到Localbuffer，根据读取的指令数据长度更新Local侧HRPTR，并将更新后的HRPTR写入Host侧，

其中所述Local buffer用于缓存写入Local侧的指令数据，所述HRPTR表示被读取的指令数据在Host buffer中的位置的指针，

响应于Host侧中的HWPTR和HRPTR不相等，根据Host buffer的空余缓存深度写入新的指令，其中所述空余缓存深度为HWPTR和HRPTR的差值。

在一些实施例中，所述Host buffer为环形buffer。

在一些实施例中，当所述HWPTR和HRPTR的差值小于一定阈值时，表示Host buffer已满，停止写入操作。

在一些实施例中，其中所述Local buffer由两个大小相同的Lbuffer组成，用于并行从Host侧读指令数据和将读取的指令数据发送至指令数据执行侧。

在一些实施例中，响应于所述Local buffer写入指令数据，根据写入的指令数据长度更新Local侧LWPTR，

响应于Local buffer非空，读取Local buffer中指令数据到所述指令数据执行侧，根据所述读取Local buffer中指令数据的长度更新LRPTR，

其中LWPTR表示写入所述Local buffer的位置的指针，其中LRPTR表示所述读取Local buffer中指令数据的位置的指针，

响应于收到指令数据执行完成标识，从Local buffer读取新的指令数据到所述指令数据执行侧。

在一些实施例中，所述两个大小相同的Lbuffer做乒乓操作。

在一些实施例中，所述指令数据执行侧收到指令数据后，解析出指令的类型、长度、原始数据、读写地址信息，根据指令信执行数据搬运、数据加减、数据填充操作，判断指令执行状态，执行完毕后，返回完成标识。

根据本公开的另一个方面，提出一种GPU指令数据管理的装置，包括，

第一更新单元，用于响应于Host buffer写入指令数据，根据写入的指令数据长度更新Host侧HWPTR，并将更新后的HWPTR写入Local侧，

第一读取单元，用于响应于Local侧中的HWPTR和HRPTR不相等，从所述Host侧读指令数据写入到Local buffer，根据读取的指令数据长度更新Local侧HRPTR，并将更新后的HRPTR写入Host侧，

第一写入单元，用于响应于Host侧中的HWPTR和HRPTR不相等，根据Host buffer的空余缓存深度写入新的指令，其中所述空余缓存深度为HWPTR和HRPTR的差值。

在一些实施例中，该装置还包括，第二更新单元，用于响应于所述Local buffer写入指令数据，根据写入的指令数据长度更新Local侧LWPTR，

第三更新单元，用于响应于Local buffer非空，读取Local buffer中指令数据到所述指令数据执行侧，根据所述读取Local buffer中指令数据的长度更新LRPTR，

第二读取单元，用于响应于收到指令数据执行完成标识，从Local buffer读取新的指令数据到所述指令数据执行侧。

根据本公开的另一个方面，提出一种电子设备，包括存储器、处理器及存储在所述存储器上并可在所述处理器上运行的计算机程序，其特征在于，

所述处理器执行所述计算机程序时实现上述方法的步骤。

根据本公开的再一个方面，提出一种用以存储处理器可执行指令数据的计算机可读存储介质，所述计算机可读存储介质中存储的处理器可执行指令数据在被执行时能够致使处理器实施如上所述GPU指令数据管理方法。

本公开提供了一种GPU指令数据管理的方法、装置、设备及存储介质，能够提高GPU指令的执行效率。具体地，将指令存储、指令读写和指令执行做并行化处理。在Host侧写入指令的同时，芯片就可以启动指令的读取，并存储到本地，然后并行做指令的执行，提高了指令执行效率。同时，当执行完部分指令后，Local会主动发起指针回写，通知Host当前指令执行的情况和位置。从而方便Host侧判断，继续向Host buffer写入或停止写入新的指令，简化了Host侧的操作复杂度，进一步提高了指令执行效率。

附图说明

下面结合附图，通过对本公开的具体实施方式详细描述，将使本公开的技术方案及其它有益效果显而易见。

图1为本公开实施例提供的GPU指令数据管理方法流程示意图。

图2为本公开实施例提供的GPU指令管理的系统结构示意图。

图3为本公开实施例提供的环形buffer结构示意图。

图4为本公开实施例提供的在Local侧指令管理流程示意图。

图5为本公开实施例提供的在执行侧指令执行流程示意图。

图6为本公开实施例提供的GPU指令数据管理装置示意图。

图7为本公开实施例提供的电子设备结构示意图。

具体实施方式

下面将结合附图，对本公开实施例中的技术方案进行清楚、完整地描述。本公开的说明书和权利要求书以及附图中的术语“第一”、“第二”、“第三”等（如果存在）是用于区别类似的对象，而不必用于描述特定的顺序或先后次序。应当理解，这样描述的对象在适当情况下可以互换。此外，术语“包括”和“具有”以及它们的任何变形，意图在于覆盖不排它的包含。在本公开的描述中，“多个”的含义是两个或两个以上，除非另有明确具体的限定。对于本领域的普通技术人员而言，可以根据具体情况理解上述术语在本公开中的具体含义。

实施例一：

具体地，请参阅图1，为本公开提供的一种GPU指令数据管理方法。具体步骤如下：

S1响应于Host buffer写入指令数据，根据写入的指令数据长度更新Host侧HWPTR，并将更新后的HWPTR写入Local侧。

其中所述Host buffer用于缓存写入Host侧的指令数据，所述HWPTR表示当前指令数据写入所述Host buffer的位置的指针。

在一个或多个实施例中，如图2所示GPU指令管理的系统结构，首先，用户把指令写入Host buffer中。指令的长度L可以为定长或者变长，不受限制。最新的指令会被写到Hostbuffer下一个地址。在一个实施例中，如图3所示，Host buffer可以是一个环形的buffer，深度大小为M byte,地址范围为0~M-1 Byte。当指令写到buffer最后一个地址M-1后，会重新从0开始。其次，Host buffer里存有写指针write pointer(简称HWPTR)和读指针readpointer(简称HRPTR)。HWPTR用于指示当前指令写入的地址，范围为0~M-1 Byte。HWPTR由Host来维护。Host根据用户每次写入的指令长度更新buffer的HWPTR。HRPTR用于指示已经被读走指令的地址，范围为0~M-1 Byte。HRPTR由Local来维护。Local根据每次读走的指令长度更新buffer的HRPTR。

初始化时，在Host侧的HWPTR和HRPTR均为0，表明Host buffer中指令已经读空，可以写入；Host会主动将更新后的HWPTR写到Local侧，通知Local buffer新的指令写入的位置。

S2响应于Local侧中的HWPTR和HRPTR不相等，从所述Host侧读指令数据写入到Local buffer，根据读取的指令数据长度更新Local侧HRPTR，并将更新后的HRPTR写入Host侧，其中所述Local buffer用于缓存写入Local侧的指令数据，所述HRPTR表示被读取的指令数据在Host buffer中的位置的指针。

在一个或多个实施例中，在Local侧有一套相同的写指针write pointer(简称HWPTR)和读指针read pointer(简称HRPTR)。写指针HWPTR由Host维护，读指针HRPTR由Local侧维护。当Local侧判断HWPTR和HRptr不相等时，表明有新的指令写入到Host buffer中。此时，Local侧会发起读指令操作。把Host buffer的指令按顺序读走，写入Localbuffer。

S3响应于Host侧中的HWPTR和HRPTR不相等，根据Host buffer的空余缓存深度写入新的指令，其中所述空余缓存深度为HWPTR和HRPTR的差值。

在一个或多个实施例中， Host侧会实时比较HWPTR和HRPTR。当两者不等时，表明已经有指令被读走，当前Host buffer有空余缓存。空余缓存深度为HWPTR和HRPTR的差值。用户会根据空余缓存的深度，把新的指令写入Host buffer。

在一个或多个实施例中，为了区分写满和读空并且保护buffer不被写溢出，当HWPTR和HRPTR差值为Gap时，表明Host buffer已经写满，用户停止写操作。Gap可以灵活设置，最小为1B。

在一个或多个实施例中，如图4所示在Local侧的指令管理流程示意图，Localbuffer由2个大小相同的Lbuffer组成，每个Lbuffer的深度固定为N。两个Lbuffer可以做乒乓操作，用于并行从Host侧读指令和发送指令给执行侧。为了提高效率，每次从Host侧读固定长度N的指令。如果N超出Host buffer中存储的指令长度L，则写入Local buffer的有效长度为L。每个Lbuffer都有独立的写指针write pointer(简称LWPTR)和读指针readpointer(简称LRPTR)。LWPTR用于指示当前指令写入的地址，范围为0~N-1 Byte。根据每次写入的指令长度更新Local buffer的LWPTR。LRPTR用于指示已经被读走指令的地址，范围为0~N-1 Byte。根据每次读走的指令长度更新Lbuffer的LRPTR。每写入一段指令，Localbuffer就会更新对应的LWPTR[0]或者LWPTR[1]。当LWPTR未达到N时，表明Lbuffer还有空余缓存，会不停的发起读操作，直到LWPTR达到N。当任意1个Lbuffer非空时，表明已经有指令写入到Local buffer中。此时，Local buffer侧会主动把指令送到指令执行侧。每次发送的指令长度为E。Local buffer根据指令执行侧返回的完成标志，会更新对应的LRPTR和HRPTR。并取出新的指令发送给指令执行侧。当某个Lbuffer的LRPTR达到N时，表明该Lbuffer中的指令已经全部读完，切换到另外一个Lbuffer。如果两个Lbuffer都已经达到N时，表明所有Lbuffer的指令都已经读完，停止发送。同时，Local侧会主动将更新后的HWPTR写到Host侧，通知Host buffer当前指令已经读走的位置。

在一个或多个实施例中，在指令数据执行侧，指令执行侧主要做指令的解析、执行和反馈。如图5所示：

首先，指令执行侧从Local buffer收到指令后，会做指令的解析。解析出指令的类型、长度、原始数据、读写地址等信息。

其次，根据指令信息，做数据搬运、数据加减、数据填充等执行操作。

然后，指令执行侧会判断执行状态。每执行完成一次指令，就会返回完成标志，通知Local buffer发送新的指令。

为了更加清楚描述本申请的构思，本公开列举如下示例：

示例1以指令数据主要用于向连续地址写数据为例，执行如下步骤：

1）.初始状态时，Host buffer没有存储任何的指令。HWPTR和HRPTR默认都为0。Host buffer深度为64GByte。

2）.用户把长度为1024Byte的指令写入Host buffer中。该指令主要用于向连续地址写数据。Host 会将HWPTR更新为1024。

3）.然后，Host会主动将更新后的HWPTR写到Local侧，通知Local buffer新的指令写入的位置。此时，Local侧的HWPTR为1024B， HRPTR为0。Local侧判断HWPTR和HRPTR不相等，表明有新的指令写入到Host buffer中。此时，Local侧会发起读指令操作。

4）.Local buffer每次固定读取256B长度的指令。分别存储到Lbuffer0和Lbuffer1，每个Lbuffer的有效长度都是256B。总共读取512B长度的指令，更新HRPTR为512B。此时Local buffer达到最大值，暂停读指令操作。

5）.Local buffer会更新本地的写指针LWPTR为512Byte。

6）. 当Lbuffer0或者Lbuffer1存满256B指令后，Local buffer非空，表明已经有写入到Local buffer中。Local buffer读写侧会主动把指令送到指令执行侧。每次发送的指令长度为16Byte。

7）.指令执行侧将16Byte取走做指令的解析。解析出指令的类型、长度、原始数据、读写地址等信息。

8）. 因此该指令用于向连续地址写数据。因此，指令执行侧会向该地址写入数据。

9）. 指令执行侧每执行完成一次指令16Byte，就会返回完成标志，通知Localbuffer发送新的指令。

10）.Local buffer根据完指令执行侧返回的完成标志，会更新LRPTR（每次加上16Byte）。并取出新的指令发送给指令执行侧。重复7）~10）的操作。

11）.当LRPTR达到256B时，表明Lbuffer0中的指令已经全部读完，会继续读Lbuffer1的指令。因为Lbuffer0的缓存为空，Local buffer会重新发起读指令操作。再从Host buffer中读走256B长度。写入到Lbuffer0中。

12）.同时，Local侧会主动将更新后的HRPTR写到Host侧，通知Host buffer当前指令接着读走的长度为256B。

13）.当LRPTR达到512B时，Lbuffer1中的指令已经全部读完，会继续读Lbuffer0的指令。因为Lbuffer1的缓存为空。Local buffer会重新发起读指令操作。再读走256B长度。写入到Lbuffer1中。Local侧会重复4）-12）的操作，直到HRPTR更新为1024。

14）.当HRPTR到达1024后，local判断HRPTR和HWPTR已经相等，表明指令已经全部被读完，停止读操作。同时，将Host侧的HRPTR回写为1024。

15）.当用户读到HRPTR为1024后，判断HRPTR和HWPTR已经相等，判断该指令已经全部执行完成，停止任何操作。准备发起下一次指令。

示例二以数据指令主要用于对连续地址的数据做加法运算为例，执行如下步骤：

1）. Host buffer中的指令已经全部执行完，HWPTR和HRPTR为32G-1（如前所述GAP为1B）。Host buffer深度为32GByte。

2）. 用户把长度为2MByte的指令写入Host buffer中。该指令主要用于对连续地址的数据做加法运算。由于指令很长，Host 分成1024次写操作，每次写入2048byte指令。例如，第一次写入2048Byte指令，将HWPTR更新为2048。当写完后，会继续写第二次2048Byte指令，将HWPTR更新为4096。以此类推。

3）. 每次更新HWPTR，Host会主动将更新后的HWPTR写到Local侧，通知Localbuffer新的指令写入的位置。第一次更新后，Local侧的HWPTR为2048， HRPTR为32G-1。Local侧判断HWPTR和HRPTR不相等，表明有新的指令写入到Host buffer中。此时，Local侧会发起读指令操作。

4）. Local buffer每次固定读取512B长度的指令。分别存储到Lbuffer0和Lbuffer1，每个Lbuffer的有效长度都是512B。总共读取1024B长度的指令，更新HRPTR为1024B。此时Local buffer达到最大值，暂停读指令操作。

5）. Local buffer会更新本地的写指针LWPTR为1024Byte。

6）. 当Lbuffer0或者Lbuffer1存满512B指令后，Local buffer非空，表明已经有写入到Local buffer中。Local buffer读写模块会主动把指令送到指令执行模块。每次发送的指令长度为32Byte。

7）. 指令执行侧将32Byte取走做指令的解析。解析出指令的类型、长度、原始数据、读写地址等信息。当前指令类型为数据加法计算。于是，从读地址读出原始数据，然后将根据指令携带的加数，对原始数据做加法，并写回原地址。

8）. 指令执行侧每执行完成一次指令32Byte，就会返回完成标志，通知Localbuffer发送新的指令。

9）. Local buffer根据指令执行侧返回的完成标志，会更新LRPTR（每次加上32Byte）。并取出新的指令发送给指令执行侧。重复7）~10）的操作。

10）.当LRPTR达到512B时，表明Lbuffer0中的指令已经全部读完，会继续读Lbuffer1的指令。因为Lbuffer0的缓存为空，Local buffer会重新发起读指令操作。再从Host buffer中读走512B长度。写入到Lbuffer0中。

11）.同时，Local会主动将更新后的HRPTR为写到Host侧，通知Host buffer当前指令已经读走的位置为512B。

12）.当LRPTR达到1024B时，Lbuffer1中的指令已经全部读完，会继续读Lbuffer0的指令。因为Lbuffer1的缓存为空。Local buffer会重新发起读指令操作。再读走512B长度。写入到Lbuffer1中。

13）.当Local侧的HWPTR为4096， HRPTR为1024。Local侧判断HWPTR和HRPTR不相等，表明有Host buffer中仍然有指令。此时，Local侧会继续发起读指令操作。重复4-12的操作。

14）.当用户写到HWPTR为2M-1后，会停止写入。用户会不停的读HRPTR，看指令是否已经执行完成。此时，Local侧每读执行完成上述4）-12）的操作，会更新一次HRPTR。

15）.当HRPTR到达2M-1后，Local判断HRPTR和HWPTR已经相等，表明指令已经全部被读完，停止读操作。同时，将Host的HRPTR回写为2M-1。

16）.当用户读到HRPTR为2M-1后，判断HRPTR和HWPTR已经相等，判断该指令已经全部执行完成，停止操作。准备发起下一次指令。

实施例二：

为实现上述目的，本实施例提供一种GPU指令数据管理的装置600，请参阅图6。具体地，装置600包括：第一更新单元601、第一读取单元602、第一写入单元603。

第一更新单元601，用于响应于Host buffer写入指令数据，根据写入的指令数据长度更新Host侧HWPTR，并将更新后的HWPTR写入Local侧，

第一读取单元602，用于响应于Local侧中的HWPTR和HRPTR不相等，从所述Host侧读指令数据写入到Local buffer，根据读取的指令数据长度更新Local侧HRPTR，并将更新后的HRPTR写入Host侧，

第一写入单元603，用于响应于Host侧中的HWPTR和HRPTR不相等，根据Hostbuffer的空余缓存深度写入新的指令，其中所述空余缓存深度为HWPTR和HRPTR的差值。

实施例三：

相应的，本申请实施例还提供一种电子设备，该电子设备可以为终端或者服务器。如图7所示，图7为本申请实施例提供的电子设备的结构示意图。

该电子设备700包括有一个或者一个以上处理核心的处理器701、有一个或一个以上计算机可读存储介质的存储器702及存储在存储器702上并可在处理器上运行的计算机程序。其中，处理器701与存储器702电性连接。本领域技术人员可以理解，图中示出的电子设备结构并不构成对电子设备的限定，可以包括比图示更多或更少的部件，或者组合某些部件，或者不同的部件布置。

处理器701是电子设备700的控制中心，利用各种接口和线路连接整个电子设备700的各个部分，通过运行或加载存储在存储器702内的软件程序（计算机程序）和/或单元，以及调用存储在存储器702内的数据，执行电子设备700的各种功能和处理数据，从而对电子设备700进行整体监控。

在本申请实施例中，电子设备700中的处理器701会按照前述实施例的方法步骤，将一个或一个以上的应用程序的进程对应的指令数据加载到存储器702中，并由处理器701来运行存储在存储器702中的应用程序，从而实现各种功能。

以上各个操作的具体实施可参见前面的实施例，在此不再赘述。

可选的，如图7所示，电子设备700还包括：GPU指令数据管理单元703、通讯单元704、输入单元705以及电源706。其中，处理器701分别与GPU指令数据管理单元703、通讯单元704、输入单元705以及电源706电性连接。本领域技术人员可以理解，图7中示出的电子设备结构并不构成对电子设备的限定，可以包括比图示更多或更少的部件，或者组合某些部件，或者不同的部件布置。

GPU指令数据管理单元703可用于实现GPU指令数据的管理。所述GPU指令数据的管理操作具体实施可参见前面的实施例，在此不再赘述。

通信侧704可用于与其他设备通信。

输入单元705可用于接收输入的数字、字符信息或用户特征信息（例如指纹、虹膜、面部信息等），以及产生与用户设置以及功能控制有关的键盘、鼠标、操作杆、光学或者轨迹球信号输入。

电源706用于给电子设备700的各个部件供电。可选的，电源706可以通过电源管理系统与处理器701逻辑相连，从而通过电源管理系统实现管理充电、放电、以及功耗管理等功能。电源706还可以包括一个或一个以上的直流或交流电源、再充电系统、电源故障检测电路、电源转换器或者逆变器、电源状态指示器等任意组件。

实施例四：

为实现上述目的，本实施例提出一种用以存储处理器可执行指令数据的计算机可读存储介质，所述计算机可读存储介质中存储的处理器可执行指令数据在被执行时能够致使处理器实施如上所述的GPU指令数据管理方法。

在上述实施例中，应用具体的实施例对本公开的原理及实施方式进行了阐述，各个实施例的描述都各有侧重，某个实施例中没有详述的部分，可以参见其他实施例的相关描述。以上实施例的说明只是用于帮助理解本公开的技术方案及其核心思想；本领域的普通技术人员应当理解：其依然可以对前述各实施例所记载的技术方案进行修改，或者对其中部分技术特征进行等同替换；而这些修改或者替换，并不使相应技术方案的本质脱离本公开各实施例的技术方案的范围。

Claims

1.一种GPU指令数据管理方法，其特征在于，

2.根据权利要求1所述的方法，其特征在于，所述Host buffer为环形buffer。

3.根据权利要求1所述的方法，其特征在于，当所述HWPTR和HRPTR的差值小于一定阈值时，表示Host buffer已满，停止写入操作。

4.根据权利要求1所述的方法，其特征在于，其中所述Local buffer由两个大小相同的Lbuffer组成，用于并行从Host侧读指令数据和将读取的指令数据发送至指令数据执行侧。

5.根据权利要求1所述的方法，其特征在于，

响应于所述Local buffer写入指令数据，根据写入的指令数据长度更新Local侧LWPTR，

其中LWPTR表示写入所述Local buffer的位置的指针，其中LRPTR表示所述读取Localbuffer中指令数据的位置的指针，

6.根据权利要求5所述的方法，其特征在于，两个大小相同的Lbuffer做乒乓操作。

7.根据权利要求5所述的方法，其特征在于，所述指令数据执行侧收到指令数据后，解析出指令的类型、长度、原始数据、读写地址信息，根据指令信执行数据搬运、数据加减、数据填充操作，判断指令执行状态，执行完毕后，返回完成标识。

8.一种GPU指令数据管理的装置，其特征在于，该装置包括，

9.根据权利要求8所述的装置，其特征在于，还包括，

第二更新单元，用于响应于所述Local buffer写入指令数据，根据写入的指令数据长度更新Local侧LWPTR，

10.一种电子设备，包括存储器、处理器及存储在所述存储器上并可在所述处理器上运行的计算机程序，其特征在于，所述处理器执行所述计算机程序时实现上述权利要求1-7中任一项所述的方法的步骤。

11.一种用以存储处理器可执行指令数据的计算机可读存储介质，所述计算机可读存储介质中存储的处理器可执行指令数据在被执行时能够致使处理器实施如权利要求1-7中任一项权利要求所述的方法。