Image compression, decompression system, image processing method and electronic device

Abstract

The application provides an image compression and decompression system, an image processing method and an electronic device. The image compression system comprises at least one first device interface, a compression end block adapter and an image compression unit. The compression end block adapter is configured to convert a first image block into a second image block that meets the size requirement of the image compression unit when the size of the first image block does not meet the size requirement of the image compression unit; and the image compression unit is configured to receive the second image block and perform compression processing to generate a compressed code stream. The image decompression system comprises an image decompression unit, a decompression end block adapter and at least one second device interface. The decompression end block adapter is configured to convert a third image block output by the image decompression unit into a fourth image block that meets the size requirement of the second device when the size of the third image block does not meet the size requirement of the second device. The intercommunication between modules and code stream sharing are realized by flexibly setting the block adapter.

Description

Technical Field

[0001] This application relates to the field of computer technology, and more specifically, to image compression and decompression systems, image processing methods, and electronic devices. Background Technology

[0002] In some scenarios, to reduce system bandwidth, power consumption, and memory space, image data is typically compressed before storage or transmission. Existing compression technologies compress image data into fixed-size blocks, writing the compressed bitstream into memory and reading and decompressing it only when needed. Because the image block size is fixed, different modules cannot communicate or share bitstreams. Summary of the Invention

[0003] The purpose of this application is to provide an image compression and decompression system, an image processing method, and an electronic device to improve the above-mentioned technical problems.

[0004] In a first aspect, embodiments of this application provide an image compression system, comprising: at least one first device interface for receiving a first image block from the first device; a compression block adapter for receiving the first image block and converting it into a second image block that meets the image block size requirements of the image compression unit when the size of the first image block does not conform to the size requirements of the image block received by the image compression unit; the compression block adapter being coupled to the first device interface; an image compression unit for receiving the second image block and performing compression processing to generate a compressed bitstream; and the image compression unit being coupled to the compression block adapter.

[0005] In the above implementation process, the image compression system provided in this application, by setting a compression end-block adapter between the first device interface and the image compression unit, can convert first image blocks of various sizes generated by different first devices into second image blocks of fixed size required by the image compression unit. This allows multiple first devices to share the same image compression unit, eliminating the need to configure a separate compression system for each first device. This simplifies the overall chip architecture design and reduces the investment in hardware resources. Furthermore, since the compression unit can directly receive second image blocks of matching size, the compression process can be more efficient.

[0006] Optionally, in this embodiment, the compression block adapter includes: a data caching unit and a data reordering unit; the data caching unit is used to receive and cache a first image block; the data reordering unit is used to process the first image block according to the size requirements of the image compression unit and output one or more second image blocks that meet the size requirements; the image compression system also includes a memory interface for writing the compressed bitstream into memory; the memory interface is coupled to the image compression unit.

[0007] In the above implementation process, by setting up a data caching unit and a data reordering unit, the compression block adapter can first temporarily store the image data output by the first device, and then rearrange it according to the specific order required by the image compression unit before outputting it. Regardless of the scanning order or image block size used by the first device, the input requirements of the image compression unit can be met after processing by the compression block adapter.

[0008] Secondly, embodiments of this application provide an image decompression system, comprising: an image decompression unit for decompressing a compressed bitstream and outputting a third image block; a decompression end-block adapter for converting the third image block into a fourth image block that meets the image block size requirements of a second device when the size of the third image block output by the image decompression unit does not meet the image block size requirements of a second device; the decompression end-block adapter is coupled to the image decompression unit; at least one second device interface for outputting a fourth image block that meets the image block size requirements to a second device; the second device interface is coupled to the decompression end-block adapter.

[0009] In the above implementation process, by setting a decompression block adapter between the image decompression unit and the second device interface, the fixed-size third image block after decompression can be converted into a fourth image block of the required size by the second device, according to the specific needs of the second device. In this way, multiple different second devices can share the same image decompression unit, eliminating the need to configure a separate decompression circuit for each device. This reduces redundant investment in hardware resources and improves the overall efficiency of image decompression and output.

[0010] Optionally, in this embodiment, the decompression end block adapter includes a command adaptation unit and a data adaptation unit; the command adaptation unit and the data adaptation unit each include a port coupled to the AXI bus channel; the command adaptation unit is used to receive and parse a read command issued by the second device, the read command being used to request a fourth image block that meets the image block size requirements required by the second device; and if it is determined that the size of the third image block does not meet the image block size requirements required by the second device, the read command is processed; the processing includes command merging processing or command splitting processing; the data adaptation unit is used to perform data processing on the third image block according to the processing of the read command by the command adaptation unit, to generate a fourth image block that meets the image block size requirements required by the second device; the data processing includes image merging processing or image splitting processing on the third image block.

[0011] In the above implementation process, the decompression end-block adapter includes a command adaptation unit and a data adaptation unit. The command adaptation unit merges or splits the read commands from the second device, and the data adaptation unit splits or merges the third image block accordingly, ensuring that the size requirements in the command match the output granularity of the data. The image decompression unit outputs data according to its fixed block size. When the fourth image block size required by the second device is the same as the third image block size, it does not need to be processed by the decompression end-block adapter.

[0012] Optionally, in this embodiment, the command adaptation unit and the data adaptation unit are configured such that: if the command adaptation unit performs command merging processing on the read command, the data adaptation unit performs image splitting processing on the third image block to generate a fourth image block; if the command adaptation unit performs command splitting processing on the read command, the data adaptation unit performs image merging processing on the third image block to generate a fourth image block.

[0013] In the above implementation process, data is split when commands are merged and data is merged when commands are split. This collaborative processing enables the image decompression unit to output data according to its own fixed block size, and the image blocks of various sizes requested by the second device can obtain a fourth image block with a matching size.

[0014] Thirdly, embodiments of this application provide an image processing method, including: if the size of a first image block generated by a first device does not meet the size requirements of an image block received by an image compression unit, then the first image block is received using a compression end-block adapter, and the first image block is converted into a second image block that meets the image block size requirements of the image compression unit, and the second image block is compressed by the image compression unit; and / or, if the size of a third image block output by an image decompression unit does not meet the image block size requirements of a second device, then the third image block is converted into a fourth image block that meets the image block size requirements of a second device using a decompression end-block adapter, and the fourth image block is output to the second device.

