KR20230007377A - GPR optimization of GPU based on GPR release mechanism - Google Patents

Abstract

This disclosure provides systems, devices, apparatuses and methods, including computer programs encoded in a storage medium, for GPR optimization in a GPU based on a GPR release mechanism. More specifically, the GPU can determine at least one unused branch within an executable shader based on constants defined for the executable shader. Based on that at least one unused branch, the GPU can further determine the number of GPRs that can be deallocated from previously allocated GPRs. The GPU can, for a subsequent thread within the draw call, deallocate the number of GPRs from previously allocated GPRs during execution of the executable shader based on the number of GPRs determined to be deallocated.

Description

GPR optimization of GPU based on GPR release mechanism

This application claims the benefit of U.S. Patent Application No. 16/877,367 filed on May 18, 2020, entitled "GPR OPTIMIZATION IN A GPU BASED ON A GPR RELEASE MECHANISM", which is incorporated herein in its entirety Obviously incorporated by reference.

This disclosure relates generally to processing systems, and more specifically to register optimization in graphics processing using a release mechanism.

Computing devices often perform graphics processing (eg, utilizing a graphics processing unit (GPU)) to render graphics data for display by the computing devices. Such computing devices may include, for example, computer workstations, mobile phones such as smart phones, embedded systems, personal computers, tablet computers, and video game consoles. GPUs are configured to execute a graphics processing pipeline that includes one or more processing stages that work together to execute graphics processing commands and output frames. A central processing unit (CPU) may control the operation of a GPU by issuing one or more graphics processing commands to the GPU. Modern CPUs are typically capable of running multiple applications simultaneously, and each of the applications may need to utilize the GPU during execution. A device providing content for visual presentation on a display may utilize a GPU.

General purpose registers (GPRs) can be assigned to programs running on the GPU to temporarily store information. However, as more GPRs are allocated to a program, fewer threads can reside simultaneously on the GPU. Therefore, it is necessary to reduce the number of GPRs allocated to programs.

The following presents a brief summary of one or more aspects to provide a basic understanding of those aspects. This summary is not an exhaustive overview of all contemplated aspects, it is intended not to identify key or critical elements of all aspects, nor to delineate the scope of any or all aspects. Its sole purpose is to present one or more aspects of some concepts in a simplified form as a prelude to the more detailed description that is presented later.

GPRs can be assigned variously to shader programs following shader compilation based on the number of possible branches within the compiled shader. More specifically, the compiler may determine at compile time that the shader's variables may be constant over the duration of the draw call, even though the exact values of the shader's variables may not be determined by the compiler at that compile time. The number of possible branches within such a compiled shader may be determined based on the different values the constant may assume at runtime of the shader. As a result, excessive GPRs are allocated to shaders at compile time to ensure that shaders have enough GPRs to execute the most complex branches of shaders regardless of whether those branches are actually executed.

Excess GPRs allocated to shaders can therefore be deallocated at compile time using a programmable GPR release mechanism. The release mechanism may be executed at runtime of the shader after the values of the constants are determined by the shader. More specifically, for example, shaders can be compiled into complex branches that require more GPRs to execute, and simple branches that require fewer GPRs to execute. Based on the values defined for the constants, the shader can decide that complex branches are not executed during draw calls and that some of the GPRs allocated to the shader at compile time are more than are required for execution of simpler branches. Thus, the release mechanism may be configured to deallocate excess/unnecessary GPRs from subsequent shader threads so that more subsequent threads can concurrently reside on the GPU.

In one aspect of the present disclosure, methods, computer readable media, and apparatus are provided. An apparatus may include a memory and at least one processor coupled to the memory. The at least one processor determines at least one unused branch within the executable shader based on constants defined for the executable shader, and deallocates from allocated GPRs based on the at least one unused branch. It can be configured to further determine the number of GPRs that can be. The at least one processor may de-allocate the number of GPRs from the allocated GPRs during execution of the executable shader within the draw call based on the determined number of GPRs.

To the accomplishment of the foregoing and related ends, one or more aspects include the features fully described below and particularly pointed out in the claims. The following description and accompanying drawings disclose in detail certain illustrative features of one or more aspects. However, these features represent only a few of the various ways in which the principles of the various aspects may be employed, and this description is intended to encompass all such aspects and their equivalents.

1 is a block diagram illustrating an example content creation system in accordance with one or more techniques of this disclosure.
2 is a block diagram illustrating example components for processing data in accordance with one or more techniques of this disclosure.
3 is a block diagram corresponding to example instructions for executing a shader based on GPR allocation in accordance with one or more techniques of this disclosure.
4 is a block diagram corresponding to example instructions for executing shaders based on a programmable GPR release mechanism in accordance with one or more techniques of this disclosure.
5 is a flowchart of an example method in accordance with one or more techniques of this disclosure.
6 is a conceptual data flow diagram illustrating data flow between different means/components in an exemplary apparatus.

Several aspects of the systems, apparatuses, computer program products and methods will be more fully described below with reference to the accompanying drawings. This disclosure may, however, be embodied in many different forms and should not be construed as limited to any specific structure or function 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 will appreciate that the systems, apparatuses, computer program products, and and any aspect of the methods. For example, an apparatus may be implemented or a method may be practiced using any number of the aspects set forth herein. Further, the scope of the present disclosure is intended to cover such apparatus or methods implemented using other structures, functions, or structures and functions other than or in addition to the various aspects of the present disclosure set forth herein. Any aspect disclosed herein may be embodied by one or more elements of a claim.

