Data processing device, chip, electronic equipment, processor and method

Abstract

The invention discloses a data processing device, a chip, electronic equipment, a processor and a method, and relates to the technical field of electronics. The device comprises a scheduling module and a plurality of analysis paths. And the scheduling module is responsible for converting a compression strategy analysis task of the whole graphic element data set into a subtask allocated to a corresponding analysis path. And each analysis path can independently read the primitive data subset corresponding to the sub-task according to the received sub-task and generate a corresponding compression strategy. In the above scheme, under the condition that the scheduling module extracts the plurality of sub-tasks from the complete task, at least two sub-tasks in the plurality of sub-tasks are output to different analysis paths, and the different analysis paths can independently read data and process the data in parallel, so that under the condition that the total amount of read bandwidth is not changed, the data processing efficiency is improved. According to the scheme, the total amount of data supported to be processed by the analysis path in unit time is increased, so that the utilization rate of read bandwidth is improved.

Description

Technical Field

[0001] This application relates to the field of electronic technology, and in particular to a data processing device, chip, electronic device, processor, and method. Background Technology

[0002] In computer graphics, primitives are the basic units that make up an image. Basic points, lines, and surfaces in an image can all be classified as primitives.

[0003] In the graphics rendering pipeline, to reduce the bandwidth consumption of primitive data during storage and transmission, it is necessary to compress the primitive data. In practical applications, the task initiator issues a compression task for the primitive dataset to the analysis path. After receiving the task, the task path reads the primitive dataset from the storage unit where it is stored and generates a compression strategy by analyzing the data in the primitive dataset.

[0004] However, in the above scheme, due to the structural limitations of the task path, in some cases the task path processes the data read from the storage unit at a slow rate, resulting in a waste of read bandwidth. Summary of the Invention

[0005] This application provides a data processing device, a chip, an electronic device, a processor, and a method. The technical solutions provided by this application are as follows: According to one aspect of the embodiments of this application, a data processing apparatus is provided, the apparatus including a scheduling module and multiple analysis paths; The scheduling module is used to receive compression strategy analysis tasks for primitive datasets; The scheduling module is further configured to extract at least one compression strategy analysis task corresponding to each of the compression strategy analysis tasks of the primitive dataset, so as to obtain at least one subtask, wherein the primitive dataset includes the at least one subset of primitive data. The scheduling module is further configured to output the at least one subtask to the analysis path, wherein one subtask is output to one analysis path, and when the at least one subtask is multiple subtasks, at least two of the multiple subtasks are output to different analysis paths. The target analysis path among the multiple analysis paths is used to read the graph data subset corresponding to the target subtask when receiving the target subtask in the at least one subtask, and to generate a compression strategy for the graph data subset corresponding to the target subtask, wherein the compression strategy for the graph data subset corresponding to the target subtask is used to compress the graph data subset corresponding to the target subtask.

[0006] According to one aspect of the embodiments of this application, a chip is provided, the chip including the above-described data processing apparatus.

[0007] According to one aspect of the embodiments of this application, an electronic device is provided, the electronic device including a chip, the chip including the above-described data processing device.

[0008] According to one aspect of the embodiments of this application, a processor is provided, the processor including the above-described data processing apparatus.

[0009] According to one aspect of the embodiments of this application, a data processing method applied to a data processing apparatus is provided, the apparatus including a scheduling module and multiple analysis paths; the method includes: The scheduling module receives the task of analyzing the compression strategy of the primitive dataset; The scheduling module extracts at least one compression strategy analysis task corresponding to a compression data subset from the compression strategy analysis task of the primitive dataset to obtain at least one subtask. The primitive dataset includes the at least one subset of primitive data. The scheduling module outputs the at least one subtask to the analysis path, wherein one subtask is output to one analysis path, and when the at least one subtask is multiple subtasks, at least two of the multiple subtasks are output to different analysis paths. When the target analysis path in the multiple analysis paths receives the target subtask from the at least one subtask, it reads the graph data subset corresponding to the target subtask and generates a compression strategy for the graph data subset corresponding to the target subtask. The compression strategy for the graph data subset corresponding to the target subtask is used to compress the graph data subset corresponding to the target subtask.

[0010] The technical solutions provided in this application have at least the following beneficial effects: A scheduling module and multiple analysis paths are designed in the data processing device. The scheduling module is responsible for transforming the compression strategy analysis task of the entire primitive dataset into subtasks assigned to the corresponding analysis paths. Each analysis path can independently read the primitive data subset corresponding to the subtask it receives and generate the corresponding compression strategy. In the above scheme, when the scheduling module extracts multiple subtasks from the complete task, since at least two subtasks are output to different analysis paths, and different analysis paths can independently read and process data in parallel, this scheme increases the total amount of data that the analysis paths can support processing per unit time, thereby improving the utilization rate of read bandwidth, while keeping the total read bandwidth of the storage unit used to store the primitive dataset unchanged, due to the parallel operation of multiple analysis paths. Attached Figure Description

[0011] Figure 1 This is a schematic diagram of the structure of a data processing apparatus provided in one embodiment of this application; Figure 2 This is a flowchart of a task scheduling process executed by a scheduling module according to an embodiment of this application; Figure 3 This is a schematic diagram of the structure of a request processing unit and a target analysis path in a data processing apparatus provided in one embodiment of this application; Figure 4 This is a schematic diagram of the structure of a data processing unit provided in one embodiment of this application; Figure 5 This is a schematic diagram of the target byte analysis path provided in one embodiment of this application; Figure 6 This is a schematic diagram of the structure of an exemplary data processing apparatus provided in one embodiment of this application; Figure 7 This is a schematic diagram of the structure of a chip provided in one embodiment of this application; Figure 8 This is a flowchart of a data processing method applied to a data processing device according to an embodiment of this application. Detailed Implementation

[0012] To make the objectives, technical solutions, and advantages of this application clearer, the embodiments of this application will be described in further detail below with reference to the accompanying drawings.

[0013] Before introducing the technical solution of this application, some terms involved in this application will be explained. The following related explanations are optional and can be combined with the technical solutions of the embodiments of this application in any way, all of which fall within the protection scope of this application. The embodiments of this application include at least some of the following contents.

[0014] Primitives: The basic geometric units that make up an image, such as points, lines, and polygons. Polygons can be triangles or quadrilaterals. Alternatively, primitives can also be considered as the smallest geometric units that are directly processed and rendered in the graphics rendering pipeline.

[0015] Graphical data: Data used to describe the location, structure, or attributes of graphic elements.

[0016] Byte: A unit of measurement used to describe the storage and transmission capacity of a computer; it is the basic unit of computer storage.

[0017] Byte Plane: In this embodiment, bytes in the graphic data can be divided into the same or different byte planes. The division rule is as follows: different bytes belonging to the same byte plane correspond to graphic data that indicate the same type of attribute or coordinate value of the graphic element, and the positions of different bytes belonging to the same byte plane in the corresponding graphic data have a corresponding relationship. In the following embodiments, this division rule will be described in more detail, and will not be repeated here.

[0018] First In First Out (FIFO) queue: A data storage structure that follows the first-in-first-out principle. Its core feature is that the element that enters the queue earliest is output and removed first.

[0019] In graphics rendering pipelines, compression of metadata is necessary to reduce bandwidth consumption during storage and transmission. The core logic of a compression method provided in this application is as follows: For a primitive dataset composed of a set of metadata, such as a dataset of metadata of primitives located close to each other in a defined space, the individual bytes are divided into different byte planes, and compression strategy analysis is performed on bytes belonging to the same byte plane. Optionally, the analysis process involves traversing each byte in the byte plane to obtain the numerical range of each byte, such as a range from minimum to maximum value. Subsequently, bit width compression can be performed on bytes belonging to the byte plane based on this numerical range. For example, if a byte within a certain numerical range only requires 4 bits of storage, then the bit width of that byte can be compressed to 4 bits.

[0020] The above analysis process can be implemented by the analysis module provided in this application. The input of the analysis module is a set of graph data, which consists of serial bytes belonging to the same byte plane. Each time a byte is input, the analysis module compares it with the numerical range of bytes in the currently recorded byte plane. If the input byte exceeds the numerical range, the numerical range is updated. If the input byte is within the recorded numerical range, the numerical range remains unchanged. This process continues until the analysis module processes the last byte belonging to the byte plane in this set of graph data, and then outputs the final numerical range as the compression strategy for bytes in the byte plane.

[0021] In some embodiments, the primitive dataset is read from the storage unit through an analysis path and a compression strategy for the primitive dataset is generated. This analysis path can be configured with multiple analysis modules to support the parallel generation of compression strategies for the primitive dataset corresponding to different byte planes.

[0022] However, in the above scheme, since bytes belonging to the same byte plane need to be input to the analysis module serially, bytes belonging to the same byte plane in a single read data cannot be used in parallel, resulting in wasted read bandwidth when reading data from the storage unit. Taking 3 bytes of the same byte plane in each read data as an example, the above analysis path can only provide 1 valid byte for several analysis modules for each read data. The other two bytes need to wait for subsequent clock cycles to be input to the analysis module. During this time, the analysis path cannot read data again, resulting in the utilization rate of the storage unit throughput being only 1 / 3, that is, the read bandwidth is not maximized.

[0023] Furthermore, in the above scheme, the throughput of the analysis path is also limited by the storage format of the graph data in the storage unit. Specifically, the utilization rate of the multiple analysis modules included in the analysis path depends on the number of byte planes corresponding to the data read from the storage unit each time. If the number of byte planes corresponding to the data read from the storage unit each time is small, only a few analysis modules will work, resulting in low throughput of the analysis path.

[0024] To address the aforementioned issues, this application provides a data processing apparatus. This apparatus includes a scheduling module for task allocation and multiple independent analysis paths. Since the multiple independent analysis paths can process sub-tasks extracted from the overall compression strategy analysis task in parallel, the data processing apparatus has both high throughput, reducing the overall time consumption of the compression strategy analysis stage, and more fully utilizing the read bandwidth of the storage unit. The structure of the above-mentioned data processing apparatus will be described in more detail in the following embodiments.

[0025] Please refer to Figure 1 The diagram illustrates the structure of a data processing apparatus 100 according to an embodiment of this application. The data processing apparatus 100 includes a scheduling module 10 and multiple analysis paths 20.

[0026] In some embodiments, the output of the scheduling module 10 is connected to the input of multiple analysis paths 20.

[0027] The scheduling module 10 is used to receive compression strategy analysis tasks for primitive datasets.

