Apparatus, methods, programs, and devices for a framework for GPU-driven data loading.

Abstract

A method for data loading in a computing device is provided. The method includes identifying, in a graphics processing unit (GPU), data to load based on execution of an application program. The method also includes loading, via the GPU, data chunks of the identified data in encoded form from a data storage device into a video memory associated with the GPU. The method further includes decoding the data in parallel by using multiple GPU thread groups in parallel to decode the data chunks, each of the data chunks being decoded independently of other data chunks.

Description

Technical Field

[0001] Cross - Reference to Related Applications This application claims the benefit of priority of U.S. Patent Application No. 18 / 085,367, filed on December 20, 2o22, the entire content of which is incorporated herein by reference.

[0002] This disclosure generally relates to a Graphics Processing Unit (GPU) that includes one or more techniques for loading data in a computing device.

Background Art

[0003] Computing devices often utilize a Graphics Processing Unit (GPU) in combination with a Central Processing Unit (CPU) to render display - ready graphic data or to perform non - graphic - related functions that utilize the massive parallelism of processing provided by the GPU. Such computing devices may include, for example, computer workstations, mobile phones such as smartphones, embedded systems, personal computers, tablet computers, and video game consoles. The GPU processes instructions and / or data within a processing pipeline that includes one or more processing stages that operate together to execute processing commands for both graphical - related and non - graphical - related functions. The CPU may control the operation of the GPU by issuing one or more processing commands to the GPU. Modern CPUs are typically capable of executing multiple applications simultaneously, each of which may need to utilize the GPU during execution.

[0004] While GPUs were initially intended to improve graphics rendering, their parallel computing capabilities have proven beneficial for accelerating a wide range of processing applications. The ability to perform separate tasks concurrently, along with the modular architecture of modern GPUs, means there are likely many ways in which solutions can be designed for any graphics or non-graphics need. This has improved GPU capabilities by making them more adaptable and programmable for purposes beyond rendering. Today, GPU parallel computing is used in a wide variety of applications.

[0005] Architecturally, a CPU consists of one or more cores with cache memory capable of processing several software threads at once. This makes CPUs suitable for sequential processing because they can perform a series of operations quickly in one go. In contrast, a GPU may contain hundreds of cores, which can potentially process thousands of threads simultaneously. This makes GPUs suitable for parallel processing because they can process thousands of operations at once. The hundreds of cores in a GPU are low-power and better suited for performing simple simultaneous calculations such as arithmetic. Therefore, GPU parallel computing allows GPUs to break down complex problems into thousands or millions of separate tasks and process them all at once rather than one by one like a CPU. This also makes GPUs more powerful than CPUs because they have more cores, more computing power, and therefore a greater potential for parallelism in computation. [Overview of the project] [Problems that the invention aims to solve]

[0006] Typically, the GPU waits for the CPU to load data from storage, decode the data, and transfer the decoded data to video memory for the GPU to process. However, as the complexity of the content being rendered increases and the constraints of CPU performance grow, the need to improve graphics processing or computer processing is increasing.

[0007] Below, a simplified overview of one or more embodiments is presented to provide a basic understanding of such embodiments. This overview is not a comprehensive overview of all possible embodiments, nor is it intended to identify the essential elements of all embodiments or to describe the scope of any or all embodiments. Its sole purpose is to present some concepts of one or more embodiments in a simplified form as a prelude to the more detailed explanations that will follow. [Means for solving the problem]

[0008] This disclosure relates to methods and apparatus for data loading in computing devices. One aspect of the subject matter described herein is implemented in a method for loading data in a computing device. The method includes the step of identifying data to be loaded on a GPU based on the execution of an application program. The method also includes the step of loading data chunks of the identified data in an encoded form from a data storage device into video memory associated with the GPU via the GPU. The method further includes the step of decoding the data chunks in parallel by using multiple GPU thread groups in parallel to decode the data chunks. Each data chunk is decoded independently of the other data chunks.

[0009] Further aspects of the subject matter described herein can be implemented in a device for data loading in a computing device. The device includes a graphics processing unit (GPU) configured to identify data to be loaded based on the execution of an application program. The GPU is also configured to load data chunks of the identified data in an encoded form from a data storage device into video memory associated with the GPU. The GPU is further configured to decode data chunks in parallel by using multiple groups of GPU threads in parallel to decode the data chunks. Each data chunk is decoded independently of the other data chunks.

[0010] Further aspects of the subject matter described herein can be implemented in a non-temporary computer-readable storage medium that stores instructions causing a processor to identify data to be loaded into a graphics processing unit (GPU) based on the execution of an application program, when executed by at least one processor. The processor is also configured to load data chunks of the identified data in an encoded form from a data storage device into video memory associated with the GPU via the GPU. The processor is further configured to decode the data chunks in parallel by using multiple GPU thread groups in parallel to decode the data chunks. Each data chunk is decoded independently of the other data chunks.

[0011] Further embodiments of the subject matter described herein can be implemented in a device. The device includes a controller configured to identify data to load based on the execution of an application program. The controller is also configured to load data chunks of the identified data in an encoded form from a data storage device into video memory associated with the GPU. The controller is further configured to decode the data chunks in parallel by using multiple GPU thread groups in parallel to decode the data chunks. Each data chunk is decoded independently of the other data chunks.

[0012] To achieve the aforementioned and related objectives, one or more embodiments include features that are fully described below and specifically pointed out in the claims. The following description and accompanying drawings illustrate in detail some exemplary features of one or more embodiments. However, these features represent only a small fraction of the various ways in which the principles of various embodiments may be employed, and this description is intended to include all such embodiments and their equivalents.

[0013] Details of one or more aspects of the subject matter described herein are given in the accompanying drawings and the following description. However, the accompanying drawings only illustrate some typical aspects of the disclosure and should therefore not be considered limiting. Other features, aspects, and advantages will become apparent from the description, drawings, and claims. [Brief explanation of the drawing]

[0014] [Figure 1A] This is a block diagram illustrating an example of a data loading system using one or more of the technologies of this disclosure. [Figure 1B] This is a block diagram illustrating an example of a data loading system using one or more of the technologies of this disclosure. [Figure 2A]This is a diagram illustrating an example of a data loading pipeline handled by multiple processors. [Figure 2B] This is a diagram illustrating an example of a GPU-driven rendering pipeline. [Figure 3] This diagram shows an example of a data loading pipeline handled by a GPU using one or more of the technologies of this disclosure. [Figure 4] This is a flowchart illustrating an example method of data loading in a computing device using one or more of the technologies of this disclosure. [Modes for carrying out the invention]

[0015] Similar reference numbers and symbols in various drawings indicate the same elements.

