Data processing method, system and apparatus, and electronic device and readable storage medium

Abstract

The present application belongs to the technical field of communications. Disclosed are a data processing method, system and apparatus, and an electronic device and a readable storage medium. The method comprises: receiving a first request from a first unit by means of a system level cache (SLC), wherein the first request is used for requesting the storage, in the SLC, of data in a data buffer; and when it is detected by means of the SLC that the first request carries a first buffer identifier, using a storage policy that corresponds to the first buffer identifier to store, in the SLC, first data in a first data buffer, wherein a first data buffer identifier is used for indicating the first data buffer.

Description

Data processing method, system, device, electronic device and readable storage medium

[0001] CROSS-REFERENCE TO RELATED APPLICATIONS

[0002] This application claims priority to Chinese Patent Application No. 202410267868.1 filed in China on March 8, 2024, the entire contents of which are incorporated herein by reference. Technical Field

[0003] The present application belongs to the field of communication technology, and specifically relates to a data processing method, system, device, electronic device and readable storage medium. Background Art

[0004] In a mobile terminal system-on-chip (SOC), a system level cache (SLC) plays a role in saving system bandwidth and reducing system power consumption.

[0005] In related technologies, SLC uses a data replacement mechanism to store data. Specifically, after a portion of the fixed-capacity SLC is occupied, the main control and firmware will determine the usage environment and dynamically release the SLC cache, so that the data stored in the SLC will be replaced by the newly stored data. Since there is currently no method for managing SLC data storage, in some scenarios, when previously stored data needs to be used again, the data needs to be read again from the memory, resulting in a large system bandwidth occupation when accessing the data, thereby resulting in high system power consumption. Summary of the Invention

[0006] The purpose of the embodiments of the present application is to provide a data processing method, system, device, electronic device and readable storage medium, which can reduce the system bandwidth occupied when accessing data, thereby saving system power consumption.

[0007] In a first aspect, an embodiment of the present application provides a data processing method, the method comprising: receiving a first request from a first unit through a system-level cache SLC, the first request being used to request storage of data in a data buffer in the SLC; when the SLC detects that the first request carries a first buffer identifier, adopting a storage strategy corresponding to the first buffer identifier to store the first data in the first data buffer to the SLC, the first data buffer identifier being used to indicate the first data buffer.

[0008] In a second aspect, an embodiment of the present application provides a data processing system, which includes: an SLC and a first unit, wherein: the SLC is used to receive a first request from the first unit, and the first request is used to request that data in a data buffer be stored in the SLC; the SLC is also used to, when detecting that the first request carries a first buffer identifier, adopt a storage strategy corresponding to the first buffer identifier to store the first data in the first data buffer to the SLC, and the first buffer identifier is used to indicate the first data buffer.

[0009] In a third aspect, an embodiment of the present application provides a data processing device, which includes: an acquisition module and a control module, wherein: the acquisition module is used to receive a first request from a first unit through a system-level cache SLC, and the first request is used to request that data in a data buffer be stored in the SLC; the control module is used to, when detecting through the SLC that the first request carries a first buffer identifier, adopt a storage strategy corresponding to the first buffer identifier to store the first data in the first data buffer to the SLC, and the first data buffer identifier is used to indicate the first data buffer.

[0010] In a fourth aspect, an embodiment of the present application provides an electronic device comprising a processor and a memory, wherein the memory stores programs or instructions that can be run on the processor, and when the programs or instructions are executed by the processor, the steps of the method described in the first aspect are implemented.

[0011] In a fifth aspect, an embodiment of the present application provides a readable storage medium, on which a program or instruction is stored. When the program or instruction is executed by a processor, the steps of the method described in the first aspect are implemented.

[0012] In a sixth aspect, an embodiment of the present application provides a chip, comprising a processor and a communication interface, wherein the communication interface is coupled to the processor, and the processor is used to run programs or instructions to implement the method described in the first aspect.

[0013] In a seventh aspect, an embodiment of the present application provides a computer program product, which is stored in a storage medium and is executed by at least one processor to implement the method described in the first aspect.

[0014] In an embodiment of the present application, a first request is received from a first unit via an SLC, where the first request is used to request that data in a data buffer be stored in the SLC. When the SLC detects that the first request carries a first buffer identifier, the first data in the first data buffer is stored in the SLC using a storage policy corresponding to the first buffer identifier. The first data buffer identifier is used to indicate the first data buffer. In this method, the buffer is marked by the data buffer identifier to distinguish different data buffers, so that when accessing data in the buffer, the data buffer to which the data to be accessed belongs can be identified according to the data buffer identifier, and the data in the data buffer is stored using the storage policy corresponding to the data buffer identifier. This allows data in different data buffers to be stored according to the corresponding storage policy, meeting the storage requirements of data in different data buffers, and enabling efficient reading of data from the SLC, thereby reducing the system bandwidth occupied when accessing data and saving system power consumption. BRIEF DESCRIPTION OF THE DRAWINGS

[0015] FIG1A is a schematic diagram of model data in a racing game scenario according to an embodiment of the present application;

[0016] FIG1B is a second schematic diagram of model data in a racing game scenario provided by an embodiment of the present application;

[0017] FIG2 is a system architecture diagram of a CPU and a GPU accessing data cache based on SLC according to an embodiment of the present application;

[0018] FIG3 is a flow chart of a data processing method according to an embodiment of the present application;

[0019] FIG4 is a schematic diagram of a character object in an image rendering scene provided by an embodiment of the present application;

[0020] FIG5 is a schematic diagram of the PBHA attribute of the Arm64 page table attribute provided in an embodiment of the present application;

[0021] FIG6A is a schematic diagram of a bus access process from a CPU and a GPU to an SLC according to an embodiment of the present application;

[0022] FIG6B is a schematic diagram of a special address segment of a physical address space provided in an embodiment of the present application;

[0023] FIG6C is a schematic diagram illustrating the correspondence between physical addresses and buffer identifiers when the SLC resolves the address space according to an embodiment of the present application;

[0024] FIG7 is a second flow chart of the data processing method provided in an embodiment of the present application;

[0025] FIG8 is a schematic structural diagram of a data processing device provided in an embodiment of the present application;

[0026] FIG9 is a schematic structural diagram of an electronic device provided in an embodiment of the present application;

[0027] FIG10 is a schematic diagram of the hardware structure of the electronic device provided in an embodiment of the present application. DETAILED DESCRIPTION

[0028] The following will be combined with the accompanying drawings in the embodiments of the present application to clearly describe the technical solutions in the embodiments of the present application. Obviously, the embodiments described are part of the embodiments of the present application, not all of the embodiments. Based on the embodiments in the present application, all other embodiments obtained by ordinary technicians in this field are within the scope of protection of this application.

[0029] The terms "first," "second," and the like in the specification and claims of this application are used to distinguish similar objects, and are not used to describe a specific order or precedence. It should be understood that the terms used in this manner are interchangeable where appropriate, so that the embodiments of this application can be implemented in an order other than that illustrated or described herein, and that the objects distinguished by "first," "second," and the like are generally of the same type, and do not limit the number of objects; for example, the first object can be one or more. In addition, the term "and / or" in the specification and claims represents at least one of the connected objects, and the character " / " generally indicates that the objects associated with each other are in an "or" relationship.

[0030] The terms "at least one" and "at least one of" in the specification and claims of this application refer to any one, any two, or a combination of more than two of the objects included. For example, at least one of a, b, and c can be represented by: "a", "b", "c", "a and b", "a and c", "b and c", and "a, b, and c", where a, b, and c can be single or multiple. Similarly, "at least two" means two or more, and its meaning is similar to "at least one".

[0031] The following is an explanation of the nouns or terms involved in the data processing method provided in this application.

[0032] CPU (Central Processing Unit): The main computing device in a computer. The CPU's primary task is to manage the computer's calculations and processing. The CPU can be thought of as the computer's "brain," carrying out all commands and calculations.

[0033] A GPU (Graphics Processing Unit) is a processing device specifically designed to process graphics and video data. It's primarily used for processing graphics and video data, as well as rendering in games. The GPU can be thought of as the computer's "painting tool."

[0034] While both CPUs and GPUs are processing devices, they work differently. CPUs primarily use a single processing unit to handle various computing tasks, such as browsing the web, running applications, and managing files. GPUs, on the other hand, use thousands of smaller processing units to handle large-scale computing tasks, such as drawing graphics, rendering animations frame by frame, and encoding videos.

[0035] SLC: System-level cache, which is different from the cache inside the processor, can improve the speed of the entire system accessing external storage. In mobile terminal SOC, system-level cache plays a role in saving system bandwidth and reducing system power consumption.

[0036] Data buffer: Buffer, that is, putting data in a continuous memory space. The continuous storage space can save the time of transferring data to the CPU.

[0037] The graphics rendering method provided in the embodiments of the present application can be applied in game scenarios.

