Method and apparatus for selecting a rendering mode

Abstract

The present disclosure relates to graphics processing. An apparatus of the present disclosure can determine a visibility stream corresponding to a target and a set of tiles into which the target is partitioned. The apparatus can select one of a first rendering mode or a second rendering mode for the target based on a first visibility stream and based on a set of second visibility streams. When the first rendering mode is selected, the apparatus can configure each tile of the set of tiles into either a first subset associated with a first type of rendering pass or a second subset associated with a second type of rendering pass. The apparatus can then render the target based on the selected one of the first rendering mode or the second rendering mode and, if applicable, based on the first rendering pass type or the second rendering pass type.

Description

Technical Field

[0001] In summary, this disclosure relates to processing systems, and more specifically, to one or more techniques for graphics processing. Background Technology

[0002] Computing devices typically utilize graphics processing units (GPUs) to accelerate the rendering of graphics data for display. Such devices can 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, which includes one or more processing stages that work together to execute graphics processing commands and output frames. The central processing unit (CPU) controls the operation of the GPU by issuing one or more graphics processing commands to it. Modern CPUs are typically capable of executing multiple applications concurrently, each of which may require the GPU to utilize its resources during execution. Devices that provide content for visual rendering on a display typically include GPUs.

[0003] Typically, a device's GPU is configured to perform processes within a graphics processing pipeline. However, with the advent of wireless communication and smaller handheld devices, the need for improved graphics processing has been continuously increasing. Summary of the Invention

[0004] The following provides a brief overview of one or more aspects to offer a basic understanding of such aspects. This overview is not a comprehensive summary of all anticipated aspects, nor is it intended to identify key elements of all aspects, nor to depict 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 descriptions that follow.

[0005] Various devices and other means configured to display graphics may include multiple processors and multiple memories. Illustratively, the example device may include a central processing unit (CPU) and a graphics processing unit (GPU), as well as system memory and graphics memory (GMEM). Potentially, the GPU may render some graphics in the GMEM and then copy those graphics to system memory for output to the display of the example device. However, other configurations are also possible.

[0006] In some aspects, GPUs can implement tiled rendering architectures to reduce power consumption and / or save memory bandwidth, for example, compared to full-frame rendering architectures. According to such a tiled rendering architecture, the scene can be divided into multiple bins, each bin representing a segment of the entire scene. Various operations can then be performed on each bin, such as corresponding evaluations of multiple bins. In practice, each bin can be rendered into the GMEM until the complete scene is rendered in the GMEM, and the complete scene can then be stored from the GMEM to system memory for display. This method of scene display can be called "visibility-tiled rendering mode" or simply "tiled rendering mode".

[0007] However, dividing a scene into multiple chunks may be undesirable in some situations, for example, because the associated performance may be unsatisfactory for some rendering implementations. For instance, the overhead commensurate with scene rendering using a chunked rendering mode can lead to unsatisfactory device performance. For example, repetitive operations for rendering the scene (including storing GMEM content into system memory and loading system memory content into GMEM) can incur significant overhead, potentially degrading device performance. Therefore, there is a need for rendering modes that can mitigate or reduce the overhead commensurate with rendering to GMEM.

[0008] This disclosure provides various aspects of a rendering mode in which a scene can be rendered to system memory without first being rendered to GMEM. This rendering mode may be referred to as "visibility direct mode," and it may differ from a tiled rendering mode. As provided by this disclosure, the visibility direct rendering mode can be implemented or implemented as an alternative to several other rendering modes, including, for example, rendering modes involving tiled or chunked rendering architectures, such as the tiled rendering mode described above.

[0009] Illustratively, rendering architectures involving direct visibility mode can generate visibility information and / or other rendering-related information (e.g., depth, blending, primitives, etc.) based on a complete frame or the entire scene. In this way, rendering architectures implementing direct visibility mode have the potential to improve resource utilization (e.g., time and / or computational resources), such as by avoiding dividing the complete scene into multiple chunks and / or avoiding rendering to GMEM as a prerequisite for rendering to system memory.

[0010] Conceptually, direct visibility mode can be similar to tiled rendering mode in some ways, as the complete scene itself can be viewed as a single tile or block encompassing the entire scene. However, direct visibility mode offers features better suited to situations where tiled rendering mode might otherwise incur significant overhead (e.g., unacceptable or excessive overhead). Specifically, rendering a scene via direct visibility mode bypasses dividing the scene into multiple blocks, instead allowing the complete scene to be treated as a single block to be evaluated and rendered. In practice, when using direct visibility mode, the complete scene can be rendered directly into system memory (instead of first rendering multiple blocks into GMEM before reaching system memory, as is done with tiled rendering mode).

[0011] While the aspects of the visibility direct mode described in this paper can be implemented in some cases to improve the rendering architecture (e.g., reducing overhead when rendering certain scenes on certain systems), visibility direct mode may not be universally advantageous compared to tiled rendering mode. Instead, in some other cases, one or more features of tiled rendering mode may make it superior to visibility direct mode. For example, the properties, characteristics, etc., of the device and / or the one or more scenes to be rendered on it may vary, and some of these variations may affect overhead (e.g., time overhead, resource overhead, etc.) and / or other metrics indicating the performance of implementing a particular mode for rendering a given scene on a particular device (or other system).

[0012] Currently, when rendering at least a portion of at least one scene on a device (e.g., a personal computing device, smartphone, tablet, another computing system, etc.), there is no practical method for selecting a rendering mode from multiple potential rendering modes. Therefore, there is a need for a mechanism to determine which rendering mode should be used when rendering at least a portion of one or more scenes using the specific architecture of a device.

[0013] Therefore, this disclosure provides various techniques and solutions for selecting a rendering mode from multiple potential rendering modes when rendering at least a portion of at least one scene using a particular device. Such techniques and solutions are described in the context of selecting between a tiled rendering mode and a direct visibility mode. For example, the device can dynamically select between a tiled rendering mode and a direct visibility mode for each of multiple scenes, which can be implemented during scene rendering. The selection between rendering modes can be based on one or more conditions or parameters associated with the scene (e.g., including one or more tiles into which the scene can be divided) and / or one or more characteristics or configurations of the device performing the rendering (e.g., hardware and / or software capabilities, device settings, etc.).

[0014] Furthermore, some of the example aspects described in the context of using visibility direct mode to render the entire scene can be used at a more granular level. That is, some operations associated with using visibility direct mode to render a scene can be incorporated into the rendering process for one or more individual chunks of the scene that have already been divided. For example, once the scene has been divided into multiple chunks (e.g., when a chunked rendering mode is selected on visibility direct mode when rendering the scene), at least one of the multiple chunks can be rendered directly to system memory, for example, based on information associated with at least one chunk and / or the device rendering the scene, in order to avoid accessing GMEM.

[0015] In fact, this disclosure describes aspects of a device configured to render scenes more efficiently than previous devices. Specifically, the aspects described herein provide a rendering mode (or set of operations) that is preferred (e.g., causes lower or lowest relative overhead) relative to at least one other rendering mode (or set of operations) at various stages of the rendering process based on at least one of the following: the scene being rendered, a specific portion of the scene being rendered (e.g., tiles or blocks), the specific device rendering the scene, and / or one or more other factors. Therefore, the device can iteratively configure operations commensurate with the scene being rendered in a scene- and / or device-dependent manner, and doing so can improve scene rendering performance. This operational configuration may change over time; for example, one of the tiled rendering mode and the visibility direct mode may be selected when rendering each scene, and / or may be selected at specific intervals. Furthermore, the operating configuration can be predicted based on the device itself (such as the hardware, software and / or firmware that the device is configured with). For example, one of the tiled rendering mode and the visibility direct mode can be selected based on the characteristics and / or capabilities of the memory, central processing unit (CPU), graphics processing unit (GPU) (such as the GPU layer), etc.

[0016] In some aspects, this disclosure describes various techniques and solutions for determining whether to use a tiled rendering mode or a visibility-direct mode to render a scene. This determination can be performed dynamically, for example, when the scene is provided for display, rather than statically when the device is powered on, when the monitor is started, etc. This disclosure describes various aspects of this determination and the conditions under which it can be predicted. In some configurations described herein, dynamic switching between tiled rendering mode and visibility-direct mode can measurably reduce overhead, for example, resulting in a performance improvement of greater than 3% to 10% on some applications that can render scenes for them on the device.

[0017] In some other aspects, this disclosure describes various techniques and solutions for determining whether to render scene chunks in a manner similar to the tiled rendering mode described above or the direct visibility mode. In fact, once the determination is made regarding rendering the scene using a tiled rendering mode, further decisions can be made regarding how each chunk should be rendered; that is, for each chunk into which the scene is divided, a corresponding determination can be made regarding whether the chunk should first be rendered to GMEM and then stored in system memory, or whether the chunk should be rendered directly to system memory to avoid GMEM.

[0018] This disclosure describes various methods, computer-readable media, and apparatuses for performing graphics processing. Performing graphics processing may include storing discrete data in at least one of a plurality of memory locations. Such discrete data may include graphical content to be output as display content on a display and may be referred to as a "target". For example, a target may include an image, a scene, a frame, etc.

[0019] In a first aspect of this disclosure, a first method, a first computer-readable medium, and a first apparatus are provided. The first apparatus may be a CPU, a GPU, or any apparatus capable of performing graphics processing. The first apparatus may include or be communicatively connected to GMEM and system memory. The first apparatus may be configured to: determine a first visibility stream corresponding to the target based on a first visibility path for the target. The first apparatus may also be configured to: determine a second set of visibility streams corresponding to each of the chunk sets, the target being divided into the chunk sets, based on a second set of visibility paths for the chunk sets. The first apparatus may be configured to: select one of a first rendering mode or a second rendering mode for the target based on the first visibility stream and based on the second set of visibility streams, the first rendering mode including rendering each chunk in the chunk set, and the second rendering mode including directly rendering the target. The first apparatus may be configured to: then render the target based on the selected first rendering mode or the second rendering mode.

[0020] In a second aspect of this disclosure, a second method, a second computer-readable medium, and a second apparatus are provided. The second apparatus may be a CPU, a GPU, or any apparatus capable of performing graphics processing. The second apparatus may include or be communicatively connected to a GMEM and system memory. The second apparatus may be configured to: determine the corresponding visibility of primitives associated with each tile in a set of tiles, each tile representing at least a corresponding portion of a target. The second apparatus may also be configured to: for each tile in the set of tiles, determine a corresponding rendering pass type from a plurality of rendering pass types based on the corresponding visibility of the primitives, the plurality of rendering pass types including a first rendering pass type associated with rendering the tile into the GMEM and a second rendering pass type associated with avoiding rendering the tile into the GMEM. The second apparatus may be configured to: then render the target based on the corresponding rendering pass type determined for each tile in the set of tiles.

[0021] Details of one or more examples of this disclosure are set forth in the accompanying drawings and the description below. Other features, objects, and advantages of this disclosure will be apparent from the specification, drawings, and claims. Attached Figure Description

[0022] Figure 1 This is a block diagram illustrating an example content generation system based on one or more aspects of this disclosure.

[0023] Figure 2 An example GPU is shown, representing one or more aspects of this disclosure.

[0024] Figure 3 Example images or surfaces are shown according to one or more aspects of this disclosure.

[0025] Figure 4 An example flowchart of an example method for graphical processing according to one or more aspects of this disclosure is shown.

[0026] Figure 5 Another example flowchart of another example method of graphical processing according to one or more aspects of this disclosure is shown. Detailed Implementation

[0027] Depending on the aspects, a graphics processing unit (GPU) can implement a tile-based rendering architecture, where a target that can be considered a complete frame (e.g., a scene, frame, image, other graphics, etc.) is divided into multiple segments (called "tiles"). A corresponding visibility path can then be executed for each of these tiles to identify the primitives (e.g., triangles) visible within each tile.

[0028] On-chip memory (e.g., GPU memory) can be characterized by high bandwidth and / or low latency (e.g., compared to some separate system memory, such as Double Data Rate (DDR) Random Access Memory (RAM)). Such on-chip memory may be subject to capacity constraints in mobile devices (e.g., smartphones, smartwatches, etc.) due to space and / or cost considerations, compared to other (larger) computing devices (e.g., desktop computers, laptops, etc.). Tile-based rendering architectures can be particularly well-suited to the relatively limited on-chip memory of GPUs, as each tile is rendered to on-chip memory to take advantage of its high bandwidth and / or low latency characteristics.

[0029] To then render the target using tile-based rendering, each tile can be rendered into Graphics Memory (GMEM). After each tile has been rendered into GMEM, the target resides in GMEM. Subsequently, the target can be stored in system memory (e.g., in the frame buffer of system memory), for example, after all visible objects have been drawn in GMEM. In other words, the target can be copied from GMEM to system memory, such as by copying the data of each tile from GMEM to the corresponding area of ​​the frame buffer in system memory. Depending on the system memory, the target is displayed on, for example, a graphical user interface (GUI) or other similar display configured on the device.

[0030] The method described above for rendering targets (in which a tile-based rendering architecture is implemented) can be referred to as a "visibility-tiled rendering mode" or simply a "tiled rendering mode". In some cases, tiled rendering modes can reduce power consumption and / or save memory bandwidth compared to one or more other rendering modes (such as those in which targets are rendered directly and / or do not divide targets into tiles).

[0031] Specifically, tiled rendering can leverage the potentially high bandwidth and / or low latency properties of GMEM to mitigate (or even eliminate) some data traffic to system memory (or other host memory), such as data traffic associated with occluded primitives and / or other unnecessary data traffic. This reduction in data traffic can decrease power consumption (e.g., battery capacity) and / or other computing resource (e.g., GPU and / or CPU load). Therefore, tiled rendering can be suitable for rendering relatively complex targets, such as scenes with a relatively large number of primitives, overdraw, blending, and / or other characteristics that may contribute to or at least contribute to the intricacy, dimensionality, etc., of the scene.

[0032] However, in some other cases, the workload on the GPU and / or central processing unit (CPU) commensurate with rendering certain scenes may not be suitable for tiled rendering mode. For example, rendering scenes in which the amount of storage from GMEM to system memory and / or the amount of loading from system memory to GMEM is significant may adversely affect GPU and / or CPU performance.

[0033] An alternative to the chunked rendering mode could be a mode that treats the target as a single chunk against which a full frame visibility path is performed. With this treatment, the target can be rendered directly into system memory, effectively bypassing GMEM and the associated storage and loading. This approach of rendering the target directly into system memory as a single chunk can be called "visibility direct mode".

[0034] Because visibility-direct mode can draw primitives or triangles directly to the frame buffer in system memory, some overhead associated with tiled rendering modes can be avoided. For example, visibility-direct mode can reduce (or potentially even eliminate) the overhead associated with binning, resolving from GMEM to system memory in the rendering path, unresolving from system memory to GMEM in the rendering path, and / or other operations performed during the implementation of tiled rendering modes but not during the implementation of visibility-direct mode. This direct framebuffer rendering is suitable for rendering simple and / or less complex targets, such as scenes with relatively low amounts of primitives or triangles, overdraw, blending, etc.

[0035] The conditions upon which a rendering target is based are often situation-specific, and therefore, the mode that provides better performance may change dynamically, for example, depending on the application providing the rendering target, the frequency of rendering, etc. Furthermore, the characteristics of the device configured as the rendering target can significantly influence which mode is better suited to the rendering target. Therefore, the ability to dynamically select among the modes used for rendering can improve device performance, for example, compared to using a single mode or statically selecting a mode for use across all applications.

[0036] Some aspects of this disclosure describe a dynamic selection between a tiled rendering mode and a direct visibility mode. This dynamic selection can be implemented via software (or firmware) of the device or other means. Specifically, a set of conditions can be determined (e.g., calculated, estimated, evaluated, etc.), and one of the tiled rendering mode or the direct visibility mode can then be dynamically selected based on this set of conditions. For example, the set of conditions can be based on a set of visibility paths associated with a target (e.g., a full-frame scene), such as various operations commensurate with the set of visibility paths (e.g., parsing, unparsing, blending, etc.), hardware configurations associated with the set of visibility paths (e.g., constraints), etc.

[0037] Some aspects of this disclosure (wherein dynamic selection of either a tiled rendering mode or a direct visibility mode) can improve the performance of applications on a device, for example, compared to using only one or the other of the tiled rendering mode and the direct visibility mode. For example, by implementing such dynamic mode selection as described herein, performance improvements of approximately 3% to 10% can be achieved for multiple applications. Potentially, power and / or memory bandwidth can also be saved.

[0038] In some other aspects of this disclosure, the various techniques and solutions described regarding the dynamic selection of rendering modes for each target (e.g., scene, image, frame, etc.) can be used at even finer-grained levels. For example, the various operations described regarding tiled rendering modes and visibility direct modes can even be implemented within the target, and specifically, can be implemented for each tile in which the rendering target is divided.

[0039] To render the target, the rendering mode to be used at the full frame level can first be determined. With the visibility direct mode selected, the target can be treated as a single chunk and rendered to system memory (e.g., directly in the frame buffer) instead of in GMEM. However, without selecting visibility direct mode, the target can be rendered at the chunk level, allowing for a corresponding determination for each chunk regarding whether the rendering path functionally resembles a chunked rendering mode or visibility direct mode.

[0040] In practice, a determination can be made for each of the multiple chunks regarding whether to render the chunk to GMEM and then store the chunk data from GMEM in system memory, or to render the chunk to system memory without first rendering it to GMEM. For example, a corresponding set of conditions can be determined for each chunk, which may include some conditions similar to and / or different from those determined when choosing between a chunk rendering mode and a visibility direct mode for a target. Based on the corresponding set of conditions, each chunk can then be rendered to GMEM first and then stored in system memory, or it can be rendered to system memory without being rendered to GMEM.

[0041] The per-tile selection of the rendering implementation can be predicted based on the target being divided into multiple tiles; therefore, a determination can be established first regarding whether to choose a tiled rendering mode or a visibility direct mode for the target. When choosing a tiled rendering mode, a corresponding determination can then be made regarding how to render each tile. However, this per-tile selection of the rendering implementation can also be implemented when using a tiled rendering mode, regardless of any determination. For example, when using a tiled or tiled rendering architecture by default, per-tile selection of the rendering implementation can be used in cases where a visibility direct mode is unavailable or absent on the device (at the full frame level), or when the device is configured with a visibility direct mode that is deactivated or turned off but a tiled rendering mode that is activated or turned on.

[0042] As mentioned above, the tiled rendering mode is better suited (e.g., more economical in terms of power and / or other computational resources) for relatively complex targets (e.g., large numbers of primitives or triangles, overdraw, blending, etc.), while the visibility-direct mode is better suited for relatively less complex or simpler targets (e.g., a small number of primitives or triangles, blending, overdrawing, etc.). However, at a finer granularity, targets may include some regions with relatively greater complexity and others with relatively less complexity. Therefore, tile-level determinations can be made regarding whether a corresponding tile should be rendered to GMEM and then stored from GMEM in system memory, or rendered to system memory without first being rendered to GMEM.

[0043] Based on some aspects of this disclosure, each block can be evaluated to determine a corresponding level of complexity associated with it. Potentially, such a level of complexity can be (e.g., numerically) represented as a complexity value, where each block has a corresponding complexity value determined therefrom. For example, the corresponding complexity value can be based on primitives at least partially within each block, overdraw within each block, the amount of blending within each block, and / or other such characteristics of each block that may directly or indirectly affect the rendering process of each block.

[0044] In practice, the corresponding complexity value can serve as a metric that can represent or estimate the overhead and / or resource consumption commensurate with each chunk in a rendering chunk. In an illustrative rather than restrictive manner, some examples of the overhead and / or resource consumption associated with each chunk in a rendering chunk (and which can be represented or approximated by the corresponding complexity value) may include the amount of power consumed (e.g., battery consumption), the number of instruction cycles consumed, the amount of memory consumed and / or the duration (e.g., including different types of memory), the load on the GPU, the load on the CPU, the duration, and / or other factors associated with rendering each chunk.