[0016] The following description covers several exemplary embodiments for the purpose of illustrating the innovative aspects of this disclosure. However, those skilled in the art will readily recognize that the teachings herein can be applied in numerous different ways.

[0017] The relevant system has a framework for loading data using multiple processors. As a first issue, the data can be any block of data consumed by the runtime process. For example, the data could be video data, mesh data, texture data, machine learning training data, text data, etc. In other words, the data can be any type of data that can benefit from parallel processing. In the relevant system, the GPU may load data from storage and ask the CPU to decode the data into a form that the GPU can consume before the decoded or decompressed data can be transferred to video memory for GPU use. However, this process creates a CPU bottleneck that slows down the process due to the exchange between the GPU and the CPU. Furthermore, the CPU bottleneck is exacerbated in mobile devices because the CPU consumes a considerable amount of processing power.

[0018] In the relevant GPU-driven rendering pipeline, the GPU receives the data necessary for rendering by loading video data from storage and requesting the CPU to decode the video data. However, this process can stall the GPU pipeline and slow down rendering. Many related systems have data loading frameworks used to render graphics. Typically, compressed data is loaded into system memory and decompressed by the CPU before being sent to the GPU, which increases loading time.

[0019] As an example, the first related system may load files into memory with or without decoding. As another example, in the second related system, video data must be compressed by the Kraken algorithm, which provides a special API for loading the data. However, a dedicated chip must be used to decode the video data from the Kraken algorithm into GPU-consumable content. As yet another example, in the third related system, only asynchronous loading is available, and there is no encoding or decoding part. The third related system may also have a new API for mapping storage devices to memory, which would require changes to the drive and OS and would not be practical in mobile devices.

[0020] Another fourth related system may include fast resource loading for streaming data into textures using an asynchronous input / output (I / O) application programming interface (API) and buffering directly from a storage device. Yet another fifth related system may transfer data between a GPU and other devices within a data center. However, both the fourth related system and the fifth related system cannot operate on multiple platforms and multiple hardware. Further, the related systems described above generally have one fixed decompression algorithm or no decompression algorithm at all. This means that the associated framework cannot reduce bandwidth by customizing the decompression algorithm for different scenarios or by adopting different decoding for different types of data. In real-world applications, different scenarios may have their best-suited compression techniques.

[0021] Aspects of the present disclosure utilize a cross-platform GPU-driven data loading framework that can be used on desktops, mobiles, consoles, servers, etc. Further, to implement the disclosed techniques, no new operating system (OS), new application programming interface (API), or new hardware needs to be modified or used. The framework typically offloads processes typically performed by a CPU to be performed on a GPU, bypassing the CPU bottleneck to reduce power consumption and improve performance. Data may also be kept in a compressed form until ready to be consumed by the GPU, which also reduces the bandwidth when transferring data and further reduces power consumption.

[0022] Aspects of the present disclosure utilize an adaptable framework so as not to focus on a specific algorithm. Instead, the GPU-driven data loading framework provides the adaptability to customize the encoding algorithm / decoding algorithm according to different scenarios. Thereby, developers can create a WARP-based parallel construction block using a customized decoding algorithm instead of starting from scratch. Different from the related GPU programs operating within a block, these WARP-based construction blocks for a compression algorithm or a decompression algorithm are optimized to operate within a WARP to modify sequential compression or sequential decompression so that those algorithms can be used in parallel by the GPU.

[0023] Various aspects of a system, an apparatus, a computer program product, and a method are described more fully hereinafter with reference to the accompanying drawings. However, the present disclosure may be embodied in many different forms and should not be construed as limited to the specific structures or specific functions presented throughout this disclosure. Rather, these aspects are provided so that this disclosure will be thorough and complete, and will fully convey the scope of the disclosure to those skilled in the art. Based on the teachings herein, those skilled in the art should understand that the scope of the present disclosure is intended to cover any aspect of the systems, apparatuses, computer program products, and methods disclosed herein, whether implemented independently of or in combination with other aspects of the present disclosure. For example, an apparatus may be implemented or a method may be performed using any number of the aspects described herein. Further, the scope of the present disclosure is intended to cover such apparatuses or methods implemented using other structures, functions, or in addition to or other than the various aspects of the present disclosure described herein. Any aspect disclosed herein may be embodied by one or more elements of a claim.

[0024] While various embodiments are described herein, many variations and substitutions of these embodiments fall within the scope of this disclosure. Although some potential benefits and advantages of embodiments of this disclosure are mentioned, the scope of this disclosure is not intended to be limited to any particular benefit, use, or purpose. Rather, embodiments of this disclosure are intended to be broadly applicable to different wireless technologies, system configurations, networks, and transmission protocols, some of which are illustrated in the drawings and the following description. The detailed description and drawings are merely illustrative and not limiting of this disclosure, and the scope of this disclosure is defined by the appended claims and their equivalents.

[0025] Several embodiments are presented with reference to various devices and methods. These devices and methods are described in the following detailed description and are illustrated in the accompanying drawings by various blocks, components, circuits, processes, algorithms, etc. (collectively referred to as “elements”). These elements may be implemented using electronic hardware, computer software, or any combination thereof. Whether such elements are implemented as hardware or software depends on the specific application and the design constraints imposed on the overall system.

[0026] For example, an element, or any part of an element, or any combination of elements, may be implemented as a “processing system” including one or more processors (which may be called processing circuits). One or more processors in a processing system may execute software. Software can be broadly interpreted to mean instructions, instruction sets, code, code segments, program code, programs, subprograms, software components, applications, software applications, software packages, routines, subroutines, objects, executable files, threads of execution, procedures, functions, etc., whether they are called software, firmware, middleware, microcode, hardware description language, or otherwise. The term application may refer to software. One or more techniques as described herein may refer to an application, i.e., software, configured to perform one or more functions. In such examples, the application may be stored in memory, e.g., on-chip memory of a processor, system memory, or any other memory. Hardware described herein, such as processors, may be configured to execute applications. For example, an application may be described as containing code that, when executed by the hardware, causes the hardware to perform one or more techniques described herein. For example, hardware may access code from memory and execute the code accessed from memory to perform one or more of the techniques described herein. In some examples, components are identified in this disclosure. In such examples, components may be hardware, software, or a combination thereof. Components may be separate components or subcomponents of a single component.

[0027] Accordingly, in one or more examples described herein, the described functions may be implemented in hardware, software, or any combination thereof. If implemented in software, the functions may be stored or encoded as one or more instructions or codes on a computer-readable medium. The computer-readable medium includes computer storage media. The storage medium may be any available medium that can be accessed by a computer. Such computer-readable media may include, but are not limited to, random access memory (RAM), read-only memory (ROM), electrically erasable programmable ROM (EEPROM), optical disk storage devices, magnetic disk storage devices, other magnetic storage devices, combinations of the computer-readable media of the aforementioned types, or any other medium that can be used to store computer executable code in the form of instructions or data structures that can be accessed by a computer.

