Address mapping method and apparatus

Abstract

Embodiments of the present application provide an address mapping method and apparatus. In the method, a memory allocation operation can be divided into a production phase and a consumption phase; and in each phase, virtual addresses are only dynamically mapped to related chips as required, so that the chips do not affect each other. In this way, a shared physical memory between a plurality of chips can be increased, thereby improving the overall performance of an electronic device.

Description

Address mapping method and apparatus

[0001] This application claims priority to Chinese Patent Application No. 202411319910.6, filed on September 20, 2024, entitled “Address Mapping Method and Apparatus”, the entire contents of which are incorporated herein by reference. Technical Field

[0002] This application relates to the field of electronic devices, and more particularly to an address mapping method and apparatus. Background Technology

[0003] With the rapid development of electronic devices, the performance of some hardware components is also becoming stronger. For example, the bit width of hardware such as graphics processing units (GPUs) and central processing units (CPUs) in electronic devices is also increasing.

[0004] However, while the hardware performance of electronic devices is becoming increasingly powerful, the overall performance improvement of electronic devices is not significant. Summary of the Invention

[0005] This application provides an address mapping method and apparatus. This facilitates the improvement of shared physical memory among multiple chips, thereby enhancing the overall performance of electronic devices.

[0006] In a first aspect, embodiments of this application propose an address mapping method applied to an electronic device, which includes a first application, a first device, a second device, a third device, and physical memory. The bit widths of the first device, the second device, and the third device are not completely equal. The method may include...

[0007] The first application requests memory. Then, the electronic device requests a first virtual address for a first device and a second virtual address for a second device, allocates first memory in physical memory, and maps the first and second virtual addresses to first physical addresses in the first memory. The first memory is used to store at least the first data written by the first device. Next, the electronic device requests a third virtual address for a third device and maps the third virtual address to the first physical address. The third device then retrieves the first data from the first memory corresponding to the first physical address for processing.

[0008] In this embodiment, during the data production phase, by requesting a first virtual address for a first device, allocating first memory in physical memory, and mapping the first virtual address to a first physical address in the first memory, the first device can write first data to the first memory. Then, by requesting a second virtual address for a second device and mapping it to a first physical address in the first memory, the second device can write second data to the first memory if acting as a producer device, and can also retrieve first data from the first memory for processing if acting as a consumer device. Then, when a third device acts as a consumer device, it can request a third virtual address and map it to a first physical address, allowing the third device to retrieve first data from the first memory corresponding to the first physical address for processing. By dividing the virtual address mapping into multiple phases, such as a data production phase and a data consumption phase, shared physical memory can be dynamically mapped to the virtual addresses of multiple chips, thereby improving the overall performance of the electronic device.

[0009] In one possible implementation, after the first application requests memory, the method may further include:

[0010] A first identifier is set for the first device and the second device, the first identifier indicating that the device has been mapped to a first physical address.

[0011] In this embodiment, setting a first identifier for the first device indicates that the first device has been mapped to a first physical address; in other words, the virtual address of the first device has been mapped to the first physical address. Setting a second identifier for the second device indicates that the second device has been mapped to the first physical address; in other words, the virtual address of the second device has been mapped to the first physical address. Optionally, the identifier in this embodiment may also be referred to as a flag bit.

[0012] In this embodiment, by setting an identifier after the virtual address of the device is mapped to the physical address, it can be determined whether the physical address is mapped to the virtual address of the device. This allows for timely reading and writing of data in the memory corresponding to the physical address, thereby improving data processing efficiency. Furthermore, it can reduce the number of virtual addresses required for the device.

[0013] In one possible implementation, requesting a third virtual address for the third device and mapping the third virtual address to a first physical address includes:

[0014] If it is determined that data is processed by a third device and a first identifier of the third device is not set, a third virtual address of the third device is requested, and the third virtual address is mapped to a first physical address, and a first identifier of the third device is set, the first identifier indicating that the device has been mapped to the first physical address.

[0015] In this embodiment of the application, if it is determined that the data is processed by the third device and the first identifier of the third device is not set, it means that the virtual address of the third device has not yet been mapped to the first physical address. Therefore, the third virtual address of the third device can be applied for and mapped to the first physical address. In other words, when the third device is a consumer device, the identifier is used to determine whether it is necessary to apply for the virtual address of the third device and map it to the first physical address. This can improve the accuracy and efficiency of applying for and mapping the virtual address of the third device.

[0016] In one possible implementation, before requesting a third virtual address for the third device and mapping the third virtual address to the first physical address, the method further includes:

[0017] Acquire a first set and a second set, wherein the first set includes a device with a first identifier set, and the second set includes a device for processing data, wherein the device with the first identifier set includes a first device and a second device, and the device for processing data includes a third device;

[0018] If a first difference set is determined to exist based on the first set and the second set, a virtual device of the device in the first difference set is requested, and the virtual device of the device in the first difference set is mapped to a first physical address. The device in the first difference set is a device in the second set and the device in the first difference set is different from any device in the first set.

[0019] Requesting a third virtual address for a third device and mapping the third virtual address to a first physical address includes:

[0020] If the first difference set includes the third device, a third virtual address of the third device is requested, and the third virtual address is mapped to the first physical address.

[0021] In this embodiment, the devices in the first difference set are determined consumer devices that are not marked with a first identifier. That is, the devices in the first difference set need to apply for a virtual address and map it to a first physical address. If the first difference set includes a third device, it means that the third device needs to apply for a virtual address and map it to a first physical address. Therefore, a third virtual address of the third device is applied for, and the third virtual address is mapped to the first physical address.

[0022] In one possible implementation, the electronic device further includes a first service, whereby a first application requests memory, including:

[0023] The first application requests memory from the first service;

[0024] Requesting a first virtual address for a first device and a second virtual address for a second device, allocating first memory in physical memory, and mapping the first virtual address and the second virtual address to the first physical address in the first memory, respectively, includes:

[0025] The first service requests a first virtual address for a first device and a second virtual address for a second device, allocates first memory in physical memory, and maps the first virtual address and the second virtual address to the first physical address in the first memory, respectively.

[0026] In this embodiment, the first application can request memory from the first service. The first service can then request a first virtual address of the first device and a second virtual address of the second device, allocate first memory in physical memory, and map the first virtual address and the second virtual address to the first physical address of the first memory, respectively. This reduces the inefficiency and resource consumption caused by multiple services interacting to achieve address mapping, thereby improving the efficiency of address mapping and reducing resource consumption.

[0027] In one possible implementation, requesting a third virtual address for the third device and mapping the third virtual address to a first physical address includes:

[0028] The first service requests a third virtual address for the third device and maps the third virtual address to the first physical address.

[0029] In this embodiment of the application, the first service can also apply for and map the virtual address of the third device. This can reduce the inefficiency and resource consumption caused by multiple services interacting to achieve address mapping, thereby improving the efficiency of address mapping and reducing resource consumption.

[0030] In one possible implementation, the first application requests memory, including:

[0031] The first application responds to opening a window on the electronic device by requesting graphics memory, which is used to store the graphics data required by the window.

[0032] In this embodiment of the application, the first application requests graphics memory in response to opening a window on the electronic device, which can increase the number of windows that the electronic device can open.

[0033] In one possible implementation, the first memory is also used to store the second data written by the second device, that is, the second device writes data to the first memory as a producer device.

[0034] In another possible implementation, requesting a second virtual address for the second device includes:

[0035] If it is determined that data is processed through the second device and the first identifier of the second device is not set, a second virtual address of the second device is requested, and the first identifier of the second device is set, wherein the first identifier indicates that the device has been mapped to the first physical address.

[0036] In this embodiment, the second device serves as a consumer device. If it is determined that access is required through the second device and the first identifier of the second device is not set, it indicates that the virtual address of the second device is not mapped to the first physical address. Consequently, the second device cannot access the first memory normally. Therefore, a second virtual address of the second device is requested, which maps the second virtual address to the first physical address, enabling the second device to access the first memory normally and then obtain the first data from the first memory for processing.

[0037] Secondly, embodiments of this application provide an address mapping apparatus, including a processor coupled to a memory, which can be used to execute instructions in the memory to implement the method in any possible implementation of the first aspect described above. Optionally, the apparatus further includes a memory. Optionally, the apparatus further includes a communication interface, to which the processor is coupled.

[0038] Thirdly, embodiments of this application provide a processor, including: an input circuit, an output circuit, and a processing circuit. The processing circuit is used to receive signals through the input circuit and transmit signals through the output circuit, causing the processor to execute the method in any possible implementation of the first aspect described above.

[0039] In specific implementation, the processor can be a chip, the input circuit can be an input pin, the output circuit can be an output pin, and the processing circuit can be a transistor, gate circuit, flip-flop, and various logic circuits. The input signal received by the input circuit can be received and input by, for example, but not limited to, a receiver, and the signal output by the output circuit can be output to, for example, but not limited to, a transmitter and transmitted by the transmitter. Furthermore, the input circuit and the output circuit can be the same circuit, which is used as the input circuit and the output circuit at different times. This application does not limit the specific implementation of the processor and various circuits.

[0040] Fourthly, an address mapping apparatus is provided, including a processor and a memory. The processor is used to read instructions stored in the memory and can receive signals via a receiver and transmit signals via a transmitter to execute the method in any of the possible implementations of the first aspect described above.

[0041] Optionally, there may be one or more processors and one or more memories.

[0042] Alternatively, the memory can be integrated with the processor, or the memory can be set up separately from the processor.

[0043] In specific implementation, the memory can be a non-transitory memory, such as read-only memory (ROM), which can be integrated with the processor on the same chip or set on different chips. The embodiments of this application do not limit the type of memory or the way the memory and processor are set.

[0044] It should be understood that the relevant data interaction process, such as sending indication information, can be the process of outputting indication information from the processor, and receiving capability information can be the process of the processor receiving input capability information. Specifically, the processed output data can be output to the transmitter, and the input data received by the processor can come from the receiver. Here, the transmitter and receiver can be collectively referred to as a transceiver.

[0045] The address mapping device in the fourth aspect above can be a chip. The processor can be implemented in hardware or software. When implemented in hardware, the processor can be a logic circuit, integrated circuit, etc. When implemented in software, the processor can be a general-purpose processor that reads software code stored in memory. The memory can be integrated into the processor or located outside the processor and exist independently.

[0046] Fifthly, a computer program product is provided, comprising: a computer program (also referred to as code or instructions) that, when executed, causes a computer to perform the method in any of the possible implementations of the first aspect above.

[0047] In a sixth aspect, a computer-readable storage medium is provided that stores a computer program (also referred to as code or instructions) that, when executed on a computer, causes the computer to perform the methods in any of the possible implementations of the first aspect described above. Attached Figure Description

[0048] Figure 1 is a schematic diagram of a scenario where multiple chips perform data processing according to an embodiment of this application;

[0049] Figure 2 is a schematic diagram showing the limitations of the overall usable memory size of electronic devices in related technologies;

[0050] Figure 3 is a schematic diagram of the hardware architecture of an electronic device provided in an embodiment of this application;

[0051] Figure 4 is a schematic diagram of the software architecture of an electronic device provided in an embodiment of this application;

[0052] Figure 5 is a schematic diagram of a data processing system architecture provided in an embodiment of this application;

[0053] Figure 6 is a flowchart illustrating a method for dynamically mapping shared physical memory to virtual addresses of multiple devices according to an embodiment of this application;