[0045] Based on an assessment of the corresponding complexity level, a determination can be made for each block in the chunk regarding whether a first rendering mode including GMEM (e.g., a chunked rendering mode similar to that described herein) or a second rendering mode excluding GMEM (e.g., a visibility direct mode similar to that described herein) should be used. For example, a first chunk subset can be rendered to GMEM based on a corresponding complexity value corresponding to the first chunk subset, and then the first chunk subset (e.g., the data of the first chunk subset) can be copied from GMEM to system memory, such as by copying the data of each chunk to the corresponding corresponding region in the frame buffer of system memory. However, a second chunk subset can be rendered to system memory without rendering to GMEM—for example, each chunk in the second chunk subset can be directly rendered to the corresponding corresponding region in the frame buffer of system memory.

[0046] This article further describes, with reference to the accompanying drawings, various aspects and other details related to determining the rendering mode for a target (e.g., an image, scene, frame, etc.) and the rendering mode for a target that can be divided into chunks.

[0047] The various aspects of the systems, apparatus, computer program products, and methods are described more fully below with reference to the accompanying drawings. However, this disclosure may be embodied in many different forms and should not be construed as limited to any particular structure or function presented throughout this disclosure. Rather, these aspects are provided so that this disclosure will be comprehensive and complete, and will fully convey the scope of this disclosure to those skilled in the art. Based on the teachings herein, those skilled in the art will recognize that the scope of this disclosure is intended to cover any aspect of the systems, apparatus, computer program products, and methods disclosed herein, whether that aspect is implemented independently of or in combination with other aspects of this disclosure. For example, an apparatus may be implemented or a method may be practiced using any number of the aspects set forth herein. Furthermore, the scope of this disclosure is intended to cover such apparatuses or methods practiced using structures, functions, or structures and functions other than or different from the aspects of this disclosure set forth herein. Any aspect disclosed herein may be embodied by one or more elements of the claims.

[0048] While various aspects are described herein, numerous variations and substitutions of these aspects fall within the scope of this disclosure. Although some potential benefits and advantages of the aspects of this disclosure are mentioned, the scope of this disclosure is not intended to be limited to a particular benefit, use, or objective. Rather, the aspects of this disclosure are intended to be broadly applicable to various wireless technologies, system configurations, networks, and transport protocols, some of which are illustrated by way of example in the accompanying drawings and the description below. The detailed description and drawings are illustrative only and not limiting of this disclosure, the scope of which is defined by the appended claims and their equivalents.

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

[0050] For example, an element, or any part of an element, or any combination of elements, can be implemented as a "processing system," which includes one or more processors (which may also be called processing units). Examples of processors include: microprocessors, microcontrollers, GPUs, general-purpose GPUs (GPGPUs), CPUs, application processors, digital signal processors (DSPs), reduced instruction set computing (RISC) processors, system-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. Whether referred to as software, firmware, middleware, microcode, hardware description languages, or others, software can be broadly interpreted as instructions, instruction sets, code, code segments, program code, programs, subroutines, software components, applications, software applications, software packages, routines, subroutines, objects, executable files, threads of execution, procedures, functions, etc. The term application can refer to software. As described herein, one or more technologies can refer to an application, i.e., software, configured to perform one or more functions. In such examples, the application may be stored on memory, such as the processor's on-chip memory, system memory, or any other memory. The hardware described herein (such as a processor) may be configured to execute the application. For example, an application may be described as including code that, when executed by the hardware, causes the hardware to perform one or more techniques described herein. As an example, the hardware may access code from memory and execute the code accessed from memory to perform one or more techniques described herein. In some examples, components are identified in this disclosure. In such examples, a component may be hardware, software, or a combination thereof. A component may be a single component or a subcomponent of a single component.

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

[0052] In summary, this disclosure describes techniques for selecting a rendering mode (e.g., a tiled rendering mode or a visibility direct mode) for a full frame target and further for selecting a corresponding type of rendering path (e.g., rendering path types that include rendering to GMEM and rendering path types that do not include rendering to GMEM) for each of the multiple tiles into which the target is divided. Each of the frame-level rendering mode selection and the tile-level rendering path type selection can be performed dynamically, thereby improving the rendering of graphics content, for example, by reducing power consumption (e.g., battery level), reducing latency, and / or reducing the load on processing units (e.g., any processing unit configured to perform one or more of the techniques described herein, such as a GPU). For example, this disclosure describes techniques for rendering architectures in any device that utilizes graphics processing. Other example benefits are described throughout this disclosure.

[0053] As used herein, instances of the term "content" can refer to "graphic content," "image," or vice versa. This is true regardless of whether the term is used as an adjective, noun, or other part of speech. In some examples, as used herein, the term "graphic content" can refer to content produced by one or more processes in a graphics processing pipeline. In some examples, as used herein, the term "graphic content" can refer to content produced by a processing unit configured to perform graphics processing. In some examples, as used herein, the term "graphic content" can refer to content produced by a graphics processing unit.

[0054] In some examples, as used herein, the term "display content" can refer to content generated by a processing unit configured to perform display processing. Graphical content can be processed to become display content. For example, a GPU can output graphical content, such as frames, to a buffer (which may be referred to as a frame buffer). A display processing unit can read graphical 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 processing unit can be configured to perform compositing on one or more rendering layers to generate frames. As another example, a display processing unit can be configured to composite, blend, or otherwise combine two or more layers into a single frame. A display processing unit can be configured to perform scaling (e.g., zooming in or out) on frames. In some examples, a frame can refer to a layer. In other examples, a frame can refer to two or more layers that have already been blended together to form a frame, i.e., a frame comprises two or more layers, and frames comprising two or more layers can subsequently be blended.

[0055] Figure 1This is a block diagram illustrating an example content generation system 100 configured to implement one or more technologies of this disclosure. The content generation system 100 includes a device 104. Device 104 may include one or more components or circuitry for performing the various functions described herein. In some examples, one or more components of device 104 may be components of a System-on-a-Chip (SOC). Device 104 may include one or more components configured to perform one or more technologies of this disclosure.

[0056] In the illustrated example, device 104 may include at least one processing unit 120, a content encoder / decoder 122, and system memory 124. In some aspects, device 104 may include multiple optional components, such as a communication interface 126, a transceiver 132, a receiver 128, a transmitter 130, a display processor 127, and one or more displays 131. The illustrated components of device 104 may be configured to communicate, for example, via one or more buses and / or one or more other wired and / or wireless connections. While system 100 illustrates various connections for communication between components, in some other examples, different and / or additional connections and / or other communication paths may be configured without departing from the scope of this disclosure.

[0057] A reference to display 131 can refer to one or more displays 131. For example, display 131 may include a single display or multiple displays. Display 131 may include a first display and a second display. The first display may be a left-eye display, and the second display may be a right-eye display. In some examples, the first and second displays may receive different frames for rendering on them. In other examples, the first and second displays may receive the same frames for rendering on them. In further examples, the results of graphics processing may not be displayed on the device; for example, the first and second displays may not receive any frames for rendering on them. Instead, the frames or graphics processing results may be transmitted to another device. In some aspects, this may be referred to as split rendering.

[0058] At least one processing unit 120 may include internal memory 121. Processing unit 120 may be configured to perform graphics processing, such as in a graphics processing pipeline 107. Content encoder / decoder 127 may include internal memory 123. In some examples, device 104 may include a display processor (such as display processor 127) to perform one or more display processing techniques on one or more frames generated by processing unit 120 prior to rendering by one or more displays 131. Display processor 127 may be configured to perform display processing. For example, display processor 127 may be configured to perform one or more display processing techniques on one or more frames generated by processing unit 120. One or more displays 131 may be configured to display or otherwise present frames processed by display processor 127. In some examples, one or more displays 131 may include one or more of the following: liquid crystal display (LCD), plasma display, organic light-emitting diode (OLED) display, projection display device, augmented reality display device, virtual reality display device, head-mounted display, or any other type of display device.

[0059] Memory (such as system memory 124) external to processing unit 120 and content encoder / decoder 122 may be accessible to processing unit 120 and content encoder / decoder 122. For example, processing unit 120 and content encoder / decoder 122 may be configured to read from and / or write to external memory such as system memory 124. Processing unit 120 and content encoder / decoder 122 may be communicatively coupled to system memory 124 via a bus. In some examples, processing unit 120 and content encoder / decoder 122 may be communicatively coupled to each other via a bus or a different connection.

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

[0061] Internal memory 121 or system memory 124 may include one or more volatile or non-volatile memories or storage devices. In some examples, internal memory 121 or system memory 124 may include RAM, static RAM (SRAM), dynamic RAM (DRAM), synchronous DRAM (SDRAM), DDR SDRAM (e.g., DDR2, DD3, etc.), erasable programmable ROM (EPROM), electrically erasable programmable ROM (EEPROM), flash memory, magnetic data media or optical storage media, or any other type of memory.

[0062] According to some examples, internal memory 121 or system memory 124 may be a non-transitory storage medium. The term "non-transitory" may indicate that the storage medium is not embodied in a carrier wave or a propagating signal. However, the term "non-transitory" should not be construed as meaning that internal memory 121 or system memory 124 is immovable or that its contents are static. As one example, system memory 124 may be removed from device 104 and moved to another device. As another example, system memory 124 may be non-removable from device 104.

[0063] In some aspects, system memory 124 may include or be communicatively coupled to frame buffer 125. Frame buffer 125 may be a segment of memory (e.g., RAM) that can drive output on display 131 (potentially dedicated). For example, frame buffer 125 may store data representing pixels of a frame or scene, wherein such data is stored in frame buffer 125 according to the corresponding area in the frame or scene presented on display 131.

[0064] At least one processing unit 120 may include at least one of the following: a CPU, a GPU, a GPGPU, or any other processing unit that can be configured to perform graphics processing. In some examples, the processing unit 120 may be integrated into the motherboard of device 104. In some examples, the processing unit 120 may reside on a graphics card mounted in a port on the motherboard of device 104, or may otherwise be incorporated into a peripheral device configured to interoperate with device 104. The processing unit 120 may include one or more processors, such as one or more microprocessors, GPUs, CPUs, 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 circuits, or any combination thereof. Some aspects of this disclosure may be implemented at least in part in software, and therefore, the processing unit 120 may store instructions for software in a suitable computer-readable storage medium (which may be non-transitory). For example, at least a portion of the internal memory 121 may include computer-executable instructions or code, and at least one processing unit 120 may use one or more processors to execute instructions in hardware to perform the aspects described herein. Any of the foregoing, including hardware, software, firmware, combinations thereof, etc., can be considered as one or more processors.

[0065] The content encoder / decoder 122 can be any processing unit configured to perform content decoding. In some examples, the content encoder / decoder 122 can be integrated into the motherboard of device 104. The content encoder / decoder 122 can include one or more processors, such as one or more microprocessors, ASICs, FPGAs, ALUs, DSPs, video processors, discrete logic, software, hardware, firmware, other equivalent integrated or discrete logic circuits, or any combination thereof. If the technology is partially implemented in software, the content encoder / decoder 122 can store instructions for software in a suitable non-transitory computer-readable storage medium (e.g., internal memory 123), and can execute the instructions in hardware using one or more processors to perform the technology of this disclosure. Any of the foregoing, including hardware, software, combinations of hardware and software, etc., can be considered as one or more processors.

[0066] In some aspects, the content generation system 100 may include an optional communication interface 126. Communication interface 126 may include a receiver 128 and a transmitter 130. Receiver 128 may be configured to perform any of the receiving functions described herein with respect to device 104. Additionally, receiver 128 may be configured to receive information (e.g., eye or head position information, rendering commands, or location information) from another device. Transmitter 130 may be configured to perform any of the transmitting functions described herein with respect to device 104. For example, transmitter 130 may be configured to send information to another device that may include a request for content. Receiver 128 and transmitter 130 may be combined into transceiver 132. In such an example, transceiver 132 may be configured to perform any of the receiving and / or transmitting functions described herein with respect to device 104.

[0067] Refer again Figure 1 In some aspects, device 104 may include one or more components, each of which may be implemented as hardware, software, firmware, or some combination thereof, configured to render a target, for example, for presentation on display 131. As described herein, a target may include a complete or entire frame and may also be referred to as a “rendering target,” “target scene,” “target frame,” “target image,” and / or other terms referring to graphical content. Thus, a target may include images, scenes, frames, etc. In some aspects, a target may include graphical content for outputting or displaying content individually or independently, such as still images, still frames, and / or still scenes. However, in some other aspects, a target may include data as part or fragments of graphical content that is output sequentially or continuously in a graphical manner, and / or include display content that changes over time (such as images in a series of images constituting an animated image, multiple frames in a video (e.g., including streaming video), or frames or scenes in a scene), etc.

[0068] To render a target, the graphics processing pipeline 107 may include at least a rendering mode selection component 198. The rendering mode selection component 198 may be configured to: determine a first visibility stream corresponding to the target based on a first visibility path for the target; and determine a second visibility stream set corresponding to each of the chunk sets based on a second visibility path set for the chunk set, wherein the target is divided into chunk sets. Further, the rendering mode selection component 198 may be configured to select one of a first rendering mode or a second rendering mode for the target based on the first visibility stream and the second visibility stream set; the first rendering mode includes rendering each chunk in the chunk set, and the second rendering mode includes directly rendering the target. The rendering mode selection component 198 may then render the target based on the selected first or second rendering mode.

[0069] By way of description rather than limitation, the first rendering mode may include rendering the target piecewise, for example, where the target is divided into multiple chunks, each chunk representing a corresponding portion of the target in a complete frame; while the second rendering mode may be a visibility direct mode, where the target is rendered into system memory. Functionally, in the case of visibility direct mode, the target can be treated as a single chunk, and therefore, the corresponding first visibility stream may include information associated with the complete frame (represented as a single chunk).

[0070] In some aspects, the first rendering mode may include a tiled rendering mode. Therefore, the rendering mode selection component 198 can render the target by rendering each of a plurality of tiles in a GMEM, for example, the GMEM may include at least a portion of internal memory 121 and / or internal memory 123 (such as buffers, caches, and / or other segments of memory), which may be dedicated or may not be dedicated. In some aspects, the GMEM may be characterized by higher bandwidth and / or lower latency than system memory 124; for example, the GMEM may include at least a portion of internal memory 121 having higher bandwidth and / or lower latency than system memory 124 (which may include DDR SDRAM and / or other RAM). In some further aspects, the GMEM may be on-chip memory; for example, the GMEM may include at least a portion of the on-chip memory of the GPU, which is the processing unit 120, within internal memory 121.

[0071] Therefore, based on these aspects, data representing multiple blocks of the target can be stored in GMEM. Render mode selection component 198 can then store (e.g., copy) the target stored in GMEM to system memory 124. For example, rendering mode selection component 198 can copy the corresponding data of each block in GMEM to the corresponding area in the frame buffer 125 of system memory 124.

[0072] In some other aspects, the rendering mode selection component 198 can select a first rendering mode (e.g., a tiled rendering mode) such that the target is rendered at the tile level, wherein each of a plurality of tiles in a memory location is rendered to its corresponding memory location. For this purpose, the rendering mode selection component 198 can be communicatively coupled to a rendering path configuration component 199, which can configure the rendering of each of the plurality of tiles into which the target is divided.

[0073] For example, the rendering path configuration component 199 can configure each block of the plurality of blocks into one of a first block subset or a second block subset based on the corresponding visibility of primitives associated with each block in the plurality of blocks and / or based on the corresponding visibility stream corresponding to each block in the plurality of blocks. In some aspects, the corresponding second visibility stream in the second visibility stream set can indicate the corresponding visibility of primitives associated with the corresponding block in the plurality of blocks. As further described herein, the rendering path configuration component 199 can render each block in the first block subset according to a first type of rendering path (e.g., similar to a tiled rendering mode) and render each block in the second block subset according to a second type of rendering path (e.g., similar to a visibility direct rendering mode).

[0074] However, when the rendering mode selection component 198 selects the second rendering mode, it can render the target by rendering it to system memory 124 instead of to GMEM (e.g., not to internal memory 121). For example, the target can be considered as a single chunk (e.g., a single chunk corresponding to or containing the entire frame), and the rendering mode selection component 198 can render the (complete frame) target directly in the frame buffer 125 of system memory 124. By doing so, the rendering mode selection component 198 can avoid rendering the target to GMEM (e.g., a single chunk corresponding to the complete frame may not be rendered to GMEM (such as internal memory 121)).

[0075] In one aspect, the rendering mode selection component 198 can determine LRZ information associated with a low-resolution z-(LRZ) buffer used for the target (e.g., for a single chunk corresponding to a full frame target). The rendering mode selection component 198 can be configured to further select one of a first rendering mode or a second rendering mode based on the LRZ information. The rendering mode selection component 198 can use the LRZ information to detect overdraw conditions, such as the amount or degree of overdraw. For example, the rendering mode selection component 198 can determine the number of visible pixels associated with the rendering target based on the LRZ information, and the rendering mode selection component 198 can be configured to further select one of the first rendering mode or the second rendering mode based on the ratio of the number of visible pixels to the total number of pixels associated with the rendering target.

[0076] In some aspects, the rendering mode selection component 198 can determine one or more values ​​associated with the rendering target that indicate "clearing" (e.g., clearing means no visible pixels) based on LRZ information. The rendering mode selection component 198 can determine LRZ information for each of the sets of segments or blocks into which the target (e.g., the pixels of the target) is divided. When the rendering mode selection component 198 determines that all values ​​for a segment or block indicate clearing, the rendering mode selection component 198 can determine that no visible pixels should be written to that segment or block. For other segments or blocks, the rendering mode selection component 198 can determine the number of visible pixels after determining the LRZ information.

[0077] In a further aspect, the rendering mode selection component 198 can be configured to determine at least one of the following: the number of resolutions, the number of unresolutions, and / or the amount of blending associated with the rendering target, based on a first visibility stream and / or a second set of visibility streams. The rendering mode selection component 198 can be configured to select one of a first rendering mode or a second rendering mode based on said at least one of the following: the number of resolutions, the number of unresolutions, and / or the amount of blending.

[0078] In another aspect, the rendering mode selection component 198 can be configured to further select one of a first rendering mode or a second rendering mode based on at least one configuration of concurrent resolution or concurrent unresolution associated with the rendering target.

[0079] In another aspect, the rendering mode selection component 198 can be configured to select one of a first rendering mode or a second rendering mode based on a configuration for at least one clearing operation concurrent with at least one parsing operation associated with the rendering target.

[0080] As described above, when the first rendering mode is selected, a corresponding determination can be made regarding how each of the multiple chunks will be rendered. Relatedly, the graphics processing pipeline 107 may also include a rendering path configuration component 199, which is communicatively coupled to, for example, the rendering mode selection component 198 and configured to perform various operations when the rendering mode selection component 198 selects the first rendering mode. Specifically, the rendering path configuration component 199 may configure each of the multiple chunks into one of a first subset or a second subset of chunks, wherein the first subset of chunks is rendered differently from the second subset of chunks.

[0081] The rendering path configuration component 199 can configure tiles to a first or second subset based on the visibility of primitives (e.g., based on visibility streams). Therefore, the rendering path configuration component 199 can be configured to determine the corresponding visibility of primitives associated with each tile in the tile set (e.g., the corresponding visibility stream corresponding to each tile in the tile set), where each tile represents at least a corresponding portion of the target. Since the rendering mode selection component 198 can determine the aforementioned second visibility stream set corresponding to each tile set, and the corresponding visibility stream corresponding to the tile set can be a second visibility stream set, the rendering path configuration component 199 can, for example, determine the corresponding visibility of primitives associated with the tile set (e.g., the corresponding visibility stream corresponding to the tile set) by obtaining the second visibility stream set from the rendering mode selection component 198.