[0038] In large-scale game scenes, the access bandwidth of the CPU and GPU is very large, generally reaching 5 to 8GB / S. In the rendering of each game frame, the bandwidth access of the CPU and GPU can reach 85MB to 136MB, which is much larger than the capacity of the SLC (6MB-32MB). The replacement strategy of SLC mostly adopts the LRU algorithm, which means that the data most frequently accessed by the CPU and GPU is more likely to be stored in the SLC. Due to the huge data access volume of the CPU and GPU, the game data accessed by the CPU and GPU in the previous frame will most likely be replaced by new data and will not be stored in the SLC.

[0039] In real-world gaming scenarios, the CPU and GPU access game data repeatedly across multiple frames. For example, in a racing game, the main character, the car, is rendered across multiple frames, and the car's model data is repeatedly accessed by the CPU and GPU. As shown in Figure 1B, the car's model data includes the wheels, driver, and car outline.

[0040] After statistical analysis, in a racing game, the access volume of the model data of the "protagonist" car is as high as 1.077GB / S. Table 1 shows the statistics of model data repeatedly accessed by the CPU and GPU in the racing game.

[0041] Table 1

[0042] As shown in Table 1, the car model data in a racing game, namely the driver, car outline, and wheels, will be accessed multiple times. If the car appears in every frame of the game, the car model data will be repeatedly accessed by the CPU and GPU. However, due to the current SLC data replacement strategy, model data that needs to be rendered multiple times in the game may not be read from the SLC. This data will always be read from the double data rate (DDR) memory. Frequent data access from the DDR memory will occupy a large amount of system bandwidth, resulting in higher system power consumption.

[0043] To address the aforementioned issues in the prior art, embodiments of the present application provide a data processing method in which the SLC can identify which data cache the CPU or GPU is currently accessing based on the address and other accompanying information of a bus request (i.e., a first request) issued by the CPU or GPU (i.e., the first unit). The data processing method provided by embodiments of the present application is described below with reference to the accompanying drawings and application scenarios.

[0044] Figure 2 shows the system architecture for CPU and GPU SLC-based data cache access, as provided in an embodiment of the present application. As shown in Figure 2, the SLC identifies the data written by the CPU as belonging to the Geometry Buffer from the CPU's bus request. The SLC stores the data written by the CPU in the Geometry Buffer according to the upper-layer software's storage policy for the Geometry Buffer. The SLC ensures that the Geometry Buffer data is not replaced by other data based on the upper-layer application's usage characteristics.

[0045] It should be noted that the data in the Geometry Buffer is reused in multiple subsequent game frame renderings and needs to reside in the SLC for a long time.

[0046] Subsequently, the SLC reads the Geometry Buffer data when it recognizes a bus request from the GPU. The SLC fulfills the GPU's bus request and returns the Geometry Buffer data to the GPU. During subsequent game rendering, the SLC recognizes that the GPU has written out GBuffer data. Based on the GBuffer usage characteristics of the upper-layer application, the SLC stores the GBuffer data in the SLC. After the GPU reads the GBuffer data, the SLC prioritizes replacing the GBuffer data out of the SLC.

[0047] It should be noted that the GPU first writes out the GBuffer and then reads into the GBuffer. The data is only used once and will not be used again.

[0048] Similarly, after the GPU renders the current game frame, it writes out the frame buffer data. Based on the frame buffer usage characteristics (the frame buffer is written by the GPU and read by the display, and the data is only used once), the SLC stores the frame buffer data written by the GPU. After the display reads the relevant data, the frame buffer is preferentially replaced with the SLC. Furthermore, the DRAM can read data from the SLC.

[0049] The data processing method provided by an embodiment of the present application receives a first request from a first unit (e.g., a GPU) through an SLC in a racing game scenario. The request is used to request storage of data in a data buffer in the SLC. When the SLC detects that the first request carries a buffer identifier indicating a geometry buffer (i.e., a first data buffer), the storage strategy corresponding to the buffer identifier is adopted to store the geometry data (i.e., the model data of the racing car) in the geometry buffer into the SLC according to the storage strategy corresponding to the first buffer identifier. For example, the storage strategy corresponding to the first buffer identifier is: writing the data to the SLC and allowing the written data to reside in the SLC for a long time until the upper-layer application releases the data. In this case, the geometry data is written to the SLC and allowed to reside in the SLC for a long time until the upper-layer application releases the geometry data. In this way, when the model data of the racing car in the racing game, that is, the driver, car outline and wheel data, is accessed multiple times, the model data that needs to be rendered multiple times can always be read from the SLC without being read from the DDR memory. In summary, the data processing method proposed in this application can adjust the storage strategy of the SLC according to the access characteristics of the CPU and GPU to the data cache, which can further save the system bandwidth in the game scene, thereby reducing system power consumption.

[0050] It should be noted that the data processing method provided in the embodiment of the present application is not only applicable to game scenarios, but can also be used in scenarios such as mobile phone imaging and UI.

[0051] The data processing method provided in the embodiments of the present application can be executed by an electronic device or at least one of the functional modules and entity modules in the electronic device that can implement the data processing method. The specific execution subject can be determined based on actual usage requirements and is not limited by the embodiments of the present invention. The following embodiments illustrate the data processing method provided in the present application by taking a data processing device executing the data processing method as an example.

[0052] The data processing method provided in the embodiment of the present application is described in detail below through specific embodiments and their application scenarios in conjunction with the accompanying drawings.

[0053] FIG3 is a flow chart of a data processing method provided in an embodiment of the present application. As shown in FIG3 , the data processing method may include the following steps S201 and S202:

[0054] Step S201: The data processing device receives a first request from a first unit through the system level cache SLC.

[0055] The first request is used to request to store the data in the data buffer in the SLC.

[0056] In some embodiments of the present application, the above-mentioned first unit includes but is not limited to any of the following: CPU, GPU, display unit (i.e., Display), neural network processor (Neural Network Processing Unit, NPU), media subsystem (Media Subsystem), Modem, digital signal processing (Digital Signal Process, DSP) module, wireless fidelity (Wireless Fidelity, WIFI), image signal processor (Image Signal Processor, ISP) and other hardware modules of electronic device SOC.

[0057] In some embodiments of the present application, the first request may be a bus request.

[0058] In some embodiments of the present application, the data in the data buffer requested to be stored in the SLC may include: geometric data (i.e., Geometry data), intermediate data obtained by the GPU performing geometric processing on the geometric data, and frame data (i.e., Frame data) obtained by the GPU performing lighting processing on the intermediate data. For example, the Geometry data may be game data (e.g., model data in a game scene), map data in a geographic information system, or other geometric shape data in any graphical interface.

[0059] It's important to note that the Geometry data type is a commonly used data type in computer programming, representing geometric shapes in two-dimensional or three-dimensional space. It can represent a variety of shapes, such as points, lines, polygons, and circles. The Geometry data type is commonly used in fields such as geographic information systems, computer-aided design, and game development.

[0060] It should be noted that in graphics applications, GPUs generally use deferred shading (i.e., deferred rendering) to render complex game scenes. Deferred rendering consists of two processing stages (i.e., passes): the geometry processing stage (i.e., geometry pass) and the lighting processing stage (i.e., lighting pass). As shown in Figure 4, in an image rendering scenario, when rendering a game screen including a character object, in the first geometry processing stage, the scene is rendered once, and then various geometric information of the character object is obtained and stored in a series of G-Buffer textures; in the second lighting processing stage, the texture data of the G-Buffer is used to perform more complex lighting calculations on the character object.

[0061] It should be noted that the above data may include but is not limited to the data listed above, that is, the above data may be any data that needs to be stored in the SLC.

[0062] For example, in an image rendering scenario, the data processing device sends a bus request to the SLC through the CPU, and the bus request is used to request the storage of Geometry data in the SLC; or, the data processing device sends a bus request to the SLC through the GPU, and the bus request is used to request the storage of intermediate data obtained through the Geometry Pass or frame data obtained through the Lighting Pass in the SLC.

[0063] Step S202: When the data processing device detects through the SLC that the first request carries the first buffer identifier, the data processing device adopts the storage strategy corresponding to the first buffer identifier to store the first data in the first data buffer into the SLC.

[0064] The first data buffer zone identifier is used to indicate the first data buffer zone.

[0065] In some embodiments of the present application, the first buffer zone identifier may be a hardware identifier (ie, hardware ID) of the buffer zone. For example, the first buffer zone identifier may be referred to as HW-BID.

[0066] It should be noted that the buffer identifier involved in the embodiment of the present application can be the physical address of the data buffer.

[0067] In some embodiments of the present application, the data processing device may create at least one data buffer through a processor (GPU or CPU), and allocate a hardware HW-BID to each data buffer.

[0068] In some embodiments of the present application, the storage strategy corresponding to the first buffer identifier includes any one of the following:

[0069] Storing the first data in the SLC and allowing the first data to reside in the SLC for a long time until an upper-layer application actively releases the data;

[0070] Storing the first data in the SLC and releasing the first data after the first data is read K times, where K is a positive integer;

[0071] The first data is not stored in the SLC.

[0072] It should be noted that the data processing device releases the data cached in the SLC from the SLC after the data has been read a certain number of times. The number of times the data is read can be one or more times, and the specific number can be determined based on the access characteristics of the data. For example, since the intermediate data cached in the GBuffer is usually only read once, the intermediate data in the GBuffer can be set to be released after being read once.