[0028] Firstly, it should be noted that the term “GPU” as used herein does not necessarily refer to a processing unit used solely for graphics processing. On the contrary, the GPUs described herein are parallel processing accelerators. While CPUs typically consist of several cores optimized for a series of sequential processes, GPUs typically have a large-scale parallel architecture that can include thousands of smaller, more efficient computing cores designed to handle multiple tasks simultaneously. This makes GPUs usable for many purposes beyond graphics, including accelerating high-performance computing, deep learning and artificial intelligence, analytics, and other processing applications.

[0029] Parallel architectures also make GPUs ideal for deep learning and neural networks because they perform a large number of simultaneous computations, thereby reducing the time it takes to train neural networks using traditional CPU techniques from days to hours. As described herein, each GPU may be used for any advanced processing task, and is particularly useful for complex tasks that benefit from large-scale parallel processing.

[0030] This disclosure includes techniques for data loading in computing devices by utilizing a framework to load GPU-driven data with minimal CPU involvement. Aspects of this disclosure offload loader and decoder processes, typically performed sequentially by the CPU, to be performed in parallel by the GPU. This framework allows the GPU to directly load data from storage into video memory and decode it on the GPU. In addition, the data is held in a compressed form until consumed by the GPU, reducing bandwidth for transfer and further reducing power consumption. The encoding and decoding algorithms may also be customizable without requiring modification of existing operating systems (OS), APIs, or hardware. Because the CPU is bypassed, the disclosed data loading framework requires less power consumption and provides faster processing. The benefits of other examples are described throughout this disclosure.

[0031] As used herein, the term “content” may mean “graphic content” and “image,” and vice versa, regardless of whether those terms are used as adjectives, nouns, or other parts of speech. In some instances, as used herein, the term “graphic content” may refer to content produced by one or more processes in a graphics processing pipeline. In some instances, as used herein, the term “graphic content” may refer to content produced by a processing unit configured to perform graphics processing. In some instances, as used herein, the term “graphic content” may refer to content produced by a graphics processing unit.

[0032] As used herein, the term “display content” may refer to content generated by a processing unit configured to perform display processing. In some examples, as used herein, the term “display content” may refer to content generated by a display processing unit. Graphic content may be processed to become display content. For example, a graphics processing unit may output graphic content, such as frames, to a buffer (sometimes called a frame buffer). A display processing unit may read one or more pieces of graphic content, such as frames, from the buffer and perform one or more display processing techniques to generate display content. For example, a display processing unit may be configured to composite one or more rendered layers to generate a frame. In other examples, a display processing unit may be configured to combine, merge, or otherwise combine two or more layers into a single frame. A display processing unit may be configured to scale frames, for example, upscaling or downscaling. In some examples, a frame may refer to a layer. In other examples, a frame may refer to two or more layers that have already been merged together to form a frame, i.e., a frame contains two or more layers, and a frame containing two or more layers may then be merged.

[0033] The relevant systems load data in computing devices that utilize processes performed by both the CPU and GPU. The CPU first loads data from disk or storage, decodes it, optionally decompresses the loaded data into a format that the GPU can consume, and then sends the decoded or decompressed data to GPU memory. However, in mobile devices, the CPU consumes a considerable amount of power, and this can slow things down due to CPU processing bottlenecks. If the entire loading process can be performed directly by the GPU with minimal CPU involvement, the processing pipeline is much faster and requires less power consumption.

[0034] Accordingly, embodiments of this disclosure include methods for data loading in computing devices and apparatus for implementing a framework for data loading in computing devices. While rendering video data for visual representation is used as an example, it should be noted that embodiments of this disclosure can be applied to loading any data used by a computing device in a runtime process and which can benefit from parallel processing. This framework allows a GPU to load data from storage into video memory and decode the data with minimal CPU involvement. The subject matter described herein can be implemented to achieve one or more benefits or advantages. For example, by shifting traditional roles performed by the CPU, such as loading and decoding to the GPU, embodiments can enable maximizing performance, minimizing bandwidth, and reducing power consumption. In addition, embodiments may be implemented without modifying existing operating systems, APIs, or hardware. The framework also utilizes common compression and decompression algorithms so that the framework may employ different decoding for different types of data.

[0035] Figure 1A is a block diagram showing an example of a data loading system 100 configured to implement one or more of the technologies of the present disclosure. The data loading system 100 includes a CPU 128, a GPU 120, and system memory 124 configured to load data according to exemplary embodiments. The CPU 128 may run a software application 111, an OS 113, and a graphics driver 115. Furthermore, the system memory 124 may include a command stream for rendering primitives, as well as an indirect buffer for storing secondary commands to be executed by the GPU 120. The GPU 120 may include a video memory 121 that may be "onboard" with the GPU 120, including a decider function 123, a loader function 125, and a decoder function 127. As will be explained in more detail in relation to Figure 1B, the components of the data loading system 100 may include, but are not limited to, some devices such as video devices, media players, set-top boxes, mobile phones, and wireless handsets such as so-called smartphones, personal digital assistants (PDAs), desktop computers, laptop computers, game consoles, video conferencing units, and tablet computing devices.

[0036] The CPU 128 may be coupled to one or more GPUs. The GPU 120 may include a processing unit configured to perform graphics-related functions, such as generating and outputting graphics data for presentation on a display, as well as non-graphics-related functions that leverage the parallelism of processing provided by the GPU 120. Since the GPU 120 can provide general-purpose processing capabilities in addition to graphics processing capabilities, the GPU 120 may be called a general-purpose GPU (GP-GPU). Examples of the CPU 128 and GPU 120 include, but are not limited to, digital signal processors (DSPs), general-purpose microprocessors, application-specific integrated circuits (ASICs), field-programmable logic arrays (FPGAs), or other equivalent integrated circuits or discrete logic circuits. In some examples, the GPU 120 may be a microprocessor designed for a specific application, such as providing large-scale parallel processing for processing graphics and for running non-graphics-related applications. Furthermore, although the CPU 128 and GPU 120 are shown as separate components, aspects of this disclosure are not limited thereto and may be implemented, for example, in a common integrated circuit (IC).

[0037] A software application 111 running on the CPU 128 may include one or more graphics rendering instructions that instruct the CPU 128 to render graphics data to a display (not shown in Figure 1A). In some examples, the graphics rendering instructions may include software instructions that conform to a graphics API. To process the graphics rendering instructions, the CPU 128 may issue one or more graphics rendering commands to the GPU 120 (for example, via the graphics driver 115) to cause the GPU 120 to render some or all of the graphics data. In some examples, the graphics data to be rendered may include a list of graphics primitives such as points, lines, triangles, quadrilaterals, and triangle strips.