[0082] Then, the rendering path configuration component 199 can determine a corresponding rendering path type from a plurality of available rendering path types for each chunk in the chunk set, based on the corresponding visibility (e.g., corresponding visibility stream) of the primitives associated with the corresponding chunk. The plurality of available rendering path types may include a first rendering path type associated with rendering the chunk into the GMEM and a second rendering path type associated with avoiding rendering the chunk into the GMEM. For example, the first rendering path type may be similar to a chunk rendering mode that includes rendering to the GMEM and then resolving to system memory 124, while the second rendering path type may be similar to a visibility direct mode that includes rendering (directly) to system memory 124 without rendering to the GMEM.

[0083] Then, the rendering path configuration component 199 can render the target based on the corresponding rendering path type determined for each chunk in the chunk set. When the first rendering path type is determined as the corresponding rendering path type for each chunk in the first chunk subset, the rendering path configuration component 199 can render each chunk in the first chunk subset to GMEM (e.g., to internal memory 121). The rendering path configuration component 199 can then store (e.g., copy, parse, etc.) the data from GMEM for each chunk in the first chunk subset to system memory 124. Since each chunk in the first chunk subset can represent a corresponding region of the target, the rendering path configuration component 199 can copy the data of each chunk in the first chunk subset from GMEM to the corresponding region of the target in the frame buffer 125 of system memory 124.

[0084] However, when the second rendering pass type is determined as the corresponding rendering pass type for each chunk in the second chunk subset, the rendering pass configuration component 199 can render each chunk in the second chunk subset to system memory 124 instead of to GMEM (e.g., internal memory 121). Specifically, the rendering pass configuration component 199 can render each chunk in the second chunk subset to the corresponding region in the frame buffer 125 of system memory 124.

[0085] In some aspects, the rendering path configuration component 199 can render each chunk in the first chunk subset before rendering each chunk in the second chunk subset. For example, the rendering path configuration component 199 can perform at least one rendering path of a first type (e.g., a tiled rendering path and / or a chunked rendering path) for each chunk in the first chunk subset. Once completed (e.g., once the data of the first chunk subset is stored from GMEM to the corresponding area in the frame buffer 125), the rendering path configuration component 199 can perform at least one rendering path of a second type (e.g., a direct rendering path and / or a visibility direct rendering path) for the second chunk subset.

[0086] The rendering path configuration component 199 can render each chunk in the first chunk subset to GMEM. After the first chunk subset is rendered to GMEM, the rendering path configuration component 199 can store (e.g., copy, parse, etc.) each chunk in the first chunk subset from GMEM to system memory 124. Therefore, the corresponding target region corresponding to the first chunk subset can be stored in the frame buffer 125 of system memory 124. Subsequently, the rendering path configuration component 199 can render each chunk in the second chunk set to system memory 124, wherein the rendering path configuration component 199 can perform this operation for all second chunk subsets in a single rendering path.

[0087] In some aspects, for each chunk in the second chunk subset, the rendering path configuration component 199 can render the respective chunk using a chunk mask based on the depth buffer associated with the respective chunk. The chunk mask can be configured for early Z or depth rejection, and thus the rendering path configuration component 199 can avoid or prevent rendering some or all pixels associated with Z values ​​and / or depth that may not be visible and / or may be overdrawn when the target is output (e.g., as display content and / or on display 131).

[0088] In some aspects, the rendering pass configuration component 199 can be configured to determine (e.g., generate) patch masks. Potentially, the rendering pass configuration component 199 can determine multiple patch masks; for example, it can determine a corresponding patch mask for each patch in a second subset of patches. The rendering pass configuration component 199 can determine the patch masks based on LRZ information and / or an LRZ buffer. The rendering pass configuration component 199 can determine the depth of pixels within the second subset of patches and can determine the patch masks based on the determined pixel depth.

[0089] Since the rendering target and the blocks into which the target is divided can be based on various associated properties or parameters, the rendering path configuration component 199 can configure each of the multiple blocks into one of a first or second subset of blocks based on such properties and / or features. For example, the rendering path configuration component 199 can configure a corresponding block into one of the first or second subset of blocks based on at least one of the following: overdraw associated with each of the multiple blocks, blending associated with the corresponding block, and / or the number of primitives or triangles associated with the corresponding block.

[0090] In another example, the rendering pipeline configuration component 199 may configure each of the multiple chunks to one of a first subset or a second subset based on information associated with one or more components of system 100, such as one or more configurations associated with the capabilities and / or characteristics of system 100. For example, the rendering pipeline configuration component 199 may configure each of the multiple chunks to one of a first subset or a second subset based on one or more configurations associated with concurrent resolution, concurrent unresolution, and cleanup operations concurrent with resolution and / or unresolution. Such configurations associated with the aforementioned operations (e.g., concurrent operations) may be based on the capabilities of system 100, for example, because the capabilities of system 100 can enable or limit certain operations and / or their concurrent execution.

[0091] To this end, the rendering path configuration component 199 can be configured to determine (e.g., calculate, compute, generate, etc.) a corresponding complexity value for each of the plurality of blocks, whereby the complexity value can be a number representing or estimating the complexity associated with the rendering block. The rendering path configuration component 199 can determine the corresponding complexity value for a given block based on the corresponding visibility of primitives in one of the plurality of blocks (e.g., a corresponding visibility stream in a second set of visibility streams) and / or based on other information associated with that given block and / or system 100. In some aspects, the rendering path configuration component 199 can determine the corresponding complexity value for a given block based on at least one of the following: overdraw associated with one of the blocks, blending associated with that block, and / or the number of objects (e.g., primitives, triangles, etc.) at least partially represented in the block.

[0092] For each of the multiple chunks, the rendering path configuration component 199 can then compare the corresponding complexity value with a chunk complexity threshold, which can be the same for all chunks. In some aspects, the chunk complexity threshold can be predetermined or pre-configured (e.g., stored in the memory of system 100, such as internal memory 121, internal memory 123, or system memory 124). In other aspects, the rendering path configuration component 199 can determine (e.g., compute, calculate, estimate) the chunk complexity threshold. For example, the rendering path configuration component 199 can determine the chunk complexity threshold based on the configuration of system 100 (e.g., the characteristics and / or capabilities of system 100).

[0093] Illustratively, the rendering path configuration component 199 can determine the chunking complexity threshold based on the configuration of the system 100 regarding overdraw, blending, and / or objects (e.g., primitives, triangles, etc.) such as the system 100's capacity regarding overdraw amount, blending amount, and / or the amount of objects to be rendered and / or the latency regarding overdraw amount, blending amount, and / or the amount of objects to be rendered that is commensurate with the rendering performed by the system 100.

[0094] Therefore, for each of the multiple blocks, the rendering path configuration component 199 can compare the corresponding complexity value with the block complexity threshold, and based on the comparison, the rendering path configuration component 199 can configure (e.g., classify, determine, identify) the block in a first subset of the multiple blocks or a second subset of the multiple blocks, wherein the first subset is configured to be rendered into GMEM, and the second subset is configured to be rendered (directly) into system memory 124, without being rendered into GMEM.

[0095] In some aspects, when the corresponding complexity value of a chunk meets (e.g., conforms to or exceeds) a chunk complexity threshold, the rendering path configuration component 199 can configure the chunk in the first subset. That is, when a chunk represents a relatively complex region of a target (such as a region with a relatively large amount of overdraw, blending, and / or objects to be rendered), the rendering path configuration component 199 can determine that the chunk should be rendered into GMEM.

[0096] Additionally, when the corresponding complexity value of a chunk fails to meet (e.g., is less than) a chunk complexity threshold, the rendering path configuration component 199 may configure the chunk in a second subset. That is, when a chunk represents a relatively less complex region of the target (such as a region with relatively little overdraw, blending, and / or objects to be rendered), the rendering path configuration component 199 may determine that the chunk should be rendered to system memory 124 instead of to GMEM.

[0097] Therefore, the rendering mode selection component 198 and the rendering path configuration component 199 can configure the rendering target process at two levels: (1) the entire frame; and (2) each chunk. At the entire frame level, the rendering mode selection component 198 can determine whether to render the target directly into system memory 124 (e.g., as a single chunk) or to render each chunk among multiple chunks into which the target is divided. At the chunk level, the rendering path configuration component 199 can determine for each of the multiple chunks whether to render the chunk into GMEM (and then resolve the chunks in GMEM to system memory 124), or to render the chunk directly into system memory 124 without rendering into GMEM. Accordingly, rendering of the target can be more efficient and / or can incur less overhead because the rendering process can be dynamically determined for both the entire frame target and (if applicable) the chunks into which the entire frame target is divided.

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

[0099] GPUs can process various types of data or data packets within the GPU pipeline. For example, in some aspects, a GPU can process two types of data or data packets, such as context register packets and draw call data. Context register packets can be a collection of global state information that manages how the graphics context will be processed, such as information about global registers, shaders, or constant data. For example, a context register packet may include information about the color format. In some aspects of context register packets, there may be bits indicating which workload belongs to the context register. Furthermore, there may be multiple functions or programs running simultaneously and / or in parallel. For example, a function or program may describe a specific operation, such as a color mode or color format. Therefore, context registers can define multiple states of the GPU.

[0100] Context states can be used to determine how individual processing units (e.g., vertex extractors (VFDs), vertex shaders (VSs), shader processors, or geometry processors) operate, and / or in which mode a processing unit operates. For this purpose, the GPU can use context registers and programming data. In some aspects, the GPU can generate workloads, such as vertex or pixel workloads, in the pipeline based on context register definitions of modes or states. Certain processing units (e.g., VFDs) can use these states to determine certain functions, such as how to assemble vertices. Because these modes or states can change, the GPU may need to modify the corresponding context. Furthermore, the workload corresponding to a mode or state can follow a constantly changing mode or state.

[0101] Figure 2 An example system 200 including a GPU 202 is shown, incorporating one or more technologies according to this disclosure. Figure 2 As shown, GPU 202 includes a command processor (CP) 210, a VFD 220, a VS 221, a vertex cache (VC) 222, a triangle setting engine (TSE) 223, a rasterizer (RAS) 224, a Z-process engine (ZPE) 225, a visibility stream compressor (VSC) 226, a pixel interpolator (PI) 227, a fragment shader (FS) 228, a (virtual) split cache (SC) 229, a rendering backend (RB) 230, and an L2 cache 231 (e.g., UCHE). Furthermore, GPU 202 may include GMEM 235, which may be on-chip memory. In some aspects, system 200 may include system memory 240, which may be communicatively coupled to GPU 202, for example, via a bus and / or other wired and / or wireless connections. In some aspects, system memory 240 may include a frame buffer.

[0102] Furthermore, system 200 may include one or more system configuration components 270. GPU 202 may include system configuration components 270 and / or be communicatively coupled to system configuration components 270, which may include one or more components that affect (e.g., enable, accelerate, limit, prevent, etc.) the performance of graphics processing by system 200. For example, system configuration components 270 may include hardware such as the GPU, GPU-related hardware, and / or other hardware that may be used during graphics processing. Each of the one or more system configuration components 270 may be configured to have characteristics and / or capabilities that positively, negatively, or neutrally affect the performance of graphics processing by system 200 (and specifically, GPU 202). Illustratively, system configuration components 270 may implement some concurrent operations commensurate with graphics processing, such as concurrent resolution, concurrent unresolution, and / or concurrent cleanup and resolution.

[0103] System configuration component 270 can provide information indicating one or more configurations associated with the capabilities and / or characteristics of system 200 (e.g., configurations associated with concurrent resolution, concurrent unresolution, and cleanup operations concurrent with resolution and / or unresolution). Through communicative coupling thereto, GPU 202 can obtain such information for use during graphics processing, such as for the dynamic selection of a first or second rendering mode when rendering a target and / or the dynamic selection of a first or second rendering path type in each of the multiple chunks into which the rendering target is divided.

[0104] although Figure 2The GPU 202 includes components 220-231 (e.g., one or more of components 220-231 may be processing units), but the GPU 202 may include multiple additional processing units and / or other components. Furthermore, components 220-231 are merely examples, and according to this disclosure, the GPU may use any combination and / or order of component (e.g., processing) units. For example, the GPU 202 may include GMEM 235, a frame buffer, or a similar memory unit configured to store images copied between system memories 240, and / or one or more of components 220-231 may include GMEM, a frame buffer, or a similar memory unit.

[0105] GPU 202 also includes a command buffer 250, which can store draw call group 212, context register group 260, and / or context state 261. Command buffer 250 can pass groups and / or states, such as draw call group 212, context register group 260, and / or context state 261, to CP 210, one or more of which may be received from system memory 240 in command buffer 250, for example, according to instructions from applications and / or other software and / or firmware.

[0106] like Figure 2 As shown, GPU 202 can utilize a CP (e.g., CP 210 and / or an accelerator) to perform various operations (such as by executing an instruction set). CP 210 can be implemented as hardware, software, firmware, or any combination thereof. In some aspects, CP 210 can receive instructions as a command stream, which can produce display content representing a complete frame target. Therefore, the command stream can include information for rendering the target. For example, the command stream can include information associated with primitives (e.g., triangles or other objects) to be rendered in the target.

[0107] In some configurations, CP 210 can execute code to dynamically select a first rendering mode (e.g., tiled rendering mode or tile-level rendering mode) or a second rendering mode (e.g., visibility direct mode) for rendering an object (e.g., a scene or image) on a display. In some other configurations, when a first rendering mode is selected for an object, CP 210 can execute code to dynamically select a first rendering pass type (e.g., including rendering the corresponding pass to GMEM 235) or a second rendering pass type (e.g., not including rendering the corresponding pass to GMEM 235) for each of the multiple passes into which the object is divided for rendering the object on a display.

[0108] In some aspects, at least one of the following operations may be implemented without hardware (e.g., implemented as software): selection of one of a first rendering mode and a second rendering mode (e.g., at the full frame level) and / or a corresponding selection of one of a first rendering pass type or a second rendering pass type (e.g., at the tile level). In some other aspects, at least one of the following operations may be implemented using both software and hardware: selection of one of a first rendering mode and a second rendering mode (e.g., at the full frame level) and / or a corresponding selection of one of a first rendering pass type or a second rendering pass type (e.g., at the tile level). Other implementations are also possible without departing from the scope of this disclosure.

[0109] The selection of a first or second rendering mode and / or the corresponding selection of a first or second rendering path type for each of multiple chunks (e.g., when the first rendering mode is selected for a full frame target) can be dynamic. Specifically, the selection of a rendering mode can be performed on a per-frame basis (e.g., the opposite of continuation or inference from a previous frame). Similarly, the selection of a corresponding rendering path type can be performed for each chunk into which the target is divided. Because this dynamic selection of the rendering mode and / or the corresponding rendering path type can configure the GPU 202 to perform relatively better (e.g., causing less overhead, consuming less power) modes and / or corresponding rendering path types, the GPU 202 can experience performance improvements over time (e.g., at least approximately 3% to 10% measurable performance improvement for some applications that provide the images / scenes to be rendered).

[0110] In some further aspects, the selection of a first or second rendering mode and / or the corresponding selection of a first or second rendering path type for each of multiple chunks (e.g., when the first rendering mode is selected for a full frame target) can be triggered by changes in the source of the rendering target, such as changes in the application, changes in active (e.g., focused) frames, and / or other similar changes. For example, in some cases, system 200 can be configured to use a specific rendering mode and / or rendering path type, but can then be triggered in response to triggering conditions (such as rendering frame layout and / or heuristics) to dynamically select the first or second rendering mode and / or dynamically select the first or second rendering path type.

[0111] In some aspects, CP 210 can be configured to parse command buffer 250 into context register groups (e.g., context register group 260) and / or draw call data groups (e.g., draw call group 212). CP 210 can then send context register group 260 or draw call data group 212 to components 220-231 (e.g., processing units or blocks) in GPU 202 via (separate) paths. Furthermore, command buffer 250 can alternate between different states of context registers and draw calls. For example, command buffer 250 can be constructed as follows: context register of context N, draw call of context N, context register of context N+1, and draw call of context N+1, and so on.

[0112] GPU 202 can be configured to render a complete frame target (e.g., an image, scene, etc.) in at least two different ways. Specifically, GPU 202 can be configured to render the target using at least rendering or tile-based rendering (which may be referred to as a first rendering mode in this disclosure). In some aspects, the first rendering mode may include a "visibility tile rendering mode" or a "tile rendering mode". When GPU 202 is configured in this first rendering mode, the target (e.g., an image, scene, frame, etc.) can be divided or separated into different segments or tiles. After the target is divided, each segment or tile can be rendered individually. Depending on the first rendering mode, GPU 202 can divide the target (e.g., a computer graphics image) into a grid format such that each part of the grid (e.g., a tile) is rendered individually. In some aspects, during the tiled pass, the target can be divided into different blocks or tiles. Furthermore, during the tiled pass, different primitives (e.g., triangles) can be shaded in some blocks, for example, using draw calls.

[0113] In some aspects, during a block-based path, depth information (e.g., using ZPE 225) can be computed, indicating the depth of one or more pixels (e.g., nearest pixel, farthest pixel, etc.) within a specific block or segment of the target. Segments can have a different size than each block (e.g., smaller); for example, each block can include multiple segments on which depth information can be computed. Because the depth information can be derived over segments (e.g., 8 pixels x 8 pixels, 32 pixels x 32 pixels, or other pixel dimensions) rather than through pixel-level depth testing, the depth information can be referred to as low-resolution Z (LRZ) information. LRZ information can be stored in an LRZ buffer (e.g., for each block).

[0114] In some aspects, during chunking, a visibility stream can be constructed, where visible primitives (e.g., triangles and / or other objects) and / or draw calls can be identified. Alternatively, during chunking (or other processing of primitives), the visibility of primitives can be determined for each chunk, for example, based on the input primitives included in the command stream associated with the target. For example, VFD 220 can determine some positional data associated with a set of vertices (e.g., vertices of one or more primitives, such as primitives visible in the corresponding chunk). VS 221 can process the vertex positional data for each chunk (e.g., data obtained from VFD 220). Potentially, VC 222 can store (e.g., cache) some vertex positional data from VS 221 and / or compute to determine the visibility of primitives for each chunk and / or facilitate the construction of a visibility stream for each chunk, for example, during chunking. The corresponding blocks can be processed by a stream compressor (e.g., VSC 226), which can use source pixels associated with rasterized primitives to generate a corresponding visibility stream for each block. In some aspects, the visibility stream can be generated based on the corresponding block, for example, based on primitive, rasterization, vertex, depth, and / or other information obtained from VFD 220, VS 221, VC 222, TSE 223, RAS 224, and / or ZPE 225.

[0115] In some additional or alternative aspects, the visibility of primitives with respect to each block can be determined, either based on classifying primitives into blocks according to their visibility within each block, or based on a corresponding visibility stream corresponding to each block. In some implementations, the visibility of primitives with respect to each block can be determined based on primitive, rasterization, vertex, depth, and / or other information obtained from VFD 220, VS 221, VC 222, TSE 223, RAS 224, and / or ZPE 225. For example, the command stream may include processing a corresponding subset of primitives associated with each block (e.g., at least partially visible in each block). In some configurations, the command stream may include partial vertex shading processing as part of determining the corresponding subset of primitives associated with the block, for example, causing the VS post-position of the corresponding subset of primitives to be generated for per-block processing.

[0116] In some aspects, GPU 202 can apply the drawing or rendering process to different tiles or blocks. For example, GPU 202 can render to a tile and then perform all drawing on the primitives or pixels within that tile. Further, GPU 202 can render to another tile and perform drawing on the primitives or pixels within that tile. Thus, in some aspects, there may be a small number of tiles X (e.g., X tiles could be four or six tiles) that cover all drawing on a surface. Further, GPU 202 can loop through all drawing within a tile, but perform drawing only on visible drawing calls (e.g., drawing calls that include visible geometry). In some aspects, such as in the visibility path and / or the tiled path, a visibility stream can be generated to determine the visibility information of each primitive in the target (e.g., an image or scene). For example, such a visibility stream can identify whether a primitive is visible. In some aspects, this information can be used to remove invisible primitives, for example, in the rendering path. In addition, at least some primitives that are marked as visible can be rendered in the rendering pass.