[0015] In the above implementation process, when the image block size generated by the first device does not match the size output by the compression unit, the compression block adapter converts it into a second image block that meets the requirements, enabling the first device to use the compression unit for compression normally. When the image block size required by the second device does not match the size output by the decompression unit, the decompression block adapter converts it into a fourth image block, allowing the second device to directly obtain data of the required size. The first and second devices with different size requirements can share the same set of compression and decompression hardware, eliminating the need to configure a separate conversion circuit for each device.

[0016] Optionally, in this embodiment, the compression block adapter includes a data buffer unit and a data reordering unit; receiving a first image block using the compression block adapter and converting the first image block into a second image block that meets the image block size requirements of the image compression unit includes: receiving the first image block and buffering the first image block in the data buffer unit; processing the first image block according to the size requirements of the image compression unit through the data reordering unit, and outputting one or more second image blocks that meet the size requirements.

[0017] In the above implementation process, the first image block is first cached in the data cache unit, and then processed by the data reordering unit according to the size requirements of the image compression unit to output one or more second image blocks that meet the requirements. Regardless of the scanning order or image block size used by the first device, the input requirements of the image compression unit can be met after processing by the compression end block adapter.

[0018] Optionally, in this embodiment, the decompression end-block adapter includes a command adaptation unit and a data adaptation unit. Converting a third image block into a fourth image block that meets the image block size requirements of the second device using the decompression end-block adapter includes: receiving and parsing a read command issued by the second device through the command adaptation unit, the read command requesting a fourth image block that meets the image block size requirements of the second device; if the command adaptation unit determines that the size of the third image block does not meet the image block size requirements of the second device, processing the read command; the processing includes command merging or command splitting; if the command adaptation unit performs command merging on the read command, then the data adaptation unit performs image splitting on the third image block to generate the fourth image block; if the command adaptation unit performs command splitting on the read command, then the data adaptation unit performs image merging on the third image block to generate the fourth image block.

[0019] In the above implementation process, the command adaptation unit first merges or splits the read commands from the second device, and then the data adaptation unit performs the reverse splitting or merging process on the third image block. The image decompression unit outputs data according to its fixed block size. When the size of the fourth image block required by the second device is the same as the size of the third image block, there is no need to perform format conversion locally. This method of command and data collaborative processing reduces the additional resource consumption caused by size mismatch.

[0020] Optionally, in this embodiment, the image compression unit and the image decompression unit are frame buffer compression units and frame buffer decompression units within the same bus arbitration domain; multiple different devices share the same frame buffer compression unit for data writing through a compression end block adapter, and multiple different devices share the same frame buffer decompression unit for data reading through a decompression end block adapter; wherein, the same bus arbitration domain arbitrates the bus access requests of multiple devices through a bus arbitrator.

[0021] In the above implementation, by placing the image compression unit and the image decompression unit within the same bus arbitration domain and having them uniformly scheduled by the bus arbitrator, the chip only needs one set of compression unit and one set of decompression unit to serve multiple devices, eliminating the need for a separate compression and decompression hardware for each device. This reduces the chip's hardware cost and chip area. The bus arbitrator also makes the entire system's data writing and reading process smoother.

[0022] Fourthly, embodiments of this application also provide an electronic device, including: a processor and a memory, the memory storing computer program instructions, which are executed by the processor to perform the method provided in the third aspect or any implementation thereof.

[0023] The image compression and decompression system, image processing method, and electronic device provided in this application allow for the image compression system to convert first image blocks of various sizes generated by different first devices into second image blocks of a fixed size required by the image compression unit by setting a compression block adapter between the first device interface and the image compression unit. This enables multiple first devices to share the same image compression unit, eliminating the need to configure a separate compression system for each first device. This simplifies the overall chip architecture design and reduces hardware resource investment. Furthermore, since the compression unit can directly receive second image blocks of matching size, the compression process is more efficient. Attached Figure Description

[0024] To more clearly illustrate the technical solutions of the embodiments of this application, the accompanying drawings used in the embodiments of this application will be briefly introduced below. It should be understood that the following drawings only show some embodiments of this application and should not be regarded as a limitation of the scope. For those skilled in the art, other related drawings can be obtained based on these drawings without creative effort.

[0025] Figure 1 This is a system architecture diagram of the image compression system provided in the embodiments of this application; Figure 2 A schematic diagram of a compression end block adapter provided in an embodiment of this application; Figure 3 This is a system architecture diagram of the image decompression system provided in the embodiments of this application; Figure 4 A schematic diagram of a decompression end block adapter provided in an embodiment of this application; Figure 5 This is a schematic diagram illustrating an embodiment of the present application that uses only an image compression system; Figure 6 This application provides a schematic diagram illustrating an embodiment of an image decompression system. Figure 7 A schematic diagram illustrating the simultaneous use of an image compression system and an image decompression system provided in this application embodiment; Figure 8 A schematic diagram illustrating multiple devices sharing the same image compression system as provided in this application embodiment; Figure 9 A schematic diagram illustrating multiple devices sharing the same image decompression system as provided in this application embodiment; Figure 10 A schematic diagram illustrating a shared image compression system and image decompression system for multiple devices provided in an embodiment of this application; Figure 11 Basic architecture diagram provided for embodiments of this application; Figure 12 This is a schematic diagram of the structure of an electronic device provided in an embodiment of this application. Detailed Implementation

[0026] The embodiments of the technical solution of this application will now be described in detail with reference to the accompanying drawings. These embodiments are only used to more clearly illustrate the technical solution of this application and are therefore merely examples, and should not be used to limit the scope of protection of this application.

[0027] Unless otherwise defined, all technical and scientific terms used herein have the same meaning as commonly understood by one of ordinary skill in the art to which this application belongs; the terminology used herein is for the purpose of describing particular embodiments only and is not intended to limit this application.

[0028] In the description of the embodiments of this application, technical terms such as "first" and "second" are used only to distinguish different objects and should not be construed as indicating or implying relative importance or implicitly specifying the number, specific order, or primary and secondary relationship of the indicated technical features. In the description of the embodiments of this application, "multiple" means two or more, unless otherwise explicitly defined.

[0029] Existing compression technologies, including framebuffer compression, compress image data in fixed-size blocks. The compressed bitstream is written to memory and then read and decompressed when needed.

[0030] This fixed-block-size design has significant limitations. Typically, the module that compresses and writes data is also responsible for reading and decompressing it. When another module needs an image block size that doesn't match the existing compressed block size, it cannot directly use the existing compressed bitstream. For example, if Master1 needs an image block size that doesn't match Master0's compressed block size, it cannot use Master0's compressed bitstream. Therefore, different Masters cannot interconnect or share bitstreams. To solve this problem, a separate compression and decompression system often needs to be developed for each module. This not only increases development difficulty and time but also consumes more hardware resources, leading to increased chip area and cost.