[0073] For example, if the first data is racing car model data in a racing game scene, the storage strategy for the first data may be to store the racing car model data in the SLC and keep it permanently resident in the SLC until the upper-layer application actively releases it, at which point the data processing device deletes the racing car model data from the SLC. In this way, racing car model data that needs to be reused across multiple game frame renderings in a racing game scene can be stored in the SLC for a long period of time, allowing it to be quickly retrieved from the SLC during subsequent game frame renderings.

[0074] For example, if the first data is intermediate data generated by the GPU geometrically processing the racing car model data in a racing game scene, the storage strategy for the first data can be to store the intermediate data in the SLC and release it after it is read once. In this way, intermediate data that is only needed once in the racing game scene can be temporarily stored in the SLC and deleted from the SLC after it is accessed, thus saving SLC storage space.

[0075] It should be noted that, in the embodiment of the present application, for some data that does not require fast access, the data processing device may not store it in the SLC to save the storage space of the SLC.

[0076] In some embodiments of the present application, the data processing device can assign buffer identifiers to different data buffers to mark the data buffers, and establish an association between the buffer identifier of the data buffer and the storage strategy of the data in the data buffer in the SLC. Then, when accessing the data buffer through a bus request, the buffer identifier of the data buffer to be accessed is carried in the bus request, so that the data in the data buffer can be stored in the SLC according to the storage strategy associated with the buffer identifier of the data buffer, thereby realizing differential storage and management of data in different data buffers.

[0077] It should be noted that accessing the buffer may include storing data in the data buffer to a storage space or reading data in the data buffer from the storage space.

[0078] In a data processing method provided by an embodiment of the present application, a data processing device receives a first request from a first unit through an SLC, the first request being used to request storage of data in a data buffer in the SLC. When the SLC detects that the first request carries a first buffer identifier, the first data in the first data buffer is stored in the SLC using a storage strategy corresponding to the first buffer identifier. The first data buffer identifier is used to indicate the first data buffer. The buffer is marked by the data buffer identifier to distinguish different data buffers, so that when accessing data in the buffer, the data buffer to which the data to be accessed belongs can be identified according to the data buffer identifier, and the data in the data buffer is stored using the storage strategy corresponding to the data buffer identifier. Thus, data in different data buffers can be stored according to the corresponding storage strategy, and the storage requirements of data in different data buffers can be met, so that data can be efficiently read from the SLC, thereby reducing the system bandwidth occupied when accessing data, and thus saving system power consumption.

[0079] In some embodiments of the present application, the above step S202 can be implemented by the following step S202a.

[0080] Step S202a: When it is detected through the SLC that the first request carries the first buffer identifier, the storage strategy corresponding to the first buffer identifier is searched from the first table according to the first buffer identifier, and the storage strategy corresponding to the first buffer identifier is used to store the first data in the SLC.

[0081] Among them, the above-mentioned first table includes at least one buffer identifier and a storage strategy corresponding to each buffer identifier. The data buffer indicated by a buffer identifier is used to store one type of data. Different types of data correspond to different storage strategies. Each storage strategy is determined by the upper-layer application based on the access characteristics of each type of data.

[0082] In some embodiments of the present application, data access characteristics may include data access capacity, access count, access bandwidth, etc. For example, in a racing game, the number of accesses to the "driver" data in the racing car model data is 5, the number of accesses to the "car outline" data in the racing car model data is 6, and the number of accesses to the "wheel" data is 7. It can be seen that in a racing game, the racing car model data is accessed multiple times.

[0083] In some embodiments of the present application, the data processing device may collect statistics on access characteristics of various types of data through an upper-layer application program to obtain access characteristics of each type of data.

[0084] In some embodiments of the present application, a buffer identifier in the first table indicates a data buffer, and a data buffer can store one type of data.

[0085] For example, taking the first table including three buffer identifiers as an example, the three buffer identifiers respectively indicate three data buffers: Geometry Buffer, GBuffer and Frame Buffer. The Geometry Buffer stores geometric data, the GBuffer stores intermediate data obtained after geometric processing of geometric type data, and the Frame Buffer stores frame data obtained after lighting processing of the intermediate data. The above three types of data are different types of data.

[0086] In some embodiments of the present application, the first table is maintained in the SLC hardware, and the upper-layer application completes the setting of the table through the register interface configuration.

[0087] It should be noted that the upper-layer application in the embodiment of the present application can also be referred to as upper-layer software.

[0088] In some embodiments of the present application, before the above-mentioned step S201, the data processing device obtains access characteristics of N types of data through an upper-layer application, and determines the storage strategies corresponding to the N types of data through the upper-layer application based on the access characteristics of the N types of data, and one type of data corresponds to one storage strategy. Then, the IDs of the N buffers corresponding to the above-mentioned N types of data are determined through the SLC, and a first table is generated based on the IDs of the above-mentioned N buffers and the storage strategies corresponding to the above-mentioned N types of data, where N is an integer greater than or equal to 1.

[0089] The following is an explanation of the relevant fields in the first table provided in the embodiment of the present application in conjunction with Table 2.

[0090] Among them, SW-BID and HW-BID represent the software and hardware IDs of the corresponding Data Buffer respectively.

[0091] The Enable field indicates whether the buffer storage policy is enabled in the SLC. If not enabled, the SLC will not cache the buffer data and will automatically clear the buffer data from the SLC.

[0092] The Current Size field indicates the storage space currently used by the buffer in the SLC.

[0093] The Buffer Size field indicates the actual capacity of the buffer.

[0094] The Release field indicates whether the buffer is in the process of active release.

[0095] The Passive Flush field indicates whether the buffer is passively cleared when it is released, that is, the SLC removes the buffer's cache line from the SLC according to the replacement policy.

[0096] The Write Policy field indicates the write storage policy of the buffer. 0 indicates no caching, and 1 indicates caching.

[0097] The Read Policy field indicates the buffer's read storage policy. 0 indicates no caching. S indicates that the buffer's cache line resides in the SLC until it is actively released. Other numbers indicate that the buffer's cache line is actively released after a corresponding number of read hits. For example, 1 indicates that the cache line is actively released after a single read hit.

[0098] The process of step S202a is explained below in combination with Table 2 and the above embodiment.

[0099] For example, taking the first unit as a GPU, the data processing device receives a bus request from the GPU through the SLC, where the bus request is used to request storage of geometric data in a data buffer in the SLC. The bus request carries an HW-BID (i.e., a first buffer identifier) ​​of 1. The data processing device obtains the storage strategy corresponding to the HW-BID with a value of 1 from the table through the SLC: the temporary storage space in the SLC is 1024 bytes, the capacity of the data buffer is 2048 bytes, and the data buffer is passively cleared when it is actively released. The data buffer is a write storage strategy, and the data in the data buffer resides in the SLC for a long time after being written to the SLC until it is actively released. After obtaining the storage strategy, the data processing device adopts the storage strategy to store and manage the geometric data in the buffer in the SLC.

[0100] In an embodiment of the present application, the data processing device can adjust the storage strategy of the SLC according to the access characteristics of the CPU and GPU to the data cache, further saving system bandwidth in the game scene, thereby saving system power consumption.

[0101] In some embodiments of the present application, before the above step S201, the data processing method provided in the embodiment of the present application may include the following steps S203 and S204:

[0102] Step S203: the data processing apparatus creates M second data buffers through the first processing unit, and allocates M buffer identifiers to the M second data buffers respectively.

[0103] The M second data buffers include the first data buffer, and M is an integer greater than or equal to 1.

[0104] Step S204: The data processing apparatus configures the M buffer identifiers in the Page Based Hardware Attributes (PBHA) bit fields of the M page table entries through the first processing unit.

[0105] The PBHA bit field of one of the page table entries is configured with one of the buffer zone identifiers, and the M page table entries are page table entries in the physical pages corresponding to the M second data buffer zones.

[0106] In some embodiments of the present application, the first processing unit may be a CPU or a GPU.

[0107] In some embodiments of the present application, the M second data buffers may include a Geometry Buffer, a GBuffer, a Frame Buffer, and the like.

[0108] It should be noted that the second data buffer includes but is not limited to the data buffers listed above. The second data buffer can be specifically set according to actual needs, and the embodiment of the present application does not limit this.

[0109] In some embodiments of the present application, for the creation process of each second data buffer, the first processing unit creates the second data buffer, applies for a software identifier (i.e., SW-BID) for the second data buffer, and calls the SLC driver (Driver), maps the SW-BID to the HW-BID (i.e., hardware identifier), then enables the HW-BID, and configures the storage policy of the HW-BID. For example, the storage policy is write cache, and it resides in the SLC for a long time until it is actively released by the upper-layer software.

[0110] For example, the GPU Driver creates a Geometry Buffer and applies for a software identifier SW-BID of 101, which can be expressed as SW-BID (101). Then, the SLC Driver is called to map the SW-BID to the HW-BID, which is 1, which can be expressed as HW-BID (1). Then, HW-BID (1) is enabled and the policy of HW-BID (1) is configured as write cache, which resides in the SLC for a long time until the upper-layer software actively releases it.