[0054] Figure 7 is a flowchart illustrating another method for dynamically mapping shared physical memory to virtual addresses of multiple devices according to an embodiment of this application;

[0055] Figure 8 is a schematic diagram of physical memory usage provided in an embodiment of this application;

[0056] Figure 9 is a flowchart illustrating an address mapping method provided in an embodiment of this application;

[0057] Figure 10 is a schematic diagram of the frame of an address mapping device provided in an embodiment of this application. Detailed Implementation

[0058] To make the objectives and technical solutions of this application clearer and more intuitive, the embodiments of this application will be described in detail below with reference to the accompanying drawings and examples, illustrating the address mapping method and apparatus. It should be understood that the specific embodiments described herein are merely illustrative and are not intended to limit the scope of this application.

[0059] Before introducing the methods and apparatus provided in the embodiments of this application, the following points should be made first.

[0060] First, in the embodiments shown below, the terms and English abbreviations, such as CPU, are merely exemplary examples given for ease of description and should not be construed as limiting this application. This application does not preclude the possibility of defining other terms that can achieve the same or similar functions in existing or future agreements.

[0061] Second, in the embodiments shown below, the first, second, and various numerical designations are merely distinctions for ease of description and are not intended to limit the scope of the embodiments of this application.

[0062] Third, "at least one" means one or more, while "more than one" means two or more. "And / or" describes the relationship between related objects, indicating that three relationships can exist. For example, A and / or B can mean: A alone, A and B simultaneously, or B alone, where A and B can be singular or plural. The character " / " generally indicates that the preceding and following related objects are in an "or" relationship. "At least one of the following" or similar expressions refer to any combination of these items, including any combination of single or plural items. For example, at least one of a, b, and c can mean: a, or b, or c, or a and b, or a and c, or b and c, or a, b, and c, where a, b, and c can be single or multiple.

[0063] The technical solutions in this application will now be described with reference to the accompanying drawings.

[0064] The technical solutions of this application can be applied to various communication systems, such as: Long Term Evolution (LTE) system, LTE Frequency Division Duplex (FDD) system, LTE Time Division Duplex (TDD) system, Universal Mobile Telecommunication System (UMTS), 5th Generation (5G) system, or New Radio (NR) system, or other evolved communication systems.

[0065] The terminal equipment in this application embodiment can also be referred to as: user equipment (UE), mobile station (MS), mobile terminal (MT), access terminal, user unit, user station, mobile station, mobile station, remote station, remote terminal, mobile device, user terminal, terminal, equipment, wireless communication equipment, electronic device, user agent, or user device, etc.

[0066] Terminal devices can be devices that provide voice / data connectivity to users, such as handheld devices with wireless connectivity, in-vehicle devices, etc. Currently, examples of terminals include: mobile phones, car infotainment systems, tablets, laptops, PDAs, mobile internet devices (MIDs), wearable devices, virtual reality (VR) devices, augmented reality (AR) devices, wireless terminals in industrial control, wireless terminals in self-driving vehicles, wireless terminals in remote medical surgery, wireless terminals in smart grids, wireless terminals in transportation safety, wireless terminals in smart cities, wireless terminals in smart homes, cellular phones, cordless phones, session initiation protocol (SIP) phones, wireless local loop (WLL) stations, personal digital assistants (PDAs), handheld devices with wireless communication capabilities, computing devices or other processing devices connected to a wireless modem, in-vehicle devices, wearable devices, terminal devices in 5G networks, or future public land mobile communication networks. Terminal devices in a network (PLMN), etc., are not limited to this in the embodiments of this application.

[0067] By way of example and not limitation, in this embodiment, the terminal device can also be a wearable device. Wearable devices, also known as wearable smart devices, are a general term for devices that utilize wearable technology to intelligently design and develop everyday wearables, such as glasses, gloves, watches, clothing, and shoes. Wearable devices are portable devices that are worn directly on the body or integrated into the user's clothing or accessories. Wearable devices are not merely hardware devices, but also achieve powerful functions through software support, data interaction, and cloud interaction. Broadly speaking, wearable smart devices include those that are feature-rich, large in size, and can achieve complete or partial functions without relying on a smartphone, such as smartwatches or smart glasses, as well as those that focus on a specific type of application function and require the use of other devices such as smartphones, such as various smart bracelets and smart jewelry for vital sign monitoring.

[0068] Furthermore, in this application embodiment, the terminal device can also be a terminal device in an Internet of Things (IoT) system. IoT is an important component of future information technology development, and its main technical feature is connecting objects to networks through communication technology, thereby realizing an intelligent network of human-machine interconnection and object-to-object interconnection. The terminal device in this application can also be an on-board unit, on-board module, on-board component, on-board chip, or on-board unit built into a vehicle as one or more components or units. The vehicle can implement the methods of this application through the built-in on-board unit, on-board module, on-board component, on-board chip, or on-board unit. Therefore, the embodiments of this application can be applied to vehicle networking, such as vehicle-to-everything (V2X), long-term evolution-vehicle (LTE-V) communication technology, and vehicle-to-vehicle (V2V) communication.

[0069] Currently, although the performance of some hardware components in electronic devices is becoming increasingly powerful—for example, the bit width of GPUs and Central Processing Units (CPUs) is also increasing—the overall performance improvement of electronic devices is not significant. One possible reason for this limited overall performance improvement is that the component with the lowest bit width among the various hardware components becomes the bottleneck, creating a "weakest link" effect that limits the total usable memory and thus hinders overall performance growth. For example, a browser can only open a limited number of web pages; if too many web pages are opened, the browser may crash or prevent new pages from being opened.

[0070] The following example illustrates why the lowest bit width becomes a bottleneck, affecting the overall usable memory size, using a scenario where data processing is performed using CPU, GPU, and display subsystem (DSS) chips.

[0071] Please refer to Figure 1, which is a schematic diagram of a scenario where multiple chips perform data processing according to an embodiment of this application. The scenario shown in Figure 1 may include a CPU, GPU, DSS, and physical memory. The bit width of the CPU and GPU can be 64 bits, and the bit width of the DSS can be 32 bits. Physical memory may include a buffer. The buffer may reside in random access memory (RAM) or a buffer area on a hard disk, etc.

[0072] In this embodiment, the buffer needs to be accessible by the CPU, GPU, and DSS, and the buffer's memory is physically shared, enabling data transfer between the CPU, GPU, and DSS via the buffer. Taking data processing, including image processing, as an example, the CPU or GPU can first complete the original layer drawing, which can be understood as the CPU or GPU producing data; then the GPU or DSS composites the image to be displayed, which can be understood as the GPU or DSS consuming the data. In this embodiment, the CPU can draw layers, and the GPU can write to disk (flush) and compose the image. "Flush" typically refers to the operation of refreshing buffered data from cache or temporary storage to permanent storage or external devices. "Compose" is usually related to the creation, combination, or compositing of images; it can refer to combining multiple image elements, layers, or image fragments into a complete image.

[0073] Optionally, image processing using CPU, GPU, and DSS includes, but is not limited to, the following:

[0074] During the data production phase, the CPU and / or GPU complete the drawing of the original layer and write the drawn data to the buffer. Then, during the data consumption phase, the GPU and / or DSS perform subsequent data processing, such as writing the drawn data to read-only memory (ROM) or external devices, or using the drawn data to synthesize the image to be displayed.

[0075] In this embodiment, the CPU completing the original layer drawing can be understood as producing data, while the GPU performing image enhancement processing such as rendering on the drawn data can be understood as consuming data. Furthermore, the GPU performing image enhancement processing such as rendering on the drawn data can also be understood as producing data, while using the DSS to synthesize the image to be displayed using this image enhancement data can be understood as consuming data.

[0076] It should be understood that the scenario shown in Figure 1 can also be applied to other data processing, such as the training or inference of artificial intelligence models, without limiting the specific data processing. The training or inference of artificial intelligence models can refer to the image processing process of CPUs, GPUs, and DSS. The differences between the training or inference of artificial intelligence models and the image processing process include: the different processing chips and the different processing procedures.

[0077] In related technologies, when data processing is required, a virtual address is first requested in the process of the application used to draw the layer. The application can also be simply referred to as an application or program. When the program needs to read or write the content of this address, the system allocates a memory page from physical memory and then maps the virtual address to the physical address.

[0078] Taking the above scenario as an example, virtual addresses need to be allocated separately in the CPU, GPU, and DSS. Then, the virtual addresses allocated by the CPU, GPU, and DSS are mapped to the same physical address space, thereby enabling shared processing among the CPU, GPU, and DSS. This can also be understood as enabling the processing of production and consumption data phases among the CPU, GPU, and DSS. The virtual address range is affected by the chip's bit width n; for example, the maximum virtual address range is 2^n. n As for the physical address range, it is related to the capacity of the physical memory.

[0079] Therefore, it can be seen that since virtual addresses are first allocated separately in the CPU, GPU, and DSS, and then these virtual addresses are mapped to the same physical address space to achieve shared processing among the CPU, GPU, and DSS, the range of usable physical addresses is affected by the chip with the lowest bit width among the CPU, GPU, and DSS. In other words, the chip with the lowest bit width becomes the bottleneck, creating a "weakest link" effect and affecting the overall usable memory size. Taking the number of web pages opened in a browser as an example, since displaying image elements is required when opening a webpage, physical memory needs to be allocated to store these image elements. However, when the overall usable physical memory size is limited, it will affect the number of webpages that can be opened by the browser.

[0080] Please refer to Figure 2, which is a schematic diagram illustrating the limitations of the overall usable memory size of an electronic device in the related art. As shown in Figure 2, since both the CPU and GPU have a bit width of 64 bits, the theoretical maximum memory size that the CPU and GPU can use is 2. 64 = 8 gigabytes (G), while the theoretical maximum memory size that DSS can use is 2 32=4G. Even if electronic devices have 16GB or even 32GB of physical RAM, and the CPU and GPU have a 64-bit bit width, due to the limitation of the DSS bit width, the CPU, GPU, and DSS can only use 4GB of RAM. The extra RAM cannot be used for graphics memory. For example, with 16GB of RAM, only 4GB can be used as graphics memory shared by the CPU, GPU, and DSS, leaving 12GB of unused RAM. This significantly limits the number of applications that can be run simultaneously and the overall performance of the electronic device. Therefore, even if the performance of some hardware components in electronic devices becomes increasingly powerful, the overall performance improvement of electronic devices is not significant.

[0081] In general, when multiple chips share physical memory, the total available memory is limited by the chip with the smallest bit width. For example, a 32-bit chip is limited to 4GB of physical memory, which means that any physical memory exceeding 4GB will be unusable and wasted. For 16GB of physical memory, the utilization rate is only 4GB / 16GB = 25%, and for 32GB of physical memory, the utilization rate is only 4GB / 32GB = 12.5%.

[0082] In view of this, embodiments of this application provide an address mapping method and apparatus that can improve the overall performance of an electronic device by dynamically mapping shared physical memory to the virtual addresses of multiple chips. Taking the number of web pages a browser can open as an example, the shared memory of chips requiring a minimum bit width for consuming data is limited by the minimum bit width, but the shared memory of chips that do not require a minimum bit width for consuming data is not limited by the minimum bit width. Thus, the number of new applications that the entire device can open increases exponentially, and more new web pages or applications can be opened as long as there is physical memory.