[0031] This application embodiment sets up a block adapter in the compression unit and / or decompression unit to convert image blocks into the required image block size, so as to realize communication between different masters.

[0032] Please see Figure 1 The diagram shows the system architecture of the image compression system provided in an embodiment of this application.

[0033] An image compression system includes: at least one first device interface, a compression block adapter, and an image compression unit.

[0034] The first device interface is a hardware port in an image compression system used for coupling with an external first device. The first device can be an on-chip image signal processor (ISP), display controller, video codec, or other module (Master) that needs to write image data to memory.

[0035] The first device interface can be implemented using a bus protocol such as AXI, and includes address, data, and control channels. The first device interface is responsible for receiving the first image block sent by the first device. The first image block refers to the raw image data unit generated by the first device; for example, the first device may output image data block by block in 8×8 pixel blocks. In hardware implementation, the first device interface internally includes registers for temporarily storing received address and control information, and a FIFO for buffering incoming image data. The first device interface then transmits the received first image block along with related control signals to the compression end block adapter.

[0036] The compression block adapter is a conversion module that couples the first device interface to the image compression unit. The function of the compression block adapter is to determine whether the size of the first image block meets the size requirements of the image block received by the image compression unit. If the size of the first image block does not meet the size requirements of the image compression unit, the adapter receives the first image block and converts it into a second image block that meets the size requirements of the image compression unit.

[0037] For example, the image compression unit internally compresses the image at a fixed 16×16 pixels, while the first image block generated by the first device is 8×8 pixels in size. When the sizes do not match, the compression block adapter receives the first image block and converts it into a second image block of 16×16 pixels that meets the requirements of the image compression unit.

[0038] In terms of implementation, the compression block adapter temporarily stores the first image block in its internal buffer according to the original output order of the first device. Then, it extracts pixels from the buffer and rearranges them according to the size requirements of the image block required by the image compression unit, so that the output second image block meets the input requirements of the image compression unit in terms of size and pixel arrangement. This process will be described in detail later.

[0039] The compression block adapter is coupled to the first device interface via an internal bus and to the image compression unit via a data stream interface.

[0040] The image compression unit is a hardware module that executes the compression algorithm. Its input interface receives second image blocks from the compression block adapter. Since the size of the second image blocks is already adapted to the requirements of the compression unit, the compression unit can directly compress each second image block to generate the corresponding compressed bitstream. The image compression unit typically contains logic circuits such as predictive coding, transform coding, or entropy coding. The compression algorithm can be ARM AFBC or other framebuffered compression techniques. After compression, the compression unit writes the compressed bitstream to external memory (such as DDR) through a memory interface for subsequent use.

[0041] In the implementation of the above embodiments: The image compression system provided in this application, by setting a compression end block adapter between the first device interface and the image compression unit, can convert first image blocks of various sizes generated by different first devices into second image blocks of fixed size required by the image compression unit. This allows multiple first devices to share the same image compression unit, eliminating the need to configure a separate compression system for each first device. This simplifies the overall chip architecture design and reduces the investment in hardware resources. Furthermore, since the compression unit can directly receive second image blocks of matching size, the compression process can be more efficient.

[0042] Please see Figure 2 The diagram shown illustrates a compressed block adapter provided in an embodiment of this application. Optionally, in an embodiment of this application, the compressed block adapter includes: a data caching unit and a data reordering unit. Figure 2 In this context, FBC_BLOCK_ADAPTER represents the compressed end block adapter, data_buffer represents the data buffer unit, and data_reorder represents the data reordering unit.

[0043] The data cache unit can be composed of on-chip static random access memory (SRAM) or a register array, used to cache the first image block received from the first device interface. It is understood that the cache can store data in the original order of the first image block, for example, using a zigzag scanning order.

[0044] The data caching unit is configured to cache at least one complete first image block. When the size of the first image block is smaller than the compressed block, multiple first image blocks may need to be cached to combine into a complete second image block; when the size of the first image block is larger than the compressed block, a portion of the data from the first image block needs to be cached to split it into multiple second image blocks. The caching unit manages the storage and retrieval of data through write pointers and read pointers.

[0045] The data reordering unit reads the first image block from the data buffer unit according to the size requirements of the image compression unit, which is the fixed compression block size required by the image compression unit, and rearranges the output order of the pixels to output one or more second image blocks that meet the size requirements.

[0046] For example, the first image block generated by the first device is a 16×16 block, while the compression unit requires 128*2 blocks of input. Although the total number of pixels is the same, the size of the first image block does not meet the size requirements, so the first image block needs to be processed.

[0047] The first device outputs pixel data in a conventional left-to-right, top-to-bottom line-by-line scanning order. Each row of 16 pixels is numbered sequentially: row 1 pixels 0-15, row 2 pixels 16-31, and so on, up to row 16 pixels 240-255. This data in its original order is first stored in the data buffer unit of the compressed block adapter. The buffer unit stores data in the order it was written, without altering the original arrangement.

[0048] The data reordering unit reads data from the data buffer unit, and its reading rules are determined by the requirements of the image compression unit. In this example, the image compression unit requires pixels to be input in a specific non-line-by-line order. The processing rules of the reordering unit are as follows: for odd-numbered rows (rows 1, 3, 5, and 7), the original left-to-right order is maintained; for even-numbered rows (rows 2, 4, 6, and 8), the reverse right-to-left order is followed. This rule also applies to rows 9 through 16.

[0049] The data reordering unit first processes the first eight rows. It reads the data from the cache sequentially: row 1 in order from 0 to 15, row 2 in order from 31 to 16, row 3 in order from 32 to 47, row 4 in order from 63 to 48, and so on until row 8. The first eight rows of pixels are concatenated into an array 128 pixels wide and 1 pixel high, forming the first row of the second image block. For the next eight rows (rows 9 to 16), the same odd-even row reversal rule is used to concatenate the reading results into a second 128×1 pixel array, forming the second row of the second image block. Thus, the data reordering unit generates a second image block that meets the stated size requirement (128*2).

[0050] The memory interface is a hardware channel connecting the image compression unit and external memory. The memory interface follows a bus protocol and includes an address channel, a write data channel, and a write response channel. After the image compression unit completes compression, it passes the compressed bitstream and its destination address in memory to the memory interface. The memory interface is responsible for writing the compressed bitstream into memory and returning a write completion status.