Although various aspects are described herein, many variations and permutations of these aspects fall within the scope of the present disclosure. Although some potential benefits and advantages of aspects of this disclosure are mentioned, the scope of this disclosure is not intended to be limited to particular benefits, uses, or objectives. Rather, aspects of the present disclosure are intended to be broadly applicable to different radio technologies, system configurations, networks, and transmission protocols, some of which are illustrated in the drawings by way of example and in the description that follows. The detailed description and drawings are illustrative rather than limiting of the disclosure, the scope of which is defined by the appended claims and equivalents thereof.

Several aspects are presented with reference to various apparatus and methods. These apparatus and methods are described in the detailed description that follows in terms of various blocks, components, circuits, processes, algorithms, etc. (collectively referred to as "elements") and are illustrated in the accompanying drawings. These elements may be implemented using electronic hardware, computer software, or any combination thereof. Whether such elements are implemented in hardware or software depends on the particular application and design constraints imposed on the overall system.

As an example, an element, or any portion of an element, or any combination of elements may be implemented as a “processing system” that includes one or more processors (which may also be referred to as processing units). Examples of processors include microprocessors, microcontrollers, graphics processing units (GPUs), general purpose GPUs (GPGPUs), central processing units (CPUs), application processors, digital signal processors (DSPs) , reduced instruction set computing (RISC) processors, systems-on-chip (SoC), baseband processors, application specific integrated circuits (ASICs), field programmable gate arrays (FPGAs), programming enabling logic devices (PLDs), state machines, gated logic, discrete hardware circuits, and other suitable hardware configured to perform the various functions described throughout this disclosure. One or more processors in the processing system may execute software. Software, whether referred to as software, firmware, middleware, microcode, hardware description language, or otherwise, includes instructions, instruction sets, code, code segments, program code, programs, subprograms, software components, Applications, software applications, software packages, routines, subroutines, objects, executables, threads of execution, procedures, functions, and the like.

The term application may also refer to software. As described herein, one or more techniques may refer to an application (eg, software) that is configured to perform one or more functions. In these examples, the application may be stored in memory (eg, on-chip memory of a processor, system memory, or any other memory). Hardware described herein, such as a processor, may be configured to run applications. For example, an application may be described as comprising code that, when executed by hardware, causes the hardware to perform one or more techniques described herein. As an example, hardware may access code from memory and execute the accessed code from memory to perform one or more techniques described herein. In some examples, components are identified in this disclosure. In such examples, components may be hardware, software, or combinations thereof. Components may be separate components or sub-components of a single component.

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 on or encoded as one or more instructions or code on a computer readable medium. Computer readable media includes computer storage media. A storage medium may be any available medium that may be accessed by a computer. By way of non-limiting example, such computer readable media may include random-access memory (RAM), read-only memory (ROM), electrically erasable programmable ROM (EEPROM), optical disk storage, magnetic disk storage, other magnetic storage devices, It may include a combination of one type of computer readable medium, or any other medium that may be used to store computer executable code in the form of instructions or data structures that may be accessed by a computer.

In general, this disclosure may improve rendering of graphical content and/or reduce the load of a processing unit (eg, any processing unit configured to perform one or more techniques described herein, such as a GPU). Techniques for graphics processing on a single device or on multiple devices are described. For example, this disclosure describes techniques applicable to graphics processing in any device that utilizes a graphics processor. Other possible advantages of this technique are described throughout this disclosure.

As used herein, instances of the term “content” may refer to “graphical content,” “images,” etc., regardless of whether the term is used as an adjective, noun, or other parts of speech. In some examples, the term “graphics content” as used herein may refer to content created by one or more processes of a graphics processing pipeline. In further examples, the term “graphics content” as used herein may refer to content created by a processing unit configured to perform graphics processing. In still further examples, the term “graphics content” as used herein may mean content created by a graphics processing unit.

GPRs can be assigned variously to shader programs following shader compilation based on the number of possible branches within the compiled shader. More specifically, the compiler may determine at compile time that the shader's variables may be constant over the duration of the draw call, even though the exact values of the shader's variables may not be determined by the compiler at that compile time. The number of possible branches within such a compiled shader may be determined based on the different values the constant may assume at runtime of the shader. As a result, excessive GPRs are allocated to shaders at compile time to ensure that shaders have enough GPRs to execute the most complex branches of shaders regardless of whether those branches are actually executed.

Excess GPRs allocated to shaders can therefore be deallocated at compile time using a programmable GPR release mechanism. The release mechanism may be executed at runtime of the shader after the values of the constants are determined by the shader. More specifically, for example, shaders can be compiled into complex branches that require more GPRs to execute, and simple branches that require fewer GPRs to execute. Based on the values defined for the constants, the shader can decide that complex branches are not executed during draw calls and that some of the GPRs allocated to the shader at compile time are more than are required for execution of simpler branches. Thus, the release mechanism can be configured to deallocate excess/unnecessary GPRs from the shader so that the excess GPRs can be allocated to subsequent threads of the GPU, allowing more subsequent threads to reside simultaneously on the GPU.