[0083] The address mapping method will be explained below in conjunction with the hardware and software architecture of electronic devices.

[0084] Please refer to Figure 3, which is a schematic diagram of the hardware architecture of an electronic device provided in an embodiment of this application.

[0085] As shown in Figure 3, the electronic device 100 may include a processor 110, an external memory interface 120, an internal memory 121, a universal serial bus (USB) interface 130, a charging management module 140, a power management module 141, a battery 142, an antenna 1, an antenna 2, a mobile communication module 150, a wireless communication module 160, an audio module 170, a speaker 170A, a receiver 170B, a microphone 170C, a headphone jack 170D, a sensor module 180, buttons 190, a motor 191, an indicator 192, a camera 193, a display screen 194, and a subscriber identification module (SIM) card interface 195, etc. The sensor module 180 may include a pressure sensor 180A, a gyroscope sensor 180B, a barometric pressure sensor 180C, a magnetic sensor 180D, an accelerometer sensor 180E, a distance sensor 180F, a proximity sensor 180G, a fingerprint sensor 180H, a temperature sensor 180J, a touch sensor 180K, an ambient light sensor 180L, a bone conduction sensor 180M, etc.

[0086] It is understood that the structures illustrated in the embodiments of the present invention do not constitute a specific limitation on the electronic device 100. In other embodiments of this application, the electronic device 100 may include more or fewer components than illustrated, or combine some components, or split some components, or have different component arrangements. The illustrated components may be implemented in hardware, software, or a combination of software and hardware.

[0087] Processor 110 may include one or more processing units, such as: application processor (AP), modem processor, CPU, GPU, DSS, image signal processor (ISP), controller, video codec, digital signal processor (DSP), baseband processor, and / or neural network processing unit (NPU), etc. Different processing units may be independent devices or integrated into one or more processors.

[0088] The controller can generate operation control signals based on the instruction opcode and timing signals to complete the control of instruction fetching and execution.

[0089] The processor 110 may also include a memory for storing instructions and data. In some embodiments, the memory in the processor 110 is a cache memory. This memory can store instructions or data that the processor 110 has just used or that are used repeatedly. If the processor 110 needs to use the instruction or data again, it can retrieve it directly from the memory. This avoids repeated accesses, reduces the waiting time of the processor 110, and thus improves the efficiency of the system.

[0090] Electronic device 100 implements display functions through a GPU, a display screen 194, and an application processor. The GPU is a microprocessor for image processing, connected to the display screen 194 and the application processor. The GPU is used to perform mathematical and geometric calculations and for graphics rendering. Processor 110 may include one or more GPUs, which execute program instructions to generate or modify display information.

[0091] Internal memory 121 can be used to store executable program code, including instructions. Internal memory 121 may include a program storage area and a data storage area. The program storage area may store the operating system, application programs required for at least one function (such as sound playback, image playback, etc.), etc. The data storage area may store data created during the use of electronic device 100 (such as audio data, image data, phone book, etc.). In addition, internal memory 121 may include high-speed random access memory, and may also include non-volatile memory, such as at least one disk storage device, flash memory device, universal flash storage (UFS), etc. Processor 110 executes various functional applications and data processing of electronic device 100 by running instructions stored in internal memory 121 and / or instructions stored in memory located in the processor.

[0092] In this embodiment, taking image data (also known as graphics data) processing as an example, the drawing of layers can be completed by the CPU or GPU, and the drawn image data can be stored in the storage data area. Then, the drawn image data can be retrieved from the storage data area by the GPU or DSS for image synthesis, and the synthesized image data can be displayed on the display screen 194. Taking the training or inference of an artificial intelligence model as an example, the user's operation data can be retrieved by the CPU and stored in the storage data area, and then the operation data can be retrieved from the storage data area by the NPU for training or inference. This operation data can be data generated by detecting user operations on the electronic device, such as data from an application clicked by the user detected by the electronic device.

[0093] Please refer to Figure 4, which is a schematic diagram of the software architecture of an electronic device provided in an embodiment of this application.

[0094] The software system of electronic device 100 can adopt a layered architecture, event-driven architecture, microkernel architecture, microservice architecture, or cloud architecture. This embodiment of the invention uses the layered architecture of the Harmony system as an example to illustrate the software structure of electronic device 100.

[0095] The Harmony system employs a multi-kernel design, optionally including the Linux kernel, the Harmony microkernel, and LiteOS. This design allows devices with different capabilities to choose the appropriate system kernel. The kernel layer also includes a Kernel Abstraction Layer (KAL), which provides basic kernel capabilities to other Harmony layers, such as process management, thread management, memory management, file system management, network management, and peripheral management. Optionally, the kernel layer also includes a render service, which is typically responsible for converting user interface (UI) elements or graphical data into images that can be displayed on the screen. This includes handling visual effects such as color, texture, lighting, and shadows, and ensuring that graphical elements are drawn to the screen in the correct manner and order to achieve smooth animation and interactive experiences. It should be understood that the render service can also be configured at other layers of the software framework, not limited to the kernel layer, as long as it enables the render service to achieve the functionality described in the embodiments of this application.

[0096] The system's basic service layer is the core capability set of the Harmony system, enabling it to provide application services through a framework layer in multi-device deployment scenarios. This layer may optionally include the following components:

[0097] The system's basic capability subsystems provide fundamental capabilities for the operation, scheduling, and migration of distributed applications across multiple devices within the Harmony system. These subsystems comprise a distributed soft bus, distributed data management and file management, distributed task scheduling, the Ark runtime, and distributed security and privacy protection. The Ark runtime provides runtime environments for multiple languages ​​(C / C++ / JavaScript) and basic system libraries. It also provides a runtime environment for Java programs statically generated using the Ark compiler (i.e., the parts of the application or framework layer developed using the Java language).

[0098] The basic software service subsystem suite provides common and general software services for the Harmony system, consisting of subsystems such as graphics and image processing, distributed media, distributed AI, multimodal input, MSDP & DV, event notification, telephony service, and distributed DFX. The basic software service subsystem suite can be customized according to the deployment environment of different device types, and each subsystem can be tailored to its functional granularity.

[0099] Enhanced Software Service Subsystem Assembly: This assembly provides Harmony systems with differentiated enhanced software services for various devices, comprising subsystems such as tablet business software, smart screen business software, in-vehicle business software, and IoT business software. The Enhanced Software Service Subsystem Assembly can be tailored to the deployment environment of different device types, at the subsystem level, and each subsystem can be further tailored at the functional level.

[0100] HarmonyDriver Framework (HDF) and Hardware Abstraction Adapter Layer (HAL): These form the foundation for the open hardware ecosystem of the Harmony system. They provide hardware capability abstraction at the top and development framework and runtime environment for various peripheral drivers at the bottom.

[0101] Hardware Service Subsystem Set: Provides common and adaptable hardware services for the Harmony system, consisting of hardware service subsystems such as general sensor, location, power, USB, and biometrics. The Hardware Service Subsystem Set can be tailored to the deployment environment of different device types, with each subsystem allowing for functional customization.

[0102] The proprietary hardware service subsystem provides differentiated hardware services for different devices within the Harmony system. Optional subsystems include proprietary hardware services for tablets, in-vehicle systems, wearables, and IoT devices. The proprietary hardware service subsystem can be tailored at the subsystem level, and each subsystem can be further customized at the functional level.

[0103] The framework layer provides Harmony system applications with user program frameworks and meta-capability frameworks in multiple languages ​​such as Java / C / C++ / JavaScript, as well as multi-language framework APIs for various software and hardware services. The application layer includes system applications and third-party applications, which can include browsers, cameras, photo galleries, calendars, call systems, maps, navigation, WLAN, Bluetooth, music, video, SMS, and other applications. Applications in the Harmony system are built upon AA and FA (Application Aspects and Components).

[0104] In this embodiment, physical memory is first allocated to the producer device (e.g., CPU or GPU), which can then write the produced data (e.g., drawn image data) into this physical memory. Then, when the produced data needs to be consumed, the consumer device (e.g., GPU or DSS) can utilize the mapping between the virtual address of the consumer device and the physical address where the produced data is written to retrieve the produced data from that physical address and consume it. The consumed data can, for example, be an image synthesized from image data to be displayed.

[0105] In this context, the producer device can be a device that produces data, and the consumer device can be a device that consumes data. The definitions of production data and consumption data can be found in the descriptions of the embodiments above, and will not be repeated here. For example, the producer device can be, for instance, a CPU or a GPU, and the consumer device can be, for instance, a GPU or a DSS.

[0106] To better understand the data processing scheme of the embodiments of this application, the following embodiments use producer devices, consumer devices, and graphics memory management decision-making devices as examples of several functional units in an electronic device, and provide exemplary descriptions of the physical address occupancy during the data production stage and the data consumption stage. The graphics memory management decision-making device can be used to manage graphics memory, such as managing each independent piece of graphics memory.

[0107] Please refer to Figure 5, which is a schematic diagram of a data processing system architecture provided in an embodiment of this application. The system architecture shown in Figure 5 may include a producer device, a consumer device, a graphics memory management decision-making device, and a physical memory device. The physical memory device is also referred to as physical memory. Optionally, the producer device may be one or more independent devices. When there are multiple producer devices, there may be 1 to M independent producer devices, where M is an integer not less than 2. Optionally, the consumer device may be one or more independent devices. When there are multiple consumer devices, there may be 1 to N independent consumer devices. In this embodiment, the producer device and consumer device may be hardware devices, while the graphics memory management decision-making device may be a software device. Taking graphics processing as an example, the producer device can be used to draw and write graphics data, and the consumer device can be used to synthesize images or read graphics data for display.

[0108] In the data production phase, the producer device requests a virtual address. Then, the graphics memory management decision unit allocates shared physical memory to the producer device and marks the producer device with a flag (also called a flag bit). This flag indicates the physical address of the shared physical memory allocated to the producer device; in other words, it indicates that the producer device's virtual address has been mapped to a physical address. Furthermore, the graphics memory management decision unit maps the producer device's virtual address to this physical address, allowing the producer device to use this mapping to write the data produced by the producer device into the memory corresponding to that physical address.

[0109] Then, in the data consumption phase, in this embodiment of the application, the graphics memory management decision-making device may perform, but is not limited to, the following steps:

[0110] 1. Locate all consumer devices for a given memory segment based on business logic.

[0111] 2. Find the difference between the set of device identifiers already marked on the memory chip and the set of consumer devices, and request virtual addresses from the consumers in the difference set.

[0112] 3. Bind the newly requested virtual address to the original physical memory.

[0113] In this embodiment, the difference set includes consumer devices that are not tagged. For example, a graphics memory management decision-making device determines a set of consumer devices for consuming production data based on business logic. The consumer device set includes one or more consumer devices, such as n consumer devices, where 0 < n < N, and n is an integer. Then, the consumer device set is compared with a set of tagged producer devices to determine if a difference set exists. If a difference set exists, it means that at least one consumer device in the consumer device set is not tagged, that is, at least one consumer device in the consumer device set has not requested a virtual address mapped to the physical address storing the production data. In other words, at most some consumer devices in the consumer device set have been tagged before the data consumption stage, meaning that at most some consumer devices in the consumer device set have requested a virtual address mapped to the physical address storing the production data.