[0028] The task of analyzing compression strategies for primitive datasets is to analyze the compression strategies of primitive datasets. This task may include at least one of the following: allocating reference information, or reading reference information.

[0029] The allocation reference information is used to extract subtasks from the compression strategy analysis task.

[0030] The reference information is used to read the graph data in the graph data set.

[0031] In some embodiments, the allocation reference information includes at least one of the following: the graph metadata type to which each graph metadata in the graph metadata set belongs, and the standard number of bytes for each graph metadata type.

[0032] Among them, the graph data elements belonging to the same graph data element type indicate the same type of coordinate values ​​or the same type of attributes of the graph elements.

[0033] The coordinate values ​​mentioned in the embodiments of this application are used to indicate the position of the graphic element in a set space. The set space can be a three-dimensional space or a two-dimensional space, i.e., a plane.

[0034] For example, the coordinate values ​​of a primitive or its vertex in each direction in three-dimensional space can be considered as a type of primitive data. For instance, if the coordinate values ​​of a primitive or its vertex in a first direction in three-dimensional space are called x-coordinates, the coordinate values ​​in a second direction are called y-coordinates, and the coordinate values ​​in a third direction are called z-coordinates, then all x-coordinates in the primitive data set can be considered to belong to one type of primitive data, all y-coordinates can be considered to belong to another type of primitive data, and all z-coordinates can be considered to belong to yet another type of primitive data. Optionally, the first, second, and third directions are perpendicular to each other.

[0035] The "attributes" mentioned in the embodiments of this application refer to the display attributes of graphic elements, which are used to determine the display style of graphic elements, such as color, texture, lighting effects, etc.

[0036] In one example, the color value of a primitive in each color channel can be considered as a primitive data type. For example, all R (Red) values ​​in the primitive data set can be considered as belonging to one primitive data type, all G (Green) values ​​can be considered as belonging to another primitive data type, and all B (Blue) values ​​can be considered as belonging to yet another primitive data type.

[0037] In another example, the texture coordinate value at each location in a primitive's texture coordinates can be considered a type of primitive data. The texture coordinates of a primitive are used to indicate the texture of the primitive. Specifically, they can be coordinates that indicate the texture used by the primitive from a large texture image. For example, texture coordinates can be represented as (u, v), and correspondingly, all u values ​​in the primitive data set can be considered to belong to one type of primitive data, and all v values ​​can be considered to belong to another type of primitive data.

[0038] In yet another example, the element value at each position in a primitive's normal vector can be considered a primitive data type. The primitive's normal vector indicates the surface orientation and direction of the primitive, which determines the lighting effect on the primitive. A primitive's normal vector includes at least two element values, thus supporting the construction of a vector. For example, for a primitive in 3D space, the normal vector can be represented as (n... x n y n z This indicates that, correspondingly, all n elements in the graph data set... x The value can be considered as a type of graph data, so all n y The value can be considered to belong to another type of graph data, all n z The value can be considered as another type of graph data type.

[0039] Of course, the above image data types are merely illustrative examples. Since those skilled in the art can configure more or fewer attributes and / or coordinate values ​​for image elements according to their needs, this application does not limit the specific classification of image data types.

[0040] The standard byte count of a graph data type refers to the number of bytes that graph data belonging to that type uniformly possesses. For example, if the standard byte count of the x-coordinate value graph data type is 3, then all x-coordinate values ​​in the graph data set have 3 bytes.

[0041] It should be noted that the standard byte count for each type of map data can also be equivalent to the number of byte planes to which the bytes of a single map data element belonging to that type belong. For example, the standard byte count for an x-coordinate value is 3, meaning that the 3 bytes of a single x-coordinate value belong to different byte planes, so the bytes of an x-coordinate value belong to a total of 3 byte planes. For a detailed explanation of byte planes, please refer to the embodiments below, which will not be repeated here.

[0042] In some embodiments, the reference information to be read includes address indication information for each piece of primitive data in the primitive data set. The address indication information is used to determine the address of the primitive data in the storage unit. The storage unit is used to store the primitive dataset.

[0043] Of course, to facilitate task assignment and distribution, technicians can configure more or less information in the primitive dataset compression strategy analysis task as needed. For example, the primitive dataset compression strategy analysis task may also include the number of primitives corresponding to the primitive dataset, the number of primitive data for each type of primitive data, etc. This application does not limit this.

[0044] The scheduling module 10 is also used to extract at least one compression strategy analysis task corresponding to a subset of graph data from the compression strategy analysis task of the graph primitive dataset, so as to obtain at least one subtask. The graph primitive dataset includes at least one subset of graph data.

[0045] The task of analyzing the compression strategy corresponding to a subset of graph data is a subtask, which is the task of analyzing the compression strategy of the corresponding subset of graph data.

[0046] In some embodiments, the scheduling module 10 is used to extract at least one compression strategy analysis task corresponding to each of the at least one subset of map data from the compression strategy analysis task based on the allocation reference information in the compression strategy analysis task, so as to obtain at least one subtask.

[0047] In some embodiments, the subtask includes: address indication information for each piece of graph data in the graph data subset.

[0048] In some embodiments, at least one subset of graph data is a subset of graph data, and correspondingly, at least one subtask is a subtask that analyzes the compression strategy of the subset of graph data. In some embodiments, this subset of graph data is a coordinate graph data subset. The graph data in the coordinate graph data subset is used to indicate the coordinate values ​​of the graph elements. For example, in the graph data subset, all x-coordinate values, y-coordinate values, and z-coordinate values ​​belong to the coordinate graph data subset.

[0049] In some embodiments, at least one subset of graph data is multiple subsets of graph data; correspondingly, at least one subtask is multiple subtasks, and the multiple subtasks are compression strategy analysis tasks corresponding to the multiple subsets of graph data respectively. In some embodiments, the multiple subsets of graph data include a coordinate graph data subset and at least two attribute graph data subsets.

[0050] The graph data in the attribute graph data subset is used to indicate the attributes of graph elements, and the graph data in any two different attribute graph data subsets indicate different attribute types.

[0051] For example, one subset of attribute graph data includes all R, G, B, and u values ​​in the graph data set, and the other subset includes all v and n values ​​in the graph data set. x value, n y value and n z value.

[0052] In some embodiments, the scheduling module 10 is configured to extract compression strategy analysis tasks corresponding to multiple subsets of graph data from the graph metadata dataset compression strategy analysis task according to the byte limit value, so as to obtain multiple subtasks.

[0053] The byte limit value is used to restrict the sum of the standard byte counts of each graph data type corresponding to a subset of graph data data. In other words, the sum of the standard byte counts of each graph data type corresponding to a subset of graph data data is less than or equal to the byte limit value.

[0054] The graph data type corresponding to a subset of graph data refers to the graph data type to which at least one graph data element in the subset belongs. For example, if a subset of graph data includes several x-coordinate values, several y-coordinate values, and several z-coordinate values, then the subset of graph data can be considered to correspond to three graph data types: "x-coordinate value", "y-coordinate value", and "z-coordinate value".

[0055] In some embodiments, the above-mentioned byte limit value is equal to the maximum number of bytes belonging to different byte planes that a single analysis path supports parallel processing; that is, it is equal to the number of byte analysis paths included in a single analysis path, as described below. For specific descriptions of byte planes and byte analysis paths, please refer to the embodiments below, which will not be repeated here.

[0056] In some embodiments, a subset of coordinate graph metadata corresponds to multiple graph metadata types, and the graph metadata belonging to different graph metadata types in the subset of coordinate graph metadata indicates different coordinate value types. Each subset of attribute graph metadata corresponds to at least one graph metadata type, and the graph metadata belonging to different graph metadata types in the subset of attribute graph metadata indicates different attribute types.

[0057] For example, if the primitive dataset includes three types of coordinate values ​​(x, y, and z) and 30 types of attributes (attribute 1 to attribute 30), then each coordinate value and each attribute can be considered as a type of primitive data. There are a total of 30 + 3 = 33 types of primitive data. The standard byte count for x-coordinate values ​​is 3, for y-coordinate values ​​it is 3, for z-coordinate values ​​it is 4, and for each attribute it is 4. Therefore, the scheduling module 10, according to the byte limit of 32, extracts five subsets of primitive data from the primitive dataset's compression strategy analysis task, corresponding to compression strategy analysis tasks, to obtain five subtasks. These five subsets of graph data include one subset of coordinate graph data and four subsets of attribute graph data. The coordinate graph data subset corresponds to graph data types such as coordinate values ​​x, y, and z, and their total standard byte count is 3 + 3 + 4 = 10. The first subset of the four attribute graph data subsets corresponds to graph data types such as attributes 1-8, and their total standard byte count is 32. The second subset corresponds to graph data types such as attributes 9-16, and their total standard byte count is 32. The third subset corresponds to graph data types such as attributes 17-24, and their total standard byte count is 32. The fourth subset corresponds to graph data types such as attributes 25-30, and their total standard byte count is 24. Although the total standard byte count in this case is less than 32, it is still considered a subset of attribute graph data.

[0058] It should be noted that in the above examples, the standard byte count for different attributes is 4. This is only for illustrative purposes. The standard byte count for different image data types can be the same or different, and this application does not limit this.

[0059] In the above embodiment, the scheduling module 10 breaks down the complete compression strategy analysis task into multiple subtasks corresponding to multiple subsets of graph data. These subsets include a coordinate graph data subset and at least two attribute graph data subsets. On one hand, this allows for task-level parallel processing of coordinate data and attribute data within the data processing device 100, thereby improving the throughput of the compression strategy analysis process. On the other hand, since the graph data in different attribute graph data subsets indicates different attribute classes, the above scheme ensures that different subtasks are always performed on bytes belonging to different byte planes, thus guaranteeing the logical integrity from task scheduling to the output of the compression strategy corresponding to a single byte plane.

[0060] The coordinate data mentioned above refers to the graphic element data used to indicate the coordinate values ​​of the graphic element, and the attribute data refers to the graphic element data used to indicate the attribute values ​​of the graphic element.

[0061] The scheduling module 10 is also used to output at least one subtask to the analysis path 20.

[0062] One of the subtasks is output to an analysis path.

[0063] In some embodiments, at least one subtask is a single subtask, which outputs one of multiple analysis paths. This analysis path can be a preset analysis path or any one of the multiple analysis paths; this application does not limit the specific analysis path.

[0064] In some embodiments, at least one subtask may be multiple subtasks, and at least two of the multiple subtasks may be output to different analysis paths.

