GPU multi-thread lookup table implementation method and device

Abstract

The invention relates to the technical field of chips, and provides a GPU multi-thread lookup table implementation method and device. The method comprises the steps that a special lookup table memory is set for the GPU, all threads are connected to the special lookup table memory, a lookup table is written into the special lookup table memory in advance, and a first application calls an ISALUT instruction to enable the threads to conduct lookup table query from the special lookup table memory; wherein the first application is an application needing to carry out lookup table accelerated query. According to the method, the special lookup table memory is arranged, and the special lookup table memory is used for executing the lookup table query operation, so that the execution efficiency of the lookup table query operation is improved, and the execution time of the lookup table operation is shortened.

Description

Technical Field

[0001] The present invention relates to the field of chip technology, and in particular to a method and device for implementing a GPU multi-threaded lookup table. Background Art

[0002] Graphics Processing Unit (GPU) is a programmable single instruction multiple threads (SIMT) high-performance computing chip, commonly used in high-performance general computing and graphics rendering. When GPU is used in data encryption and decryption and signal processing applications (such as SM4 encryption algorithm and fast Fourier transform FFT), it is often necessary to use a lookup table (LUT) query operation, that is, to find another value y through an index value x, y = LUT (x), where the lookup table is generally a pre-configured array container with a certain depth. For example, the lookup table in the SM4 algorithm contains 256 entries, each of which is 1 byte.

[0003] Since GPU chips are based on SIMT architecture (common commercial chips include SIMD32, SIMD64, etc.), taking SIMD32 architecture as an example, 32 threads are independent of each other but executed in parallel. Each thread has its own local memory for storing runtime information. Therefore, when the GPU implements the above lookup table y = LUT (x) operation, it usually needs to process 32 threads at the same time. For example, when executing (y 31 ,y 30 ,…y0)=LUT(x 31 ,x 30 ,…x0).

[0004] In existing GPU chips, the above table lookup operation is usually implemented with the help of shared memory. Unlike local memory, shared memory is shared by multiple threads, and data can be exchanged between threads of SIMD32 through shared memory. Due to its large capacity (usually each computing core is configured with more than 64K bytes) and for performance considerations, shared memory is generally constructed using multiple static random access memories (SRAM for short) (for example, 8 or 16 blocks are usually used), and each SRAM usually contains a read port.

[0005] The shared memory-based lookup table implementation has the following drawbacks in terms of efficiency:

[0006] (1) GPU instructions are required for address mapping. For any thread input x n , the address in the shared memory needs to be calculated through instructions, including the row address and block number.

[0007] (2) Each SRAM usually has only one multiplexed read / write port (Single Port RAM) or independent read / write port (Dual Port RAM). 31 ,x 30 ,…x0) may be mapped to the same SRAM after address mapping, causing a read conflict (Bank conflict). When a read conflict occurs, the SRAM can only process one read request per clock cycle, so the SRAM can only be split into multiple clock cycles for processing.

[0008] (3) SRAM usually has a read latency of at least two clock cycles. Combined with additional pipeline processing and buffering, the lookup table operation usually requires multiple clock cycles to complete.

[0009] The above defects result in low efficiency and long time consumption when using shared memory to perform table lookup queries. Especially when multiple threads perform table lookup queries concurrently, read conflicts will cause query efficiency to further decrease.

[0010] In view of this, overcoming the defects of the prior art is an urgent problem to be solved in the field of this technology. Summary of the invention

[0011] The technical problem to be solved by the present invention is that the existing technology of using shared memory to perform table lookup is inefficient and time-consuming.

[0012] The present invention adopts the following technical solution:

[0013] In a first aspect, the present invention provides a method for implementing a GPU multi-threaded lookup table, wherein a dedicated lookup table memory is set for the GPU, each thread is connected to the dedicated lookup table memory, and the lookup table is pre-written into the dedicated lookup table memory, the method comprising:

[0014] The first application calls the ISA_LUT instruction to enable the thread to perform a lookup table query from a dedicated lookup table memory; wherein the first application is an application that needs to perform an accelerated lookup table query.

[0015] Preferably, each thread is connected to a dedicated lookup table memory, specifically including:

[0016] Divide each thread into multiple groups, and set a dedicated lookup table memory for each group;

[0017] Each thread is connected to its group's dedicated lookup table memory.

[0018] Preferably, the step of pre-writing the lookup table into a dedicated lookup table memory specifically includes:

[0019] The lookup table required by the corresponding thread is written into the dedicated lookup table memory of the group where it belongs; wherein, when threads of multiple groups need to query the same lookup table, the lookup table is written into the dedicated lookup table memory of multiple groups.