[0114] Therefore, the graphics memory management decision-making device can request virtual addresses from each of the at least one consumer device. Then, the graphics memory management decision-making device maps the requested virtual addresses to the physical addresses. Each consumer in the at least one consumer device can then retrieve production data from the memory corresponding to the physical address for consumption, based on the mapping between the requested virtual address and the physical address. For consumer devices that have been tagged, these consumer devices can utilize the mapping between the requested virtual address and the physical address to retrieve production data from the memory corresponding to the physical address for consumption.

[0115] It should be noted that if there is no difference set, it means that each consumer device in the consumer device set has applied for a virtual address mapped to the physical address before consuming data. In this case, each consumer device in the consumer device set can use the mapping between the applied virtual address and the physical address to obtain production data from the memory corresponding to the physical address for consumption.

[0116] In summary, the embodiments of this application divide memory allocation operations into a production stage and a consumption stage. Each stage dynamically maps virtual addresses to the relevant chips only as needed, ensuring that the chips do not interfere with each other. In this way, the total usable memory of the entire machine is no longer limited by the bit width of a single chip. The theoretical maximum value is the sum of the virtual spaces of all chips, which is greater than the capacity of the physical address space, thus maximizing the utilization of physical memory.

[0117] For example, consider image data processing. Assume the system framework includes a CPU, GPU, and DSS, where the GPU can be both a producer and a consumer device, the CPU acts as a producer, and the DSS acts as a consumer. During the data production phase, the CPU and GPU each request virtual addresses; let's say the CPU requests virtual address 1 and the GPU requests virtual address 2. Then, the graphics memory management decision module allocates memory 1 for the CPU and GPU, mapping virtual address 1 and virtual address 2 to physical address 1 of memory 1, and marking the CPU and GPU with identifiers indicating the physical address 1. At this point, after producing data, the CPU can use the mapping between virtual address 1 and physical address 1 to write the data produced by the CPU into memory 1 corresponding to physical address 1. Then, during the data consumption phase, the graphics memory management decision module determines the set of consumer devices for consuming the produced data based on business logic. This set of consumer devices includes the GPU and the DSS. Comparing the set of consumer devices with the marked set of producer devices yields a difference set, which includes the DSS. Then, for the DSS, the graphics memory management decision unit can request virtual address 3 from the DSS, and then map virtual address 3 to physical address 1. The DSS can then retrieve the data produced by the CPU from memory 1 corresponding to physical address 1 based on this mapping, and consume the produced data. For the GPU, since the GPU is already identified during the data production stage—that is, the virtual address 2 requested by the GPU is already mapped to physical address 1 during the data production stage—the GPU can utilize the mapping between virtual address 2 and physical address 1 to retrieve the produced data from memory 1 corresponding to physical address 1 for consumption during the data consumption stage.

[0118] It should be noted that if the determined set of consumer devices includes GPUs but excludes DSS, then there is no difference between the consumer device set and the set of tagged producer devices. Conversely, if the determined set of consumer devices includes DSS but excludes GPUs, then there is a difference between the consumer device set and the set of tagged producer devices.

[0119] In this embodiment, during the data production phase, the CPU and GPU each request virtual addresses and map their respective virtual addresses to the physical addresses of the allocated memory. Therefore, during the data consumption phase, if data needs to be consumed using the GPU, since the GPU has already requested and mapped virtual addresses to physical addresses, it does not need to request and map virtual addresses again during the data consumption phase, thereby improving data consumption efficiency. In other words, this embodiment requests virtual addresses for multiple devices during the data production phase and maps these virtual addresses to physical addresses. If a device that has already requested and mapped virtual addresses needs to consume data, it can directly utilize the mapping between virtual and physical addresses to obtain and consume data during the data consumption phase, thus improving data consumption efficiency.

[0120] It should be noted that, in the embodiments of this application, the devices involved in data processing include at least three, and the bit width of at least two of the at least three devices is greater than the bit width of the other devices. For example, the devices involved in image processing include a CPU, a GPU, and a DSS, wherein the bit width of the CPU and GPU is greater than the bit width of the DSS. However, the bit width of the CPU and GPU can be the same or different, determined according to the actual situation. For example, the bit width of the CPU may be greater than the bit width of the GPU, or the bit width of the CPU may be equal to the bit width of the GPU, or the bit width of the CPU may be less than the bit width of the GPU.

[0121] In this embodiment, during the production data stage, in addition to the producer device needing to apply for a virtual address and map it to a physical address, at least one device with the largest bit width among at least three devices can also apply for a virtual address. Then, the virtual addresses of each of the at least one device with the largest bit width are mapped to the allocated physical addresses. The range of physical addresses supported by the device with the largest bit width is greater than or equal to the range of physical addresses supported by other devices with different bit widths. In other words, the range of physical addresses supported by the device with the largest bit width can cover the range of physical addresses supported by other devices with different bit widths. This not only improves the efficiency of data consumption but also reduces the possibility that the physical addresses where larger bit-width devices store production data cannot be accessed by smaller bit-width devices due to the smaller bit width of the device applying for the virtual address during the production data stage. This further reduces the possibility of smaller bit-width devices being unable to access production data and thus preventing data consumption.

[0122] For example, assuming the CPU and GPU have a bit width of 64 bits, and the DSS has a bit width of 32 bits, since the CPU and GPU have the largest bit widths, during the data production phase, the CPU and / or GPU can request virtual addresses and map the requested virtual addresses to physical addresses. As another example, assuming the CPU has a bit width of 128 bits, the GPU has a bit width of 64 bits, and the DSS has a bit width of 32 bits, since the CPU has the largest bit width, during the data production phase, the CPU can request virtual addresses and map the requested virtual addresses to physical addresses. In this case, if the GPU is a producer device, the GPU can also request virtual addresses and map them to physical addresses; if the GPU is not a producer device, it can choose not to request virtual addresses initially. For example, assuming the CPU has a 64-bit bit width, the GPU has a 128-bit bit width, and the DSS has a 32-bit bit width, since the GPU has the largest bit width, during the data production phase, the GPU can request addresses and map the requested virtual addresses to physical addresses. At this time, if the CPU is a producer device, the CPU can also request virtual addresses and map them to physical addresses; if the CPU is not a producer device, it can choose not to request virtual addresses initially. For example, assuming the CPU has a 32-bit bit width, and both the GPU and DSS have 64-bit bit widths, since both the GPU and DSS have the largest bit widths, during the data production phase, the GPU and / or DSS can request virtual addresses and map them to physical addresses. For example, assuming the CPU has a 64-bit bit width, the DSS has a 32-bit bit width, and the DSS has a 128-bit bit width, during the data production phase, the DSS can request virtual addresses and map them to physical addresses.

[0123] It should be understood that if the producer device and the device with the largest bit width are not the same device during the data production phase, the producer device needs to request a virtual address and map it to a physical address because it needs to store the produced data. However, for the device with the largest bit width, it can also request a virtual address and map it to the physical address where the produced data is stored during the data production phase. This is beneficial because when the device with the largest bit width acts as a consumer device, it can promptly obtain and consume the produced data. Optionally, the device with the largest bit width can also request a virtual address and map it to the physical address where the produced data is stored only when it is determined to be either a producer device or a consumer device.

[0124] In another possible implementation, virtual addresses can also be requested for at least three devices other than the one with the smallest bit width. Then, the virtual addresses of the other devices can be mapped to the allocated physical addresses. In this way, when the other devices need to consume data, the data can be consumed in a timely manner, thereby improving the efficiency of data consumption.

[0125] For example, assuming the CPU has a 128-bit bit width, the GPU has a 64-bit bit width, and the DSS has a 32-bit bit width, the CPU and / or GPU can request virtual addresses and map the requested virtual addresses to physical addresses. Again, assuming the CPU has a 64-bit bit width, the GPU has a 128-bit bit width, and the DSS has a 32-bit bit width, the CPU and / or GPU can request virtual addresses and map the requested virtual addresses to physical addresses. Again, assuming the CPU has a 64-bit bit width, the GPU has a 32-bit bit width, and the DSS has a 128-bit bit width, the CPU and / or the DSS can request virtual addresses and map the requested virtual addresses to physical addresses.

[0126] In another possible implementation, a virtual address can be requested from the device only when the device needs to process data, and the virtual address can be mapped to a physical address. This can reduce the situation where a virtual address is requested and mapped to a physical address but remains unused, thereby improving the utilization rate of device resources.

[0127] It should be noted that, in the embodiments of this application, when marking the producer devices during the production data stage, it can be that M producer devices are marked separately, or that some of the M producer devices are marked. These partial producer devices can be, for example, the producer devices that actually participate in the data processing in this round of data processing, such as the producer devices that actually participate in drawing layer data.

[0128] The following describes the method flow for dynamically mapping shared physical memory to virtual addresses across multiple devices. The following embodiments use a multi-device architecture including a CPU, GPU, and DSS as an example. In this embodiment, the CPU and GPU can act as producer devices, and the GPU and DSS can act as consumer devices; that is, the GPU can act as both a producer and a consumer device. Optionally, the bit width of the CPU is greater than the bit width of the DSS, and the bit width of the GPU is greater than the bit width of the DSS. The bit widths of the CPU and GPU can be the same or different. For example, the bit width of both the CPU and GPU is 64 bits, and the bit width of the DSS is 32 bits. Alternatively, the bit width of the CPU may be 256 bits, the bit width of the GPU may be 128 bits, and the bit width of the DSS may be 64 bits.

[0129] Please refer to Figure 6, which is a flowchart illustrating a method for dynamically mapping shared physical memory to virtual addresses of multiple devices according to an embodiment of this application. The method of this embodiment may include:

[0130] S611, The application requests graphics memory from the rendering service.

[0131] Graphics memory can be a space used to store graphics data, and this graphics memory corresponds to a physical address. In the embodiments of this application, the application can be an application capable of generating graphics data, such as a camera application, a browser application, etc., and is not limited thereto.

[0132] S612 and the rendering service request virtual addresses from the CPU and GPU respectively, allocate memory 1, map the virtual address 1 requested by the CPU and the virtual address 2 requested by the GPU to the physical address 1 of memory 1 respectively, and set the flag bits of the CPU and GPU.

[0133] In this embodiment, the rendering service acts as a graphics memory management decision-making device. It should be understood that the functionality of the graphics memory management decision-making device can also be implemented through other services or modules, and is not limited to the rendering service. Optionally, the rendering service can transmit virtual address request requests to both the CPU and GPU. Upon receiving a virtual address request, the CPU requests virtual address 1 and transmits it to the rendering service. The rendering service can then map virtual address 1 to physical address 1, obtaining mapping relationship 1, which maps the relationship between virtual address 1 and physical address 1. The rendering service then transmits mapping relationship 1 to the CPU. Similarly, upon receiving a virtual address request, the GPU requests virtual address 2 and transmits it to the rendering service. The rendering service can then map virtual address 2 to physical address 1, obtaining mapping relationship 2, which maps the relationship between virtual address 2 and physical address 1. The rendering service then transmits mapping relationship 2 to the GPU. Furthermore, the rendering service sets flags for the CPU and GPU, which record that both the CPU and GPU have allocated and mapped the physical address 1.

[0134] It should be noted that, in the embodiments of this application, the application and rendering service can be software processes running on the CPU. The CPU running the application and rendering service can be a different CPU from the CPU that writes layer data to memory 1 corresponding to physical address 1. That is, the CPU running the application and rendering service is CPU1, and the CPU that writes layer data to memory 1 corresponding to physical address 1 is CPU2.