[0065] The target analysis path in the multiple analysis paths 20 is used to read the graph data subset corresponding to the target subtask when receiving at least one target subtask in the subtask, and to generate a compression strategy for the graph data subset corresponding to the target subtask.

[0066] The compression strategy for the graph data subset corresponding to the target subtask is used to compress the graph data subset corresponding to the target subtask.

[0067] The target analysis path can be any one of the multiple analysis paths 20, and the target subtask can be any one of at least one subtask. In the embodiments of this application, for any analysis path that receives a subtask, the way it processes the subtask can refer to the way the target analysis path processes the target subtask, and this application will not elaborate further on this.

[0068] The compression strategies of at least one subset of graph metadata generated by the processing of at least one subtask mentioned above in analysis path 20 constitute the compression strategy of the graph metadata dataset.

[0069] Furthermore, as can be seen from the above embodiments, since the above subtask is first used to trigger the reading of a subset of graph data, the above subtask can also be called a "read task".

[0070] The technical solution provided in this application embodiment designs a scheduling module and multiple analysis paths in a data processing device. The scheduling module is responsible for transforming the compression strategy analysis task of the entire primitive dataset into subtasks assigned to the corresponding analysis paths. Each analysis path can independently read the primitive data subset corresponding to the subtask it receives and generate the corresponding compression strategy. In the above solution, when the scheduling module extracts multiple subtasks from the complete task, since at least two subtasks are output to different analysis paths, and different analysis paths can independently read data and process data in parallel, the total read bandwidth of the storage unit used to store the primitive dataset remains unchanged. Because multiple analysis paths work in parallel, this solution increases the total amount of data that the analysis paths can process per unit time, thereby improving the utilization rate of read bandwidth.

[0071] In addition, it should be noted that the above-mentioned data processing device 100 has strong hardware scalability. Specifically, the number of analysis paths 20 it includes can be flexibly expanded according to different read bandwidth scenarios. In different read bandwidth scenarios, the storage unit supports providing different read bandwidths. The larger the read bandwidth supported by the storage unit, the more analysis paths can be added accordingly. This application does not limit this.

[0072] In the following embodiments, a more detailed explanation will be given of how the scheduling module 10 assigns multiple subtasks to the analysis path 20.

[0073] In some embodiments, the scheduling module 10 is used to output multiple subtasks to the analysis path according to the bandwidth requirements of each subtask.

[0074] The bandwidth requirement of the subtask reflects the read bandwidth requirement of the storage unit for executing the subtask. The storage unit is used to store the primitive dataset.

[0075] The read bandwidth of a storage unit is the bandwidth for reading data from the storage unit. In some embodiments, the analysis path 20 is directly connected to the storage unit; therefore, the analysis path 20 supports sending read requests directly to the storage unit and receiving a subset of map data elements returned by the storage unit. In other embodiments, the analysis path 20 is indirectly connected to the storage unit through a request processing unit, which forwards read requests to the storage unit and returns a subset of map data elements read from the storage unit to the analysis path 20. For a detailed description of the request processing unit, please refer to the embodiments below; it will not be repeated here.

[0076] In some embodiments, the bandwidth requirement of a subtask is positively correlated with the read bandwidth requirement of the storage unit for executing the subtask. In other embodiments, the bandwidth requirement of a subtask is negatively correlated with the read bandwidth requirement of the storage unit for executing the subtask.

[0077] In the above embodiment, the scheduling module 10 allocates subtasks based on the bandwidth requirements of different subtasks, thereby maximizing the overall utilization of the storage unit read bandwidth by the data processing device 100. The implementation principle of this effect will be explained in the following embodiment.

[0078] In some embodiments, the data processing device 100 includes M analysis paths, meaning the number of analysis paths 20 in the data processing device 100 is M, where M is an integer greater than 1. The scheduling module 10 is used to implement the following steps: 1. Arrange the multiple subtasks into a subtask queue based on their respective bandwidth requirements.

[0079] In some embodiments, multiple subtasks are arranged into a subtask queue according to the bandwidth requirement values ​​from low to high / from high to low.

[0080] For example, suppose there are five subtasks: subtask 1, subtask 2, subtask 3, subtask 4, and subtask 5. The bandwidth requirement of subtask 1 is 1 / 2, the bandwidth requirements of subtask 2 and subtask 3 are 1 / 4, the bandwidth requirement of subtask 4 is 1 / 3, and the bandwidth requirement of subtask 5 is 1 / 8. Then the subtask queue is [subtask 5, subtask 2, subtask 3, subtask 4, subtask 1].

[0081] 2. If the i-th analysis path out of the M analysis paths is idle, take a subtask from one end of the subtask queue and output it to the i-th analysis path, where i is a positive integer less than M.

[0082] In some embodiments, upon receiving an idle signal from the i-th analysis path, a subtask is taken from one end of the subtask queue and output to the i-th analysis path.

[0083] An idle signal sent by the analysis path is used to indicate that the sub-path is idle.

[0084] Once a subtask is taken out of the task queue, it is removed from the task queue. In other words, for every subtask output by the scheduling module 10, one subtask is removed from the task queue.

[0085] 3. If the (i+1)th analysis path in the M analysis paths is idle, take a subtask from the other end of the subtask queue and output it to the (i+1)th analysis path.

[0086] In some embodiments, upon receiving an idle signal from the (i+1)th analysis path, a subtask is taken from the other end of the subtask queue and output to the (i+1)th analysis path.

[0087] For example, assuming M=4, and the M analysis paths are analysis path A, analysis path B, analysis path C, and analysis path D. After the scheduling module 10 splits the subtasks 1-5 from the strategy analysis task and arranges them into the subtask queue, it outputs subtask 5 (the leftmost end of the queue) to analysis path A and subtask 1 (the rightmost end of the queue) to analysis path B. At this point, the subtask queue becomes [subtask 2, subtask 3, subtask 4]. Since analysis paths C and D are also idle, the scheduling module 10 outputs subtask 2 (the leftmost end of the queue) to analysis path C and subtask 4 (the rightmost end of the queue) to analysis path D. Now, only subtask 3 remains in the queue. The scheduling module 10 then outputs the remaining subtask 3 to any one of the four analysis paths to obtain an idle allocation path. Through this process, the allocation of the five subtasks to the four analysis paths is completed.

[0088] For example, assuming M=2, and the M analysis paths are analysis path A and analysis path B, the scheduling module 10, after splitting subtasks 1-5 from the strategy analysis task and arranging them into the subtask queue, outputs subtask 5 (the leftmost end of the subtask queue) to analysis path A and subtask 1 (the rightmost end of the subtask queue) to analysis path B. At this time, the subtask queue becomes [subtask 2, subtask 3, subtask 4]. After subtask 4 is processed in analysis path A, analysis path A becomes idle, so the scheduling module 10 takes subtask 2 (the leftmost end of the subtask queue) and outputs it to analysis path A. After subtask 1 is processed in analysis path B, analysis path B becomes idle, so the scheduling module 10 takes subtask 4 (the rightmost end of the subtask queue) and outputs it to analysis path B. At this time, only subtask 3 remains in the subtask queue. In this case, after subtask 2 is processed in analysis path A, the scheduling module 10 outputs the remaining subtask 3 to analysis path A. Alternatively, after analysis path B finishes processing subtask 4, scheduling module 10 outputs the remaining subtask 3 to analysis path B. Through this process, the allocation of the five subtasks to the two analysis paths is completed.

[0089] In the above embodiment, subtasks are taken from both ends of the subtask queue arranged according to bandwidth requirements and assigned to the i-th and (i+1)-th analysis paths in the data processing device 100, respectively. This ensures that the data processing device has a balanced read bandwidth requirement at different times, thereby ensuring the rational utilization of the read bandwidth of the storage unit. For example, if there are many subtasks, such as 10 subtasks, and multiple analysis paths all take subtasks from the left end of the task queue, that is, from subtasks with low bandwidth requirements to subtasks with high bandwidth requirements, it will result in that in the early stage of the compression strategy analysis task, the read bandwidth requirement of all analysis paths executing subtasks is too low, and the read bandwidth provided by the storage unit cannot be fully utilized. In the late stage of the compression strategy analysis task, using the above allocation method, since the subtasks with low bandwidth requirements have all been taken from the task queue, all analysis paths executing subtasks will be assigned to subtasks with high bandwidth requirements, which will bring a large load to the storage unit.

[0090] For example, please refer to Figure 2 This document illustrates a flowchart of a task scheduling process performed by a scheduling module 10 according to an embodiment of this application. Taking M=2 as an example, the task scheduling process includes at least one of the following steps 210-250.

[0091] Step 210: Receive the task of analyzing the compression strategy of the primitive dataset.

[0092] Step 220: Divide the compression strategy analysis task into N sub-tasks and determine the bandwidth requirements of each of the N sub-tasks, where N is a positive integer.

[0093] Step 230: Determine if N is greater than 1. If yes, proceed to step 240; otherwise, directly assign one subtask to one of the two analysis paths.

[0094] Step 240: Arrange the N subtasks into a subtask queue according to their bandwidth requirements, either from smallest to largest or from largest to smallest.

[0095] Step 250: When one of the two analysis paths is idle, take a subtask from one end of the subtask queue, assign it to that analysis path, and delete the subtask from the subtask queue; when the other analysis path is idle, take a subtask from the other end of the subtask queue, assign it to that analysis path, and delete the subtask from the task queue; repeat the above process until the subtask queue is empty.

[0096] The following section will provide a further explanation of how the bandwidth requirements for subtasks are calculated.

[0097] In some embodiments, the scheduling module 10 is further configured to determine the bandwidth requirement value of each of the multiple subtasks based on the maximum number of bytes corresponding to the multiple data subsets respectively. The maximum number of bytes corresponding to the data subset refers to the maximum number of bytes belonging to the same byte plane among the bytes of each data contained in the data subset.

[0098] Among them, the different bytes belonging to the same byte plane correspond to the same type of graphic data, which are used to indicate the same type of attribute or the same type of coordinate value of graphic elements, and the different bytes belonging to the same byte plane have a corresponding relationship in the position of the corresponding graphic data.

[0099] The metadata corresponding to a byte refers to the metadata containing that byte. For example, for the metadata containing the x-coordinate value of a certain element, each byte included in that x-coordinate value corresponds to that x-coordinate value.

[0100] Different graphic element data of the same type of attribute or the same type of coordinate value can be regarded as belonging to the same graphic element data type.