[0020] Preferably, when each thread is divided into N groups, an M-bit dedicated lookup table memory is used; wherein M=D×W×N, D is the depth of the dedicated lookup table memory, and W is the bit width of the dedicated lookup table memory.

[0021] Preferably, for a SIMD32 architecture with 32 threads, each thread is divided into 4 groups, each group includes 8 threads, and each group is provided with a 1024-bit dedicated lookup table memory; wherein the depth of the dedicated lookup table memory is 32 bits, and the bit width of the dedicated lookup table memory is 8 bits.

[0022] Preferably, the pre-writing of the lookup table into the dedicated lookup table memory is accomplished by an ISA_LUT instruction, specifically:

[0023] The ISA_LUT instructions include an ISA_LUT write instruction and an ISA_LUT lookup instruction;

[0024] The ISA_LUT write instruction is used to write the lookup table into the dedicated lookup table memory;

[0025] The ISA_LUT lookup instruction is used to perform a lookup table query from a dedicated lookup table memory.

[0026] Preferably, when the first application is an SM4 encryption and decryption application, the depth of the dedicated lookup table memory is designed to be 256 bits and the bit width is 1 byte.

[0027] Preferably, the second application calls a LUT instruction to enable the thread to perform a lookup table query from the shared memory; wherein the second application is an application that does not need to perform a lookup table accelerated query.

[0028] In a second aspect, the present invention further provides a GPU multi-threaded lookup table implementation device, comprising a processor and a dedicated lookup table memory; the processor is used to carry multiple threads, each thread is connected to the dedicated lookup table memory;

[0029] The processor is used to execute the GPU multi-threaded lookup table implementation method described in the first aspect.

[0030] In a third aspect, the present invention further provides a method for implementing a GPU multi-threaded lookup table, comprising:

[0031] An ISA_LUT instruction is issued to the threads in the GPU multi-threaded lookup table implementation device described in the second aspect, so that the threads perform a lookup table query from a dedicated lookup table memory.

[0032] In a fourth aspect, the present invention further provides a non-volatile computer storage medium, wherein the computer storage medium stores computer executable instructions, and the computer executable instructions are executed by one or more processors to complete the method described in the first aspect.

[0033] In a fifth aspect, a chip is provided, comprising: a processor and an interface, for calling and running a computer program stored in the memory from the memory, and executing the method of the first aspect.

[0034] In a sixth aspect, a computer program product comprising instructions is provided, which, when executed on a computer or a processor, causes the computer or the processor to execute the method of the first aspect.

[0035] The present invention sets a dedicated lookup table memory and uses the dedicated lookup table memory to execute the lookup table query operation, thereby improving the execution efficiency of the lookup table query operation and reducing the execution time of the lookup table operation. BRIEF DESCRIPTION OF THE DRAWINGS

[0036] In order to more clearly illustrate the technical solutions of the embodiments of the present invention, the following briefly introduces the drawings required for use in the embodiments of the present invention. Obviously, the drawings described below are only some embodiments of the present invention, and for ordinary technicians in this field, other drawings can be obtained based on these drawings without creative work.

[0037] Figure 1 It is a schematic diagram of an existing GPU multi-threaded lookup table implementation method provided by an embodiment of the present invention;

[0038] Figure 2 It is a schematic diagram of a GPU multi-threaded lookup table implementation method provided by an embodiment of the present invention;

[0039] Figure 3 It is a flowchart diagram of an existing GPU multi-threaded lookup table implementation method provided by an embodiment of the present invention;

[0040] Figure 4 It is a flowchart diagram of an existing GPU multi-threaded lookup table implementation method provided by an embodiment of the present invention;

[0041] Figure 5 It is a schematic diagram of an existing GPU multi-threaded lookup table implementation method provided by an embodiment of the present invention;

[0042] Figure 6It is a schematic diagram of an existing GPU multi-threaded lookup table implementation method provided by an embodiment of the present invention;

[0043] Figure 7 It is a schematic diagram of an existing GPU multi-threaded lookup table implementation method provided by an embodiment of the present invention;

[0044] Figure 8 It is a schematic diagram of an existing GPU multi-threaded lookup table implementation method provided by an embodiment of the present invention;

[0045] Fig. 9 It is a schematic diagram of the architecture of an existing GPU multi-threaded lookup table implementation device provided by an embodiment of the present invention. DETAILED DESCRIPTION

[0046] In order to make the purpose, technical solution and advantages of the present invention more clearly understood, the present invention is further described in detail below in conjunction with the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are only used to explain the present invention and are not intended to limit the present invention.