[0135] S613: The CPU writes the layer data generated by the application to memory 1 based on the mapping between virtual address 1 and physical address 1.

[0136] In this embodiment, the layer data generated by the application can be transmitted to the CPU. The CPU can then write the layer data generated by the application into memory 1 corresponding to physical address 1, or the CPU can process the layer data generated by the application and then write it into memory 1 corresponding to physical address 1. It should be noted that the layer data can be drawn by the CPU running the application, or it can be drawn jointly by the CPU and GPU running the application; no limitation is imposed here. If the layer data is drawn jointly by the CPU and GPU running the application, the method in this embodiment may further include the GPU writing the layer data generated by the GPU into memory 1 corresponding to physical address 1 based on the mapping between virtual address 2 and physical address 1.

[0137] S614, The rendering service determines that layer data needs to be composited by the GPU.

[0138] In this embodiment, since the GPU flag has been set in S612, the rendering service can know that the virtual address requested by the GPU has been mapped to the physical address 1 through the GPU flag. In other words, the physical address 1 already has the GPU flag, so the rendering service does not need to request a virtual address from the GPU again.

[0139] It should be noted that if the GPU does not have a flag, then you need to request a virtual address from the GPU, and then map the virtual address 2 requested by the GPU to physical address 1.

[0140] S615, Rendering service instructs the GPU to composite images.

[0141] In this embodiment of the application, the rendering service may transmit an instruction message 1 to the GPU, which is used to instruct the GPU to synthesize an image.

[0142] The S616 GPU obtains layer data from memory 1 corresponding to physical address 1 based on the mapping between virtual address 2 and physical address 1, and synthesizes images based on the layer data.

[0143] S617. The rendering service determines that layer data needs to be composited via DSS.

[0144] S618. The rendering service requests a virtual address from the DSS, maps the virtual address 3 requested by the DSS to the physical address 1, and sets the flag bit of the DSS.

[0145] In this embodiment, since the DSS flag is not set in S612, in other words, a virtual address has not yet been requested from the DSS and mapped to physical address 1. Therefore, the rendering service requests a virtual address from the DSS. Optionally, by setting the DSS flag, if the DSS needs to access memory 1 corresponding to physical address 1 again later, the flag of the DSS can be used to know that physical address 1 already has the DSS flag. In this way, the DSS can be instructed to access physical address 1 without needing to request a virtual address from the DSS again and then map it to physical address 1.

[0146] It should be noted that if the DSS has a flag, then there is no need to apply for a virtual address from the DSS.

[0147] S619, Rendering service indicates DSS composite image.

[0148] In this embodiment of the application, the rendering service may transmit an instruction message 2 to the GPU, which is used to instruct the DSS to synthesize the image.

[0149] S620 and DSS obtain layer data from memory 1 corresponding to physical address 1 based on the mapping between virtual address 3 and physical address 1, and synthesize images based on the layer data.

[0150] In the embodiments of this application, S614-S616 and S617-S620 are two parallel branches. In other words, the steps of S614-S616 or S617-S620 can be executed.

[0151] Optionally, the rendering service can choose to synthesize images via GPU or DSS according to certain business logic. In one possible implementation, this could be based on a power-performance balance logic. Optionally, assuming the GPU's performance is superior to the DSS's and the GPU's power consumption is greater than the DSS's, if the rendering service detects that the electronic device is in power-saving mode or its current battery level is below a threshold, the rendering service can synthesize images via DSS; if the rendering service detects that the electronic device is in performance mode or not in power-saving mode, or its current battery level is above or equal to a threshold, the rendering service can choose to synthesize images via GPU. Optionally, the image synthesis priority between GPU and DSS can also be set, prioritizing the synthesis of images using the higher priority memory first, and then using the lower priority memory when the higher priority memory is exhausted.

[0152] It should be understood that the business logic for selecting GPU or CPU for image compositing provided above is only an example and can be set as needed; no restrictions are imposed here.

[0153] It should be noted that S611-S613 can be understood as the production data stage, and S614-S620 can be understood as the consumption data stage.

[0154] In another possible implementation, if the GPU is not involved in drawing layer data, then in S612, the rendering service can request a virtual address from the CPU, allocate memory 1, map the virtual address 1 requested by the CPU to physical address 1, and set the CPU's flag. Then, if it is necessary to composite the image using the GPU, then before S615, the rendering service requests a virtual address from the GPU and maps the virtual address 2 requested by the GPU to physical address 1.

[0155] In another possible implementation, the GPU or DSS does not necessarily need to synthesize images; it can also perform image enhancement processing on layer data, without any restrictions.

[0156] In the embodiment shown in Figure 6, the case where the CPU running the application and service rendering can be a different CPU from the CPU writing layer data to physical address 1 is illustrated.

[0157] In the following embodiments, the case where the CPU running the application and service rendering is the same CPU as the CPU that writes layer data to memory 1 corresponding to physical address 1 is described. In other words, the application and service rendering are software processes running on the CPU that writes layer data to memory 1 corresponding to physical address 1.

[0158] Please refer to Figure 7, which is a flowchart illustrating another method for dynamically mapping shared physical memory to multi-device virtual addresses according to an embodiment of this application. The method of this embodiment may include:

[0159] S711, the application requests graphics memory from the rendering service.

[0160] S711 can be referred to in the description of S611, and will not be repeated here.

[0161] S712, the rendering service requests virtual address 1 from the CPU and virtual address 2 from the GPU, allocates memory 1, maps virtual address 1 and virtual address 2 requested by the GPU to physical address 1 of memory 1 respectively, and sets the flag bits of the CPU and GPU.

[0162] In this embodiment of the application, since the rendering service runs on the CPU that writes data, the rendering service can directly request virtual address 1.

[0163] It should be understood that it is also possible to request the mapping between virtual and physical addresses through other services running on the CPU and then forward it to the rendering service.

[0164] S713, the rendering service writes the layer data generated by the application to memory 1 based on the mapping between virtual address 1 and physical address 1.

[0165] In this embodiment, since the rendering service runs on the CPU that writes data, it can directly write the layer data generated by the application to memory 1 corresponding to physical address 1. Optionally, the layer data generated by the application can be transmitted to the rendering service, and then written to memory 1 corresponding to physical address 1 by the rendering service.

[0166] It should be understood that the layer data generated by the application can also be written to memory 1 corresponding to physical address 1 through other services running on the CPU. In this case, the rendering service can transfer the layer data to other services, and then the other services can write the layer data to memory 1 corresponding to physical address 1.

[0167] S714, The rendering service determines that layer data needs to be composited by the GPU.

[0168] S714 can be referred to in the explanation of S614, and will not be repeated here.

[0169] S715, Rendering service instructs the GPU to composite images.

[0170] S715 can be referred to in the description of S615, and will not be repeated here.

[0171] The S716 GPU obtains layer data from memory 1 corresponding to physical address 1 based on the mapping between virtual address 2 and physical address 1, and synthesizes images based on the layer data.

[0172] S716 can be referred to in the explanation of S616, and will not be repeated here.

[0173] S717, The rendering service determines that layer data needs to be composited via DSS.

[0174] S717 can be referred to in the explanation of S617, and will not be repeated here.

[0175] S718 The rendering service requests a virtual address from the DSS, maps the virtual address 3 requested by the DSS to the physical address 1, and sets the flag bit of the DSS.

[0176] S718 can be referred to in the explanation of S618, and will not be repeated here.

[0177] S719, Rendering Service Instructs DSS Composite Image.

[0178] For S719, please refer to the description of S619, which will not be repeated here.

[0179] S720 and DSS obtain layer data from memory 1 corresponding to physical address 1 based on the mapping between virtual address 3 and physical address 1, and synthesize images based on the layer data.

[0180] The description of S720 can be referred to in the description of S620, and will not be repeated here.

[0181] In this embodiment, generally speaking, when an application in the application layer starts, it can request graphics memory from a graphics memory management decision-making device (e.g., a rendering service). The graphics memory management decision-making device can first allocate the physical address of a producer device (e.g., a CPU) and the virtual address of the requested producer device, and set a flag bit for the producer device. This flag bit can be used to mark the physical address allocated to the producer device; that is, the flag bit of the producer device can be used to mark the physical address allocated to the producer device as ready to be accessed by the producer device. Then, the graphics memory management decision-making device maps the virtual address of the producer device to the physical address of the memory allocated to the producer device. The producer device can then use the mapping between the virtual address of the producer device and the physical address allocated to the producer device to write the produced data (e.g., image data) to the physical address of the memory allocated to the producer device. Finally, the graphics memory management decision-making device selects a consumer device that needs to consume the data. If the consumer device does not have a flag set (e.g., the DSS does not have a flag set), then the consumer device's flag and the requested virtual address are set. The consumer device's flag indicates the physical address of the memory where the generated data is stored; that is, the consumer device's flag can be used to mark the physical address storing the generated data as ready for access by the consumer device. Then, the graphics memory management decision unit maps the consumer device's virtual address to the physical address storing the generated data. The consumer device can then use this mapping to retrieve the generated data from the memory corresponding to the physical address storing the generated data and process it.

[0182] In the embodiments of this application, some scenarios in which image processing is performed using CPU, GPU, and DSS may include, but are not limited to:

[0183] Scenario 1: The CPU completes the drawing of the original layer and writes the drawn data to a buffer. Then, the GPU or DSS reads the drawn data from the buffer and uses it to synthesize the image to be displayed.

[0184] Scenario 2: The CPU completes the drawing of the original layer and writes the drawn data to a buffer. Then, the GPU reads the drawn data from the buffer and writes the drawn data to read-only memory (ROM) or an external device.

[0185] Scenario 3: The CPU completes the original layer drawing and writes the drawn data to a buffer. The GPU then reads the drawn data from the buffer, performs image enhancement processing such as rendering, and writes the enhanced data back to the buffer. The DSS then reads the enhanced data from the buffer and uses it to synthesize the image to be displayed. Image enhancement processing may include, but is not limited to, one or more of the following: contrast adjustment, sharpening, color enhancement, or filtering.

[0186] Scenario 4: The original layers are drawn using both the CPU and GPU. The CPU draws a portion of the original layers, while the GPU draws the other portion. Each CPU and GPU then writes their drawn original layers to a buffer. The DSS then reads the drawn data from the buffer and uses it to composite the image to be displayed.

[0187] Scenario 5: The CPU completes the drawing of the original layer and writes the drawn data to a buffer. Then, the GPU and DSS read the drawn data from the buffer and use it to synthesize the image to be displayed. Optionally, in this scenario, the GPU may use a portion of the drawn data to synthesize a part of the image, while the DSS may use another portion to synthesize another part. The GPU-synthesized portion and the DSS-synthesized portion are then stitched together to obtain the complete image. Alternatively, the GPU and DSS may both synthesize the image using the drawn data, and then the GPU-synthesized and DSS-synthesized images are merged to obtain a blended image.

[0188] The following examples illustrate how to dynamically map shared physical memory to virtual addresses of multiple devices in the above scenarios.