[0101] The above rules for dividing the byte plane can be understood using the following example: For example, all x-coordinate values ​​in the image data set can be regarded as the same type of coordinate values. When the x-coordinate value has 3 bytes, the first byte of all x-coordinate values ​​can be considered to belong to one byte plane, the second byte of all x-coordinate values ​​can be considered to belong to another byte plane, and the third byte of all x-coordinate values ​​can be considered to belong to yet another byte plane.

[0102] For example, all R values ​​in the graph data set can be considered as the same type of attribute. If the R value type of attribute has two bytes, the first byte of all R values ​​can be considered to belong to one byte plane, and the second byte of all R values ​​can be considered to belong to another byte plane.

[0103] In some embodiments, the bandwidth requirement value corresponding to the subtask is positively correlated with the read bandwidth requirement of the storage unit for executing the subtask, and correspondingly, the bandwidth requirement value corresponding to the subtask is negatively correlated with the maximum number of bytes corresponding to the graph data subset corresponding to the subtask.

[0104] In some embodiments, the scheduling module 10 is used to take the reciprocal of the maximum number of bytes corresponding to the multiple subsets of graph data as the required bandwidth value of each of the multiple subtasks.

[0105] For example, if a subset of graph data corresponds to four graph data types (attributes 1 to 4), where the standard byte count for attributes 1 to 3 is 2 and the standard byte count for attribute 4 is 4, then the graph data in this subset belongs to 10 byte planes. In this case, if the subset includes three different attributes 1, two different attributes 2, two different attributes 3, and two different attributes 4, then the byte count in each of the two byte planes corresponding to attribute 1 is 3, the byte count in each of the two byte planes corresponding to attribute 2 is 2, the byte count in each of the two byte planes corresponding to attribute 3 is 2, and the byte count in each of the four byte planes corresponding to attribute 4 is 2. Therefore, the maximum byte count for this subset of graph data is 3, and the bandwidth requirement for the subtask corresponding to this subset is 1 / 3.

[0106] In the above embodiment, a new method for calculating bandwidth requirements is provided. This method directly uses the maximum number of bytes belonging to the same byte plane among the bytes included in the subset of graph data to be analyzed to quantify the read bandwidth requirements of the subtask. When the analysis path serially processes bytes in the same byte plane, it can accurately and simply measure the data reading requirements of the analysis path when processing the subtask. On the one hand, the implementation logic is simple and the complexity is low; on the other hand, it ensures the reasonable allocation of multiple subtasks by the scheduling module 10.

[0107] In the embodiments described below, the process of processing target subtasks using the target analysis path will be used as an example to provide a more detailed description of the structure and function of the analysis path. It should be noted that the structure and function of any analysis path can be referenced from the structure and function of the target analysis path described below, and this application will not repeat them here.

[0108] In some embodiments, please refer to Figure 3 The data processing device 100 also includes a request processing unit 30, and the target analysis path includes a read module 21 and a data processing unit 22.

[0109] The input end of the target analysis path is the input end of the reading module 21. Therefore, the output end of the scheduling module 10 is connected to the input end of the reading module 21, and the output end of the scheduling module 10 is connected to the input end of the reading module 21 included in each of the multiple analysis paths 20.

[0110] The output of the read module 21 is connected to the input of the request processing unit 30, and the output of the read module 21 included in each of the multiple analysis paths 20 is connected to the input of the request processing unit 30.

[0111] The output of the request processing unit 30 is connected to the input of the data processing unit 22, and the output of the request processing unit 30 is connected to the input of the data processing unit 22 included in each of the multiple analysis paths.

[0112] The read module 21 is used to send a target read request to the request processing unit when a target subtask is received. The target read request is a read request for the subset of graph data corresponding to the target subtask.

[0113] For the sake of simplicity, the subset of graph data corresponding to the target subtask will be referred to as the target graph data subset.

[0114] In some embodiments, the read module 21 is configured to, upon receiving a target subtask, determine, based on the target subtask, such as address indication information included in the target subtask, the address of each piece of graph data in the storage unit within the target graph data subset; and send a target read request carrying the aforementioned address to the request processing unit.

[0115] In some embodiments, the address indication information included in the target subtask is the address of the graph data in the target graph data subset in the storage unit. Therefore, the read module 21 can directly obtain the above address from the target subtask.

[0116] In other embodiments, the address indication information included in the target subtask has a mapping relationship with the address of the graph data in the graph data subset in the storage unit. Therefore, the read module 21 can calculate the above address based on the address indication information included in the target subtask.

[0117] In some embodiments, the reading module 21 is further configured to send an idle signal to the scheduling module 10 when the target analysis path is detected to be idle.

[0118] The request processing unit 30 is used to return the subset of graph data corresponding to the target subtask to the data processing unit 22.

[0119] In some embodiments, the request processing unit 30 is configured to return a subset of graph data corresponding to the target subtask to the data processing unit 22 upon receiving a target read request.

[0120] In some embodiments, the request processing unit 30 is configured to forward the target read request to the storage unit upon receiving a target read request, and return a subset of the target image data returned by the storage unit to the data processing unit 22.

[0121] In some embodiments, the request processing unit 30 is connected to the storage unit.

[0122] In some embodiments, the request processing unit 30 is configured to, when receiving multiple read requests simultaneously, forward the multiple read requests to the storage unit in sequence according to the priority of the type of the subset of graph data that each read request targets, wherein the multiple read requests include a target read request.

[0123] Multiple read requests are sent by different read modules within different analysis paths. The subset of graph data that a read request targets is the subset of graph data that the read request wants to read.

[0124] For example, request processing unit 30 receives three read requests simultaneously. The first read request is sent by the read module included in analysis path A, the second read request is sent by the read module included in analysis path B, and the third read request is sent by the read module included in analysis path C. If the subset of graph data data targeted by the first read request belongs to type a, the subset of graph data data targeted by the second read request belongs to type b, and the subset of graph data data targeted by the third read request belongs to type c, and type b has a higher priority than type a, and type a has a higher priority than type c, then request processing unit 30 forwards the second read request to the storage unit first, then forwards the first read request, and finally forwards the third read request.

[0125] The priority of the type of map data subset is used to reflect the priority of processing this type of map data subset. It can be configured as needed by technicians, and this application does not limit it.

[0126] In the above embodiment, a unified request processing unit 30 is configured to relay read requests from read modules from different analysis paths. On the one hand, this can save hardware costs; on the other hand, the request processing unit 30 can determine the priority of the read requests based on the type of the subset of graph data to be read, ensuring the orderliness of access to the storage unit and avoiding processing logic confusion due to receiving multiple read requests at the same time.

[0127] In some embodiments, the types of the map data subset include a coordinate map data subset and an attribute map data subset. The map data in the coordinate map data subset is used to indicate the coordinate values ​​of the map element, and the map data in the attribute map data subset is used to indicate the attributes of the map element.

[0128] Among them, the priority of the coordinate graph data subset is higher than that of the attribute graph data subset.

[0129] For example, the request processing unit 30 receives two read requests simultaneously. The first read request is sent by the read module included in analysis path A, and the second read request is sent by the read module included in analysis path B. If the subset of graph data data targeted by the first read request belongs to the coordinate graph data data subset, and the subset of graph data data targeted by the second read request belongs to the attribute graph data data subset, then the request processing unit 30 first forwards the first read request to the storage unit, and then forwards the second read request.

[0130] In the above embodiment, by configuring the priority of the coordinate graph data subset to be higher than the priority of the attribute graph data subset, the coordinate data of each graph element in the graph data subset will be processed first and a corresponding compression strategy will be generated, thereby facilitating the subsequent compression encoding module to perform the compression task.

[0131] It should be noted that in the above embodiments, the graph data subset is divided into two types: coordinate graph data subset and attribute graph data subset. This type division method is only an example of this application. In practical applications, those skilled in the art can divide the graph data subset into more or fewer types according to their needs and configure the priorities accordingly. This application does not limit this. For example, those skilled in the art can divide the graph data subset into different types according to the graph data type corresponding to the graph data subset. For example, for 30 graph data types such as attribute 1 to attribute 30, the graph data subset corresponding to attribute 1 to 8 can be divided into one type, the graph data subset corresponding to attribute 9 to 16 can be divided into one type, the graph data subset corresponding to attribute 17 to 24 can be divided into one type, and the graph data subset corresponding to attribute 25 to 30 can be divided into one type.

[0132] In some embodiments, the request processing unit 30 is further configured to record the sending source of the target read request as the target analysis path after forwarding the target read request to the storage unit.

[0133] In some embodiments, the request processing unit 30 includes a request source cache queue. The request processing unit is configured to record the sending source of the target read request as the target analysis path in the request source cache queue after forwarding the target read request to the storage unit.

[0134] In some embodiments, the request processing unit 30 records the target analysis path by recording the identification information of the target analysis path. The identification information of the target analysis path is used to indicate the target analysis path, and different analysis paths have different identification information.

[0135] In some embodiments, the request processing unit 30 records the identification information of the target read request and the target analysis path in the request source cache queue, such as recording them in the same entry in the request source cache queue.

[0136] In some embodiments, the depth of the request source queue is the depth of the subtask queue, that is, the maximum number of sending sources that support read requests for records in the request source queue is equal to the maximum number of subtasks that support records in the subtask queue.

[0137] In some embodiments, the depth of the request source cache queue is equal to the number of analysis paths 20, that is, the maximum number of sending sources that support read requests for records in the request source cache queue is equal to the number of analysis paths 20 in the data processing device 100.

[0138] The request processing unit 30 is used to return the subset of graph data corresponding to the target subtask to the data processing unit in the target analysis path according to the sending source of the recorded target read request.

[0139] In some embodiments, the request processing unit 30 is further configured to delete the sending source of the target read request recorded in the request source cache queue after returning the subset of graph data corresponding to the target subtask to the data processing unit in the target analysis path.

[0140] In some embodiments, the request source cache queue is a FIFO queue. The request processing unit 30 is used to return a subset of the graph data corresponding to the target subtask to the data processing unit in the target analysis path based on the earliest recorded sending source in the request source cache queue. It also deletes the earliest recorded sending source from the request source cache queue.

[0141] In the above embodiment, the request processing unit 30 records the source of the read request it receives. Therefore, even if it is responsible for relaying read requests sent by read modules in multiple analysis paths, it can ensure that the read data is accurately returned to the corresponding analysis path.

[0142] The data processing unit 22 is used to generate a compression strategy for the graph data subset corresponding to the target subtask.

[0143] In some embodiments, the data processing unit 22 is used to generate a compression strategy for the graph data subset corresponding to the target subtask based on the graph data subset corresponding to the target subtask.