[0051] In the implementation of the above embodiments: by setting a data caching unit and a data reordering unit, the compression block adapter can first temporarily store the image data output by the first device, and then rearrange it according to the specific order required by the image compression unit before outputting it. Regardless of the scanning order or image block size used by the first device, the input requirements of the image compression unit can be met after processing by the compression block adapter.

[0052] Please see Figure 3 The diagram shows the system architecture of the image decompression system provided in an embodiment of this application.

[0053] An image decompression system includes: an image decompression unit, a decompression end block adapter, and at least one second device interface.

[0054] The image decompression unit is a hardware module used to read the compressed bitstream from memory and perform decompression processing. The compressed bitstream is compressed data written to memory by the image compression system. The image decompression unit internally contains decompression logic corresponding to the compression algorithm. After reading the compressed bitstream from memory through the memory interface, the image decompression unit decompresses it block by block according to the frame buffer decompression algorithm, outputting the restored original image data, i.e., the third image block. The third image block has a fixed size, which is consistent with the size of the second image block used during compression. The output interface of the image decompression unit passes the third image block to the subsequent decompression end-block adapter.

[0055] The decompression block adapter is a hardware conversion module that connects the image decompression unit and the second device interface. Its function is to convert the third image block output by the image decompression unit into a fourth image block that meets the requirements of the second device, provided that the size of the third image block does not conform to the size requirements of the second device.

[0056] The second device can be a display controller, image processor, or other module (Master) that needs to read image data. Each second device has a fixed size of image blocks that it needs to receive. When the fixed size of the third image block does not match the size required by the second device, the decompression end block adapter needs to convert the third image block to generate a fourth image block that meets the requirements of the second device.

[0057] The decompression end block adapter needs to receive and parse the read command issued by the second device. The read command contains the image block size requirements and address information requested by the second device. The decompression end block adapter also needs to receive the third image block from the image decompression unit and split or merge the data according to the command requirements.

[0058] The decompression end block adapter internally contains command parsing logic and data reassembly logic. The command parsing logic is responsible for determining the relationship between the block size requested by the second device and the third image block size, and accordingly decides whether to merge or split the read command. The data reassembly logic, based on the result of the command processing, splits a single third image block into multiple fourth image blocks, or merges multiple third image blocks into a single fourth image block.

[0059] The decompression end block adapter also includes a channel port that interfaces with the AXI bus to receive read commands from the bus and return the corresponding data.

[0060] The second device interface is used to output a fourth image block that meets the image block size requirements to the second device; the second device interface is coupled to the decompression end block adapter.

[0061] The second device interface is a hardware port in the image decompression system used to connect to external second devices. Each second device corresponds to at least one second device interface. This interface also conforms to the standard bus protocol. After the decompression end block adapter completes the data conversion, the generated fourth image block is sent to the second device that initiated the read command through the second device interface. The second device interface is responsible for packaging the fourth image block according to the bus protocol format and returning it to the second device. In the case of multiple second devices, the second device interface can work with the bus arbitrator to ensure that the requests of each device are reasonably scheduled.

[0062] In the implementation of the above embodiments: by setting a decompression block adapter between the image decompression unit and the second device interface, the fixed-size third image block after decompression can be converted into a fourth image block of the required size by the second device according to the specific needs of the second device. In this way, multiple different second devices can share the same image decompression unit, eliminating the need to configure a separate decompression circuit for each device. This reduces redundant investment in hardware resources and improves the overall efficiency of image decompression and output.

[0063] Please see Figure 4 The diagram shown illustrates a decompression end-block adapter provided in an embodiment of this application. Optionally, in an embodiment of this application, the decompression end-block adapter includes a command adaptation unit and a data adaptation unit; the command adaptation unit and the data adaptation unit each include a port coupled to an AXI bus channel. Figure 4 In this context, FBDC_BLOCK_ADAPTER represents the decompression end block adapter, cmd_adapt represents the command adaptation unit, and data_adapt represents the data adaptation unit.

[0064] The command adapter unit is a module in the decompression block adapter used to process read commands from the second device. The command adapter unit includes a port directly connected to the AXI bus read address channel, capable of receiving read commands from the second device. The read command includes the address of the image block requested by the second device and the image block size requirement (i.e., the size of the fourth image block).

[0065] The command adaptation unit first parses the read command and extracts the image block size required by the second device. It then compares the required image block size with the fixed size of the third image block output by the image decompression unit. When the two are inconsistent, the command adaptation unit needs to process the read command. There are two processing methods: command merging and command splitting.

[0066] Command merging processing is applicable when the image block size required by the second device is smaller than the third image block size. For example, the third image block is 16×16 pixels, while the second device requests multiple 8×8 pixel fourth image blocks. In this case, the second device will issue multiple read commands, each requesting one 8×8 block. The command adaptation unit merges these scattered small-sized read commands into a large read command, the amount of data requested by this large command corresponding to a complete 16×16 third image block.

[0067] Command splitting is used when the image block size required by the second device is larger than the third image block size. For example, the third image block is 16×16 pixels, but the second device requests a fourth image block of 32×32 pixels. In this case, the amount of data requested by a single read command from the second device exceeds the size of a single third image block. The command adaptation unit splits this read command into multiple smaller commands, each requesting a 16×16 third image block. These split smaller commands are sent sequentially to the image decompression unit, causing it to output multiple third image blocks one by one.

[0068] The data adaptation unit is the module in the decompression block adapter responsible for processing the image data stream. The data adaptation unit includes a port directly connected to the AXI bus read data channel, and is used to return the requested fourth image block data to the second device. The data adaptation unit works in conjunction with the command adaptation unit: based on the processing result of the read command by the command adaptation unit, it performs corresponding data processing on the third image block output by the image decompression unit.

[0069] When the command adaptation unit performs command merging processing (combining multiple small commands into one large command), the image decompression unit outputs a relatively large third image block. This third image block corresponds to multiple small fourth image blocks requested by the second devices. The data adaptation unit needs to perform image splitting processing on this third image block.

[0070] For example, the second device needs a fourth image block of 8×8 pixels, while the third image block output by the image decompression unit is 16×16 pixels. At this time, the second device will issue multiple read commands, each requesting an 8×8 block. Command merging processing refers to the command adaptation unit merging these smaller commands into a large read command, the amount of data requested by this large command corresponding to a complete 16×16 third image block. The image decompression unit outputs a third image block based on this large command. After receiving the third image block, the data adaptation unit, according to the block positions requested by the original smaller commands, splits the third image block into four 8×8 fourth image blocks and returns them to the second device respectively.