[0038] The GPU120 may be configured to perform graphics operations for rendering one or more graphics primitives to a display. Therefore, when one of the software applications running on the CPU128 requires graphics processing, the CPU128 may provide graphics commands and graphics data to the GPU120 for rendering to the display. The graphics data may include, for example, drawing commands, state information, primitive information, and texture information. The GPU120 may, in some cases, be built in a highly parallel structure that provides more efficient processing of graphics-related operations that are more complex than those of the CPU128. For example, the GPU120 may include multiple processing elements configured to operate in parallel for multiple vertices or pixels.

[0039] The GPU 120 may process data locally using local storage (i.e., video memory 121) instead of host memory or system memory. This allows the GPU 120 to operate more efficiently by eliminating the need for the GPU 120 to read and write data over a shared bus, which may encounter heavy bus traffic. The video memory 121 may include one or more volatile or non-volatile memories or storage devices, such as random access memory (RAM), static RAM (SRAM), dynamic RAM (DRAM), and one or more registers.

[0040] The video memory 121 may also be used directly by a decider function 123, a loader function 125, and a decoder function 127. The decider function 123 may be configured to identify the data to load based on the execution of an application program. The loader function 125 may be configured to load data chunks of the identified data in encoded form from a data storage device into video memory associated with the GPU (e.g., video memory 121) via the GPU. The decoder function 127 may be configured to decode data chunks in parallel by using multiple GPU thread groups in parallel to decode the data chunks. In some embodiments, the processor performing the functions described above may be a general-purpose processor (e.g., a CPU).

[0041] The CPU 128 and / or GPU 120 may store the rendered image data in a frame buffer 138, which may be in separate memory or allocated within system memory 124. The display processor may retrieve the rendered image data from the frame buffer 138 and display the rendered image data on the display.

[0042] The system memory 124 may be memory within the device, or it may be outside the CPU 128 and GPU 120, that is, it may be off-chip relative to the CPU 128 and off-chip relative to the GPU 120. The system memory 124 may store applications executed by the CPU 128 and GPU 120. Furthermore, the system memory 124 may store data on which the executed applications operate, as well as data generated from the applications.

[0043] System memory 124 may store program modules, instructions, or both accessible for execution by CPU 128, and / or data for use by programs running on CPU 128. For example, system memory 124 may store a window manager application used by CPU 128 to present a graphical user interface (GUI) on the display. Furthermore, system memory 124 may store user applications and application surface data associated with those applications. As described in detail below, system memory 124 may act as device memory for GPU 120 and store data on which GPU 120 should operate as well as data resulting from operations performed by GPU 120. For example, system memory 124 may store any combination of texture buffers, depth buffers, stencil buffers, vertex buffers, frame buffers, etc.

[0044] Examples of system memory 124 include, but are not limited to, random access memory (RAM), read-only memory (ROM), or electrically erasable programmable read-only memory (EEPROM), or any other medium that can be used to carry or store desired program code in the form of instructions or data structures and that can be accessed by a computer or processor. For example, system memory 124 may be removed from the device and moved to another device. For another example, a storage device substantially similar to system memory 124 may be inserted into the device.

[0045] Figure 1B is a detailed block diagram showing an example of a data loading system 100 configured to implement one or more of the technologies of this disclosure. Note that the data loading system 100 shown in Figure 1B may correspond to the data loading system in Figure 1A. In this regard, the data loading system 100 in Figure 1B includes a CPU 128, a GPU 120, and system memory 124.

[0046] As further shown, the data loading system 100 includes a device 104 which may include one or more components configured to perform one or more of the techniques of the present disclosure. In the examples shown, device 104 may include a GPU 120, a content encoder / decoder 137, and system memory 124. In some embodiments, device 104 may include several additional components, e.g., a communication interface 126, a transceiver 132, a receiver 133, and a transmitter 130, as well as one or more displays 131. References to displays 131 may refer to one or more displays 131. For example, displays 131 may include a single display or multiple displays. Displays 131 may include a first display and a second display. In further examples, the results of graphics processing do not have to be displayed on the device; for example, display 131 does not have to receive frames to present there. Instead, frames or the results of graphics processing may be transferred to other devices. In some embodiments, this may be called hybrid rendering.

[0047] The GPU 120 includes video memory 121. The GPU 120 may be configured to perform graphics processing or non-graphics processing. The GPU 120 may be configured to identify data to load based on the execution of an application program, load data chunks of the identified data in encoded form from the data storage video into the video memory associated with the GPU (e.g., video memory 121), and decode the data chunks in parallel by using multiple GPU thread groups in parallel to decode the data chunks. The content encoder / decoder 137 may include internal memory 135. In some examples, the device 104 may include a display processor, such as a CPU 128, to perform one or more display processing techniques on one or more frames generated by the GPU 120 before presentation by one or more displays 131, as described above. The CPU 128 may be configured to perform display processing. One or more displays 131 may be configured to display or present the frames processed by the CPU 128. In some examples, one or more displays 131 may include one or more liquid crystal displays (LCDs), plasma displays, organic light-emitting diode (OLED) displays, projection display devices, augmented reality display devices, virtual reality display devices, head-mounted displays, or any other type of display device.

[0048] External memory of the GPU 120 and content encoder / decoder 137, such as the system memory 124 described above, may be accessible to the GPU 120 and content encoder / decoder 137. For example, the GPU 120 and content encoder / decoder 137 may be configured to read from and / or write to external memory, such as the system memory 124. The GPU 120 and content encoder / decoder 137 may be communicatively coupled to the system memory 124 via a bus. In some examples, the GPU 120 and content encoder / decoder 137 may be communicatively coupled to each other via a bus or different connections.

[0049] The content encoder / decoder 137 may be configured to receive graphic content or data from any source, such as the system memory 124 and / or the communication interface 126. The system memory 124 may be configured to store the received encoded or decoded graphic content or data. The content encoder / decoder 137 may be configured to receive encoded or decoded graphic content or data in the form of encoded pixel data or encoded data from, for example, the system memory 124 and / or the communication interface 126. The content encoder / decoder 137 may be configured to encode or decode any graphic content or data.

[0050] In some examples, the video memory 121 or system memory 124 may be a non-temporary computer-readable storage medium. The term “non-temporary” may indicate that the storage medium is not embodied in a carrier wave or propagating signal. However, the term “non-temporary” should not be interpreted to mean that the video memory 121 or system memory 124 is immovable or that its contents are static. For example, the system memory 124 may be removed from device 104 and moved to another device. In another example, the system memory 124 may not be removable from device 104.