[0144] In the above embodiments, each analysis path has an independent read module. Therefore, each analysis path supports the independent generation and sending of read requests. For example, when the number of analysis paths 20 is 2, the data processing device 100 supports initiating two read requests at the same time, thereby making fuller use of the read bandwidth of the storage unit.

[0145] In the following embodiments, the structure and function of the data processing unit 22 will be described in more detail using the process of the data processing unit 22 processing a subset of target map data in the target analysis path as an example. It should be noted that the structure and function of the data processing unit 22 in any analysis path can refer to the structure and function of the data processing unit 22 described below, and this application will not repeat them here.

[0146] In some embodiments, please refer to Figure 4 The data processing unit 22 includes an allocation module 23 and multiple byte analysis paths 24.

[0147] The input terminal of the data processing unit 22 is also the input terminal of the allocation module 23. Therefore, the output terminal of the request processing unit 30 is connected to the input terminal of the allocation module 23, and the output terminal of the request processing unit 30 is connected to the input terminal of the allocation module 23 included in each of the multiple analysis paths 20.

[0148] The output of the allocation module 23 is connected to the input of multiple byte analysis paths 24.

[0149] The allocation module 23 is used to split the subset of graph data corresponding to the target subtask into multiple bytes.

[0150] Multiple bytes can be divided into multiple byte groups. Bytes in the same byte group belong to the same byte plane, while bytes in different byte groups belong to different byte planes.

[0151] For example, multiple bytes can be divided into P byte groups, where the bytes in the j-th byte group of the P byte groups belong to the j-th byte plane of the P byte plane, where P is an integer less than or equal to M.

[0152] The allocation module 23 is also used to send multiple bytes to multiple byte analysis paths, wherein bytes belonging to the same byte group are sent to the same byte analysis path, and bytes belonging to different byte groups are sent to different byte analysis paths.

[0153] For example, the allocation module 23 is further configured to send multiple bytes to P byte analysis paths among multiple byte analysis paths, wherein bytes belonging to the j-th byte plane are sent to the j-th byte analysis path among the P byte analysis paths.

[0154] In some embodiments, the allocation module 23 is configured to send multiple bytes to multiple byte analysis paths according to their respective plane identifiers, wherein bytes with the same plane identifier are sent to the same byte analysis path, and bytes with different plane identifiers are sent to different byte analysis paths.

[0155] The plane identifier of a byte is used to indicate the byte plane to which the byte belongs. In some embodiments, the output of the read module 21 is connected to the input of the allocation module 23. Therefore, the read module 21 can also be used to send the plane identifiers of multiple bytes to the allocation module 23. The plane identifier of a byte can be generated by the read module 21 or by the scheduling module 10, and can also be attached to the compression strategy analysis task received by the scheduling module 10. This application does not limit this.

[0156] The target byte analysis path in the multiple byte analysis path 24 is used to generate a compression strategy for the target byte group when a byte belonging to the target byte group in multiple byte groups is received. The compression strategy of the graph data subset corresponding to the target subtask includes the compression strategies of each of the multiple byte groups.

[0157] The compression strategy for a byte group is used to compress the bytes within that byte group. The compression strategy for the target byte group is used to compress the bytes within that target byte group.

[0158] The target byte group can be any one of the above-mentioned byte groups; this application only uses the target byte group as an example.

[0159] In some embodiments, the target byte analysis path is used to generate a compression strategy for the target byte group based on the bytes in the target byte group.

[0160] In some embodiments, multiple byte analysis paths are used to generate compression strategies for multiple byte groups, wherein one byte analysis path is used to generate a compression strategy for one byte group, and different byte analysis paths are used to generate compression strategies for different byte groups.

[0161] For example, the j-th byte analysis path in the P byte analysis paths is used to generate the compression strategy for the j-th byte group in the P byte groups.

[0162] In some embodiments, multiple byte analysis paths are used to generate compression strategies for multiple byte groups in parallel. P byte analysis paths are used to generate compression strategies for P byte groups in parallel.

[0163] In the above embodiment, the data processing unit 22 is provided with multiple byte analysis paths 24 and an allocation module 23 for allocating bytes in the received target image data subset to different byte analysis paths according to their respective byte planes. This enables the data processing unit 22 to support parallel processing of bytes belonging to different byte planes to generate compression strategies for corresponding byte groups, ensuring the throughput of a single data processing unit 22, and thus ensuring the throughput of the entire data processing device 100.

[0164] In the embodiments described below, the process of processing bytes in a target byte group using the target byte analysis path will be used as an example to provide a more detailed description of the structure and function of the byte analysis path. It should be noted that the structure and function of any byte analysis path can be referenced from the structure and function of the target byte analysis path described below, and this application will not repeat them here.

[0165] In some embodiments, please refer to Figure 5 The target byte analysis path includes cache queue 241 and analysis module 242.

[0166] The input of the target byte analysis path is the input of the cache queue 241. Therefore, the output of the allocation module 23 is connected to the input of the cache queue 241, and the output of the allocation module 23 is connected to the input of the cache queue 241 included in each of the multiple byte analysis paths 24.

[0167] The output of the buffer queue 241 is connected to the input of the analysis module 242.

[0168] Cache queue 241 is used to store bytes belonging to the target byte group.

[0169] In some embodiments, please refer to Figure 5 The buffer queue 241 is a first-in-first-out (FIFO) queue, and within the same clock cycle, the buffer queue 241 supports input of multiple bytes and output of 1 byte.

[0170] The aforementioned clock cycle refers to the clock cycle during which the analysis module 242 processes one byte.

[0171] In some embodiments, the cache queue 241 is used to output the byte that was first written into the cache queue 241 from the various bytes stored in the cache queue 241.

[0172] In the above embodiment, the cache queue 241 is a FIFO queue that supports a greater number of input bytes than the number of output bytes within the same clock cycle. On the one hand, it ensures that regardless of the method and order in which the allocation module 23 inputs bytes from the target byte group to the cache queue 241, the cache queue 241 can output bytes to the analysis module 242 with a relatively stable timing. On the other hand, it ensures that when the analysis module 242 processes bytes serially, the cache queue 241 can temporarily store bytes sent by the allocation module 23 that the analysis module 242 has not yet had time to process. Therefore, when multiple analysis paths 20 process subtasks in parallel, the FIFO queue included in each analysis path 20 can serve to cache bytes serially input to the analysis module 242, thereby reducing the bandwidth waste caused by waiting for serial input as described above. For example, taking the example that each read data contains 3 bytes from the same byte plane, using the above scheme, when two analysis paths are in parallel, the utilization rate of the storage unit throughput increases from 1 / 3 to 2 / 3.

[0173] In some embodiments, the read module 21 determines whether the target analysis path is idle by detecting whether each cache queue 241 in the target analysis path it is located in is idle. For example, the read module 21 synchronously records the number of occupied entries or the number of remaining entries in each cache queue 241 in the target analysis path. One entry is used to cache one byte. If the recorded number of entries meets the set conditions, it determines that the target analysis path it is located in is idle. The above-mentioned set conditions are set by the technicians as needed, such as the number of occupied entries being less than a certain threshold, the number of remaining entries being greater than a certain threshold, etc. This application does not limit this.

[0174] The analysis module 242 is used to generate a compression strategy for the target byte group based on the bytes output by the cache queue 241.

[0175] In some embodiments, the analysis module 242 is used to determine the numerical range information corresponding to the target byte group based on the bytes output by the cache queue 241, and use the numerical range information corresponding to the target byte group as the compression strategy of the target byte group.

[0176] In the above embodiment, the cache queue 241 and the analysis module 242 are used to form a byte analysis path. The existence of the cache queue 241 provides an intermediate cache device for the allocation module 23 to perform unified allocation of byte groups and for the analysis module 242 to serially process individual bytes. This ensures the correctness and stability of the process from byte allocation to byte processing while avoiding byte loss.

[0177] In some embodiments, the analysis module 242 is used to adjust the numerical range information corresponding to the target byte group according to the bytes output by the cache queue 241. The numerical range corresponding to the target byte group is used to indicate the numerical range of bytes in the target byte group.

[0178] In some embodiments, the initial range of the numerical range indicated by the numerical range information corresponding to the target byte group is pre-configured, such as [0,0].

[0179] In some embodiments, the analysis module is used to adjust the maximum value of the numerical range indicated by the numerical range information to the value of the byte output by the cache queue when the value of the byte output by the cache queue is greater than the maximum value of the numerical range indicated by the numerical range information; or, when the value of the byte output by the cache queue is less than the minimum value of the numerical range indicated by the numerical range information, adjust the minimum value of the numerical range indicated by the numerical range information to the value of the byte output by the cache queue.

[0180] In some embodiments, the analysis module 242 records numerical range information by recording the maximum and minimum values ​​of the bytes in the target byte group, that is, the numerical range information includes the maximum and minimum values ​​of the bytes in the target byte group.

[0181] For example, the analysis module 242 compares the value of the byte output by the cache queue 241 with its own recorded maximum and minimum values. If the byte is greater than the maximum value, the maximum value is updated to the value of the byte, while the minimum value remains unchanged. If the byte is less than or equal to the maximum value and greater than or equal to the minimum value, both the maximum and minimum values ​​remain unchanged. If the byte is less than the minimum value, the minimum value is updated to the value of the byte.

[0182] In some embodiments, the analysis module 242 records numerical range information by recording the minimum value and range of bytes in the target byte group. That is, the numerical range information includes the minimum value and range of bytes in the target byte group. The range of bytes in the target byte group refers to the difference between the maximum value and the minimum value of bytes in the target byte group.

[0183] For example, the analysis module 242 compares the value of the byte output by the cache queue 241 with the minimum value and the first numerical sum recorded by itself, where the first numerical sum is the sum of the minimum value and the range recorded by the analysis module 222. If the byte is greater than the first numerical sum, the range is updated to the difference between the byte value and the minimum value. If the byte is less than or equal to the first numerical sum and greater than or equal to the minimum value, the minimum value and the range remain unchanged. If the byte is less than the minimum value, the minimum value is updated to the value of the byte.

[0184] In some embodiments, the analysis module 242 records numerical range information by recording the maximum value and range of bytes in the target byte group, that is, the numerical range information includes the maximum value and range of bytes in the target byte group.