[0071] When the command adaptation unit performs command splitting (breaking a large command into multiple smaller commands), the image decompression unit sequentially outputs multiple third image blocks. The data adaptation unit combines these multiple third image blocks into a single large fourth image block requested by the second device.

[0072] For example, the second device needs a fourth image block of 32×32 pixels, while the third image block is 16×16 pixels. The second device issues a read command requesting a 32×32 block. The command adaptation unit splits this command into four subcommands, each requesting a 16×16 third image block, and sends them to the image decompression unit. The image decompression unit outputs the four third image blocks sequentially. The data adaptation unit receives these four third image blocks sequentially and stitches them together into a complete 32×32 fourth image block. After merging, the data adaptation unit returns the fourth image block to the second device all at once.

[0073] In the implementation of the above embodiments: the decompression end-block adapter is equipped with a command adaptation unit and a data adaptation unit. The command adaptation unit merges or splits the read commands from the second device, and the data adaptation unit splits or merges the third image block accordingly, so that the size requirements in the command and the output granularity of the data can match each other. The image decompression unit outputs data according to its fixed block size. When the size of the fourth image block required by the second device is the same as the size of the third image block, it does not need to be processed by the decompression end-block adapter.

[0074] The collaborative processing of data splitting during command merging and data merging during command splitting allows the image decompression unit to output data according to its own fixed block size, while the image blocks of various sizes requested by the second device can obtain a fourth image block with a matching size.

[0075] The image compression and decompression systems provided in this application can be configured independently or used in combination. In actual chip design, depending on different application requirements, one can choose to configure the image compression system only in the data write path (i.e., configure only the compression end block adapter), or only in the data read path (i.e., configure only the decompression end block adapter), or configure both systems simultaneously in the data write and read paths. The following six implementation examples illustrate the applicable scenarios and working principles of different configuration methods.

[0076] Implementation Case 1: Using only an image compression system; Please see Figure 5 The illustration shows a schematic diagram of an image compression system provided by an embodiment of this application; wherein, DDR represents Double Data Rate Synchronous Dynamic Random Access Memory, FAB_AXI represents AXI bus interconnect matrix, AXI_ARB represents AXI bus arbiter, FBC represents frame buffer compression unit, FBDC represents frame buffer decompression unit, and block_adapter represents block adapter (it can be understood that if block_adapter is connected to FBC, it is a compression end block adapter; if block_adapter is connected to FBDC, it is a decompression end block adapter).

[0077] like Figure 5 As shown in Case 1, Master 0 (the first device) produces image blocks of 8×8 pixels, while the Frame Buffer Compression Unit (FBC) requires a compressed block size of 16×16 pixels, creating a mismatch. Master 1 (the second device) requires an image block size of 16×16 pixels, matching the size output by the decompression unit. Therefore, an image compression system (containing a compressed block adapter) is used only on the write path, and no image decompression system is used on the decompression path; only a single decompression unit (FBDC) is required.

[0078] Application scenarios that rely solely on image compression systems can include: an image processing module (such as an ISP) outputs raw image data in small blocks, while the compression unit needs to receive large data blocks to improve compression efficiency; subsequently, a display module happens to require the same large data blocks for display. In this case, the compression block adapter in the image compression system combines multiple small blocks into a large block, compresses it, decompresses it, and directly outputs it to the display module, eliminating the need for an image decompression system.

[0079] Implementation Case 2: Using only an image decompression system; Please see Figure 6 The illustration shown is a schematic diagram of an image decompression system provided by an embodiment of this application; as shown Figure 6 As shown in Case 2, the image block size produced by Master 0 is 16×16 pixels, which matches the size required by the compression unit. The image block size required by Master 1 is 8×8 pixels, which does not match the 16×16 pixels output by the decompression unit. Therefore, an image decompression system (which includes a decompression end block adapter) is used only on the read path, and no image compression system is used on the compression path; only one compression unit, FBC, is needed.

[0080] Application scenarios that utilize only an image decompression system may include: the image data output by the camera module already meets the block size requirements of the compression unit and can be directly compressed and stored; however, the subsequent image recognition module needs to process the data in small blocks. In this case, the decompression end block adapter in the image decompression system breaks down large blocks into smaller blocks and provides them to the recognition module to match its processing granularity.

[0081] Implementation Case 3: Simultaneous use of an image compression system and an image decompression system; Please see Figure 7 The illustration shown is a schematic diagram of an embodiment of this application that simultaneously employs an image compression system and an image decompression system; as shown Figure 7As shown in Case 3, the image block size generated by Master 0 is 8×8 pixels, while the compression unit requires a size of 16×16 pixels; meanwhile, the image block size required by Master 1 is 8×8 pixels, while the output size of the decompression unit is 16×16 pixels. Since the two ends are mismatched, the write path uses an image compression system (including a compression end block adapter), and the read path uses an image decompression system (including a decompression end block adapter).

[0082] Application scenarios that simultaneously employ image compression and decompression systems can include: image preprocessing modules outputting images in small blocks, while compression units require larger blocks to improve the compression ratio; and in subsequent multiple consumption modules, some require small blocks, while others require large blocks. In this case, the compression block adapter is responsible for combining small blocks into large blocks, and the decompression block adapter splits large blocks into smaller blocks according to downstream requirements, enabling a single compression and decompression hardware system to serve multiple input / output granularities.

[0083] Implementation Case 4: Multiple Masters (first devices) share the same image compression system; Please see Figure 8 The diagram shown illustrates multiple devices sharing the same image compression system according to an embodiment of this application; as follows: Figure 8 As shown in Case 4, the image block size generated by Master 0 and Master 1 is 8×8 pixels, which does not match the 16×16 pixels required by the compression unit. The image block size required by Master 2 and Master 3 is 16×16 pixels, which matches the output size of the decompression unit. Therefore, only one image compression system (including a compression end block adapter) is used in the write path, and the compression end block adapter in this system serves both Master 0 and Master 1.

[0084] Application scenarios where multiple Masters (first devices) share the same image compression system can include: two different image acquisition modules both output small blocks of data, and they share the same compression system for data writing. The compression end block adapter in the image compression system needs to handle alternating write requests from the two Masters, merging their respective small blocks into a larger block before sending it to the compression unit. The decompression path does not require an image decompression system, as the downstream module directly receives the large data block.