[0051] A GPU (or processing circuit) may be configured to perform graphics processing or non-graphics processing in accordance with exemplary techniques such as those described herein. In some examples, the GPU 120 may be integrated into the motherboard of device 104. In some examples, the GPU 120 may reside on a graphics card installed in a port on the motherboard of device 104, or it may be incorporated into a peripheral device configured to interact with device 104. The GPU 120 may include one or more processors, such as one or more microprocessors, GPUs, ASICs, FPGAs, ALUs, DSPs, discrete logic, software, hardware, firmware, other equivalent integrated circuits or discrete logic circuits, or any combination thereof. If these techniques are partially implemented in software, the GPU 120 may store instruction sets for the software in a suitable non-temporary computer-readable storage medium and execute these instruction sets in hardware using one or more processors to perform the techniques of the present disclosure. Any of the above, including hardware, software, and combinations of hardware and software, may be considered as one or more processors.

[0052] In some embodiments, the data loading system 100 may include a communication interface 126. The communication interface 126 may include a receiver 133 and a transmitter 130. The receiver 133 may be configured to perform any receiving functions described herein with respect to device 104. Furthermore, the receiver 133 may be configured to receive information from other devices, such as eye or head position information, rendering commands, or location information. The transmitter 130 may be configured to perform any transmitting functions described herein with respect to device 104. For example, the transmitter 130 may be configured to transmit information to other devices, which may include requests regarding content. The receiver 133 and transmitter 130 may be combined with a transceiver 132. In such an example, the transceiver 132 may be configured to perform any receiving and / or transmitting functions described herein with respect to device 104.

[0053] Referring again to Figure 1B, in a particular embodiment, device 104 may include a control component 198 configured to control a processor (e.g., GPU 120) to identify data to load based on the execution of an application program. Furthermore, the control component 198 may also be configured to control the processor to load data chunks of the identified data in an encoded form from a data storage device into video memory associated with the GPU (e.g., 121). In addition, the control component 198 may be further configured to control the processor to decode data chunks in parallel by using multiple GPU thread groups in parallel to decode the data chunks.

[0054] As described herein, a device, such as device 104, may refer to any device, apparatus, or system configured to perform one or more of the techniques described herein. For example, a device may be a server, client device, computer (e.g., personal computer), desktop computer, laptop computer, tablet computer, computer workstation, or mainframe computer, telephone, smartphone, video game platform or console, handheld device (e.g., portable video game device or personal digital assistant (PDA)), wearable computing device, such as a smartwatch, augmented reality device, virtual reality device, display or display device, television, television set-top box, network device, digital media player, video streaming device, content streaming device, in-vehicle computer, or any other device configured to perform one or more of the techniques described herein. The processes described herein may be described as being performed by a specific component, such as a GPU, but in further embodiments, they may also be performed using other processing components configured to perform the described processes.

[0055] Figure 2A illustrates an example of a data loading pipeline handled by multiple processors. Specifically, Figure 2A shows the roles of multiple processors and the interactions between multiple processors during the data lifecycle. As mentioned above, the data may be any block of data consumed in the runtime process. As shown in Figure 2A, the processing pipeline 200a includes at least a hard drive 201, host memory 203, CPU 205, video memory 207, and GPU 209.

[0056] In the associated system, the CPU 205 performs the decider function 211, loader function 213, and decoder function 215, while the GPU 209 performs the consumption function 217. The decider function 211 is configured to determine which data to load. The loader function 213 is configured to read data and load it into memory. The decoder function 215 is configured to decode data. The consumption function 217 is configured to consume data.

[0057] In processing pipeline 200a, the GPU 209 requests the CPU 205 to load data from the hard drive 201. The data is decoded by the CPU 205 and sent to host memory 203. The CPU 205 and video memory 207 can then access the decoded data from host memory 203. The process of the GPU requesting the CPU to load data and then waiting for the CPU to decode the data creates a bottleneck while the GPU is waiting for the data.

[0058] Figure 2B illustrates an example of a GPU-driven rendering pipeline handled by multiple processors. Specifically, Figure 2B shows the roles of multiple processors and the interactions between them during the video data lifecycle. As shown in Figure 2B, the processing pipeline 200b includes at least a hard drive 201, host memory 203, CPU 205, video memory 207, and GPU 209.

[0059] In the GPU-driven rendering pipeline, the GPU 209 determines the data required for rendering, loads the data from storage, and requests the CPU 205 to decode the data. In contrast to the processing pipeline 200a shown in Figure 2A, the processing pipeline 200b transfers the role of the decider function 211 to the GPU 209. This allows the GPU 209 to decide what to load based on the scene and field of view. The decision is then read back to the CPU 205, which performs the loader function 213 and the decoder function 215. Finally, the decoded data is transferred to the GPU for consumption function 219.

[0060] Generally, when GPU209 requests CPU205 to load data, both CPU205 and GPU209 operate asynchronously and must read the data back to CPU205 each time, resulting in a latency of 1-3 frames when processing the request.

[0061] Processing pipelines 200a and 200b have several drawbacks. First, the GPU 209 must wait for the CPU to load and decode the data, which slows down the processing pipeline. Second, the CPU 205 has a lower performance-to-power ratio than the GPU 209, so requesting the CPU 205 to perform decoding consumes a considerable amount of processing power. In addition, the non-integrated memory architecture (NUMA) requires high bandwidth for transferring the determined data from host memory 203 to video memory 207, which increases power consumption.

[0062] Finally, GPU decompression algorithms focus on one type of data. For example, mesh compression can only compress meshes and then decompress them into other meshes. Similarly, texture compression can only focus on texture data. What is needed is a GPU that can perform compression and decompression applicable to different types of data.

[0063] Figure 3 illustrates an example of a data loading pipeline handled by a GPU using one or more of the technologies of this disclosure. Specifically, Figure 3 shows the entire processing pipeline handled by GPU 309. In contrast to processing pipelines 200a from Figure 2A and 200b from Figure 2B, processing pipeline 300 shows loader function 313, decoder function 315, decider function 317, and consumption function 319, all performed by GPU 309.

[0064] Aspects of this disclosure offload the loader function 213 and decoder function 215 from the CPU 205 to the GPU 309. This allows the entire processing pipeline to operate on the GPU 309 with minimal CPU involvement. Consequently, there may be no exchange between the GPU and CPU during the process of loading data for use on the GPU 309. Instead, the GPU may decode the data more efficiently in parallel and transfer the data in a compressed form. In addition, the compressed data is loaded directly into GPU memory, and the GPU 209 decodes the data back into uncompressed data for consumption, so processing occurs in video memory 307 and there is no need to return to host memory 303. Bypassing the CPU bottleneck results in higher performance, lower power consumption, and lower bandwidth usage compared to other related systems involving a CPU.