[0185] For example, the analysis module 242 compares the value of the byte output by the cache queue 241 with its own recorded maximum value and a first numerical difference, where the first numerical difference is the difference obtained by subtracting the range from the maximum value recorded by the analysis module 222. If the byte is greater than the maximum value, the maximum value is updated to the value of the byte, while keeping the range unchanged. If the byte is less than or equal to the maximum value and greater than or equal to the first numerical difference, the maximum value and the range remain unchanged. If the byte is less than the first numerical difference, the range is updated to the difference between the maximum value and the value of the byte.

[0186] The analysis module 242 is used to adjust the numerical range information corresponding to the target byte group based on the last byte in the target byte group, and then output the numerical range information corresponding to the target byte group as the compression strategy of the target byte group.

[0187] In some embodiments, the analysis module 242 is configured to, upon receiving a byte accompanied by an end marker, adjust the numerical range information corresponding to the target byte group according to the byte, and output the numerical range information corresponding to the target byte group as the compression strategy of the target byte group.

[0188] An end marker is used to indicate that the byte it accompanies is the last byte in a byte group. In some embodiments, the end marker is generated by the allocation module 23. In some embodiments, the allocation module 23 is used to synchronously send the end marker when sending the last byte in the target byte group to the target byte analysis path.

[0189] In the above embodiment, the analysis module 242 continuously adjusts the numerical range information corresponding to the target byte group based on the serially input bytes until the last byte is processed, and then outputs the compression strategy of the target byte group. This provides a relatively simple method for generating compression strategies. This process only requires simple functions such as value substitution, comparison, and storage, and can be implemented with only a small number of registers, logic devices, and comparators, thereby simplifying the hardware complexity of the analysis module 242.

[0190] In some embodiments, the sum of the standard bytes of each graph metadata type corresponding to a subset of graph metadata is less than or equal to the number of byte analysis paths included in each analysis path.

[0191] For details regarding the graph data type corresponding to the subset of graph data and the standard byte count, please refer to the above embodiment; they will not be repeated here.

[0192] This embodiment uses the number of byte analysis paths included in the analysis path as the criterion for dividing the graph data subset, that is, the allocation criterion for subtasks, thereby ensuring that the subtasks received by the analysis path meet its hardware processing capabilities. In other words, it ensures that the number of bytes belonging to different byte planes that need to be processed in parallel by an analysis path does not exceed the number of byte analysis paths it contains.

[0193] In some embodiments, the number of byte analysis paths included in each of the multiple analysis paths is the same.

[0194] For example, each of the multiple analysis paths includes 32 byte analysis paths, thereby supporting parallel processing of bytes belonging to a 32-byte plane.

[0195] In some embodiments, the number of byte analysis paths included in the analysis path is the byte limit value described above, which is used to limit the sum of the standard byte counts of each graph metadata type corresponding to a subset of graph metadata.

[0196] In the above embodiment, the number of byte analysis paths included in different analysis paths in the data processing device 100 is the same. On the one hand, this is beneficial for the scheduling module 10 to allocate subtasks according to a unified standard. On the other hand, since the structures of different analysis paths are completely consistent, the design complexity of expanding the number of analysis paths 20 in the data processing device 100 is simplified.

[0197] The following example illustrates the compression strategy for generating a primitive dataset using the data processing apparatus 100 provided in this application. This example uses a data processing apparatus comprising two analysis paths: a first analysis path and a second analysis path.

[0198] For example, please refer to Figure 6 In this example, the data processing device 100 includes a scheduling module 10, a first analysis path 20-1, a second analysis path 20-2, and a request processing unit 30. The first analysis path 20-1 includes a read module 21, an allocation module 23, and 32 byte analysis paths. These 32 byte analysis paths comprise 32 cache queues 241 and 32 analysis modules 242. An allocation module 23 and the 32 byte analysis paths constitute one data processing unit. The second analysis path 20-2 includes a read module 21, an allocation module 23, and 32 byte analysis paths. The generation process includes the following steps.

[0199] 1. The scheduling module 10 receives the task of analyzing the compression strategy of the primitive dataset.

[0200] 2. The scheduling module 10 extracts the compression strategy analysis tasks corresponding to the graph element data subset a (hereinafter referred to as subtask A), the compression strategy analysis tasks corresponding to the graph element data subset b (hereinafter referred to as subtask B), the compression strategy analysis tasks corresponding to the graph element data subset c (hereinafter referred to as subtask C), the compression strategy analysis tasks corresponding to the graph element data subset d (hereinafter referred to as subtask D), and the compression strategy analysis tasks corresponding to the graph element data subset e (hereinafter referred to as subtask E) from the compression strategy analysis of the graph element data dataset, resulting in a total of 5 subtasks from subtask A to subtask E.

[0201] Among them, subset a of the graph data is a coordinate graph data subset, and the sum of the standard bytes of its corresponding graph data types is 10; subset b of the graph data is an attribute graph data subset, and the sum of the standard bytes of its corresponding graph data types is 32; subset c of the graph data is an attribute graph data subset, and the sum of the standard bytes of its corresponding graph data types is 32; subset d of the graph data is an attribute graph data subset, and the sum of the standard bytes of its corresponding graph data types is 32; subset e of the graph data is an attribute graph data subset, and the sum of the standard bytes of its corresponding graph data types is 24.

[0202] 3. The scheduling module 10 arranges the subtasks A to E into the following subtask queue [subtask A, subtask B, subtask C, subtask D, subtask E] according to the bandwidth requirements corresponding to subtasks A to E respectively (for the calculation method of bandwidth requirements, please refer to the above embodiment, which will not be repeated here).

[0203] 4. The scheduling module 10 takes subtask A from the leftmost side of the subtask queue and outputs it to the reading module 21 included in the first analysis path 20-1, and takes subtask E from the rightmost side of the subtask queue and outputs it to the reading module 21 included in the second analysis path 20-2. At this time, the subtask queue changes to [subtask B, subtask C, subtask D].

[0204] 5. After receiving subtask A, the reading module 21 of the first analysis path 20-1 sends a read request for the map data subset a to the request processing unit 30; after receiving subtask E, the reading module 21 of the second analysis path 20-2 sends a read request for the map data subset e to the request processing unit 30.

[0205] 6. The request processing unit 30 receives two read requests simultaneously. Since the coordinate attribute data subset has higher priority, the request processing unit first forwards the read request for data subset a to the storage unit, and then forwards the read request for data subset b to the storage unit. Furthermore, according to the forwarding order, the request processing unit 30 sequentially records the identification information of the first analysis path 20-1 and the second analysis path 20-2 in the request source cache queue.

[0206] 7. The request processing unit 30 returns the subset a of the image data returned by the storage unit to the allocation module 23 included in the first analysis path 20-1 according to the identification information of the first analysis path 20-1 recorded in the request source cache queue, and removes the identification information of the first analysis path 20-1 from the request source cache queue; and returns the subset b of the image data returned by the storage unit to the allocation module 23 included in the first analysis path 20-1 according to the identification information of the second analysis path 20-2 recorded in the request source cache queue, and removes the identification information of the second analysis path 20-2 from the request source cache queue.

[0207] 8. In the first analysis path 20-1, the allocation module 23 splits the data in the map data subset a into byte form and allocates these bytes to the 10 cache queues 241 in the first analysis path 20-1. Each of the 10 cache queues 241 receives one byte group, and the 10 cache queues 241 receive a total of 10 byte groups. Similarly, in the second analysis path 20-2, the allocation module 23 splits the data in the map data subset e into byte form and allocates these bytes to the 24 cache queues 241 in the second analysis path 20-2. Each of the 24 cache queues 241 receives one byte group, and the 24 cache queues 241 receive a total of 24 byte groups.

[0208] 9. The 10 analysis modules 242 in the first analysis path 20-1 work in parallel, reading bytes from the cache queue 241 included in their respective byte analysis paths, and adjusting the value range of the bytes they record based on the read bytes to obtain the compression strategies for each of the 10 byte groups as the compression strategies for the map data subset a. Similarly, the 24 analysis modules 242 in the second analysis path 20-2 work in parallel, reading bytes from the cache queue 241 included in their respective byte analysis paths, and adjusting the value range of the bytes they record based on the read bytes to obtain the compression strategies for each of the 24 byte groups as the compression strategies for the map data subset e.

[0209] 10. After processing subtask A in the first analysis path 20-1 and becoming idle, scheduling module 10 retrieves subtask B from the leftmost side of the subtask queue and outputs it to the read module 21 included in the first analysis path 20-1. After processing subtask E in the second analysis path 20-2 and becoming idle, scheduling module 10 retrieves subtask D from the rightmost side of the subtask queue and outputs it to the read module 21 included in the second analysis path 20-2. At this point, only subtask C remains in the subtask queue.

[0210] 11. After receiving subtask B, the reading module 21 of the first analysis path 20-1 sends a read request for the map data subset b to the request processing unit 30; after receiving subtask D, the reading module 21 of the second analysis path 20-2 sends a read request for the map data subset d to the request processing unit 30.

[0211] 12. After receiving a read request for a subset b of the graph data, request processing unit 30 forwards the read request for the subset b to the storage unit and records the identification information of the first analysis path 20-1 in the request source cache queue. After receiving a read request for a subset d of the graph data, request processing unit 30 forwards the read request for the subset d to the storage unit and records the identification information of the second analysis path 20-2 in the request source cache queue.

[0212] 13. The request processing unit 30 returns the subset b of the image data returned by the storage unit to the allocation module 23 included in the first analysis path 20-1 according to the identification information of the first analysis path 20-1 recorded in the request source cache queue, and removes the identification information of the first analysis path 20-1 from the request source cache queue; and returns the subset d of the image data returned by the storage unit to the allocation module 23 included in the first analysis path 20-1 according to the identification information of the second analysis path 20-2 recorded in the request source cache queue, and removes the identification information of the second analysis path 20-2 from the request source cache queue.

[0213] 14. In the first analysis path 20-1, the allocation module 23 splits the data in the map data subset a into byte form and allocates these bytes to the 32 cache queues 241 in the first analysis path 20-1. Each cache queue 241 receives one byte group, and the 32 cache queues 241 receive a total of 32 byte groups. Similarly, in the second analysis path 20-2, the allocation module 23 splits the data in the map data subset e into byte form and allocates these bytes to the 32 cache queues 241 in the second analysis path 20-2. Each cache queue 241 receives one byte group, and the 32 cache queues 241 receive a total of 32 byte groups.