[0047] Unless the context requires otherwise, throughout the specification and claims, the term "including" is to be interpreted as open inclusion, that is, "including, but not limited to". In the description of the specification, the terms "one embodiment", "some embodiments", "exemplary embodiments", "examples", "specific examples" or "some examples" and the like are intended to indicate that specific features, structures, materials or characteristics associated with the embodiment or example are included in at least one embodiment or example of the present disclosure. The schematic representation of the above terms does not necessarily refer to the same embodiment or example. In addition, the specific features, structures, materials or characteristics may be included in any one or more embodiments or examples in any appropriate manner, that is, although they may be carried in the embodiments or examples of the above terms due to reasons such as the order and position of appearance, it is not limited to that they can be carried in combination by one embodiment or example.

[0048] In the description of the present invention, the terms "first" and "second" are used only for descriptive purposes, and cannot be understood as indicating or implying relative importance or implicitly indicating the number of indicated technical features. Thus, the features defined as "first" and "second" may explicitly or implicitly include one or more of the features. In the description of the embodiments of the present disclosure, unless otherwise specified, the meaning of "multiple" is two or more. In addition, for example, the same type of nouns may be described as two independent individuals by adding "A" and "B" at the end. In this case, the corresponding features defined as "A" and "B" are only used to distinguish the same type of individuals for description purposes, and cannot be understood as indicating or implying relative importance or implicitly indicating the number of indicated technical features.

[0049] When describing some embodiments, the expressions "coupling", "coupling" and "connection" and their derivatives may be used. For example, when describing some embodiments, the term "connection" may be used to indicate that two or more components are in direct physical or electrical contact with each other. For another example, when describing some embodiments, the term "coupling" may be used to indicate that two or more components are in direct physical or electrical contact. However, the terms "connection" or "coupling" may also refer to two or more components that are not in direct contact with each other, but still cooperate or interact with each other, such as "optical path coupling", "wireless connection", etc. The embodiments disclosed herein are not necessarily limited to the contents of the present invention.

[0050] In the description of the present invention, the expression "A and / or B" (where A and B are used to formally represent specific characteristic contents) will be involved, and the corresponding expressions include the following three combinations: only A, only B, and a combination of A and B.

[0051] As used herein, "about," "substantially," or "approximately" includes the stated value and an average value that is within an acceptable range of deviation from the particular value as determined by one of ordinary skill in the art taking into account the measurements in question and the errors associated with the measurement of the particular quantity (i.e., the limitations of the measurement system).

[0052] In order to make the technical solution and advantages of the present invention more clear, the prior art is briefly described here. The prior art uses shared memory to perform table lookup, which essentially completes the mapping process from the local memory of each thread to the shared memory through GPU instructions. Figure 1 As shown, each thread is connected to the shared memory, and the contents of the lookup table are pre-configured in the shared memory. Assume that for thread n, its local memory has input xn, and then the address in the shared memory is calculated through GPU instructions, and then the corresponding result is read from the shared memory, that is, the search process of yn=LUT(xn) is completed, and then yn is written back to the local memory of the thread. For GPUs, for performance considerations, multiple threads are generally executed in parallel at the same time. For example, in the SIMD32 chip, 32 threads are executed in parallel at the same time.

[0053] In addition, the technical features involved in the various embodiments of the present invention described below can be combined with each other as long as they do not conflict with each other.

[0054] The existing technology uses shared memory to perform lookup table query, which is inefficient and time-consuming. In particular, when multiple threads perform lookup table query concurrently, read conflicts will cause the query efficiency to further decrease. In order to solve this problem, an embodiment of the present invention provides a GPU multi-threaded lookup table implementation method, such as Figure 2As shown, a dedicated lookup table memory is set for the GPU, and each thread is connected to the dedicated lookup table memory, such as Figure 3 As shown, the method includes:

[0055] In step 201, the lookup table is pre-written into a dedicated lookup table memory. It is understandable that the dedicated lookup table memory may be a register in actual use scenarios, and in the drawings, registers are also used as dedicated lookup table memory for presentation, and the present invention does not limit this.

[0056] In step 202, the first application calls the ISA_LUT instruction to enable the thread to perform a lookup table query from the dedicated lookup table memory; wherein the first application is an application that needs to perform an accelerated lookup table query. The ISA_LUT instruction may be a customized instruction by a person skilled in the art.

[0057] In an optional implementation, the pre-writing of the lookup table into the dedicated lookup table memory is accomplished by an ISA_LUT instruction, specifically:

[0058] The ISA_LUT instruction includes an ISA_LUT write instruction and an ISA_LUT lookup instruction; the ISA_LUT write instruction is used to write the lookup table into the dedicated lookup table memory; the ISA_LUT lookup instruction is used to perform a lookup table query from the dedicated lookup table memory. That is, calling the ISA_LUT write instruction causes the thread to write the lookup table into the dedicated lookup table memory.

[0059] The above-mentioned setting of a dedicated lookup table memory for the GPU and connecting each thread to the dedicated lookup table memory actually means that: a shared memory is originally set in the GPU, the shared memory is kept, a dedicated lookup table memory is additionally set, and the processor where each thread is located is connected to the dedicated lookup table memory. The purpose of retaining the shared memory is that in actual use, the GPU not only performs lookup table query operations (i.e., LUT instructions), but also often needs to execute other instructions, such as MOV instructions, DMA instructions, etc. The difference between LUT instructions and other instructions is that the thread concurrency of LUT instructions is usually greater than that of other instructions, so the probability of read conflicts when using shared memory to execute LUT instructions is greater, resulting in the use of shared cache to execute LUT instructions. The efficiency is lower than that of executing other instructions, and the dedicated lookup table memory has relatively less storage space, and it is also difficult to cope with the needs of large-scale data processing under other instructions.

[0060] Therefore, this embodiment sets a dedicated lookup table memory and uses the dedicated lookup table memory to perform the lookup table query operation, thereby improving the execution efficiency of the lookup table query operation and reducing the execution time of the lookup table operation.

[0061] In actual use, since multiple threads are connected to a dedicated lookup table memory, it will cause congestion in the GPU chip during the back-end wiring layout stage. In order to solve this problem, this embodiment also provides a preferred implementation method, that is, each thread is connected to a dedicated lookup table memory, such as Figure 4 As shown, specifically including:

[0062] In step 301, each thread is divided into a plurality of groups, and a dedicated lookup table memory is correspondingly set for each group.

[0063] In step 302, each thread is connected to the dedicated lookup table memory of its group, such as Figure 5 As shown. Specifically, how to divide the groups is determined by those skilled in the art according to demand analysis, and the number of threads in each group can be the same or different. Each thread only uses the dedicated lookup table memory of its group to perform a lookup table query, thereby solving potential backend congestion problems and making software programming more flexible.

[0064] Correspondingly, the step of pre-writing the lookup table into a dedicated lookup table memory specifically includes:

[0065] The lookup table required by the corresponding thread is written into the dedicated lookup table memory of the group to which it belongs; wherein, when threads of multiple groups need to query the same lookup table, the lookup table is written into the dedicated lookup table memory of multiple groups, such as when Figure 5 When threads 0 to n-1 and threads m×n to m×n+n-1 need to query lookup table 1, the complete contents of lookup table 1 are written into dedicated lookup table memory LUT 0 and dedicated lookup table memory LUT m; when threads of multiple groups need to query different tables, their respective lookup tables are written into the dedicated lookup table memory of the group to which the respective threads belong. Since each group is provided with a corresponding dedicated lookup table memory, each group can correspond to a different lookup table, thereby improving the degree of freedom of lookup table query.

[0066] In some implementations, when each thread is divided into N groups, an M-bit dedicated lookup table memory is used; wherein M = D×W×N, D is the depth of the dedicated lookup table memory, and W is the bit width of the dedicated lookup table memory. For example, for a SIMD32 architecture with 32 threads, each thread is divided into 4 groups, each group includes 8 threads, and each group is provided with a 1024-bit dedicated lookup table memory; wherein the depth of the dedicated lookup table memory is 32 bits, and the bit width of the dedicated lookup table memory is 8 bits.

[0067] In other implementations, when the first application is an SM4 encryption and decryption application, the depth of the dedicated lookup table memory is designed to be 256 bits and the bit width is 1 byte.

[0068] It is understandable that in actual use, since the present embodiment additionally defines the ISA_LUT instruction and does not rewrite or overwrite the original LUT instruction, the present embodiment also retains the original function of using shared memory for table lookup query, thereby supporting the selection of using dedicated table lookup memory or shared memory for table lookup query, and the specific selection is determined by the application according to its own needs. That is, for applications that need to perform table lookup acceleration query, call the ISA_LUT instruction to use the dedicated table lookup memory for table lookup query, and for applications that do not need to perform table lookup acceleration query, call the LUT instruction to use the GPU's own shared memory for table lookup query, that is, the second application calls the LUT instruction to enable the thread to perform table lookup query from the shared memory; wherein, the second application is an application that does not need to perform table lookup acceleration query. The second application is an application that does not need to perform table lookup acceleration query.