[0085] Implementation Case 5: Multiple Masters (Second Devices) Sharing the Same Image Decompression System; Please see Figure 9 The diagram shown illustrates multiple devices sharing the same image decompression system according to an embodiment of this application; as shown Figure 9As shown in Case 5, the image block size produced by Master 0 and Master 1 is 16×16 pixels, which matches the size of the compression unit. The image block size required by Master 2 and Master 3 is 8×8 pixels, which does not match the 16×16 pixels output by the decompression unit. Therefore, only one image decompression system (including a decompression end block adapter) is used in the read path, and the decompression end block adapter in this system serves both Master 2 and Master 3.

[0086] Application scenarios where multiple devices share the same image decompression system can include situations where multiple display or processing modules need to read the same frame of image data, but each requires data blocks of different granularities. The decompression block adapter in the image decompression system breaks down the large decompressed block into smaller blocks and returns the required small blocks of data according to the read commands from each Master, thus enabling a single compressed data set to serve multiple devices with different needs.

[0087] Implementation Case 6: Multiple Masters (first device and second device) simultaneously share an image compression system and an image decompression system; Please see Figure 10 The diagram shown illustrates a shared image compression system and image decompression system provided in an embodiment of this application; as follows: Figure 10 As shown in Case 6, the image block size generated by Master 0 and Master 1 is 8×8 pixels, which does not match the 16×16 pixels required by the compression unit; the image block size required by Master 2 and Master 3 is also 8×8 pixels, which does not match the 16×16 pixels output by the decompression unit. Therefore, the write path uses an image compression system (including a compression end block adapter), and the read path uses an image decompression system (including a decompression end block adapter), with the adapters in the two systems serving their respective multiple Masters.

[0088] Application scenarios where multiple devices share an image compression and decompression system can include: in a complex heterogeneous computing system, multiple image sources generate small data blocks, and multiple consumer modules also require small data blocks. By employing both an image compression and decompression system simultaneously, all Masters share the same set of frame buffer compression and decompression hardware, eliminating the need to design a separate compression system for each Master.

[0089] This application also provides an image processing method that can be applied to the aforementioned image compression system and / or image decompression system. The image processing method may include: Step S110: If the size of the first image block generated by the first device does not meet the size requirements of the image block received by the image compression unit, the first image block is received by the compression end block adapter, and the first image block is converted into a second image block that meets the image block size requirements of the image compression unit. The second image block is then compressed by the image compression unit.

[0090] And / or, step S120: if the size of the third image block output by the image decompression unit does not meet the image block size requirements of the second device, then the third image block is converted into a fourth image block that meets the image block size requirements of the second device using the decompression end block adapter, and the fourth image block is output to the second device.

[0091] Step S110 is applied to the image compression system described above. In step S110, when the size of the first image block generated by the first device is inconsistent with the input block size required by the image compression unit, the compression end block adapter is activated. This adapter receives the first image block, temporarily stores the pixel data in the original order through its internal data buffer unit, and then the data reordering unit rereads and arranges the pixels from the buffer according to the fixed block size and pixel arrangement rules required by the image compression unit to generate a second image block. Subsequently, the image compression unit performs lossless or lossy compression on the second image block, generating a compressed bitstream and storing it in memory. If the size of the first image block already meets the requirements, the compression end block adapter can be bypassed, and the first image block is directly sent to the image compression unit without conversion.

[0092] Step S120 is applied to the aforementioned image decompression system. When the fixed size of the third image block output by the image decompression unit is inconsistent with the size of the fourth image block required by the second device, the decompression end block adapter is activated. This adapter receives and parses the read command issued by the second device through the command adaptation unit, determining whether to merge or split the command based on the requested block size. Simultaneously, it performs corresponding splitting or merging processing on the third image block through the data adaptation unit, generating a fourth image block that meets the requirements of the second device, and outputs it through the second device interface. If the size of the third image block already meets the requirements of the second device, the decompression end block adapter can be bypassed, and the third image block is directly output to the second device.

[0093] The use of "and / or" to connect steps S110 and S120 indicates that the image processing in this embodiment can perform only step S110 on the compression side (suitable for scenarios where only compression is needed and decompression is not required), only step S120 on the decompression side (suitable for scenarios where only reading of compressed data is needed), or both steps S110 and S120 can be performed simultaneously (suitable for complete data processing scenarios requiring simultaneous compression writing and decompression reading). This flexible configuration allows the method to adapt to the compression and decompression resource requirements of different chip designs, enabling the deployment of either the compression side or the decompression side separately, or both sides to be deployed completely.

[0094] In the implementation of the above embodiments: when the image block size generated by the first device does not match the size of the compression unit, the compression block adapter converts it into a second image block that meets the requirements, enabling the first device to use the compression unit for compression normally. When the image block size required by the second device does not match the size output by the decompression unit, the decompression block adapter converts it into a fourth image block, enabling the second device to directly obtain data of the required size. The first and second devices with different size requirements can share the same set of compression and decompression hardware, without the need to configure a separate conversion circuit for each device.

[0095] Optionally, in this embodiment, the compression block adapter includes a data buffer unit and a data reordering unit; receiving a first image block using the compression block adapter and converting the first image block into a second image block that meets the image block size requirements of the image compression unit includes: The system receives a first image block and caches it in a data cache unit. The data reordering unit processes the first image block according to the size requirements of the image compression unit, and outputs one or more second image blocks that meet the size requirements.

[0096] The data cache unit can be composed of on-chip static random access memory (SRAM) or a register array, used to cache the first image block received from the first device interface. It is understood that the cache can store data in the original order of the first image block, for example, using a zigzag scanning order.

[0097] The data caching unit is configured to cache at least one complete first image block. When the size of the first image block is smaller than the compressed block, multiple first image blocks may need to be cached to combine into a complete second image block; when the size of the first image block is larger than the compressed block, a portion of the data from the first image block needs to be cached to split it into multiple second image blocks. The caching unit manages the storage and retrieval of data through write pointers and read pointers.

[0098] The data reordering unit reads a first image block from the data buffer unit according to the size requirements of the image compression unit, which is the fixed compression block size required by the image compression unit. It then rearranges the output order of the pixels and outputs one or more second image blocks that meet the size requirements. See the foregoing for a detailed example.