1 is a block diagram illustrating an example content creation system 100 configured to implement one or more techniques of this disclosure. Content creation system 100 may include video devices (eg, media players), set top boxes, wireless communication devices (eg, smart phones), personal digital assistants (PDAs), desktop/laptop computers, game consoles, video device 104, which may be, but is not limited to, a conferencing device, a tablet computing device, and the like. Device 104 may include one or more components or circuits to perform various functions described herein. In some examples, one or more components of device 104 may be components of a SOC. Device 104 may include one or more components that are configured to perform one or more techniques of this disclosure. In the example shown, device 104 may include processing unit 120 and system memory 124 . In some aspects, device 104 may include a plurality of optional components (e.g., communication interface 126, transceiver 132, receiver 128, transmitter 130, display processor 127, and one or more displays 131). Display(s) 131 may refer to one or more displays 131 . For example, display 131 may include a single display or multiple displays, which may include a primary display and a secondary display. The first display may be a left eye display and the second display may be a right eye display. In some examples, the first and second displays may receive different frames for presentation thereon. In other examples, the first and second displays may receive the same frames for presentation thereon. In further examples, results of graphics processing may not be displayed on the device, eg, the first and second displays may not receive any frames for presentation thereto. Instead, frames or graphics processing results may be transmitted to another device. In some aspects, this may be referred to as split rendering.

Processing unit 120 may include internal memory 121 . Processing unit 120 may be configured to perform graphics processing using graphics processing pipeline 107 . In some examples, device 104 may use a display processor, such as a display processor, to perform one or more display processing techniques on one or more frames generated by processing unit 120 before being displayed by one or more displays 131 . display processor 127. Display processor 127 may be configured to perform display processing. For example, display processor 127 may be configured to perform one or more display processing techniques on one or more frames generated by processing unit 120 . One or more displays 131 may be configured to display or otherwise present frames processed by display processor 127 . In some examples, one or more displays 131 may be a liquid crystal display (LCD), a plasma display, an organic light emitting diode (OLED) display, a projection display device, an augmented reality display device, a virtual reality display device, a head mounted display, or any It may also include one or more of other types of display devices.

Memory external to processing unit 120 , such as system memory 124 , may be accessible to processing unit 120 . For example, processing unit 120 may be configured to read and/or write to external memory, such as system memory 124 . Processing unit 120 may be communicatively coupled to system memory 124 via a bus. In some examples, processing unit 120 may be communicatively coupled to internal memory 121 via a bus or other connection. Internal memory 121 or system memory 124 may include one or more volatile or non-volatile memories or storage devices. In some examples, internal memory 121 or system memory 124 is RAM, static random access memory (SRAM), dynamic random access memory (DRAM), erasable programmable ROM (EPROM), EEPROM, flash memory, a magnetic data medium, or optical storage media or any other type of memory.

Internal memory 121 or system memory 124 may be a non-transitory storage medium according to some examples. The term “non-transitory” may indicate that the storage medium is not embodied in a carrier wave or propagated signal. However, the term “non-transitory” should not be construed to mean that internal memory 121 or system memory 124 is not removable or that its contents are static. As an example, system memory 124 may be removed from device 104 and moved to another device. As another example, system memory 124 may not be removable from device 104 .

Processing unit 120 may be a CPU, GPU, GPGPU, or any other processing unit that may be configured to perform graphics processing. In some examples, processing unit 120 may be integrated into a motherboard of device 104 . In further examples, processing unit 120 may reside on a graphics card installed in a port other than the mother of device 104 or may otherwise be integrated within a peripheral device configured to interact with device 104 . Processing unit 120 may include one or more processors, such as one or more microprocessors, GPUs, ASICs, FPGAs, arithmetic logic units (ALUs), DSPs, discrete logic, software, hardware, firmware, It may also include other equivalent integrated or discrete logic circuitry or any combination thereof. If the techniques are implemented partly in software, processing unit 120 may store instructions for software in a suitable non-transitory computer-readable storage medium, such as internal memory 121, to perform the techniques of this disclosure. One or more processors may be used to execute instructions in hardware. Any of the foregoing, including hardware, software, combinations of hardware and software, or the like, may be considered one or more processors.

In some aspects, content creation system 100 can include an optional communication interface 126 . Communications interface 126 may include a receiver 128 and a transmitter 130 . Receiver 128 may be configured to perform any receive function described herein for device 104 . Additionally, receiver 128 may be configured to receive information from another device, eg, eye or head position information, rendering commands, or location information. Transmitter 130 may be configured to perform any transmission function described herein for device 104 . For example, transmitter 130 may be configured to transmit information, which may include a request for content, to another device. Receiver 128 and transmitter 130 may be combined into a transceiver 132 . In such examples, transceiver 132 may be configured to perform any receive function and/or transmit function described herein for device 104 .

Referring again to FIG. 1 , in certain aspects, graphics processing unit 120 determines at least one unused branch within an executable shader based on constants defined for the executable shader; determine a number of GPRs that can be de-allocated from the allocated GPRs based on the at least one unused branch; and a GPR deallocation component 198 configured to, for a subsequent thread within the draw call, deallocate the number of GPRs from allocated GPRs during execution of the executable shader based on the determined number of GPRs. Describing and referencing deassignment component 198 as a “component” is for convenience of explanation and does not necessarily correspond to a specific hardware component of processing unit 120 . For example, deassignment component 198 may be configured as code, logic, and the like.

A device, such as device 104 , may refer to any device, apparatus, or system that is configured to perform one or more techniques described herein. For example, a device may be a server, base station, user equipment, client device, station, access point, computer such as a personal computer, desktop computer, laptop computer, tablet computer, computer workstation, or mainframe computer, end product , devices, phones, smartphones, servers, video game platforms or consoles, handheld devices such as portable video game devices or personal digital assistants (PDAs), wearable computing devices such as smart watches, augmented reality devices or virtual reality devices. , non-wearable device, display or display device, television, television set top box, intermediate network device, digital media player, video streaming device, content streaming device, computer in vehicle, any mobile device, any configured to generate graphical content device, or any device configured to perform one or more techniques described herein. Processes herein may be described as being performed by a particular component (eg, GPU), but in other embodiments, consistent with the disclosed embodiments, other components (eg, CPU) It can also be done using