[0069] In some application scenarios, whether the corresponding application needs to perform accelerated lookup table query is determined by those skilled in the art based on demand analysis. In other application scenarios, this embodiment also provides a preferred implementation method, that is, the upstream application uniformly calls the LUT instruction to perform the lookup table query operation. When the GPU receives the LUT instruction, it chooses to continue to use the LUT instruction to perform the lookup table query operation from the shared memory, or chooses to map the LUT instruction to the ISA_LUT instruction to perform the lookup table query operation from the dedicated lookup table memory, according to the size of the lookup table to be searched or the type of the upstream application. Specifically:

[0070] During initialization, the lookup table is written into the shared cache and into the register; when the GPU receives the LUT instruction of the first upstream application, it is determined whether the acceleration identifier of the first upstream application is stored in the GPU.

[0071] When it is determined that the acceleration mark of the first upstream application is not stored in the GPU, a LUT instruction is used to perform a lookup table query operation from the shared cache, and the time t0 consumed by the lookup table query operation is recorded; if t0 is greater than the first preset time, the acceleration mark of the first upstream application stored in the GPU is 1; if t0 is less than the second preset time, the acceleration mark of the first upstream application stored in the GPU is 0; if t0 is greater than or equal to the second preset time, and less than or equal to the first preset time, the acceleration mark of the first upstream application is stored as 2. The first preset time and the second preset time are both obtained by those skilled in the art based on empirical analysis, and the second preset time is less than the first preset time.

[0072] When it is determined that the acceleration flag of the first upstream application is stored in the GPU, and the acceleration flag of the first upstream application is 1, the LUT instruction is mapped to the ISA_LUT instruction, so as to use the ISA_LUT instruction to perform a lookup table query operation from the dedicated lookup table memory. For example, when the first upstream application first performs a lookup table query operation, that is, executes y=LUT(x), and then performs arithmetic processing on the search result, that is, executes z=y*y. This complete operation will be translated into multiple instructions in the GPU, among which, the ISA_LUT.write instruction will be inserted before the program runs to complete the initialization of the dedicated lookup table memory in the GPU (that is, write the lookup table into the register). When the GPU runs y=LUT(x), if it is identified that the acceleration flag of the first upstream application is 1, y=LUT(x) will be mapped to the ISA_LUT.lookup instruction; z=y*y will be mapped to an arithmetic INT instruction, so as to use the register to perform a lookup table query operation.

[0073] When it is determined that the acceleration identifier of the first upstream application is stored in the GPU and the acceleration identifier of the first upstream application is 0, a LUT instruction is used to perform a lookup table query operation in the shared cache.

[0074] When it is determined that the acceleration flag of the first upstream application is stored in the GPU and the acceleration flag of the first upstream application is 2, a LUT instruction is used to perform a lookup table query operation from the shared cache, and the number of times the first upstream application performs the lookup table query operation, frequency, is recorded within a preset period. If the record shows that the frequency within the preset period is greater than the preset number of times, the acceleration flag of the first upstream application is switched to 1, so that a dedicated lookup table memory can be used to perform the lookup table query operation subsequently. The preset period can be obtained by a person skilled in the art based on empirical analysis, and the present invention is not limited to this.

[0075] It can be understood that: when the use of shared memory to perform a table lookup operation takes too long (exceeds the first preset time), or the query frequency is too high and time-consuming (i.e., the time exceeds the second preset time, and the number of queries within the preset cycle is greater than the preset number), the register is used to perform the table lookup operation to improve the efficiency of the table lookup; otherwise, the shared memory is still used for the table lookup operation. For other instructions that require the participation of the memory, they are all implemented using shared memory.

[0076] The present invention is based on the method described above, combined with specific application scenarios, and uses technical descriptions in related scenarios to illustrate the implementation process of the present invention in the characteristic scenarios.

[0077] This embodiment takes SIMD32 GPU as an example of an application scenario. The purpose of this embodiment is to enable multi-threaded GPU to perform lookup table operations efficiently and quickly, such as quickly executing (y 31 ,y 30 ,…y0)=LUT(x 31 ,x 30 ,…x0).

[0078] In the prior art, GPU lookup table query is mainly implemented based on shared memory, which has defects such as address calculation, read conflict, long delay, etc. In order to avoid the defects such as address calculation, read conflict, long delay, etc. in the existing shared memory-based solutions, this embodiment uses a dedicated low-cost register array (Flip-Flop Array) to implement the lookup table, and creates a customized lookup table instruction to complete the parallel implementation of multi-threaded lookup table operations.