[0111] For another example, the GPU Driver creates a G-Buffer, applies for a software identifier SW-BID of 102, calls the SLC Driver, maps the S-DSID to HW-BID (2), enables HW-BID (2), and configures the storage policy of HW-BID (2) as a write cache, which is released after reading once.

[0112] As another example, the GPU Driver creates a Frame Buffer, applies for a software SW-BID (111), calls the SLC Driver, maps the SW-BID to the HW-BID (3), enables the HW-BID (3), and configures the policy of the HW-BID (1) to be a write cache and release after reading once.

[0113] In this way, the data processing device configures SLC storage policies for each buffer through upper-layer software. These policies ensure that buffers accessed repeatedly by the CPU and GPU are retained in the SLC, while buffers read and written once are promptly cleared from the SLC. These SLC management measures further conserve system bandwidth during data access, thereby reducing system power consumption.

[0114] In some possible implementations, the data processing device can configure a buffer identifier in the PBHA bit field in the ARM's PTE and pass the buffer identifier through the PBHA bit field. The SLC can identify the buffer identifier through the PBHA bit field and identify the data buffer to which the request from the CPU, GPU or other units belongs based on the buffer identifier.

[0115] In some embodiments of the present application, for each second data buffer, after creating the second data buffer and determining the HW-BID (i.e., buffer identifier) ​​of the second data buffer, the data processing device applies for system virtual address space for the second data buffer through the GPU or CPU, and calls the kernel interface to obtain the corresponding physical page, then initializes the CPU / GPU page table, and configures the PBHA attribute to the HW-BID of the second data buffer.

[0116] For example, when creating a Geometry Buffer and determining that the HW-BID of the Geometry Buffer is 1, the GPU Driver applies for the system virtual address space for the Geometry Buffer, calls the kernel interface to obtain the corresponding physical page, initializes the CPU / GPU page table, and configures the PBHA attribute to HW-BID (1).

[0117] In an embodiment of the present application, the data processing device uses the PBHA bit field of the upper attributes in the Arm64 Page Table Entry to pass the buffer identification information of the CPU and GPU data access. As shown in Figure 5, the PBHA of the Arm64 page table attributes allows the software to set up to 4 bits of custom attributes in the page table, which are propagated in the memory system through bus access. As shown in Figure 6A, when the CPU and GPU want to access the data buffer of the memory, the virtual address used needs to be converted into a physical address by the MMU module. The MMU module reads the attributes of the page table to obtain the PBHA attributes during address conversion, and passes the PBHA as the access buffer ID to the SLC.

[0118] In this embodiment of the present application, when a data processing device creates a data buffer through upper-layer software, it applies for memory space and initializes a page table. The upper-layer software then applies for a buffer identifier for the data buffer and writes the buffer ID into the PBHA bit field of the page table attributes. This allows the buffer identifier to be transmitted through the PBHA attribute, eliminating the need to occupy additional resources to transmit the buffer identifier and conserving system bandwidth resources.

[0119] In other possible implementations, the data processing device may allocate a buffer identifier in a special space, and the SLC may parse the special space to obtain the buffer identifier, and identify the data buffer to which the request from the CPU, GPU or other unit belongs based on the buffer identifier.

[0120] In some embodiments of the present application, the special space may be a special address segment allocated to a data cache that needs to be cached in the SLC. For example, the special space may be a specially designated special space, which may be a continuous address space. In other words, the use of the special space may require that the data cache use a continuous address space.

[0121] In some embodiments of the present application, for each second data buffer, after creating the second data buffer and determining the HW-BID of the second data buffer, the data processing device applies for a system virtual address space for the second data buffer through the GPU or CPU, calls the kernel interface to obtain the corresponding physical page, and then allocates the HW-BID of the second data buffer in a special address segment in the physical address space.

[0122] Exemplarily, when creating a Geometry Buffer and determining that the HW-BID of the Geometry Buffer is 1, the GPU Driver applies for a system virtual address space for the Geometry Buffer and calls the kernel interface to obtain the corresponding physical page. The system can allocate the physical address of the Geometry Buffer to a special space (such as 0x6000_0000-0x6F00_0000). Figure 6B is a schematic diagram of a special address segment in the physical address space provided by an embodiment of the present application. As shown in Figure 6B, the address segment range of the physical address space is 0x00_0000-0000 to 0xFF_FFFF-FFFF, wherein the address range of the special address segment is 0x00_6000-0000 to 0x00_6FFF-FFFF. The SLC obtains the buffer identifier of the Geometry Buffer by parsing the special address segment, and identifies that the request (such as the first request) issued by the CPU and GPU belongs to the Geometry Buffer based on the buffer identifier.

[0123] Specifically, the SLC identifies whether the physical address belongs to the buffer identifier that requires special processing and data cache of the SLC by decoding and parsing the physical address of the special address segment. For example, a system with a physical address of 48 bits and a maximum physical address space of 256G, where the address segment from 0x00_6000_0000 to 0x00_6FFF_FFFF is set as a special address segment, which is used to allocate to the data cache that needs to be cached in the SLC. Then, as shown in Figure 6C, the SLC parses the physical address as follows: Physical_Address[39:28] is parsed as the SLC identifier (SLC_identification), which is 0x006 in this example. Physical_Address[27:24] is parsed as the buffer identifier (Data Buffer ID). Physical_Address[27:24] includes 4 bits, which means that there are up to 16 Data Buffer IDs. The SLC determines whether the request is needed by comparing bits 39 to 28 of the physical address to see if they are equal to 0x006. It then further parses bits 27 to 24 of the physical address to obtain the data cache ID. By looking up Table 2 above, it obtains the management policy for the data cache in the SLC.

[0124] It should be noted that Physical_Address[39:28] represents bits 39 to 28 of the physical address.

[0125] In the embodiment of the present application, the SLC can parse the special address segment to obtain the buffer identifier and then search the table for the policy for caching data in the SLC based on the buffer identifier, thereby caching and managing data conveniently and efficiently. Furthermore, this approach reduces implementation costs by not requiring the physical address space to be divided into a special address segment.

[0126] In some embodiments of the present application, the data processing method provided in the embodiments of the present application may include the following steps S205 and S206:

[0127] Step S205: The data processing device receives a second request from the second unit through the SLC.

[0128] The second request is used to request to read data in the data buffer from the SLC, and the second request carries a first buffer identifier, which is used to indicate the first data buffer.

[0129] Step S205: the data processing device reads the first data in the first data buffer in the SLC according to the first buffer identifier through the SLC, and sends the first data to the second unit.

[0130] The second unit includes but is not limited to any one of the following: CPU, GPU, display unit, NPU, media subsystem, Modem, DSP module, WIFI module, ISP.

[0131] In some embodiments of the present application, the first data buffer may include but is not limited to at least one of a Geometry Buffer, a GBuffer, and a Frame Buffer.

[0132] In some embodiments of the present application, the above-mentioned first data may include but is not limited to any one of the following: geometric data stored in the Geometry Buffer, intermediate data stored in the GBuffer obtained after geometric processing of geometric type data, and frame data stored in the Frame Buffer obtained after lighting processing of the intermediate data.

[0133] For example, taking the second unit as a GPU, in a game scenario, the data processing device reads the Geometry data using HW-BID (1) through the GPU, and the data processing device detects the read request (i.e., the second request) carrying HW-BID (1) through the SLC, queries the SLC tag (Tag), and provides the Geometry data to the GPU.

[0134] As another example, let's take the GPU as the second unit. In a game scenario, the GPU Driver starts Lighting Render, and the GPU reads the G-Buffer data using HW-BID (2). The SLC detects the request from HW-BID (2), queries the SLC Tag, and then provides the data to the GPU. The data is then actively released and no longer stored in the SLC. The release here can be the SLC actively clearing the cache line corresponding to the G-Buffer, or the SLC marking the cache line corresponding to the G-Buffer as a priority replacement cache line and passively clearing the data from the SLC.

[0135] As another example, taking the second unit as the display unit, in a game scenario, the display unit reads the Frame Buffer, the SLC detects the request of HW-BID (3), queries the SLC Tag, provides the data to the Display, and actively releases the data so that it is no longer stored in the SLC.

[0136] In an embodiment of the present application, a buffer identifier is carried in a read request sent to the SLC through the CPU, GPU or display unit, so that the SLC can identify the data buffer to which the data that the CPU or GPU needs to access belongs, so that the SLC can quickly query the data that needs to be accessed in the data buffer and return the data to the CPU, GPU or display unit, thereby reducing the system bandwidth during data access and saving system power consumption.

[0137] The data processing method provided in the embodiments of the present application is described below through specific examples in combination with scenarios.

[0138] The data processing method provided in the embodiments of this application uses the data processing process of the three hardware modules, CPU, GPU, and Display, in a gaming scenario as an example to illustrate the use of the PBHA bit field or physical address in the PTE to identify data caches, thereby allowing the SLC to apply different management policies to unused data caches. However, the application scenarios of this invention are not limited to data processing of the CPU, GPU, and Display, and also include but are not limited to data processing of modules such as the NPU, Media System, Wi-Fi, DSP, and Modern.

