Method and apparatus for facilitating dedicated unbound stateful processors

Abstract

The present disclosure relates to methods and apparatus for graphics processing. The techniques facilitate improved unbound state processing at a graphics processor. A shader program comprising a preamble and a main instruction portion may be received at the graphics processor. A scalar processor dedicated to processing the preamble may execute instructions in the preamble to implement an unbound mechanism for loading constant data associated with the shader program. The main instruction portion and the constant data may be distributed to stream processors for execution of the shader program.

Description

Technical Field

[0001] The present disclosure relates generally to processing systems and, more particularly, to one or more techniques for graphics processing. Background Art

[0002] Computing devices typically utilize a graphics processing unit (GPU) to accelerate the rendering of graphics data for display. Such computing devices may include, for example, computer workstations, mobile phones such as so-called smartphones, embedded systems, personal computers, tablet computers, and video game consoles. The GPU executes a graphics processing pipeline that includes one or more processing stages that operate together to execute graphics processing commands and output frames. A central processing unit (CPU) can control the operation of the GPU by issuing one or more graphics processing commands to the GPU. Modern CPUs are typically capable of executing multiple applications concurrently, each of which may require the use of a GPU during execution. Summary of the Invention

[0003] The following presents a simplified overview of one or more aspects in order to provide a basic understanding of these aspects. This overview is not an exhaustive overview of all contemplated aspects and is intended to neither identify key elements of all aspects nor delineate the scope of any or all aspects. Its sole purpose is to present some concepts of one or more aspects in a simplified form as a prelude to the more detailed description that is presented later.

[0004] In aspects of the present disclosure, a method, computer-readable medium, and apparatus are provided. The apparatus may be an application processor, a CPU, a GPU, a general-purpose GPU (GPGPU), a display processor, a display processing unit (DPU), or a video processor. The apparatus may receive a shader program at a graphics processor, the shader program including a preamble and a main instruction portion. The apparatus may also execute instructions in the preamble using a scalar processor dedicated to processing the preamble to implement a no-binding mechanism for loading constant data associated with the shader program. The apparatus may also distribute the main instruction portion and the constant data to a stream processor for executing the shader program. In some examples, the apparatus may also employ the same instruction set architecture (ISA) for the scalar processor and the stream processor. In some examples, the shader program may include an indicator indicating whether the scalar processor or the stream processor is to execute the instructions in the preamble. In some examples, the scalar processor may be configured to execute a subset of the functionality of the stream processor. In some examples, the apparatus may also implement the no-binding mechanism during runtime. In some examples, the apparatus may also load a first data subset from a first buffer. In some examples, the apparatus may also load a second data subset from a second buffer. In some examples, the device may further concatenate the first data subset and the second data subset into a third buffer. In some examples, the third buffer may include constant data. In some examples, the device may further retrieve instructions of the leading portion from the buffer. In some examples, the device may further decode the instructions of the leading portion. In some examples, the device may further retrieve one or more operands to execute the instructions of the leading portion. In some examples, the device may further perform flow control to execute the instructions of the leading portion. In some examples, the device may further execute the instructions of the leading portion based on the flow control. In some examples, the device may further store output data generated by executing the instructions of the leading portion in the buffer.

[0005] The details of one or more examples of the present disclosure are set forth in the accompanying drawings and the description below. Other features, objects, and advantages of the present disclosure will be apparent from the description and drawings, and from the claims. BRIEF DESCRIPTION OF THE DRAWINGS

[0006] Figure 1 is a block diagram illustrating an example content generation system in accordance with one or more techniques of this disclosure.

[0007] Figure 2 An example graphics processor is shown in accordance with one or more techniques of this disclosure.

[0008] Figure 3 An example implementation of a graphics processor that performs aspects of a graphics processing pipeline in accordance with one or more techniques of this disclosure is shown.

[0009] Figure 4 is a diagram illustrating one or more techniques according to the present disclosure. Figure 1 A block diagram of the components of the device.

[0010] Figure 5 A diagram illustrating a method for performing a multi-processor system according to one or more techniques of the present disclosure is shown. Figure 4 Example timeline of a GPU processing workload sequence.

[0011] Figure 6 A diagram illustrating a method for performing a multi-processor system according to one or more techniques of the present disclosure is shown. Figure 4 Another example timeline of a graphics processor processing workload sequence.

[0012] Figure 7 is a diagram illustrating one or more techniques according to the present disclosure. Figure 4 A block diagram of the components of an unbound state processor.

[0013] Figure 8 A diagram illustrating a method for performing a multi-processor system according to one or more techniques of the present disclosure is shown. Figure 4 Another example timeline of a graphics processor processing workload sequence.

[0014] Figure 9 is an example flow chart of an example method in accordance with one or more techniques of this disclosure. DETAILED DESCRIPTION

[0015] The example techniques disclosed herein facilitate performing resource-free processing at a graphics processor using scalar processing. Specifically, the disclosed techniques can be implemented by a processor-based device (such as a graphics processor) that utilizes a parallel processing unit (PPU), which is configured to perform many operations in parallel (e.g., simultaneously or nearly simultaneously). For example, a graphics processor may include one or more processor cores (e.g., stream processors) that execute instructions for one or more programs (sometimes referred to as "shader programs" or "shaders"). Although the following description provides examples for implementing one or more disclosed techniques using a GPU, the concepts described herein are applicable to other processor-based devices that employ parallel processing units and / or non-parallel processing units (e.g., processing units configured to perform parallel processing).

[0016] In some examples, a graphics processor can be implemented with a single instruction, multiple data (SIMD) architecture. In a SIMD architecture, a stream processor (sometimes referred to as a "shader processor") includes multiple processing elements that execute instructions of the same program but with different data. In some examples, a specific instruction executed on a specific processing element can be referred to as a "fiber" or "thread." Thus, although different processing elements of a stream processor can be considered to execute different fibers, different processing elements can still execute the same specific instruction. In this way, the SIMD architecture enables the graphics processor to perform many tasks in parallel (e.g., simultaneously or nearly simultaneously).

[0017] In general, the example techniques disclosed herein help improve the processing of unbound resources (e.g., resources requested at runtime). For example, a graphics processor may include a high-level sequencer (HLSQ) and one or more stream processors. The HLSQ may be configured to facilitate receiving a shader program including a leading portion and a main instruction portion. In a graphics processing example, a shader program may include drawing commands that are executed on multiple work items (e.g., pixels or vertices). In some such examples, the leading portion may be executed once in each drawing command, and the main instruction portion may be executed once in each work item (e.g., once per pixel or once per vertex). Therefore, it can be understood that for a shader program, the leading portion of the shader program will be executed at a different (e.g., lower) frequency than the main instruction portion. The one or more stream processors may be configured to execute the shader program. In some examples, the HLSQ may facilitate preparing the context state of the stream processor and provide the stream processor with resources for executing the shader program. The example techniques disclosed herein use an unbound state processor (BSP) with an HLSQ to prepare resources before providing them to the stream processor. In some examples, the BSP may be a processor dedicated to executing instructions to load unbound resources. For example, the BSP may execute instructions of a prologue portion of a shader program to load constant data for a corresponding context state of a stream processor. The BSP may store the constant data in a buffer of the HLSQ. After the instructions of the prologue portion are completed and the corresponding constant data is stored in the buffer, the HLSQ may then broadcast (e.g., distribute) the constant data and the main instruction portion of the shader program to one or more stream processors for executing the shader program.

[0018] Various aspects of the systems, devices, computer program products, and methods are described more fully below with reference to the accompanying drawings. However, the present disclosure can be embodied in many different forms and should not be construed as limited to any specific structure or function presented throughout the present disclosure. On the contrary, these aspects are provided so that the present disclosure will be thorough and complete, and will fully convey the scope of the present disclosure to those skilled in the art. Based on the teachings herein, it should be understood by those skilled in the art that the scope of the present disclosure is intended to cover any aspect of the systems, devices, computer program products, and methods disclosed herein, whether implemented independently of or in combination with other aspects of the present disclosure. For example, any number of aspects set forth herein may be used to implement a device or practice method. In addition, the scope of the present disclosure is intended to cover a device or method that is practiced using other structures, functions, or structures and functions outside or in addition to the various aspects of the present disclosure described herein. Any aspect disclosed herein may be embodied by one or more elements of a claim.

[0019] Although various aspects are described herein, many variations and permutations of these aspects fall within the scope of this disclosure. Although some potential benefits and advantages of various aspects of this disclosure are mentioned, the scope of this disclosure is not intended to be limited to a particular benefit, use, or objective. On the contrary, aspects of this disclosure are intended to be broadly applicable to different wireless technologies, system configurations, networks, and transmission protocols, some of which are illustrated by way of example in the drawings and the following description. The detailed description and drawings are merely illustrative of the disclosure and are not limiting, and the scope of this disclosure is defined by the appended claims and their equivalents.

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