[0099] In the implementation process of the above embodiments: the first image block is first cached in the data cache unit, and then processed by the data reordering unit according to the size requirements of the image compression unit to output one or more second image blocks that meet the requirements. Regardless of the scanning order or image block size used by the first device, the input requirements of the image compression unit can be met after processing by the compression end block adapter.

[0100] Optionally, in this embodiment, the decompression end-block adapter includes a command adaptation unit and a data adaptation unit; using the decompression end-block adapter to convert the third image block into a fourth image block that meets the image block size requirements of the second device includes: The command adaptation unit receives and parses the read command issued by the second device. The read command requests a fourth image block that meets the image block size requirements of the second device. When the second device needs to read image data, it issues a read command to the bus. This command contains information such as the requested address and the image block size requirements. The command adaptation unit receives this command through the read address channel of the AXI bus and parses out the image block size required by the second device.

[0101] If the command adaptation unit determines that the size of the third image block does not meet the image block size requirements of the second device, it processes the read command; this processing includes command merging or command splitting. The command adaptation unit compares the parsed image block size required by the second device with the fixed size of the third image block output by the image decompression unit. If the two are inconsistent, the read command needs to be processed.

[0102] There are two methods for processing read commands: command merging and command splitting. Command merging is suitable when the image block size required by the second device is smaller than the image block size of the third device. Command splitting is suitable when the image block size required by the second device is larger than the image block size of the third device.

[0103] The data adaptation unit then processes the third image block according to the command processing results. The processing procedure is as follows: If the command adaptation unit performs command merging processing on the read command, then the data adaptation unit performs image splitting processing on the third image block to generate the fourth image block; if the command adaptation unit performs command splitting processing on the read command, then the data adaptation unit performs image merging processing on the third image block to generate the fourth image block.

[0104] In the implementation of the above embodiments: firstly, the command adaptation unit merges or splits the read commands of the second device, and then the data adaptation unit performs the reverse splitting or merging process on the third image block. The image decompression unit outputs data according to its fixed block size. When the size of the fourth image block required by the second device is the same as the size of the third image block, it does not need to perform format conversion locally. This method of command and data collaborative processing reduces the additional resource consumption caused by size mismatch.

[0105] Optionally, in this embodiment, the image compression unit and the image decompression unit are frame buffer compression units and frame buffer decompression units within the same bus arbitration domain. Multiple different devices share the same frame buffer compression unit for data writing through a compression end block adapter, and multiple different devices share the same frame buffer decompression unit for data reading through a decompression end block adapter.

[0106] In actual chip design, multiple first and second devices (Masters) are connected to memory and peripherals via a system bus. A bus arbitration domain refers to the range of bus access managed by the same bus arbitrator. In this embodiment, the image compression unit (i.e., the frame buffer compression unit FBC) and the image decompression unit (i.e., the frame buffer decompression unit FBDC) are placed within the same bus arbitration domain. This way, all first devices that need to write image data and second devices that need to read image data are connected to the FBC and FBDC through the same bus structure, and access requests are uniformly scheduled by the same arbitrator. The advantage of this design is that the FBC and FBDC become shared public resources for all devices within the arbitration domain, enabling interconnection and stream sharing between Masters.

[0107] When multiple first devices need to write image data to memory, the size of their respective image blocks may not match the fixed compressed block size required by the FBC. The data from each first device is first buffered and reordered by the compression end block adapter, converted into second image blocks that meet the FBC size requirements, and then sent to the FBC for compression. Since the compression end block adapter handles the size adaptation, the FBC only needs to receive data according to its own fixed block size. Therefore, multiple first devices can share the same FBC sequentially, without needing to configure a separate compression unit for each device.

[0108] Similarly, when multiple second devices (such as multiple display output interfaces or multiple recognition processing modules) need to read image data from memory, the size of the image blocks they require may not match the fixed size output by the FBDC. The FBDC first outputs a fixed-size third image block, and then the decompression end block adapter splits or merges the third image block into a fourth image block required by each device according to the read command of each second device. In this way, multiple second devices can share the same FBDC.

[0109] Within the same bus arbitration domain, a bus arbitrator arbitrates bus access requests from multiple devices.

[0110] When multiple first devices need to write data simultaneously, or multiple second devices need to read data simultaneously, the bus arbiter is responsible for determining which device currently has the right to use the bus, according to a preset priority or round-robin algorithm. For example, when first device A and first device B simultaneously send image blocks to the compressed block adapter, the arbiter will select one device to transmit data through the bus first, while the other device needs to wait. In hardware implementation, the bus arbiter is usually located inside FAB_AXI, monitoring the request signals of each master device and returning authorization signals. Through the arbitration mechanism, multiple devices can share the same set of FBC and FBDC in an orderly manner, reducing bus conflicts and data corruption. At the same time, the compressed block adapter and decompressed block adapter also need to cooperate with the arbiter to transmit data or respond to commands only after obtaining bus authorization.

[0111] For example, regarding the frame buffer compression unit, please refer to [link / reference]. Figure 11 The diagram shown is a basic architecture diagram provided by an embodiment of this application.

[0112] Figure 11 The system comprises multiple devices, Master0 and Master1, which are connected to the AXI bus interconnect matrix (FAB_AXI) via an AXI bus arbiter (AXI_ARB). The bus matrix connects to the Frame Buffer Compression Unit (FBC) and the Frame Buffer Decompression Unit (FBDC), which in turn are connected to external memory (DDR). Block adapters (block_adapter0 and block_adapter1) are located at the front end of the FBC and the back end of the FBDC, respectively. When Master0 and Master1 write data, the data is first converted to the required size by the compression end block adapter, then compressed by the FBC before being stored in DDR. When reading data, the FBDC decompresses fixed-size data from DDR, converts it to the size required by each Master via the decompression end block adapter, and then returns it. The entire system uses AXI_ARB to arbitrate bus access requests from multiple Masters.

[0113] In the implementation of the above embodiments: by setting the image compression unit and the image decompression unit within the same bus arbitration domain and scheduling them uniformly by the bus arbitrator, the chip only needs to be equipped with one set of compression unit and one set of decompression unit to serve multiple devices, eliminating the need for a separate compression and decompression hardware for each device. This reduces the chip's hardware cost and chip area. The bus arbitrator also makes the entire system's data writing and reading process smoother.

[0114] Please see Figure 12 The diagram shows a structural schematic of an electronic device provided in an embodiment of this application. An electronic device 300 provided in this application includes a processor 310 and a memory 320. The memory 320 stores machine-readable instructions executable by the processor 310. When the machine-readable instructions are executed by the processor 310, the method described above is performed.