2 is a block diagram 200 illustrating example components such as processing unit 120 and system memory 124 as may be identified with respect to example device 104 for processing data. In aspects, processing unit 120 may include CPU 202 and GPU 212 . GPU 212 and CPU 202 may be formed as an integrated circuit (eg, SOC) and/or GPU 212 may be integrated on a motherboard along with CPU 202 . Alternatively, CPU 202 and GPU 212 may be configured as separate processing units communicatively coupled to each other. For example, GPU 212 may be integrated on a graphics card installed in a port of a motherboard that includes CPU 202 .

CPU 202 may be configured to execute a software application that causes graphical content to be displayed (eg, on display(s) 131 of device 104 ) based on one or more operations of GPU 212 . there is. A software application may issue commands to a graphics application program interface (API) 204 , which may be a runtime program that converts commands received from the software application into a format readable by the GPU driver 210 . After receiving commands from a software application via graphics API 204, GPU driver 210 may control the operation of GPU 212 based on the commands. For example, GPU driver 210 may generate one or more command streams that are placed in system memory 124, where GPU 212 executes the command streams (eg, via one or more system calls). instructed to do Command engine 214 included in GPU 212 is configured to retrieve one or more commands stored in a command stream. Command engine 214 may provide commands from a command stream for execution by GPU 212 . Command engine 214 may be hardware of GPU 212 , software/firmware running on GPU 212 , or a combination thereof.

GPU driver 210 is configured to implement graphics API 204, although GPU driver 210 is not limited to being configured according to any particular API. System memory 124 may store code for GPU driver 210 that CPU 202 may retrieve for execution. In examples, GPU driver 210 may be used to provide information between CPU 202 and GPU 212, such as when CPU 202 offloads graphics or non-graphics processing tasks to GPU 212 via GPU driver 210. It can be configured to allow communication.

The system memory 124 may further store source code for one or more of the preamble shader 224 or the main shader 226 . In such configurations, shader compiler 208 running on CPU 202 uses shaders 224-226 to generate object code or intermediate code executable by shader core 216 of GPU 212 during runtime. may compile the source code of (e.g., when shaders 224-226 are to be executed on shader core 216). In some examples, shader compiler 208 may precompile shaders 224 - 226 and store object code or intermediate code of shader programs in system memory 124 .

Shader compiler 208 (or GPU driver 210 in another example) running on CPU 202 may build a shader program having multiple components, including preamble shader 224 and main shader 226. . Main shader 226 may correspond to part or all of a shader program that does not include preamble shader 224 . Shader compiler 208 may receive instructions to compile shader(s) 224 - 226 from a program running on CPU 202 . Shader compiler 208 may also identify constant load instructions and common operations in a shader program to include common operations within preamble shader 224 (rather than main shader 226). The shader compiler 208 can identify these common instructions, for example, based on (currently undetermined) constants 206 to be included in the common instructions. Constants 206 may be defined within the graphics API 204 to be constant across the entire draw call. Shader compiler 208 may use instructions such as start preamble shader to indicate the beginning of preamble shader 224 and end preamble shader to indicate the end of preamble shader 224 . Similar instructions can be used for the main shader 226.

The shader core 216 included in the GPU 212 may include a GPR 218 and a constant memory 220 . GPR 218 may correspond to a single GPR, GPR file, and/or GPR bank. Each GPR within GPRs 218 may store data accessible to a single thread. Software and/or firmware running on GPU 212 may be shader programs 224 - 226 , which may run on shader core 216 of GPU 212 . Shader core 216 may be configured to execute many instances of the same instructions of the same shader program in parallel. For example, shader core 216 can execute main shader 226 for each pixel defining a given shape.

Shader core 216 may send and receive data from applications running on CPU 202 . In examples, constants 206 used in the execution of shaders 224-226 may be stored in constant memory 220 (eg, read/write constant RAM) or GPR 218. Shader core 216 may load constant 206 into constant memory 220 . In further examples, execution of the preamble shader 224 may generate a constant value or set of constant values in on-chip memory, such as constant memory 220 (e.g., constant RAM), GPU memory 222, or system memory 124. can be stored. Constant memory 220 may include memory accessible by all aspects of shader core 216 rather than just a specific portion reserved for a specific thread, such as the value held in GPR 218.

3 is a block diagram 300 corresponding to example instructions 350 for executing shader 302 based on GPR assignments. GPRs can be dynamically assigned to shaders at shader compilation. However, as the number of GPRs 218 allocated to a shader 302 increases, the corresponding number of threads that can simultaneously reside on the GPU decreases. Such an effect of increasing the number of assigned GPRs 218 can limit latency concealment as well as degrade the overall performance of the GPU. To balance the tradeoff between increasing the number of GPRs 218 allocated to shader 302 and increasing the number of threads that can simultaneously reside on the GPU, shader 302 is It may also be implemented based only on the minimum number of GPRs 218 required for shader execution so that there are no unused allocated GPR resources.

The minimum number of GPRs 218 required to execute shader 302 may be based on a single draw call or constant/uniform value that does not change during runtime of shader 302 for a kernel. If the exact value of constant 206 may not be known by the compiler when shader 302 is compiled, an excess of GPRs 218 may lead to more complex paths/branches of shader 302 (e.g., complex branch 304 )) may be assigned to the shader 302 to ensure sufficient availability of the GPR 218 to execute. If the value of the constant 206 is known when the shader 302 is compiled, the compiler removes from the shader 302 certain branches that require more GPRs 218 to execute, so that subsequent to compilation the shader ( 302) can increase shader performance by reducing the number of GPRs 218 that need to be allocated. Alternatively, if the GPU driver can determine the value of constant 206 when the shader 302 is submitted (e.g., queued) to the GPU, then the compiler should each have a different GPR assignment and the GPU driver should be used on submission. You can create multiple versions of shader 302 allowing you to choose which version of shader 302 you want.