[0189] In the case of image processing corresponding to scenario one, the rendering service can allocate memory for the CPU, request a virtual address for the CPU, and set a CPU flag. This CPU flag indicates the physical address of the memory allocated to the CPU; that is, the CPU flag marks the physical address allocated to the CPU as ready for CPU access. Then, the rendering service maps the CPU's virtual address to this physical address. The CPU can then use this mapping to write image data (also called drawing data or layer data) into the memory corresponding to that physical address. If image compositing is required using the GPU, the rendering service sets a GPU flag. This GPU flag indicates the physical address where the image data is stored; that is, the GPU flag marks the physical address where the image data is stored as ready for GPU access. Furthermore, the rendering service can request a GPU virtual address and map it to the physical address where the image data is stored. The GPU can then use this mapping to retrieve image data from the memory corresponding to the physical address of the image data for image compositing. If an image needs to be composited using DSS (Dynamic Sequence Rendering), the rendering service sets a flag for DSS. This flag indicates the physical address where the image data is stored; in other words, it marks the physical address where the image data is stored as ready for DSS access. The rendering service can also request a virtual address for DSS and map this virtual address to the physical address where the image data is stored. DSS can then utilize this mapping to retrieve image data from the memory corresponding to the physical address where the image data is stored for image compositing.

[0190] In the case of image processing corresponding to scenario two, the rendering service can allocate memory for the CPU, request a virtual address for the CPU, and set the CPU's flags. Then, the rendering service maps the CPU's virtual address to the physical address in that memory. The CPU can then use this mapping to write image data to that physical address. If the image data needs to be written to read-only memory (ROM) via the GPU, the rendering service sets the GPU's flags, requests a virtual address for the GPU, and maps the GPU's virtual address to the physical address storing the image data. The GPU can then use this mapping to retrieve the image data from the memory corresponding to the physical address of the image data and write it to ROM.

[0191] In the case of image processing corresponding to scenario three, the rendering service can allocate memory for the CPU, request a virtual address for the CPU, and set a flag for the CPU. Then, the rendering service maps the CPU's virtual address to the physical address of that memory. The CPU can then use this mapping to write image data to that physical address. If image enhancement processing is required via the GPU, the rendering service sets a flag for the GPU and requests a virtual address for the GPU. It then maps the GPU's virtual address to the physical address storing the image data. The GPU can then use this mapping to retrieve the image data from the memory corresponding to the physical address of the image data for image enhancement processing. At this point, the GPU can write the enhanced image data to the physical address where the image data is stored, or write it to another physical address. If the enhanced image data is written to another physical address, the rendering service can allocate another memory for the GPU and set another flag for the GPU. This other flag indicates the other physical address of the other memory; that is, this other flag can be used to mark the other physical address allocated by the GPU as ready for GPU access. Furthermore, the rendering service can request another virtual address from the GPU and map this virtual address to another physical address. The GPU can then use this mapping to write image-enhanced image data to that physical address. Then, if image compositing is required via DSS, the rendering service sets a flag for DSS. This flag indicates that the other physical address is ready for DSS access. The rendering service can also request a virtual address for DSS and map it to that physical address. DSS can then use this mapping to retrieve image-enhanced image data from the corresponding memory location for image compositing.

[0192] It should be noted that in the image processing of scenario three, if it is necessary to retain the original image data, the image data after image enhancement can be written to another memory corresponding to another physical address; if it is not necessary to retain the original image data, the image data after image enhancement can be written to the memory corresponding to that physical address to replace the original image data previously written to that physical address.

[0193] In the case of image processing corresponding to scenario four, the rendering service can allocate memory for the CPU and GPU, request virtual addresses for both the CPU and GPU (this can be understood as requesting virtual addresses for each), and set flags for the CPU and GPU. These flags indicate the physical addresses of the memory allocated to the CPU and GPU, marking that the memory is ready for access by either the CPU or GPU. The rendering service then maps the virtual addresses of the CPU and GPU to physical addresses. The CPU can then use this mapping to write image data to the memory corresponding to the specified physical address, and the GPU can do the same. Next, the rendering service determines that the image data needs to be sent to the DSS for compositing. If so, it sets the DSS flags to indicate that the memory is ready for DSS access. The rendering service can then request a virtual address for the DSS and map it to the physical address. The DSS can then use this mapping to retrieve image data from the memory corresponding to the physical address for compositing.

[0194] In the case of image processing corresponding to scenario five, the rendering service can allocate memory for the CPU, request a virtual address for the CPU, and set the CPU's flags. Then, the rendering service maps the CPU's virtual address to that physical address. The CPU can then use this mapping to write image data into the memory corresponding to that physical address. Next, the rendering service requests virtual addresses for both the CPU and GPU, sets the CPU and GPU flags, and maps the CPU's and GPU's virtual addresses to physical addresses respectively. The CPU can then use this mapping to retrieve image data from the memory corresponding to the physical address for compositing, and the GPU can use this mapping to retrieve image data from the memory corresponding to the physical address for compositing.

[0195] To provide a more intuitive understanding of the physical memory usage in the embodiments of this application, the following embodiments provide illustrations to illustrate the physical memory usage in the embodiments of this application.

[0196] Please refer to Figure 8, which is a schematic diagram of physical memory usage according to an embodiment of this application. This embodiment uses a 64-bit CPU and GPU and a 32-bit DSS as an example. As shown in Figure 8, the shared physical memory used by the CPU, GPU, and DSS is 2GB, while the shared physical memory used by the CPU and GPU alone is 6GB. This means that the CPU and GPU can use a total of 8GB of shared physical memory. Compared to the physical memory usage in Figure 2, the shared physical memory used by the CPU and GPU is increased, thereby improving the utilization of physical memory by the CPU and GPU and thus enhancing the overall performance of the electronic device.

[0197] It's important to note that the physical memory shared by the CPU, GPU, and DSS is not limited to 2GB; it can be the maximum physical memory supported by the DSS. For example, with a 32-bit DSS, the maximum physical memory shared by the CPU, GPU, and DSS can not exceed 4GB. However, since the maximum physical memory supported by the CPU and GPU is 8GB, in this scenario, the shared physical memory between the CPU and GPU can be 4GB. In other words, the shared physical memory usable by the CPU and GPU can still be 8GB.

[0198] In this example, physical memory usage can exceed 4GB (the maximum bit width that the smallest bit width chip can use), and the virtual address of the smallest bit width chip does not exceed 4GB.

[0199] In this embodiment of the application, for example, for 16G of physical memory, the shared memory utilization rate of CPU and GPU is 8G / 16G = 50%, and for 32G of physical memory, the shared memory utilization rate of CPU and GPU is 8G / 32G = 25%. By comparing the utilization rate of this application with related technologies, the shared memory utilization rate of the embodiment of this application is improved.

[0200] It should be understood that, in the embodiments of this application, the shared physical memory among multiple devices is limited by the maximum physical memory supported by the device with the smallest bit width. Furthermore, the shared physical memory among devices with larger bit widths is limited by the maximum physical memory supported by the device with the smallest bit width among the larger bit widths.

[0201] For example, assuming the CPU has a bit width of 128 bits, the GPU has a bit width of 64 bits, and the DSS has a bit width of 32 bits, the shared physical memory between the CPU, GPU, and DSS is limited by the maximum physical memory supported by the DSS (4GB). The shared physical memory between the CPU and GPU is further limited by the maximum physical memory supported by the GPU (8GB). In other words, the maximum shared memory between the CPU and GPU can be 8GB, and the minimum can be 4GB (the difference between the maximum physical memory supported by the GPU (8GB) and the maximum physical memory supported by the DSS (4GB)).

[0202] For example, assuming the CPU has a bit width of 32 bits, the GPU has a bit width of 64 bits, and the DSS has a bit width of 128 bits, the shared physical memory between the CPU, GPU, and DSS is limited by the maximum physical memory supported by the CPU (4GB). The shared physical memory between the DSS and GPU is also limited by the maximum physical memory supported by the GPU (8GB). In other words, the maximum shared memory between the DSS and GPU can be 8GB, and the minimum can be 4GB (the difference between the maximum physical memory supported by the GPU (8GB) and the maximum physical memory supported by the CPU (4GB)).

[0203] The above embodiments described a scenario where there is only one CPU, GPU, and DSS. The following embodiments describe scenarios where there are two or more CPU, GPU, and DSS components.

[0204] In one possible implementation, assuming there are multiple CPUs, including CPU3 and CPU4, when a CPU needs to produce data, CPU3 can first write the data to a physical address. Once CPU3 reaches its maximum supported physical memory address, CPU4 will then write the data to the next physical address. This allows another CPU to be used only after one reaches its limit, thus extending the lifespan of some CPUs. Alternatively, when CPUs need to produce data, CPU3 and CPU4 can alternately write the data to physical addresses. For example, CPU3 writes the first batch of data to physical address 3, CPU4 writes the second batch to physical address 4, the third batch to physical address 5, and the fourth batch to physical address 6, and so on, until at least one of CPUs (CPU3 and CPU4) reaches its maximum supported physical memory address. This extends the overall lifespan of all CPUs.

[0205] In another possible implementation, assuming there are multiple GPUs, including GPU1 and GPU2, when GPUs need to produce data, GPU1 can first write the production data to a physical address. Once GPU1 reaches its maximum supported physical memory address, GPU4 can then write the production data to the physical address. This allows another GPU to be used only after one GPU reaches its limit, thus extending the lifespan of some GPUs. Alternatively, GPU1 can be dedicated to writing production data to a physical address, while GPU2 can be dedicated to reading data from the physical address and processing it. Alternatively, GPU1 and GPU2 can process data alternately. For example, GPU1 writes the fifth batch of production data to physical address 7, then GPU2 retrieves the sixth batch of production data from physical address 8 for consumption, then GPU1 retrieves the seventh batch of production data from physical address 9 for consumption, and then GPU2 retrieves the eighth batch of production data from physical address 10 for consumption. This can extend the overall lifespan of the multiple GPUs.

[0206] It should be noted that the alternating processing of GPUs can be the alternating processing of production data, the alternating processing of consumption data, or the alternating processing of both production and consumption data; no specific limitation is made here.

[0207] In another possible implementation, assuming there are multiple DSSs, including DSS1 and DSS2, when data needs to be consumed by a DSS, it can first be retrieved from a physical address via DSS1 for consumption. Once DSS1 reaches its maximum supported physical memory address, subsequent data consumption can continue via another DSS. This allows one DSS to reach its usage limit before another is used, thus extending the lifespan of some DSSs. Alternatively, DSS1 and DSS2 can process data alternately. For example, DSS1 retrieves the ninth batch of production data from physical address 11 for consumption, and then DSS2 retrieves the tenth batch of production data from physical address 12 for consumption. This extends the overall lifespan of the multiple DSSs.

[0208] It should be noted that in the embodiments of this application, how the CPU writes data to the physical address, how the GPU writes data to the physical address, how the GPU reads data from the physical address for processing, and how the DSS reads data from the physical address for processing can be referred to the relevant descriptions in Figures 6 and 7 of the above embodiments, and will not be repeated here.

[0209] It should be understood that, in the embodiments of this application, the relationship between the devices performing data processing is mainly considered, and the size of the physical memory is sufficient by default to meet the physical memory requirements of multiple devices performing data processing.

[0210] In the above embodiments, the processing of graphic data was used as an example for illustration. Graphic data may include layer data. It should be understood that for other data processing, such as machine learning scenarios, including but not limited to the training or inference of artificial intelligence models, the training or inference of artificial intelligence models can also refer to the description of the embodiments of this application, and will not be repeated here.