[0079] That is, in the GPU computing core, a small register array is used as a dedicated lookup table container. The register LUT can be adjusted according to the application requirements. For example, in the SM4 encryption and decryption application, it can be configured to have a depth (D) of 256 and a width (W) of one byte. The advantage of register array implementation is that there is no clock cycle delay in reading and writing registers, and it can process read and write requests of multiple threads at the same time, without read and write conflicts between multiple threads.

[0080] In order to further improve the flexibility of the use of lookup table operations and prevent possible congestion in the GPU chip during the back-end wiring layout stage, this embodiment also introduces an additional grouping strategy. For the SIMD32 architecture, 32 threads are divided into several groups. Each group has an independent register LUT, and all threads in each group can access the register LUT at the same time. During the user application programming stage, each register LUT can be independently initialized to configure different lookup table contents, increasing programming flexibility. For example, SIMD32 is divided into 4 groups, then the original (y 31 ,y 30 ,…,y0)=LUT(x 31 ,x 30 ,…,x0) can be expanded into four instructions, namely (y 31 ,…y 24 )=LUT0(x 31 ,…x 24 ), (y 23 ,…,y 16 )=LUT1(x 23 ,…,x 16 ), (y 15,…,y8)=LUT2(x 15 ,…,x8), (y7,…,y0)=LUT3(x7,…,x0). Assuming the register LUT specification is set to 32depth×8width, and SIMD32 is divided into 4 groups, each computing core only needs 32×8×4=1024bit registers. When implementing GPU design, the specific grouping strategy needs to be considered comprehensively based on SIMD size, application requirements, and backend timing.

[0081] In addition to the grouped register LUTs, the present invention also uses customized lookup table LUT instructions (ie, ISA_LUT instructions) to implement read and write control of the register array.

[0082] The ISA_LUT instruction includes two operations: Write and Lookup. Write is used to initialize the register LUT and complete the assignment operation for each entry in the LUT. The ISA_LUT write instruction mainly includes two operands x and d, which are stored in the local storage of each thread. x is the index value of the LUT, and d is the entry value corresponding to x. Figure 6 Lookup is the query process of LUT. Each thread can independently execute the operation y=LUT(x). The content in LUT is usually initialized in advance through the ISA_LUT write instruction. The ISA_LUT lookup instruction contains the operand x and the return value y. Figure 7 As shown, both x and y are stored in the local memory of each thread.

[0083] In combination with the dedicated register LUT and ISA_LUT instruction, this embodiment can complete various operations of the GPU multi-threaded lookup table, including specification configuration, table entry initialization and query operation, and the execution of the ISA_LUT instruction can achieve the theoretical maximum performance.

[0084] This embodiment uses a dedicated hardware lookup table and customized lookup table instructions to implement GPU multi-threaded lookup table operations. In terms of performance, it can achieve the theoretical maximum performance of SIMD32 in one clock cycle, and can be fully pipelined. Compared with the existing shared memory solution, it avoids problems such as address calculation, read conflict, and long delay.

[0085] In this embodiment, SIMD32 is divided into 4 groups, each group includes 8 threads. For example, each register is 32×8×4=1024 bits. Figure 8As shown, threads 0 to 7 are connected to register LUT 0, threads 8 to 15 are connected to register LUT 1, threads 16 to 23 are connected to register LUT 2, and threads 24 to 31 are connected to register LUT 3. Before performing a lookup table query, the application writes the lookup table into the register in advance. For example, application 1 sends an ISA_LUT write instruction to threads 0 to 7 during the initialization phase, which carries the index value x and the table entry value d in Table 1, so that threads 0 to 7 write the lookup table 1 into the register LUT 0; in the subsequent actual operation, the first application sends an ISA_LUTlookup instruction to threads 0 to 7, which carries the operand x, so that threads 1 to 7 perform a lookup table query from register LUT 0 in parallel.

[0086] If there is application 2 that also needs to be accelerated, and the lookup table it needs to query is different from that of application 1, such as the lookup table that application 2 needs to query is Table 2, application 2 can be made to correspond to other groups, such as making application 2 correspond to Group 2, that is, threads 8 to 15. Similarly, application 2 sends an ISA_LUT write instruction to threads 8 to 15, which carries the index value x and the table entry value d in Table 2, so that threads 8 to 15 write lookup Table 2 into register LUT 0. In subsequent work, the first application sends an ISA_LUT lookup instruction to threads 8 to 15, so that threads 8 to 15 perform lookup table queries in register LUT 0 in parallel.