[0139] For example, taking the GPU completing the deferred shading method as an example, as shown in FIG7 , the data processing method provided in the embodiment of the present application may include the following steps:

[0140] Step 1: The GPU Driver creates a Geometry Buffer, applies for a Buffer ID (SW-BID: 101), calls the SLC Driver, maps the SW-BID to the HW-BID (1), enables HW-BID (1), and configures the HW-BID (1) policy as a write cache, which resides in the SLC for a long time until the upper-layer software actively releases it.

[0141] It's important to note that in this step, the software buffer ID requested by the upper-layer software must be mapped to a hardware buffer ID through the SLC. This decouples the software's buffer ID request from the hardware's ID resources. Because the PBHA bit field is relatively efficient, typically 2-4 bits, hardware ID resources only have 4-16 IDs. However, upper-layer software may require hundreds or even thousands of buffers, a requirement that hardware ID resources cannot meet. Therefore, decoupling software and hardware buffer IDs facilitates buffer ID management and use by upper-layer software. Upper-layer software requests a SW-BID and only calls the SLC driver to request a HW-BID from the SLC hardware when it is actually needed. The SLC hardware then completes the mapping between the SW-BID and the HW-BID.

[0142] Step 2: The GPU Driver applies for system virtual address space for the Geometry Buffer, calls the kernel interface to obtain the corresponding physical page, initializes the CPU / GPU page table, and configures the PBHA attribute to HW-BID (1).

[0143] For example, the above step 2 can be replaced by the following step 2a: GPU Driver applies for system virtual address space for Geometry Buffer, calls the kernel interface to obtain the corresponding physical page, and the system can allocate HW-BID (1) of the physical address of Geometry Buffer to a special space such as (0x6000_0000-0x6F00_0000).

[0144] Step 3: The GPU Driver creates a G-Buffer, applies for a software SW-BID (102), calls the SLC Driver, maps the S-DSID to the HW-BID (2), enables the HW-BID (2), and configures the storage policy of the HW-BID (2) to write cache and release after reading once.

[0145] Step 4: The GPU Driver applies for system virtual address space for the G-Buffer, calls the kernel interface to obtain the corresponding physical page, initializes the CPU / GPU page table, and configures the PBHA attribute to HW-BID (2).

[0146] Exemplarily, the above step 4 can be replaced by the following step 4a: GPU Driver applies for system virtual address space for GBuffer, calls the kernel interface to obtain the corresponding physical page, and the system can allocate HW-BID (2) of the physical address of GBuffer to a special space.

[0147] Step 5: The GPU Driver starts the Geometry Render Pass. The CPU processes the geometry data and writes it out to HW-BID (1). The SLC detects the write request from HW-BID (1) and caches the data in the SLC.

[0148] Step 6: The GPU reads the Geometry data using HW-BID (1). The SLC detects the read request from HW-BID (1), queries the SLC Tag, and provides the data to the GPU.

[0149] Step 7: The GPU completes the Geometry Render Pass and writes the G-Buffer to HW-BID (2). The SLC detects the write request from HW-BID (2) and caches the data in the SLC.

[0150] Step 8: This step is implemented based on whether the GPU Driver decides to actively release the Geometry Buffer. If the GPU Driver decides to actively release the Geometry Buffer, it calls the SLC Driver and configures the SLC to release the data of HW-BID(1). The SLC invalidates all the cache lines of HW-BID(1). After completing the cache line invalidation operation of HW-BID(1), the GPU Driver calls the SLC Driver to disable HW-BID(1) and release the SW-BID and HW-BID corresponding to the Geometry Buffer.

[0151] Step 9: The GPU Driver creates a Frame Buffer, applies for a software SW-BID (111), calls the SLC Driver, maps the SW-BID to the HW-BID (3), enables the HW-BID (3), and configures the HW-BID (1) policy as a write cache that is released after reading once.

[0152] Step 10: The GPU Driver applies for system virtual address space for the Frame Buffer, calls the kernel interface to obtain the corresponding physical page, initializes the GPU page table, and configures the PBHA attribute to HW-BID (3).

[0153] Exemplarily, the above step 10 can be replaced by the following step 10a: the GPU Driver applies for system virtual address space for the Frame Buffer, calls the kernel interface to obtain the corresponding physical page, and the system can allocate HW-BID (3) of the physical address of the Frame Buffer to a special space.

[0154] Step 11: The GPU Driver starts Lighting Render, and the GPU reads the G-Buffer data using HW-BID (2). The SLC detects the request from HW-BID (2), queries the SLC Tag, and provides the data to the GPU. It then actively releases the data and no longer stores it in the SLC. This release can be the SLC actively clearing the cache line corresponding to the G-Buffer, or the SLC marking the cache line corresponding to the G-Buffer as a priority cache line and passively clearing the data from the SLC.

[0155] Step 12: The GPU completes the Lighting Render Pass and writes the Frame Buffer to HW-BID (3). The SLC detects the write request from HW-BID (3) and caches the data in the SLC.

[0156] Step 13: The Display module reads the Frame Buffer. The SLC detects the request from the HW-BID (3), queries the SLC Tag, and provides the data to the Display. The data is then actively released and no longer stored in the SLC.

[0157] The data processing method provided in the embodiment of the present application utilizes the PBHA bit field of the Arm64 Page Table Entry to retransmit the ID of the data buffer to the memory system, allowing the SLC to identify the buffer of the upper-layer application. Based on the access characteristics of the CPU and GPU to the data cache, the upper-layer software configures the SLC storage strategy for each buffer. These strategies ensure that buffers that are repeatedly accessed by the CPU and GPU can reside in the SLC, and buffers that are read and written once can be cleared in the SLC in a timely manner. These SLC management measures further save system bandwidth in gaming scenarios, thereby saving system power consumption.

[0158] An embodiment of the present application provides a data processing system, which includes: an SLC and a first unit, wherein: the above-mentioned SLC is used to receive a first request from the above-mentioned first unit, and the above-mentioned first request is used to request that data in a data buffer be stored in the above-mentioned SLC; the above-mentioned SLC is also used to, when detecting that the above-mentioned first request carries a first buffer identifier, adopt a storage strategy corresponding to the above-mentioned first buffer identifier to store the first data in the first data buffer to the SLC, and the above-mentioned first buffer identifier is used to indicate the above-mentioned first data buffer.

[0159] In some embodiments of the present application, the first unit includes any one of the following: CPU, GPU, display unit, NPU, media subsystem, Modem, DSP module, WIFI module, ISP.

[0160] In some embodiments of the present application, the above-mentioned SLC is specifically used to, when detecting that the above-mentioned first request carries the above-mentioned first buffer identifier, search the storage policy corresponding to the above-mentioned first buffer identifier from the first table according to the above-mentioned first buffer identifier, and adopt the storage policy corresponding to the above-mentioned first buffer identifier to store the above-mentioned first data in the above-mentioned SLC; wherein the above-mentioned first table includes at least one buffer identifier and a storage policy corresponding to each of the above-mentioned buffer identifiers, the data buffer indicated by a buffer identifier is used to store one type of data, different types of data correspond to different storage policies, and each storage policy is determined by the upper-layer application according to the access characteristics of each type of data.

[0161] In some embodiments of the present application, the storage strategy corresponding to the first buffer identifier includes any one of the following:

[0162] Storing the first data in the SLC and allowing the first data to reside in the SLC for a long time until an upper-layer application actively releases the data;

[0163] Storing the first data in the SLC and releasing the first data after the first data is read K times, where K is a positive integer;

[0164] The first data is not stored in the SLC.

[0165] In some embodiments of the present application, the data processing system further includes: a first processing unit;

[0166] The first processing unit is configured to create M second data buffers and allocate M buffer identifiers to each of the M second data buffers; the M second data buffers include the first data buffer, and M is an integer greater than or equal to 1;

[0167] The first processing unit is further configured to configure the M buffer identifiers in the PBHA bit fields of the M page table entries, one buffer identifier is configured in the PBHA bit field of one page table entry, and the M page table entries are page table entries in the physical pages corresponding to the M second data buffers.

[0168] In some embodiments of the present application, the system further includes: a second unit;

[0169] The SLC is further configured to receive a second request from the second unit, the second request being configured to request reading data from the data buffer from the SLC, the second request carrying a first buffer identifier, the first buffer identifier being configured to indicate a first data buffer;

[0170] The SLC is further configured to read the first data in the first data buffer in the SLC according to the first buffer identifier, and send the first data to the second unit;

[0171] The second unit includes any one of the following: CPU, GPU, display unit, NPU, media subsystem, Modem, DSP module, WIFI module, ISP.

[0172] It should be noted that the explanation of this embodiment can be found in the relevant explanation of the above method side embodiment, which will not be repeated here.

[0173] The above-mentioned method embodiments, or various possible implementation methods in each method embodiment, can be executed separately, or, under the premise that there is no contradiction, can also be executed in combination with each other. The specific implementation can be determined according to actual usage requirements, and the embodiments of the present application do not limit this.

[0174] The data processing method provided in the embodiment of the present application can be executed by a data processing device. In the embodiment of the present application, the data processing device provided in the embodiment of the present application is described by taking the data processing method executed by the data processing device as an example.