[0214] 15. The 32 analysis modules 242 in the first analysis path 20-1 work in parallel, reading bytes from the cache queue 241 included in their respective byte analysis paths, and adjusting the value range of the bytes they record based on the read bytes to obtain the compression strategies for each of the 32 byte groups as the compression strategies for the map data subset b. Similarly, the 32 analysis modules 242 in the second analysis path 20-2 work in parallel, reading bytes from the cache queue 241 included in their respective byte analysis paths, and adjusting the value range of the bytes they record based on the read bytes to obtain the compression strategies for each of the 32 byte groups as the compression strategies for the map data subset d.

[0215] 16. After the scheduling module 10 finishes processing subtask A in the first analysis path 20-1 and becomes idle, it retrieves subtask C from the leftmost side of the subtask queue and outputs it to the read module 21 included in the first analysis path 20-1. At this time, the subtask queue is empty. It should be noted that subtask C can also be processed by the second analysis path 20-2 when it becomes idle. Here, we only use the example of the first analysis path 20-1 becoming idle first for explanation.

[0216] 17. After receiving subtask C, the reading module 21 in the first analysis path 20-1 sends a read request for the graph data subset c to the request processing unit 30.

[0217] 18. After receiving a read request for the image data subset c, the request processing unit 30 forwards the read request for the image data subset c to the storage unit and records the identification information of the first analysis path 20-1 in the request source cache queue.

[0218] 19. The request processing unit 30 returns the subset of image data c returned by the storage unit to the allocation module 23 included in the first analysis path 20-1 according to the identification information of the first analysis path 20-1 recorded in the request source cache queue, and removes the identification information of the first analysis path 20-1 from the request source cache queue.

[0219] 20. The allocation module 23 in the first analysis path 20-1 splits the data in the image data subset c into byte form and gives these bytes to the 32 cache queues 241 in the first analysis path 20-1. Each of the 32 cache queues 241 receives one byte group of bytes, and the 32 cache queues 241 receive a total of 32 byte groups of bytes.

[0220] 21. The 32 analysis modules 242 in the first analysis path 20-1 work in parallel, read bytes from the cache queue 241 included in their respective byte analysis paths, and adjust the value range of the bytes they record according to the read bytes, so as to obtain the compression strategy of each of the 32 byte groups as the compression strategy of the image data subset c.

[0221] The compression strategies of the aforementioned subsets of primitive data a, b, c, d, and e constitute the compression strategy for the primitive dataset. It is evident that when using the aforementioned data processing device to handle compression strategy analysis tasks, the two analysis paths can operate simultaneously, overcoming the throughput limitations of a single analysis path. Furthermore, through dual-path parallelism, two read requests can be initiated at the same time, and the data read by each read request can be serially input into the analysis module through a cache queue, thereby reducing bandwidth waste caused by waiting for serial input.

[0222] An exemplary embodiment of this application also provides a chip that includes the aforementioned data processing device. This chip may be a GPU (Graphics Processing Unit) chip, a CPU (Central Processing Unit) chip, or a chip specifically designed for data compression; this application does not limit the specific application to this type of chip.

[0223] In some embodiments, please refer to Figure 7The chip 200 includes a data processing device 100 and a compression encoding module 110. The output of the data processing device 100 is connected to the input of the compression encoding module 110. The data processing device 100 is used to process the compression strategy analysis task of the primitive dataset and generate a compression strategy for the primitive dataset. The compression encoding module 110 is used to compress the primitive dataset according to the received compression strategy. Optionally, the chip 200 may also include a storage unit 120 for storing the primitive dataset. Optionally, the storage unit 120 may also be located outside the chip 200.

[0224] An exemplary embodiment of this application also provides an electronic device, which includes a chip that includes the data processing device described above.

[0225] The electronic device can be such as a mobile phone, tablet computer, multimedia playback device, PC (Personal Computer), wearable device, in-vehicle terminal device, VR (Virtual Reality) device, AR (Augmented Reality) device, MR (Mixed Reality) device, etc., and this application does not limit it.

[0226] An exemplary embodiment of this application also provides a processor, which includes the data processing apparatus described above.

[0227] The aforementioned processor may include one or more processing cores, such as a quad-core processor or an octa-core processor. The processor may be implemented using at least one hardware form selected from DSP (Digital Signal Processing), FPGA (Field Programmable Gate Array), and PLA (Programmable Logic Array). The processor may also include a main processor and a coprocessor. The main processor, also known as the CPU, is used to process data in the wake-up state; the coprocessor is a low-power processor used to process data in the standby state. In some embodiments, the processor may be a GPU, which is responsible for rendering and drawing the content required to be displayed on the screen. In some embodiments, the processor may also include an AI (Artificial Intelligence) processor, which is used to handle computational operations related to machine learning.

[0228] One embodiment of this application also provides a GPU, which includes the data processing apparatus described in the above embodiments.

[0229] One embodiment of this application also provides a graphics card, the graphics card including a chip, the chip including the data processing device described above.

[0230] The following are embodiments of the method of this application. For details not described in the embodiments of the method of this application, please refer to the embodiments of the data processing device above.

[0231] Please refer to Figure 8 The diagram illustrates a flowchart of a data processing method applied to a data processing apparatus according to an embodiment of this application. The data processing apparatus includes a scheduling module and multiple analysis paths. The method includes at least one of the following steps 810-840.

[0232] Step 810: The scheduling module receives the compression strategy analysis task for the primitive dataset.

[0233] Step 820: The scheduling module extracts at least one compression strategy analysis task corresponding to a subset of graph data from the compression strategy analysis task of the graph primitive dataset to obtain at least one subtask.

[0234] The primitive dataset includes at least one subset of primitive data.

[0235] Step 830: The scheduling module outputs at least one subtask to the analysis path.

[0236] In this case, one subtask is output to one analysis path, and if the at least one subtask is multiple subtasks, at least two of the multiple subtasks are output to different analysis paths.

[0237] Step 840: When the target analysis path in the multiple analysis paths receives at least one target subtask, it reads the graph data subset corresponding to the target subtask and generates a compression strategy for the graph data subset corresponding to the target subtask.

[0238] The compression strategy for the graph data subset corresponding to the target subtask is used to compress the graph data subset corresponding to the target subtask.

[0239] In some embodiments, step 830 includes: the scheduling module outputting the plurality of subtasks to the analysis path according to the bandwidth requirement values ​​of each of the plurality of subtasks, wherein the bandwidth requirement value of the subtask is used to reflect the read bandwidth requirement of the storage unit for executing the subtask, and the storage unit is used to store the primitive dataset.

[0240] In some embodiments, the device includes M analysis paths, where M is an integer greater than 1. Step 830 further includes: the scheduling module arranging the plurality of subtasks into a subtask queue according to the bandwidth requirements of each of the plurality of subtasks; when the i-th analysis path in the M analysis paths is idle, taking a subtask from one end of the subtask queue and outputting it to the i-th analysis path, where i is a positive integer less than M; when the (i+1)-th analysis path in the M analysis paths is idle, taking a subtask from the other end of the subtask queue and outputting it to the (i+1)-th analysis path.

[0241] In some embodiments, the plurality of subtasks are compression strategy analysis tasks corresponding to the plurality of subsets of map data. The method further includes: the scheduling module determining the bandwidth requirement value of each of the plurality of subtasks based on the maximum number of bytes corresponding to the plurality of map data subsets, wherein the maximum number of bytes corresponding to the map data subset refers to the maximum number of bytes belonging to the same byte plane among the bytes of each data contained in the map data subset; wherein the data corresponding to different bytes belonging to the same byte plane are used to indicate the same type of attribute or the same type of coordinate value of the map element, and the positions of different bytes belonging to the same byte plane in the corresponding data have a corresponding relationship.

[0242] In some embodiments, the plurality of subtasks are compression strategy analysis tasks corresponding to the plurality of graph data subsets respectively. The plurality of graph data subsets include a coordinate graph data subset and at least two attribute graph data subsets. The graph data in the coordinate graph data subset is used to indicate the coordinate values ​​of the graph element, and the graph data in the attribute graph data subset is used to indicate the attributes of the graph element. Moreover, the graph data in any two different attribute graph data subsets indicates different attribute types.

[0243] In some embodiments, the above-described apparatus further includes a request processing unit, and the target analysis path includes a read module and a data processing unit.

[0244] Step 830 above includes: when the reading module receives the target subtask, it sends a target read request to the request processing unit, wherein the target read request is a read request for a subset of graph data corresponding to the target subtask.

[0245] The above method further includes: the request processing unit returning a subset of graph data corresponding to the target subtask to the data processing unit.

[0246] Step 830 above also includes: the data processing unit generating a compression strategy for the subset of graph data corresponding to the target subtask.

[0247] In some embodiments, the method further includes: when the request processing unit receives multiple read requests simultaneously, it forwards the multiple read requests to the storage unit in sequence according to the priority of the type of the primitive data subset targeted by each of the multiple read requests, wherein the multiple read requests include the target read request, and the storage unit is used to store the primitive dataset.

[0248] The above-mentioned step of "the request processing unit returning the graph data subset corresponding to the target subtask to the data processing unit" includes: after receiving the graph data subset corresponding to the target subtask returned by the storage unit, the request processing unit returns the graph data subset corresponding to the target subtask to the data processing unit.

[0249] In some embodiments, the subset of graph data includes a coordinate graph data subset and an attribute graph data subset. The graph data in the coordinate graph data subset indicates the coordinate values ​​of a graph element, and the graph data in the attribute graph data subset indicates the attributes of the graph element. The coordinate graph data subset has a higher priority than the attribute graph data subset.

[0250] In some embodiments, the above method further includes: after forwarding the target read request to the storage unit, the request processing unit records the sending source of the target read request as the target analysis path.

[0251] The above-mentioned step of "the request processing unit returns the subset of graph data corresponding to the target subtask to the data processing unit" includes: the request processing unit returns the subset of graph data corresponding to the target subtask to the data processing unit in the target analysis path according to the recorded source of the target read request.

[0252] In some embodiments, the data processing unit includes an allocation module and multiple byte analysis paths. Step 840 above includes the following steps 842-846 (…). Figure 8 (Not shown in the image).

[0253] Step 842: The allocation module splits the subset of graph data corresponding to the target subtask into multiple bytes, wherein bytes in the same byte group belong to the same byte plane, and bytes in different byte groups belong to different byte planes; Step 844: The allocation module sends the multiple bytes to the multiple byte analysis paths, wherein bytes belonging to the same byte group are sent to the same byte analysis path, and bytes belonging to different byte groups are sent to different byte analysis paths; Step 846: When the target byte analysis path in the multiple byte analysis paths receives bytes belonging to the target byte group in the multiple byte groups, it generates a compression strategy for the target byte group, wherein the compression strategy of the graph data subset corresponding to the target subtask includes the compression strategies of each of the multiple byte groups.