[0117] In some aspects of the first rendering mode, multiple processing stages or pathways may exist. For example, rendering may be performed in at least two pathways (e.g., a visibility or tile-visibility pathway and a rendering or tile-rendering pathway). During the visibility pathway, GPU 202 may input the rendering workload, record the position of primitives or triangles, and then determine which primitives or triangles fall into which tile or region. In some aspects of the visibility pathway, GPU 202 may also identify or mark the visibility of each primitive or triangle in the visibility stream.

[0118] During the rendering pipeline, the GPU 202 can take in a visibility stream and process one chunk or region at a time. In some aspects, the visibility stream can be analyzed to determine which primitives or primitive vertices are visible or invisible. Therefore, visible primitives or primitive vertices can be processed. By doing so, the GPU 202 can reduce the unnecessary workload of processing or rendering invisible primitives or triangles.

[0119] In some aspects, certain types of primitive geometry, such as location-only geometry, can be processed during the visibility path. Furthermore, primitives can be classified into different chunks or regions based on their position or location. In some cases, classifying primitives or triangles into different chunks can be performed by determining visibility information for those primitives or triangles. For example, GPU 202 can determine visibility information for each primitive in each chunk or region or write it to, for example, system memory 240. This visibility information can be used to determine or generate a visibility stream.

[0120] In the rendering pipeline, primitives in each chunk can be rendered individually. In these cases, the visibility stream can be retrieved from memory used to discard primitives that are not visible to that chunk. In some aspects, each chunk is rendered individually in GMEM 235, for example, until all chunks have been rendered in GMEM 235, and thus the entire image is in GMEM 235. The image can then be resolved (stored) from GMEM 235 to system memory 240, for example, by copying the image from GMEM 235. Specifically, once all (visible) primitives or triangles have been fully rendered in GMEM 235, the data corresponding to each chunk rendered in GMEM 235 can be stored in the corresponding region of the frame buffer of GMEM 235. Depending on the aspect, "resolved" may also be referred to as "stored," "[chunk] GMEM to system memory copy," or other terms with the same or similar effect.

[0121] In some cases, the first rendering mode may include one or more unparse (load) operations, which may be complementary to a parse (store) operation performed to first render the image to GMEM 235 and then copy it to system memory 240. Depending on the context, "unparse" may also be referred to as "load," "[chunked] system memory to GMEM copy," or other terms with the same or similar effects.

[0122] To render an image based on another image (e.g., a previous image) in a first rendering mode, a subset of multiple blocks can be modified, while different subsets of the multiple blocks can remain unchanged. For this purpose, the complete image (e.g., all blocks in the multiple blocks) can be unparsed (loaded) from system memory 240 into GMEM 235, and the modified blocks can then be rendered into GMEM 235, while the unchanged blocks can remain unchanged in GMEM 235. Subsequently, all blocks in GMEM 235 can be parsed into system memory 240. Specifically, data for each block in GMEM 235 can be copied to a corresponding region in the frame buffer of system memory 240, where each region corresponds to the corresponding block into which the image is divided.

[0123] Depending on several aspects, at least two rendering passes can be executed for multiple blocks into which the target is divided. A GPU or GPU architecture (e.g., GPU 202) can configure each of the multiple blocks into one of a first subset or a second subset, where the first subset is rendered according to a first rendering pass type, and the second subset is rendered according to a second rendering pass type. For the first type of rendering pass, the blocks in the first subset can be rendered as described above, since each of these blocks can be rendered into GMEM 235, and then all blocks in GMEM 235 can be resolved into system memory 240.

[0124] However, for the second type of rendering pass, chunks in the second subset can be rendered directly to system memory 240 instead of to GMEM 235. The second chunk subset can be rendered directly to system memory 240 in a single rendering pass. A chunk mask can be used to render the second chunk subset to system memory 240 for early Z-rejection. For example, the chunk mask can be based on an internal depth buffer, which can be generated according to ZPE 225. The chunk mask can cause some data (e.g., pixel data) at certain depths to be rejected or discarded, for example, making such data (e.g., pixel data) not rendered, such as when pixels at certain depths are occluded and / or not visible in the displayed content when output to the display.

[0125] In some respects, the first type of rendering pass can be executed before the second type of rendering pass. For example, the first chunk subset can be rendered into GMEM 235 first, and once rendered into GMEM 235, it can be resolved into system memory 240; subsequently, the second chunk subset can be rendered into system memory 240 in a single rendering pass for all chunks in the second chunk subset.

[0126] In addition to the first rendering mode (e.g., rendering the target at a tile level in the first rendering mode), the GPU or GPU architecture of this disclosure (e.g., GPU 202) may also be configured with a second rendering mode for rendering the entire frame target; for example, the second rendering mode may be referred to as the visibility direct mode. According to some implementations, the visibility direct mode can be considered a primarily software-based rendering mode. However, similar to the tile rendering mode and the first rendering pass type, rendering to GMEM 235 (and then resolving to system memory 240) can be considered a primarily hardware-based rendering mode.

[0127] To render in a second rendering mode (e.g., visibility direct mode), the driver or CPU can replicate the entire frame geometry by processing each view at a time. Furthermore, several different states can change depending on the view. Therefore, in visibility direct mode, the software can replicate the entire workload by changing some states that can be used to render for each viewpoint in the image.

[0128] In some respects, increased overhead may exist because the GPU 202 may submit the same workload multiple times for each viewpoint in the target. In contrast, in the case of tiled rendering mode, the GPU 202 and / or other hardware can handle the copying or processing of geometry for each viewpoint in the target. Therefore, the GPU 202 and / or other hardware can manage the copying or processing of primitives or triangles for each viewpoint in the target.

[0129] Based on the visibility direct mode, the target (e.g., the image) can be rendered directly into system memory 240, for example, because the entire frame geometry is copied by processing a single view. Therefore, it is possible to avoid rendering multiple chunks or tiles into GMEM 235 to store the complete image in GMEM 235. Specifically, the complete frame target (e.g., the entire image or the complete frame geometry) can be processed as a whole, rather than separating the target into multiple chunks (e.g., X chunks), each corresponding to a discrete segment of the complete frame image.

[0130] Potentially, the LRZ buffer can be based on the visibility path (and / or the chunking path) used for a single chunk in visibility direct mode. The LRZ buffer can include information indicating the number of visible pixels in the full frame target. For example, ZPE 225 can generate LRZ information indicating the number of visible pixels in the full frame target for VSC 226.

[0131] However, for visibility direct mode, the entire frame target can be treated as a single chunk. A visibility stream (e.g., a full frame visibility stream) can be constructed for each single chunk corresponding to the entire frame target. Because the entire frame target can be treated as a single chunk, the full frame visibility stream can include information identifying visible primitives or triangles in the entire frame target, as well as draw calls associated with the entire frame target. In some aspects, a stream compressor (e.g., VSC226) can be configured for full frame targets in visibility direct mode.

[0132] Potentially, the overhead associated with GPU 202 generating a full frame visibility stream for a single chunk corresponding to the target can be “hidden” by the overhead caused by one or more parallel operations (such as one or more current or previous rendering paths performed for each chunk in multiple chunks corresponding to the corresponding segment in the segments into which the target is divided). For example, the rendering paths processed by GPU 202 for each chunk in multiple chunks corresponding to the corresponding segment in the segments into which the target is divided (such as rendering paths for multiple chunks after the full frame visibility path and / or (previous) rendering paths for multiple chunks in parallel with the full frame visibility path) can completely cover in time the overhead caused by the full frame visibility path for a single chunk corresponding to the target.

[0133] Refer again Figure 2 In some aspects of GPU 202, CP 210 can be configured to select between a first rendering mode (e.g., a tiled rendering mode or a tile-level rendering mode) and a second rendering mode (e.g., a visibility direct mode). In some further aspects, for example, when the first rendering mode is selected, CP 210 can be configured to select between a first rendering pass type (e.g., including rendering to GMEM 235) and a second rendering pass type (e.g., not including rendering to GMEM 235). CP 210 can perform such selection and / or determination dynamically, for example, based on data and / or grouping in the GPU pipeline, based on context and / or context changes, etc. CP 210 can select one of the two modes (and, if applicable, one of the two rendering pass types) based, for example, on a set of conditions associated with one or more of the visibility stream, the LRZ buffer, the system configuration component 270, and / or other conditions / parameters.

[0134] The configuration for selecting between a first rendering mode and a second rendering mode and / or a first rendering pass type and a second rendering pass type can be constructed as at least one command stream, comprising a set of command streams (e.g., including instructions and / or operations) that configures CP 210 to operate under one of the first or second rendering modes and (if applicable) one of the first or second rendering pass types. For example, the command streams can be stored in a command buffer 250, and commands can be issued to CP 210 from there. In effect, the configuration for dynamically switching between the first and second rendering modes (and potentially dynamically switching between the first and second rendering pass types) of GPU 202 can bypass the CPU and / or other processing separate from GPU 202, which can reduce overhead on the CPU and / or other processing units in the device in which GPU 202 is implemented.

[0135] Initially, for example, the command stream may include a set of commands for determining (e.g., detecting, calculating, etc.) a set of conditions (e.g., parameters, factors, variables, etc.) that are associated with or otherwise affect the rendering of one or more targets. For example, the set of conditions may be based on one or more of the following: (1) multiple visibility streams, each corresponding to a multiple block into which the target is divided (e.g., X blocks); (2) a single visibility stream, each corresponding to a single block corresponding to the target; (3) at least one depth buffer that indicates the set of visible pixels in at least one segment of the target (e.g., a segment of the target may include a block of pixels of a specific dimension); (4) hardware and / or software capabilities associated with the rendering target; and / or (5) other conditions associated with the rendering target.

[0136] The command stream may include a set of commands that configure CP 210 to perform a set of visibility paths (and / or chunking paths) against the target. In some aspects, CP 210 may obtain a set of LRZ information based on the set of visibility paths (and / or chunking paths), for example, in at least one LRZ buffer, each of which corresponds to at least one chunk in X+1 chunks. For a first rendering mode, CP 210 may obtain LRZ information for each of the multiple chunks into which the target is divided. For a second rendering mode, CP 210 may obtain LRZ information for a single chunk corresponding to the target.

[0137] In some other aspects, CP 210 can obtain a set of visibility streams based on executing a set of visibility paths (and / or performing chunked paths), each of the visibility stream sets corresponding to at least one chunk of the target (e.g., a full-frame image or a full-frame scene). For a first rendering mode, CP 210 can execute multiple visibility paths for each of the multiple chunks into which the target is divided (e.g., X visibility paths for each of X chunks). For a second rendering mode, CP 210 can execute a single visibility path for a single chunk corresponding to the target (e.g., one visibility path for a single chunk corresponding to the target).

[0138] Then, CP 210 can obtain visibility streams for each block corresponding to a portion of the target and / or for a single block corresponding to the target among multiple blocks. Depending on some aspects, the target can be divided into X blocks, and therefore CP 210 can obtain X+1 visibility streams for the X blocks and the single block corresponding to the target. Alternatively or additionally, CP 210 can obtain LRZ information corresponding to the target based on at least one of the X+1 visibility paths (or block-making paths). That is, CP 210 can obtain low-resolution pixel depths for each block among the X blocks and / or for the single block corresponding to the target. For example, after obtaining LRZ information for VSC 226, CP 210 can obtain the number of visible pixels in the target (e.g., the number of pixel depths in a specific segment for a resolution lower than the pixel-level resolution).

[0139] The command stream can be configured such that CP 210 selects either a first rendering mode or a second rendering mode, for example, based on a set of conditions. This set of conditions can be given by at least one of the following: overhead, workload, capabilities (e.g., limitations), computation, etc., of the system configuration component 270 (these can have a direct or indirect impact on the rendering target). In some configurations, the set of conditions can be based on at least one LRZ buffer and / or at least one visibility stream from X+1 visibility streams. In some other configurations, the set of conditions can be based on the system configuration component 270, such as the system configuration component 270's ability to perform various operations for the rendering target (e.g., limitations).

[0140] A non-limiting list of example operations may include, in particular, blending, clearing (e.g., setting all pixel color values ​​to default values, such as transparent or white), parsing or storing, unparsing or loading, detecting overdraw, etc. Furthermore, some example operations may be concurrent, such as concurrent parsing and / or unparsing, concurrent parsing and / or storing while clearing. Such concurrent operations can occur when at least two of X chunks are stored, loaded, cleared, or otherwise used concurrently.

[0141] By way of illustration, concurrent parsing may include concurrently parsing at least two blocks from GMEM 235 to system memory 240, such as concurrently parsing blocks (n) and blocks (m) in [block (0), block (1), block (2), ..., block (X-1)], where 0 ≤ m ≤ X-1, 0 ≤ n ≤ X-1 and m ≠ n. By way of illustration, concurrent store-time clearing may include concurrently storing (parsing) blocks (n) from GMEM 235 to system memory 240 and clearing blocks (m) from the X blocks, which may reduce the overhead associated with clearing blocks (m) (e.g., the overhead associated with clearing blocks (m) may be “hidden” from the overhead associated with storing (parsing) blocks (n) from GMEM 235 to system memory 240). As a further explanation, concurrent parsing and unparsing can include concurrently parsing block (n) from GMEM 235 to system memory 240 and unparsing block (m) from system memory 240 to GMEM 235. In yet another explanation, concurrent unparsing can include concurrently unparsing at least two of the X blocks from system memory 240 to GMEM 235, for example, concurrently unparsing block (n) and block (m).

[0142] Therefore, CP 210 can determine (e.g., compute, estimate, etc.) one or more conditions associated with: (1) parsing or storing; (2) canceling parsing or loading; (3) blending; (4) overdrawing; and / or (5) another operation commensurate with the rendering target. In some configurations, one or more conditions may be based on overhead, which may represent the amount and / or frequency of the operation (e.g., instruction cycles), memory overhead due to the operation, power overhead due to the operation, processor overhead due to the operation, and / or another metric that can be used to evaluate the consumption of one or more resources (e.g., power, processor, memory, and / or other computing resources).