[0175] Figure 8 is a structural schematic diagram of a data processing device provided in an embodiment of the present application. As shown in Figure 8, the data processing device 800 may include: an acquisition module 801 and a control module 802, wherein: the above-mentioned acquisition module 801 is used to receive a first request from a first unit through a system-level cache SLC, and the above-mentioned first request is used to request that data in a data buffer be stored in the above-mentioned SLC; the above-mentioned control module 802 is used to, when it is detected through the above-mentioned SLC that the above-mentioned first request carries a first buffer identifier, adopt a storage strategy corresponding to the above-mentioned first buffer identifier to store the first data in the first data buffer to the SLC, and the above-mentioned first data buffer identifier is used to indicate the above-mentioned first data buffer.

[0176] In some embodiments of the present application, the first unit is any one of the following: a central processing unit (CPU), a graphics processing unit (GPU), a display unit, an NPU, a media subsystem, a modem, a DSP module, a WIFI module, and an ISP.

[0177] In some embodiments of the present application, the control module is specifically configured to: upon detecting, through the SLC, that the first request carries a first buffer identifier, search a first table for a storage policy corresponding to the first buffer identifier based on the first buffer identifier, and store the first data in the SLC using the storage policy corresponding to the first buffer identifier;

[0178] Among them, the above-mentioned first table includes at least one buffer identifier and a storage strategy corresponding to each of the above-mentioned buffer identifiers. The data buffer indicated by a buffer identifier is used to store one type of data. Different types of data correspond to different storage strategies. Each storage strategy is determined by the upper-layer application based on the access characteristics of each type of data.

[0179] In some embodiments of the present application, the storage strategy corresponding to the first buffer identifier includes any one of the following:

[0180] Storing the first data in the SLC and allowing the first data to reside in the SLC for a long time until an upper-layer application actively releases the first data;

[0181] Storing the first data in the SLC and releasing the first data after the first data is read K times, where K is a positive integer;

[0182] The first data is not stored in the SLC.

[0183] In some embodiments of the present application, the above-mentioned control module is also used to: create M second data buffers through the first processing unit, and allocate M buffer identifiers to the above-mentioned M second data buffers respectively, the above-mentioned M second data buffers include the above-mentioned first data buffer, and M is an integer greater than or equal to 1; configure the above-mentioned M buffer identifiers in the page-based hardware attribute PBHA bit field of the M page table entries through the above-mentioned first processing unit, and configure one buffer identifier in the PBHA bit field of the above-mentioned page table entry, and the above-mentioned M page table entries are page table entries in the physical pages corresponding to the above-mentioned M second data buffers.

[0184] In some embodiments of the present application, the acquisition module is further configured to receive a second request from the second unit through the SLC, the second request being configured to request reading data in the data buffer from the SLC, the second request carrying a first buffer identifier, the first buffer identifier being configured to indicate a first data buffer; the control module is further configured to read the first data in the first data buffer in the SLC according to the first buffer identifier through the SLC, and send the first data to the second unit;

[0185] The second unit includes any one of the following: CPU, GPU, display unit, NPU, media subsystem, Modem, DSP module, WIFI module, ISP.

[0186] The data processing device in the embodiment of the present application can be an electronic device or a component in the electronic device, such as an integrated circuit or a chip. The electronic device can be a terminal or other device other than a terminal. For example, the electronic device can be a mobile phone, a tablet computer, a laptop computer, a PDA, an in-vehicle electronic device, a mobile Internet device (MID), an augmented reality (AR) / virtual reality (VR) device, a robot, a wearable device, an ultra-mobile personal computer (UMPC), a netbook or a personal digital assistant (PDA), etc. It can also be a server, a network attached storage (NAS), a personal computer (PC), a television (TV), a teller machine or a self-service machine, etc., and the embodiment of the present application does not specifically limit it.

[0187] The data processing device in the embodiment of the present application may be a device having an operating system. The operating system may be an Android operating system, an iOS operating system, or other possible operating systems, which are not specifically limited in the embodiment of the present application.

[0188] The data processing device provided in the embodiment of the present application can implement each process implemented in the method embodiments of Figures 1 to 7. To avoid repetition, they will not be described here.

[0189] Optionally, as shown in Figure 9, an embodiment of the present application also provides an electronic device 900, including a processor 901 and a memory 902, and the memory 902 stores a program or instruction that can be run on the processor 901. When the program or instruction is executed by the processor 901, the various steps of the above-mentioned data processing method embodiment are implemented and the same technical effect can be achieved. To avoid repetition, it will not be repeated here.

[0190] It should be noted that the electronic devices in the embodiments of the present application include the mobile electronic devices and non-mobile electronic devices mentioned above.

[0191] FIG10 is a schematic diagram of the hardware structure of an electronic device implementing an embodiment of the present application.

[0192] The electronic device 100 includes but is not limited to components such as a radio frequency unit 101 , a network module 102 , an audio output unit 103 , an input unit 104 , a sensor 105 , a display unit 106 , a user input unit 107 , an interface unit 108 , a memory 109 , and a processor 110 .

[0193] Those skilled in the art will appreciate that the electronic device 100 may further include a power source (such as a battery) for powering various components. The power source may be logically connected to the processor 110 via a power management system, thereby enabling the power management system to manage charging, discharging, and power consumption. The electronic device structure shown in FIG10 does not limit the electronic device. The electronic device may include more or fewer components than shown, or may combine certain components or arrange the components differently, which will not be described in detail here.

[0194] Among them, the above-mentioned processor 110 is used to receive a first request from the first unit through the system-level cache SLC, and the above-mentioned first request is used to request to store the data in the data buffer in the above-mentioned SLC; the above-mentioned processor 110 is also used to adopt the storage strategy corresponding to the above-mentioned first buffer identifier when detecting that the above-mentioned first request carries a first buffer identifier through the above-mentioned SLC, and store the first data in the first data buffer to the SLC, and the above-mentioned first data buffer identifier is used to indicate the above-mentioned first data buffer.

[0195] In some embodiments of the present application, the first unit is any one of the following: CPU, GPU, display unit, NPU, media subsystem, Modem, DSP module, WIFI module, ISP.

[0196] In some embodiments of the present application, the processor 110 is specifically configured to: upon detecting, through the SLC, that the first request carries a first buffer identifier, search a first table for a storage policy corresponding to the first buffer identifier based on the first buffer identifier, and store the first data in the SLC using the storage policy corresponding to the first buffer identifier;

[0197] Among them, the above-mentioned first table includes at least one buffer identifier and a storage strategy corresponding to each of the above-mentioned buffer identifiers. The data buffer indicated by a buffer identifier is used to store one type of data. Different types of data correspond to different storage strategies. Each storage strategy is determined by the upper-layer application based on the access characteristics of each type of data.

[0198] In some embodiments of the present application, the storage strategy corresponding to the first buffer identifier includes any one of the following:

[0199] Storing the first data in the SLC and allowing the first data to reside in the SLC for a long time until an upper-layer application actively releases the first data;

[0200] Storing the first data in the SLC and releasing the first data after the first data is read K times, where K is a positive integer;

[0201] The first data is not stored in the SLC.

[0202] In some embodiments of the present application, the processor 110 is further configured to: create M second data buffers through a first processing unit, and allocate M buffer identifiers to the M second data buffers respectively, where the M second data buffers include the first data buffer, and M is an integer greater than or equal to 1; configure the M buffer identifiers in the page-based hardware attribute PBHA bit fields of the M page table entries through the first processing unit, and configure one buffer identifier in the PBHA bit field of one page table entry, where the M page table entries are page table entries in the physical pages corresponding to the M second data buffers.

[0203] In some embodiments of the present application, the processor 110 is further configured to receive, through the SLC, a second request from the second unit, the second request being configured to request reading data in the data buffer from the SLC, the second request carrying a first buffer identifier, the first buffer identifier being configured to indicate a first data buffer; the processor 110 is further configured to read, through the SLC, the first data in the first data buffer in the SLC according to the first buffer identifier, and send the first data to the second unit;

[0204] The second unit includes any one of the following: CPU, GPU, display unit, NPU, media subsystem, Modem, DSP module, WIFI module, ISP.

[0205] An electronic device provided in an embodiment of the present application receives a first request from a first unit through an SLC, the first request being used to request that data in a data buffer be stored in the SLC. When the SLC detects that the first request carries a first buffer identifier, the electronic device uses a storage strategy corresponding to the first buffer identifier to store the first data in the first data buffer in the SLC, wherein the first data buffer identifier is used to indicate the first data buffer. In this method, the electronic device marks the buffer using the data buffer identifier to distinguish different data buffers, so that when accessing data in the buffer, the data buffer to which the data to be accessed belongs can be identified according to the data buffer identifier, and the data in the data buffer can be stored using the storage strategy corresponding to the data buffer identifier, thereby enabling data in different data buffers to be stored according to the corresponding storage strategy, thereby meeting the storage requirements of data in different data buffers, thereby enabling efficient reading of data from the SLC, thereby reducing the system bandwidth occupied when accessing data, and thereby saving system power consumption.