In general, the value of constant 206 cannot be determined by the compiler at compile time or by the GPU driver at submit time. The compiled shader 302 can be configured to identify the value of the constant 206 at runtime, but the number of GPRs 218 probably determines the number of GPRs 218 needed to execute a particular branch of the shader 302. In excess, it may already be assigned to shader 302 by the time runtime occurs. Thus, although the compiler may be configured to identify that the variable is a constant at compile time, the exact value of the constant 206 may remain unknown during shader compilation and the constant value may not be available to reduce GPR allocation.

A shader can have different flow control paths/branches based on some combination of constants (206). The constant 206 may be defined within the graphics API to remain the same throughout the entire draw call (eg, throughout the lifetime of the corresponding shape). That is, a constant 206 of a given value does not change pixel by pixel from one pixel to the next across a draw call. Constant 206 remains unchanged throughout the shader lifetime for every pixel executing the corresponding shape. Constant buffers, also referred to as uniform buffers, can be managed by graphics APIs and can reside in memory (similar to texture buffers or frame buffers, for example), where constant buffers are constant/uniform via draw calls. It can be accessed by shader 302 to provide a value.

The executable shader program may include a preamble portion of the shader program and a main portion of the shader program (or simply “preamble shader” 224 and “main shader” 226). The preamble shader 224 may be part of the shader 302 that is executed only once per draw call or per kernel. The preamble shader 224 may be executed before allowing any thread to execute the main shader 226. The preamble shader 224 may also preload constant values into the local memory of the GPU, where the constant values may be used by multiple threads executing within the main shader 226 . Thus, the constant value can be fetched by the preamble shader once per draw call rather than by the main shader for each thread (eg pixel) in the draw call.

In one example, preamble shader 224 can fetch local constant 206 from a local constant buffer. When local constant 206 has a first value (eg constant value X), main shader 226 uses a first number of GPRs 218 (eg 20 GPRs) to create a complex branch. (304) can be executed. When the local constant has a second value (e.g. constant value Y), the main shader 226 uses the second number of GPRs 218 (e.g. 4 GPRs) to make a simple branch 306 can run However, if the local constant for the draw call is 0 and execution of the complex branch 304 is not required, the shader 302 will still be executed based on the allocation of 20 GPRs rather than, for example, the allocation of 4 GPRs. may be As a result, some of the GPRs 218 allocated to shaders 302 may be unnecessary/redundant.

4 is a block diagram 400 corresponding to example instructions 450 for executing a shader 302 based on a programmable GPR release mechanism 402 . The GPR release mechanism 402 may be executed at run time to allow the GPR “footprint” to be modified based on local constant values and/or determining the number of assigned GPRs 218 . For example, when local constant 206 is 0, shader 302 can execute a simple branch 306 to the draw call (e.g., with 4 GPRs per thread) and within the draw call a subsequent thread /may release any excess GPRs 218 associated with a pixel run (eg, 16 GPRs may be released). Unlike the compiler, which may cause GPR assignments to be based on complex branches (304) because the compiler may have no way of determining the value of the constant (206) at compile time, the shader (302) uses the GPR release mechanism (402) to After identifying these values of the constants 206, determine the number of GPRs 218 actually needed for execution of the shader 302 so that any unnecessary GPRs 218 can be released/deallocated from the shader 302.