[0087] There is also a possible situation: application 1 needs to implement the concurrency of more than 8 threads, such as 24 threads need to concurrently query Table 1. Then, application 1 sends ISA_LUT write instructions to threads 0 to 7, threads 8 to 15, and threads 16 to 23 in the initialization phase, wherein the instructions carry the index value x and the table item value d in Table 1, so that threads 0 to 7 write lookup table 1 to register LUT 0, threads 8 to 15 write lookup table 1 to register LUT 1, and threads 16 to 23 write lookup table 1 to register LUT 2; in the subsequent actual operation, the first application sends ISA_LUT lookup instructions to threads 0 to 7, threads 8 to 15, and threads 16 to 23, wherein the instructions carry the operand x, so that threads 1 to 7 perform lookup table queries in parallel from register LUT 0, threads 8 to 15 perform lookup table queries in parallel from register LUT 1, and threads 16 to 23 perform lookup table queries in parallel from register LUT 2. 2, the final search results all depend on the same lookup table (i.e., Table 1).

[0088] It should be noted here that the thread grouping and the number of registers are all set during the GPU hardware design and development stage. Before calling the ISA_LUT write instruction and the ISA_LUT lookup instruction, each application needs to know the thread grouping and the number of registers in advance. This information can be recorded in advance by those skilled in the art so that each application can obtain it by calling the record, or it can be obtained through communication between the application and the GPU. The present invention does not limit the specific way in which the application obtains the thread grouping and the number of registers.

[0089] The present invention is further elaborated below by taking the SM4 algorithm encryption and decryption application as an example of the application scenario of the first application.

[0090] The SM4 algorithm mainly includes XOR, shift and box transformation operations. It is divided into two modules: key expansion and encryption / decryption. The processes of these two modules are similar. Among them, shift transformation refers to circular left shift; box transformation is a transformation that maps 8-bit input to 8-bit output. It is a fixed transformation, and box transformation is usually implemented based on GPU. In actual use, one SM4 encryption and decryption usually requires multiple box transformations, and each box transformation requires a lookup table query operation. The lookup table used for the box transformation is the S box (Substitution-box). The S box is expressed as a 16×16 table. The first 4 bits of the input 8-bit number determine the row, and the last 4 bits determine the column. The row and column jointly determine an item in the table. In actual use, the S box is usually set to a one-dimensional array with a length of 256. In this embodiment, the one-dimensional array is written into a register. That is, the SM4 algorithm encryption and decryption application calls the ISA_LUT write instruction in advance to write the one-dimensional array into the register. When the SM4 algorithm encryption and decryption application actually performs SM4 encryption or SM4 decryption, it calls the ISA_LUT lookup instruction to perform a lookup table query from the register to obtain the result of the box transformation.

[0091] This embodiment also provides a GPU multi-threaded lookup table implementation device, including a processor and a register; the processor is used to carry multiple threads, each thread is connected to a dedicated lookup table memory;

[0092] The processor is used to execute the above-mentioned GPU multi-threaded lookup table implementation method. The processor can be a GPU, and the shared memory and registers in the GPU are also collectively referred to as memory in subsequent embodiments. It should be noted here that in order to make the technical solution of the present invention clearer, this embodiment is described based on a simplest GPU architecture, and the original connection relationship in the GPU is not repeated in this embodiment; in actual use, the GPU often includes not only a processor and a memory, but also multiple modules such as a local memory, an arithmetic logic unit, and a storage unit.

[0093] Based on the above GPU multi-threaded lookup table implementation device, this embodiment also provides a GPU multi-threaded lookup table implementation method, including: issuing ISA_LUT instructions to threads in the above GPU multi-threaded lookup table implementation device, so that the threads perform lookup table queries from registers. The GPU multi-threaded lookup table implementation method can be executed by the GPU itself or by other external modules, and this embodiment does not limit the specific execution location of the method.

[0094] like Fig. 9 , is a schematic diagram of the architecture of a GPU multi-threaded lookup table implementation device according to an embodiment of the present invention. The GPU multi-threaded lookup table implementation device according to this embodiment includes one or more processors 21 and a memory 22. The memory 22 includes registers and shared memory. Fig. 9 A processor 21 is taken as an example.

[0095] The processor 21 and the memory 22 may be connected via a bus or other means. Fig. 9 The example of connecting through bus is taken in the following.

[0096] The memory 22 is a non-volatile computer-readable storage medium that can be used to store non-volatile software programs and non-volatile computer executable programs, such as the GPU multi-threaded lookup table implementation method described above. The processor 21 executes the GPU multi-threaded lookup table implementation method by running the non-volatile software programs and instructions stored in the memory 22.