[0065] Another benefit of processing pipeline 300 is that it does not require modification of the current OS, API, and hardware. The framework introduced in processing pipeline 300 may mainly consist of three parts. Firstly, a file mapping function provided by the OS is used to swap the contents of a file into a memory block. Using the file mapping function means that there is no need to allocate memory because the file is mapped into memory space. After the file is mapped into a memory block, the OS may load the contents asynchronously. Secondly, an API extension may be used to correlate a memory block to a graphics API buffer so that the GPU309 can access the file indirectly via the memory block. The advantage of this is that there is no need to create a buffer. Instead, the data on the storage device may be bound to the graphics API buffer. Thirdly, a build block is provided for constructing GPU decoding algorithms so that common decompression (e.g., unzipping) can be performed in parallel on the GPU309 to convert encoded data into GPU-consumable data. The advantage of this is that it provides an adaptable framework without having to stick to a specific algorithm for a particular file type.

[0066] Since GPU309 is not optimized for rendering from mapped host memory, rendering from mapped host memory may be slower than reading from video memory 307. Therefore, a third part (e.g., a build block for constructing a GPU decoding algorithm) is used to decode the content from mapped host memory 303 to video memory 307. Here, the GP GPU technology is configured to convert a sequential CPU decoding algorithm into a parallel GPU algorithm. For example, build blocks such as prefix sum scan, sort, and matching may be converted into parallel GPU algorithms. After the data has been decoded into video memory 307, GPU209 may use the decoded data.

[0067] A non-exclusive example of a tool that can be used to create a buffer from an existing memory address or block is the Vulkan extension group. Vulkan is a graphics API used in mobile and personal computer / console game development. Vulkan extensions are supported by various platforms and may map existing memory to Vulkan buffers. Specifically, in this non-exclusive example of using Vulkan extensions, a Vulkan extension (e.g., VK_KHR_external_memory) may also be used to associate a memory block with a Vulkan buffer, with respect to a second part (e.g., correlating a memory block with a graphics API buffer). This allows the GPU to access the file indirectly through the Vulkan buffer. In Windows, a second Vulkan extension called memory host (e.g., VK_EXT_external_memory_host) may be used to create a buffer from an existing memory address. In Linux and Android, other Vulcan extensions, such as Memory FD (e.g., VK_KHR_external_memory_fd), may create buffers from file descriptors.

[0068] These extensions allow file contents to be bound to Vulcan buffers without explicit copying. Vulcan buffers are ignorant of how memory is allocated. Instead, by default, space is created within the Vulcan extension group as buffers. This is in contrast to related systems where buffers must be created before data can be delivered to the GPU. In these related systems, when data is delivered to the GPU, the data must first be placed in a buffer, copied, and then sent to the GPU. This extension allows existing allocated buffers to be bound to Vulcan buffers so that data can be sent directly to the GPU for consumption.

[0069] Continuing with non-restrictive examples of using Vulcan extensions, a Vulcan extension used to correlate a memory block to a Vulcan buffer (e.g., VK_KHR_external_memory) may include additional conditions for the memory. The first condition is that the memory is aligned to VkPhysicalDeviceExternalMemoryHostPropertiesEXT::minImportedHostPointerAlignment. The second condition is that the size of the memory is a multiple of the alignment value. The third condition is that the memory status is in READ mode and WRITE mode, even if the memory is only being read from. In Windows, memory addresses from file mappings automatically comply with the first and second conditions. The third condition may be met when the file is created, the mapping is created, and the address is obtained.

[0070] In addition, the associated decompression algorithm is designed without considering parallelism. Therefore, the data is decompressed sequentially. To increase the parallelism of processing in order to take advantage of the GPU309's parallel processing architecture, the data may be reorganized into data chunks. For example, the data may be reorganized into 4KB data chunks. Each data chunk is independently encoded and decoded with a customizable algorithm. The GPU may have millions of threads, but they are organized into groups so that each group always executes the same instruction simultaneously in a single-instruction / multiple-data (SIMD) manner. The groups are called WARPs. A WARP is a collection of threads executed simultaneously by a streaming multiprocessor (SM). Each SM has a set of execution units, a set of registers, and chunks of shared memory. Multiple warps may run on an SM at the same time. On a GPU, a WARP may contain 16 to 128 threads, depending on the hardware implementation.

[0071] Simply allocating threads to decode chunks slows down the decoding process due to branch deviations. Instead, a WARP is assigned to decode chunks, relying on data parallelism for some decoding steps. To minimize interference between decoded chunks, the decoding algorithm may be restricted to using only operations within the WARP. Thus, a WARP-based build block is provided in the framework for this purpose, which can also help implement parallel decoding procedures. In some embodiments, a parallelized unzipping algorithm may be used as the default solution.

[0072] Several examples of WARP-based construction block operations, such as prefix sum scanning, sorting, and matching, are described in more detail below. Each of these WARP-based construction blocks plays a crucial role in the decoding algorithm and may be applicable to all types of compression and decompression scenarios.

[0073] The first WARP-based building block is the prefix sum scan operation. In this framework, instead of adding block-based shared memory, the WARP shuffle function is used for inter-thread data exchange within the WARP. The scan operation is important for converting sequential algorithms to parallel algorithms, and is especially important when the output length of each thread is variable.

[0074] The second WARP-based construction block is the sorting operation. Two sorting algorithms may exist. The first sorting algorithm is radix sort for 32-bit integers. In radix sort, the input data length may be less than or equal to the width of the WARP. The second sorting algorithm is merge sort for arbitrary data types and may be optimized for data lengths of less than 512 elements. This sorting algorithm is based on merge paths and is adapted to the WARP scenario. Each thread in the WARP holds N elements so that the second sorting algorithm can sort a total of (N*WARP size) elements. Synchronization and communication between threads may be modified to remain within the WARP.

[0075] Other WARP-based construction blocks are matching operations. Many decompression algorithms use a matching process to copy from previously decompressed data. For example, "Abcd" may be encoded as "Abcd a[D=5, L=9]", where D is the distance and L is the length. For example, [D=5, L=9] corresponds to rewinding the pointer by 5 bytes and copying 9 bytes. In sequential decompression, this is a straightforward task as bytes are copied one by one. However, when parallelized, more data may be copied in parallel at once, and some bytes are generated during the copying process. In this example, the first 5 bytes "bcd a" are already there and are copied, but the next 4 bytes must be copied later. These 9 bytes cannot be copied in parallel at once. Therefore, the algorithm is iterative. With each iteration, the [D, L] region is divided into two: a non-overlapping region [D, min(L, D)] and an overlapping region [D+min(L, D), max(0, LD)]. Non-overlapping regions can be directly copied to become new [D, L] regions, and partitioning continues until L is less than or equal to D. In the example above, [D=5, L=9] is partitioned into [D=5, L=5] and [D=10, L=4]. Non-overlapping regions can be copied in parallel. Next, [D=10, L=4] becomes a non-overlapping region, and the other copy handles it. The non-overlapping length doubles with each iteration. Therefore, the parallelism doubles with each iteration.