[0206] It should be understood that in an embodiment of the present application, the input unit 104 may include a graphics processing unit (GPU) 1041 and a microphone 1042, and the graphics processor 1041 processes the image data of a static picture or video obtained by an image capture device (such as a camera) in a video capture mode or an image capture mode. The display unit 106 may include a display panel 1061, and the display panel 1061 may be configured in the form of a liquid crystal display unit, an organic light emitting diode, etc. The user input unit 107 includes a touch panel 1071 and at least one of other input devices 1072. The touch panel 1071 is also called a touch screen. The touch panel 1071 may include two parts: a touch detection device and a touch controller. Other input devices 1072 may include, but are not limited to, a physical keyboard, function keys (such as volume control keys, switch keys, etc.), a trackball, a mouse, and an operating stick, which will not be repeated here.

[0207] The memory 109 can be used to store software programs and various data. The memory 109 may mainly include a first storage area for storing programs or instructions and a second storage area for storing data, wherein the first storage area may store an operating system, applications or instructions required for at least one function (such as a sound playback function, an image playback function, etc.). In addition, the memory 109 may include a volatile memory or a non-volatile memory, or the memory 109 may include both volatile and non-volatile memories. Among them, the non-volatile memory may be a read-only memory (ROM), a programmable read-only memory (PROM), an erasable programmable read-only memory (EPROM), an electrically erasable programmable read-only memory (EEPROM), or a flash memory. The volatile memory may be a random access memory (RAM), a static random access memory (SRAM), a dynamic random access memory (DRAM), a synchronous dynamic random access memory (SDRAM), a double data rate synchronous dynamic random access memory (DDRSDRAM), an enhanced synchronous dynamic random access memory (ESDRAM), a synchronous link dynamic random access memory (SLDRAM), and a direct memory bus random access memory (DRRAM). The memory 109 in the embodiment of the present application includes but is not limited to these and any other suitable types of memory.

[0208] Processor 110 may include one or more processing units. Optionally, processor 110 integrates an application processor and a modem processor. The application processor primarily handles operations related to the operating system, user interface, and application programs, while the modem processor primarily processes wireless communication signals, such as a baseband processor. It is understood that the modem processor may not be integrated into processor 110.

[0209] An embodiment of the present application also provides a readable storage medium, on which a program or instruction is stored. When the program or instruction is executed by a processor, the various processes of the above-mentioned data processing method embodiment are implemented and the same technical effect can be achieved. To avoid repetition, it will not be repeated here.

[0210] The processor is the processor in the electronic device described in the above embodiment. The readable storage medium includes a computer readable storage medium, such as a computer read-only memory (ROM), a random access memory (RAM), a magnetic disk, or an optical disk.

[0211] An embodiment of the present application further provides a chip, which includes a processor and a communication interface, wherein the communication interface is coupled to the processor, and the processor is used to run programs or instructions to implement the various processes of the above-mentioned data processing method embodiment and can achieve the same technical effect. To avoid repetition, it will not be repeated here.

[0212] It should be understood that the chip mentioned in the embodiments of the present application can also be called a system-level chip, a system chip, a chip system or a system-on-chip chip, etc.

[0213] An embodiment of the present application provides a computer program product, which is stored in a storage medium. The program product is executed by at least one processor to implement the various processes of the above-mentioned data processing method embodiment and can achieve the same technical effect. To avoid repetition, it will not be repeated here.

[0214] It should be noted that, in this article, the terms "comprise", "include" or any other variants thereof are intended to cover non-exclusive inclusion, so that a process, method, article or device comprising a series of elements includes not only those elements, but also other elements not explicitly listed, or also includes elements inherent to such process, method, article or device. In the absence of further restrictions, an element defined by the statement "comprises a ..." does not exclude the presence of other identical elements in the process, method, article or device comprising the element. In addition, it should be noted that the scope of the methods and devices in the embodiments of the present application is not limited to performing functions in the order shown or discussed, and may also include performing functions in a substantially simultaneous manner or in the opposite order according to the functions involved. For example, the described method may be performed in an order different from that described, and various steps may also be added, omitted, or combined. In addition, the features described with reference to certain examples may be combined in other examples.

[0215] Through the description of the above implementation methods, those skilled in the art can clearly understand that the above-mentioned embodiment methods can be implemented by means of software plus the necessary general hardware platform, and of course can also be implemented by hardware, but in many cases the former is a better implementation method. Based on this understanding, the technical solution of the present application is essentially or the part that contributes to the prior art can be embodied in the form of a computer software product, which is stored in a storage medium (such as ROM / RAM, magnetic disk, optical disk), including a number of instructions for enabling a terminal (which can be a mobile phone, computer, server, or network device, etc.) to execute the methods described in each embodiment of the present application.

[0216] The embodiments of the present application are described above in conjunction with the accompanying drawings, but the present application is not limited to the above-mentioned specific implementation methods. The above-mentioned specific implementation methods are merely illustrative and not restrictive. Under the guidance of this application, ordinary technicians in this field can also make many forms without departing from the purpose of this application and the scope of protection of the claims, all of which are within the protection of this application.

Claims

1. A data processing method, comprising: receiving, through a system-level cache (SLC), a first request from a first unit, wherein the first request is for requesting to store data in a data buffer in the SLC; When the SLC detects that the first request carries a first buffer identifier, the first data in the first data buffer is stored in the SLC using a storage strategy corresponding to the first buffer identifier, where the first data buffer identifier is used to indicate the first data buffer.

2. The method according to claim 1, wherein The first unit includes any one of the following: a central processing unit CPU, a graphics processing unit GPU, a display unit, a neural network processor NPU, a media subsystem, a modem Modem, a digital signal processing DSP module, a wireless fidelity WIFI module, and an image signal processor ISP.

3. The method according to claim 1, wherein The storing the first data in the SLC by using a storage strategy corresponding to the first buffer zone identifier when detecting, through the SLC, that the first request carries the first buffer zone identifier includes: When the SLC detects that the first request carries a first buffer identifier, searching a first table for a storage policy corresponding to the first buffer identifier according to the first buffer identifier, and storing the first data in the SLC using the storage policy corresponding to the first buffer identifier; Among them, the first table includes at least one buffer identifier and a storage strategy corresponding to each buffer identifier. The data buffer indicated by a buffer identifier is used to store one type of data. Different types of data correspond to different storage strategies. Each storage strategy is determined by the upper-layer application based on the access characteristics of each type of data.

4. The method according to any one of claims 1 to 3, wherein The storage strategy corresponding to the first buffer identifier includes any one of the following: storing the first data in the SLC, and allowing the first data to reside in the SLC for a long time until an upper-layer application actively releases the first data; storing the first data in the SLC, and releasing the first data after the first data is read K times, where K is a positive integer; The first data is not stored in the SLC.

5. The method according to any one of claims 1 to 3, wherein Before receiving, through the SLC, the first request from the first unit, the method further includes: Creating M second data buffers by the first processing unit, and allocating M buffer identifiers to the M second data buffers respectively, wherein the M second data buffers include the first data buffer, and M is an integer greater than or equal to 1; The first processing unit configures the M buffer identifiers in the PBHA bit fields of the M page table entries, one buffer identifier is configured in the PBHA bit field of one page table entry, and the M page table entries are page table entries in the physical pages corresponding to the M second data buffers.

6. The method according to claim 1, wherein The method further comprises: receiving, through the SLC, a second request from a second unit, where the second request is used to request reading data in a data buffer from the SLC, and the second request carries the first buffer identifier; reading the first data in the first data buffer in the SLC according to the first buffer identifier through the SLC, and sending the first data to the second unit; The second unit includes any one of the following: CPU, GPU, display unit, NPU, media subsystem, Modem, DSP module, WIFI module, ISP.

7. A data processing system, comprising: SLC and Unit 1, where: The SLC is configured to receive a first request from the first unit, wherein the first request is configured to request storage of data in a data buffer in the SLC; The SLC is further used to store the first data in the first data buffer to the SLC using a storage strategy corresponding to the first buffer identifier when detecting that the first request carries a first buffer identifier, where the first buffer identifier is used to indicate the first data buffer.

8. The system according to claim 7, wherein: The first unit includes any one of the following: CPU, GPU, display unit, NPU, media subsystem, Modem, DSP module, WIFI module, ISP.

9. The system according to claim 7, wherein: The SLC is specifically configured to, when detecting that the first request carries the first buffer identifier, search a first table for a storage policy corresponding to the first buffer identifier according to the first buffer identifier, and store the first data in the SLC using the storage policy corresponding to the first buffer identifier; Among them, the first table includes at least one buffer identifier and a storage strategy corresponding to each buffer identifier. The data buffer indicated by a buffer identifier is used to store one type of data. Different types of data correspond to different storage strategies. Each storage strategy is determined by the upper-layer application based on the access characteristics of each type of data.

10. The system according to any one of claims 7 to 9, wherein: The storage strategy corresponding to the first buffer identifier includes any one of the following: storing the first data in the SLC, and allowing the first data to reside in the SLC for a long time until an upper-layer application actively releases the data; storing the first data in the SLC, and releasing the first data after the first data is read K times, where K is a positive integer; The first data is not stored in the SLC.