[0021] 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 (also 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 a chip (SOCs), baseband processors, application-specific integrated circuits (ASICs), field programmable gate arrays (FPGAs), programmable 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 a processing system can execute software. Software can be broadly interpreted to mean instructions, instruction sets, codes, code segments, program codes, programs, subroutines, software components, applications, software applications, software packages, routines, subroutines, objects, executable files, execution threads, processes, functions, etc., whether referred to as software, firmware, middleware, microcode, hardware description languages, or other. The term application can refer to software. As described herein, one or more technologies may refer to an application (such as software) configured to perform one or more functions. In such an example, the application may be stored on a memory (e.g., on-chip memory of a processor, system memory, or any other memory). The hardware described herein, such as a processor, may be configured to execute an application. For example, an application may be described as including code that causes the hardware to perform one or more technologies described herein when executed by the hardware. As an example, the hardware may access code from the memory and execute the code accessed from the memory to perform one or more technologies described herein. In some examples, components are identified in this disclosure. In such an example, the components may be hardware, software, or a combination thereof. These components may be separate components or subcomponents of a single component.

[0022] Therefore, in one or more examples described herein, the functions described can be implemented in hardware, software, or any combination thereof. If implemented in software, these functions can be stored on a computer-readable medium or encoded as one or more instructions or codes on a computer-readable medium. Computer-readable media include computer storage media. Storage media can be any available medium that a computer can access. As an example and not limitation, such computer-readable media can include random access memory (RAM), read-only memory (ROM), electrically erasable programmable ROM (EEPROM), optical disk storage, magnetic disk storage, other magnetic storage devices, a combination of computer-readable media of the above types, or any other medium that can be used to store computer-executable code in the form of computer-accessible instructions or data structures.

[0023] In general, examples disclosed herein provide techniques for improving the performance of operations in a graphics processor. Example techniques can improve the performance of executing shader programs with a graphics processor by enabling efficient loading of unbound resources (e.g., unbound constant buffers) that can be accessed during execution of a shader program and / or reducing the load on a processing unit (e.g., any processing unit configured to perform one or more techniques disclosed herein, such as a GPU, application processor, CPU, display processor, DPU, etc.). For example, the present disclosure describes techniques for graphics processing in any device that uses hardware to facilitate loading of unbound resources. Other example benefits are also described throughout this disclosure.

[0024] As used herein, instances of the term "content" may refer to "graphics content," "images," and vice versa. This is true regardless of whether these terms are used as adjectives, nouns, or other parts of speech. In some examples, as used herein, the term "graphics content" may refer to content produced by one or more processes of a graphics processing pipeline. In some examples, as used herein, the term "graphics content" may refer to content produced by a processing unit configured to perform graphics processing. In some examples, as used herein, the term "graphics content" may refer to content produced by a graphics processor. In some examples, as used herein, a graphics processor may be any device capable of processing graphics content (e.g., an application processor, a CPU, a display processor, a DPU, etc.) and / or any device designed to perform graphics processing (e.g., a GPU).

[0025] In some examples, 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. Graphics content may be processed to become display content. For example, a graphics processor may output graphics content, such as a frame, to a buffer (which may be referred to as a frame buffer). A display processor (or DPU) may read graphics content, such as one or more frames, from the buffer and perform one or more display processing techniques on it to generate display content. For example, a display processor may be configured to perform compositing on one or more rendering layers to generate a frame. As another example, a display processor may be configured to compose, blend, or otherwise combine two or more layers into a single frame. The display processor may be configured to perform scaling on a frame, such as upscaling or downscaling. In some examples, a frame may refer to a layer. In some examples, a frame may refer to two or more layers that have been blended together to form a frame (e.g., a frame includes two or more layers), and the frame including the two or more layers may then be blended.

[0026] Figure 1is a block diagram illustrating an example content generation system 100 configured to implement one or more techniques of this disclosure. Content generation system 100 includes device 104. Device 104 may include one or more components or circuits for performing the various functions described herein. In some examples, one or more components of device 104 may be components of a system-on-chip (SoC). Device 104 may include one or more components configured to perform one or more techniques of this disclosure. In the example shown, device 104 includes a processing unit 120 and a memory 124. In some examples, device 104 may include multiple additional or alternative components, such as a communication interface 126, a transceiver 132, a receiver 128, a transmitter 130, and a display client 131.

[0027] Processing unit 120 may include internal memory 121. Processing unit 120 may be configured to perform graphics processing, such as in graphics processing pipeline 107. Example implementations of graphics processing pipeline 107 may facilitate rendering (or drawing) graphics content to a display, such as example display client 131. In some examples, processing unit 120 may additionally or alternatively be configured to perform non-graphics processing, such as in compute processing pipeline 108. Example implementations of compute processing pipeline 108 may facilitate performing general-purpose operations or non-graphics operations, such as machine learning operations.

[0028] In some examples, processing unit 120 may include a display processor to perform one or more display processing techniques on one or more frames generated by processing unit 120 before display client 131 presents the generated frames. The display processor may be configured to perform display processing. For example, the display processor may be configured to perform one or more display processing techniques on one or more frames generated by processing unit 120. The display processor may output image data to display client 131 according to an interface protocol, such as, for example, MIPI DSI (Mobile Industry Processor Interface, Display Serial Interface).

[0029] Display client 131 may be configured to display or otherwise present frames processed by processing unit 120 (and / or display processor). In some examples, display client 131 may include one or more of 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 other type of display device.

[0030] References to display client 131 may refer to one or more displays. For example, display client 131 may include a single display or multiple displays. Display client 131 may include a first display and a second display. In further examples, the results of graphics processing may not be displayed on a device. For example, a display may not receive any frames for rendering on it. Instead, the frames or graphics processing results may be transmitted to another device. In some examples, transmitting the frames or graphics processing results to another device may be referred to as split rendering.

[0031] As described above, display client 131 can be configured according to the MIPI DSI standard. The MIPI DSI standard supports video mode and command mode. In an example where display client 131 operates in video mode, processing unit 120 (and / or display processor) can continuously refresh the graphics content of display client 131. For example, the entire graphics content of a frame can be refreshed at each refresh cycle (e.g., line by line).

[0032] In examples where display client 131 operates in command mode, processing unit 120 (and / or display processor) may write the graphics content of a frame to a buffer. In some examples, display client 131 may include a buffer, and thus, the buffer may represent local memory of display client 131. In some such examples, processing unit 120 (and / or display processor) may not continuously refresh the graphics content of display client 131. Instead, processing unit 120 (and / or display processor) may use vertical synchronization (Vsync) pulses to coordinate the presentation and consumption of graphics content at the buffer. For example, when a Vsync pulse is generated, processing unit 120 (and / or display processor) may output new graphics content to the buffer. Thus, the generation of a Vsync pulse may indicate when the current graphics content at the buffer has been rendered.

[0033] Processing unit 120, display client 131, and / or communication interface 126 can access memory external to processing unit 120, such as memory 124. For example, processing unit 120 can be configured to read from and / or write to external memory, such as memory 124. Processing unit 120, display client 131, and / or communication interface 126 can be communicatively coupled to memory 124 via a bus. In some examples, processing unit 120, memory 124, communication interface 126, and / or display client 131 can be communicatively coupled to each other via a bus or different connections.

[0034] In some examples, device 104 may include a content encoder / decoder configured to receive graphics and / or display content from any source, such as memory 124 and / or communication interface 126. Memory 124 may be configured to store received encoded content or decoded content. In some examples, the content encoder / decoder may be configured to receive encoded content or decoded content (e.g., from memory 124 and / or communication interface 126) in the form of encoded pixel data or decoded pixel data. In some examples, the content encoder / decoder may be configured to encode or decode any content.

[0035] Internal memory 121 and / or storage 124 may include one or more volatile or non-volatile memory or storage devices. In some examples, internal memory 121 and / or storage 124 may include RAM, SRAM, DRAM, erasable programmable ROM (EPROM), electrically erasable programmable ROM (EEPROM), flash memory, magnetic data media, optical storage media, or any other type of memory.

[0036] According to some examples, internal memory 121 and / or storage 124 may be non-transitory storage media. The term "non-transitory" may indicate that the storage medium is not embodied in a carrier wave or propagating signal. However, the term "non-transitory" should not be interpreted to mean that internal memory 121 and / or storage 124 are non-removable or that their contents are static. As an example, storage 124 may be removable from device 104 and moved to another device. As another example, storage 124 may not be removable from device 104.

[0037] Processing unit 120 may be a CPU, an application processor, a GPU, a general purpose GPU (GPGPU), a DPU, a display processor, or any other processing unit that may be configured to perform graphics processing and / or non-graphics processing (e.g., computational processing). In some examples, processing unit 120 may be integrated into the motherboard of device 104. In some examples, processing unit 120 may reside on a graphics card installed in a port in the motherboard of device 104, or may otherwise be incorporated into a peripheral device configured to interoperate with device 104. Processing unit 120 may include one or more processors, such as one or more microprocessors, CPUs, application processors, GPUs, DPUs, display processors, image signal processors (ISPs), application specific integrated circuits (ASICs), field programmable gate arrays (FPGAs), arithmetic logic units (ALUs), digital signal processors (DSPs), discrete logic, software, hardware, firmware, other equivalent integrated or discrete logic circuitry, or any combination thereof. If these techniques are implemented partially in software, the processing unit 120 may store instructions for the software in a suitable, non-transitory computer-readable storage medium (e.g., internal memory 121), and may execute these instructions in hardware using one or more processors to perform the techniques of this disclosure. Any of the above, including hardware, software, a combination of hardware and software, etc., may be considered to be one or more processors.

[0038] In some examples, the content generation system 100 may include a communication interface 126. The communication interface 126 may include a receiver 128 and a transmitter 130. The receiver 128 may be configured to perform any receiving functions described herein with respect to the device 104. In addition, the receiver 128 may be configured to receive information (e.g., eye or head position information, rendering commands, or position information) from another device. The transmitter 130 may be configured to perform any sending functions described herein with respect to the device 104. For example, the transmitter 130 may be configured to send information to another device, which information may include a request for content. The receiver 128 and the transmitter 130 may be combined into a transceiver 132. In such an example, the transceiver 132 may be configured to perform any receiving functions and / or sending functions described herein with respect to the device 104.

[0039] In some examples, graphical content from processing unit 120 for display via display client 131 may not be static and may change. Accordingly, processing unit 120 (and / or the display processor) may periodically refresh the graphical content displayed by display client 131. For example, processing unit 120 (and / or the display processor) may periodically retrieve graphical content from memory 124, where the graphical content may have been updated by the execution of an application (and / or processing unit 120) that outputs the graphical content to memory 124.

[0040] Reference again Figure 1 In some aspects, the processing unit 120 may be configured to operate one or more of the techniques disclosed herein. For example, the processing unit 120 may include a no-binding state processing component 198 configured to receive a shader program comprising a preamble portion and a main instruction portion at a graphics processor. The no-binding state processing component 198 may also be configured to execute instructions in the preamble portion using a scalar processor dedicated to processing the preamble portion to implement a no-binding mechanism for loading constant data associated with the shader program. The no-binding state processing component 198 may also be configured to distribute the main instruction portion and constant data to stream processors for executing the shader program. The no-binding state processing component 198 may also be configured to utilize the same instruction set architecture (ISA) at the scalar processors and the stream processors. The no-binding state processing component 198 may also be configured to implement the no-binding mechanism during runtime. The no-binding state processing component 198 may also be configured to load a first data subset from a first buffer. The no-binding state processing component 198 may also be configured to load a second data subset from a second buffer. The unbound state processing component 198 may also be configured to concatenate the first data subset and the second data subset into a third buffer. The unbound state processing component 198 may also be configured to retrieve a leading portion of the instruction from the buffer. The unbound state processing component 198 may also be configured to decode the leading portion of the instruction. The unbound state processing component 198 may also be configured to retrieve one or more operands for executing the leading portion of the instruction. The unbound state processing component 198 may also be configured to perform flow control to execute the leading portion of the instruction. The unbound state processing component 198 may also be configured to execute the leading portion of the instruction based on the flow control. The unbound state processing component 198 may also be configured to store output data generated by executing the leading portion of the instruction in the buffer.

[0041] 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, a base station, a user device, a client device, a station, an access point, a computer (e.g., a personal computer, a desktop computer, a laptop computer, a tablet computer, a computer workstation, or a mainframe computer), an end product, an apparatus, a phone, a smartphone, a server, a video game platform or console, a handheld device (e.g., a portable video game device or a personal digital assistant (PDA)), a wearable computing device (e.g., a smartwatch, an augmented reality device, or a virtual reality device), a non-wearable device, a display or display device, a television, a television set-top box, an intermediate network device, a digital media player, a video streaming device, a content streaming device, an in-vehicle computer, any mobile device, any device configured to generate graphical content, or any device configured to perform one or more of the techniques described herein. The processes herein may be described as being performed by a specific component (e.g., a GPU), but in further embodiments, may be performed using other components (e.g., an application processor or a CPU) consistent with the disclosed embodiments.

[0042] The graphics processor can process multiple types of data or data packets in the graphics pipeline. For example, in some examples, the graphics processor can process two types of data or data packets (e.g., context register packets and draw call data). The context register packet can be a collection of global state information (e.g., information about global registers, shader programs, or constant data) that can regulate how the graphics context is processed. For example, the context register packet may include information about the color format. In some examples, the context register packet may include a bit indicating which workload belongs to the context register. In addition, multiple functions or programming can be run simultaneously and / or in parallel. For example, a function or programming can describe a specific operation (e.g., a color mode or color format). Therefore, the context register can define multiple states of the graphics processor.

[0043] The context state can be used to determine how a single processing unit (e.g., a vertex fetcher (VFD), a vertex shader (VS), a shader processor, or a geometry processor) operates, and / or in which mode the processing unit operates. To this end, the graphics processor can use, for example, context registers and programming data. In some examples, the graphics processor can generate a workload (e.g., a vertex workload or a pixel workload) in the pipeline based on the context register definition of the mode or state. Certain processing units (e.g., VFDs) can use these states to determine certain functions, such as how to assemble vertices. When these modes or states can change, the graphics processor can change the corresponding context. In addition, the workload corresponding to the mode or state can follow the changed mode or state (e.g., the workload can be received after the mode or state is changed).

[0044] Figure 2 An example graphics processor 200 is shown in accordance with one or more techniques of this disclosure. Figure 2 As shown, the graphics processor 200 includes a command processor (CP) 210, a draw call group 212, a VFD 220, a VS 222, a vertex cache (VPC) 224, a triangle setup engine (TSE) 226, a rasterizer (RAS) 228, a Z processing engine (ZPE) 230, a pixel interpolator (PI) 232, a fragment shader (FS) 234, a rendering backend (RB) 236, an L2 cache (UCHE) 238, and a memory 240. Although Figure 2 The graphics processor 200 is shown to include processing units 220 through 238, but the graphics processor 200 may include a plurality of additional and / or alternative processing units. Furthermore, the processing units 220 through 238 are merely examples, and in accordance with the present disclosure, the graphics processor may utilize any combination or order of processing units. The example graphics processor 200 also includes a command buffer 250, a context register group 260, and a context state 261.

[0045] like Figure 2 As shown, the graphics processor can utilize a CP (e.g., CP 210 or a hardware accelerator) to parse a command buffer into context register packets (e.g., context register packet 260) and / or draw call data packets (e.g., draw call packet 212). CP 210 can then send context register packet 260 or draw call data packet 212 to a processing unit or block in the graphics processor via separate paths. Furthermore, command buffer 250 can alternate between different states of context registers and draw calls. For example, a command buffer can be structured as follows: context registers for context #N, draw calls for context N, context registers for context #N+1, and draw calls for context #N+1.

[0046] In some aspects, for each GPU processing unit or block, context registers may need to be prepared before any draw call data can be processed. Because context registers and draw calls can be serialized, it can be helpful to prepare an additional context register before the next draw call. In some cases, the draw call for the next context can be fed through the GPU data pipeline to hide the context register programming latency. Furthermore, when the GPU is equipped with multiple context register sets, each processing unit can have sufficient context switching capacity to manage smooth context handling. In turn, this can enable the GPU to cover pipeline latency that may be caused by unpredictable memory access latency and / or extended processing pipeline latency.

[0047] Figure 3 An example implementation of a graphics processor 300 that performs aspects of a graphics processing pipeline according to one or more techniques of this disclosure is shown. In some examples, one or more aspects of the graphics processor 300 may be implemented by Figure 1 The processing unit 120 and / or Figure 2 In some examples, Figure 3 One or more aspects of the graphics processing pipeline may be determined by Figure 1 The graphics processing pipeline 107 is implemented.

[0048] like Figure 3 As shown, the graphics processor 300 includes a command processor (CP) 310, a geometry processing front-end component 320, a vertex shader (VS) high-level sequencer (HLSQ) 330, VS stream processors 340a, 340b, 340c, 340d (collectively referred to herein as VS stream processors 340), a geometry processing back-end component 350, a fragment shader (FS) processing front-end component 360, a FS HLSQ 370, FS stream processors 380a, 380b, 380c, 380d (collectively referred to herein as FS stream processors 380), and a FS processing back-end component 390. Although Figure 3 The example graphics processor 300 includes four VS stream processors 340 and four FS stream processors 380 , but additional or alternative examples of graphics processors may include other suitable numbers of VS stream processors 340 and / or FS stream processors 380 .

[0049] The command processor 310 may be configured to receive a command stream representing operations to be performed by the graphics processor 300. The geometry processing front end component 320 may be configured to perform front-end operations related to geometry processing for the graphics processing pipeline. For example, the geometry processing front end component 320 may be configured to prepare vertex workloads for processing by the graphics processing pipeline (e.g., the geometry processing front end component 320 may retrieve vertex workloads from, for example, a memory such as a Figure 1In some examples, one or more aspects of the geometry processing front end component 320 may be provided by: Figure 2 220 implementations of VFD.

[0050] VS HLSQ 330 can be configured to receive vertex workloads and distribute the vertex workloads to one or more of VS stream processors 340. In some examples, VS HLSQ 330 can prepare contexts and resources for each VS stream processor 340 based on the vertex workloads. VS stream processors 340 can be configured to execute vertex shader programs to process the received vertex workloads. In some examples, one or more aspects of VS stream processors 340 can be handled by Figure 2 VS 222 implementation.

[0051] The geometry processing backend component 350 can be configured to perform further processing on the vertices output by the VS stream processor 340. For example, the geometry processing backend component 350 can be configured to perform edge coefficient calculations, shadow volume extrusion, etc. and / or store the processed vertex data in memory (e.g., in a vertex cache). In some examples, one or more aspects of the geometry processing backend component 350 can be implemented by Figure 2 VPC 224 implementation.

[0052] FS processing front-end component 360 can be configured to perform front-end operations related to fragment shader processing for the graphics processing pipeline. For example, FS processing front-end component 360 can be configured to prepare fragment shader workloads for processing by the graphics processing pipeline (e.g., FS processing front-end component 360 can set up triangles, tiles, etc.). In some examples, one or more aspects of FS processing front-end component 360 can be handled by Figure 2 226, RAS 228, ZPE 230 and / or PI 232 implementation.

[0053] FS HLSQ 370 can be configured to receive fragment shader workloads and distribute the fragment shader workloads to one or more of FS stream processors 380. In some examples, FS HLSQ 370 can prepare contexts and resources for each FS stream processor 380 based on the fragment shader workload. FS stream processors 380 can be configured to execute fragment shader programs to process the distributed fragment shader workload. In some examples, one or more aspects of FS stream processors 380 can be managed by Figure 2 Implementation of FS 234.

[0054] FS processing backend component 390 can be configured to perform further processing on the fragment data output by FS stream processor 380. For example, FS processing backend component 390 can be configured to perform pixel post-processing. In some examples, one or more aspects of FS processing backend component 390 can be implemented by Figure 2 The output of the FS processing backend component 390 can be stored in a memory such as Figure 2 Unified cache 238.

[0055] In some examples, the stream processors may be fixed-function stream processors configured to execute corresponding shader programs. For example, the VS stream processor 340 may be a fixed-function stream processor configured to execute a vertex shader program, and / or the FS stream processor 380 may be a fixed-function stream processor configured to execute a fragment shader program.

[0056] In some examples, the stream processors may be programmable stream processors that may be configured to execute one or more shader programs by loading corresponding shader programs into the programmable stream processors. For example, the graphics processor 300 (and / or the CP 310) may load a vertex shader program into a first stream processor (e.g., SP0 340a, 380a) to cause the first stream processor to execute the vertex shader program, may load a hull shader program into a second stream processor (e.g., SP1 340b, 380b) to cause the second stream processor to execute the hull shader program, may load a domain shader program into a third stream processor (e.g., SP2 340c, 380c) to cause the third stream processor to execute the domain shader program, may load a geometry shader program into a fourth stream processor (e.g., SP3 340d, 380d) to cause the fourth stream processor to execute the geometry shader program, and / or may load a fragment shader program into a first stream processor (e.g., SP0 340a, 380a) to cause the first stream processor to execute the fragment shader program. In some examples, a stream processor capable of executing different shader programs may be referred to as a "unified stream processor."

[0057] Therefore, despite the Figure 3380 are shown as separate components, but in some examples, the VS stream processor 340 and the FS stream processor 380 can be implemented by the same stream processor (e.g., a unified stream processor). For example, the GPU 300 (and / or the CP 310) can instruct the stream processors 340, 380 to perform different shading operations, such as vertex shading, hull shading, domain shading, geometry shading, fragment shading (sometimes referred to as "pixel shading"), by sending commands to the stream processors 340, 380 to execute one or more corresponding shader programs (sometimes referred to as "shaders"). A shader program may include one or more instructions that control the operation of the stream processors 340, 380 within the graphics processor 300. Example shader programs include a vertex shader program that can be executed by one or more of the stream processors 340, 380 to process received vertex data and attributes, a hull shader program that can be executed by one or more of the stream processors 340, 380 to generate tessellation factors and / or control points, a domain shader program that can be executed by one or more of the stream processors 340, 380 to create new vertices, a geometry shader program that can be executed by one or more of the stream processors 340, 380 to receive a primitive defined by its vertex data and further process the primitive (e.g., silhouette edge detection, shadow volume extrusion, etc.), a fragment shader program that can be executed by one or more of the stream processors 340, 380 to generate per-pixel data (e.g., color, texture blending, lighting model calculations, etc.), and the like.

[0058] In addition, despite Figure 3 370 can be implemented by the same HLSQ. For example, when the HLSQ receives workloads from front-end components (e.g., vertex workloads from the geometry processing front-end component 320 and / or fragment shader workloads from the FS processing front-end component 360), the HLSQ can determine which stream processors 340, 380 to distribute the respective workloads to. In some such examples, when the HLSQ receives vertex workloads, the HLSQ can be referred to as the VS HLSQ 330 and / or when the HLSQ receives fragment shader workloads, the HLSQ can be referred to as the FS HLSQ 370.

[0059] In some examples, the HLSQ can distribute workloads to fixed-function stream processors and / or unified stream processors. For example, in some examples, the HLSQ can distribute vertex workloads to fixed-function stream processors that are configured to execute vertex shader programs to process the vertex workloads. In some examples, the HLSQ can distribute vertex workloads to unified stream processors and can also load vertex shader programs to the unified stream processors so that the unified stream processors process the vertex workloads by executing the vertex shader programs.

[0060] Figure 4 is a diagram showing an aspect of the present disclosure Figure 1 A block diagram 400 of components of the device 104 is shown. Figure 4 In the illustrated example of FIG, block diagram 400 includes an application processor 410, a memory 420, and a graphics processor 430. In some examples, one or more aspects of application processor 410 and / or graphics processor 430 may be implemented by Figure 1 In some examples, one or more aspects of memory 420 may be implemented by Figure 1 The memory 124 and / or the internal memory 121 are implemented. Figure 4 As shown, the example application processor 410, the example memory 420, and the example graphics processor 430 communicate via the example bus 402. The example bus 402 may be implemented using any combination of bus structures and / or bus protocols.

[0061] exist Figure 4 In the illustrated example of , application processor 410 may include one or more processors configured to execute application 412 , graphics framework 414 , graphics driver 416 , and compiler 418 . Figure 4 The example memory 430 may be configured to store the command buffer 422 and the graphics data buffer 424. Figure 4 In the illustrated example of , graphics processor 430 may include one or more processors configured to execute a high level sequencer (HLSQ) 432 and one or more stream processors 434 .

[0062] In some examples, application processor 410 can be configured to execute instructions that cause application processor 410 to perform one or more of the example techniques disclosed herein. In some examples, memory 420 can store instructions that, when executed, cause application processor 410 and / or graphics processor 430 to perform one or more of the example techniques disclosed herein. In some examples, graphics processor 430 can be configured to execute instructions that cause graphics processor 430 to perform one or more of the example techniques disclosed herein.

[0063] In the example shown, application processor 410 can be configured to execute application 412. Application 412 can be an application (e.g., a graphics application) that offloads execution of graphics tasks (e.g., drawing commands) to graphics processor 430. For example, application 412 can issue instructions that cause graphics processor 430 to perform processing graphics tasks. In some examples, application 412 can store data used to process graphics tasks in graphics data buffer 424 of memory 420. For example, application 412 can store attributes of work items (e.g., pixels, vertices, etc.) in graphics data buffer 424.

[0064] In the example shown, graphics framework 414 may include one or more software frameworks that can be used with application 412. In some examples, graphics framework 414 may convert instructions received from application 412 into a format usable by graphics driver 416 to provide to graphics processor 430. In some examples, graphics framework 414 may include one or more application programming interfaces (APIs). Examples of graphics framework 414 may include OPENGL API, OPENGL ES API, DIRECTX API, and other graphics frameworks. In some examples, an operating system executing on application processor 410 may provide graphics framework 414 to application 412.

[0065] Graphics driver 416 receives instructions from application 412 via graphics framework 414 and controls the operation of graphics processor 430 to execute the instructions. For example, graphics driver 416 may generate one or more command streams, store the generated command streams in command buffer 422 of memory 420, and instruct graphics processor 430 to execute the command streams. In some examples, graphics driver 416 may communicate with graphics processor 430 via one or more system calls of an operating system executing on application processor 410.

[0066] Compiler 418 may be configured to compile one or more shader programs to be sent to and executed by graphics processor 430. A shader program may represent software and / or firmware executed by graphics processor 430 to implement a pipeline, such as Figure 1 4. In some examples, compiler 418 may pre-compile shader programs and store the pre-compiled shader programs in memory 420. In some examples, compiler 418 may compile shader programs during runtime (e.g., during execution of application 412).

[0067] In the illustrated example, memory 420 includes a command buffer 422 and a graphics data buffer 424. Command buffer 422 may be configured to record one or more commands and / or shader programs received from application processor 410. Example graphics data buffer 434 may be configured to store data generated by application 412 and usable by graphics processor 430 during the processing of a graphics task. In some examples, graphics data buffer 434 may include multiple different constant buffers generated by application 412. For example, a graphics task may include the transformation of objects (e.g., pixels or vertices). To facilitate the execution of the transformation, application 412 may generate a first buffer to store constant data associated with different colors, a second buffer to store constant data associated with different shapes, a third buffer to store constant data associated with different angles, and so on. In some such examples, application 412 may store one or more different buffers in graphics data buffer 434. Graphics processor 430 may read the data stored in graphics data buffer 434 to perform a graphics task and may also store output data generated by performing the graphics task in graphics data buffer 434. It should be appreciated that in some examples, application processor 410 may read output data generated by graphics processor 430 and stored in graphics data buffer 434 .

[0068] In the illustrated example, graphics processor 430 includes HLSQ 432 to receive workloads associated with graphics tasks and distribute the workloads to one or more stream processors 434 of graphics processor 430. In some examples, HLSQ 432 prepares context states and resources for stream processors 434. For example, HLSQ 432 can set up global register context state, shader constant context state, buffer descriptor context state, instruction context state, etc. for stream processors 434.

[0069] In the example shown, the stream processor 434 may include one or more processing elements, such as one or more arithmetic logic units (ALUs), one or more elementary logic units (EFUs), one or more full-precision ALUs (FALUs), and / or one or more half-precision ALUs (HALUs). In some examples, the stream processor 434 may be a programmable stream processor that is a fixed-function stream processor. Although Figure 4 The illustrated example includes two stream processors, but in additional or alternative examples, graphics processor 430 may include another suitable number of stream processors.

[0070] The programmable stream processor may include, for example, a programmable shader unit configured to execute one or more shader programs downloaded (e.g., from application processor 410 and / or memory 420) to graphics processor 430. In some examples, the shader program may be a compiled version of a program written in a shading language. In some examples, the programmable shader unit may include a vertex shader unit, a fragment shader unit, a compute shader unit, etc.

[0071] The fixed-function stream processor may include hardware that is hardwired to perform certain functions. In some examples, the fixed-function stream processor may additionally or alternatively include a freely programmable shader-controlled pipeline that enables the fixed-function stream processor to perform some configurable functions. Although the fixed-function stream processor can be configured to perform different functions (e.g., via one or more control signals), the fixed-function hardware may not include program memory capable of receiving user-compiled programs (e.g., from the application processor 410).

[0072] It should be appreciated that stream processors 434 allow for parallelization, which is at least one reason why it may be useful to perform graphics tasks via graphics processor 430. For example, each stream processor 434 of graphics processor 430 may be configured to perform the same operation, but on different data. In this way, the parallel processing structure of stream processors 434 allows graphics processor 430 to perform many operations in parallel (e.g., simultaneously), which may be useful in processing graphics tasks.

[0073] During execution, a graphics application (e.g., application 412) may create multiple buffers that can be used to process objects (e.g., graphics tasks). In some examples, the buffers may store constant data. For example, graphics processor 430 performing a transform task may include accessing different buffers storing constant data associated with different shapes, different colors, different angles, etc. Different types of constant data may be stored in different constant buffers. However, graphics processor 430 may not require all of the data in the different constant buffers to process the object.

[0074] To improve object processing, some techniques employ a binding mechanism to allocate (or "bind") resources for processing a particular object. For example, for a first object, the binding mechanism may include selecting a first data subset from a first buffer, selecting a second data subset from a second buffer, and then concatenating the first data subset and the second data subset into a third buffer. In some such examples, the third buffer may be used by graphics processor 430 to process the first object.

[0075] In some examples, the binding mechanism may be performed by graphics driver 416 of application processor 410. In some such examples, graphics driver 416 may instruct graphics processor 430 to perform the binding mechanism by providing the location of the data subset and the location for storing the third buffer to graphics processor 430. However, it should be understood that performance of the binding mechanism by graphics driver 416 is limited to instances where the data subset is static and therefore graphics processor 430 is able to provide the location of the data subset.

[0076] Figure 5 A diagram illustrating a method for performing a multi-processor system according to one or more techniques of the present disclosure is shown. Figure 4 5. An example timeline 500 of a graphics processor 430 processing a sequence of workloads is shown. In the example shown, the HLSQ 432 receives a workload for a series of context states (e.g., context state #N, context state #N+1, and context state #N+2). The HLSQ 432 processes the respective workloads and preloads instructions and constant data for the respective context states based on, for example, commands associated with a binding mechanism employed by the graphics driver. For example, at time T1, the HLSQ 432 preloads instructions and constant data for context state #N, at time T2, the HLSQ 432 preloads instructions and constant data for context state #N+1, and at time T4, the HLSQ 432 preloads instructions and constant data for context state #N+2. The HLSQ 432 may preload instructions and constant data for the respective context states from the graphics data buffer 426 into a buffer of the HLSQ 432. After loading resources (e.g., instructions and constant data) for a context state, the HLSQ 432 may broadcast (e.g., distribute) the resources to one or more stream processors 434 to facilitate execution of corresponding workloads. For example, after completing preloading of resource context state #N at time T2, the HLSQ 432 may broadcast the resources to the stream processors 434, which may then begin executing the workload of context state #N (e.g., drawing commands).

[0077] like Figure 5 As shown, after the stream processor 434 starts executing the workload of the context state, the HLSQ 432 can start preloading resources for the next context state. For example, even if the HLSQ 432 completes preloading resources for the context state #N+1 at time T3, the HLSQ 432 waits until the stream processor 434 starts executing the workload of the context state #N+1 (at time T4) to start preloading resources for the context state #N+2. It should be understood that Figure 5As shown, HLSQ 432 processes resources for workloads before stream processor 434, so once the resources are ready, stream processor 434 can begin processing the workload. In addition, it should be understood that the processing elements of stream processor 434 can be used continuously to execute workloads.

[0078] Reference again Figure 4 As the application evolves, control of the resources used to process the workload is transferred from the graphics driver 416 to the application 412. By enabling the application 412 to handle resource control, resources can be dynamically allocated during the runtime of the application. For example, unbound resources can be requested by the graphics processor 430 at runtime and are not assigned (or bound) to the processing of a specific object, as described above with respect to the binding mechanism. That is, compared to the binding mechanism, using the "unbound mechanism" can dynamically allocate resources. For example, the data subset to be selected from the buffer for processing the current workload may depend on the processing of the previous workload. As a result, the graphics driver 416 may not be able to provide the location to the graphics processor 430 for cascading data subsets.

[0079] However, the compiler 418 can compile the shader program to implement dynamic binding of resources. For example, the compiler 418 can determine that the application 412 may indicate a load operation for a cascaded buffer, but may not be able to identify which data subsets to use for binding the resources (e.g., the data subsets may be dynamically determined during runtime). In some such examples, the compiler 418 can compile the shader program to include a prologue portion that provides instructions for binding the resources during runtime. For example, the shader program prologue may include a first instruction for loading a first data subset from a first buffer, may include a second instruction for loading a second data subset from a second buffer, and may include a third instruction for concatenating the first and second data subsets and storing them in a constant buffer of the stream processor. When executing the shader program, the stream processor may first execute the shader program prologue to obtain constant data associated with the shader program, and once the constant data is loaded, the main instruction portion of the shader program may then be executed.

[0080] Figure 6 A diagram illustrating a method for performing a multi-processor system according to one or more techniques of the present disclosure is shown. Figure 4 Another example timeline 600 of a sequence of processing workloads by the graphics processor 430 of FIG. Figure 6 In the example shown, HLSQ 432 loads instructions for the context state from the graphics data buffer 426 of the memory 420. The HLSQ 432 can then provide the instructions for the context state to each of the stream processors. In the example shown, the instructions loaded by HLSQ 432 can represent a shader program including a shader program prologue and a main instruction portion of the shader program. Figure 6 As shown, the stream processor 434 may then execute instructions in the prologue of the shader program to load constant data and then execute the main instruction portion of the shader program.

[0081] For example, in Figure 6 In the illustrated example, at time T1, HLSQ 432 loads instructions for context state #N, at time T2, loads instructions for context state #N+1, and at time T4, loads instructions for context state #N+2. After loading the instructions for the context states, HLSQ 432 may broadcast (e.g., distribute) the instructions to one or more of the stream processors to facilitate execution of the corresponding workload. For example, after completing loading the instructions for context state #N, HLSQ 432 broadcasts the instructions (e.g., a shader program including a prologue portion and a main instruction portion) to stream processor 434 at time T2. Stream processor 434 then executes the instructions of the prologue portion of the received instructions (e.g., of the shader program) to load constant data for context state #N between time T2 and time T3. After loading the constant data (at time T3), stream processor 434 may then begin executing the main instruction portion of the received instructions (e.g., of the shader program) to facilitate execution of the workload (e.g., drawing commands) for context state #N.

[0082] like Figure 6 As shown, after the stream processor 434 begins executing instructions in the leading portion of the received instructions for the context state, the HLSQ 432 may begin loading instructions (e.g., a shader program) for the next context state. For example, the HLSQ 432 loads instructions for context state #N+1 between time T2 and time T3 while the stream processor 434 is executing instructions in the leading portion of the shader program for context state #N to load constant data for context state #N. Similarly, the HLSQ 432 waits to load instructions for context state #N+2 (e.g., a shader program for context state #N+2) until the stream processor 434 begins executing instructions in the leading portion of the shader program for context state #N+1 at time T4 to load constant data for context state #N+1.

[0083] Using the aforementioned aspects of the preamble of a shader program (e.g. Figure 6432 ) can include a number of different advantages. For example, the stream processor can load constant data from the graphics data buffer 424 to the constant buffer of the stream processor. Loading the constant data from the graphics data buffer 424 to the constant buffer of the stream processor 434 can be more processing and / or memory bandwidth efficient than loading the constant data from the graphics data buffer 424 to the buffer of the HLSQ 432 and then from the buffer of the HLSQ 432 to the constant buffer of the stream processor 434. In addition, including instructions for loading a subset of constant data in the prologue portion of the shader program rather than in the main instruction portion of the shader program can allow the constant data to be loaded from the graphics data buffer 424 once per graphics task (e.g., once per draw command) rather than once per work item (e.g., once per pixel or once per vertex), which can help improve processing and / or memory bandwidth efficiency.

[0084] However, if Figure 6 As shown, using the stream processor 434 to execute instructions of the prologue portion and the main instruction portion of the shader program results in serialized processing of constant data and workload. For example, the stream processor 434 executes instructions of the prologue portion of the shader program for context state #N between time T2 and time T3, then executes the main instruction portion of the shader program for context state #N between time T3 and time T4, then executes instructions of the prologue portion of the shader program for context state #N+1 between time T4 and time T5, then executes the main instruction portion of the shader program for context state #N+1 between time T5 and time T6, then executes instructions of the prologue portion of the shader program for context state #N+2 between time T6 and time T7, then executes the main instruction portion of the shader program for context state #N+2 at time T7, and so on.

[0085] Furthermore, loading constant data for context state may not be a resource-intensive task. For example, execution of the instructions of the preamble may be performed by a subset (e.g., one) of the processing elements of stream processor 434. In some such examples, the remaining processing elements of stream processor 434 may be idle, which may result in underutilization of resources of graphics processor 430.

[0086] Reference again Figure 4To improve the processing of unbound resources (e.g., resources requested at runtime), the example HLSQ 432 includes a unbound state processor 436 (e.g., a scalar processor) configured to operate on one work item at a time. In some examples, the unbound state processor (BSP) 436 can be a processor dedicated to executing instructions to load unbound resources. For example, the BSP 436 can be dedicated to processing the prologue portion and execute instructions of the prologue portion of the shader program to load constant data for the corresponding context state. The BSP 436 can load the constant data from the graphics data buffer 426 and can store the constant data in a buffer 438 of the HLSQ 432. After the BSP 436 completes executing the instructions of the prologue portion and stores the corresponding constant data in the buffer 438, the HLSQ 432 can then broadcast (e.g., distribute) the constant data and the main instruction portion of the shader program to one or more stream processors 434.

[0087] In the example shown, BSP 436 is a processor configured to execute instructions for processing the leading portion of a shader program. In particular, BSP 436 can implement the same instruction set architecture (ISA) as stream processor 434. An ISA generally defines instructions and / or operations that a processing circuit can parse and execute. In some examples, the ISA can be in the form of machine language instructions specific to the processing circuit (e.g., specific to BSP 436 and stream processor 434). By adopting the same ISA at BSP 436 and stream processor 434, the instructions leading to the shader program can be executed by either BSP 436 or stream processor 436 during runtime. For example, in some examples, BSP 436 can execute the instructions leading to the shader program, while in other examples, stream processor 434 can execute the instructions leading to the shader program. In some examples, the shader program can include an indicator (e.g., a flag or bit) to indicate whether BSP 436 or stream processor 434 will execute the instructions leading to the shader program. However, it should be understood that other techniques for indicating whether the BSP 436 or the stream processor 434 is to execute the instructions of the shader program prologue may be used in addition or instead.

[0088] In some examples, although BSP 436 and stream processor 434 may implement the same ISA, BSP 436 may be configured to perform a subset of the functionality of stream processor 434. For example, BSP 436 may be configured to perform functions related to processing of the preamble portion, and stream processor 434 may be configured to perform functions related to processing of the preamble portion and processing of the main instruction portion.

[0089] As described above, the prologue portion of the shader program can be executed once per graphics task (e.g., once per draw command or once for a context state), while the main instruction portion of the shader program can be executed once per work item (e.g., once per pixel, once per vertex, etc.). In this way, the load of constant data by the BSP 436 can be executed less frequently than the execution of instructions in the main instruction portion by the stream processor 434.

[0090] Figure 7 is a block diagram of a bound-free state processor (BSP) 700 according to aspects of the present disclosure. In the example shown, the BSP 700 can be any type of processor configured to operate on one work item at a time. For example, the BSP 700 can be a scalar processor. One or more aspects of the BSP 700 can be implemented by Figure 4 Implementation of BSP 436. Figure 7 In the example shown, BSP 700 includes a single-fiber scheduler 702 , a single-fiber context register 704 , a single-fiber load-store unit 706 , an unbound state cache 708 , unified general purpose registers (uGPRs) 710 , a scalar EFU 712 , and a scalar ALU 714 .

[0091] In the illustrated example, the single fiber scheduler 702 is configured to process different shader program preambles. For example, the single fiber scheduler 702 can be configured to process vertex shader program preambles, fragment (or pixel) shader program preambles, geometry shader program preambles, domain shader program preambles, hull shader program preambles, compute shader program preambles, and the like. In some examples, the single fiber scheduler 702 can be configured to control the execution of the scalar EFU 712 and / or scalar ALU 714 by, for example, instructing the scalar EFU 712 and / or scalar ALU 714 which functions to execute. For example, the single fiber scheduler 702 can facilitate the execution of instructions scheduled and managed by the scalar EFU 712 and / or scalar ALU 714. In some examples, the single-fiber scheduler 702 can be configured to fetch instructions from the buffer 438 and / or the unbound state cache 708 of the HLSQ 432, decode each instruction (if necessary), fetch operands (if necessary) for executing the instruction, and perform flow control for the single-fiber scheduler 702.

[0092] In the example shown, a single fabric context register 704 is configured to enable flow control within the BSP 700. In some examples, the single fabric context register 704 may include address registers, predicate registers, etc. to facilitate flow control.

[0093] In the example shown, the single-fiber load-store unit 706 is configured to control the loading of instructions and / or data into and from the BSP 700. For example, the single-fiber load-store unit 706 can interface with the graphics data buffer 426 of the memory 420 and / or the buffer 438 of the HLSQ 432 and load instructions into the unbound state cache 708 of the BSP 700. The single-fiber load-store unit 706 can also interface with the graphics data buffer 426 and load data from the graphics data buffer 426 into the memory of the BSP 700 (e.g., the unbound state cache 708 and / or the uGPR 710). The single-fiber load-store unit 706 can also write data into the buffer 438. For example, the single-fiber load-store unit 706 can retrieve constant data generated by executing a shader program prologue from the graphics data buffer 426 and store the retrieved constant data in the buffer 438.

[0094] In the example shown, the unbound state cache 708 is memory accessible by the scalar EFU 712 and the scalar ALU 714. In the example shown, the unbound state cache 708 is configured to store data accessible to the scalar EFU 712 and / or scalar ALU 714 executing an optical fiber.

[0095] In the example shown, uGPR 710 is memory accessible to various components of BSP 700. In the example shown, uGPR 710 includes scalar registers for storing one element at a time. uGPR 710 can store output data generated by scalar EFU 712 and / or scalar ALU 714, and can additionally or alternatively store input data provided to BSP 700 for processing (e.g., operands for performing arithmetic functions). In the example shown, uGPR 710 is configured to store data accessible to BSP 700 executing an optical fiber. For example, uGPR 710 can store input data used by scalar EFU 712 and / or scalar ALU 714 to execute an optical fiber, can store intermediate results generated by scalar EFU 712 and / or scalar ALU 714 during execution of an optical fiber, and / or can store output data generated by executing an optical fiber.

[0096] exist Figure 7In the illustrated example of , the scalar EFU 712 and the scalar ALU 714 may be execution units configured to perform operations on a single data slice. The scalar EFU 712 and / or the scalar ALU 714 may perform arithmetic operations (e.g., addition, subtraction, multiplication, division, etc.), logical operations (e.g., logical AND, logical OR, logical XOR, etc.), comparison operations (e.g., greater than function, less than function, equal to zero function, etc.), etc. The scalar EFU 712 and the scalar ALU 714 may perform (or execute) operations based on instructions received from the single-fiber scheduler 702. The instruction may include an operation identifier identifying the operation to be performed, operands for performing the operation, and a destination for storing the output of performing the operation. The scalar EFU 712 and the scalar ALU 714 may be configured to operate on one component (or attribute) at a time.

[0097] Figure 8 A diagram illustrating a method for performing a multi-processor system according to one or more techniques of the present disclosure is shown. Figure 4 Another example timeline 800 of a sequence of processing workloads by the graphics processor 430. Figure 8 In the illustrated example of , the HLSQ 432 loads instructions for the context state from the graphics data buffer 426 of the memory 420. In the illustrated example, the instructions loaded by the HLSQ 432 may represent a shader program including a shader program prologue and a main instruction portion of the shader program. The BSP 436 may then execute the instructions of the shader program prologue to facilitate loading constant data from the graphics data buffer 426 to the buffer 438 of the HLSQ 432. The HLSQ 432 may then provide the loaded resources (e.g., load instructions and constant data of the shader program) to the respective stream processors in the stream processors for processing. Figure 8 As shown, the HLSQ 432 and BSP 436 facilitate loading resources for the workload and then provide the resources to the stream processor 434 for processing.

[0098] For example, at time T1, HLSQ 432 loads instructions for context state #N (e.g., a shader program including a prologue portion and a main instruction portion). At time T2, BSP 436 may execute the instructions of the prologue portion of the shader program and load constant data for context state #N. For example, BSP 436 may load constant data from graphics data buffer 426 and store the constant data at buffer 438 of HLSQ 432. After loading the constant data, then at time T3, HLSQ 432 may broadcast (e.g., distribute) resources for context state #N to stream processor 434. For example, HLSQ 432 may provide the main instruction portion of the shader program and the constant data for context state #N to stream processor 434. At time T3 (or shortly thereafter), stream processor 434 may begin executing the workload (e.g., drawing commands) for context state #N using the received main instruction portion and constant data of the shader program. HLSQ 432 may also begin loading instructions for context state #N+1 (eg, a shader program including a prologue portion and a main instruction portion).

[0099] At time T4, BSP 436 may execute the instructions of the prologue portion of the shader program and load constant data for context state #N+1. For example, BSP 436 may load the constant data from graphics data buffer 426 and store the constant data at buffer 438 of HLSQ 432. In the example shown, after loading the constant data (at time T5), HLSQ 432 waits for stream processor 434 to complete executing the workload of context state #N (at time T6) before broadcasting the resources for context state #N+1. For example, HLSQ 432 may provide the main instruction portion of the shader program and the constant data for context state #N+1 to stream processor 434. At time T6 (or shortly thereafter), stream processor 434 may begin executing the workload of context state #N+1 (e.g., drawing commands) using the received main instruction portion and constant data of the shader program. HLSQ 432 may also begin loading instructions for context state #N+2 (e.g., a shader program including the prologue portion and the main instruction portion).

[0100] At time T7, BSP 436 may execute instructions of the prologue portion of the shader program and load constant data for context state #N+2. For example, BSP 436 may load the constant data from graphics data buffer 426 and store the constant data at buffer 438 of HLSQ 432. In the example shown, after loading the constant data (at time T8), HLSQ 432 waits for stream processor 434 to complete executing the workload of context state #N (at time T9) before broadcasting resources for context state #N+2. For example, HLSQ 432 may provide the main instruction portion of the shader program and the constant data for context state #N+2 to stream processor 434. At time T9 (or shortly thereafter), stream processor 434 may begin executing the workload of context state #N+2 (e.g., drawing commands) using the received main instruction portion of the shader program and the constant data.

[0101] The aforementioned aspects of employing BSP 436 to facilitate the execution of the preamble portion of a shader program can include many different advantages. For example, by providing BSP 436 as a component of HLSQ 432, BSP 436 can facilitate the efficient loading of unbound constant data for executing workloads. For example, execution of the shader program preamble by a dedicated unbound state processor enables efficient execution of the instructions of the shader program preamble and also avoids situations where the processing or memory bandwidth of the graphics processor 430 cannot be efficiently utilized. BSP 436 also allows loading of unbound constant data as early as possible (e.g., before broadcasting resources to the stream processor 434), which enables HLSQ 432 and BSP 436 to manage state processing of the shader program and enables the stream processor to perform workload processing. In addition, by employing scalar and single-fiber components, BSP 436 can be a resource-efficient addition to the graphics processor 430. For example, the physical area and hardware cost of BSP 436 can be relatively minimal. Additionally, since the BSP 436 and the stream processor 432 utilize the same ISA, the software cost of implementing the BSP 436 can also be relatively minimal.

[0102] Figure 9 An example flow chart 900 of an example method according to one or more techniques of this disclosure is shown. The method may be performed by, for example, Figure 1 devices 104, graphics processors (e.g., CPU, application processor, DPU, display processor, GPU, video processor, etc.), and / or such Figure 1 The components of the processing unit 120 of the device 104 are executed.

[0103] At 902, the apparatus may receive a shader program at a graphics processor, the shader program including a prologue portion and a main instruction portion, such as in conjunction with Figures 1 to 7 and / or Figure 8 For example, HLSQ 432 can load a shader program.

[0104] At 904, the apparatus may execute instructions of the preamble using a scalar processor dedicated to processing the preamble to load constant data associated with the shader program, such as in conjunction with Figures 1 to 7 and / or Figure 8 For example, BSP 436 may execute the instructions in the leading portion. In some examples, executing the instructions in the leading portion may include retrieving the instructions in the leading portion from a buffer, decoding the instructions in the leading portion, retrieving one or more operands to execute the instructions in the leading portion, performing flow control to execute the instructions in the leading portion, executing the instructions in the leading portion based on the flow control, and storing output data generated by executing the instructions in the leading portion in the buffer.

[0105] At 906, the apparatus may execute the instructions of the leading portion by implementing a no-binding mechanism, such as in conjunction with Figures 1 to 7 and / or Figure 8 For example, implementing the no-binding mechanism may include loading a first data subset from a first buffer, loading a second data subset from a second buffer, and concatenating the first data subset and the second data subset into a third buffer.

[0106] At 908, the apparatus may distribute the main instruction portion and constant data of the shader program to the stream processors for executing the shader program, such as in conjunction with Figures 1 to 7 and / or Figure 8 For example, the HLSQ 432 may distribute the main instruction portion and constant data from the buffer 438 to the stream processor 434 to execute the main instruction portion of the shader program.

[0107] In one configuration, a method or apparatus for graphics processing is provided. The apparatus may be a processing unit, a GPU, an application processor, a CPU, a display processor, a display processing unit (DPU), a video processor, or some other processor capable of performing graphics processing. In some examples, the apparatus may be a processing unit 120 within a device 104, or may be some other hardware within the device 104 or another device. The apparatus may include components for receiving a shader program at a graphics processor, the shader program including a preamble and a main instruction portion. The apparatus may also include components for executing instructions in the preamble with a scalar processor dedicated to processing the preamble to implement a no-binding mechanism for loading constant data associated with the shader program. The apparatus may also include components for distributing the main instructions and constant data to stream processors for executing the shader program. The apparatus may also include components for employing the same instruction set architecture (ISA) at the scalar processor and the stream processor. The apparatus may also include components for implementing the no-binding mechanism during runtime. The apparatus may also include components for loading a first subset of data from a first buffer. The apparatus may also include components for loading a second subset of data from a second buffer. The apparatus may further include means for concatenating the first subset of data and the second subset of data into a third buffer.

[0108] The apparatus may further include means for retrieving instructions in the preamble from a buffer. The apparatus may further include means for decoding instructions in the preamble. The apparatus may further include means for retrieving one or more operands for executing instructions in the preamble. The apparatus may further include means for performing flow control to execute instructions in the preamble. The apparatus may further include means for executing instructions in the preamble based on flow control. The apparatus may further include means for storing output data generated by executing instructions in the preamble in a buffer.

[0109] The subject matter described herein can be implemented to achieve one or more benefits or advantages. For example, the described graphics processing techniques can be used by a graphics processor (e.g., a GPU, an application processor, a CPU, a display processor, a DPU, a video processor, or some other processor that can perform graphics processing) to implement improvements in unbound state processing at the graphics processor, reduce the load on a processing unit (e.g., any processing unit configured to perform one or more of the techniques disclosed herein, such as a graphics processor), and / or reduce the power consumption of the processing unit.

[0110] According to the present disclosure, the term "or" can be interpreted as "and / or" unless the context dictates otherwise. In addition, although phrases such as "one or more" or "at least one" may be used for some features disclosed herein but not for other features, features that do not use such language can be interpreted as having such meanings implicitly unless the context dictates otherwise.

[0111] In one or more examples, the functionality described herein may be implemented in hardware, software, firmware, or any combination thereof. For example, although the term "processing unit" has been used throughout this disclosure, such a processing unit may be implemented in hardware, software, firmware, or any combination thereof. If any functionality, processing unit, technique, or other module described herein is implemented in software, the functionality, processing unit, technique, or other module described herein may be stored on or transmitted over a computer-readable medium as one or more instructions or code. Computer-readable media may include computer data storage media or communication media, including any media that facilitates the transfer of a computer program from one place to another. In this manner, a computer-readable medium may generally correspond to (1) a non-transitory, tangible computer-readable storage medium or (2) a communication medium such as a signal or carrier wave. A 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 techniques described in this disclosure. By way of example and not limitation, such computer-readable media may include RAM, ROM, EEPROM, CD-ROM or other optical disk storage, magnetic disk storage, or other magnetic storage devices. Disk and disc, as used herein, include compact disc (CD), laser disc, optical disc, digital versatile disc (DVD), floppy disk, and Blu-ray disc. Disks generally reproduce data magnetically, while discs reproduce data optically using lasers. Combinations of the above are also intended to be included within the scope of computer-readable media. A computer program product may include computer-readable media.

[0112] 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 or discrete logic circuits. Thus, the term "processor," as used herein, may refer to any of the aforementioned structures or any other structure suitable for implementing the techniques described herein. Furthermore, these techniques may be fully implemented in one or more circuits or logic elements.

[0113] The technology of the present disclosure can be implemented in a variety of devices or apparatuses, including wireless handsets, integrated circuits (ICs) or IC collections, such as chip collections. Various components, modules or units are described in this disclosure to emphasize the functional aspects of devices configured to perform the disclosed technology, but they do not necessarily need to be implemented by different hardware units. Instead, as described above, the various units can be combined in any hardware unit, or provided by a collection of interoperable hardware units (including one or more processors as described above) together with appropriate software and / or firmware.

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

Claims

1. A method for performing graphics processing, comprising: Receiving, at a graphics processor, a shader program comprising a prologue portion and a main instruction portion; executing instructions of the preamble with a scalar processor dedicated to processing the preamble to implement a no-bind mechanism for loading constant data associated with the shader program; as well as Distributing the main instruction portion and the constant data to a stream processor for executing the shader program, The implementation of the non-binding mechanism includes: loading a first subset of data from a first buffer; loading a second subset of data from the second buffer; and The first subset of data and the second subset of data are concatenated into a third buffer, wherein the third buffer includes the constant data.

2. The method according to claim 1, wherein The scalar processor and the stream processor adopt the same instruction set architecture (ISA).

3. The method according to claim 1, wherein The shader program includes an indicator indicating whether the scalar processor or the stream processor is to execute the instructions of the leading portion.

4. The method according to claim 1, wherein The scalar processor is configured to perform a subset of the functionality of the stream processor.

5. The method according to claim 1, wherein The scalar processor is configured to implement the no-binding mechanism during runtime.

6. The method according to claim 1, wherein The instructions for executing the leading portion include: Retrieving the instruction of the leading portion from a buffer; decoding the instruction of the preamble; obtaining one or more operands for executing the instruction of the leading portion; performing flow control for executing the instructions of the leading portion; executing the instructions of the leading portion based on the flow control; and Output data generated by executing the instructions of the preamble is stored at the buffer.

7. An apparatus for performing graphics processing, comprising: at least one memory including instructions; and at least one processor configured to execute the instructions so that the apparatus: Receiving, at a graphics processor, a shader program comprising a prologue portion and a main instruction portion; executing instructions of the preamble with a scalar processor dedicated to processing the preamble to implement a no-bind mechanism for loading constant data associated with the shader program; as well as Distributing the main instruction portion and the constant data to a stream processor for executing the shader program, The scalar processor is configured to implement the no-binding mechanism in the following manner: loading a first subset of data from a first buffer; loading a second subset of data from the second buffer; and concatenating the first data subset and the second data subset into a third buffer, Wherein, the third buffer includes the constant data.

8. The device according to claim 7, wherein The scalar processor and the stream processor adopt the same instruction set architecture (ISA).

9. The device according to claim 7, wherein The shader program includes an indicator indicating whether the scalar processor or the stream processor is to execute the instructions of the leading portion.

10. The device according to claim 7, wherein The scalar processor is configured to perform a subset of the functionality of the stream processor.

11. The device according to claim 7, wherein The scalar processor is configured to include at least a single fiber scheduler, a single fiber context register, a single fiber load-store unit, an unbound state cache, a unified general register, a scalar basic function unit, and a scalar arithmetic logic unit.

12. The device according to claim 7, wherein The scalar processor is configured to implement the no-binding mechanism during runtime.

13. The device according to claim 7, wherein The apparatus includes a wireless communication device.

14. A non-transitory computer-readable medium storing computer-executable code for a data graph, comprising code for: Receiving, at a graphics processor, a shader program comprising a prologue portion and a main instruction portion; executing instructions of the preamble with a scalar processor dedicated to processing the preamble to implement a no-bind mechanism for loading constant data associated with the shader program; as well as Distributing the main instruction portion and the constant data to a stream processor for executing the shader program, in, The implementation of the no-binding mechanism includes: loading a first subset of data from a first buffer; loading a second subset of data from the second buffer; and The first subset of data and the second subset of data are concatenated into a third buffer, wherein the third buffer includes the constant data.

15. The non-transitory computer-readable medium of claim 14, further comprising code for employing a same instruction set architecture (ISA) at the scalar processor and the stream processor.

16. The non-transitory computer-readable medium of claim 14, further comprising code for determining whether the scalar processor or the stream processor is to execute the instructions of the prologue portion based on an indicator of the shader program.

17. An apparatus for performing graphics processing, the apparatus comprising means for performing the method according to any one of claims 1 to 6.

18. A computer program product comprising computer readable instructions which, when executed by a processor, cause the processor to perform the method according to any one of claims 1 to 6.

Images