[0211] For example, an electronic device includes a data preprocessing chip (e.g., a CPU), a first training chip (e.g., a GPU), and a second training chip (e.g., an NPU). The data preprocessing chip can be used to preprocess data, such as data cleaning and model selection. Then, a model can be trained using either the first or second training chip. Alternatively, the first training chip can select a model and pre-train it, and then the second training chip can be used to further train the pre-trained model. In this scenario, the data preprocessing chip acts as a producer device, the first training chip can act as either a producer or a consumer device, and the second training chip can act as a consumer device.

[0212] In this scenario, during the data production phase, virtual addresses and memory 2 can be requested from the data preprocessing chip and the first training chip, respectively. The requested virtual address 4 of the preprocessing chip and the requested virtual address 5 of the first training chip are mapped to physical address 2 of memory 2. Then, the data preprocessing chip can write the selected model into memory 2 corresponding to physical address 2. During the data consumption phase, if training by the first training chip is required, there is no need to request a virtual address from it. The first training chip can utilize the mapping between virtual address 5 and physical address 2 to retrieve the model from memory 2 corresponding to physical address 2 for training. If training by the second training chip is required, a virtual address 6 is requested from it and mapped to physical address 2. The second training chip can then retrieve the model from memory 2 corresponding to physical address 2 for training based on the mapping between virtual address 6 and physical address 2.

[0213] Alternatively, during the data production phase, after the first training chip selects a model and pre-trains it, it can use the mapping between virtual address 5 and physical address 2 to write the pre-trained model into memory 2 corresponding to physical address 2. Then, during the data consumption phase, it can request virtual address 6 from the second training chip and map virtual address 6 to memory 2 corresponding to physical address 2. The second training chip can then obtain the pre-trained model from memory 2 corresponding to physical address 2 for further training based on the mapping between virtual address 6 and physical address 2.

[0214] It should be understood that, in addition to the scenarios described above, this solution can also be applied to scenarios where a head-up display for a car is implemented using a GPU, such as displaying content on the car's windshield.

[0215] In summary, the shared memory allocation in this application embodiment is divided into a production stage and a consumption stage, with each stage dynamically mapping virtual addresses to the relevant chips as needed.

[0216] Please refer to Figure 9, which is a flowchart illustrating an address mapping method provided in an embodiment of this application. The method shown in Figure 9 can be applied to an electronic device, which includes a first application, a first device, a second device, a third device, and physical memory. The bit widths of the first device, the second device, and the third device are not necessarily equal. For example, the bit widths of the first and second devices may both be greater than the bit width of the third device, or the bit widths of the first device may all be less than the bit widths of the second and third devices, or the bit widths of the second device may all be less than the bit widths of the first and third devices; this is not a limitation. The first, second, and third devices can be chips. For example, the first device may include a CPU, the second device may include a GPU, and the third device may include a DSS. In this embodiment, the first device acts as a producer device, the second device can act as both a producer and a consumer device, and the third device can act as a consumer device. The method shown in Figure 9 may include:

[0217] S901, the first application requests memory.

[0218] The first application can be an application installed on an electronic device. In this embodiment, the first application can be an application that requires the use of physical memory. For example, the first application can include, but is not limited to, browser applications and camera applications. For instance, when a browser application or camera application opens its application window, it needs memory to store graphics data.

[0219] For example, S901 can be described with reference to the description of S611, which will not be repeated here.

[0220] S902, apply for a first virtual address of the first device and a second virtual address of the second device, allocate a first memory in physical memory, and map the first virtual address and the second virtual address to the first physical address of the first memory respectively, wherein the first memory is used to store at least the first data written by the first device.

[0221] Virtual address is a concept relative to physical address. It is the address in the address space used to access memory. The main purpose of virtual address is to provide an abstraction layer for memory management, enabling the operating system to effectively manage physical memory while protecting memory isolation between processes. Physical address is a unique identifier for each byte in physical memory; it directly corresponds to the actual location in computer hardware (such as memory chips).

[0222] In this embodiment, the first virtual address and the second virtual address are respectively mapped to the first physical address of the first memory. This allows the first device and the second device to access the first physical address and then read and write data in the first memory. Optionally, the first device in this embodiment can act as a producer device to write first data to the first memory. If the second device acts as a producer device, it can also write its second data to the first memory. If the second device acts as a consumer device, it can read the first data from the first memory for processing.

[0223] For example, if the first device includes a CPU, the first virtual address may be, for example, virtual address 1; if the second device includes a GPU, the second virtual address may be, for example, virtual address 2. The first memory may be, for example, memory 1, and the first physical address may be, for example, physical address 1. The third virtual address may be, for example, virtual address 3. S902 can be referred to the description of S712, and will not be repeated here.

[0224] S903. Apply for a third virtual address for the third device and map the third virtual address to the first physical address.

[0225] In this embodiment, when a third device needs to process data, that is, when the third device acts as a consumer device, a virtual address of the third device is requested and mapped to the first physical address. In this way, the third device can also access the first physical address, thereby obtaining data from the first memory for processing.

[0226] For example, S903 can be described with reference to S718, and will not be repeated here.

[0227] S904, The third device retrieves the first data from the first memory corresponding to the first physical address and processes it.

[0228] In the embodiments of this application, the processing performed by the third device may be, for example, image synthesis, or model training or inference, etc., and is not limited thereto.

[0229] For example, S904 can be described with reference to S720, and will not be repeated here.

[0230] It should be noted that since the first memory stores the first data, the third device can at least retrieve the first data from the first memory for processing. If the second memory also stores the second data written by the second device, the third device can also retrieve the second data from the first memory for processing.

[0231] In this embodiment, during the data production phase, by requesting a first virtual address for a first device, allocating first memory in physical memory, and mapping the first virtual address to a first physical address in the first memory, the first device can write first data to the first memory. Then, by requesting a second virtual address for a second device and mapping it to a first physical address in the first memory, the second device can write second data to the first memory if acting as a producer device, and can also retrieve first data from the first memory for processing if acting as a consumer device. Then, when a third device acts as a consumer device, it can request a third virtual address and map it to a first physical address, allowing the third device to retrieve first data from the first memory corresponding to the first physical address for processing. By dividing the virtual address mapping into multiple phases, such as a data production phase and a data consumption phase, shared physical memory can be dynamically mapped to the virtual addresses of multiple chips, thereby improving the overall performance of the electronic device.

[0232] For example, the first data and the second data may be, for instance, drawn layer data, and the data processing of the corresponding third device may be, for instance, image compositing processing.

[0233] In one possible implementation, after the first application requests memory, the method may further include:

[0234] A first identifier is set for the first device and the second device, the first identifier indicating that the device has been mapped to a first physical address.

[0235] In this embodiment, setting a first identifier for the first device indicates that the first device has been mapped to a first physical address; in other words, the virtual address of the first device has been mapped to the first physical address. Setting a second identifier for the second device indicates that the second device has been mapped to the first physical address; in other words, the virtual address of the second device has been mapped to the first physical address. Optionally, the identifier in this embodiment may also be referred to as a flag bit.

[0236] It should be noted that if the device already has a first identifier, then when the device needs to access the first physical address of the first memory, mapping is no longer required.

[0237] For example, the embodiments of this application can be described with reference to S612, which will not be repeated here.

[0238] In this embodiment, by setting an identifier after the virtual address of the device is mapped to the physical address, it can be determined whether the physical address is mapped to the virtual address of the device. This allows for timely reading and writing of data in the memory corresponding to the physical address, thereby improving data processing efficiency. Furthermore, it can reduce the number of virtual addresses required for the device.

[0239] In another possible implementation, the device could request a virtual address and map it to a physical address in memory each time it accesses memory. This would reduce the resources required to set up the identifier.

[0240] In one possible implementation, requesting a third virtual address for the third device and mapping the third virtual address to a first physical address includes:

[0241] If it is determined that data is processed by a third device and a first identifier of the third device is not set, a third virtual address of the third device is requested, and the third virtual address is mapped to a first physical address, and a first identifier of the third device is set, the first identifier indicating that the device has been mapped to the first physical address.

[0242] For example, this embodiment can be described with reference to S614-S616, which will not be repeated here.

[0243] In this embodiment of the application, if it is determined that the data is processed by the third device and the first identifier of the third device is not set, it means that the virtual address of the third device has not yet been mapped to the first physical address. Therefore, the third virtual address of the third device can be applied for and mapped to the first physical address. In other words, when the third device is a consumer device, the identifier is used to determine whether it is necessary to apply for the virtual address of the third device and map it to the first physical address. This can improve the accuracy and efficiency of applying for and mapping the virtual address of the third device.

[0244] In another possible implementation, once it is determined that data will be processed by a third device, a virtual address of the third device can be requested and mapped to the first virtual address. This can reduce the resources required to set the identifier of the third device.

[0245] In one possible implementation, before requesting a third virtual address for the third device and mapping the third virtual address to the first physical address, the method further includes:

[0246] Acquire a first set and a second set, wherein the first set includes a device with a first identifier set, and the second set includes a device for processing data, wherein the device with the first identifier set includes a first device and a second device, and the device for processing data includes a third device;

[0247] If a first difference set is determined to exist based on the first set and the second set, a virtual device of the device in the first difference set is requested, and the virtual device of the device in the first difference set is mapped to a first physical address. The device in the first difference set is a device in the second set and the device in the first difference set is different from any device in the first set.

[0248] Requesting a third virtual address for a third device and mapping the third virtual address to a first physical address includes:

[0249] If the first difference set includes the third device, a third virtual address of the third device is requested, and the third virtual address is mapped to the first physical address.

[0250] The first set can also be called the set of device identifiers that have been marked, and the second set can also be called the set of consumer devices.

[0251] In this embodiment, the devices in the first difference set are determined consumer devices that are not marked with a first identifier. That is, the devices in the first difference set need to apply for a virtual address and map it to a first physical address. If the first difference set includes a third device, it means that the third device needs to apply for a virtual address and map it to a first physical address. Therefore, a third virtual address of the third device is applied for, and the third virtual address is mapped to the first physical address.

[0252] For example, the embodiments of this application can be described with reference to the embodiment in FIG5, which will not be repeated here.

[0253] In one possible implementation, the electronic device further includes a first service, whereby a first application requests memory, including:

[0254] The first application requests memory from the first service;

[0255] Requesting a first virtual address for a first device and a second virtual address for a second device, allocating first memory in physical memory, and mapping the first virtual address and the second virtual address to the first physical address in the first memory, respectively, includes:

[0256] The first service requests a first virtual address for a first device and a second virtual address for a second device, allocates first memory in physical memory, and maps the first virtual address and the second virtual address to the first physical address in the first memory, respectively.

[0257] For example, the first service could be a rendering service, or it could be another service running on the system, without limitation.

[0258] In this embodiment, the first application can request memory from the first service. The first service can then request a first virtual address of the first device and a second virtual address of the second device, allocate first memory in physical memory, and map the first virtual address and the second virtual address to the first physical address of the first memory, respectively. This reduces the inefficiency and resource consumption caused by multiple services interacting to achieve address mapping, thereby improving the efficiency of address mapping and reducing resource consumption.