[0143] For example, conditions can be determined based on a comparison of overhead with a corresponding threshold (such as a pre-configured threshold or an adjustable / configurable threshold that can be dynamically adjusted based on the target and / or the source of the target (e.g., the application). Illustratively, if the overhead fails to meet (e.g., is greater than or equal to) the corresponding threshold, the overhead can be considered inefficient, which can be weighted by CP 210 to favor other modes (e.g., a second rendering mode). Otherwise, if the overhead meets (e.g., is less than) the corresponding threshold, the overhead can be considered efficient, which can be weighted by CP 210 to favor the associated mode (e.g., a first rendering mode).

[0144] In some other configurations, one or more conditions may be based on the ability of system configuration component 270 to perform one or more operations commensurate with tiled rendering or direct visibility mode. Because hardware components may vary across devices, some devices implementing GPU 202 may include various hardware components that are insufficient to meet the minimum performance expectations for rendering an image using either tiled rendering or direct visibility mode, or that are constrained by limited capabilities that effectively prevent the performance of some operations necessary for efficiently rendering an image using either tiled rendering or direct visibility mode. Therefore, CP 210 can determine one or more conditions under which system configuration component 270 can satisfactorily perform one or more operations associated with either tiled rendering or direct visibility mode, and CP 210 can take such hardware-related conditions into account when selecting between tiled rendering and direct visibility mode.

[0145] In one aspect, CP 210 may determine at least one overhead associated with parsing or storing, which is proportionate to X visibility streams associated with a first rendering mode. CP 210 may determine (e.g., estimate, compute, etc.) the overhead on GPU 202 and / or system configuration component 270 for parsing or storing some or all of the X chunks to be rendered into GMEM 235 from GMEM 235 to system memory 240. Potentially, the parsing or storing may be associated with depth information (e.g., number of pixel depths) of one or more of the X chunks into which the target can be divided. For example, the parsing or storing from GMEM 235 to system memory 240 may be based on one or more LRZ buffers associated with multiple chunks into which the target is divided, and the one or more LRZ buffers may be obtained based on visibility paths (or chunking paths) performed for the multiple chunks.

[0146] CP 210 can determine (e.g., estimate, compute, etc.) the parsing or storage overhead on GPU 202 and / or system configuration component 270 for parsing or storing data from GMEM 235 to system memory 240 when rendering at least a portion of the target. The parsing or storage overhead (e.g., the time determined / estimated for parsing or storage) or the amount of parsing or storage can be compared to at least one parsing / storage threshold.

[0147] Such a condition associated with parsing or storage can indicate that CP 210 should select the second rendering mode when the overhead (or quantity) meets (e.g., is greater than or equal to) at least one parsing / storage threshold (e.g., because the visibility direct mode can cause lower overhead, be more efficient, etc.). However, such a condition associated with parsing or storage can indicate that CP 210 should select the first rendering mode when the overhead or quantity of parsing or storage fails to meet (e.g., is less than) at least one parsing / storage threshold.

[0148] In another aspect, CP 210 can determine the conditions for unparse or load associated with the rendering target. For example, such conditions can be based on at least one overhead associated with unparse or load, which is commensurate with the X visibility streams associated with the first rendering mode. One or more unparses or stores can be performed when modifying one or more tiles from existing content (e.g., a previous image) in system memory 240 to render the target in GMEM 235 (e.g., in contrast to clearing system memory 240 and / or GMEM 235 to render the entire frame target from scratch). Potentially, the number of unparses or loads may affect the number of parses or stores, for example, because after unparse or loading the content of system memory 240 (e.g., the previous target) into GMEM 235, only those tiles modified within GMEM 235 can be parsed or stored from GMEM 235 into system memory 240.

[0149] According to one configuration, cancel parsing or loading can be associated with color. For example, cancel parsing or loading can be associated with one or more modifications to one or more colors on one or more blocks. At least one overhead for at least one cancel parsing or loading can be determined based on the number of pixel colors for each of the X blocks for the target and / or the number of pixel colors for each of the X blocks modified from the contents of system memory 240.

[0150] According to another configuration, de-parsing or loading can be associated with depth. For example, de-parsing or loading can be associated with one or more modifications to one or more pixel depths (e.g., low-resolution pixel depths) on one or more blocks. At least one overhead for at least one de-parsing or loading can be determined based on the number of pixel depths for each of the X blocks for the target and / or the number of pixel depths for each of the X blocks modified from the contents of system memory 240. Since such depth information can be provided by an LRZ buffer, depth de-parsing or loading can be based on the LRZ buffer, which is obtained, for example, from each of the X visibility paths (or the block-making path).

[0151] CP 210 can determine (e.g., estimate, compute, etc.) the overhead on GPU 202 and / or system configuration component 270 for cancel parsing or loading from system memory 240 to GMEM 235 during rendering of a target. The overhead of cancel parsing or loading (e.g., the time determined / estimated for cancel parsing or loading) or the amount of cancel parsing or loading can be compared to at least one cancel parsing / loading threshold.

[0152] The condition that the overhead of canceling parsing or loading (and / or the number of cancels) satisfies (e.g., greater than or equal to) at least one cancel parsing / loading threshold can indicate that CP 210 should select the second rendering mode (e.g., because the visibility direct mode can cause lower overhead, can be more efficient, etc.). However, the condition that the overhead of canceling parsing or loading or the number of cancels is not satisfied (e.g., less than) at least one cancel parsing / loading threshold can indicate that CP 210 should select the first rendering mode.

[0153] In another aspect, CP 210 may determine at least one condition based on blending and / or the associated overhead. According to one configuration, CP 210 may determine whether blending is enabled, for example, for rendering at least one of X chunks. According to another configuration, CP 210 may determine the overhead on GPU 202 and / or system configuration component 270 based on the number of X chunks in which blending is enabled, the number of primitives (e.g., triangles) blended in one or more of the X chunks, and / or the number of draws indicating blending is enabled (e.g., the number of draw call groups 212). For example, CP 210 may compare at least one blending threshold with at least one of the following: the number of blended primitives (e.g., triangles), the ratio of the number of blended primitives to the number of unblended primitives, the number of X chunks in which blending is enabled, the ratio of the number of X chunks in which blending is enabled to the number of X chunks in which blending is disabled, the number of draws in which blending is enabled, and / or the ratio of the number of draws in which blending is enabled to the number of draws in which blending is disabled.

[0154] Depending on the device and / or GPU configuration, blending may be better suited (e.g., causing less overhead, being more efficient, etc.) to render chunk-by-chunk (e.g., as in chunked rendering mode or rendering paths for first and second chunk subsets) rather than directly rendering the entire frame target (e.g., as in visibility direct mode). Therefore, if the conditions for enabling blending, or the conditions for the quantity or ratio of primitives, chunks, and / or draws associated with enabling blending, are satisfied (e.g., greater than or equal to) at least one blending threshold, it may indicate that CP 210 should select the first rendering mode when rendering the target (e.g., because visibility direct mode may cause more overhead, may be less efficient, etc.). However, if the conditions for disabling blending, or the conditions for the quantity or ratio of primitives, chunks, and / or draws associated with disabling blending, are not satisfied (e.g., less than) at least one blending threshold, it may indicate that CP 210 should select the second rendering mode (e.g., visibility direct mode).

[0155] On the other hand, CP 210 can determine at least one condition based on overdraw and / or its associated overhead. Overdraw can occur in some cases when pixels are rendered multiple times (such as when two or more primitives are rendered at the same or overlapping locations in a scene or image). Overdraw can potentially cause inefficient or harmful overhead, for example, because only the nearest or topmost primitive can be visible in a scene or image, so rendering pixels more than once (e.g., for the bottommost primitive and / or the farthest pixel) may be unnecessary, and / or may result in unnecessary rendering of pixels, which could distort pixel colors. Therefore, CP 210 can detect overdraw.

[0156] In some configurations, CP 210 can detect overdraw by determining the quotient of the number of visible pixels divided by the total number of pixels to be drawn. For example, CP 210 can determine the number of visible pixels in a full frame after determining the (low-resolution) pixel depth used for VSC 226 (e.g., using ZPE 225). CP 210 can then compare this quotient to an overdraw threshold.

[0157] A high overdraw condition can be identified or detected when the quotient meets (e.g., greater than or equal to) an overdraw threshold, and a low or no overdraw condition can be identified or detected when the quotient fails to meet (e.g., less than) the overdraw threshold. A high overdraw condition can instruct CP 210 to select a first rendering mode (e.g., because high overdraw may be associated with higher complexity, a tiled rendering mode or per-tile rendering may be more efficient and / or incur less overhead than a visibility-direct mode). However, a low / no overdraw condition can instruct CP 210 to select a second rendering mode (e.g., because a visibility-direct mode may be more efficient and incur less overhead when rendering targets with relatively lower complexity (such as low or no overdraw), etc.).

[0158] The overdraw threshold can be a pre-configured value; for example, it could be equal to 2.0. However, the overdraw threshold can be an adjustable or configurable parameter that can be modified based on the target and / or its source. For example, the overdraw threshold can be dynamically adjusted based on the application on which the rendering target is based. Therefore, the overdraw threshold can be adjusted across applications, for example, based on the application type, historical data associated with the application, and / or other factors associated with the application.

[0159] In another aspect, CP 210 can determine at least one condition for selecting between a first rendering mode and a second rendering mode based on whether system configuration component 270 is capable (satisfactorily) of executing concurrent operations associated with the rendering target. The concurrent operations can be at least two operations executed in parallel, such that the execution of each of the two operations at least partially overlaps in time. For example, CP 210 can concurrently execute at least two operations by sending corresponding grouped sets for each of the at least two operations to components 220-231 of GPU 202 via separate paths.

[0160] In one configuration, CP 210 can determine whether the system configuration component 270 is capable of performing concurrent resolution and / or unresolution. For example, CP 210 can determine whether the system configuration component 270 can concurrently resolve blocks (n) and blocks (m) out of X blocks from GMEM 235 to system memory 240, concurrently unresolution blocks (n) and blocks (m) out of X blocks from system memory 240 to GMEM 235, and / or concurrently resolve blocks (n) and unresolve blocks (m). If CP 210 determines conditions under which the system configuration component 270 cannot perform concurrent resolution and / or unresolution, these conditions can instruct CP 210 to select a second rendering mode, for example, because the inability to perform concurrent resolution or unresolution may cause additional overhead when rendering the target. Otherwise, if CP 210 determines the conditions that enable concurrent resolution and / or cancellation of resolution for system configuration component 270, then those conditions may instruct CP 210 to select the first rendering mode.

[0161] In another configuration, CP 210 can determine conditions under which system configuration component 270 can satisfactorily perform concurrent parsing and / or deparsing. That is, CP 210 can determine this condition based on whether the overhead associated with concurrent parsing and / or deparsing meets (e.g., is less than) at least one concurrent parsing / deparsing threshold. For example, if CP 210 determines that conditions regarding the satisfactory performance of concurrent parsing and / or deparsing, such as when the overhead for concurrent parsing and / or deparsing fails to meet (e.g., is less than) a concurrent parsing / deparsing threshold, then this condition can instruct CP 210 to select a first rendering mode. However, if CP 210 determines that the overhead for concurrent parsing and / or deparsing meets (e.g., is greater than or equal to) a concurrent parsing / deparsing threshold, or if CP 210 determines that concurrent parsing and / or deparsing is not fully enabled due to limitations of system configuration component 270, then this condition can instruct CP 210 to select a second rendering mode.

[0162] In a further configuration, CP 210 can determine the conditions under which system configuration component 270 can perform a store-time clear operation. For example, CP 210 can determine whether system configuration component 270 can concurrently resolve blocks (n) out of X blocks from GMEM 235 to system memory 240 and clear blocks (m). If CP 210 determines the conditions under which system configuration component 270 cannot perform store-time clear, these conditions can instruct CP 210 to select a second rendering mode, for example, because the inability to perform concurrent store-time clear may cause additional overhead when rendering targets. If CP 210 determines the conditions under which system configuration component 270 can perform store-time clear, these conditions can instruct CP 210 to select a first rendering mode, for example, because enabling store-time clear can reduce overhead for direct rendering targets.

[0163] In another configuration, CP 210 can determine conditions under which system configuration component 270 can satisfactorily perform concurrent parsing and / or deparsing. That is, CP 210 can determine this condition based on whether the overhead associated with concurrent parsing and / or deparsing meets (e.g., is less than) at least one concurrent parsing / deparsing threshold. For example, if CP 210 determines that conditions regarding the satisfactory performance of concurrent parsing and / or deparsing, such as when the overhead for concurrent parsing and / or deparsing fails to meet (e.g., is less than) a concurrent parsing / deparsing threshold, then this condition can instruct CP 210 to select a first rendering mode. However, if CP 210 determines that the overhead for concurrent parsing and / or deparsing meets (e.g., is greater than or equal to) a concurrent parsing / deparsing threshold, or if CP 210 determines that concurrent parsing and / or deparsing is not fully enabled due to limitations of system configuration component 270, then this condition can instruct CP 210 to select a second rendering mode.

[0164] Therefore, CP 210 can select one of a first or second rendering mode based on a set of conditions, which may include one or more of the conditions described herein. For example, CP 210 may receive a command stream from command buffer 250, determine the set of conditions based on the command stream, and then select between the first and second rendering modes based on the set of conditions. CP 210 may include at least one algorithm (e.g., function, method, etc.) that takes the set of conditions as input or parameters and returns an output or result indicating whether the first or second rendering mode should be selected during evaluation (or execution). In some aspects, each condition in the set of conditions may be equally weighted during the evaluation of at least one algorithm. In some other aspects, each condition in the set of conditions may be assigned a corresponding weight, such that the evaluation of at least one algorithm is more likely to result in either the first or second rendering mode based on which conditions are assigned larger weights and which conditions are assigned smaller weights.

[0165] Then, CP 210 can render the target using either the first rendering mode or the second rendering mode. For example, CP 210 can be configured to parse command buffer 250 into context register groups (e.g., context register group 260) and / or draw call data groups (e.g., draw call group 212), and can then send context register group 260 and / or draw call data group 212 to components 220-231 via (separate) paths, depending on which of the first or second rendering modes is selected. Selecting either the first or second rendering mode can cause one or more of components 220-231, as well as CP 210, to be (re)configured according to the selected rendering mode.

[0166] In an illustrative manner, when the second rendering mode (e.g., direct visibility mode) is selected, CP 210 can configure the target to be rendered directly into system memory 240. Therefore, when the second rendering mode is selected, CP 210 can avoid rendering the target in GMEM 235. Furthermore, CP 210 can utilize the full frame visibility stream obtained from the full frame visibility path corresponding to a single chunk of the target, as well as the LRZ buffer. By doing so, the performance of GPU 202 in rendering the target in the second rendering mode can significantly improve the performance of one or more other direct rendering modes, such as those in which images / frames / scenes are rendered directly into system memory 240 (bypassing GMEM 235) but do not obtain a visibility stream and / or LRZ buffer.

[0167] When CP 210 selects a first rendering mode to render the target, GPU 202 can be configured to (dynamically) determine how to render each of the X chunks during the rendering pass. A command stream consisting of a set of commands (e.g., including instructions and / or operations) can be constructed to configure each of the X chunks into one of the first or second subset of chunks. CP 210 can execute the command stream (e.g., when the first rendering mode is selected) to render each of the X chunks according to either a first rendering pass type (e.g., including rendering chunks to GMEM 235) or a second rendering pass type (e.g., including rendering chunks directly to system memory 240 without rendering to GMEM 235). For example, the command stream can be stored in command buffer 250, and commands can be issued to CP 210 from there.

[0168] The command stream may include a set of commands for determining (e.g., detection, computation, etc.) a set of conditions (e.g., parameters, factors, variables, etc.) associated with or otherwise affecting each of the X blocks. For example, the set of conditions may be based on one or more of the following: (1) multiple visibility streams corresponding to the X blocks into which the target is divided; (2) at least one depth buffer indicating the set of visible pixels in at least one segment of the target (e.g., a segment of the target may include a block of pixels of a specific dimension); (3) hardware and / or software capabilities associated with each of the X blocks into which the rendering target is divided; and / or (5) other conditions associated with each of the X blocks into which the rendering target is divided.

[0169] The command flow may include a set of commands for determining (e.g., accounting, computation, etc.) a corresponding complexity value for each of the X blocks. In some aspects, the corresponding complexity value may be determined for a given block among the X blocks based on at least one of the following: overdraw associated with that given block, blending associated with that given block, and / or the number of objects (e.g., primitives, triangles, etc.) of the target that are at least partially represented in that given block. In some other aspects, the corresponding complexity value for each of the X blocks may additionally or alternatively be based on one or more of the system configuration components 270, such as whether the system configuration component 270 enables concurrent resolution and / or concurrent store-time cleanup operations.

[0170] Therefore, CP 210 can execute a set of commands in the command stream for determining a corresponding complexity value for each of the X blocks. CP 210 may include at least one algorithm (e.g., a function, method, etc.) that receives information associated with the block (and / or information from system configuration component 270) as input or parameters, and returns an output or result indicating the complexity value during evaluation (or execution). In some aspects, different pieces of information may be equally weighted during the evaluation of at least one algorithm. In some other aspects, different pieces of information may be assigned appropriate weights, making the evaluation of at least one algorithm more likely to result in a higher or lower complexity value based on which piece of information is assigned a larger weight and which piece of information is assigned a lower weight.

[0171] In some aspects, CP 210 may determine a corresponding complexity value for a given block based on the mixing and / or the overhead associated with that mixing in the respective block of X blocks. For example, CP 210 may determine the corresponding complexity value based on the number of primitives (e.g., triangles) mixed in the corresponding block and / or based on the number of draws associated with the corresponding block indicating that mixing is enabled (e.g., the number of draw call groups 212). For example, CP 210 may determine the number of primitives (e.g., triangles) mixed in the corresponding block, the ratio of the number of primitives mixed to the number of primitives not mixed in the corresponding block, the number of draws associated with the corresponding block where mixing is enabled, and / or the ratio of the number of draws associated with the corresponding block where mixing is enabled to the number of draws associated with the corresponding block where mixing is disabled.

[0172] Depending on the device and / or GPU configuration, blending may be more suitable (e.g., causing less overhead, being more efficient, etc.) for rendering the corresponding chunk to GMEM 235 rather than rendering the corresponding chunk directly to system memory 240. Therefore, if at least one blending chunk threshold is satisfied (e.g., greater than or equal to) a blending enable condition associated with the corresponding chunk, or a condition associated with the corresponding chunk where the quantity or ratio of primitives and / or draw quantities associated with blending enable is satisfied (e.g., greater than or equal to), CP 210 may instruct CP 210 to select a first rendering path type when rendering the corresponding chunk; for example, the corresponding chunk should be rendered to GMEM 235 and then resolved to system memory 240. Therefore, CP 210 may increase the corresponding complexity value for the corresponding chunk based on such conditions. For example, CP 210 may increment the corresponding complexity value for the corresponding chunk in response to enabling blending in the corresponding chunk and / or in response to the blending amount and / or the ratio associated with the blending amount satisfying (e.g., greater than or equal to) at least one blending chunk threshold.

[0173] However, if the conditions for disabling blending for a given chunk or the conditions for the blending amount and / or the ratio associated with the blending amount are not met (e.g., less than) at least one blending chunk threshold, CP 210 may indicate that it should select a second rendering path type. For example, since rendering the given chunk directly to system memory 240 is more efficient for lower complexity, chunks with relatively low (or no) blending amounts can be rendered directly more efficiently (compared to rendering to GMEM 235). Therefore, CP 210 may reduce (e.g., decrease) the corresponding complexity value for the given chunk based on the relatively low (or no) blending amount associated with it.

[0174] In a further aspect, CP 210 can determine at least one condition based on overdraw and / or the associated overhead. CP 210 can detect overdraw at the block level, for example, for each of the X blocks into which the target is divided. Overdraw can increase the complexity commensurate with rendering the corresponding block, and therefore, for blocks with relatively large amounts of overdraw, rendering the block to GMEM 235 can be relatively more efficient, while for blocks with low (or no) amounts of overdraw, rendering the block directly to system memory 240 can be relatively more efficient.

[0175] CP 210 can be configured to determine the corresponding overdraw (and / or its amount) for each of the X blocks. For example, CP 210 can determine the overdraw for a given block by determining the (low-resolution) pixel depth (e.g., using ZPE 225) (e.g., for the corresponding visibility stream corresponding to the given block). In some aspects, CP 210 can determine the overdraw by determining the quotient or ratio of the number of visible pixels associated with the given block to the total number of pixels associated with the given block. However, CP 210 can determine the overdraw associated with a given block in different ways depending on various aspects.

[0176] In some aspects, CP 210 can determine that a corresponding block is associated with a relatively high amount of overdraw. For example, CP 210 can compare an overdraw value indicating the amount of overdraw associated with a corresponding block to at least one overdraw block threshold. For example, the overdraw value can include the quotient or ratio of the number of visible pixels associated with the corresponding block to the total number of pixels associated with the corresponding block. When the overdraw value (e.g., the quotient or ratio of visible pixels to total pixels for the corresponding block) meets (e.g., greater than or equal to) the overdraw block threshold, CP 210 can determine that the corresponding block is associated with a high overdraw condition. However, when the overdraw value (e.g., the quotient or ratio of visible pixels to total pixels for the corresponding block) does not meet (e.g., less than) the overdraw block threshold, CP 210 can determine that the corresponding block is associated with a low (or no) overdraw condition.

[0177] When CP 210 determines that a corresponding chunk is associated with a high overdraw condition, CP 210 can determine that the corresponding chunk is relatively more complex, and therefore, rendering the corresponding chunk to GMEM 235 is more efficient for the corresponding chunk. Therefore, CP 210 can increase (e.g., increment) the corresponding complexity value associated with the corresponding chunk. However, when CP 210 determines that a corresponding chunk is associated with a low (or no) overdraw condition, CP 210 can determine that the corresponding chunk is relatively less complex, and therefore, rendering the corresponding chunk directly to system memory 240 is more efficient for the corresponding chunk. Therefore, CP 210 can decrease (e.g., decrement) the corresponding complexity value associated with the corresponding chunk.

[0178] In another configuration, CP 210 can determine (e.g., adjust, compute, calculate) the corresponding complexity value for each of the X chunks based on whether system configuration component 270 is able to (satisfactorily) perform concurrent operations associated with the rendering target. In one configuration, CP 210 can determine each complexity value based on whether system configuration component 270 is able to perform concurrent parsing and / or cancellation parsing. For example, CP 210 can decrease one or more complexity values ​​based on system configuration component 270's inability to perform concurrent parsing and / or cancellation parsing. Conversely, CP 210 can increase one or more complexity values ​​based on system configuration component 270's ability to perform concurrent parsing and / or cancellation parsing.

[0179] In a further aspect, CP 210 can determine (e.g., adjust, calculate, account for) the corresponding complexity value for each of the X chunks based on whether the system configuration component 270 is capable of performing store-time cleanup operations. For example, CP 210 can determine whether the system configuration component 270 is capable of concurrently performing parsing and cleanup associated with rendering one or more of the X chunks. If CP 210 determines that the system configuration component 270 cannot perform store-time cleanup, then CP 210 can decrease one or more complexity values. However, if CP 210 determines that the system configuration component 270 can perform store-time cleanup, then CP 210 can increase one or more complexity values.

[0180] CP 210 can configure each block into either a first subset associated with rendering to GMEM 235 (and then resolving to system memory 240) or a second subset associated with direct rendering to system memory 240 (without rendering to GMEM 235) based on the corresponding complexity value associated with each block in the X blocks. Specifically, CP 210 can compare each complexity value in the complexity values ​​with a block complexity threshold, and CP 210 can determine whether to include the corresponding block in the first block subset or the second block subset based on the comparison with the block complexity threshold.

[0181] In some aspects, the block complexity threshold may be pre-configured. In other aspects, the block complexity threshold may be determined, for example, by the GPU 202 or by another processor (e.g., the CPU). Potentially, the block complexity threshold may be determined based on the system configuration component 270. For example, the block complexity threshold may be increased or decreased based on one or more configurations of the system configuration component 270, such as the capability or characteristics associated with concurrent parsing and / or concurrent unparsing and / or concurrent store-on-sweep operations. For example, the block complexity threshold may increase in response to a configuration of the system configuration component 270 that prevents concurrent parsing and / or unparsing and / or concurrent store-on-sweep operations. Thus, the block complexity threshold may decrease in response to a configuration of the system configuration component 270 that enables concurrent parsing and / or unparsing and / or concurrent store-on-sweep operations.

[0182] Since the rendering path including rendering to GMEM 235 is more suitable for relatively high complexity, CP 210 can determine to include the corresponding block in the first subset in response to determining, based on comparison, that the complexity value of the corresponding block among the X blocks meets (e.g., is greater than or equal to) a block complexity threshold. Direct rendering to system memory 240 is more suitable for relatively low complexity, and therefore, CP 210 can determine to include the corresponding block in the second subset in response to determining, based on comparison, that the complexity value of the corresponding block among the X blocks does not meet (e.g., is less than) a block complexity threshold.

[0183] In some aspects, CP 210 can then perform at least one rendering pass for the first subset of chunks. The at least one rendering pass for the first subset of chunks can be of a first type associated with rendering into GMEM 235. Thus, CP 210 can perform at least one rendering pass of the first type for the first subset of chunks, and in doing so, CP 210 can render each chunk in the first subset of chunks into GMEM 235.

[0184] Further regarding at least one rendering path of the first type, CP 210 may then store (e.g., parse or copy) a first chunk subset (e.g., data corresponding to the first chunk subset) from GMEM 235 to system memory 240. In some aspects, storing the contents of GMEM 235 (e.g., data from the first chunk subset) to system memory 240 may also be referred to as a "parse path," and therefore, at least one rendering path of the first type may include or may be associated with a parse path in which a portion of the data corresponding to the target (as data from the first chunk subset) is parsed from GMEM 235 to system memory 240.

[0185] Furthermore, CP 210 can then perform at least one rendering pass for the second subset of chunks. The at least one rendering pass for the second subset of chunks can be of a second type, associated with direct rendering to system memory 240 (and avoiding rendering to GMEM 235). Therefore, CP 210 can perform at least one rendering pass of a second type for the second subset of chunks. For example, CP 210 can perform a single rendering pass of the second type, in which CP 210 directly renders each chunk in the second subset of chunks to system memory 240.

[0186] In a second type of (single) rendering pass for the second chunk subset, CP 210 may use a chunk mask to render each chunk in the second chunk subset. CP 210 may use a chunk mask to render each chunk in the second chunk subset to reject (e.g., avoid rendering or discard) some data (e.g., pixels or other values) at certain depths, such as invisible pixels and / or pixels that can be rendered together with other pixels (e.g., pixels at higher depths and / or visible pixels). In some aspects, the chunk mask may be a bitmap mask, which, for example, indicates bits corresponding to a bitmap in the frame buffer of system memory 240 that are to be masked when directly rendering the second chunk subset. CP 210 may determine the chunk mask based on an internal depth buffer (e.g., an LRZ buffer), which may be generated or determined using ZPE 225.

[0187] Therefore, CP 210 can be configured to render the first chunk subset before rendering the second chunk subset. To this end, CP 210 can parse the first chunk subset (e.g., data or bits corresponding to the first chunk subset) from GMEM 235 into system memory 240 before rendering the second chunk subset into system memory 240. In other words, CP 210 can complete at least one rendering pass of the first type (e.g., including at least one parsing pass) before executing the second type (single) rendering pass.

[0188] Figure 3 An image or surface 300 is shown, comprising multiple primitives divided into multiple blocks. For example... Figure 3 As shown, the image or surface 300 includes a complete frame 302, which may be a rendering target and may include primitives 321, 322, 323, and 324. Primitives 321, 322, 323, and 324 are divided or placed into different blocks, such as blocks 310, 311, 312, 313, 314, and 315. Figure 3 An example of tile-based rendering using multiple viewpoints is shown for primitives 321-324. For example, primitives 321-324 are in a first viewpoint 350 and a second viewpoint 351. In this way, GPU processing or rendering of an image or surface 300 including a full frame 302 can utilize multiple viewpoints or multi-view rendering.

[0189] As noted in this document, GPUs or graphics processing units can use multi-watt rendering architectures, which in certain situations (depending on the specific type and / or source of the image being rendered) can reduce power consumption and / or save memory bandwidth. In some aspects, a multi-watt rendering architecture may include a tiled rendering mode, which may include rendering tiles into GMEM before resolving them into system memory. In other aspects, a multi-watt rendering architecture may include tile-level determination regarding whether to render the corresponding tiles into GMEM (before resolving them into system memory) or to render the corresponding tiles directly into system memory (without rendering them into GMEM).

[0190] As described herein, in tile-based rendering, a complete frame 302 can be divided into multiple tiles 310-315, and in some respects, the complete frame 302 can also be considered as a single tile (e.g., a single tile corresponding to the complete frame 302). Multiple visibility paths can be executed using the complete frame 302 and the tiles 310-315 to generate a first visibility stream corresponding to the complete frame 302 and multiple second visibility streams corresponding to each tile in the tiles 310-315, respectively. The first visibility stream can identify primitives 321-324 visible in the complete frame 302, and each of the second visibility streams can identify primitives 321-324 visible in the corresponding tile in the tiles 310-315.

[0191] In some aspects, at least one LRZ buffer may be populated (e.g., for each of the plurality of blocks 310-315). The LRZ buffer may include information indicating the depth of the corresponding low-resolution pixels in each of the plurality of blocks 310-315. Potentially, a block mask may be generated based on some or all of the information in the LRZ buffer, wherein the block mask facilitates early Z-rejection during rendering one or more blocks (e.g., a subset of blocks rendered directly to system memory).

[0192] Using a tile-based rendering architecture, a complete frame 302 of an image or surface 300 can be rendered multiple times. For example, when using a tile-based rendering mode to render a complete frame 302, the complete frame 302 of the image or surface 300 can be rendered multiple times into the GMEM (e.g., once per tile) and then resolved from the GMEM into system memory.

[0193] However, in some implementations, each block in 310-315 can be configured into one of a first subset or a second subset, where different types of rendering paths are performed for blocks in the first subset and blocks in the second subset. Each block in 310-315 can have a corresponding complexity value associated with it. The complexity value can represent (e.g., estimate or approximate) the amount or level of complexity associated with rendering a block in 310-315, for example, because the rendering process can be improved by rendering more complex blocks to GMEM and then resolving the GMEM content to system memory, and by rendering less complex blocks directly to system memory without rendering to GMEM.

[0194] By way of illustration, since there are no primitives in it, the third block 312 can be relatively less complex. For example, the third block 312 may lack any overdraw and / or blending, which may contribute to the complexity associated with the rendering block. Therefore, the third block 312 can be associated with a relatively low complexity value, which can be determined for the third block 312 based on the absence of any primitives, overdraw, and / or blending.

[0195] Conversely, the fifth block 314 may be relatively complex due to primitives 322-324 and / or viewpoints 350-351 included therein. The fifth block 314 may include a relatively high amount of overdraw and / or blending associated with primitives 322-324 and / or viewpoints 350-351, which are at least partially located within the fifth block 314. For example, the layout of primitives 322-324 used to represent viewpoints 350-351 in the fifth block 314 may include some overdraw and / or blending that affects the rendering process. Therefore, the fifth block 314 may be associated with a relatively high complexity value, which may be determined for the fifth block 314 based on at least one of the primitives, overdraw, and / or blending associated with rendering the fifth block 314.

[0196] Each complexity value in the complexity values ​​for the corresponding block in blocks 310-315 can be compared with a block complexity threshold. Based on the comparison, each block in blocks 310-315 can be assigned to either a first subset or a second subset. Specifically, blocks with complexity values ​​that satisfy (e.g., are greater than or equal to) the block complexity threshold can be assigned to the first subset, while blocks with complexity values ​​that fail to satisfy (e.g., are less than) the block complexity threshold can be assigned to the second subset.

[0197] In passing Figure 3In the example shown, the third block 312 can be associated with a relatively low complexity value that may fail to meet the block complexity threshold. Therefore, the third block 312 can be configured into the second block subset based on its failure to meet the block complexity threshold, for example, because it would be more appropriate to render the third block 312 directly into system memory in terms of latency, overhead, etc.

[0198] However, the fifth block 314 can be associated with a relatively high complexity value that satisfies the block complexity threshold. Therefore, the fifth block 314 can be configured into the first block subset based on satisfying the block complexity threshold, for example, because it is more appropriate to render the fifth block 314 into GMEM before parsing it into system memory in terms of latency, overhead, etc.

[0199] Similarly, a corresponding complexity value can be determined for each of the remaining blocks 310, 311, 313, and 315. Therefore, based on a comparison of the corresponding complexity value with the block complexity threshold, each of the remaining blocks 310, 311, 313, and 315 can be assigned to one of the first or second subsets. By way of illustration rather than restriction, the fourth, fifth, and sixth blocks 313-315 can be assigned to the first subset, while the first, second, and third blocks 310-312 can be assigned to the second subset. Therefore, all blocks 310-315 into which the complete frame 302 is divided can be assigned to either the first subset for the first type of rendering path or the second subset for the second type of rendering path.

[0200] Chunks 313-315 in the first subset can be rendered first, for example, via at least one rendering path of the first type. In at least one rendering path of the first type, each of the fourth, fifth, and sixth chunks 313-315 can be rendered into the GMEM (e.g., piecewise). The contents of the GMEM generated from rendering the first subset of chunks 313-315 can be resolved into system memory (e.g., according to at least one resolution path included in or associated with at least one rendering path of the first type). In some aspects, each of the fourth, fifth, and sixth chunks 313-315 can be rendered for each of the viewpoints 350-351.

[0201] After resolving the contents of the GMEM generated from rendering the first subset 313-315 into system memory, at least one rendering pass of the second type can be executed for the second subset 310-312. In some aspects, a single rendering pass of the second type can be executed to render the first, second, and third subsets 310-312 directly into system memory without rendering any of the first, second, or third subsets 310-312 into the GMEM.

[0202] Once all the blocks 310-315 into which the complete frame 302 is divided are represented in the system memory, the complete frame 302 of the image or surface 300 can be output to the display. For example, the contents of the system memory may include a bitmap in a frame buffer, which may include display content that can be rendered on the display.

[0203] Furthermore, the GPU or graphics processing unit can use a single-tile rendering architecture (which may be a second rendering mode referred to as "direct visibility mode") to reduce power consumption and / or save memory bandwidth in certain other cases (which may depend on certain other types and / or sources of the image being rendered). This direct visibility method treats the entire frame 302 of the image or surface 300 as a single tile (e.g., the entire frame 302) and includes a visibility path to obtain a full frame visibility stream corresponding to the entire frame 302, and identifies primitives 321-324 (e.g., triangles) visible in the entire frame 302. Further, a full frame LRZ buffer can be obtained for the entire frame 302, for example, the full frame LRZ buffer indicating the low-resolution pixel depth for the entire frame 302. The entire frame 302 of the image or surface 300 can then be rendered directly to system memory (e.g., once for the single tile corresponding to the entire frame 302), thereby avoiding rendering to GMEM.

[0204] GPUs and / or graphics processing units can dynamically determine, for example, whether to implement a multi-watt or single-watt rendering architecture for each target (e.g., a frame) to be rendered. Furthermore, GPUs and / or graphics processing units implementing multi-watt rendering architectures can dynamically determine, for each of multiple chunks, whether to render the corresponding chunk to GMEM (e.g., for resolution to system memory) or to render the corresponding chunk directly to system memory (e.g., without rendering to GMEM). This dynamic determination by the GPU and / or graphics processing unit can reduce power consumption and / or save memory bandwidth, for example, because rendering at both the frame level and the chunk level can adapt to different targets and the complexity of their chunks.

[0205] Figure 4An example flowchart of an example method 400 according to one or more aspects of this disclosure is shown. Method 400 can be executed by a device such as a GPU, a graphics processing device, and / or one or more other processing units. Figure 1-3 In this context, for example, method 400 can be performed by system 100 and / or system 200 for rendering a complete frame 302 of image or surface 300. Depending on different aspects of method 400, one or more boxes in the boxes shown may be omitted, interchanged, and / or performed simultaneously.

[0206] At 402, the apparatus can determine a first visibility stream corresponding to the target based on a first visibility path for the target (e.g., frame, scene, image, etc.). In some aspects, a visibility stream associated with a complete frame target that can be considered as a single chunk can be constructed, where visibility primitives (e.g., triangles) and / or draw calls can be identified. For example, the apparatus (e.g., VFD) can determine some positional data associated with a set of vertices (e.g., vertices of one or more primitives, such as primitives visible in the target). The apparatus (e.g., VS) can process the vertex position data of the target (e.g., obtained from the VFD). The apparatus can process the complete frame target (e.g., processed as a single chunk) using a stream compressor (e.g., VSC). The apparatus (e.g., VSC) can use source pixels associated with rasterized primitives to generate a first visibility stream for the complete frame target (e.g., a single chunk).

[0207] exist Figure 1 and Figure 3 In this context, the rendering mode selection component 198 can determine the first visibility stream corresponding to the full frame 302 of the image or surface 300 based on the first visibility path used for the full frame 302 of the image or surface 300. Figure 2 and Figure 3 In this context, CP 210 can determine a first visibility stream corresponding to the complete frame 302 of the image or surface 300 based on a first visibility path for the complete frame 302 of the image or surface 300. For example, the complete frame 302 of the image or surface 300 and / or its associated draw calls can be processed by one or more of (e.g., for the visibility path associated with the complete frame 302 of the image or surface 300) such as VFD 220, VS 221, VC 222, TSE 223, RAS 224 and / or ZPE 225, which can facilitate VSC 226 in generating the first visibility stream.

[0208] At 404, the device can determine a set of second visibility streams corresponding to each of the tile sets based on a second set of visibility paths used for the tile set. The target can be divided into a set of tiles, for example, X tiles. In some aspects, a corresponding visibility stream can be constructed associated with each tile in the set to which the target is divided, where visible primitives (e.g., triangles) and / or draw calls can be identified. For example, for each tile in the tile set, the device (e.g., VFD) can determine corresponding positional data associated with a corresponding set of vertices (e.g., vertices of one or more primitives, such as primitives visible in the corresponding tile). The device (e.g., VS) can process the corresponding vertex positional data for each tile in the tile set (e.g., obtained from the VFD). The device can process each tile in the tile set using a stream compressor (e.g., VSC). The device (e.g., VSC) can use source pixels associated with rasterized primitives to generate each second visibility stream corresponding to the corresponding tile in the tile set.

[0209] exist Figure 1 and Figure 3 In this context, the rendering mode selection component 198 can determine the second visibility stream set corresponding to the block set 310-315 based on the second visibility path set of the block set 310-315 into which the complete frame 302 for the image or surface 300 is divided. Figure 2 and Figure 3 In this context, CP 210 can determine the set of second visibility streams corresponding to blocks 310-315 based on the set of second visibility paths into which the complete frame 302 of the image or surface 300 is divided. For example, each of blocks 310-315 and / or its associated corresponding draw call can be processed by one or more of VFD 220, VS 221, VC 222, TSE 223, RAS 224 and / or ZPE 225 (e.g., for the corresponding visibility path associated with one of blocks 310-315), which can facilitate VSC 226 in generating each of the second visibility streams in the set of second visibility streams.

[0210] At 406, the device can determine LRZ information associated with an LRZ buffer used for a target (e.g., frame, scene, image, etc.). For example, the device can determine one or more pixel depths (e.g., nearest pixel, farthest pixel) for one or more segments of the target, and the device can store the LRZ information in the LRZ buffer. Potentially, the device can determine the LRZ information of the LRZ buffer for each of multiple blocks into which the target is divided and / or for a single block corresponding to the target. Figure 1 and Figure 3 In this context, the rendering mode selection component 198 can determine the LRZ information associated with the LRZ buffer of the full frame 302 used for the image or surface 300. Figure 2 and Figure 3 In this context, GPU 202 (e.g., CP 210) can determine LRZ information for each of the multiple blocks 310-315 and / or for a single block corresponding to the complete frame 302 (e.g., using ZPE 225).

[0211] At 408, the apparatus may determine a set of conditions based on a first visibility stream and a second set of visibility streams, the set of conditions being associated with one or more resolutions, one or more unresolutions, blending, and / or overdraw associated with the rendering target. For example, the apparatus may determine or estimate the number of times X tiles rendered into GMEM will be copied to system memory. In another example, the apparatus may determine or estimate the number of times X tiles copied to system memory will be loaded or unresolutioned into GMEM to modify at least one of the X tiles in GMEM. In a further example, the apparatus may determine or estimate whether blending is enabled for the target and / or for one or more of the X tiles. In yet another example, the apparatus may determine or estimate the amount of overdraw associated with the target and / or with one or more of the X tiles; for example, the apparatus may determine the ratio of the number of visible pixels associated with the rendering target and / or each of the X tiles to the total number of pixels.

[0212] exist Figure 1 and Figure 3 In this context, the rendering mode selection component 198 can determine a set of conditions based on a first visibility stream and a second visibility stream set, which is associated with one or more resolutions, one or more unresolutions, blending, and / or overdraws associated with a complete frame 302 of the rendered image or surface 300. Figure 2 and Figure 3 In this context, GPU 202 (e.g., CP 210) may determine a set of conditions based on a first visibility stream and a second set of visibility streams, which is associated with one or more resolutions, one or more unresolutions, blending and / or overdraws (which may be based on draw call groups 212, context register groups 260 and / or context states 261 associated with rendering X chunks 310-315) of the rendered image or surface 300.

[0213] At 410, the apparatus can select one of a first rendering mode or a second rendering mode based on a first visibility stream and a second set of visibility streams. The first rendering mode may include each tile in a set of rendering tiles (e.g., a multi-tile rendering architecture), while the second rendering mode may include a direct rendering target (e.g., a single-tile rendering architecture). In some aspects, the apparatus can also select one of the first rendering mode and the second rendering mode based on a determined set of conditions associated with one or more resolutions, one or more unresolutions, blending, and / or overdraw associated with the rendering target. For example, the apparatus can further select one of the first rendering mode or the second rendering mode based on at least one configuration for concurrent resolutions or concurrent unresolutions associated with the rendering target. In another example, the apparatus can further select one of the first rendering mode or the second rendering mode based on a configuration for at least one cleanup operation concurrently with at least one resolution operation associated with the rendering target.

[0214] In some other aspects, the apparatus may further select one of a first rendering mode or a second rendering mode based on LRZ information associated with the LRZ buffer. For example, the LRZ information may include one or more values ​​that (still) indicate "clear," which may reflect that no visible pixels are written to a segment (or block); the selection of one of the first rendering mode or the second rendering mode may then be based on the ratio of the number of visible pixels associated with the rendering target to the total number of pixels (e.g., in a segment or block as defined for the LRZ buffer).

[0215] exist Figure 1 and Figure 3 In this context, the rendering mode selection component 198 can select either a first rendering mode or a second rendering mode based on a first visibility stream and a second visibility stream set, wherein the first rendering mode includes each tile in the set of rendering tiles 310-315 (e.g., a multi-tile rendering architecture), and the second rendering mode includes the entire frame 302 of directly rendering the image or surface 300 (e.g., a single-tile rendering architecture). Figure 2 and Figure 3In this context, GPU 202 (e.g., CP 210) can select either a first rendering mode or a second rendering mode based on a first visibility stream and a second visibility stream set. The first rendering mode includes rendering each tile in the set of tile sets 310-315 (e.g., a multi-tile rendering architecture), and the second rendering mode includes directly rendering the entire frame 302 of the image or surface 300 (e.g., a single-tile rendering architecture). The tile rendering mode can be associated with a set of tiles as a plurality (X) of tiles 310-315, each tile corresponding to a corresponding segment of the entire frame 302, while the visibility direct mode can be associated with a set of tiles as a single tile corresponding to the entire frame 302.

[0216] If at position 410, the device selects the first rendering mode to render the target, then:

[0217] At 412, the apparatus determines whether to use a hybrid rendering path. When the apparatus determines not to use a hybrid rendering path, it can determine whether to use a rendering path based on a tiled rendering mode. In some aspects, the apparatus can determine whether to use a hybrid rendering path based on a first set of visibility streams and a second set of visibility streams. For example, the apparatus can determine whether to use a hybrid rendering path based on determining a set of conditions associated with one or more resolutions, one or more unresolutions, blending, and / or overdraw associated with the rendering target. In some other aspects, the apparatus can determine whether to use a hybrid rendering mode based on the complexity associated with the set of tiles (such as the ratio of the number of relatively complex tiles to the number of relatively less complex tiles). When this ratio is relatively high (e.g., indicating a large number of complex tiles), the apparatus can determine not to use a hybrid rendering path because a tiled rendering mode is more suitable for rendering a large number of relatively complex tiles. When this ratio is relatively low (e.g., indicating a small number of complex tiles), the apparatus can determine to use a hybrid rendering path because the apparatus can benefit from rendering a large number of less complex tiles directly into system memory.

[0218] exist Figure 1 and Figure 3 In this context, the rendering pipeline configuration component 199 can determine whether to use a hybrid rendering pipeline (or whether to use a tiled rendering mode). Figure 2 and Figure 3 In this context, GPU 202 (e.g., CP 210) can determine whether to use a hybrid rendering path (or whether to use a tiled rendering mode).

[0219] If at position 412, the device determines to use a hybrid rendering path, then:

[0220] At 414, the apparatus can configure each of the X chunks into one of the first or second subsets of chunks based on the corresponding second visibility stream in the second visibility stream set. The apparatus can configure a corresponding chunk of the X chunks into one of the first or second subsets of chunks based on at least one of the following: overdraw associated with the corresponding chunk, blending associated with the corresponding chunk, configuration for concurrent resolution operations associated with at least the corresponding chunk, and / or configuration for at least one cleanup operation concurrent with at least one resolution operation associated with rendering at least the corresponding chunk.

[0221] exist Figure 1 and Figure 3 In this context, the rendering path configuration component 199 can configure each block in blocks 310-315 to one item in either the first block subset or the second block subset based on the corresponding second visibility stream in the second visibility stream set. Figure 2 and Figure 3 In this context, GPU 202 (e.g., CP 210) can configure each block in blocks 310-315 to one of the first block subset or the second block subset based on the corresponding second visibility stream in the second visibility stream set.

[0222] At 416, the apparatus can render chunks in the first chunk subset into GMEM. For example, the apparatus can render the first chunk into GMEM based at least on the visibility stream for the first chunk in the first subset, and the apparatus can render the second chunk into GMEM based at least on the visibility stream for the second chunk in the first chunk subset, and the apparatus can similarly render each of the remaining chunks in the first subset into GMEM based at least on the corresponding visibility stream for each of the remaining chunks in the first subset.

[0223] exist Figure 1 and Figure 3 In this context, the rendering path configuration component 199 can render each block in the fourth, fifth, and sixth blocks 313-315 to GMEM (e.g., internal memory 121 or internal memory 123) based on the corresponding visibility stream in the visibility stream corresponding to the fourth, fifth, and sixth blocks 313-315 (e.g., the first block subset). Figure 2 and Figure 3 In this context, GPU 202 (e.g., CP 210) can render each block in the fourth, fifth, and sixth blocks 313-315 into GMEM 235 based on the corresponding visibility stream in the visibility stream corresponding to the fourth, fifth, and sixth blocks 313-315 (e.g., the first block subset).

[0224] At 418, the device can resolve the first subset of blocks from GMEM to system memory. In some aspects, the device can determine (e.g., identify, calculate, etc.) the corresponding region in the frame buffer of the system memory corresponding to each block in the first subset of blocks stored in GMEM, and the device can store or copy each block in the first subset of blocks from GMEM to the corresponding corresponding region in the frame buffer of the system memory.

[0225] exist Figure 1 and Figure 3 In this context, the rendering path configuration component 199 can resolve each block in the fourth, fifth, and sixth blocks 313-315 (e.g., the first block subset) from GMEM (e.g., internal memory 121 or internal memory 123) to the corresponding region in the frame buffer 125 of system memory 124. Figure 2 and Figure 3 In this context, GPU 202 (e.g., CP 210) can resolve each block in the fourth, fifth, and sixth blocks 313-315 (e.g., the first block subset) from GMEM 235 to system memory 240.

[0226] At 420, the device can directly render the second subset of blocks into system memory. For example, the device can determine (e.g., identify, calculate, etc.) the corresponding region in the frame buffer of the system memory corresponding to each block of the second subset of blocks, and the device can directly store each block of the second subset of blocks into the corresponding region in the frame buffer of the system memory. Therefore, the device can avoid rendering any blocks of the second subset of blocks into GMEM.

[0227] exist Figure 1 and Figure 3 In this context, the rendering path configuration component 199 can render each block in the first, second, and third blocks 310-312 (e.g., a subset of the second blocks) to the corresponding region in the frame buffer 125 of the system memory 124. The rendering path configuration component 199 can avoid rendering any blocks in the first, second, and third blocks 310-213 to GMEM (e.g., internal memory 121 or internal memory 123). Figure 2 and Figure 3 In this context, GPU 202 (e.g., CP 210) can render each block in the first, second, and third blocks 310-312 (e.g., the second block subset) to system memory 240 without rendering any of the blocks in the first, second, and third blocks 310-312 to GMEM 235.

[0228] If at 412, the device determines not to use a hybrid rendering pass (e.g., the device determines to use a tiled rendering mode), then:

[0229] At 422, the apparatus can render each of the X blocks in GMEM. For example, the apparatus can render the first block in GMEM based at least on the visibility stream for the first block of the X blocks, and the apparatus can render the second block in GMEM based at least on the visibility stream for the second block of the X blocks, and the apparatus can similarly render each of the remaining blocks of the X blocks in GMEM based at least on the corresponding visibility stream for each of the remaining blocks of the X blocks.

[0230] exist Figure 1 and Figure 3 In this context, the rendering path configuration component 199 can render each block in blocks 310-315 to GMEM (e.g., internal memory 121 or internal memory 123) based on the corresponding visibility stream in the visibility stream corresponding to each block in blocks 310-315. Figure 2 and Figure 3 In this context, GPU 202 (e.g., CP 210) can render each block in 310-315 to GMEM 235 based on the corresponding visibility stream in the visibility stream corresponding to each block in 310-315.

[0231] At 424, the device can resolve X blocks from GMEM to system memory. In some aspects, the device can determine (e.g., identify, calculate, etc.) the corresponding region in the frame buffer of the system memory corresponding to each of the X blocks stored in GMEM, and the device can store or copy each of the X blocks from GMEM to the corresponding region in the frame buffer of the system memory.

[0232] exist Figure 1 and Figure 3 In this context, the rendering path configuration component 199 can resolve each block from blocks 310-315 in the GMEM (e.g., internal memory 121 or internal memory 123) to the corresponding region in the frame buffer 125 of the system memory 124. Figure 2 and Figure 3 In this context, GPU 202 (e.g., CP 210) can resolve each block in blocks 310-315 from GMEM 235 to system memory 240.

[0233] If the device selects the second rendering mode at position 410, then:

[0234] At position 426, the device can render the target to system memory instead of to GMEM. The device can render the target directly to system memory as a single chunk. For example, the device can store the target directly in the frame buffer of system memory (e.g., as a single chunk). Therefore, the device can avoid rendering the target to GMEM.

[0235] exist Figure 1 and Figure 3 In this context, the rendering mode selection component 198 can render the complete frame 302 of the image or surface 300 directly to the frame buffer 125 of the system memory 124. The rendering mode selection component 198 can also avoid rendering the complete frame 302 of the image or surface 300 to GMEM (e.g., internal memory 121 or internal memory 123). Figure 2 and Figure 3 In this context, GPU 202 (e.g., CP 210) can render the complete frame 302 of the image or surface 300 to system memory 240 instead of rendering the complete frame 302 of the image or surface 300 to GMEM 235.

[0236] Figure 5 An example flowchart of an example method 500 according to one or more aspects of this disclosure is shown. Method 500 can be executed by a device such as a GPU, a graphics processing device, and / or one or more other processing units. Figure 1-3 In this context, for example, method 500 can be performed by system 100 and / or system 200 for rendering a complete frame 302 of image or surface 300. Depending on different aspects of method 500, one or more boxes in the boxes shown may be omitted, interchanged, and / or performed simultaneously.

[0237] At 502, the apparatus can determine the corresponding visibility of primitives associated with each block in the set of blocks. Each block in the set of blocks can represent at least a corresponding portion of a target (e.g., an image, frame, scene, etc.), that is, the target can be divided into a set of blocks. In some aspects, the apparatus can determine a corresponding visibility stream corresponding to each block in the set of blocks; for example, the corresponding visibility stream corresponding to a corresponding block can include information indicating the corresponding visibility of primitives associated with the corresponding block. In some aspects, each visibility stream in the visibility stream can be obtained based on a corresponding visibility path on the corresponding block in the set of blocks. A corresponding visibility stream associated with each block in the set of blocks to which the target is divided can be constructed, wherein visible primitives (e.g., triangles) and / or draw calls can be identified. For example, for each block in the set of blocks, the apparatus (e.g., VFD) can determine corresponding positional data associated with a corresponding set of vertices (e.g., vertices of one or more primitives, such as primitives visible in the corresponding block). The device (e.g., VS) can process the corresponding vertex position data (e.g., obtained from VFD) for each block in the chunk set. The device can process each block in the chunk set using a stream compressor (e.g., VSC). The device (e.g., VSC) can use source pixels associated with rasterized primitives to generate each visibility stream in the visibility stream corresponding to the corresponding block in the chunk set.

[0238] In some other aspects, the apparatus can determine the corresponding visibility of elements associated with each block in a set of blocks by processing the primitives of the target, which may be input via a command stream. For example, the apparatus can divide the target into a set of blocks such that each block represents a different segment of the target (e.g., a non-overlapping portion), and then the apparatus can classify elements (e.g., input elements) into one of these blocks, for example, based on the visibility of elements within one of these blocks. For example, the primitives can be processed via a visual system (VS), and the primitives can be classified into blocks based on the output of the VS processing.

[0239] exist Figure 1 and Figure 3 In this context, the rendering mode selection component 198 can determine the corresponding visibility of primitives associated with each block in the set of blocks 310-315 into which the complete frame 302 of the image or surface 300 is divided. For example, the rendering mode selection component 198 can determine the corresponding visibility flow corresponding to each block in the set of blocks 310-315, for example, based on the set of visibility paths used to divide the complete frame 302 of the image or surface 300 into blocks 310-315. Figure 2 and Figure 3In this context, CP 210 can determine the corresponding visibility of primitives associated with each block in the set of blocks 310-315 into which the complete frame 302 of the image or surface 300 is divided. In some aspects, CP 210 can determine the corresponding visibility flow corresponding to each block in the set of blocks 310-315, for example, based on the set of visibility paths used for the set of blocks 310-315 into which the complete frame 302 of the image or surface 300 is divided. For example, each block in the set of blocks 310-315 and / or its associated corresponding draw call can be processed by one or more of VFD 220, VS 221, VC 222, TSE 223, RAS 224 and / or ZPE 225 (e.g., for the corresponding visibility path associated with a block in the set of blocks 310-315), which can facilitate VSC 226 in generating each visibility flow in the set of visibility flows.

[0240] At point 504, the apparatus can determine a corresponding complexity value for each block in the block set based on the corresponding visibility of primitives. For example, the apparatus can determine the corresponding complexity value for each block in the block set based on the corresponding visibility flow corresponding to the corresponding block. In some aspects, the apparatus can determine the corresponding complexity value for a block in the block set based on at least one of the following: overdraw associated with the corresponding block, blending associated with the corresponding block, and / or the number of objects (e.g., primitives, triangles, etc.) at least partially represented in the block. For example, the apparatus can determine at least one of the following: overdraw amount associated with the block, blending amount associated with the block, and / or the number of objects at least partially within the block.

[0241] The device can then determine (e.g., calculate, adjust, etc.) a corresponding complexity value for a block based on at least one of the following: the amount of overdraw associated with the block, the amount of blending associated with the block, and / or the number of objects, at least partially, within the block. For example, the device can increase the corresponding complexity value based on a relatively high amount of overdraw, a relatively high amount of blending, and / or a relatively large number of objects associated with the block. However, the device can decrease the corresponding complexity value based on a relatively low amount of overdraw, a relatively low amount of blending, and / or a relatively small number of objects associated with the block.

[0242] In some other aspects, the apparatus may determine a corresponding complexity value for a block in the block set based on at least one configuration associated with concurrent parsing and / or concurrent unparsing and / or concurrent store-time cleanup operations. For example, the apparatus may determine whether at least one configuration of the apparatus enables concurrent parsing and / or concurrent unparsing and / or concurrent store-time cleanup operations, and the apparatus may reduce the complexity value based on such enabling. However, if the apparatus determines that at least one configuration of the apparatus disables concurrent parsing and / or concurrent unparsing and / or concurrent store-time cleanup operations, the apparatus may reduce the complexity value based on such disabling.

[0243] exist Figure 1 and Figure 3 In this context, the rendering path configuration component 199 can determine a corresponding complexity value for each block in blocks 310-315 based on the corresponding visibility of primitives associated with the corresponding blocks in blocks 310-315. For example, the rendering path configuration component 199 can determine a corresponding complexity value for each block in blocks 310-315 based on the corresponding visibility flow corresponding to the corresponding blocks in blocks 310-315. Figure 2 and Figure 3 In this context, GPU 202 (e.g., CP 210) can determine the corresponding complexity value for each block in blocks 310-315 based on the corresponding visibility of the primitives associated with the corresponding blocks in blocks 310-315. For example, GPU 202 (e.g., CP 210) can determine the corresponding complexity value for each block in blocks 310-315 based on the corresponding visibility flow associated with the corresponding blocks in blocks 310-315.

[0244] At point 506, the device can compare a corresponding complexity value with a threshold value for each block in the block set. For example, the device can determine a threshold value to be compared to determine whether the corresponding block in the block is rendered to GMEM or directly to system memory. The threshold value can be pre-configured, or the device can determine (e.g., calculate, compute, adjust) the threshold value based on the block set and / or based on the configuration of one or more components of the device (such as the ability to perform cleanup operations during concurrent parsing, concurrent unparsing, and / or concurrent storage). The device can then determine whether the corresponding complexity value meets (e.g., is greater than) the threshold value or fails to meet (e.g., is less than) the threshold value.

[0245] exist Figure 1 and Figure 3 In this context, the rendering path configuration component 199 can compare the corresponding complexity value with the block complexity threshold for each block in blocks 310-315. Figure 2 and Figure 3 In this context, GPU 202 (e.g., CP210) can compare the corresponding complexity value with the block complexity threshold for each block in blocks 310-315.

[0246] At point 508, the apparatus can determine a corresponding rendering path type from multiple rendering path types for each block in the block set based on the corresponding visibility of primitives associated with the corresponding block in the block set. In some aspects, the apparatus can determine a corresponding rendering path type from multiple rendering path types for each block in the block set based on a corresponding visibility flow corresponding to the corresponding block in the block set. The multiple rendering path types may include at least a first rendering path type associated with rendering to GMEM and a second rendering path type associated with avoiding rendering to GMEM (e.g., associated with direct rendering to system memory). The apparatus can determine the corresponding rendering path type for each block in the block set based on the corresponding visibility of primitives and / or based on the corresponding corresponding visibility flow.

[0247] For example, the apparatus can determine the corresponding complexity value for each chunk based at least on the corresponding visibility of primitives associated with the corresponding chunk in the chunk set. For example, the apparatus can determine the corresponding complexity value for each chunk in the chunk set based at least on the corresponding visibility flow associated with the corresponding chunk in the chunk set. The apparatus can then determine the corresponding rendering path type based on a comparison of the corresponding complexity value with a threshold value, since the corresponding complexity value can be based on the corresponding visibility of primitives and / or the corresponding visibility flow, and therefore the corresponding rendering path type can be determined based on the corresponding visibility of primitives and / or the corresponding visibility flow.

[0248] In some aspects, the apparatus can determine, for each block in the block set, whether a corresponding complexity value meets a threshold value based on comparison. In response to determining that the corresponding complexity value meets the threshold value, the apparatus can include the block in a first subset of blocks associated with a first rendering path type that includes rendering to the GMEM. In response to determining that the corresponding complexity value fails to meet the threshold value, the apparatus can include the block in a second subset of blocks associated with a second rendering path type that does not include rendering to the GMEM.

[0249] exist Figure 1 and Figure 3In this context, the rendering path configuration component 199 can determine a corresponding rendering path type from multiple rendering path types for each block in blocks 310-315 based on the corresponding visibility of primitives associated with the corresponding blocks in blocks 310-315. For example, the rendering path configuration component 199 can determine a corresponding rendering path type from multiple rendering path types for each block in blocks 310-315 based on the corresponding visibility flow associated with the corresponding blocks in blocks 310-315. The multiple rendering path types may include a first rendering path type associated with rendering to GMEM (e.g., internal memory 121 and / or internal memory 123) and a second rendering path type associated with avoiding rendering to GMEM. Figure 2 and Figure 3 In this context, GPU 202 (e.g., CP 210) can determine a corresponding rendering pass type for each of the blocks 310-315 from a plurality of rendering pass types, including a first rendering pass type associated with rendering to GMEM 235 and a second rendering pass type associated with avoiding rendering to GMEM 235. For example, GPU 202 (e.g., CP 210) can determine the corresponding rendering pass type for each of the blocks 310-315 based on the corresponding visibility of primitives associated with the corresponding blocks in the blocks 310-315 and / or based on the corresponding visibility flow associated with the corresponding blocks in the blocks 310-315.

[0250] At point 510, the apparatus can render each tile in the first subset of tiles into the GMEM, each tile in the first subset of tiles being associated with a first rendering path type. For example, the apparatus can render the first tile into the GMEM based at least on the corresponding visibility of the primitives associated with the first tile in the first subset (e.g., a subset of primitives visible in the first tile, which comes from a set of primitives visible in the target) and / or based on the visibility stream for the first tile. The apparatus can also render the second tile into the GMEM based at least on the corresponding visibility of the primitives associated with the second tile in the first subset of tiles and / or the visibility stream for the second tile. Similarly, the apparatus can render each tile in the remaining tiles into the GMEM based at least on the corresponding visibility of the primitives associated with each tile in the remaining tiles in the first subset and / or the corresponding visibility stream for each tile in the remaining tiles in the first subset.

[0251] exist Figure 1 and Figure 3In this context, the rendering path configuration component 199 can render each block of the fourth, fifth, and sixth blocks 313-315 to GMEM (e.g., internal memory 121 or internal memory 123) based on the corresponding visibility of primitives 322-324 associated with the fourth, fifth, and sixth blocks 313-315 (e.g., the first block subset). For example, the rendering path configuration component 199 can render each block of the fourth, fifth, and sixth blocks 313-315 to GMEM based on the corresponding visibility stream in the visibility stream corresponding to the fourth, fifth, and sixth blocks 313-315. Figure 2 and Figure 3 In this context, GPU 202 (e.g., CP 210) can render each block of the fourth, fifth, and sixth blocks 313-315 into GMEM 235 based on the corresponding visibility of primitives 322-324 associated with the fourth, fifth, and sixth blocks 313-315 (e.g., the first block subset). For example, GPU 202 (e.g., CP 210) can render each block of the fourth, fifth, and sixth blocks 313-315 into GMEM 235 based on the corresponding visibility stream in the visibility stream corresponding to the fourth, fifth, and sixth blocks 313-315 (e.g., the first block subset).

[0252] At point 512, the device can store each block in the first subset of blocks from GMEM into system memory. In some aspects, the device can determine (e.g., identify, calculate, etc.) a corresponding region in the frame buffer of system memory that corresponds to each block in the first subset of blocks stored in GMEM, and the device can store or copy each block in the first subset of blocks from GMEM to the corresponding region in the frame buffer of system memory.

[0253] exist Figure 1 and Figure 3 In this context, the rendering path configuration component 199 can resolve (e.g., store, copy, etc.) each block in the fourth, fifth, and sixth blocks 313-315 (e.g., the first block subset) from GMEM (e.g., internal memory 121 or internal memory 123) to the corresponding region in the frame buffer 125 of system memory 124. Figure 2 and Figure 3 In this context, GPU 202 (e.g., CP 210) can store (e.g., parse, copy, etc.) each block in the fourth, fifth, and sixth blocks 313-315 (e.g., the first block subset) from GMEM 235 to system memory 240.

[0254] At point 514, the device can render each block in the second subset of blocks to system memory instead of to GMEM, each block in the second subset of blocks being associated with a second rendering path type. For example, the device can determine (e.g., identify, calculate, etc.) the corresponding region in the frame buffer of the system memory corresponding to each block in the second subset of blocks, and the device can directly store each block in the second subset of blocks to the corresponding region in the frame buffer of the system memory. Therefore, the device can render the second subset of blocks directly to system memory, and further, can avoid rendering any blocks in the second subset of blocks to GMEM.

[0255] In some aspects, the device may use a block mask based on a depth buffer (e.g., an LRZ buffer) associated with each block in the second block subset to render the corresponding blocks into system memory. When rendering each block in the second block subset, the block mask may be configured for early Z-rejection.

[0256] In some aspects, the first subset of chunks can be rendered before the second subset of chunks is rendered. For example, the apparatus can render each chunk in the first subset of chunks to GMEM, and then the apparatus can resolve each chunk in the first subset of chunks from GMEM to system memory. After the first subset of chunks is resolved, the apparatus can render the second subset of chunks directly to system memory. The apparatus can render the second subset of chunks directly to system memory in a single rendering pass.

[0257] exist Figure 1 and Figure 3 In this context, the rendering path configuration component 199 can render each block in the first, second, and third blocks 310-312 (e.g., a subset of the second blocks) to the corresponding region in the frame buffer 125 of the system memory 124. The rendering path configuration component 199 can avoid rendering any blocks in the first, second, and third blocks 310-213 to GMEM (e.g., internal memory 121 or internal memory 123). Figure 2 and Figure 3 In this context, GPU 202 (e.g., CP 210) can render each block in the first, second, and third blocks 310-312 (e.g., the second block subset) to system memory 240 without rendering any blocks in the first, second, and third blocks 310-312 to GMEM 235.

[0258] The subjects 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 GPU, CPU, or some other processor capable of performing graphics processing to implement the rendering techniques described herein. This can also be achieved at a lower cost compared to other graphics processing techniques. Furthermore, the graphics processing techniques described herein can improve or accelerate data processing or execution. Further, the graphics processing techniques described herein can improve resource or data utilization and / or resource efficiency. Additionally, aspects of this disclosure can utilize the rendering mode selection techniques described herein to reduce the time and / or cost incurred during incremental or command streaming.

[0259] According to this disclosure, unless otherwise specified in the context, the term "or" may be interpreted as "and / or". Additionally, while phrases such as "one or more" or "at least one" may be used for some features disclosed herein but not for others, features not using such language may be interpreted as implying such a meaning unless otherwise specified in the context.

[0260] 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, then the functionality, processing unit, technique, or other module described herein may be stored on or transmitted via a computer-readable medium as one or more instructions or code. A computer-readable medium may include a computer data storage medium or a communication medium, including any medium that facilitates the transfer of a computer program from one place to another. In this way, 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 herein. By way of example, and not limitation, such a computer-readable medium may include RAM, ROM, EEPROM, CD-ROM or other optical disk storage, magnetic disk storage, or other magnetic storage devices. As used herein, disks and optical discs include compact optical discs (CDs), laser optical discs, optical discs, digital versatile optical discs (DVDs), floppy disks, and Blu-ray discs, wherein disks typically copy data magnetically, while optical discs use lasers to copy data optically. Combinations of the above should also be included within the scope of computer-readable media. Computer program products may include computer-readable media.

[0261] The code can 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 arrays (FPGAs), or other equivalent integrated or discrete logic circuits. Therefore, the term "processor" as used herein can refer to any of the foregoing structures or any other structure suitable for implementing the techniques described herein. Furthermore, the techniques can be sufficiently implemented in one or more circuit or logic elements.

[0262] The techniques disclosed herein can be implemented in a wide variety of devices or apparatuses, including wireless mobile phones, integrated circuits (ICs), or a set of ICs (e.g., chipsets). Various components, modules, or units are described in this disclosure to emphasize functional aspects of a device configured to perform the disclosed techniques, but they do not necessarily require implementation through different hardware units. Specifically, as described above, the various units can be combined in any hardware unit, or provided by a batch of interoperable hardware units (including one or more processors as described above) combined with suitable software and / or firmware.

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

[0264] Example 1 is an apparatus for graphics processing configured to: determine the corresponding visibility of primitives associated with each tile in a set of tiles, each tile representing at least a corresponding portion of the target; for each tile in the set of tiles, determine a corresponding rendering pass type from a plurality of rendering pass types based on the corresponding visibility or primitives, the plurality of rendering pass types including a first rendering pass type associated with rendering the tile into a GMEM and a second rendering pass type associated with avoiding rendering the tile into the GMEM; and render the target based on the corresponding rendering pass type determined for each tile in the set of tiles.

[0265] Example 2 may include the apparatus according to Example 1, the apparatus further configured to: render each block in the first subset of the chunk set to the GMEM when the first rendering pass type is determined for the corresponding rendering pass type of each block in the first subset of the chunk set; and store data corresponding to each block in the first subset of the chunk set from the GMEM to system memory.

[0266] Example 3 may include the apparatus according to Example 2, which is further configured to render each block in the second subset of the chunk set to the system memory, but not to the GMEM, when the second rendering pass type is determined to be the corresponding rendering pass type for each block in the second subset of the chunk set.

[0267] Example 4 may include the apparatus according to Example 3, wherein the first subset of the chunk set is rendered before the second subset of the chunk set is rendered.

[0268] Example 5 may include the apparatus according to Example 3 or Example 4, wherein each block in the first subset of blocks is rendered into the GMEM before each block in the first subset of blocks is stored from the GMEM into the system memory, and wherein the second subset of the set of blocks is rendered into the system memory in a rendering pass.

[0269] Example 6 may include the apparatus according to any one of Examples 3-5, and for each chunk in the second subset of the chunk set, the corresponding chunk is rendered using a chunk mask based on a depth buffer associated with the corresponding chunk.

[0270] Example 7 may include an apparatus according to any one of Examples 1-6, the apparatus being further configured to: determine a corresponding complexity value for each block in the set of blocks based on the corresponding visibility of the primitives, and the corresponding rendering path type for each block in the set of blocks is determined based on the corresponding complexity value.

[0271] Example 8 may include the apparatus according to Example 7, and the corresponding complexity value is determined for a corresponding block in the set of blocks based on at least one of the following: overdraw associated with the corresponding block, blending associated with the corresponding block, or the number of objects of the target that are at least partially represented in the corresponding block.

[0272] Example 9 may include the apparatus according to Example 7 or Example 8, the apparatus being further configured to: compare the corresponding complexity value with a threshold value for each block in the set of blocks, and determine the corresponding rendering path type for each block in the set of blocks based on the comparison of the corresponding complexity value with the threshold value.

[0273] Example 10 is an apparatus for graphics processing configured to: determine a first visibility stream corresponding to a target based on a first visibility path for a target; determine a second visibility stream set corresponding to each of the tile sets based on a second visibility path set for a tile set, the target being divided into the tile set; select one of a first rendering mode or a second rendering mode for the target based on the first visibility stream and based on the second visibility stream set, the first rendering mode including rendering each tile in the tile set, and the second rendering mode including directly rendering the target; and render the target based on the selected first rendering mode or the second rendering mode.

[0274] Example 11 may include the apparatus according to Example 10, wherein, when the first rendering mode is selected, rendering the target includes: configuring each chunk in the chunk set to one of a first chunk subset or a second chunk subset based on a corresponding second visibility stream in the second visibility stream set; rendering each chunk in the first chunk subset in the GMEM to store a first portion of the target in the GMEM; storing the first portion of the target from the GMEM in system memory; and rendering each chunk in the second subset of the chunk set in the system memory without rendering it to the GMEM to store the remaining portion of the target in the system memory.

[0275] Example 12 may include the apparatus according to Example 11, and the respective chunk in the chunk set is further configured to one of the first chunk subset or the second chunk subset based on at least one of the following: overdraw associated with the respective chunk, blending associated with the respective chunk, configuration for concurrent parsing operations associated with at least the respective chunk, or configuration for at least one cleanup operation concurrent with at least one parsing operation associated with rendering at least the respective chunk.

[0276] Example 13 may include the apparatus according to Example 10, and when the first rendering mode is selected, rendering the target includes: rendering each chunk in the chunk set in a GMEM to store the target in the GMEM; and storing the target from the GMEM in system memory.

[0277] Example 14 may include the apparatus according to any one of Examples 10-13, and when the second rendering mode is selected, rendering the target includes: rendering the target in system memory, wherein the target is rendered directly in system memory and not rendered in GMEM.

[0278] Example 15 may include an apparatus according to any one of Examples 10-14, the apparatus being further configured to: determine LRZ information associated with an LRZ buffer for the target, and the selection of the first rendering mode or the second rendering mode is further based on the LRZ information.

[0279] Example 16 may include the apparatus according to Example 15, and the selection of the first rendering mode or the second rendering mode is further based on the ratio of the number of visible pixels to the total number of pixels associated with rendering the target, and the number of visible pixels is based on the LRZ information.

[0280] Example 17 may include the apparatus of any one of the sets of examples 10-16, the apparatus being further configured to: determine a set of conditions based on the first visibility stream and based on the second set of visibility streams, the set of conditions being associated with one or more resolutions, one or more unresolutions, blending or overdrawing associated with rendering the target, and the selection of the first rendering mode or the second rendering mode being further based on the determined set of conditions.

[0281] Example 18 may include the apparatus according to any one of Examples 10-17, and the selection of the first rendering mode or the second rendering mode is further based on at least one configuration for concurrent resolution or concurrent unresolution associated with the rendering of the target.

[0282] Example 19 may include the apparatus according to any one of Examples 10-18, and the selection of the first rendering mode or the second rendering mode is further based on a configuration for at least one clearing operation concurrent with at least one parsing operation associated with the rendering of the target.

Claims

1. A method for graphics processing, comprising: A first visibility flow corresponding to the target is determined based on a first visibility path used for the target; A second set of visibility streams corresponding to each of the chunk sets is determined based on a second set of visibility paths used for the chunk set, wherein the target is divided into the chunk set; Based on the first visibility stream and the second set of visibility streams, one of a first rendering mode or a second rendering mode is selected for the target, the first rendering mode comprising rendering each chunk in the set of chunks, and the second rendering mode comprising directly rendering the target, wherein the selection of the first rendering mode or the second rendering mode is further based on at least one configuration for concurrent resolution or concurrent cancellation associated with rendering the target; and The target is rendered based on either the first rendering mode or the second rendering mode. When the first rendering mode is selected, the rendering of the target includes: Based on the corresponding second visibility stream in the second visibility stream set, each block in the block set is configured into an item in either the first block subset or the second block subset; Each block in the first subset of blocks is rendered in the graphics memory GMEM to store a first portion of the target in the GMEM. The first portion of the target is stored from the GMEM in the system memory; and Each block in the second subset of the block set is rendered in the system memory instead of in the GMEM, so that the remainder of the target is stored in the system memory.

2. The method according to claim 1, wherein, The corresponding chunk in the chunk set is further configured to one of the first chunk subset or the second chunk subset based on at least one of the following: overdraw associated with the corresponding chunk, blending associated with the corresponding chunk, configuration for concurrent parsing operations associated with at least the corresponding chunk, or configuration for at least one cleanup operation concurrent with at least one parsing operation associated with rendering at least the corresponding chunk.

3. The method according to claim 1, wherein, When the second rendering mode is selected, the rendering of the target includes: The target is rendered in the system memory, and the target is rendered directly in the system memory instead of in GMEM.

4. The method according to claim 1, further comprising: Determine the LRZ information associated with the low-resolution depth LRZ buffer used for the target. The selection of either the first rendering mode or the second rendering mode is further based on the LRZ information.

5. The method according to claim 4, wherein, The selection of either the first rendering mode or the second rendering mode is further based on the ratio of the number of visible pixels to the total number of pixels associated with rendering the target, and the number of visible pixels is based on the LRZ information.

6. The method according to claim 1, further comprising: A set of conditions is determined based on the first visibility stream and the second visibility stream set, the set of conditions being associated with one or more resolutions, one or more unresolutions, blending, or overdrawing associated with rendering the target. The selection of either the first rendering mode or the second rendering mode is further based on a determined set of conditions.

7. The method according to claim 1, wherein, The selection of either the first rendering mode or the second rendering mode is further based on a configuration for at least one cleanup operation concurrent with at least one parsing operation associated with the rendering of the target.

8. An apparatus for graphics processing, comprising: Memory; as well as At least one processor, coupled to the memory, is configured to: A first visibility flow corresponding to the target is determined based on a first visibility path used for the target; A second set of visibility streams corresponding to each of the chunk sets is determined based on a second set of visibility paths used for the chunk set, wherein the target is divided into the chunk set; Based on the first visibility stream and the second set of visibility streams, one of a first rendering mode or a second rendering mode is selected for the target, the first rendering mode comprising rendering each chunk in the set of chunks, and the second rendering mode comprising directly rendering the target, wherein the selection of the first rendering mode or the second rendering mode is further based on at least one configuration for concurrent resolution or concurrent cancellation associated with rendering the target; and The target is rendered based on either the first rendering mode or the second rendering mode. When the first rendering mode is selected, in order to render the target, the at least one processor is configured as follows: Based on the corresponding second visibility stream in the second visibility stream set, each block in the block set is configured into an item in either the first block subset or the second block subset; Each block in the first subset of blocks is rendered in the graphics memory GMEM to store a first portion of the target in the GMEM. The first portion of the target is stored from the GMEM in the system memory; and Each block in the second subset of the block set is rendered in the system memory instead of in the GMEM, so that the remainder of the target is stored in the system memory.

9. The apparatus according to claim 8, wherein, The corresponding chunk in the chunk set is further configured to one of the first chunk subset or the second chunk subset based on at least one of the following: overdraw associated with the corresponding chunk, blending associated with the corresponding chunk, configuration for concurrent parsing operations associated with at least the corresponding chunk, or configuration for at least one cleanup operation concurrent with at least one parsing operation associated with rendering at least the corresponding chunk.

10. The apparatus according to claim 8, wherein, When the second rendering mode is selected, in order to render the target, the at least one processor is configured to: The target is rendered in the system memory, and the target is rendered directly in the system memory instead of in GMEM.

11. The apparatus according to claim 8, wherein, The at least one processor is further configured to: Determine the LRZ information associated with the low-resolution depth LRZ buffer used for the target. The selection of either the first rendering mode or the second rendering mode is further based on the LRZ information.

12. The apparatus according to claim 11, wherein, The selection of either the first rendering mode or the second rendering mode is further based on the ratio of the number of visible pixels to the total number of pixels associated with rendering the target, and the number of visible pixels is based on the LRZ information.

13. The apparatus according to claim 8, wherein, The at least one processor is further configured to: A set of conditions is determined based on the first visibility stream and the second visibility stream set, the set of conditions being associated with one or more resolutions, one or more unresolutions, blending, or overdrawing associated with rendering the target. The selection of either the first rendering mode or the second rendering mode is further based on a determined set of conditions.

14. The apparatus according to claim 8, wherein, The selection of either the first rendering mode or the second rendering mode is further based on a configuration for at least one cleanup operation concurrent with at least one parsing operation associated with the rendering of the target.

15. An apparatus for graphics processing, comprising: A unit for determining a first visibility stream corresponding to the target based on a first visibility path for the target; A unit for determining a second set of visibility streams corresponding to each of the chunks based on a second set of visibility paths used for the chunk set, wherein the target is divided into the chunk set; A unit for selecting one of a first rendering mode or a second rendering mode for the target based on a first visibility stream and a second set of visibility streams, the first rendering mode comprising rendering each chunk in the set of chunks, and the second rendering mode comprising directly rendering the target, wherein the selection of the first rendering mode or the second rendering mode is further based on at least one configuration for concurrent resolution or concurrent cancellation associated with rendering the target; and A unit for rendering the target based on a selection of the first rendering mode or the second rendering mode. When the first rendering mode is selected, the unit for rendering the target is configured as follows: Based on the corresponding second visibility stream in the second visibility stream set, each block in the block set is configured into an item in either the first block subset or the second block subset; Each block in the first subset of blocks is rendered in the graphics memory GMEM to store a first portion of the target in the GMEM. The first portion of the target is stored from the GMEM in the system memory; and Each block in the second subset of the block set is rendered in the system memory instead of in the GMEM, so that the remainder of the target is stored in the system memory.

16. The apparatus according to claim 15, wherein, The corresponding chunk in the chunk set is further configured to one of the first chunk subset or the second chunk subset based on at least one of the following: overdraw associated with the corresponding chunk, blending associated with the corresponding chunk, configuration for concurrent parsing operations associated with at least the corresponding chunk, or configuration for at least one cleanup operation concurrent with at least one parsing operation associated with rendering at least the corresponding chunk.

17. The apparatus according to claim 15, wherein, When the second rendering mode is selected, the unit for rendering the target is configured as follows: The target is rendered in the system memory, and the target is rendered directly in the system memory instead of in GMEM.

18. The apparatus of claim 15, further comprising: A unit for determining LRZ information associated with a low-resolution depth LRZ buffer for the target. The selection of either the first rendering mode or the second rendering mode is further based on the LRZ information.

19. The apparatus according to claim 18, wherein, The selection of either the first rendering mode or the second rendering mode is further based on the ratio of the number of visible pixels to the total number of pixels associated with rendering the target, and the number of visible pixels is based on the LRZ information.

20. The apparatus of claim 15, further comprising: A unit for determining a set of conditions based on the first visibility stream and the second visibility stream set, the set of conditions being associated with one or more resolutions, one or more unresolutions, blending, or overdrawing associated with rendering the target. The selection of either the first rendering mode or the second rendering mode is further based on a determined set of conditions.

21. A computer-readable medium storing computer-executable code for graphics processing, the code causing the processor to perform the following operations when executed by a processor: A first visibility flow corresponding to the target is determined based on a first visibility path used for the target; A second set of visibility streams corresponding to each of the chunk sets is determined based on a second set of visibility paths used for the chunk set, wherein the target is divided into the chunk set; Based on the first visibility stream and the second set of visibility streams, one of a first rendering mode or a second rendering mode is selected for the target, the first rendering mode comprising rendering each chunk in the set of chunks, and the second rendering mode comprising directly rendering the target, wherein the selection of the first rendering mode or the second rendering mode is further based on at least one configuration for concurrent resolution or concurrent cancellation associated with rendering the target; and The target is rendered based on either the first rendering mode or the second rendering mode. When the first rendering mode is selected, in order to render the target, the code causes the processor to: Based on the corresponding second visibility stream in the second visibility stream set, each block in the block set is configured into an item in either the first block subset or the second block subset; Each block in the first subset of blocks is rendered in the graphics memory GMEM to store a first portion of the target in the GMEM. The first portion of the target is stored from the GMEM in the system memory; and Each block in the second subset of the block set is rendered in the system memory instead of in the GMEM, so that the remainder of the target is stored in the system memory.

22. The computer-readable medium of claim 21, wherein, The corresponding chunk in the chunk set is further configured to one of the first chunk subset or the second chunk subset based on at least one of the following: overdraw associated with the corresponding chunk, blending associated with the corresponding chunk, configuration for concurrent parsing operations associated with at least the corresponding chunk, or configuration for at least one cleanup operation concurrent with at least one parsing operation associated with rendering at least the corresponding chunk.

23. The computer-readable medium of claim 21, wherein, When the second rendering mode is selected, in order to render the target, the code causes the processor to: The target is rendered in the system memory, and the target is rendered directly in the system memory instead of in GMEM.

24. The computer-readable medium of claim 21, wherein, The code also enables the processor to: Determine the LRZ information associated with the low-resolution depth LRZ buffer used for the target. The selection of either the first rendering mode or the second rendering mode is further based on the LRZ information.

25. The computer-readable medium of claim 24, wherein, The selection of either the first rendering mode or the second rendering mode is further based on the ratio of the number of visible pixels to the total number of pixels associated with rendering the target, and the number of visible pixels is based on the LRZ information.

26. The computer-readable medium of claim 21, wherein, The code also enables the processor to: A set of conditions is determined based on the first visibility stream and the second visibility stream set, the set of conditions being associated with one or more resolutions, one or more unresolutions, blending, or overdrawing associated with rendering the target. The selection of either the first rendering mode or the second rendering mode is further based on a determined set of conditions.

27. The computer-readable medium of claim 21, wherein, The selection of either the first rendering mode or the second rendering mode is further based on a configuration for at least one cleanup operation concurrent with at least one parsing operation associated with the rendering of the target.

Images