Thus, shader 302 may be executed based on a complex branch 304 that requires a larger number of GPRs 218 or shader 302 may be executed based on a determined value of constant 206 by GPR release mechanism 402. It can be implemented based on a simple branch 306 requiring fewer GPRs 218 based on . However, if the value of the constant 206 is determined to be a value corresponding to the execution of the simple branch 306, so that the complex branch 304 does not need to be executed, the shader ( GPR 218 allocated to 302 may be deallocated from shader 302 for subsequent execution instances. Thus, the GPR release mechanism 402 increases the availability of the GPR 218 for use by other threads on the GPU outside of the shaders 302, allowing more threads to reside simultaneously, thereby freeing the GPU of GPR resources. It can be configured to provide more efficient allocation.

Deallocation of GPR 218 via GPR release mechanism 402 may not apply to the first running instance of preamble shader 224 or main shader 226 (which is executed only once per draw call), but has not yet been issued. may apply only to subsequent threads in the draw call that have not yet received a GPR allocation. Because the GPR release mechanism 402 is configured to modify GPR assignments for subsequent threads, the approach for releasing GPRs 218 from subsequent threads is the approach for releasing GPRs from the current thread that already have GPRs 218 assigned to them. can be simplified by comparison with The exact time at which GPR 218 must be deallocated for subsequent threads may be less important in some cases since previously issued threads that run with excess GPR allocation will still run correctly. As such, the GPR release mechanism 402 uses the preamble shader 224 (e.g., to cause the GPR to be deallocated for all threads of the draw call) and/or the preamble shader 224 (e.g., may be integrated into either or both of the main shader 226 to allow the GPR to be deallocated for a subset of the threads of the draw call, such as in configurations that do not.

A command processor or other programmable hardware unit that accesses constant 206 may be configured to perform similar operations to GPR release mechanism 402 . For example, the command processor can be configured to determine based on the constant 206 the number of GPRs 218 needed to execute the shader 302 before the shader 302 is launched by the command processor. The command processor may then cause the GPRs 218 to be assigned to the shader 302 based on the determined number of GPRs 218 .

The preamble shader 224 and the main shader 226 may be compiled simultaneously. The preamble shader 224 can be used to fetch the constant 206 from memory and store the constant 206 in a local constant buffer where it can be accessed more efficiently during a draw call. Because the constant 206 remains unchanged throughout the draw call, the preamble shader 224 is not fetched for each pixel by the main shader 226, rather than the constant 206 at the beginning of the draw call. Provides a one-time fetch method. Although the preamble shader 224 may provide the benefit of managing local constant storage for the purpose of more efficient access to the constants 206, the preamble shader 224 is not a requirement for the implementation of the GPR release mechanism 402. not. For example, the compiler could instead compile main shader 226 to fetch constant 206 from memory, but on a per-pixel basis rather than once per draw call. The main shader ( The decision may be made by the GPR release mechanism 402 at 226). Since the per-pixel decision is based on the constant 206, the determined number of GPRs 218 for subsequent pixels/threads remains unchanged throughout the draw call. The preamble shader 224 may allow the GPR 218 to be deallocated as soon as the execution of the main shader 226 begins, but the GPR release mechanism 402 does not allow the first part of the draw call to deallocate the excess GPR. may be similarly executed by the main shader 402 after being executed with a less efficient GPR allocation to provide/more efficient GPR allocation to execute the second part of the draw call.

When the compiler generates shader 302, the number of unique paths/branches through shader 302 can be identified based on different possible constants 206 that can be input to a function of shader 302. That is, the compiler can determine the number of GPRs 218 that should be assigned to the shader 302 based on the function of the shader 302 and the different possible constants 206 . The number of GPRs 218 determined by the compiler at compile time is generally sufficient to satisfy even the most complex path/branch (e.g., complex branch 304) through the shader 302 based on different possible constants 206. flexible enough The preamble shader 224 incorporates a GPR release mechanism 402 to determine the number of GPRs 218 required for shader execution since the deallocation of unnecessary GPRs 218 occurs at the initial execution time of the main shader 226. It may be a natural position to do. However, the GPR release mechanism 402 reduces GPR allocations thereby allowing more threads/pixels to run concurrently, improving latency concealment, and/or increasing the efficiency of both shaders 302 and system memory. are not limited to integration within the preamble shader 224 to

5 is a flowchart of an example method 500 of GPR deallocation in accordance with one or more techniques of this disclosure. Method 500 may be performed by a GPU, CPU, command processor, apparatus for graphics processing, wireless communication device, or the like as used in connection with the examples of FIGS. 1-4 .

At 502, the preamble shader may fetch defined constants (eg, to perform the method of GPR deallocation). For example, referring to FIG. 2 , preamble shader 224 running on shader core 216 can fetch constant 206 from graphics API 204 . The method of GPR deallocation may be performed by the preamble shader within the executable shader and before the main part of the executable shader when executed by the GPU. Additionally or alternatively, the method of GPR deallocation may be performed within a main part of an executable shader when executed by a GPU and may be applied to subsequent calls of the main part of an executable shader within a draw call. For example, referring to FIG. 2 , the preamble shader 224 and/or the main shader 226 may be executed on the shader core 216 of the GPU 212 to perform a method of de-allocating the GPR. In a further configuration, the method of de-allocating the GPR may be performed by a command processor within the GPU. For example, referring to FIG. 2 , command engine 214 can execute commands from the command stream on GPU 212 to perform the method of GPR deallocation.

At 504, the defined constants may be stored in a local constant buffer accessible within the executable shader. For example, referring to FIG. 2 , constant 206 may be stored in constant memory 220 accessible to shader core 216 . In additional aspects, constant 206 may be stored in GPU memory 222 .

At 506, the number of branches within the executable shader can be determined. For example, referring to FIG. 2 , the number of branches is determined by GPU 212 based on different values of constants 206 that may be used in the execution of preamble shader 224 and/or main shader 226. can be determined Constants may be undefined when compiling an executable shader. Thus, constants 206 that may be used by an executable shader may assume values not determined by the shader compiler 208 at compile time, but may be determined by the executable shader at runtime.

At 508, a GPR may be assigned based on the number of branches determined. For example, referring to FIG. 2 , GPR 218 can be assigned to shader core 216 to execute branches of preamble shader 224 and/or main shader 226 . When the de-allocation of a GPR is to be performed, the number of GPRs in the allocated GPR may be de-allocated.

At 510, at least one unused branch within the executable shader may be determined based on the constants defined for the executable shader. For example, referring to FIG. 2 , the constant 206 fetched by the preamble shader 224 or the main shader 226 can be used to determine at least one unused branch in the main shader 226 .

At 512, the number of GPRs that can be de-assigned from the allocated GPRs based on the at least one unused branch can be determined. For example, referring to FIG. 4 , instructions 400 indicate that 16 GPRs may be deallocated from the 20 allocated GPRs, eg, based on a local constant of 0 indicating an unused branch. Determining the number of GPRs that can be deallocated based on the at least one unused branch may include determining a total number of GPRs required for execution of executable shaders if there is no at least one unused branch; and determining the number of GPRs that can be deallocated based on the number of allocated GPRs exceeding the determined total number of GPRs. For example, referring to FIG. 4, instruction 400 indicates that four GPRs may be required for execution of an executable shader when there are no complex branches. As such, instructions 400 may determine that 16 GPRs out of a total of 20 allocated GPRs exceed the 4 requested GPRs and may be de-allocated.

At 514, for a subsequent thread within the draw call, during execution of the executable shader based on the determined number of GPRs, the number of GPRs may be de-allocated from the allocated GPRs. For example, referring to FIG. 4 , instruction 400 indicates that 16 GPRs may be deallocated from the 20 allocated GPRs during execution of the executable shader, for subsequent threads in the draw call. In aspects, the number of GPRs may be deallocated prior to execution of an executable shader. For example, referring to FIG. 2 , GPR 218 may be deallocated by preamble shader 224 prior to execution of main shader 226 .

6 is a conceptual data flow diagram 600 illustrating data flow between different means/components in the example apparatus 602. Apparatus 602 may be a GPU, a command processor, an apparatus having executable shaders, a wireless communication device, or other similar apparatus.

Apparatus 602 includes a decision component 604 that can determine, after compilation of the executable shader, that a constant is undefined for the branch of the executable shader. Based on the undefined constant, the fetcher component 606 included in device 602 executes a system call to fetch the defined constant from CPU 650 . For example, as described with respect to 502 , fetcher component 606 can fetch constants defined via a preamble shader. Apparatus 602 includes a storage component 608 that receives constants from CPU 650 and stores the constants in a local constant buffer. For example, as described with respect to 504, the storage component 608 can store the defined constants in a local constant buffer accessible within the executable shader.

The determining component 604 can determine the total number of branches within the executable shader based on the constants retrieved from the local constant buffer. For example, as described with respect to 506, determining component 604 can determine the number of branches within an executable shader. Apparatus 602 further includes an assignment component 610 that can assign GPRs to executable shaders. For example, as described with respect to 508, allocation component 610 can allocate a GPR based on the determined number of branches.

After receiving the allocated GPRs, determining component 604 can determine the number of allocated GPRs to be deallocated based on the unused branches of the executable shader and the determined unused branches. For example, as described with respect to 510 , determining component 604 can determine at least one unused branch within an executable shader based on constants defined for the executable shader. As described with respect to 512 , determining component 604 can further determine a number of GPRs that can be deassigned from the allocated GPRs based on the at least one unused branch.

Apparatus 602 includes a deallocation component 612 that deallocates the GPR from an executable shader for a subsequent thread in the draw call. For example, as described with respect to 514, the deallocation component 612 may, for subsequent threads in the draw call, determine the number of GPRs from the allocated GPRs during execution of the executable shader based on the determined number of GPRs. can be deallocated.

Apparatus 602 may include additional components that perform each of the blocks of the algorithm in the aforementioned flowchart of FIG. 5 . As such, each block in the aforementioned flowchart of FIG. 5 may be performed by a component, and apparatus 602 may include one or more of these components. Components are one or more hardware components specifically configured to perform the stated processes/algorithms, or implemented by a processor (eg, logic and/or code executed by the processor) configured to perform the stated processes/algorithms; , stored in a computer readable medium for implementation by a processor, or some combination thereof.

It is understood that the specific order or hierarchy of blocks in the processes/flowcharts disclosed is an illustration of exemplary approaches. Based upon design preferences, it is understood that the specific order or hierarchy of blocks in the processes/flowcharts may be rearranged. Also, some blocks may be combined or omitted. The accompanying method claims present elements of the various blocks in a sample order, and are not intended to be limited to the specific order or hierarchy presented.

The previous description is provided to enable any person skilled in the art to practice the various aspects described herein. Various modifications to these aspects will be readily apparent to those skilled in the art, and the general principles defined herein may be applied to other aspects. Thus, the claims are not intended to be limited to the various aspects shown herein but are to be accorded the full scope consistent with the language of the claims and references to singular elements should be substituted for "one and only one" unless specifically stated so. ", but rather "one or more". The word "exemplary" is used herein to mean "serving as an example, instance, or illustration." Any aspect described herein as “exemplary” is not necessarily to be construed as advantageous or preferred over other aspects.

Unless specifically stated otherwise, the term “some” refers to one or more, and the term “or” may be interrupted as “and/or” when the context does not dictate otherwise. "At least one of A, B, or C", "At least one of A, B, or C", "At least one of A, B, and C", "At least one of A, B, and C", and " Combinations such as "A, B, C, or any combination thereof" include any combination of A, B, and/or C, and may include multiples of A, multiples of B, or multiples of C. may be Specifically, “at least one of A, B, or C”, “one or more of A, B, or C”, “at least one of A, B, and C”, “one or more of A, B, and C” , and combinations such as "A, B, C, or any combination thereof" may be only A, only B, only C, A and B, A and C, B and C, or A and B and C, , wherein any such combinations may include one or more members or members of A, B, or C. All structural and functional equivalents to elements of the various aspects described throughout this disclosure that are known, or will become known to those skilled in the art, are expressly incorporated herein by reference and are intended to be covered by the claims. Furthermore, nothing disclosed herein is intended to be dedicated to the public regardless of whether such disclosure is explicitly recited in the claims. The words "module", "mechanism", "element", "device" and the like may not be substitutes for the word "means". As such, no claim element should be construed as a means plus function unless that element is expressly recited using the phrase “means for”.

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 units may be implemented in hardware, software, firmware, or any combination thereof. If any function, processing unit, technology, or other module is implemented in software, the function, processing unit, technology, or other module may include one or more instructions or instructions on a computer-readable medium. It may be stored or transmitted as a code.

Computer readable media may include computer data storage media or communication media including any medium that facilitates transfer of a computer program from one place to another. In this manner, computer readable media may generally be: (1) tangible computer readable storage media that are non-transitory or (2) communication media such as signals or carrier waves. Data storage media may be any available media that can be accessed by one or more computers or one or more processors to retrieve instructions, code, and/or data structures for implementation of the techniques described in this disclosure. By way of example and not limitation, such computer readable media may include RAM, ROM, EEPROM, compact disc-read only memory (CD-ROM) or other optical disk storage, magnetic disk storage or other magnetic storage devices. . As used herein, disk and disc include compact discs (CDs), laser discs, optical discs, digital versatile discs (DVDs), floppy discs, and Blu-ray discs, where the disc Disks typically reproduce data magnetically, while discs typically reproduce data optically using lasers. Combinations of the above should also be included within the scope of computer readable media. A computer program product may include a computer readable medium.

The techniques of this disclosure may be implemented in a wide variety of devices or apparatuses, including a wireless handset, an integrated circuit (IC) or set of ICs, such as a chip set. Various components, modules, or units are described in this disclosure to emphasize functional aspects of devices configured to perform the disclosed techniques, but do not necessarily require realization by different hardware units. Rather, as described above, the various units may be combined in any hardware unit including one or more processors as described above along with suitable software and/or firmware or provided by a collection of interoperable hardware units. there is. Accordingly, the term “processor,” as used herein may refer to any of the foregoing structure or any other structure suitable for implementation of the techniques described herein. Also, the techniques may be implemented entirely in one or more circuits or logic elements.

Various examples have been described. These and other examples are within the scope of the following claims.

Claims (20)

As a method of deallocating a general register (GPR),
determining at least one unused branch within an executable shader based on constants defined for the executable shader;
determining the number of GPRs that can be de-allocated from the allocated GPRs based on the at least one unused branch; and
for a subsequent thread within a draw call, de-allocating the number of GPRs from the allocated GPRs during execution of the executable shader based on the determined number of GPRs. According to claim 1,
Determining the number of GPRs that can be deallocated based on the at least one unused branch comprises:
determining a total number of GPRs required for execution of the executable shader if there is no at least one unused branch; and
and determining the number of GPRs that can be deallocated based on the number of GPRs allocated in excess of the determined total number of GPRs. According to claim 1,
wherein the number of GPRs is deallocated prior to execution of the executable shader. According to claim 1,
wherein the method is performed by a preamble shader within the executable shader when executed by a graphics processing unit (GPU) and before a main portion of the executable shader. According to claim 4,
fetching the defined constants by the preamble shader; And
The method of GPR deallocation further comprising storing the defined constants in a local constant buffer accessible within the executable shader. According to claim 1,
The method of GPR deallocation, wherein the method is performed within the main part of the executable shader when executed by a graphics processing unit (GPU) and applied to subsequent invocations of the main part of the executable shader within the draw call. . According to claim 1,
wherein the method is performed by a command processor in a graphics processing unit (GPU). According to claim 1,
determining the number of branches within the executable shader; and
allocating GPRs based on the determined number of branches, further comprising allocating the GPRs, wherein the number of GPRs is de-allocated from the allocated GPRs. According to claim 1,
The method of GPR deallocation, wherein the constants are not defined at compile time of the executable shader. A device for general purpose register (GPR) deallocation,
Memory; and
at least one processor coupled to the memory;
The at least one processor,
determine at least one unused branch within the executable shader based on constants defined for the executable shader;
determine a number of GPRs that can be de-allocated from allocated GPRs based on the at least one unused branch; and
To, for a subsequent thread within a draw call, deallocate the number of GPRs from the allocated GPRs during execution of the executable shader based on the number of GPRs determined.
A device for de-allocating GPRs, which is configured. According to claim 10,
The at least one processor configured to determine the number of GPRs that can be deallocated based on the at least one unused branch also:
determine a total number of GPRs required for execution of the executable shader if there is no at least one unused branch; and
and determine the number of GPRs that can be deallocated based on the number of GPRs allocated in excess of the determined total number of GPRs. According to claim 10,
wherein the number of GPRs is deallocated prior to execution of the executable shader. According to claim 10,
wherein the action of the at least one processor is performed by a preamble shader within the executable shader when executed by a graphics processing unit (GPU) and before a main portion of the executable shader. According to claim 13,
The at least one processor also,
fetch, by the preamble shader, the defined constants; And
Apparatus for GPR deallocation, configured to store the defined constants in a local constant buffer accessible within the executable shader. According to claim 10,
the actions of the at least one processor are performed within the main part of the executable shader when executed by a graphics processing unit (GPU) and apply to subsequent invocations of the main part of the executable shader within the draw call; A device for de-allocating GPRs. According to claim 10,
The action of the at least one processor is performed by a command processor in a graphics processing unit (GPU). According to claim 10,
The at least one processor also,
determine a number of branches within the executable shader; and
Allocating GPRs based on the determined number of branches, wherein the number of GPRs is de-allocated from the allocated GPRs. According to claim 10,
A device for GPR deallocation, wherein the constants are not defined at compile time of the executable shader. According to claim 10,
The apparatus for deassigning a GPR, wherein the apparatus is a wireless communication device. A computer-readable storage medium storing computer-executable code,
The code, when executed by at least one processor, causes the at least one processor to:
determine at least one unused branch within an executable shader based on constants defined for the executable shader;
determine a number of GPRs that can be de-allocated from allocated GPRs based on the at least one unused branch; and
de-allocate the number of GPRs from the allocated GPRs during execution of the executable shader within a draw call based on the determined number of GPRs.

Images