[0076] The decoding and construction block operation described above is general and lossless. This framework may handle arbitrary data such as video data, texture data, mesh data, neural network data, and text data. The framework may also be used on top of domain-specific compressions such as Adaptive Scalable Texture Compression (ASTC) texture compression or Draco geometry compression to provide a higher compression ratio. ASTC is a form of texture compression that uses a variable block size rather than a single fixed size. ASTC is designed to virtually obscure most conventional compression formats by providing one format with all the features of other compression formats plus the advantages of one format. Draco is a library for compressing and decompressing 3D geometric meshes and point clouds, aiming to improve the storage and transmission of 3D graphics. Furthermore, instead of one data file per file, all game data can be placed in a large file, and the data may be managed using a virtual file system. This allows applications to correlate the large file to the GPU and then load any data within it into the GPU.

[0077] Therefore, in processing pipeline 300, the GPU 309 can decode data in parallel more efficiently than processing pipelines 200a and 200b because it does not communicate with the CPU. In addition, the GPU 309 can also transfer data in a compressed form. As a result, it has higher performance, consumes less power, and uses less bandwidth than processing pipelines 200a and 200b.

[0078] Figure 4 illustrates flowcharts of various example methods of data loading in a computing device using one or more of the technologies of this disclosure. Method 400 may be performed by devices such as control component 198 as described above. In some implementations, Method 400 is performed by processing logic including hardware, firmware, software, or a combination thereof. In some implementations, Method 400 is performed by a processor that executes code stored in a non-temporary computer-readable medium (e.g., memory). Method 400 includes the step of loading data in a computing device.

[0079] In block 402, method 400 includes the step of identifying data to load on the GPU based on the execution of an application program. In some embodiments, the data may correspond to video data, texture data, mesh data, neural network data, or text data. For example, referring back to Figure 3, the GPU 309 is configured to determine which data to load based on the execution of an application program in the decider function 317.

[0080] In block 404, method 400 includes the step of loading data chunks of identified data in an encoded form from a data storage device into video memory associated with the GPU via the GPU. The identified data is organized into chunks during an offline (i.e., previously performed) compression phase. This organization of data into data chunks enables the GPU to load the data chunks during runtime. In some embodiments, the step of loading data into video memory includes the steps of mapping data files (e.g., one or more files of data chunks) to memory blocks and associating the memory blocks mapped to data files with buffers using an Application Programming Interface (API) extension group. For example, referring back to Figure 3, the GPU 309 is configured in loader function 313 to load data in an encoded form from hard drive 301 into video memory 307.

[0081] In block 406, method 400 includes the step of decoding data chunks in parallel by using multiple GPU thread groups in parallel to decode the data chunks. Each data chunk is decoded independently of the others. For example, referring back to Figure 3, GPU 309 is configured to decode data chunks in parallel in decoder function 315.

[0082] In some embodiments, each of multiple GPU thread groups may decode one of each data chunk independently of other data chunks by employing an intragroup decoding function limited to using data from its own thread group. In some embodiments, the step of decoding data chunks in parallel may include a step of decoding a first data chunk using a first GPU thread group of the multiple GPU thread groups, and a step of decoding a second data chunk using a second GPU thread group of the multiple thread groups, in parallel and independently. In some embodiments, the intragroup decoding function may include a shuffle function that enables inter-thread data exchange within one of the multiple GPU thread groups. In some embodiments, the intragroup decoding function may include a radix sort of one or more threads in one of the multiple GPU thread groups, the radix sort having an input bit length less than or equal to the number of threads in one of the multiple GPU thread groups. In some embodiments, the intragroup decoding function may include a merge sort applicable to a maximum number of elements equal to the product of the number of elements in one thread and the number of threads in the GPU thread group. In some embodiments, the group decoding function may include a matching operation that iteratively includes (i) copying the non-overlapping regions separated from the overlapping regions of the data, and (ii) dividing the overlapping regions into subsequent non-overlapping regions and subsequent overlapping regions until the length of the subsequent overlapping regions is less than the distance of the subsequent overlapping regions.

[0083] Method 400 may include the step of rendering the decoded data for a visual representation. For example, referring back to Figure 3, the GPU 309 is configured to consume the decoded data by rendering the decoded data for a visual representation in the consumption function 319.

[0084] The subject matter described herein can be implemented to achieve one or more benefits or advantages. For example, the technology disclosed herein enables a method of data loading in a computing device, where the identification, reading, and decoding processes are performed by the GPU rather than the CPU. As a result, the CPU bottleneck is bypassed, providing faster performance and lower latency. In addition, no modification of the current OS, API, hardware, drivers, or existing components is required to utilize the method. Furthermore, the technology disclosed herein provides an adaptable framework that does not require reliance on specific algorithms for specific file types.

[0085] The subject matter described herein can be implemented to achieve one or more benefits or advantages. For example, the graphics processing and non-graphics processing techniques described herein can be used by a server, client, GPU, or any other processor capable of performing computer processing or graphics processing to implement the shared techniques described herein. This can also be achieved at a lower cost compared to other computer or graphics processing techniques. Furthermore, the computer processing or graphics processing techniques described herein can improve or accelerate data processing or execution. Furthermore, the computer processing or graphics processing techniques described herein can improve resource or data utilization and / or resource efficiency.

[0086] According to this disclosure, the term “or” may be interpreted as “and / or” unless the context indicates otherwise. Furthermore, phrases such as “one or more” or “at least one” may be used in some features disclosed herein but not in others, and features in which such wording is not used may be interpreted as having such an implied meaning unless the context indicates otherwise.

[0087] In one or more examples, the functions described herein may be implemented in hardware, software, firmware, or any combination thereof. For example, although the term “processing unit” is used throughout this disclosure, such processing unit may be implemented in hardware, software, firmware, or any combination thereof (e.g., by processing circuitry). If any function, processing unit, technology described herein, or other module is implemented in software, that function, processing unit, technology described herein, or other module may be stored or transferred as one or more instructions or code on a computer-readable medium. The computer-readable medium may include computer data storage medium or communication medium, including any medium that facilitates the transfer of computer programs from one location to another. Thus, the computer-readable medium may generally correspond to (1) a non-transient, tangible computer-readable storage medium, or (2) a communication medium such as a signal or carrier wave. The data storage medium may be any available medium that can be accessed by one or more computers or one or more processors to retrieve instructions, code, and / or data structures for implementing the technology described herein. Such computer-readable media may include, but are not limited to, RAM, ROM, EEPROM, CD-ROM or other optical disk storage devices, magnetic disk storage devices or other magnetic storage devices. The terms "disk" and "disc" as used herein include compact discs (CDs), laser discs, optical discs, digital multi-purpose discs (DVDs), floppy disks, and Blu-ray discs, where a disk typically reproduces data magnetically, and a disc reproduces data optically using a laser. Combinations of the above should also be included within the scope of computer-readable media. Computer program products may include computer-readable media.