[0115] Figure 12 The components shown can be implemented using hardware, software, or a combination thereof. Electronic device 300 may be a physical device, such as a server or PC, or a virtual device, such as a virtual machine or virtualization container. Furthermore, electronic device 300 is not limited to a single device; it can be a combination of multiple devices or a cluster of numerous devices.

[0116] It should be understood that the disclosed apparatus and methods can also be implemented in other ways, as provided in the embodiments of this application. The apparatus embodiments described above are merely illustrative. For example, the flowcharts and block diagrams in the accompanying drawings show the architecture, functions, and operations that may be implemented according to various embodiments of this application. In this regard, each block in a flowchart or block diagram may represent a module, segment, or part of code, which contains one or more executable instructions for implementing a specified logical function. It should also be noted that in some alternative implementations, the functions marked in the blocks may occur in a different order than those marked in the drawings. For example, two consecutive blocks may actually be executed substantially in parallel, or they may sometimes be executed in reverse order, depending on the functions involved. It should also be noted that each block in a block diagram and / or flowchart, and combinations of blocks in block diagrams and / or flowcharts, can be implemented using a dedicated hardware-based system that performs the specified function or action, or using a combination of dedicated hardware and computer instructions.

[0117] In addition, the functional modules in the various embodiments of this application can be integrated together to form an independent part, or each module can exist independently, or two or more modules can be integrated to form an independent part.

[0118] The above description is only an optional implementation of the embodiments of this application, but the protection scope of the embodiments of this application is not limited thereto. Any changes or substitutions that can be easily conceived by those skilled in the art within the technical scope disclosed in the embodiments of this application should be covered within the protection scope of the embodiments of this application.

Claims

1. An image compression system, characterized in that, include: At least one first device interface for receiving a first image block from the first device; A compression block adapter is used to receive the first image block when the size of the first image block does not meet the size requirements of the image block received by the image compression unit, and to convert the first image block into a second image block that meets the size requirements of the image block of the image compression unit; the compression block adapter is coupled to the first device interface; An image compression unit is used to receive the second image block and perform compression processing to generate a compressed bitstream; The image compression unit is coupled to the compression block adapter.

2. The image compression system according to claim 1, characterized in that, The compressed end block adapter includes: a data caching unit and a data reordering unit; The data caching unit is used to receive and cache the first image block; The data reordering unit is used to process the first image block according to the size requirements of the image compression unit, and output one or more second image blocks that meet the size requirements; The image compression system further includes a memory interface for writing the compressed bitstream into memory; the memory interface is coupled to the image compression unit.

3. An image decompression system, characterized in that, include: The image decompression unit is used to decompress the compressed bitstream and output a third image block; A decompression end-block adapter is used to convert the third image block output by the image decompression unit into a fourth image block that meets the image block size requirements of the second device when the size of the third image block does not meet the requirements of the second device; the decompression end-block adapter is coupled to the image decompression unit; At least one second device interface is provided for outputting the fourth image block that meets the image block size requirements to the second device; the second device interface is coupled to the decompression end block adapter.

4. The image decompression system according to claim 3, characterized in that, The decompression end block adapter includes a command adaptation unit and a data adaptation unit; the command adaptation unit and the data adaptation unit each include a port coupled to the AXI bus channel; The command adaptation unit is configured to receive and parse a read command issued by the second device, the read command being used to request a fourth image block that meets the image block size requirements of the second device; and, if it is determined that the size of the third image block does not meet the image block size requirements of the second device, to process the read command; the processing includes command merging processing or command splitting processing; The data adaptation unit is used to process the data of the third image block according to the processing of the read command by the command adaptation unit, and generate a fourth image block that meets the image block size requirements of the second device; the data processing includes image merging processing or image splitting processing of the third image block.

5. The image decompression system according to claim 4, characterized in that, The command adaptation unit and the data adaptation unit are configured such that: if the command adaptation unit performs command merging processing on the read command, the data adaptation unit performs image splitting processing on the third image block to generate the fourth image block; If the command adaptation unit performs command splitting processing on the read command, then the data adaptation unit performs image merging processing on the third image block to generate the fourth image block.

6. An image processing method, characterized in that, include: If the size of the first image block generated by the first device does not meet the size requirement of the image block received by the image compression unit, the first image block is received by the compression end block adapter and converted into a second image block that meets the image block size requirement of the image compression unit. The second image block is then compressed by the image compression unit. And / or, if the size of the third image block output by the image decompression unit does not meet the image block size requirements of the second device, the third image block is converted into a fourth image block that meets the image block size requirements of the second device using the decompression end block adapter, and the fourth image block is output to the second device.

7. The method according to claim 6, characterized in that, The compression block adapter includes a data buffer unit and a data reordering unit; it receives the first image block using the compression block adapter and converts the first image block into a second image block that meets the image block size requirements of the image compression unit, including: Receive the first image block and cache the first image block in the data cache unit; The data reordering unit processes the first image block according to the size requirements of the image compression unit, and outputs one or more second image blocks that meet the size requirements.

8. The method according to claim 6, characterized in that, The decompression end-block adapter includes a command adaptation unit and a data adaptation unit; using the decompression end-block adapter, the third image block is converted into a fourth image block that meets the image block size requirements of the second device, including: The command adaptation unit receives and parses the read command issued by the second device, which is used to request a fourth image block that meets the image block size requirements of the second device. If the command adaptation unit determines that the size of the third image block does not meet the image block size requirements of the second device, it processes the read command; the processing includes command merging or command splitting. If the command adaptation unit performs command merging processing on the read command, then the data adaptation unit performs image splitting processing on the third image block to generate the fourth image block; If the command adaptation unit performs command splitting processing on the read command, then the data adaptation unit performs image merging processing on the third image block to generate the fourth image block.

9. The method according to claim 6, characterized in that, The image compression unit and the image decompression unit are frame buffer compression units and frame buffer decompression units within the same bus arbitration domain; Multiple different devices share the same frame buffer compression unit through the compression end block adapter to write data, and multiple different devices share the same frame buffer decompression unit through the decompression end block adapter to read data; The same bus arbitration domain arbitrates bus access requests from multiple devices through a bus arbitrator.

10. An electronic device, characterized in that, include: A processor and a memory, the memory storing computer program instructions that, when executed by the processor, perform the method as described in any one of claims 6 to 9.

Images