[0259] In another possible implementation, the allocation of virtual addresses, memory allocation, and mapping between virtual and physical addresses can be implemented through different services or modules. For example, a first service allocates virtual addresses, a second service allocates memory, and a third service maps virtual addresses to physical addresses; this is not limited to specific services. This reduces the excessive computational pressure on a service caused by performing multiple processes through a single service.

[0260] In one possible implementation, requesting a third virtual address for the third device and mapping the third virtual address to a first physical address includes:

[0261] The first service requests a third virtual address for the third device and maps the third virtual address to the first physical address.

[0262] In this embodiment of the application, the first service can also apply for and map the virtual address of the third device. This can reduce the inefficiency and resource consumption caused by multiple services interacting to achieve address mapping, thereby improving the efficiency of address mapping and reducing resource consumption.

[0263] In another possible implementation, a third virtual address of the third device can be requested through other services and mapped to the first physical address. This can reduce the problem of excessive service computing power pressure caused by performing multiple processes through a single service.

[0264] In one possible implementation, the first application requests memory, including:

[0265] The first application responds to opening a window on the electronic device by requesting graphics memory, which is used to store the graphics data required by the window.

[0266] In the embodiments of this application, the window can be the window that launches the first application, or it can be a newly opened window in the first application, and there is no limitation here.

[0267] In this embodiment of the application, the first application requests graphics memory in response to opening a window on the electronic device, which can increase the number of windows that the electronic device can open.

[0268] In one possible implementation, the first memory is also used to store the second data written by the second device, that is, the second device writes data to the first memory as a producer device.

[0269] In another possible implementation, requesting a second virtual address for the second device includes:

[0270] If it is determined that data is processed through the second device and the first identifier of the second device is not set, a second virtual address of the second device is requested, and the first identifier of the second device is set, wherein the first identifier indicates that the device has been mapped to the first physical address.

[0271] In this embodiment, the second device serves as a consumer device. If it is determined that access is required through the second device and the first identifier of the second device is not set, it indicates that the virtual address of the second device is not mapped to the first physical address. Consequently, the second device cannot access the first memory normally. Therefore, a second virtual address of the second device is requested, which maps the second virtual address to the first physical address, enabling the second device to access the first memory normally and then obtain the first data from the first memory for processing.

[0272] It should be noted that the user information (including but not limited to user device information, user personal information, etc.) and data (including but not limited to data used for analysis, data stored, data displayed, etc.) involved in this application are all information and data authorized by the user or fully authorized by all parties. Furthermore, the collection, use and processing of the relevant data must comply with the relevant laws, regulations and standards of the relevant countries and regions, and corresponding operation portals are provided for users to choose to authorize or refuse.

[0273] It should also be understood that the steps of the various embodiments described above can be coupled to each other, and this application does not limit this. Furthermore, the sequence number of each process does not imply the order of execution; the execution order of each process should be determined by its function and internal logic, and should not constitute any limitation on the implementation process of the embodiments of this application.

[0274] The address mapping method of the present application embodiment has been described in detail above. The address mapping device of the present application embodiment will be described in detail below with reference to FIG10.

[0275] Figure 10 shows a schematic block diagram of an address mapping device 1000 provided in an embodiment of this application. The device 1000 includes a processor 1001, a transceiver 1002, and a memory 1003. The processor 1001, transceiver 1002, and memory 1003 communicate with each other via internal interconnection paths. The memory 1003 stores instructions, and the processor 1001 executes the instructions stored in the memory 1003 to control the transceiver 1002 to transmit and / or receive signals.

[0276] It should be understood that the steps performed by the apparatus 1000 in this application embodiment can be referred to the description of the method embodiment above, and will not be repeated here.

[0277] In embodiments of this application, the device 1000 in FIG10 may also be a chip or a chip system, such as a system on chip (SoC).

[0278] It should be understood that the device 1000 may specifically be the electronic device in the above embodiments, and may be used to execute the various steps and / or processes corresponding to the electronic device in the above method embodiments. Optionally, the memory 1003 may include read-only memory and random access memory, and provide instructions and data to the processor. A portion of the memory may also include non-volatile random access memory. For example, the memory may also store device type information. The processor 1001 may be used to execute instructions stored in the memory, and when the processor 1001 executes instructions stored in the memory, the processor 1001 is used to execute the various steps and / or processes of the above method embodiments. The transceiver 1002 may include a transmitter and a receiver, the transmitter may be used to implement the various steps and / or processes corresponding to the transceiver for performing a transmitting action, and the receiver may be used to implement the various steps and / or processes corresponding to the transceiver for performing a receiving action.

[0279] It should be understood that, in the embodiments of this application, the processor may be a central processing unit (CPU), or it may be other general-purpose processors, digital signal processors (DSPs), application-specific integrated circuits (ASICs), field-programmable gate arrays (FPGAs), or other programmable logic devices, discrete gate or transistor logic devices, discrete hardware components, etc. The general-purpose processor may be a microprocessor or any conventional processor.

[0280] In implementation, each step of the above method can be completed by integrated logic circuits in the processor's hardware or by instructions in software. The steps of the method disclosed in the embodiments of this application can be directly manifested as execution by a hardware processor, or as a combination of hardware and software modules within the processor. The software modules can reside in random access memory, flash memory, read-only memory, programmable read-only memory, electrically erasable programmable memory, registers, or other mature storage media in the art. This storage medium is located in memory, and the processor executes the instructions in the memory, combining them with its hardware to complete the steps of the above method. To avoid repetition, detailed descriptions are omitted here.

[0281] It should be understood that the device 1000 here can also be embodied in the form of a functional module. For example, device 1000 can refer to an application-specific integrated circuit (ASIC), electronic circuits, a processor (e.g., a shared processor, a proprietary processor, or a group processor, etc.) and memory for executing one or more software or firmware programs, combined logic circuits, and / or other suitable components that support the described functions.

[0282] This application also provides a computer-readable storage medium for storing a computer program that implements the methods shown in the above-described method embodiments.

[0283] This application also provides a computer program product, which includes a computer program (also referred to as code or instructions). When the computer program is run on a computer, the computer can execute the methods shown in the above-described method embodiments.

[0284] Those skilled in the art will recognize that the units and algorithm steps of the various examples described in conjunction with the embodiments disclosed herein can be implemented in electronic hardware, or a combination of computer software and electronic hardware. Whether these functions are implemented in hardware or software depends on the specific application and design constraints of the technical solution. Those skilled in the art can use different methods to implement the described functions for each specific application, but such implementation should not be considered beyond the scope of this application.

[0285] Those skilled in the art will understand that, for the sake of convenience and brevity, the specific working processes of the systems, devices, and units described above can be referred to the corresponding processes in the foregoing method embodiments, and will not be repeated here.

[0286] In the embodiments provided in this application, it should be understood that the disclosed systems, apparatuses, and methods can be implemented in other ways. For example, the apparatus embodiments described above are merely illustrative; for instance, the division of units is only a logical functional division, and in actual implementation, there may be other division methods. For example, multiple units or components may be combined or integrated into another system, or some features may be ignored or not executed. Furthermore, the coupling or direct coupling or communication connection shown or discussed may be through some interfaces; the indirect coupling or communication connection between apparatuses or units may be electrical, mechanical, or other forms.

[0287] The units described as separate components may or may not be physically separate. The components shown as units may or may not be physical units; that is, they may be located in one place or distributed across multiple network units. Some or all of the units can be selected to achieve the purpose of the embodiments of this application, depending on actual needs.

[0288] In addition, the functional units in the various embodiments of this application can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit.

[0289] If a function is implemented as a software functional unit and sold or used as an independent product, it can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of this application can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute all or part of the steps of the methods of the various embodiments of this application. The aforementioned storage medium includes various media capable of storing program code, such as USB flash drives, portable hard drives, read-only memory (ROM), random access memory (RAM), magnetic disks, or optical disks.

Claims

1. An address mapping method, characterized by, The method is applied to an electronic device, which includes a first application, a first device, a second device, a third device, and physical memory, wherein the bit widths of the first device, the second device, and the third device are not completely equal. The first application requests memory; The system requests a first virtual address for the first device and a second virtual address for the second device, allocates first memory in the physical memory, and maps the first virtual address and the second virtual address to the first physical address of the first memory, wherein the first memory is used to store at least the first data written by the first device. Request a third virtual address for the third device and map the third virtual address to the first physical address; The third device retrieves the first data from the first memory corresponding to the first physical address and processes it.

2. The method of claim 1, wherein, After the first application requests memory, the method further includes: A first identifier is set for the first device and the second device, the first identifier indicating that the device has been mapped to the first physical address.

3. The method according to claim 1 or 2, characterized in that, The step of applying for the third virtual address of the third device and mapping the third virtual address to the first physical address includes: If it is determined that data is processed through the third device and the first identifier of the third device is not set, a third virtual address of the third device is requested, and the third virtual address is mapped to the first physical address. The first identifier of the third device is set, indicating that the device has been mapped to the first physical address.

4. The method according to any one of claims 1-3, characterized in that, Before applying for the third virtual address of the third device and mapping the third virtual address to the first physical address, the method further includes: Obtain a first set and a second set, wherein the first set includes a device with the first identifier set, the second set includes a device for processing data, the device with the first identifier set includes the first device and the second device, and the device for processing data includes the third device; If a first difference set is determined to exist based on the first set and the second set, a virtual device of the device in the first difference set is requested, and the virtual device of the device in the first difference set is mapped to the first physical address. The device in the first difference set is a device in the second set and the device in the first difference set is different from any device in the first set. The step of applying for the third virtual address of the third device and mapping the third virtual address to the first physical address includes: If the first difference set includes the third device, a third virtual address of the third device is requested, and the third virtual address is mapped to the first physical address.

5. The method according to any one of claims 1-4, characterized in that, The first device includes a central processing unit, the second device includes a graphics processor, and the third device includes a display subsystem.

6. The method according to any one of claims 1-5, characterized in that, The electronic device further includes a first service, wherein the first application requests memory, including: The first application requests memory from the first service; The process of requesting a first virtual address for the first device and a second virtual address for the second device, allocating first memory in the physical memory, and mapping the first virtual address and the second virtual address to first physical addresses in the first memory, includes: The first service requests a first virtual address for the first device and a second virtual address for the second device, allocates first memory in the physical memory, and maps the first virtual address and the second virtual address to the first physical address of the first memory, respectively.

7. The method according to any one of claims 1 to 6, characterized in that, The first application requests memory, including: The first application requests graphics memory in response to the opening of a window on the electronic device, the graphics memory being used to store the graphics data required by the window.

8. The method according to any one of claims 1 to 7, characterized in that, The first memory is also used to store the second data written by the second device; or, The application for the second virtual address of the second device includes: If it is determined that data is being processed by the second device and the first identifier of the second device is not set, a second virtual address of the second device is requested, and the first identifier of the second device is set, wherein the first identifier indicates that the device has been mapped to the first physical address.

9. An address mapping apparatus, characterized by comprising: include: A processor coupled to a memory storing computer-executable instructions, the processor executing the computer-executable instructions stored in the memory, causing the processor to perform the method as described in any one of claims 1 to 8.

10. A computer-readable storage medium, characterized in that, Used to store a computer program, the computer program including instructions for implementing the method as described in any one of claims 1 to 8.

11. A computer program product comprising computer program code in said computer program product, characterised in that, When the computer program code is run on a computer, it causes the computer to implement the method as described in any one of claims 1 to 8.

Images