[0088] The code may be executed by one or more processors, such as one or more digital signal processors (DSPs), general-purpose microprocessors, application-specific integrated circuits (ASICs), arithmetic logic units (ALUs), field-programmable logic arrays (FPGAs), or other equivalent integrated circuits or discrete logic circuits. Therefore, the term “processor” as used herein may refer to any of the aforementioned structures or any other structure suitable for implementing the technologies described herein. Furthermore, these technologies can be fully implemented in one or more circuits or logic elements.

[0089] The technology of this disclosure may be implemented in a wide variety of devices or apparatus, including wireless handsets, integrated circuits (ICs), or sets of ICs, such as chipsets. While various components, modules, or units are described in this disclosure to highlight the functional aspects of devices configured to perform the disclosed technology, implementation by different hardware units is not necessarily required. Rather, as described above, the various units may be combined with any hardware unit, along with appropriate software and / or firmware, or may be provided by a set of interoperable hardware units including one or more processors as described above. [Explanation of Symbols]

[0090] 100 Data Loading Systems 104 devices 111 Software Applications 113 OS 115 Graphics Driver 120 GPU 121 Video Memory 123. Decider function 124 System Memory 125 Loader function 126 Communication Interfaces 127 Decoder function 128 CPU 130 Transmitters 131 displays 132 transceivers 133 Receiver 135 Internal Memory 137 Content Encoder / Decoder 138 frame buffers 198 Control Components 200a, 200b, 300 Processing Pipelines 201 Hard Drive 203 Host Memory 205 CPU 207 Video Memory 209 GPU 211. Decider function 213 Loader function 215 Decoder function 217, 219 consumption function 301 Hard Drive 303 Host Memory 307 Video Memory 309 GPU 313 Loader function 315 Decoder function 317. Decider function 319 Consumption function 400 ways 402 blocks 404 Block 406 blocks

Claims

1. A data loading method performed by a computing device, In a graphics processing unit (GPU), the steps include identifying the data to be loaded based on the execution of an application program, The steps include loading the data chunks of the identified data in an encoded form from a data storage device into the video memory associated with the GPU via the GPU, A step of decoding the data chunk in parallel by using multiple GPU thread groups in parallel to decode the data chunk, wherein each of the data chunks is decoded independently of the other data chunks. Includes, Each of the aforementioned GPU thread groups decodes one of the data chunks independently of other data chunks by employing an intra-group decoding function limited to using data from the respective thread group. The group decoding function includes a shuffling function that enables inter-thread data exchange within one of the multiple GPU thread groups when the output length of each thread is variable. Data loading method.

2. The method according to claim 1, wherein the step of decoding the data chunks in parallel includes decoding the first data chunk using a first GPU thread group from among the plurality of GPU thread groups, and decoding the second data chunk using a second GPU thread group from among the plurality of thread groups, in parallel and independently.

3. The method according to claim 1, wherein the group decoding function includes radix sorting of one or more threads in one of the plurality of GPU thread groups, and the radix sort has an input bit length that is less than or equal to the number of threads in one of the plurality of GPU thread groups.

4. The method according to claim 1, wherein the group decoding function includes a merge sort applicable to a maximum number of elements equal to the product of the number of elements in one thread and the number of threads in the GPU thread group.

5. The method according to claim 1, wherein the group decoding function includes a matching operation that iteratively includes (i) copying a non-overlapping region separated from the overlapping region of the data, and (ii) dividing the overlapping region into a subsequent non-overlapping region and the subsequent overlapping region until the length of the subsequent overlapping region is less than the distance of the subsequent overlapping region.

6. The step of loading the data into the video memory is: The steps include mapping the aforementioned data file to a memory block, The steps include: associating the memory block mapped to the file of the data with a buffer using an Application Programming Interface (API) extension group; The method according to claim 1, including the method described in claim 1.

7. The method according to claim 1, wherein the data corresponds to video data, texture data, mesh data, neural network data, or text data.

8. The method according to claim 1, further comprising the step of rendering the decoded data for visual representation.

9. An apparatus configured to perform the method described in any one of claims 1 to 8.

10. A computer program for causing a computer to perform the method described in any one of claims 1 to 8.

11. Based on the execution of the application program, identify the data to load. The data chunks of the identified data in their encoded form are loaded from the data storage device into the video memory associated with the GPU. Decoding the data chunk in parallel by using multiple GPU thread groups in parallel to decode the data chunk, wherein each of the data chunks is decoded independently of the other data chunks. A controller configured in such a way Equipped with, Each of the aforementioned GPU thread groups decodes one of the data chunks independently of other data chunks by employing an intra-group decoding function limited to using data from the respective thread group. The group decoding function includes a shuffling function that enables inter-thread data exchange within one of the multiple GPU thread groups when the output length of each thread is variable. device.

12. The device according to claim 11, wherein decoding the data chunks in parallel includes decoding a first data chunk using a first GPU thread group among the plurality of GPU thread groups, and decoding a second data chunk using a second GPU thread group among the plurality of thread groups, in parallel and independently.

13. The device according to claim 11, wherein the intragroup decoding function includes radix sorting of one or more threads in one of the plurality of GPU thread groups, and the radix sort has an input bit length that is less than or equal to the number of threads in one of the plurality of GPU thread groups.

14. The device according to claim 11, wherein the group decoding function includes a merge sort applicable to a maximum number of elements equal to the product of the number of elements in one thread and the number of threads in the GPU thread group.

15. The device according to claim 11, wherein the group decoding function includes a matching operation that iteratively includes (i) copying a non-overlapping region separated from the overlapping region of the data, and (ii) dividing the overlapping region into a subsequent non-overlapping region and the subsequent overlapping region until the length of the subsequent overlapping region is less than the distance of the subsequent overlapping region.

16. Loading the data into the video memory is Mapping the aforementioned data file to a memory block, Using an Application Programming Interface (API) extension group, associate the memory block mapped to the file of the data with the buffer. The device according to claim 11, including the device described in claim 11.

17. The device according to claim 11, wherein the data corresponds to video data, texture data, mesh data, neural network data, or text data.

18. The device according to claim 11, wherein the controller is further configured to render the decoded data for visual representation.

Images