11. The system according to claim 7 to 9, wherein: The data processing system further includes: a first processing unit; The first processing unit is configured to create M second data buffers and allocate M buffer identifiers to the M second data buffers respectively; the M second data buffers include the first data buffer, and M is an integer greater than or equal to 1; The first processing unit is further configured to configure the M buffer identifiers in the PBHA bit fields of the M page table entries, one buffer identifier is configured in the PBHA bit field of one page table entry, and the M page table entries are page table entries in the physical pages corresponding to the M second data buffers.

12. The system according to claim 7, wherein: The system further comprises: a second unit; The SLC is further configured to receive a second request from the second unit, where the second request is configured to request reading data in a data buffer from the SLC, and the second request carries an identifier of the first buffer; The SLC is further configured to read the first data in the first data buffer in the SLC according to the first buffer identifier, and send the first data to the second unit; The second unit includes any one of the following: CPU, GPU, display unit, NPU, media subsystem, Modem, DSP module, WIFI module, ISP.

13. A data processing device, comprising: Acquisition module and control module, where: The acquisition module is configured to receive a first request from a first unit through a system level cache (SLC), wherein the first request is configured to request that the data in the data buffer be stored in the SLC; The control module is used to store the first data in the first data buffer to the SLC using the storage strategy corresponding to the first buffer identifier when detecting through the SLC that the first request carries a first buffer identifier, wherein the first data buffer identifier is used to indicate the first data buffer.

14. The device according to claim 13, wherein The first unit is any one of the following: central processing unit CPU, graphics processing unit GPU, display unit, NPU, media subsystem, modem, DSP module, WIFI module, ISP.

15. The device according to claim 13 or 14, wherein The control module is specifically configured to: when detecting through the SLC that the first request carries a first buffer identifier, search a first table for a storage policy corresponding to the first buffer identifier according to the first buffer identifier, and store the first data in the SLC using the storage policy corresponding to the first buffer identifier; Among them, the first table includes at least one buffer identifier and a storage strategy corresponding to each buffer identifier. The data buffer indicated by a buffer identifier is used to store one type of data. Different types of data correspond to different storage strategies. Each storage strategy is determined by the upper-layer application based on the access characteristics of each type of data.

16. The device according to any one of claims 13 to 15, wherein The storage strategy corresponding to the first buffer identifier includes any one of the following: storing the first data in the SLC, and allowing the first data to reside in the SLC for a long time until an upper-layer application actively releases the first data; storing the first data in the SLC, and releasing the first data after the first data is read K times, where K is a positive integer; The first data is not stored in the SLC.

17. The device according to any one of claims 13 to 15, wherein The control module is further configured to: Creating M second data buffers by the first processing unit, and allocating M buffer identifiers to the M second data buffers respectively, wherein the M second data buffers include the first data buffer, and M is an integer greater than or equal to 1; The first processing unit configures the M buffer identifiers in the PBHA bit fields of the M page table entries, one buffer identifier is configured in the PBHA bit field of one page table entry, and the M page table entries are page table entries in the physical pages corresponding to the M second data buffers.

18. The device according to claim 13, wherein The acquisition module is further configured to receive a second request from a second unit through the SLC, where the second request is configured to request reading data in a data buffer from the SLC, and the second request carries the first buffer identifier; The control module is further configured to read the first data in the first data buffer in the SLC according to the first buffer identifier through the SLC, and send the first data to the second unit; The second unit includes any one of the following: CPU, GPU, display unit, NPU, media subsystem, Modem, DSP module, WIFI module, ISP.

19. An electronic device comprising a processor and a memory, wherein the memory stores a program or instruction that can be run on the processor, and when the program or instruction is executed by the processor, the processor performs the following operations: receiving, through a system-level cache (SLC), a first request from a first unit, wherein the first request is for requesting to store data in a data buffer in the SLC; When the SLC detects that the first request carries a first buffer identifier, the first data in the first data buffer is stored in the SLC using a storage strategy corresponding to the first buffer identifier, where the first data buffer identifier is used to indicate the first data buffer.

20. The electronic device according to claim 19, wherein The first unit includes any one of the following: a central processing unit CPU, a graphics processing unit GPU, a display unit, a neural network processor NPU, a media subsystem, a modem Modem, a digital signal processing DSP module, a wireless fidelity WIFI module, and an image signal processor ISP.

21. The electronic device according to claim 19, wherein The processor specifically performs the following operations: when detecting, through the SLC, that the first request carries a first buffer identifier, searching a first table for a storage policy corresponding to the first buffer identifier according to the first buffer identifier, and storing the first data in the SLC using the storage policy corresponding to the first buffer identifier; Among them, the first table includes at least one buffer identifier and a storage strategy corresponding to each buffer identifier. The data buffer indicated by a buffer identifier is used to store one type of data. Different types of data correspond to different storage strategies. Each storage strategy is determined by the upper-layer application based on the access characteristics of each type of data.

22. The electronic device according to claims 19 to 21, wherein: The storage strategy corresponding to the first buffer identifier includes any one of the following: storing the first data in the SLC, and allowing the first data to reside in the SLC for a long time until an upper-layer application actively releases the first data; storing the first data in the SLC, and releasing the first data after the first data is read K times, where K is a positive integer; The first data is not stored in the SLC.

23. The electronic device according to claims 19 to 21, wherein: The processor also performs the following operations: Creating M second data buffers by the first processing unit, and allocating M buffer identifiers to the M second data buffers respectively, wherein the M second data buffers include the first data buffer, and M is an integer greater than or equal to 1; The M buffer identifiers are configured in the PBHA bit fields of the M page table entries by the first processing unit, one buffer identifier is configured in the PBHA bit field of one page table entry, and the M page table entries are page table entries in the physical pages corresponding to the M second data buffers.

24. The electronic device according to claim 19, wherein The processor also performs the following operations: receiving, through the SLC, a second request from a second unit, where the second request is used to request reading data in a data buffer from the SLC, and the second request carries the first buffer identifier; reading the first data in the first data buffer in the SLC according to the first buffer identifier through the SLC, and sending the first data to the second unit; The second unit includes any one of the following: CPU, GPU, display unit, NPU, media subsystem, Modem, DSP module, WIFI module, ISP.

25. A readable storage medium storing a program or instruction, wherein the program or instruction, when executed by a processor, implements the steps of the data processing method according to any one of claims 1 to 6.

26. A chip comprising a processor and a communication interface, wherein the communication interface is coupled to the processor, and the processor is configured to run a program or instruction to perform the following operations: receiving, through a system-level cache (SLC), a first request from a first unit, wherein the first request is for requesting to store data in a data buffer in the SLC; When the SLC detects that the first request carries a first buffer identifier, the first data in the first data buffer is stored in the SLC using a storage strategy corresponding to the first buffer identifier, where the first data buffer identifier is used to indicate the first data buffer.

27. The chip according to claim 26, wherein: The first unit includes any one of the following: a central processing unit CPU, a graphics processing unit GPU, a display unit, a neural network processor NPU, a media subsystem, a modem Modem, a digital signal processing DSP module, a wireless fidelity WIFI module, and an image signal processor ISP.

28. The chip according to claim 26, wherein The processor specifically performs the following operations: when detecting, through the SLC, that the first request carries a first buffer identifier, searching a first table for a storage policy corresponding to the first buffer identifier according to the first buffer identifier, and storing the first data in the SLC using the storage policy corresponding to the first buffer identifier; Among them, the first table includes at least one buffer identifier and a storage strategy corresponding to each buffer identifier. The data buffer indicated by a buffer identifier is used to store one type of data. Different types of data correspond to different storage strategies. Each storage strategy is determined by the upper-layer application based on the access characteristics of each type of data.

29. The chip according to claims 26 to 28, wherein: The storage strategy corresponding to the first buffer identifier includes any one of the following: storing the first data in the SLC, and allowing the first data to reside in the SLC for a long time until an upper-layer application actively releases the first data; storing the first data in the SLC, and releasing the first data after the first data is read K times, where K is a positive integer; The first data is not stored in the SLC.

30. The chip according to claims 26 to 28, wherein The processor also performs the following operations: Creating M second data buffers by the first processing unit, and allocating M buffer identifiers to the M second data buffers respectively, wherein the M second data buffers include the first data buffer, and M is an integer greater than or equal to 1; The M buffer identifiers are configured in the PBHA bit fields of the M page table entries by the first processing unit, one buffer identifier is configured in the PBHA bit field of one page table entry, and the M page table entries are page table entries in the physical pages corresponding to the M second data buffers.

31. The chip according to claim 26, wherein The processor also performs the following operations: receiving, through the SLC, a second request from a second unit, where the second request is used to request reading data in a data buffer from the SLC, and the second request carries the first buffer identifier; reading the first data in the first data buffer in the SLC according to the first buffer identifier through the SLC, and sending the first data to the second unit; The second unit includes any one of the following: CPU, GPU, display unit, NPU, media subsystem, Modem, DSP module, WIFI module, ISP.

32. A computer program product, wherein the computer program product is stored in a storage medium and is executed by at least one processor to implement the data processing method according to any one of claims 1 to 6.

Images