[0097] The memory 22 may include a high-speed random access memory, and may also include a non-volatile memory, such as at least one disk storage device, a flash memory device, or other non-volatile solid-state storage devices. In some embodiments, the memory 22 may optionally include a memory remotely arranged relative to the processor 21, and these remote memories may be connected to the processor 21 via a network. Examples of the above-mentioned network include, but are not limited to, the Internet, an intranet, a local area network, a mobile communication network, and combinations thereof.

[0098] The program instructions / modules are stored in the memory 22, and when executed by the one or more processors 21, the above-mentioned GPU multi-threaded lookup table implementation method is executed.

[0099] It is worth noting that the information interaction, execution process, etc. between the modules and units within the above-mentioned devices and systems are based on the same concept as the processing method embodiment of the present invention. The specific contents can be found in the description of the method embodiment of the present invention and will not be repeated here.

[0100] A person skilled in the art may understand that all or part of the steps in the various methods of the embodiments may be completed by instructing related hardware through a program, and the program may be stored in a computer-readable storage medium, and the storage medium may include: a read-only memory (ROM), a random access memory (RAM), a disk or an optical disk, etc.

[0101] The above description is only a preferred embodiment of the present invention and is not intended to limit the present invention. Any modifications, equivalent substitutions and improvements made within the spirit and principles of the present invention should be included in the protection scope of the present invention.

Claims

1. A GPU multi-threaded lookup table implementation method, characterized in that: A dedicated lookup table memory is set for the GPU, each thread is connected to the dedicated lookup table memory, and the lookup table is pre-written into the dedicated lookup table memory. The method includes: The first application calls the ISA_LUT instruction to enable the thread to perform a lookup table query from a dedicated lookup table memory; wherein the first application is an application that needs to perform an accelerated lookup table query.

2. The GPU multi-threaded lookup table implementation method according to claim 1, characterized in that: Each thread is connected to a dedicated lookup table memory including: Divide each thread into multiple groups, and set a dedicated lookup table memory for each group; Each thread is connected to its group's dedicated lookup table memory.

3. The GPU multi-threaded lookup table implementation method according to claim 2, characterized in that: The step of pre-writing the lookup table into the dedicated lookup table memory comprises: The lookup table required by the corresponding thread is written into the dedicated lookup table memory of the group where it belongs; wherein, when threads of multiple groups need to query the same lookup table, the lookup table is written into the dedicated lookup table memory of multiple groups.

4. The GPU multi-threaded lookup table implementation method according to claim 2, characterized in that: When each thread is divided into N groups, an M-bit dedicated lookup table memory is used; wherein M=D×W×N, D is the depth of the dedicated lookup table memory, and W is the bit width of the dedicated lookup table memory.

5. The GPU multi-threaded lookup table implementation method according to claim 4, characterized in that: For a SIMD32 architecture with 32 threads, each thread is divided into 4 groups, each group includes 8 threads, and each group is provided with a 1024-bit dedicated lookup table memory; wherein the depth of the dedicated lookup table memory is 32 bits, and the bit width of the dedicated lookup table memory is 8 bits.

6. The GPU multi-threaded lookup table implementation method according to claim 1, characterized in that: The pre-writing of the lookup table into the dedicated lookup table memory is accomplished by an ISA_LUT instruction, including: The ISA_LUT instructions include an ISA_LUT write instruction and an ISA_LUT lookup instruction; The ISA_LUT write instruction is used to write the lookup table into the dedicated lookup table memory; The ISA_LUT lookup instruction is used to perform a lookup table query from a dedicated lookup table memory.

7. The GPU multi-threaded lookup table implementation method according to claim 1, characterized in that: When the first application is an SM4 encryption and decryption application, the depth of the dedicated lookup table memory is designed to be 256 bits and the bit width is 1 byte.

8. The GPU multi-threaded lookup table implementation method according to claim 1, characterized in that: The second application calls the LUT instruction to enable the thread to perform a lookup table query from the shared memory; wherein the second application is an application that does not need to perform a lookup table accelerated query.

9. A GPU multi-threaded lookup table implementation device, characterized in that: It includes a processor and a dedicated lookup table memory; the processor is used to carry multiple threads, and each thread is connected to the dedicated lookup table memory; The processor is used to execute the GPU multi-threaded lookup table implementation method according to any one of claims 1 to 8.

10. A GPU multi-threaded lookup table implementation method, characterized in that: include: An ISA_LUT instruction is issued to the thread in the GPU multi-threaded lookup table implementation device of claim 9, so that the thread performs a lookup table query from a dedicated lookup table memory.

Images