[0254] In some embodiments, the target byte analysis path includes a cache queue and an analysis module. The cache queue stores bytes belonging to the target byte group. Step 846 includes the following step: the analysis module generates a compression strategy for the target byte group based on the bytes output from the cache queue.

[0255] In some embodiments, step 846 further includes the following steps: the analysis module adjusts the numerical range information corresponding to the target byte group according to the bytes output by the cache queue, the numerical range information corresponding to the target byte group is used to indicate the numerical range of bytes in the target byte group; after adjusting the numerical range corresponding to the target byte group according to the last byte in the target byte group, the analysis module outputs the numerical range corresponding to the target byte group as the compression strategy of the target byte group.

[0256] In some embodiments, if the value of the byte output by the cache queue is greater than the maximum value of the numerical range indicated by the numerical range information, the analysis module adjusts the maximum value of the numerical range indicated by the numerical range information to the value of the byte output by the cache queue; or, if the value of the byte output by the cache queue is less than the minimum value of the numerical range indicated by the numerical range information, the minimum value of the numerical range indicated by the numerical range information is adjusted to the value of the byte output by the cache queue.

[0257] In some embodiments, the sum of the standard byte counts of each graph metadata type corresponding to the graph metadata subset is less than or equal to the number of byte analysis paths included in each analysis path; wherein, the graph metadata type corresponding to the graph metadata subset refers to the graph metadata type to which at least one graph metadata in the graph metadata subset belongs, and the standard byte count of the graph metadata type refers to the number of bytes uniformly possessed by the graph metadata belonging to the graph metadata type.

[0258] It should be understood that "multiple" as used herein refers to two or more. "And / or" describes the relationship between related objects, indicating that three relationships can exist. For example, A and / or B can represent: A alone, A and B simultaneously, or B alone. The character " / " generally indicates that the preceding and following related objects are in an "or" relationship. Furthermore, the step numbers described herein are merely illustrative of one possible execution order. In some other embodiments, the steps may not be executed in numerical order, such as two steps with different numbers being executed simultaneously, or two steps with different numbers being executed in the reverse order of the illustration. This application does not limit this.

[0259] The above are merely exemplary embodiments of this application and are not intended to limit this application. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of this application shall be included within the protection scope of this application.

Claims

1. A data processing apparatus, characterized in that, The device includes a scheduling module and multiple analysis paths; The scheduling module is used to receive compression strategy analysis tasks for primitive datasets; The scheduling module is further configured to extract at least one compression strategy analysis task corresponding to each of the compression strategy analysis tasks of the primitive dataset, so as to obtain at least one subtask, wherein the primitive dataset includes the at least one subset of primitive data. The scheduling module is further configured to output the at least one subtask to the analysis path, wherein one subtask is output to one analysis path, and when the at least one subtask is multiple subtasks, at least two of the multiple subtasks are output to different analysis paths. The target analysis path among the multiple analysis paths is used to read the graph data subset corresponding to the target subtask when receiving the target subtask in the at least one subtask, and to generate a compression strategy for the graph data subset corresponding to the target subtask, wherein the compression strategy for the graph data subset corresponding to the target subtask is used to compress the graph data subset corresponding to the target subtask.

2. The apparatus according to claim 1, characterized in that, The scheduling module is used to output the plurality of subtasks to the analysis path according to the bandwidth requirement values ​​of each of the plurality of subtasks, wherein the bandwidth requirement value of the subtask is used to reflect the read bandwidth requirement of the storage unit for executing the subtask, and the storage unit is used to store the primitive dataset.

3. The apparatus according to claim 2, characterized in that, The device includes M analysis paths, where M is an integer greater than 1; the scheduling module is used for: Based on the bandwidth requirements of each of the subtasks, the subtasks are arranged into a subtask queue. If the i-th analysis path in the M analysis paths is idle, a subtask is taken from one end of the subtask queue and output to the i-th analysis path, where i is a positive integer less than M; If the (i+1)th analysis path in the M analysis paths is idle, a subtask is taken from the other end of the subtask queue and output to the (i+1)th analysis path.

4. The apparatus according to claim 2, characterized in that, The multiple subtasks are compression strategy analysis tasks corresponding to multiple subsets of graph data; The scheduling module is further configured to determine the bandwidth requirement value of each of the multiple subtasks based on the maximum number of bytes corresponding to the multiple subsets of graph data. The maximum number of bytes corresponding to the subset of graph data refers to the maximum number of bytes belonging to the same byte plane among the bytes of each set of graph data contained in the subset of graph data. Among them, the different bytes belonging to the same byte plane correspond to the same type of graphic data, which are used to indicate the same type of attribute or the same type of coordinate value of graphic elements, and the different bytes belonging to the same byte plane have a corresponding relationship in the position of the corresponding graphic data.

5. The apparatus according to claim 1, characterized in that, The multiple subtasks are compression strategy analysis tasks corresponding to multiple subsets of graph data; The plurality of graph data subsets include a coordinate graph data subset and at least two attribute graph data subsets. The graph data in the coordinate graph data subset is used to indicate the coordinate values ​​of the graph element, and the graph data in the attribute graph data subset is used to indicate the attributes of the graph element. Furthermore, the graph data in any two different attribute graph data subsets indicates different attribute types.

6. The apparatus according to any one of claims 1 to 5, characterized in that, The device further includes a request processing unit, and the target analysis path includes a reading module and a data processing unit; The read module is used to send a target read request to the request processing unit when the target subtask is received. The target read request is a read request for a subset of graph data corresponding to the target subtask. The request processing unit is used to return a subset of graph data corresponding to the target subtask to the data processing unit; The data processing unit is used to generate a compression strategy for the subset of graph data corresponding to the target subtask.

7. The apparatus according to claim 6, characterized in that, The request processing unit is configured to, when receiving multiple read requests simultaneously, forward the multiple read requests to the storage unit in sequence according to the priority of the type of the primitive data subset targeted by each of the multiple read requests. The multiple read requests include the target read request. The storage unit is configured to store the primitive dataset. The request processing unit is configured to return the subset of graph data corresponding to the target subtask to the data processing unit after receiving the subset of graph data corresponding to the target subtask returned by the storage unit.

8. The apparatus according to claim 7, characterized in that, The types of the image data subsets include coordinate image data subsets and attribute image data subsets. The image data in the coordinate image data subset is used to indicate the coordinate values ​​of the image elements, and the image data in the attribute image data subset is used to indicate the attributes of the image elements. The priority of the coordinate graph data subset is higher than that of the attribute graph data subset.

9. The apparatus according to claim 7, characterized in that, The request processing unit is further configured to, after forwarding the target read request to the storage unit, record the sending source of the target read request as the target analysis path; The request processing unit is configured to return a subset of graph data corresponding to the target subtask to the data processing unit in the target analysis path, based on the recorded source of the target read request.

10. The apparatus according to claim 6, characterized in that, The data processing unit includes an allocation module and multiple byte analysis paths; The allocation module is used to split the subset of graph data corresponding to the target subtask into multiple bytes, wherein the multiple bytes can be divided into multiple byte groups, the bytes in the same byte group belong to the same byte plane, and the bytes in different byte groups belong to different byte planes; The allocation module is further configured to send the plurality of bytes to the plurality of byte analysis paths, wherein, among the plurality of bytes, bytes belonging to the same byte group are sent to the same byte analysis path, and bytes belonging to different byte groups are sent to different byte analysis paths; The target byte analysis path in the multiple byte analysis paths is used to generate a compression strategy for the target byte group when a byte belonging to the target byte group in the multiple byte groups is received. The compression strategy for the graph data subset corresponding to the target subtask includes the compression strategies of each of the multiple byte groups.

11. The apparatus according to claim 10, characterized in that, The target byte analysis path includes a cache queue and an analysis module; The cache queue is used to store bytes belonging to the target byte group; The analysis module is used to generate a compression strategy for the target byte group based on the bytes output by the cache queue.

12. The apparatus according to claim 11, characterized in that, The analysis module is used to adjust the numerical range information corresponding to the target byte group according to the bytes output by the cache queue. The numerical range information is used to indicate the numerical range of bytes in the target byte group. The analysis module is used to adjust the numerical range information corresponding to the target byte group based on the last byte in the target byte group, and then output the numerical range information corresponding to the target byte group as the compression strategy of the target byte group.

13. The apparatus according to claim 12, characterized in that, The analysis module is used to adjust the maximum value of the numerical range indicated by the numerical range information to the value of the byte output by the cache queue when the value of the byte output by the cache queue is greater than the maximum value of the numerical range indicated by the numerical range information; or, If the value of the byte output by the cache queue is less than the minimum value of the numerical range indicated by the numerical range information, the minimum value of the numerical range indicated by the numerical range information is adjusted to the value of the byte output by the cache queue.

14. The apparatus according to claim 10, characterized in that, The sum of the standard bytes of each graph data type corresponding to the subset of graph data is less than or equal to the number of byte analysis paths included in each analysis path; The graph metadata type corresponding to the graph metadata subset refers to the graph metadata type to which at least one graph metadata in the graph metadata subset belongs, and the standard byte count of the graph metadata type refers to the number of bytes that graph metadata belonging to the graph metadata type uniformly possesses.

15. A chip, characterized in that, The chip includes a data processing device as described in any one of claims 1 to 14.

16. An electronic device, characterized in that, The electronic device includes a chip, the chip including a data processing device as described in any one of claims 1 to 14.

17. A processor, characterized in that, The processor includes the data processing apparatus as described in any one of claims 1 to 14.

18. A data processing method applied to a data processing device, characterized in that, The device includes a scheduling module and multiple analysis paths; the method includes: The scheduling module receives the task of analyzing the compression strategy of the primitive dataset; The scheduling module extracts at least one compression strategy analysis task corresponding to a compression data subset from the compression strategy analysis task of the primitive dataset to obtain at least one subtask. The primitive dataset includes the at least one subset of primitive data. The scheduling module outputs the at least one subtask to the analysis path, wherein one subtask is output to one analysis path, and when the at least one subtask is multiple subtasks, at least two of the multiple subtasks are output to different analysis paths. When the target analysis path in the multiple analysis paths receives the target subtask from the at least one subtask, it reads the graph data subset corresponding to the target subtask and generates a compression strategy for the graph data subset corresponding to the target subtask. The compression strategy for the graph data subset corresponding to the target subtask is used to compress the graph data subset corresponding to the target subtask.

Images