System and method for efficient multi-GPU rendering of geometry by pretesting against interleaved screen regions before rendering

Abstract

To provide a method for graphics processing.SOLUTION: The method includes: rendering graphics for an application by using a plurality of graphics processing units (GPUs); dividing responsibility for the rendering of geometry of the graphics between the plurality of GPUs based on a plurality of screen regions that are interleaved, wherein each GPU has a corresponding division of the responsibility which is known to the plurality of GPUs; assigning a piece of geometry of an image frame generated by the application, to a GPU for geometry pretesting; performing geometry pretesting at the GPU to generate information regarding the piece of geometry and its relation to each of the plurality of screen regions; and using the information at each of the plurality of GPUs when rendering the image frame.SELECTED DRAWING: Figure 6B

Description

[Technical field]

[0001] The present disclosure relates to graphics processing, and more particularly, to multi-GPU cooperation when rendering images for applications. [Background technology]

[0002] In recent years, there has been a continuing effort towards online services that allow online or cloud gaming to occur in a streaming format between cloud gaming servers and clients connected through a network. The streaming format has become increasingly popular due to the availability of game titles on demand, the ability to run more complex games, network connectivity between players in case of multiplayer gaming, asset sharing between players, instantaneous sharing of experiences between players and / or spectators, the ability of friends to watch friends play video games, and the ability of friends to join in on-going gameplay of friends.

[0003] A cloud gaming server may be configured to provide resources to one or more clients and / or applications. That is, a cloud gaming server may be configured with resources capable of high throughput. For example, there is a limit to the performance that an individual graphics processing unit (GPU) can achieve. It may be desirable to use multiple GPUs to render a single image in order to render more complex scenes or to use more complex algorithms (e.g., materials, lighting, etc.) when generating a scene. However, even if there are multiple GPUs to process images for an application using conventional techniques, a corresponding increase in both screen pixel count and geometry density cannot be supported (four GPUs cannot write four times the pixels and / or process four times the vertices or primitives for an image).

[0004] It is against this background that embodiments of the present disclosure have been made. Summary of the Invention

[0005] Embodiments of the present disclosure relate to using multiple GPUs in cooperation to render a single image, for example, multi-GPU rendering of geometry for an application by performing pre-testing on screen regions (which may be interleaved) before rendering.

[0006] In an embodiment of the present disclosure, a method for performing graphics processing is disclosed. The method includes rendering graphics for an application using a plurality of graphics processing units (GPUs). The method divides a responsibility for rendering the geometry of the graphics among a plurality of GPUs based on a plurality of screen regions, each GPU having a corresponding division of the responsibility known to the plurality of GPUs. The screen regions are interleaved. The method includes assigning a plurality of pieces of geometry of an image frame to a plurality of GPUs for geometry testing. The method includes assigning a piece of geometry of an image frame generated by an application to a GPU for geometry testing. The method includes performing a geometry test at the GPU to generate information regarding the piece of geometry and its relationship to each of a plurality of screen regions. The method includes rendering the piece of geometry using the information at each of the plurality of GPUs, where using the information can include, for example, skipping rendering entirely if it is determined that the piece of geometry does not overlap any screen region assigned to a given GPU.

[0007] In another embodiment, a non-transitory computer readable medium for performing a method is disclosed. The computer readable medium includes program instructions for rendering graphics for an application using a plurality of graphics processing units (GPUs). The computer readable medium includes program instructions for dividing a responsibility for rendering geometry of the graphics among a plurality of GPUs based on a plurality of screen regions, each GPU having a corresponding division of responsibility known to the plurality of GPUs, the screen regions in the plurality of screen regions being interleaved. The computer readable medium includes program instructions for assigning pieces of geometry of an image frame generated by the application to the GPUs for geometry pre-testing. The computer readable medium includes program instructions for performing geometry pre-testing in the GPUs to generate information regarding the pieces of geometry and their relationship to each of the plurality of screen regions. The computer readable medium includes program instructions for using the information in each of the plurality of GPUs when rendering the image frame.

[0008] In yet another embodiment, a computer system is disclosed. The computer system includes a processor and a memory coupled to the processor and having instructions stored thereon, the instructions, when executed by the computer system, causing the computer system to perform a method for performing graphics processing. The method includes rendering graphics for an application using a plurality of graphics processing units (GPUs). The method divides a responsibility for rendering geometry of the graphics among the plurality of GPUs based on a plurality of screen regions, each GPU having a corresponding division of the responsibility known to the plurality of GPUs, the screen regions in the plurality of screen regions being interleaved. The method includes assigning pieces of geometry of an image frame generated by the application to the GPUs for geometry pre-testing. The method includes performing geometry pre-testing at the GPU to generate information about the pieces of geometry and their relationship to each of the plurality of screen regions. The method includes using the information at each of the plurality of GPUs when rendering the image frame.

[0009] In an embodiment of the present disclosure, a method for performing graphics processing is disclosed. The method includes rendering graphics for an application using a plurality of graphics processing units (GPUs). The method includes dividing the responsibility for rendering the geometry of the graphics among a plurality of GPUs based on a plurality of screen regions, each GPU having a corresponding division of the responsibility known to the plurality of GPUs. The method includes performing a geometry test in a GPU pre-test for a plurality of pieces of geometry of an image frame generated by the application to generate information regarding each piece of geometry and its relationship to each of a plurality of screen regions. The method includes rendering the plurality of pieces of geometry in each of the plurality of GPUs using the generated information for each of the plurality of pieces of geometry, where using the information includes, for example, skipping rendering entirely if it is determined that the piece of geometry does not overlap any screen region assigned to a given GPU.

[0010] In another embodiment, a non-transitory computer readable medium for performing a method is disclosed. The computer readable medium includes program instructions for rendering graphics for an application using multiple graphics processing units (GPUs). The computer readable medium includes program instructions for dividing the responsibility for rendering the geometry of the graphics among multiple GPUs based on multiple screen regions, each GPU having a corresponding division of the responsibility known to the multiple GPUs. The computer readable medium includes program instructions for performing geometry tests in a GPU pre-test for multiple pieces of geometry of an image frame generated by the application to generate information regarding each piece of geometry and its relationship to each of the multiple screen regions. The computer readable medium includes program instructions for rendering multiple pieces of geometry in each of the multiple GPUs using the generated information for each of the multiple pieces of geometry, where using the information includes, for example, skipping rendering entirely if it is determined that the piece of geometry does not overlap any screen region assigned to a given GPU.

[0011] In yet another embodiment, a computer system is disclosed. The computer system includes a processor and a memory coupled to the processor and having instructions stored thereon, the instructions, when executed by the computer system, causing the computer system to perform a method for performing graphics processing. The method includes rendering graphics for an application using a plurality of graphics processing units (GPUs). The method divides a responsibility for rendering a geometry of the graphics among the plurality of GPUs based on a plurality of screen regions, each GPU having a corresponding division of responsibility known to the plurality of GPUs. The method includes performing a geometry test in a GPU pre-test for a plurality of pieces of geometry of an image frame generated by the application to generate information regarding each piece of geometry and its relationship to each of a plurality of screen regions. The method uses the generated information for each of the plurality of pieces of geometry to render the plurality of pieces of geometry in each of the plurality of GPUs, and when using the information, for example, skipping rendering entirely if it is determined that the piece of geometry does not overlap any screen region assigned to a given GPU.

[0012] In an embodiment of the present disclosure, a method for performing graphics processing is disclosed. The method includes rendering graphics for an application using a plurality of graphics processing units (GPUs). The method includes dividing a responsibility for rendering a geometry of the graphics among the plurality of GPUs based on a plurality of screen regions, each GPU having a corresponding division of the responsibility known to the plurality of GPUs. The method includes rendering a first plurality of pieces of geometry in the plurality of GPUs during a rendering phase of a previous image frame generated by the application. The method includes generating statistics for the rendering of the previous image frame. The method includes assigning a second plurality of pieces of geometry of a current image frame generated by the application to the plurality of GPUs for geometry testing based on the statistics. The method includes performing a geometry test on the second plurality of pieces of geometry in the current image frame to generate information regarding each piece of the second plurality of pieces of geometry and its relationship to each of a plurality of screen regions, the geometry test being performed based on the assignment in each of the plurality of GPUs. The method includes rendering a second plurality of pieces of geometry on each of a plurality of GPUs using the information generated for each of the second plurality of pieces of geometry, and skipping rendering entirely when it is determined that the piece of geometry does not overlap with any screen area assigned to a given GPU when using the information.

[0013] In another embodiment, a non-transitory computer readable medium for performing a method is disclosed. The computer readable medium includes program instructions for rendering graphics for an application with a plurality of graphics processing units (GPUs). The computer readable medium includes program instructions for dividing a responsibility for rendering a geometry of the graphics among a plurality of GPUs based on a plurality of screen regions, each GPU having a corresponding division of responsibility known to the plurality of GPUs. The computer readable medium includes program instructions for rendering a first plurality of pieces of geometry in the plurality of GPUs during a rendering phase of a previous image frame generated by the application. The computer readable medium includes program instructions for generating statistics for the rendering of the previous image frame. The computer readable medium includes program instructions for assigning a second plurality of pieces of geometry of a current image frame generated by the application to the plurality of GPUs for geometry testing based on the statistics. The computer readable medium has programming instructions for performing a geometry test on a second plurality of pieces of geometry in a current image frame to generate information regarding each piece of the second plurality of pieces of geometry and its relationship to each of a plurality of screen regions, the geometry test being performed based on the assignment in each of the plurality of GPUs. The computer readable medium has programming instructions for rendering the second plurality of pieces of geometry in each of the plurality of GPUs using the generated information for each of the second plurality of pieces of geometry, where, when using the information, for example, rendering can be skipped entirely if it is determined that the piece of geometry does not overlap any screen region assigned to a given GPU.

[0014] In yet another embodiment, a computer system is disclosed. The computer system includes a processor and a memory coupled to the processor and having instructions stored thereon, the instructions, when executed by the computer system, causing the computer system to perform a method for performing graphics processing. The method includes rendering graphics for an application using a plurality of graphics processing units (GPUs). The method divides a responsibility for rendering a geometry of the graphics among the plurality of GPUs based on a plurality of screen regions, each GPU having a corresponding division of responsibility known to the plurality of GPUs. The method renders a first plurality of pieces of geometry in the plurality of GPUs during a rendering phase of a previous image frame generated by the application. The method includes generating statistics for the rendering of the previous image frame. The method includes assigning a second plurality of pieces of geometry of a current image frame generated by the application to the plurality of GPUs for geometry testing based on the statistics. The method performs a geometry test on the second plurality of pieces of geometry in the current image frame to generate information regarding each piece of the second plurality of pieces of geometry and its relationship to each of a plurality of screen regions, the geometry testing being performed based on the assignment in each of the plurality of GPUs. The method may include rendering a second plurality of pieces of geometry on each of a plurality of GPUs using the information generated for each of the second plurality of pieces of geometry, and skipping rendering entirely when using the information, for example, if it is determined that the piece of geometry does not overlap with any screen area assigned to the given GPU.

[0015] An embodiment of the present disclosure discloses a method for performing graphics processing. The method includes rendering graphics for an application using a plurality of graphics processing units (GPUs). The method divides a responsibility for rendering a geometry of the graphics among a plurality of GPUs based on a plurality of screen regions, each GPU having a corresponding division of the responsibility known to the plurality of GPUs. The method assigns a plurality of pieces of geometry of an image frame to a plurality of GPUs for geometry testing. The method includes setting a first state that configures one or more shaders to perform the geometry test. The method includes performing a geometry test on the plurality of pieces of geometry in the plurality of GPUs to generate information regarding each piece of geometry and its relationship to each of a plurality of screen regions. The method includes setting a second state that configures one or more shaders to perform rendering. The method uses the information generated for each of the plurality of pieces of geometry to render the plurality of pieces of geometry in each of the plurality of GPUs, and skips rendering entirely when using the information, for example, if it is determined that the piece of geometry does not overlap any screen region assigned to a given GPU.

[0016] In another embodiment, a non-transitory computer readable medium for performing a method is disclosed. The computer readable medium includes program instructions for rendering graphics for an application using a plurality of graphics processing units (GPUs). The computer readable medium has program instructions for dividing a responsibility for rendering a geometry of the graphics among a plurality of GPUs based on a plurality of screen regions, each GPU having a corresponding division of the responsibility known to the plurality of GPUs. The computer readable medium includes program instructions for assigning a plurality of pieces of geometry of an image frame to a plurality of GPUs for geometry testing. The computer readable medium includes program instructions for setting a first state that configures one or more shaders to perform the geometry test. The computer readable medium includes program instructions for performing a geometry test on a plurality of pieces of geometry in the plurality of GPUs to generate information regarding each piece of geometry and its relationship to each of a plurality of screen regions. The computer readable medium includes program instructions for setting a second state that configures one or more shaders to perform rendering. The computer-readable medium has program instructions for rendering multiple pieces of geometry on each of multiple GPUs using the information generated for each of the multiple pieces of geometry, and, when using the information, for example, skipping rendering entirely if it is determined that the piece of geometry does not overlap with any screen area assigned to a given GPU.

[0017] In yet another embodiment, a computer system is disclosed. The computer system includes a processor and a memory coupled to the processor and having instructions stored thereon, the instructions, when executed by the computer system, causing the computer system to perform a method for performing graphics processing. The method includes rendering graphics for an application using a plurality of graphics processing units (GPUs). The method divides a responsibility for rendering geometry of the graphics among the plurality of GPUs based on a plurality of screen regions, each GPU having a corresponding division of responsibility known to the plurality of GPUs. The method includes assigning a plurality of pieces of geometry of an image frame to the plurality of GPUs for geometry testing. The method includes setting a first state that configures one or more shaders to perform the geometry test. The method includes performing a geometry test on the plurality of pieces of geometry in the plurality of GPUs to generate information regarding each piece of geometry and its relationship to each of a plurality of screen regions. The method includes setting a second state that configures one or more shaders to perform the rendering. The method uses the generated information for each of the pieces of geometry to render the pieces of geometry on each of the multiple GPUs, and when using the information, for example, skips rendering entirely if it is determined that the piece of geometry does not overlap with any screen area assigned to a given GPU.

[0018] An embodiment of the present disclosure discloses a method for performing graphics processing. The method includes rendering graphics for an application using a plurality of graphics processing units (GPUs). The method divides a responsibility for rendering a geometry of the graphics among a plurality of GPUs based on a plurality of screen regions, with each GPU having a corresponding division of the responsibility known to the plurality of GPUs. The method includes allocating a plurality of pieces of geometry of an image frame to a plurality of GPUs for geometry testing. The method includes interleaving a first set of shaders that perform geometry testing and rendering on a first set of pieces of geometry and a second set of shaders that perform geometry testing and rendering on a second set of pieces of geometry. The geometry testing generates corresponding information regarding each piece of geometry in the first set or the second set and its relationship to each of a plurality of screen regions. The corresponding information is used by the plurality of GPUs to render each piece of geometry in the first set or the second set. When using the information, for example, if it is determined that a piece of geometry does not overlap with any screen area allocated to a given GPU, then rendering is skipped entirely.

[0019] In another embodiment, a non-transitory computer readable medium for performing a method is disclosed. The computer readable medium includes program instructions for rendering graphics for an application using a plurality of graphics processing units (GPUs). The computer readable medium includes program instructions for dividing the responsibility for rendering the geometry of the graphics among the plurality of GPUs based on a plurality of screen regions, each GPU having a corresponding division of the responsibility known to the plurality of GPUs. The computer readable medium includes program instructions for assigning a plurality of pieces of geometry of an image frame to the plurality of GPUs for geometry testing. The computer readable medium includes programming instructions for interleaving a first set of shaders that perform geometry testing and rendering on a first set of pieces of geometry and a second set of shaders that perform geometry testing and rendering on a second set of pieces of geometry. The geometry testing generates corresponding information regarding each piece of geometry in the first set or the second set and its relationship to each of the plurality of screen regions. The corresponding information is used by the plurality of GPUs to render each piece of geometry in the first set or the second set. When using the information, for example, if it is determined that a piece of geometry does not overlap with any screen area allocated to a given GPU, then rendering is skipped entirely.

[0020] In yet another embodiment, a computer system is disclosed. The computer system includes a processor and a memory coupled to the processor and having instructions stored thereon, the instructions, when executed by the computer system, causing the computer system to perform a method for performing graphics processing. The method includes rendering graphics for an application using a plurality of graphics processing units (GPUs). The method divides a responsibility for rendering geometry of the graphics among the plurality of GPUs based on a plurality of screen regions, each GPU having a corresponding division of responsibility known to the plurality of GPUs. The method includes assigning a plurality of pieces of geometry of an image frame to the plurality of GPUs for geometry testing. The method interleaves a first set of shaders that perform geometry tests and rendering on a first set of pieces of geometry and a second set of shaders that perform geometry tests and rendering on a second set of pieces of geometry. The geometry test generates corresponding information regarding each piece of geometry in the first or second set and its relationship to each of the plurality of screen regions. The corresponding information is used by the multiple GPUs to render each piece of geometry in the first or second set, for example, to skip rendering entirely if it is determined that the piece of geometry does not overlap with any screen region assigned to a given GPU.

[0021] Other aspects of the present disclosure will become apparent from the following detailed description, taken in conjunction with the accompanying drawings, which illustrate, by way of example, the principles of the present disclosure.

[0022] The present disclosure may be best understood by referring to the accompanying drawings in conjunction with the following description. [Brief description of the drawings]

[0023] [Figure 1]FIG. 1 illustrates a system for providing gaming over a network among one or more cloud gaming servers configured to run multiple GPUs (graphics processing units) in cooperation to render a single image, according to an embodiment of the present disclosure, including multiple GPUs that render geometry for an application by pre-testing geometry over screen regions (which may be interleaved). [Diagram 2] FIG. 2 is a diagram of a multi-GPU architecture in which multiple GPUs work together to render a single image, according to one embodiment of the present disclosure. [Diagram 3] FIG. 1 illustrates a diagram of multiple graphics processing unit resources configured to perform multi-GPU rendering of geometry for an application by pre-testing the geometry against screen regions (which may be interleaved) in accordance with one embodiment of the present disclosure. [Figure 4] FIG. 1 illustrates a rendering architecture that implements a graphics pipeline configured for multi-GPU processing in which multiple GPUs work together to render a single image, according to one embodiment of the present disclosure. [Diagram 5] FIG. 1 is a flow diagram illustrating a method for performing graphics processing including multi-GPU rendering of geometry for an application by performing pre-testing on interleaved screen regions before rendering, according to one embodiment of the present disclosure. [Figure 6A] FIG. 2 is a diagram of a screen subdivided into quadrants when performing multi-GPU rendering, according to one embodiment of the present disclosure. [Figure 6B] FIG. 2 is a diagram of a screen being subdivided into multiple interleaved regions when performing multi-GPU rendering, according to one embodiment of the present disclosure. [Figure 7A] FIG. 2 is a diagram of a rendering command buffer shared by multiple GPUs working together to render a single image, including pre-test and rendering portions of geometry, according to one embodiment of the present disclosure. [Figure 7B-1] FIG. 2 illustrates an example image including four objects rendered by multiple GPUs according to one embodiment of the present disclosure, showing the screen area responsibility for each GPU when rendering the objects of the image. [Figure 7B-2] 7B-1 is a table illustrating the rendering performed by each GPU when rendering the four objects of FIG. 7B-1 according to one embodiment of the present disclosure. [Figure 7C] FIG. 7B-1 illustrates an embodiment of the present disclosure in which geometry pre-testing and geometry rendering are performed by one or more GPUs when rendering an image frame through cooperation of multiple GPUs (e.g., the image of FIG. 7B-1). [Figure 8A] FIG. 2 illustrates an example object testing for screen region when multiple GPUs work together to render a single image, according to one embodiment of the present disclosure. [Figure 8B] FIG. 2 illustrates testing of portions of an object against screen area when multiple GPUs work together to render a single image, according to one embodiment of the present disclosure. [Figure 9] 1A-C are diagrams illustrating various strategies for allocating screen area to corresponding GPUs when multiple GPUs work together to render a single image, according to one embodiment of the present disclosure. [Figure 10] 1A-1C are diagrams illustrating various distributions of GPU allocation for performing geometry pre-tests on multiple pieces of geometry according to embodiments of the present disclosure. [Figure 11A] FIG. 1 illustrates pre-testing and rendering of geometry of a previous image frame by multiple GPUs, and using statistics collected during rendering to influence the allocation of pre-testing of geometry of a current image frame to multiple GPUs for the current image frame, according to one embodiment of the present disclosure. [Figure 11B]FIG. 1 is a flow diagram illustrating a method for performing graphics processing including pre-testing and rendering of geometry of a previous image frame with multiple GPUs, and using statistics collected during rendering to influence the allocation of pre-testing of geometry of a current image frame to multiple GPUs for the current image frame, in accordance with one embodiment of the present disclosure. [Figure 12A] FIG. 1 illustrates the use of a shader configured to perform both pre-testing and rendering of geometry of an image frame in two passes through a portion of a command buffer, according to one embodiment of the disclosure. [Figure 12B] FIG. 1 is a flow diagram illustrating a method for performing graphics processing that includes both pre-testing and rendering geometry of an image frame using the same set of shaders in two passes through a portion of a command buffer, according to one embodiment of the present disclosure. [Figure 13A] FIG. 1 illustrates the use of a shader configured to perform both geometry testing and rendering, in which the geometry testing and rendering performed on different sets of pieces of geometry are interleaved using separate portions of corresponding command buffers, in accordance with one embodiment of the present disclosure. [Figure 13B] FIG. 1 is a flow diagram illustrating a method for performing graphics processing that includes interleaving geometry pre-testing and rendering of an image frame for different sets of pieces of geometry with separate portions of corresponding command buffers, according to one embodiment of the present disclosure. [Figure 14] FIG. 1 illustrates components of an example device that can be used to implement aspects of various embodiments of the present disclosure. DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

[0024] Although the following detailed description contains many specific details for purposes of explanation, one of ordinary skill in the art will recognize that many variations and modifications to the following details are within the scope of the disclosure. Accordingly, the aspects of the disclosure described below are set forth without any loss of generality to, and without imposing limitations on, the claims that follow this description.

[0025] Generally speaking, there is a limit to the performance that an individual GPU can achieve, which is derived, for example, from a limit on how large a GPU can be. In embodiments of the present disclosure, it is desirable to use multiple GPUs to render a single image in order to render more complex scenes or to use more complex algorithms (e.g., materials, lighting, etc.). In particular, various embodiments of the present disclosure describe methods and systems configured to perform multi-GPU rendering of geometry for an application by pre-testing the geometry against screen regions (which may be interleaved). The multiple GPUs work together to generate the image. The responsibility for rendering is divided among the multiple GPUs based on the screen regions. Before rendering the geometry, the GPU generates information about the geometry and its relationship to the screen regions. This allows the GPU to render the geometry more efficiently or avoid rendering altogether. For example, this has the advantage that multiple GPUs can render more complex scenes and / or images at the same time.

[0026] With the above general understanding of the various embodiments in mind, detailed examples of the embodiments will now be described with reference to the various drawing figures.

[0027] Throughout the specification, references to an "application" or a "game" or a "video game" or a "gaming application" are intended to represent any type of interactive application that is directed through the execution of input commands. By way of example only, interactive applications include applications for gaming, word processing, video processing, video game processing, etc. Furthermore, the terms introduced above are interchangeable.

[0028] Throughout the specification, various embodiments of the present disclosure are described in terms of performing multi-GPU processing or rendering of geometry for an application using an exemplary architecture having four GPUs, although it will be appreciated that any number of GPUs (e.g., two or more GPUs) may cooperate when rendering geometry for an application.

[0029] FIG. 1 is a diagram of a system for multi-GPU processing when rendering images (e.g., image frames) for an application, according to one embodiment of the present disclosure. In accordance with an embodiment of the present disclosure, the system is configured to provide gaming over a network among one or more cloud gaming servers, and more specifically, configured to coordinate multiple GPUs to render a single image for an application. Cloud gaming involves running a video game on a server to generate game-rendered video frames, which are then sent to a client for display. In particular, the system 100 is configured to provide efficient multi-GPU rendering of geometry for an application by pre-testing screen regions (which may be interleaved or interleaved) prior to rendering.

[0030] While FIG. 1 illustrates an implementation of multi-GPU rendering of geometry across one or more cloud gaming servers of a cloud gaming system, other embodiments of the present disclosure provide efficient multi-GPU rendering of geometry for applications by performing area tests during rendering within a standalone system (e.g., a personal computer or gaming console that includes a high-end graphics card with multiple GPUs).

[0031] It should also be appreciated that multi-GPU rendering of geometry may be performed using physical or virtual GPUs, or a combination of both, in various embodiments (e.g., in a cloud gaming environment or in a standalone system). For example, a virtual machine (e.g., an instance) may be formed using a hypervisor on host hardware (e.g., located in a data center) using one or more components of a hardware layer (e.g., multiple CPUs, memory modules, GPUs, network interfaces, communication components, etc.). These physical resources may be arranged in racks (e.g., a rack of CPUs, a rack of GPUs, a rack of memory, etc.). The physical resources in the racks may be accessed using a top-of-rack switch, which facilitates a structure for assembling and accessing components for use with the instance (e.g., when building the virtualized components of the instance). In general, a hypervisor may present multiple guest operating systems of multiple instances configured with virtual resources. That is, each operating system may be configured with a corresponding set of virtualized resources supported by one or more hardware resources (e.g., located in a corresponding data center). For example, each operating system may be supported by a virtual CPU, multiple virtual GPUs, virtual memory, virtualized communication components, etc. Additionally, the configuration of an instance may be transferred from one data center to another to reduce latency. The GPU utilization defined for a user or game may be used when saving a gaming session for the user. The GPU utilization may include any number of configurations described herein for optimizing fast rendering of video frames for a gaming session. In one embodiment, the GPU utilization defined for a game or user may be transferred between data centers as a configurable setting.As users connect to play games from different geolocations, the ability to port GPU utilization settings allows gameplay to be efficiently migrated from data center to data center.

[0032] According to one embodiment of the disclosure, the system 100 provides gaming via a cloud gaming network 190. The games are executed remotely from the client devices 110 (e.g., thin clients) of the corresponding users who are playing the games. The system 100 may provide gaming control for one or more users who are playing one or more games through the cloud gaming network 190 via the network 150 in either single player or multiplayer mode. In some embodiments, the cloud gaming network 190 may include multiple virtual machines (VMs) that execute on a hypervisor of a host machine. The one or more virtual machines are configured to execute a game processor module that uses hardware resources available to the host hypervisor. The network 150 may include one or more communication technologies. In some embodiments, the network 150 may include a fifth generation (5G) network technology having an advanced wireless communication system.

[0033] In some embodiments, wireless technologies may be used to facilitate communication. Such technologies may include, for example, 5G wireless communication technologies. 5G is the fifth generation of cellular network technology. 5G networks are digital cellular networks in which the service area covered by a provider is divided into small geographical areas known as cells. Analog signals representing sound and images are digitized in the phone, converted by an analog-to-digital converter, and transmitted as a stream of bits. All 5G wireless devices within a cell communicate by radio waves using a local antenna array and low-power automated transceivers (transmitters and receivers) within the cell on frequency channels assigned by the transceivers from a pool of frequencies reused in other cells. The local antennas are connected to the telephone network and the Internet by high-bandwidth optical fiber or wireless backhaul connections. As with other cellular networks, when a mobile device crosses from one cell to another, it is automatically transferred to the new cell. Of course, 5G networks are merely an example of a type of communication network, and embodiments of the present disclosure may use previous generations of wireless or wired communication, as well as later generations of wired or wireless technologies that come after 5G.

[0034] As shown, the cloud gaming network 190 includes a game server 160 that provides access to multiple video games. The game server 160 may be any type of server computing device available in the cloud and may be configured as one or more virtual machines running on one or more hosts. For example, the game server 160 may manage virtual machines supporting game processors that instantiate instances of games for users. Thus, the game processors of the game server 160 associated with the multiple virtual machines are configured to run multiple instances of one or more games associated with gameplay of multiple users. In this manner, the back-end server support provides streaming of gameplay media (e.g., video, audio, etc.) of multiple gaming applications to multiple corresponding users. That is, the game server 160 is configured to stream data (e.g., rendered images and / or frames of corresponding gameplay) back to the corresponding client devices 110 over the network 150. In this manner, computationally complex gaming applications may be executed on the back-end server in response to controller inputs received and forwarded by the client devices 110. Each server can render images and / or frames, which are then encoded (eg, compressed) and streamed to a corresponding client device for display.

[0035] For example, multiple users may access the cloud gaming network 190 via the communication network 150 using corresponding client devices 110 configured to receive streaming media. In one embodiment, the client devices 110 may be configured as thin clients to provide interworking with a backend server (e.g., the cloud gaming network 190) configured to provide computing functionality (e.g., including a game title processing engine 111). In another embodiment, the client devices 110 may be configured with a game title processing engine and game logic for at least some local processing of the video game, and may also be used to receive streaming content generated by the video game running on the backend server, or other content provided by the backend server support. For local processing, the game title processing engine includes basic processor-based functionality for executing the video game and services associated with the video game. The game logic may then be stored on the local client device 110 and used to execute the video game.

[0036] Each of the client devices 110 may be requesting access to a different game from the cloud gaming network. For example, the cloud gaming network 190 may be executing one or more game logics implemented on a game title processing engine 111 for execution using CPU resources 163 and GPU resources 365 of a game server 160. For example, game logic 115a may be executing on the game server 160 for one client in conjunction with the game title processing engine 111, game logic 115b may be executing on the game server 160 for a second client in conjunction with the game title processing engine 111, ... and game logic 115n may be executing on the game server 160 for an nth client in conjunction with the game title processing engine 111.

[0037] In particular, a client device 110 of a corresponding user (not shown) is configured to request access to a game via a communications network 150 (e.g., the Internet) and to render display images (e.g., image frames) generated by a video game executed by a game server 160. The encoded images are sent to the client device 110 and displayed in association with the corresponding user. For example, the user may be interacting with an instance of a video game executing on a game processor of the game server 160 through the client device 110. More particularly, the instance of the video game is executed by a game title processing engine 111. Corresponding game logic (e.g., executable code) 115 implementing the video game is stored and accessible through a data store (not shown) and is used to execute the video game. The game title processing engine 111 may support multiple video games using multiple game logics (e.g., gaming applications), each of which is selectable by a user.

[0038] For example, the client device 110 is configured to interact with a game title processing engine 111 associated with a corresponding user's game play, e.g., through input commands used to drive the game play. In particular, the client device 110 may receive input from various types of input devices, e.g., a game controller, a tablet computer, a keyboard, gestures captured by a video camera, a mouse, a touchpad, etc. The client device 110 may be any type of computing device having at least a memory and a processor module that may be connected to the game server 160 via the network 150. The back-end game title processing engine 111 is configured to generate a rendered image. The rendered image is sent over the network 150 to be displayed on a corresponding display associated with the client device 110. For example, through a cloud-based service, the game rendered image may be sent by an instance of a corresponding game (e.g., game logic) running on the game execution engine 111 of the game server 160. That is, the client device 110 is configured to receive an encoded image (e.g., encoded from a game rendered image generated through the execution of a video game) and to display the rendered image on the display 11. In one embodiment, display 11 includes an HMD (e.g., displaying VR content). In some embodiments, rendered images may be streamed to a smartphone or tablet, wirelessly or wired, directly from a cloud-based service or via client device 110 (e.g., PlayStation® Remote Play).

[0039] In one embodiment, the game server 160 and / or the game title processing engine 111 include basic processor-based functionality for executing games and services associated with gaming applications. For example, the game server 160 includes central processing unit (CPU) resources 163 and graphics processing unit (GPU) resources 365 configured to perform processor-based functions (e.g., 2D or 3D rendering, physics simulation, scripting, audio, animation, graphics processing, lighting, shading, rasterization, ray tracing, shadowing, culling, transformation, artificial intelligence, etc.). In addition, the CPU and GPU group may perform services for the gaming applications (including, in part, memory management, multi-thread management, quality of service (QoS), bandwidth testing, social networking, management of social friends, communication with friends' social networks, communication channels, texting, instant messaging, chat support, etc.). In one embodiment, one or more applications share a particular GPU resource. In one embodiment, multiple GPU devices may be combined to perform graphics processing for a single application running on a corresponding CPU.

[0040] In one embodiment, the cloud gaming network 190 is a distributed game server system and / or architecture. In particular, a distributed game engine that executes the game logic is configured as a corresponding instance of a corresponding game. In general, a distributed game engine takes each of the game engine's functions and distributes them to be executed by multiple processing entities. Individual functions can be further distributed across one or more processing entities. The processing entities may be configured in different configurations (e.g., physical hardware) and / or as virtual components or virtual machines and / or as virtual containers. Containers are different from virtual machines because they virtualize instances of gaming applications that run on a virtualized operating system. The processing entities may use and / or rely on the servers of the cloud gaming network 190 and their underlying hardware, which may be on one or more servers (computing nodes). The servers may be located on one or more racks. The coordination, allocation, and management of the execution of these functions for the various processing entities is performed by a distributed synchronization layer. In this way, the distributed synchronization layer controls the execution of these functions to enable the generation of media (e.g., video frames, audio, etc.) for the gaming application in response to the controller input by the player. The distributed synchronization layer can perform these functions efficiently across distributed processing entities (e.g., through load balancing) and distribute and reassemble critical game engine components / functions for more efficient processing.

[0041] 2 is a diagram of an exemplary multi-GPU architecture 200 in which multiple GPUs work together to render a single image of a corresponding application, according to one embodiment of the present disclosure. Of course, many architectures in which multiple GPUs work together to render a single image are possible in various embodiments of the present disclosure, but will not be explicitly described or illustrated. For example, multi-GPU rendering of geometry for an application by performing area testing during rendering may be performed across one or more cloud gaming servers of a cloud gaming system, or may be performed within a standalone system (e.g., a personal computer or gaming console that includes a high-end graphics card with multiple GPUs).

[0042] Multi-GPU architecture 200 includes a CPU 163 and multiple GPUs configured to perform multi-GPU rendering of a single image for an application and / or each image in a sequence of images for an application. In particular, CPU 163 and GPU resources 365 are configured to perform processor-based functions (e.g., 2D or 3D rendering, physics simulation, scripting, audio, animation, graphics processing, lighting, shading, rasterization, ray tracing, shadowing, culling, transformations, artificial intelligence, etc., as previously described).

[0043] For example, although four GPUs are shown in GPU resources 365 of multi-GPU architecture 200, any number of GPUs may be used when rendering images for an application. Each GPU is connected to a corresponding dedicated memory (e.g., random access memory (RAM)) via high-speed bus 220. In particular, GPU-A is connected to memory 210A (e.g., RAM) via bus 220, GPU-B is connected to memory 210B (e.g., RAM) via bus 220, GPU-C is connected to memory 210C (e.g., RAM) via bus 220, and GPU-D is connected to memory 210D (e.g., RAM) via bus 220.

[0044] Further, each GPU is connected to each other via a bus 240. Depending on the architecture, the bus 240 may be approximately equal in speed to or slower than the bus 220 used for communication between the corresponding GPU and its corresponding memory. For example, GPU-A is connected to each of GPU-B, GPU-C, and GPU-D via the bus 240. GPU-B is also connected to each of GPU-A, GPU-C, and GPU-D via the bus 240. In addition, GPU-C is connected to each of GPU-A, GPU-B, and GPU-D via the bus 240. In addition, GPU-D is connected to each of GPU-A, GPU-B, and GPU-C via the bus 240.

[0045] CPU 163 is connected to each of the GPUs via a slower speed bus 230 (e.g., bus 230 is slower than bus 220 used for communication between a corresponding GPU and its corresponding memory). In particular, CPU 163 is connected to each of GPU-A, GPU-B, GPU-C, and GPU-D.

[0046] FIG. 3 is a diagram of a graphics processing unit resource 365 configured to perform multi-GPU rendering of geometry for image frames generated by an application by performing pre-tests on screen regions (which may be interleaved) prior to rendering, according to one embodiment of the disclosure. For example, game server 160 may be configured to include GPU resource 365 in cloud gaming network 190 of FIG. 1. As shown, GPU resource 365 includes multiple GPUs (e.g., GPU 365a, GPU 365b, . . . GPU 365n). As previously discussed, various architectures may include multiple GPUs working together to render a single image by performing multi-GPU rendering of geometry for an application through region testing during rendering. For example, performing multi-GPU rendering of geometry across one or more cloud gaming servers of a cloud gaming system, or performing multi-GPU rendering of geometry within a standalone system (e.g., a personal computer or gaming console including a high-end graphics card with multiple GPUs).

[0047] In particular, in one embodiment, the game server 160 is configured to perform multi-GPU processing when rendering a single image of an application, with multiple GPUs working together to render the single image and / or each of one or more images in a sequence of images when executing the application. For example, in one embodiment, the game server 160 may include a CPU and GPU group configured to perform multi-GPU rendering of each of one or more images in a sequence of images of an application, where one CPU and GPU group may be running the graphics and / or rendering pipeline for the application. The CPU and GPU group may be configured as one or more processing devices. As previously described, the GPU and GPU group may include a CPU 163 and GPU resources 365. The CPU 163 and GPU resources 365 are configured to perform processor-based functions (e.g., 2D or 3D rendering, physics simulation, scripting, audio, animation, graphics processing, lighting, shading, rasterization, ray tracing, shadowing, culling, transformation, artificial intelligence, etc.).

[0048] GPU resources 365 are responsible for and / or configured to render objects (e.g., writing color or normal vector values ​​for pixels of an object to multiple render targets-MRTs) and execute synchronous computation kernels (e.g., full screen effects on the resulting MRTs). The synchronous computations to perform and the objects to render are specified by commands contained in rendering command buffer 325, which the GPU executes. In particular, GPU resources 365 are configured to render objects and perform synchronous computations (e.g., while executing synchronous computation kernels) when executing commands from rendering command buffer 325, where commands and / or operations may depend on other operations such that they are performed sequentially.

[0049] For example, GPU resources 365 may be configured to perform synchronized computations and / or render objects using one or more rendering command buffers 325 (e.g., rendering command buffer 325a, rendering buffer 325b, . . . rendering command buffer 325n). In one embodiment, each GPU in GPU resources 365 may have its own command buffer. Alternatively, when substantially the same set of objects are being rendered by each GPU (e.g., due to small region sizes), the GPUs in GPU resources 365 may use the same command buffer or the same set of command buffers. Additionally, each of the GPUs in GPU resources 365 may support commands that can be executed by one GPU but not another. For example, a flag on a drawing command or predication in a rendering command buffer may allow a single GPU to execute one or more commands in the corresponding command buffer, while the other GPUs ignore the commands. For example, rendering command buffer 325a may support flag 330a, rendering command buffer 325b may support flag 330b,... rendering command buffer 325n may support flag 330n.

[0050] Performing synchronous computations (e.g., executing synchronous compute kernels) and rendering objects are portions of overall rendering. For example, if a video game is running at 60 Hz (e.g., 60 frames per second), then all object rendering and execution of synchronous compute kernels for an image frame must typically be completed within approximately 16.67 ms (e.g., one frame at 60 Hz). As previously mentioned, the operations performed when rendering objects and / or executing synchronous compute kernels are ordered, and operations may depend on other operations (e.g., commands in a rendering command buffer may need to complete execution before other commands in that rendering command buffer can execute).

[0051] In particular, each rendering command buffer 325 contains various types of commands, such as commands that affect the corresponding GPU configuration (e.g., commands that specify the location and format of a render target), as well as commands to render objects and / or execute synchronous computation kernels. For purposes of illustration, synchronous computation performed when executing synchronous computation kernels may include performing a full screen effect when objects are all rendered to one or more corresponding Multiple Render Targets (MRTs).

[0052] Additionally, GPU resources 365 are configured via registers of each GPU 365a, 365b,..., 365n when GPU resources 365 render objects for an image frame and / or execute synchronous computation kernels when generating an image frame. For example, GPU 365a is configured via its registers 340 (e.g., registers 340a, 340b,..., 340n) to perform its rendering or compute kernel execution in a particular manner. That is, the values ​​stored in registers 340 define a hardware context (e.g., GPU configuration or GPU state) for GPU 365a when executing commands in rendering command buffer 325 used to render objects for an image frame and / or execute synchronous computation kernels. Each of the GPUs in GPU resources 365 may be similarly configured such that GPU 365b is configured via its registers 350 (e.g., register 350a, register 350b, ... register 350n) to perform its rendering or calculate a kernel execution in a particular manner, ... and GPU 365n is configured via its registers 370 (e.g., register 370a, register 370b, ... register 370n) to perform its rendering or calculate a kernel execution in a particular manner.

[0053] Some examples of GPU configurations include the location and format of the render target (e.g., MRT). Other examples of GPU configurations include the operation procedure. For example, when rendering an object, the Z value of each pixel of the object can be compared to the Z buffer in various ways. For example, an object pixel can be written only if the object Z value matches the value in the Z buffer. Or, an object pixel can be written only if the object Z value is equal to or less than the value in the Z buffer. The type of test to be performed is specified in the GPU configuration.

[0054] FIG. 4 is a schematic diagram of a rendering architecture implementing a graphics pipeline 400 configured for multi-GPU processing, where multiple GPUs work together to render a single image, according to one embodiment of the disclosure. The graphics pipeline 400 illustrates a general process for rendering an image using a 3D (three-dimensional) polygon rendering process. The graphics pipeline 400 for rendering an image outputs corresponding color information for each pixel in a display. The color information may represent texture and shading (e.g., color, shadowing, etc.). The graphics pipeline 400 may be implementable within the client device 110, game server 160, game title processing engine 111, and / or GPU resources 365 of FIGS. 1 and 3. That is, various architectures may include multiple GPUs working together to render a single image by performing multi-GPU rendering of geometry for an application through region testing during rendering. For example, performing multi-GPU rendering of geometry across one or more cloud gaming servers of a cloud gaming system, or performing multi-GPU rendering of geometry within a standalone system (e.g., a personal computer or gaming console that includes a high-end graphics card with multiple GPUs).

[0055] As shown, the graphics pipeline receives input geometry 405. For example, a geometry processing stage 410 receives the input geometry 405. For example, the input geometry 405 may include vertices in a 3D gaming world and information corresponding to each vertex. A given object in the gaming world may be represented using a polygon (e.g., a triangle) defined by the vertices. The surface of the corresponding polygon is then processed through the graphics pipeline 400 to achieve a final effect (e.g., color, texture, etc.). Vertex attributes may include normals (e.g., which direction is perpendicular to that location of the geometry), color (e.g., RGB - red, green, and blue tricolors, etc.), and texture coordinates / mapping information.

[0056] Geometry processing stage 410 is responsible for (and can perform) both vertex processing (e.g., via vertex shaders) and primitive processing. In particular, geometry processing stage 410 may output a set of vertices that define a primitive and send it to the next stage of graphics pipeline 400, as well as positions (more precisely, homogeneous coordinates) and various other parameters for those vertices. The positions are placed in position cache 450 for access by later shader stages. Other parameters are placed in parameter cache 460, also for access by later shader stages.

[0057] Various operations may be performed by the geometry processing stage 410, such as performing lighting and shadowing calculations on primitives and / or polygons. In one embodiment, the geometry stage may process primitives and therefore perform backface culling and / or clipping (e.g., testing against the view frustum), thereby reducing the burden on downstream stages (e.g., rasterization stage 420, etc.). In another embodiment, the geometry stage may generate primitives (e.g., with functionality equivalent to a traditional geometry shader).

[0058] The primitives output by the geometry processing stage 410 are fed into a rasterization stage 420, which converts the primitives into a raster image made up of pixels. In particular, the rasterization stage 420 is configured to project objects in a scene onto a two-dimensional (2D) image plane defined by a viewing location (e.g., a camera location, a user eye location, etc.) in a 3D gaming world. At a simplified level, the rasterization stage 420 looks at each primitive and determines which pixels are affected by the corresponding primitive. In particular, the rasterizer 420 divides the primitives into pixel-sized fragments. Each fragment corresponds to a pixel in the display. It is important to note that when displaying an image, one or more fragments may contribute to the color of the corresponding pixel.

[0059] As previously mentioned, further operations may be performed by rasterization stage 420, such as clipping (identifying and ignoring fragments outside the viewing frustum) and culling (ignoring fragments obscured by closer objects) relative to the viewing location. In connection with clipping, geometry processing stage 410 and / or rasterization stage 420 may be configured to identify and ignore primitives that are outside the viewing frustum defined by the viewing location within the gaming world.

[0060] The pixel processing stage 430 may use the parameters (as well as other data) formed by the geometry processing stage to generate values ​​such as the resulting color of the pixel. In particular, the pixel processing stage 430 essentially performs shading operations on the fragments to determine how the color and brightness of the primitives vary with the available lighting. For example, the pixel processing stage 430 may determine the depth, color, normal, and texture coordinates (e.g., texture detail) for each fragment, and may further determine the appropriate levels of light, darkness, and color for the fragment. In particular, the pixel processing stage 430 calculates the characteristics of each fragment, such as color and other attributes (e.g., z-depth for distance from the viewing location, and alpha value for transparency). In addition, the pixel processing stage 430 applies lighting effects to the fragments based on the available lighting that affects the corresponding fragment. In addition, the pixel processing stage 430 may apply shadowing effects to each fragment.

[0061] The output of pixel processing stage 430 includes the processed fragments (e.g., texture and shading information) and is sent to output merger stage 440, the next stage in graphics pipeline 400. Output merger stage 440 uses the output of pixel processing stage 430, as well as other data (e.g., values ​​already in memory), to generate a final color for the pixel. For example, output merger stage 440 may perform optional blending of values ​​between the fragment and / or pixel determined from pixel processing stage 430 and values ​​already written to the MRT for that pixel.

[0062] Color values ​​for each pixel in the display may be stored in a frame buffer (not shown). These values ​​are scanned into the corresponding pixels when displaying the corresponding image of the scene. In particular, the display reads color values ​​from the frame buffer for each pixel row by row, left to right or right to left, top to bottom or bottom to top, or in any other pattern, and illuminates the pixels that use these pixel values ​​when displaying the image.

[0063] With detailed descriptions of the cloud gaming network 190 (e.g., in the game server 160) and GPU resources 365 of FIGS. 1-3, the flow diagram 500 of FIG. 5 illustrates a method for performing graphics processing when performing multi-GPU rendering of geometry for image frames generated by an application by pre-testing the geometry for interleaved screen regions prior to rendering, according to one embodiment of the present disclosure. In this manner, multiple GPU resources are used to efficiently perform rendering of objects when executing the application. As previously discussed, various architectures may include multiple GPUs working together to render a single image by performing multi-GPU rendering of geometry for an application through region testing during rendering. Rendering may occur, for example, within one or more cloud gaming servers of a cloud gaming system, or within a standalone system (e.g., a personal computer or gaming console that includes a high-end graphics card with multiple GPUs), etc.

[0064] At 510, the method includes rendering graphics for the application using multiple graphics processing units (GPUs) working together to generate images. In particular, the multi-GPU processing occurs when rendering a single image frame and / or one or more individual image frames of a sequence of image frames for the real-time application.

[0065] At 520, the method includes dividing the responsibility for rendering the geometry of the graphics among the multiple GPUs based on the multiple screen regions. That is, each GPU has a corresponding division or subdivision of the responsibility (e.g., corresponding screen region) known to all the GPUs. More specifically, each GPU has a responsibility for rendering the geometry in a corresponding set of screen regions of the multiple screen regions. The corresponding set of screen regions includes one or more screen regions. For example, a first GPU has a first division of the responsibility for rendering objects in the first set of screen regions, and a second GPU has a second division of the responsibility for rendering objects in the second set of screen regions. This is then repeated for the remaining GPUs.

[0066] At 530, the method includes allocating a first piece or fragment of geometry of an image frame generated during execution of the application to a first GPU for geometry testing. For example, an image frame may include one or more objects. Each object may be defined by one or more pieces of geometry. That is, in one embodiment, geometry pre-testing and rendering is performed on a piece of geometry that is an entire object. In another embodiment, geometry pre-testing and rendering is performed on a piece of geometry that is a portion of an entire object.

[0067] For example, each of the multiple GPUs is assigned to a corresponding portion of the geometry associated with an image frame. In particular, all portions of the geometry are assigned to a corresponding GPU for the purpose of geometry pre-testing. In one embodiment, the geometry may be assigned evenly among the multiple GPUs. For example, if there are four GPUs in the multiple, each GPU may process one-quarter of the geometry in an image frame. In other embodiments, the geometry may be assigned unevenly among the multiple GPUs. For example, in an example using four GPUs for multi-GPU rendering of an image frame, one GPU may process more geometry of the image frame than another GPU.

[0068] At 540, the method includes performing a geometry pre-test on the first GPU to generate information for how the piece of geometry relates to the multiple screen regions. In particular, the first GPU generates information for the piece of geometry and how it relates to each of the multiple screen regions. For example, the geometry pre-test by the first GPU may determine whether the piece of geometry overlaps a particular screen region assigned to the corresponding GPU for object rendering. The first piece of geometry may overlap a screen region for which another GPU has a responsibility to perform object rendering and / or may overlap a screen region for which the first GPU has a responsibility to perform object rendering. In one embodiment, before any of the multiple GPUs renders the geometry, a shader in the corresponding command buffer of the first GPU performs the geometry test. In another embodiment, the geometry test is performed by hardware, for example in the rasterization stage 420 of the graphics pipeline 400.

[0069] Geometry pre-testing is typically performed by multiple GPUs in embodiments on all geometry of the corresponding image frame simultaneously. That is, each GPU performs geometry pre-testing on its portion of the geometry of the corresponding image frame. In this manner, the geometry pre-testing by the GPUs allows each GPU to know which pieces of geometry to render and which pieces of geometry to skip. In particular, when the corresponding GPU performs geometry pre-testing, the corresponding GPU tests its portion of the geometry against the screen area of ​​each of the multiple GPUs used to render the image frame. For example, if there are four GPUs, each GPU may perform geometry testing on one-quarter of the geometry of the image frame, particularly if the geometry is uniformly assigned to the GPUs for geometry testing purposes. Thus, even though each GPU performs geometry pre-testing only on its portion of the geometry of the corresponding image frame, geometry pre-testing is typically performed by multiple GPUs in embodiments on all geometry of the image frame simultaneously, so that the generated information indicates how all geometry (e.g., pieces of geometry) in the image frame relates to the screen area of ​​all GPUs. Each screen region may be assigned to a corresponding GPU for object rendering, and / or rendering may be performed on a piece of geometry (eg, an entire object or a portion of an object).

[0070] At 550, the method includes using the information in each of the multiple GPUs when rendering the piece of geometry (e.g., to include rendering the piece of geometry completely or skipping rendering the piece of geometry). That is, rendering the piece of geometry using the information in each of the multiple GPUs. Sending geometry test results (e.g., information) to the other GPUs so that the information is known to each GPU. For example, geometry (e.g., pieces of geometry) in an image frame is typically rendered simultaneously by multiple GPUs in an embodiment. In particular, when the piece of geometry overlaps with any screen region assigned to the corresponding GPU for object rendering, the GPU renders the piece of geometry based on the information. On the other hand, when the piece of geometry does not overlap with any screen region assigned to the corresponding GPU for object rendering, the GPU can skip rendering the piece of geometry based on the information. Thus, the information enables all GPUs to render the geometry in the image frame more efficiently and / or to avoid rendering the geometry entirely. For example, rendering may be performed by shaders in corresponding command buffers to be executed by multiple GPUs. As described more fully below in Figures 7A, 12A, and 13A, the shaders may be configured to perform one or both of the geometry tests and / or the rendering based on the corresponding GPU configuration.

[0071] According to an embodiment of the present disclosure, in some architectures, if the corresponding rendering GPU receives the corresponding information in time to use it, the GPU uses the information when determining which geometry to render in the corresponding image. That is, the information may be taken as a hint. Otherwise, the rendering GPU processes the piece of geometry as it normally does. Using an example where the information may indicate whether the geometry overlaps with any screen area assigned to the rendering GPU (e.g., the second GPU), if the information indicates that there is no overlap of the geometry, the rendering GPU may skip rendering the geometry entirely. Also, if only the pieces of geometry do not overlap, the second GPU may skip rendering at least the pieces of geometry that do not overlap with any of the screen areas assigned to the second GPU for object rendering. On the other hand, the information may indicate that there is overlap for the geometry, in which case the second or rendering GPU renders the geometry. Also, the information may indicate when a particular piece of geometry overlaps with any screen area assigned to the second or rendering GPU for object rendering. In that case, the second or rendering GPU renders only the pieces of geometry that overlap. In yet other embodiments, if the information is not present or is not generated or received in time, the second GPU performs the rendering normally (e.g., renders the geometry). Thus, the information provided as a hint, if received in time, may increase the overall efficiency of the graphics processing system. If the information is not received in time, the graphics processing system still operates properly in the absence of such information.

[0072] In one embodiment, one GPU (e.g., a pre-test GPU) is dedicated to performing geometry pre-tests and generating information. That is, the dedicated GPU is not used to render objects (e.g., pieces of geometry) in a corresponding image frame. Specifically, as described above, graphics for an application are rendered using multiple GPUs. The responsibility for rendering the geometry of the graphics is divided among the multiple GPUs based on multiple screen regions (which may be interleaved), with each GPU having a corresponding division of responsibility known to the multiple GPUs. Geometry tests are performed on the multiple pieces of geometry of an image frame generated by the application in the pre-test GPU to generate information regarding each piece of geometry and its relationship to each of the multiple screen regions. The multiple pieces of geometry are rendered in each of the multiple GPUs using the information generated for each of the multiple pieces of geometry. That is, the information is used when rendering each piece of geometry by a corresponding rendering GPU from the GPU used to render the image frame.

[0073] 6A-6B show, purely for illustrative purposes, rendering for a screen subdivided into regions and sub-regions. Of course, the number of subdivisions and sub-regions can be selected for efficient multi-GPU processing of one or more images of an image and / or image sequence. That is, the screen may be subdivided into two or more regions, and each region may be further divided into sub-regions. In one embodiment of the present disclosure, the screen is subdivided into four quadrants, as shown in FIG. 6A. In another embodiment of the present disclosure, the screen is subdivided into a larger number of interleaved regions, as shown in FIG. 6B. The following description of FIGS. 6A-6B is intended to illustrate the inefficiencies that arise when performing multi-GPU rendering for multiple screen regions assigned to multiple GPUs. FIGS. 7A-7C and 8A-8B show more efficient rendering according to some embodiments of the present invention.

[0074] In particular, Figure 6A is an illustration of a screen 610A that is subdivided into quadrants (e.g., four regions) when performing multi-GPU rendering. As shown, the screen 610A is subdivided into four quadrants (e.g., A, B, C, and D). Each quadrant is assigned to one of the four GPUs [GPU-A, GPU-B, GPU-C, and GPU-D] in a one-to-one relationship. For example, GPU-A is assigned to quadrant A, GPU-B is assigned to quadrant B, GPU-C is assigned to quadrant C, and GPU-D is assigned to quadrant D.

[0075] Geometry can be culled. For example, CPU 163 can check the bounding box for each quadrant frustum and request each GPU to render only those objects that overlap its corresponding frustum. As a result, each GPU is responsible for rendering only a portion of the geometry. For purposes of illustration, screen 610 shows pieces of geometry, each piece being a corresponding object, and screen 610 shows objects 611-617 (e.g., pieces of geometry). Since no objects overlap quadrant A, GPU-A does not render any objects. GPU-B renders objects 615 and 616 (because part of object 615 is in quadrant B, the CPU's culling test correctly concludes that GPU-B must render it). GPU-C renders objects 611 and 612. GPU-D renders objects 612, 613, 614, 615, and 617.

[0076] In Fig. 6A, when the screen 610A is divided into quadrants A-D, the amount of work each GPU has to perform can be very different because, in some cases, there can be a disproportionate amount of geometry in one quadrant. For example, quadrant A has no pieces of geometry, while quadrant D has five pieces of geometry or at least parts of at least five pieces of geometry. Thus, GPU-A assigned to quadrant A is unused, while GPU-D assigned to quadrant D is disproportionately busy in rendering objects in the corresponding image.

[0077] FIG. 6B illustrates another approach to subdividing a screen into regions. In particular, when performing multi-GPU rendering of a single image or one or more individual images in an image sequence, instead of subdividing into quadrants, screen 610B is subdivided into multiple interleaved regions. In that case, screen 610B is subdivided into a larger number of interleaved regions (e.g., more than four quadrants) while using the same number of GPUs for rendering (e.g., four). The objects (611-617) shown on screen 610A are also shown in the same corresponding locations on screen 610B.

[0078] In particular, four GPUs (e.g., GPU-A, GPU-B, GPU-C, and GPU-D) are used to render images for corresponding applications. Each GPU is responsible for rendering geometry that overlaps with a corresponding region. That is, each GPU is assigned to a corresponding set of regions. For example, GPU-A is responsible for each of the regions labeled A in the corresponding set, GPU-B is responsible for each of the regions labeled B in the corresponding set, GPU-C is responsible for each of the regions labeled C in the corresponding set, and GPU-D is responsible for each of the regions labeled D in the corresponding set.

[0079] Moreover, the regions are interleaved in a certain pattern. Due to the interleaving of the regions (and the larger number of regions), the amount of work each GPU must perform can be much more balanced. For example, a pattern for interleaving the screen 610B includes alternating rows (e.g., region ABAB, etc., and region CDCD, etc.). Other patterns for interleaving the regions are also supported in embodiments of the present disclosure. For example, the patterns may include regions of repeating arrangement, uniformly distributed regions, non-uniformly distributed regions, regions of repeatable row arrangement, regions of random arrangement, regions of random row arrangement, etc.

[0080] Choosing the number of regions is important. For example, if the distribution of regions is too fine (e.g., too many regions and not optimal), each GPU still has to process most or all of the geometry. For example, it may be difficult for a GPU to check the bounding box of an object for all regions for which it is responsible. Also, even if it is possible to check the bounding box in a timely manner, small region sizes may result in each GPU having to process most of the geometry, since every object in an image overlaps with at least one region on each GPU (e.g., a GPU processes an entire object even if only a part of the object overlaps with at least one region in the set of regions assigned to that GPU).

[0081] As a result, choosing the number of regions, the pattern of interleaving, etc. is important. Choosing too few or too many regions, or choosing too few or too many regions for interleaving, or choosing an inefficient pattern for interleaving, can lead to inefficiencies when doing GPU processing (e.g., each GPU processes most or all of the geometry). In such cases, even if there are multiple GPUs for rendering the image, the corresponding increase in both screen pixel count and geometry density cannot be supported due to GPU inefficiencies (i.e., four GPUs cannot write four times the pixels and process four times the vertices or primitives). The following embodiments are directed to improvements in culling strategies (FIGS. 7A-7C) and culling granularity (FIGS. 8A-8B), among others.

[0082] 7A-7C are diagrams illustrating the use of multiple GPUs to render a single image and / or at least one or more images in a sequence of images in accordance with an embodiment of the present disclosure. The selection of four GPUs is provided merely for ease of illustrating multi-GPU rendering when rendering images while executing an application, and it should be understood that any number of GPUs may be used for multi-GPU rendering in various embodiments.

[0083] In particular, FIG. 7A is a diagram of a rendering command buffer 700A shared by multiple GPUs that work together to render a single image frame, according to one embodiment of the disclosure. That is, in this embodiment, multiple GPUs each use the same rendering command buffer (e.g., buffer 700A), and each GPU executes all commands in the rendering command buffer. Multiple commands (a complete set) are loaded into rendering command buffer 700A and used to render the corresponding image frame. Of course, more than one rendering command buffer may be used to generate the corresponding image frame. In one example, the CPU generates one or more draw calls for the image frame. The draw calls include commands that are placed in one or more rendering command buffers to be executed by one or more GPUs of GPU resources 365 of FIG. 3 when performing multi-GPU rendering of the corresponding image. In some implementations, the CPU 163 may request one or more GPUs to generate all or a portion of the draw calls used to render the corresponding image. Additionally, FIG. 7A may show the entire set of commands contained within rendering command buffer 700A, or FIG. 7A may show a portion of the entire set of commands contained within rendering command buffer 700A.

[0084] The GPUs typically render simultaneously when performing multi-GPU rendering of an image or one or more images in a sequence of images in an embodiment. Rendering an image can be broken down into multiple phases. In each phase, the GPUs must synchronize and faster GPUs must wait for slower GPUs to complete. The commands shown in FIG. 7A for the rendering command buffer 700A show one phase. Although FIG. 7A shows commands for only one phase, the rendering command buffer 700A may contain commands for one or more phases when rendering an image. In FIG. 7A, only a portion of all the commands are shown, and commands for other phases are not shown. In the piece of the rendering command buffer 700A shown in FIG. 7A illustrating one phase, there are four objects to be rendered (e.g., object 0, object 1, object 2, and object 3). This is shown in FIG. 7B-1.

[0085] As shown, the pieces of rendering command buffer 700A shown in FIG. 7A include commands for geometry testing, rendering of objects (e.g., pieces of geometry), and commands for configuring the state of one or more rendering GPUs that are executing commands from rendering command buffer 700A. For purposes of illustration only, the pieces of rendering command buffer 700A shown in FIG. 7A include commands (710-728) used for geometry pre-testing, rendering of objects, and / or execution of synchronous compute kernels when rendering a corresponding image for a corresponding application. In some implementations, geometry pre-testing and rendering of objects for that image and / or execution of synchronous compute kernels must occur within a frame period. Two processing sections are shown in rendering command buffer 700A. In particular, processing section 1 includes pre-testing or geometry testing 701, and section 2 includes rendering 702.

[0086] Section 1 includes performing geometry tests 701 of objects in an image frame. Each object may be defined by one or more pieces of geometry. The pre-test or geometry test 701 may be performed by one or more shaders. For example, a portion of the geometry of an image frame may be assigned to each GPU used in multi-GPU rendering of the corresponding image frame to perform the geometry test. In one embodiment, the entire portion may be assigned for pre-testing. The assigned portion may include one or more pieces of geometry. Each piece may include the entire object or may include a portion of the object (e.g., vertices, primitives, etc.). In particular, the geometry test is performed on the piece of geometry to generate information about how the piece of geometry relates to each of multiple screen regions. For example, the geometry test may determine whether the piece of geometry overlaps with a particular screen region assigned to the corresponding GPU for object rendering.

[0087] As shown in FIG. 7A, section 1 geometry test 701 (e.g., geometry pre-test) includes commands for configuring the state of one or more GPUs to execute commands from rendering command buffer 700A, and commands for performing geometry tests. In particular, the GPU state of each GPU is configured before the GPU executes a geometry test on a corresponding object. For example, commands 710, 713, and 715 are each used to configure the GPU state of one or more GPUs for the purpose of executing commands for the geometry test. As shown, command 710 configures the GPU state to allow geometry test commands 711-712 to be properly executed. Command 711 executes a geometry test on object 0, and command 712 executes a geometry test on object 1. Similarly, command 713 configures the GPU state to allow geometry test command 714 to execute a geometry test on object 2, and command 715 configures the GPU state to allow geometry test command 716 to execute a geometry test on object 3. Of course, the GPU state may be configured for one or more geometry test commands (eg, test commands 711 and 712).

[0088] As previously mentioned, when executing commands in the rendering command buffer 700A for geometry testing and / or rendering of objects and / or execution of synchronous computation kernels on the corresponding images, the values ​​stored in the registers define the hardware context (e.g., GPU configuration) for the corresponding GPU. As illustrated, the GPU state may change throughout the processing of the commands in the rendering command buffer 700A. Subsequent sections of the commands may be used to configure the GPU state. As applied to FIG. 7A, as well as throughout the specification, when referring to setting the GPU state, the GPU state may be set in various ways. For example, the CPU or GPU may set a value in random access memory (RAM). The GPU checks the value in RAM. In another example, the state may be internal to the GPU, such as when the command buffer is called twice as a subroutine and the internal GPU state is different between the two subroutine calls.

[0089] Section 2 includes rendering 702 of an object in an image frame (e.g., a piece of geometry is rendered). Rendering 702 may be performed by one or more shaders in command buffer 700A. As shown in FIG. 7A, rendering 702 of section 2 includes commands to configure the state of one or more GPUs to execute commands from rendering command buffer 700A and commands to perform the rendering. In particular, the GPU state of each GPU is configured before the GPU renders the corresponding object (e.g., a piece of geometry). For example, commands 721, 723, 725, and 727 are each used to configure the GPU state of one or more GPUs for purposes of executing commands for the rendering. As shown, command 721 configures the GPU state so that render command 722 can render object 0. Command 723 configures the GPU state so that render command 724 can render object 1. Command 725 configures the GPU state so that render command 726 can render object 2. Command 727 also configures the GPU state so that rendering command 728 can render object 3. Although Figure 7A shows a GPU state being configured for each rendering command (e.g., render object 0), it will be appreciated that the GPU state may be configured for one or more rendering commands.

[0090] As described above, each GPU used in the multi-GPU rendering of the corresponding image frame renders a corresponding piece of geometry based on information generated during geometry pre-testing. Specifically, the information known to each GPU provides a relationship between objects and screen regions. When rendering the corresponding pieces of geometry, the GPU may use the information if it is received in a timely manner in order to render those pieces of geometry efficiently. Specifically, when the information indicates that the piece of geometry overlaps with any screen region or regions assigned to the corresponding GPU for object rendering, the GPU performs rendering for that piece of geometry. On the other hand, the information may indicate that the first GPU should completely skip rendering the piece of geometry (e.g., the piece of geometry does not overlap with any screen region assigned to the first GPU with a responsibility to perform object rendering). In this way, each GPU renders only those pieces of geometry that overlap with the screen region or regions for which it has a responsibility to perform object rendering. Thus, the information is provided as a hint to each GPU, and the information is taken into account by each GPU that is rendering a piece of geometry if it is received before rendering begins. In one embodiment, if the information is not received in time, rendering proceeds normally. For example, a piece of geometry is rendered completely by the corresponding GPU, regardless of whether the corresponding piece of geometry overlaps with any screen area allocated to the GPU for object rendering.

[0091] For purposes of illustration only, the four GPUs divide the corresponding screen into regions between them. As previously described, each GPU has the responsibility to render objects in a corresponding set of regions. A corresponding set includes one or more regions. In one embodiment, the rendering command buffer 700A is shared by multiple GPUs that work together to render a single image. That is, the GPUs used for multi-GPU rendering of a single image or one or more individual images in an image sequence share a common command buffer. In another embodiment, each GPU may have its own command buffer.

[0092] Alternatively, in yet another embodiment, the GPUs may each be rendering a somewhat different set of objects. This may be true when it can be determined that a particular GPU does not need to render a particular object because, for example, it does not overlap with its corresponding screen region in the corresponding set. As previously mentioned, multiple GPUs can still use the same command buffer (e.g., share one command buffer) as long as the command buffer supports commands that can be executed by one GPU but not another. For example, execution of commands in the shared rendering command buffer 700A may be restricted to one of the rendering GPUs. This can be achieved in various ways. In another example, a flag may be used on the corresponding command to indicate which GPU should execute it. Predication may also be performed in the rendering command buffer with bits indicating which GPU will do what under which conditions. An example of predication is "if this is GPU-A, skip the next X commands."

[0093] In yet other embodiments, multiple GPUs may still use the same command buffer since substantially the same set of objects are being rendered by each GPU. For example, as described above, when the region is relatively small, each GPU may render all of the objects.

[0094] FIG 7B-1 illustrates an example screen 700B. Screen 700B shows an image including four objects being rendered by multiple GPUs using the rendering command buffer 700A of FIG 7A, according to one embodiment of the present disclosure. According to one embodiment of the present disclosure, multi-GPU rendering of geometry is performed for an application by pre-testing the geometry against a screen region (which may be interleaved) before rendering pieces of geometry corresponding to objects in an image frame.

[0095] In particular, the responsibility for rendering geometry is divided by screen region among the multiple GPUs. The multiple screen regions are configured to reduce the imbalance of rendering time among the multiple GPUs. For example, screen 700B shows the screen region responsibility for each GPU when rendering objects of an image. Four GPUs (GPU-A, GPU-B, GPU-C, and GPU-D) are used to render objects in the image shown in screen 700B. To balance pixel and vertex load among the GPUs, screen 700B is divided into smaller quadrants than those shown in FIG. 6A. In addition, screen 700B is divided into regions that may be interleaved. For example, the interleaving includes multiple rows of regions. Rows 731 and 733 each have region A alternating with region B. Rows 732 and 734 each have region C alternating with region D. More particularly, within the pattern, rows containing regions A and B alternate with rows containing regions C and D.

[0096] As previously discussed, various techniques may be used when dividing the screen into regions to achieve GPU processing efficiency, such as increasing or decreasing the number of regions (e.g., to select a precise amount of regions), interleaving the regions, increasing or decreasing the number of regions to interleave and select a particular pattern when interleaving regions and / or sub-regions, etc. In one embodiment, each of the multiple screen regions is of uniform size. In one embodiment, each of the multiple screen regions is not of uniform size. In yet other embodiments, the number and sizing of the multiple screen regions varies dynamically.

[0097] Each GPU is responsible for rendering objects in a corresponding set of regions. Each set may include one or more regions. Thus, GPU-A is responsible for rendering objects in each A region in the corresponding set, GPU-B is responsible for rendering objects in each B region in the corresponding set, GPU-C is responsible for rendering objects in each C region in the corresponding set, and GPU-D is responsible for rendering objects in each D region in the corresponding set. There may be other GPUs with other responsibilities, which may not perform rendering (e.g., performing asynchronous compute kernels that run over multiple frame periods, performing culling for rendering GPUs, etc.).

[0098] Each GPU has a different amount of rendering to do. FIG. 7B-2 illustrates a table showing the rendering that each GPU does when rendering the four objects in FIG. 7B-1 according to one embodiment of the present disclosure. As shown in the table, after a geometry pre-test, it may be determined that object 0 is rendered by GPU-B, object 1 is rendered by GPU-C and GPU-D, object 2 is rendered by GPU-A, GPU-B, and GPU-D, and object 3 is rendered by GPU-B, GPU-C, and GPU-D. There may be some more unbalanced rendering because GPU A needs to render only object 2 and GPU D needs to render objects 1, 2, and 3. However, overall, due to the interleaving of screen regions, the rendering of objects in an image is reasonably balanced among the multiple GPUs used for multi-GPU rendering of the image or rendering of one or more of each image in an image sequence.

[0099] 7C is a diagram illustrating the rendering of each object performed by each GPU when multiple GPUs cooperate to render a single image frame (e.g., image frame 700B shown in FIG. 7B-1) according to one embodiment of the present disclosure. In detail, FIG. 7C illustrates the rendering process of objects 0 to 3 performed by each of four GPUs (e.g., GPU-A, GPU-B, GPU-C, and GPU-D) using the shared rendering command buffer 700A in FIG. 7A.

[0100] In particular, two rendering timing diagrams are shown relative to time axis 740. Rendering timing diagram 700C-1 illustrates multi-GPU rendering of objects 0-3 of corresponding images in one phase of rendering. Each GPU performs rendering if there is no information about overlap between objects 0-3 and the screen region. Rendering timing diagram 700C-2 illustrates multi-GPU rendering of objects 0-3 of corresponding images in the same phase of rendering. Information generated during geometry testing of the screen region (e.g., performed prior to rendering) is shared by each GPU and used to render objects 0-3 through the corresponding GPU pipeline. Rendering timing diagrams 700C-1 and 700C-2 each illustrate the time it takes each GPU to process each piece of geometry (e.g., perform geometry testing and rendering). In one embodiment, the piece of geometry is an entire object. In another embodiment, the piece of geometry may be a portion of an object. For illustrative purposes, the example of FIG. 7C illustrates rendering of pieces of geometry. Each piece of geometry corresponds to an object (e.g., in its entirety). In each of rendering timing diagrams 700C-1 and 700C-2, objects (e.g., pieces of geometry) that have no geometry (e.g., object primitives) that overlap at least one screen region of the corresponding GPU (e.g., within a corresponding set of regions) are represented by dashed boxes, while objects that have geometry that overlaps at least one screen region of the corresponding GPU (e.g., within a corresponding set of regions) are represented by solid boxes.

[0101] Rendering timing diagram 700C-1 illustrates the rendering of objects 0-3 using four GPUs (e.g., GPU-A, GPU-B, GPU-C, and GPU-D). In rendering timing diagram 700C-1, vertical line 755a illustrates the beginning of a phase of rendering for an object, and vertical line 755b illustrates the end of a phase of rendering for an object. The beginning and end points along timeline 740 for the illustrated phases of rendering represent synchronization points. Each of the four GPUs is synchronized in executing a corresponding GPU pipeline. For example, at vertical line 755b, which illustrates the end of a phase of rendering, all GPUs must wait for the slowest GPU (e.g., GPU-B) to finish rendering objects 0-3 through their corresponding graphics pipeline before moving to the next phase of rendering.

[0102] In rendering timing diagram 700C-1, no geometry pre-testing is performed. Thus, each GPU must process each object through its corresponding graphics pipeline. If there are no pixels to draw for an object in any region (e.g., within the corresponding set) assigned to the corresponding GPU for object rendering, the GPU may not fully render the object through the graphics pipeline. For example, when the objects do not overlap, only the geometry processing stage of the graphics pipeline is executed. However, this still takes some time to process.

[0103] In particular, GPU-A does not fully render objects 0, 1, and 3 because they do not overlap any of the screen regions (e.g., in the corresponding set) assigned to GPU-A for object rendering. The rendering of these three objects is shown in boxes with dashed lines, indicating that at least the geometry processing stage has occurred, but the graphics pipeline has not yet occurred. GPU-A fully renders object 2 because that object overlaps at least one screen region assigned to GPU-A for rendering. The rendering of object 2 is shown in boxes with solid lines, indicating that all stages of the corresponding graphics pipeline have occurred. Similarly, GPU-B does not fully render object 1 (shown in boxes with dashed lines) (i.e., it performs at least the geometry processing stage), but fully renders objects 0, 2, and 3 (shown in boxes with solid lines) because those objects overlap at least one screen region assigned to GPU-B for rendering (e.g., in the corresponding set). Also, GPU-C does not fully render (i.e., performs at least the geometry processing stage) objects 0 and 2 (shown in boxes with dashed lines), but does fully render objects (shown in boxes with solid lines) because these objects overlap with at least one screen region (e.g., in the corresponding pair) assigned to GPU-C for rendering. Furthermore, GPU-D does not fully render (i.e., performs at least the geometry processing stage) object 0 (shown in boxes with dashed lines), but does fully render objects 1, 2, and 3 (shown in boxes with solid lines) because these objects overlap with at least one screen region (e.g., in the corresponding pair) assigned to GPU-D for rendering.

[0104] Rendering timing diagram 700C-2 illustrates geometry pre-test 701' and rendering 702' of objects 0-3 using multiple GPUs. In rendering timing diagram 700C-2, vertical line 750a illustrates the start of a rendering phase (e.g., including geometry pre-test and rendering) for an object, and vertical line 750b illustrates the end of a rendering phase for an object. The start and end points along time axis 740 for the rendering phases illustrated in timing diagram 700C-2 represent synchronization points. As previously discussed, each of the four GPUs is synchronized when executing a corresponding GPU pipeline. For example, at vertical line 750b illustrating the end of a rendering phase, all GPUs must wait for the slowest GPU (e.g., GPU-B) to finish rendering objects 0-3 through their corresponding graphics pipeline before moving to the next rendering phase.

[0105] First, the GPUs perform geometry pretest 701'. Each GPU performs geometry pretest on a subset of the geometry of the image frame for all screen regions, each of which is assigned to a corresponding GPU for object rendering. As previously described, each GPU is assigned to a corresponding portion of the geometry associated with the image frame. The geometry pretest generates information about how a particular piece of geometry relates to each of the screen regions (e.g., whether the piece of geometry overlaps with any of the screen regions (e.g., in the corresponding set) assigned to the corresponding GPU for object rendering). This information is shared by each GPU used to render the image frame. For example, the geometry pretest 701' shown in FIG. 7C includes having GPU-A perform geometry pretest on object 0, GPU-B perform geometry pretest on object 1, GPU-C perform geometry pretest on object 2, and GPU-D perform geometry pretest on object 3. Depending on the object being tested, the time to perform the geometry pretest may vary. For example, geometry pretesting of object 0 takes less time than performing geometry pretesting on object 1. This may be due to object sizing, number of overlapping screen regions, etc.

[0106] After the geometry pretest, each GPU performs rendering for all objects or pieces of geometry that intersect with its screen region. In one embodiment, each GPU starts rendering its piece of geometry as soon as the geometry test is finished. That is, there is no synchronization point between the geometry test and the rendering. This is possible because the geometry test information being generated is treated as a hint rather than a hard dependency. For example, GPU-A starts rendering object 2 before GPU-B finishes the geometry pretest for object 1, and therefore before GPU-B starts rendering objects 0, 2, and 3.

[0107] Vertical line 750a is aligned with vertical line 755a such that rendering timing diagrams 700C-1 and 700C-2 each begin at the same time to render objects 0-1. However, the rendering of objects 0-3 shown in rendering timing diagram 700C-2 occurs in less time than the rendering shown in rendering timing diagram 700C-1. That is, vertical line 750b indicating the end of a rendering phase for the lower timing diagram 700C-2 occurs earlier than the end of a rendering phase for the upper timing diagram 700C-1 indicated by vertical line 755b. Specifically, a speed increase 745 in rendering objects 0-3 is achieved when performing multi-GPU rendering of the geometry of an image for an application (including pre-testing the geometry for a region of the screen before rendering) and providing the results of the geometry pre-test as information (e.g., a hint). As shown, speed increase 745 is the time difference between vertical line 750b of timing diagram 700C-2 and vertical line 755b of timing diagram 700C-1.

[0108] The speed increase is achieved through the generation and sharing of information generated during geometry pre-test. For example, during geometry pre-test, GPU-A generates information indicating that object 0 should only be rendered by GPU-B. Thus, GPU-B is informed that it should render object 0, and other GPUs (e.g., GPU-A, GPU-C, and GPU-D) may skip rendering object 0 entirely, since object 0 does not overlap with any region (e.g., in the corresponding set) assigned to these GPUs for object rendering. For example, these GPUs do not need to perform the geometry processing stage, while, as shown in timing diagram 700C-1, this stage was processed without geometry pre-test, even if these GPUs do not completely render object 0. Also, during geometry pre-test, GPU-B generates information indicating that object 1 should be rendered by GPU-C and GPU-D, and GPU-A and GPU-B may skip rendering object 1 entirely. This is because object 1 does not overlap with any region (e.g., in the respective corresponding pairs) assigned to GPU-A or GPU-B for object rendering. Also, during geometry pre-test, GPU-C generates information indicating that object 2 should be rendered by GPU-A, GPU-B, and GPU-D, and GPU-C may skip rendering object 2 entirely. This is because object 2 does not overlap with any region (e.g., in the respective corresponding pairs) assigned to GPU-C for object rendering. Also, during geometry pre-test, GPU-D generates information indicating that object 3 should be rendered by GPU-B, GPU-C, and GPU-D, and GPU-A may skip rendering object 3 entirely.This is because object 3 does not overlap with any regions (eg, in the corresponding set) that have been assigned to GPU-A for object rendering.

[0109] The information generated from the geometry pretest is shared between the GPUs so that each GPU can determine which objects to render. Thus, after performing the geometry pretest and the results from the test are shared by all the GPUs, each GPU has information as to which object or piece of geometry the corresponding GPU needs to render. For example, GPU-A renders object 2, GPU-B renders objects 0, 2, and 3, GPU-C renders objects 1 and 3, and GPU-D renders objects 1, 2, and 3.

[0110] In particular, GPU A performs geometry processing for Object 1 and determines that Object 1 can be skipped by GPU-B because Object 1 does not overlap with any region (e.g., in the corresponding set) assigned to GPU-B for object rendering. In addition, Object 1 is not fully rendered by GPU-A because Object 1 does not overlap with any region (e.g., in the corresponding set) assigned to GPU-A for object rendering. Because the determination that Object 1 does not overlap with any region assigned to GPU-B is made before GPU-B begins geometry processing for Object 1, GPU-B skips rendering of Object 1.

[0111] 8A-8B illustrate object testing for screen regions 820A and 820B. The screen regions may be interleaved (e.g., screen regions 820A and 820B represent portions of a display). In particular, multi-GPU rendering of an object is performed for a single image frame or for each of one or more image frames in a sequence of image frames by performing a geometry test before rendering the object in the screen. As shown, GPU-A is assigned responsibility for rendering objects in screen region 820A. GPU-B is assigned responsibility for rendering objects in screen region 820B. Information for a "piece of geometry" is generated. A piece of geometry can be an entire object or a portion of an object. For example, the piece of geometry can be object 810 or a portion of object 810.

[0112] FIG. 8A illustrates an example object test for a screen region when multiple GPUs work together to render a single image, according to one embodiment of the disclosure. As previously described, a piece of geometry can be an object, where the piece corresponds to the geometry that a corresponding draw call uses or generates. During geometry pre-testing, it may be determined that object 810 overlaps with region 820A. That is, portion 810A of object 810 overlaps with region 820A. In that case, GPU-A is tasked with rendering object 810. Also, during geometry pre-testing, it may be determined that object 810 overlaps with region 820B. That is, portion 810B of object 810 overlaps with region 820B. In that case, GPU-B is also tasked with rendering object 810.

[0113] FIG. 8B is a diagram illustrating testing of portions of an object against screen regions and / or screen sub-regions when multiple GPUs work together to render a single image frame, according to one embodiment of the disclosure. That is, pieces of geometry can be parts of an object. For example, an object 810 may be divided into pieces, and the geometry that a draw call uses or generates is subdivided into smaller pieces of geometry. In one embodiment, each piece of geometry is roughly the size that a position cache and / or parameter cache is allocated for. Information (e.g., a hint or hints) is then generated for those smaller pieces of geometry during geometry testing. As previously described, the information is used by the rendering GPUs.

[0114] For example, object 810 is divided into smaller objects. The pieces of geometry used for region testing correspond to these smaller objects. As shown, object 810 is divided into pieces of geometry "a", "b", "c", "d", "e", and "f". After geometry pre-testing, GPU-A renders only pieces of geometry "a", "b", "c", "d", and "e". That is, GPU-A can skip rendering piece of geometry "f". And after geometry pre-testing, GPU-B renders only pieces of geometry "d", "e", and "f". That is, GPU-B can skip rendering piece of geometry "a", "b", and "c".

[0115] In one embodiment, since the geometry processing stage is configured to perform both vertex and primitive processing, a geometry pre-test can be performed on the piece of geometry using a shader in the geometry processing stage. For example, the geometry processing stage generates information (e.g., hints), such as by testing a bounding frustum for the geometry against a GPU screen region (which may be performed by a software shader operation). In one embodiment, this testing is accelerated through the use of a dedicated instruction or instructions implemented through hardware, resulting in a software / hardware solution. That is, a dedicated instruction or instructions are used to accelerate the generation of information about the piece of geometry and its relationship to the screen region. For example, homogeneous coordinates of vertices of primitives of the piece of geometry are provided as input to instructions for the geometry pre-test in the geometry processing stage. The testing may generate a Boolean return value for each GPU indicating whether the primitive overlaps with any screen region (e.g., in a corresponding set) allocated to that GPU for object rendering. Thus, information (eg, hints) generated during geometry pre-testing regarding corresponding geometry pieces and their relationship to screen regions are generated by shaders in the geometry processing stage.

[0116] In another embodiment, geometry pre-testing on pieces of geometry may be performed at the hardware rasterization stage, for example, a hardware scan converter may be configured to perform geometry pre-testing such that the scan converter generates information regarding all screen regions allocated to multiple GPUs for object rendering of a corresponding image frame.

[0117] In yet other embodiments, the pieces of geometry can be primitives, i.e., some of the objects used for geometry pretesting may be primitives. Thus, information (e.g., hints) generated by one GPU during geometry pretesting indicates whether individual triangles (e.g., representing primitives) should be rendered by another rendering GPU.

[0118] In one embodiment, the information generated during geometry pretest and shared by the GPUs used for rendering includes the number of primitives (e.g., the number of primitives remaining) that overlap with any screen region (e.g., in the corresponding set) assigned to the corresponding GPU for object rendering. The information may also include the number of vertices used to construct or define these primitives. That is, the information includes the number of vertices remaining. Thus, when rendering, the corresponding rendering GPU may use the provided number of vertices to allocate space in its position cache and parameter cache. For example, in one embodiment, rendering efficiency may be increased because no space is allocated to vertices that are not needed.

[0119] In other embodiments, the information (e.g., hints) generated during geometry pre-testing includes specific primitives (e.g., primitives that remain as exact matches) that overlap with any screen regions (e.g., in a corresponding set) assigned to the corresponding GPU for object rendering. That is, the information generated for the rendering GPU includes a specific set of primitives for rendering. The information may also include specific vertices used to construct or define these primitives. That is, the information generated for the rendering GPU includes a specific set of vertices for rendering. This information may, for example, save other rendering GPU time during that geometry processing stage when rendering a piece of geometry.

[0120] In yet other embodiments, there may be processing overhead (either software or hardware) associated with generating information during geometry testing. In that case, it may be useful to skip generating information for certain pieces of geometry. That is, information provided as hints is generated for certain objects but not others. For example, a piece of geometry (e.g., an object or piece of an object) representing a skybox or large terrain piece may contain large triangles. In that case, it is possible that each GPU used for multi-GPU rendering of an image frame or one or more respective image frames in an image frame sequence will need to render these pieces of geometry. That is, information may or may not be generated depending on the characteristics of the corresponding piece of geometry.

[0121] 9A-9C illustrate various strategies for allocating screen regions to corresponding GPUs when multiple GPUs work together to render a single image, according to one embodiment of the present disclosure. Various techniques may be used when dividing the screen into regions to achieve GPU processing efficiency, such as increasing or decreasing the number of regions (e.g., to select a precise amount of regions), interleaving the regions, increasing or decreasing the number of regions to interleave and select a specific pattern when interleaving the regions, etc. For example, multiple GPUs are configured to perform multi-GPU rendering of geometry for an image frame generated by an application by pre-testing the geometry against the interleaved screen regions before rendering objects in the corresponding image. The configuration of screen regions in FIGS. 9A-9C is designed to reduce even minor imbalances in rendering time between multiple GPUs. The complexity of the tests (e.g., overlapping corresponding screen regions) varies depending on how the screen regions are allocated to the GPUs. As shown in the diagrams illustrated in FIGS. 9A-9C, the bold box 910 is an outline of the corresponding screen or display used when rendering the image.

[0122] In one embodiment, the plurality of screen regions or each of the plurality of regions is of uniform size. In one embodiment, each of the plurality of screen regions is not of uniform size. In yet another embodiment, the number and sizing of screen regions in the plurality of screen regions varies dynamically.

[0123] In particular, FIG. 9A illustrates a simple pattern 900A for a screen 910. Each of the screen regions is of uniform size. For example, the size of each region may be a rectangle with dimensions that are a power of two pixels. For example, each region may be 256×256 pixels in size. As shown, the region allocation is a checkerboard pattern, with some rows of A and B regions alternating with other rows of B and C regions. Pattern 900A can be easily tested during geometry pre-testing. However, some rendering inefficiencies may exist. For example, the screen area allocated to each GPU is substantially different (i.e., less coverage for screen regions C and D within screen 910), which may lead to an imbalance in rendering times for each GPU.

[0124] FIG. 9B illustrates a pattern 900B of screen regions for a screen 910. Each of the screens or sub-regions is of uniform size. The screen regions are assigned and distributed to reduce the imbalance of rendering times between the GPUs. For example, assigning GPUs to screen regions in pattern 900B results in an approximately equal quantity of screen pixels assigned to each GPU across the screen 910. That is, the screen regions are assigned to the GPUs such that the screen area or coverage within the screen 910 is equal. For example, if each region may be 256×256 pixels in size, then the coverage of each region within the screen 910 is approximately the same. In detail, the set of screen areas A covers an area of ​​size 6x256x256 pixels, the set of screen areas B covers an area of ​​size 5.75x256x256 pixels, the set of screen areas C covers an area of ​​size 5.5x256x256 pixels, and the set of screen areas D covers an area of ​​size 5.5x256x256 pixels.

[0125] FIG. 9C illustrates an example screen region pattern 900C for a screen 910. The screen regions are not uniform in size. That is, the screen regions that are assigned the responsibility of rendering objects to a GPU may not be uniform in size. In particular, the screen 910 is divided such that each GPU is assigned the same number of pixels. For example, if a 4K display (3840×2160) is divided vertically equally into four regions, each region would be 520 pixels high. However, GPUs typically perform many operations on 32×32 blocks of pixels, and 520 pixels is not a multiple of 32 pixels. Thus, in one embodiment, the pattern 900C may include blocks that are 512 pixels high (a multiple of 32) and other blocks that are 544 pixels high (also a multiple of 32). In other embodiments, blocks of different sizes may be used. The pattern 900C illustrates how an equal number of screen pixels are assigned to each GPU by using non-uniform screen regions.

[0126] In yet another embodiment, the needs of an application when rendering images change over time and screen regions are dynamically selected. For example, if it is known that most of the rendering time is spent on the lower half of the screen, it is advantageous to allocate regions such that an approximately equal number of screen pixels in the lower half of the display are allocated to each GPU used to render the corresponding image. That is, the regions allocated to each GPU used to render the corresponding image may be dynamically changed. For example, changes may be applied based on game modes, different games, screen sizes, patterns selected for regions, etc.

[0127] FIG. 10 is a diagram illustrating various distributions of GPU allocations to pieces of geometry for purposes of geometry pre-testing, according to one embodiment of the present disclosure. That is, FIG. 10 illustrates the distribution of responsibility for generating information during geometry pre-testing among multiple GPUs. As previously described, each GPU is assigned to a corresponding portion of the geometry of an image frame. The portion may be further divided into objects, parts of objects, geometries, pieces of geometry, and the like. Geometry pre-testing involves determining whether a particular piece of geometry overlaps with any screen region or screen regions assigned to the corresponding GPU for object rendering. Geometry pre-testing is typically performed by the GPUs simultaneously for all geometry (e.g., all pieces of geometry) of a corresponding image frame in an embodiment. In this manner, geometry testing is performed by the GPUs in a coordinated manner, which allows each GPU to know which pieces of geometry to render and which pieces of geometry to skip rendering, as previously described.

[0128] As shown in FIG. 10, each piece of geometry may be an object, a portion of an object, etc. For example, as previously described, a piece of geometry may be a portion of an object (e.g., a piece that is roughly the size of the position and / or parameter cache allocated). Purely for illustrative purposes, object 0 (e.g., specified to be rendered by command 722 in rendering command buffer 700A) is divided into pieces "a", "b", "c", "d", "e", and "f" (e.g., object 810 in FIG. 8B). Object 1 (e.g., specified to be rendered by command 724 in rendering command buffer 700A) is also divided into pieces "g", "h", and "i". Object 2 (e.g., specified to be rendered by command 724 in rendering command buffer 700A) is further divided into pieces "j", "k", "l", "m", "n", and "o". The pieces may be ordered (e.g., a-o) for purposes of distributing the GPUs' responsibilities to geometry tests.

[0129] Distribution 1010 (e.g., rows ABCDABCDABCD...) indicates an even distribution of responsibility for geometry tests among multiple GPUs. In particular, rather than having one GPU take the first quarter of the geometry (e.g., in a block, for example, GPU A takes the first four pieces of approximately 16 total pieces including "a", "b", "c", and "d" for geometry tests), a second GPU take the second quarter, etc., the assignment to the GPUs is interleaved. That is, consecutive pieces of the geometry are assigned to different GPUs. For example, piece "a" is assigned to GPU-A, piece "b" is assigned to GPU-B, piece "c" is assigned to GPU-C, piece "d" is assigned to GPU-D, piece "e" is assigned to GPU-A, piece "f" is assigned to GPU-B, piece "g" is assigned to GPU-C, etc. As a result, the processing of the geometry tests is roughly balanced between the GPUs (eg, GPU-A, GPU-B, GPU-C, and GPU-D).

[0130] Distribution 1020 (e.g., rows ABBCDABBCDABBCD...) indicates an asymmetric distribution of responsibility for geometry tests among multiple GPUs. An asymmetric distribution may be advantageous if a particular GPU takes longer to perform geometry tests than other GPUs when rendering a corresponding image frame. For example, one GPU may have finished rendering objects for a previous frame or frames of a scene earlier than other GPUs, and therefore may be assigned more pieces of geometry for performing geometry tests (because this frame is also expected to finish earlier). Again, the assignments to the GPUs are interleaved. As shown, GPU-B is assigned more pieces of geometry for geometry pre-testing than the other GPUs. To illustrate, piece "a" is assigned to GPU-A, piece "b" is assigned to GPU-B, piece "c" is also assigned to GPU-B, piece "d" is assigned to GPU-C, piece "e" is assigned to GPU-D, piece "f" is assigned to GPU-A, piece "g" is assigned to GPU-B, piece "h" is also assigned to GPU-B, piece "i" is assigned to GPU-C, etc. Although the assignment of geometry tests to GPUs may not be balanced, the combined processing of a complete phase (e.g., geometry pre-test and render geometry) may turn out to be roughly balanced (e.g., each GPU spends approximately the same amount of time performing geometry pre-test and render geometry).

[0131] 11A-11B illustrate the use of statistics for one or more image frames when allocating responsibility for a geometry test among multiple GPUs. For example, based on the statistics, some GPUs may process more or less pieces of geometry during the geometry test to generate information that is useful when rendering.

[0132] In particular, Figure 11A illustrates a diagram illustrating the pre-testing and rendering of geometry of a previous image frame by multiple GPUs and using statistics collected during rendering to influence the allocation of geometry pre-testing of a current image frame to multiple GPUs in the current image frame, according to one embodiment of the present disclosure. Purely for illustrative purposes, in the second frame 1100B of Figure 11A, GPU-B processes (e.g., during pre-testing) twice as many pieces of geometry as the other GPUs (e.g., GPU-A, GPU-C, and GPU-D). The allocation of a larger share of pieces of geometry to GPU-B to perform geometry pre-testing in the current image frame is based on statistics collected during the rendering of the previous image frame or frames.

[0133] For example, timing diagram 1100A shows geometry pre-test 701A and rendering 702A on a previous image frame. For both processes, four GPUs (e.g., GPU-A, GPU-B, GPU-C, and GPU-D) are used. The allocation of geometry (e.g., pieces of geometry) for the previous image frame is evenly distributed among the GPUs. This is shown by the roughly balanced performance of geometry pre-test 701A by each GPU.

[0134] Rendering statistics collected from one or more image frames may be used to determine how to perform geometry testing and rendering of the current image frame. That is, the statistics may provide information for use when performing geometry testing and rendering of a subsequent image frame (e.g., the current image frame). For example, statistics collected during the rendering of an object (e.g., a piece of geometry) of a previous image frame may indicate that GPU-B finished rendering earlier than the other GPUs. In particular, GPU-B has idle time 1130A after rendering its portion of the geometry that overlaps with any screen region (e.g., in the corresponding set) that was assigned to GPU-B for object rendering. The other GPUs, GPU-A, GPU-C, and GPU-D each perform rendering until approximately the end 710 of the corresponding frame period of the previous image frame.

[0135] Previous and current image frames may be generated for a particular scene when executing an application. Thus, objects from scene to scene may be approximately similar in number and location. In that case, the time to perform geometry pre-test and rendering is similar for the GPUs among multiple image frames in the image frame sequence. That is, based on the statistics, it is reasonable to assume that GPU-B also has idle time when performing geometry test and rendering in the current image frame. Thus, GPU-B may be assigned more pieces of geometry for geometry pre-test in the current frame. For example, having GPU-B process more pieces of geometry during geometry pre-test results in GPU-B finishing approximately at the same time as other GPUs after rendering objects in the current image frame. That is, GPU-A, GPU-B, GPU-C, and GPU-D each perform rendering until approximately the end 711 of the corresponding frame period of the current image frame. In one embodiment, the total time to render the current image frame is shorter, resulting in a shorter time to render the current image frame when using the rendering statistics. Thus, statistics for the rendering of the previous frame and / or previous frames may be used to adjust geometry pre-testing (e.g., distribution of geometry (e.g., pieces of geometry) allocation among GPUs in the current image frame).

[0136] FIG. 11B is a flow diagram 1100B illustrating a method for performing graphics processing according to one embodiment of the disclosure, including pre-testing and rendering geometry of a previous image frame with multiple GPUs and using statistics collected during rendering to influence the allocation of pre-testing geometry of a current image frame to multiple GPUs in the current image frame. The diagram in FIG. 11A illustrates using statistics in the method of flow diagram 1100B to determine the distribution of geometry (e.g., pieces of geometry) allocation among GPUs for an image frame. As previously discussed, various architectures may include multiple GPUs working together to render a single image by performing multi-GPU rendering of geometry for an application, for example, in one or more cloud gaming servers of a cloud gaming system, or in a standalone system (e.g., a personal computer or gaming console that includes a high-end graphics card with multiple GPUs).

[0137] In particular, at 1110, the method includes rendering graphics for the application with a plurality of GPUs, as described above. At 1120, the method includes dividing the responsibility for rendering geometry of the graphics among the plurality of GPUs based on a plurality of screen regions, each GPU having a corresponding division of the responsibility known to the plurality of GPUs. More specifically, as described above, each GPU has responsibility for rendering geometry in a corresponding set of screen regions of the plurality of screen regions. The corresponding set of screen regions includes one or more screen regions. In one embodiment, the screen regions are interleaved (e.g., when a display is divided into sets of screen regions for geometry pre-testing and rendering).

[0138] At 1130, the method includes rendering a first plurality of pieces of geometry on a plurality of GPUs of a previous image frame generated by the application. For example, timing diagram 1100A illustrates timing of rendering of geometry tests and objects (e.g., pieces of geometry) of the pieces of geometry in the previous image frame. At 1140, the method includes generating statistics for the rendering of the previous image frame. That is, statistics may be collected when rendering the previous image frame.

[0139] At 1150, the method includes allocating the second plurality of pieces of geometry of the current image frame generated by the application to the multiple GPUs for the geometry test based on the statistical values. That is, the statistical values ​​may be used to allocate the same, fewer, or more pieces of geometry for the geometry test to a particular GPU when rendering the next or current image frame. In some cases, the statistical values ​​may indicate that pieces in the second plurality of pieces of geometry should be allocated evenly to the multiple GPUs when performing the geometry test.

[0140] In another case, the statistics may indicate that pieces in the second plurality of pieces of geometry must be unevenly assigned to the multiple GPUs when performing geometry testing. For example, as shown on timeline 1100A, the statistics may indicate that GPU-B finished rendering before any of the other GPUs in the previous image frame. In particular, it may be determined that the first GPU (e.g., GPU-B) finished rendering the first plurality of pieces of geometry before the second GPU (e.g., GPU-A) finished rendering the first plurality of pieces of geometry (e.g., a portion of the piece of geometry). As previously described, the first GPU (e.g., GPU-B) renders one or more pieces of the first plurality of pieces of geometry that overlap with any screen area assigned to the first GPU for object rendering, and the second GPU (e.g., GPU-A) renders one or more pieces of the first plurality of pieces of geometry that overlap with any screen area assigned to the second GPU for object rendering. Thus, based on the statistics, the first GPU (e.g., GPU-B) is expected to require less time to render the second plurality of pieces of geometry than the second GPU (e.g., GPU-A), so more pieces of geometry may be assigned to the first GPU for geometry pre-test when rendering the current image frame. For example, a first number of the second plurality of pieces of geometry may be assigned to the first GPU (e.g., GPU-B) for geometry test, and a second number of the second plurality of pieces of geometry may be assigned to the second GPU (e.g., GPU-A) for geometry test. The first number is greater than the second number (and if the time imbalance is large enough, no pieces may be assigned to GPU-A). In this way, GPU-B processes more pieces of geometry than GPU-A during geometry test.For example, timing diagram 1100B shows that GPU-B, which has more pieces of geometry assigned to it, takes longer to perform the geometry test than the other GPUs.

[0141] At 1160, the method includes performing a geometry pre-test on a second plurality of pieces of geometry in the current image frame to generate information regarding each piece of the second plurality of pieces of geometry and its relationship to each of the plurality of screen regions. The geometry pre-test is performed in each of the plurality of GPUs based on the allocation. The geometry pre-test is performed in the pre-test GP on the plurality of pieces of geometry of the image frame generated by the application to generate information regarding each piece of geometry and its relationship to each of the plurality of screen regions.

[0142] At 1170, the method includes rendering the multiple pieces of geometry during a rendering phase using the information generated for each of the second multiple pieces of geometry (e.g., including fully rendering the piece of geometry in a corresponding GPU or skipping rendering of that piece of geometry). The rendering typically occurs simultaneously in each GPU in an embodiment. In particular, the multiple pieces of geometry of the current image frame are rendered in each of the multiple GPUs using the information generated for each piece of geometry.

[0143] In other embodiments, the distribution of pieces of geometry to GPUs for generating information is dynamically adjusted. That is, the allocation of pieces of geometry for a current image frame to perform geometry pre-testing may be dynamically adjusted during rendering of the current image frame. For example, in the example of timing diagram 1100B, it may be determined that GPU-A was performing geometry pre-testing on its assigned pieces of geometry at a slower rate than expected. Thus, the pieces of geometry assigned to GPU-A for geometry pre-testing may be reallocated on the fly (e.g., reallocating the pieces of geometry from GPU-A to GPU-B), and GPU-B is now tasked with performing geometry pre-testing on the pieces of geometry during the frame period used to render the current image frame.

[0144] 12A-12B illustrate another approach for processing the rendering command buffer. One approach was previously described in connection with FIGs. 7A-7C, where the command buffer contains commands to perform a geometry pretest on an object (e.g., a piece of geometry), followed by commands to render the object (e.g., the piece of geometry). FIGs. 12A-12B illustrate a geometry pretest and rendering approach that uses a shader that can take either action depending on the GPU configuration.

[0145] 12A is a diagram illustrating the use of shaders configured to perform both geometry pre-testing and rendering of an image frame in two passes through a portion of command buffer 1200A, in accordance with one embodiment of the present disclosure. That is, a shader used to execute commands in command buffer 1200A may be configured to either perform geometry pre-testing when appropriately configured, or to perform rendering when appropriately configured.

[0146] As shown, the portion of the command buffer 1200A shown in FIG. 12A is executed twice, with different actions resulting from each execution. The first execution results in a geometry pretest, and the second execution results in rendering of geometry. This can be accomplished in various ways. For example, the portion of the command buffer shown in 1200A can be explicitly called twice as a subroutine. Different states (e.g., register settings or values ​​in RAM) are explicitly set to different values ​​before each call. Alternatively, the portion of the command buffer shown in 1200A can be implicitly executed twice, for example, by using special commands to mark the beginning and end of the portion and executing it twice, and implicitly setting different configurations (e.g., register settings) for the first and second executions of the portion of the command buffer. When a command in the portion of the command buffer 1200A (e.g., a command to set state or a command to execute a shader) is executed, the result of the command will be different (e.g., to perform a geometry pretest vs. to perform a render) based on the GPU state. That is, the commands in the command buffer 1200A may be configured for geometry pretest or for rendering. In particular, a portion of command buffer 1200A includes commands for configuring the state of one or more GPUs to execute commands from rendering command buffer 1200A and commands for executing a shader that performs either a geometry pretest or a rendering depending on the state. For example, commands 1210, 1212, 1214, and 1216 are each used to configure the state of one or more GPUs to execute a shader that performs either a geometry pretest or a rendering depending on the state. As shown, command 1210 configures the GPU state such that shader 0 may be executed via command 1211 to perform either a geometry pretest or a rendering. And command 1212 configures the GPU state such that shader 1 may be executed via command 1213 to perform either a geometry pretest or a rendering.Additionally, command 1214 configures the GPU state so that shader 2 may be executed via command 1215 to perform either geometry pretest or rendering. Finally, command 1216 configures the GPU state so that shader 3 may be executed via command 1217 to perform either geometry pretest or rendering.

[0147] In a first traversal 1291 through command buffer 1200A, corresponding shaders perform geometry pretests based on the GPU state that is set explicitly or implicitly as described above, as well as the GPU state configured by commands 1210, 1212, 1214, and 1216. For example, shader 0 is configured to perform a geometry pretest on object 0 (e.g., a piece of geometry) (e.g., based on the objects shown in FIG. 7B-1), shader 1 is configured to perform a geometry pretest on object 1, shader 2 is configured to perform a geometry pretest on object 2, and shader 3 is configured to perform a geometry pretest on object 3.

[0148] In one embodiment, commands may be skipped or interpreted differently based on the GPU state. For example, certain commands that set state (portions of 1210, 1212, 1214, and 1216) may be skipped based on the GPU state that is explicitly or implicitly set as described above. For example, when configuring shader 0 executed via command 1210, less GPU state needs to be configured for geometry pre-testing than when configuring for rendering geometry, it may be useful to skip setting unnecessary portions of the GPU state, since setting GPU state may have overhead. To provide another example, certain commands that set state (portions of 1210, 1212, 1214, and 1216) may be interpreted differently based on the GPU state that is explicitly or implicitly set as described above. For example, shader 0 executed via command 1210 may need to configure a different GPU state for geometry pre-testing than when configured for rendering geometry, or shader 0 executed via command 1210 may require different inputs for geometry pre-testing and rendering geometry.

[0149] In one embodiment, a shader configured for geometry pretesting does not allocate space in the position and parameter cache, as described above. In another embodiment, a single shader is used to perform either the pretest or the rendering. This can be done in a variety of ways, for example, via an external hardware state that the shader can check (e.g., as set explicitly or implicitly, as described above), or via inputs to the shader (e.g., as set by commands that are interpreted differently in the first and second passes through the command buffer).

[0150] In a second traversal 1292 through command buffer 1200A, based on the GPU state set explicitly or implicitly as described above, as well as the GPU state configured by commands 1210, 1212, 1214, and 1216, the corresponding shaders perform rendering of pieces of geometry for the corresponding image frame. For example, shader 0 is configured to perform rendering of object 0 (e.g., a piece of geometry) (e.g., based on the objects shown in FIG. 7B-1). Also, shader 1 is configured to perform rendering of object 1, shader 2 is configured to perform rendering of object 2, and shader 3 is configured to perform rendering of object 3.

[0151] 12B is a flow diagram 1200B illustrating a method for performing graphics processing including both pre-testing and rendering geometry of an image frame with the same set of shaders in two passes through a portion of a command buffer, according to one embodiment of the disclosure. As previously discussed, various architectures may include multiple GPUs working together to render a single image by performing multi-GPU rendering of geometry for an application, such as in one or more cloud gaming servers of a cloud gaming system, or in a standalone system (e.g., a personal computer or gaming console that includes a high-end graphics card with multiple GPUs).

[0152] In particular, at 1210, the method includes rendering graphics for the application with a plurality of GPUs, as described above. At 1220, the method includes dividing the responsibility for rendering geometry of the graphics among the plurality of GPUs based on a plurality of screen regions, each GPU having a corresponding division of the responsibility known to the plurality of GPUs. More specifically, as described above, each GPU has responsibility for rendering geometry in a corresponding set of screen regions of the plurality of screen regions. The corresponding set of screen regions includes one or more screen regions. In one embodiment, the screen regions are interleaved (e.g., when the display is divided into sets of screen regions for geometry pre-testing and rendering).

[0153] At 1230, the method includes allocating a plurality of pieces of geometry of the image frame to a plurality of GPUs for geometry testing. In particular, each of the plurality of GPUs is allocated a corresponding portion of the geometry associated with the image frame for purposes of performing the geometry testing. As previously mentioned, the allocation of the pieces of geometry may be distributed uniformly or non-uniformly. In an embodiment, each portion includes one or more pieces of geometry, or potentially no pieces of geometry at all.

[0154] At 1240, the method includes loading a first GPU state that configures one or more shaders to perform a geometry pretest. For example, depending on the GPU state, the corresponding shaders may be configured to perform different operations. Thus, the first GPU state configures the corresponding shaders to perform a geometry pretest. In the example of FIG. 12A, this can be set in various ways. For example, by setting a state externally, explicitly or implicitly, in a portion of the command buffer shown in 1200A, as described above. In particular, the GPU state may be set in various ways. For example, the CPU or GPU can set a value in random access memory (RAM). The GPU checks the value in RAM. In another example, the state may be internal to the GPU. For example, when the command buffer is called twice as a subroutine and the internal GPU state is different between the two subroutine calls. Alternatively, the command 1210 of FIG. 12A can be interpreted differently or skipped based on the state that is set explicitly or implicitly, as described above. Based on this first GPU state, shader 0 executed by command 1211 is configured to perform a geometry pre-test.

[0155] At 1250, the method includes performing a geometry pretest on a plurality of pieces of geometry at a plurality of GPUs to generate information regarding each piece of geometry and its relationship to each of a plurality of screen regions. As previously described, the geometry pretest may determine whether the piece of geometry overlaps with any screen regions (e.g., in a corresponding set) assigned to the corresponding GPU for object rendering. The geometry pretest is typically performed by the GPUs, in an embodiment, simultaneously on all geometry of a corresponding image frame so that each GPU knows which pieces of geometry to render and which pieces of geometry to skip. This completes a first traversal through the command buffer. A shader may be configured to perform each of the geometry pretest and / or rendering depending on the GPU state.

[0156] At 1260, the method includes loading a second GPU state that configures one or more shaders to perform rendering. As previously described, depending on the GPU state, corresponding shaders may be configured to perform different operations. Thus, the second GPU state configures the corresponding shader (the same shader previously used to perform the geometry pre-test) to perform rendering. In the example of FIG. 12A, based on this second GPU state, shader 0 executed by command 1211 is configured to perform rendering.

[0157] At 1270, the method includes using the generated information for each of the multiple pieces of geometry when rendering the multiple pieces of geometry in each of the multiple GPUs (e.g., to include fully rendering the piece of geometry in the corresponding GPU or skipping rendering of the piece of geometry). As previously described, the information may indicate whether the piece of geometry overlaps with any screen region (e.g., in the corresponding set) assigned to the corresponding GPU for object rendering. This information may be used to render each of the multiple pieces of geometry in each of the multiple GPUs, such that each GPU can efficiently render only those pieces of geometry that overlap with at least one screen (e.g., in the corresponding set) assigned to its corresponding GPU for object rendering. This completes a second traversal through the command buffer. A shader may be configured to perform each of the geometry pretests and / or rendering depending on the GPU state.

[0158] 13A-13B illustrate another approach for processing the rendering command buffer. An approach was previously described in connection with FIGS. 7A-7C, where a command buffer contains commands for geometry pre-testing of an object (e.g., a piece of geometry) followed by commands to render the object (e.g., a piece of geometry). Also described in FIGS. 12A-12B was another approach using a shader that can perform either operation depending on the GPU configuration. FIGS. 13A-13B illustrate a geometry test and render approach using a shader that can perform either geometry pre-testing or rendering, where the processes of geometry pre-testing and rendering are interleaved for different sets of pieces of geometry, according to an embodiment of the present disclosure.

[0159] In particular, FIG. 13A illustrates the use of shaders configured to perform both geometry pretests and rendering. According to one embodiment of the present disclosure, geometry pretests and renderings performed on different sets of pieces of geometry are interleaved using separate portions of corresponding command buffers 1300A. That is, rather than running a portion of command buffer 1300A from start to finish, command buffer 1300A is dynamically configured and executed such that geometry pretests and renderings are interleaved on different sets of pieces of geometry. For example, in a command buffer, some shaders (e.g., executed via commands 1311 and 1313) are configured to perform geometry pretests on a first set of pieces of geometry. After performing the geometry tests, these same shaders (e.g., executed by commands 1311 and 1313) are then configured to perform rendering. After performing renderings on the first set of pieces of geometry, other shaders in the command buffer (e.g., executed via commands 1315 and 1317) are configured to perform geometry pretests on a second set of pieces of geometry. After performing the geometry pre-tests, these same shaders (e.g., executed via commands 1315 and 1317) are then configured to render using these commands on a second set of pieces of geometry. An advantage of this approach is that it allows for imbalances between GPUs to be dynamically addressed, for example, by using asymmetric interleaving of geometry tests throughout the rendering. An example of asymmetric interleaving of geometry tests was previously introduced in distribution 102 of FIG. 10.

[0160] Since the interleaving of geometry pretest and rendering is done dynamically, the configuration of the GPU (e.g., via register settings or values ​​in RAM) is done implicitly. That is, aspects of the GPU configuration occur outside of the command buffer. For example, a GPU register may be set to 0 (indicating that geometry pretest should be done) or 1 (indicating that rendering should be done). The traversal of the command buffer interleaving and the setting of this register may be controlled by the GPU based on the number of objects being processed, primitives being processed, imbalance between GPUs, etc. Alternatively, a value in RAM may be used. As a result of this external configuration (meaning setting externally to the command buffer), when a command in a portion of the command buffer 1300A (e.g., a command to set state or a command to execute a shader) is executed, the result of the command will be different (e.g., to do geometry pretest vs. to do rendering) based on the GPU state. That is, a command in the command buffer 1300A may be configured for geometry pretest 1391 or rendering 1392. In particular, a portion of command buffer 1300A includes commands for configuring the state of one or more GPUs to execute commands from rendering command buffer 1300A and commands for executing shaders that perform either geometry pretests or rendering depending on the state. For example, commands 1310, 1312, 1314, and 1316 are each used to configure the state of the GPU to execute shaders that perform either geometry pretests or rendering depending on the state. As shown, command buffer 1310 configures the GPU state such that shader 0 may be executed via command 1311 to perform either geometry pretests or rendering of object 0. And command buffer 1312 configures the GPU state such that shader 1 may be executed via command 1313 to perform either geometry pretests or rendering of object 1.Also, command buffer 1314 configures the GPU state so that shader 2 may be executed via command 1315 to either perform geometry pre-testing or rendering of object 2. Furthermore, command buffer 1316 configures the GPU state so that shader 3 may be executed via command 1317 to either perform geometry pre-testing or rendering of object 3.

[0161] Geometry pretests and rendering may be interleaved for different sets of pieces of geometry. For purposes of example only, command buffer 1300A may be configured to first perform geometry pretests and rendering for objects 0 and 1, and then command buffer 1300A is configured to perform geometry pretests and rendering for objects 2 and 3. Of course, different numbers of pieces of geometry may be interleaved in different sections. For example, section 1 illustrates a first traversal through command buffer 1300A. Based on the GPU state implicitly set as described above and the GPU state configured by commands 1310 and 1312, the corresponding shaders perform geometry pretests. For example, shader 0 is configured to perform geometry pretests for object 0 (e.g., a piece of geometry) (e.g., based on the objects shown in FIG. 7B-1), and shader 1 is configured to perform geometry pretests for object 1. Section 2 illustrates a second traversal through command buffer 1300A. Based on the GPU state that is implicitly set as described above, and the GPU state configured by commands 1310 and 1312, the corresponding shaders perform rendering. For example, shader 0 is configured to next perform rendering of object 0, shader 1 is configured to next perform rendering of object 1, etc.

[0162] FIG. 13A illustrates interleaving the execution of geometry pre-tests and rendering for different sets of pieces of geometry. In particular, section 3 illustrates a third partial traversal through command buffer 1300A. Based on the GPU state implicitly set as described above and the GPU state configured by commands 1314 and 1316, the corresponding shaders perform geometry pre-tests. For example, shader 2 (executed via command 1315) performs a geometry test for object 2 (e.g., a piece of geometry) (e.g., based on the object shown in FIG. 7B-1), and shader 3 (executed via command 1317) performs a geometry test for object 3. Section 4 illustrates a fourth partial traversal through command buffer 1300A. Based on the GPU state implicitly set as described above and the GPU state configured by commands 1314 and 1316, the corresponding shaders perform rendering. For example, shader 2 (executed via command 1315) performs a rendering for object 2, and shader 3 (executed via command 1317) performs a rendering for object 3.

[0163] Note that hardware contexts are preserved or saved (or saved) and read (or restored). For example, the geometry pre-test GPU context at the end of section 1 is needed at the beginning of section 3 to perform the geometry pre-tests, and the rendering GPU context at the end of section 2 is needed for the beginning of section 4 to perform the rendering.

[0164] In one embodiment, commands may be skipped or interpreted differently based on the GPU state. For example, certain commands that set state (portions 1310, 1312, 1314, and 1316) may be skipped based on the GPU state that is implicitly set as described above. For example, when configuring shader 0 executed via command 1310, less GPU state needs to be configured for geometry testing than when configuring for rendering geometry, it may be useful to skip setting unnecessary portions of the GPU state, since setting GPU state may have overhead. To provide another example, certain commands that set state (portions 1310, 1312, 1314, and 1316) may be interpreted differently based on the GPU state that is implicitly set as described above. For example, shader 0 executed via command 1310 may need to configure a different GPU state for geometry pre-testing than when configured for rendering geometry, or shader 0 executed via command 1310 may require different inputs for geometry testing versus rendering geometry.

[0165] In one embodiment, a shader configured for geometry pretesting does not allocate space in the position and parameter cache, as described above. In another embodiment, a single shader is used to perform either the pretest or the rendering. This can be done in a variety of ways, for example, via an external hardware state that the shader can check (e.g., as implicitly set as described above), or via inputs to the shader (e.g., as set by commands that are interpreted differently in the first and second passes through the command buffer).

[0166] 13B is a flow diagram illustrating a method for performing graphics processing that includes interleaving geometry pre-testing and rendering of an image frame for different sets of pieces of geometry with separate portions of corresponding command buffers, according to one embodiment of the disclosure. As previously discussed, various architectures may include multi-GPU rendering of geometry for an application, with multiple GPUs working together to render a single image, such as in one or more cloud gaming servers of a cloud gaming system, or in a standalone system (e.g., a personal computer or gaming console that includes a high-end graphics card with multiple GPUs).

[0167] In particular, at 1310, the method includes rendering graphics for the application with a plurality of GPUs, as described above. At 1320, the method includes dividing the responsibility for rendering geometry of the graphics among the plurality of GPUs based on a plurality of screen regions, each GPU having a corresponding division of the responsibility known to the plurality of GPUs. More specifically, as described above, each GPU has a responsibility for rendering geometry in a corresponding set of screen regions of the plurality of screen regions. The corresponding set of screen regions includes one or more screen regions. In one embodiment, the screen regions are interleaved (e.g., when a display is divided into sets of screen regions for geometry pre-testing and rendering).

[0168] At 1330, the method includes allocating a plurality of pieces of geometry of the image frame to a plurality of GPUs for geometry testing. In particular, each of the plurality of GPUs is allocated a corresponding portion of the geometry associated with the image frame for purposes of performing the geometry testing. As previously mentioned, the allocation of the pieces of geometry may be distributed uniformly or non-uniformly. Each portion may include one or more pieces of geometry, or potentially no pieces of geometry at all.

[0169] At 1340, the method includes interleaving the first set of shaders with the second set of shaders in the command buffer. The shaders are configured to perform both geometry pretest and rendering. In particular, the first set of shaders are configured to perform geometry pretest and rendering on the first set of pieces of geometry. Thereafter, the second set of shaders are configured to perform geometry pretest and rendering on the second set of pieces of geometry. As previously described, the geometry pretest generates corresponding information regarding each piece of geometry in the first set or the second set and its relationship to each of the multiple screen regions. The corresponding information is used by the multiple GPUs to render each piece of geometry in the first set or the second set. As previously described, the GPU state may be set in various ways to perform either the geometry pretest or the rendering. For example, the CPU or the GPU can set a value in a random access memory (RAM). The GPU checks the value in the RAM. In another example, the state may be internal to the GPU. For example, when you call a command buffer twice as a subroutine and the internal GPU state is different between the two subroutine calls.

[0170] The interleaving process is further described. In particular, as described above, the first set of shaders of the command buffer is configured to perform a geometry pretest on the first set of pieces of geometry. The geometry pretest is performed on the first set of pieces of geometry on the multiple GPUs to generate first information regarding each piece of geometry in the first set and its relationship to each of the multiple screen regions. And, as described above, the first set of shaders is configured to perform rendering of the first set of pieces of geometry. The first information is then used when rendering the multiple pieces of geometry on each of the multiple GPUs (e.g., to include fully rendering the first set of pieces of geometry on the corresponding GPU or skipping rendering of the first set of pieces of geometry). As described above, the information indicates which pieces of geometry overlap with screen regions allocated to the corresponding GPU for object rendering. For example, the information may be used to skip rendering of the pieces of geometry on a GPU when the information indicates that the pieces of geometry do not overlap with any screen regions (e.g., in the corresponding set) allocated to the GPU for object rendering.

[0171] The second set of shaders is then used for geometry testing and rendering of the second set of pieces of geometry. In particular, the second set of shaders of the command buffer is configured to perform geometry pre-tests on the second set of pieces of geometry, as described above. The geometry tests are then performed on the second set of pieces of geometry on the multiple GPUs to generate second information regarding each piece of geometry in the second set and its relationship to each of the multiple screen regions. The second set of shaders is then configured to perform rendering of the second set of pieces of geometry, as described above. The rendering of the second set of pieces of geometry is then performed on each of the multiple GPUs using the second information. As described above, the information indicates which pieces of geometry overlap with screen regions (e.g., of a corresponding set) allocated to the corresponding GPU for object rendering.

[0172] Although the above describes multiple GPUs processing geometry in lockstep (i.e., multiple GPUs performing geometry pretests and multiple GPUs performing rendering), in some embodiments, the GPUs are not explicitly synchronized with each other. For example, one GPU may be rendering a first set of pieces of geometry while a second GPU is performing geometry pretests on a second set of pieces of geometry.

[0173] FIG. 14 illustrates components of an example device 1400 that can be used to perform aspects of various embodiments of the present disclosure. For example, FIG. 14 illustrates an exemplary hardware system suitable for multi-GPU rendering of geometry for an application by pre-testing the geometry for screen regions (which may be interleaved) before rendering objects for an image frame, according to embodiments of the present disclosure. The device 1400 illustrated in this block diagram can incorporate or be a personal computer, server computer, gaming console, mobile device, or other digital device (each suitable for performing embodiments of the present invention). The device 1400 includes a central processing unit (CPU) 1402 for executing software applications and optionally an operating system. The CPU 1402 can be composed of one or more homogeneous or heterogeneous processing cores.

[0174] According to various embodiments, CPU 1402 is one or more general-purpose microprocessors having one or more processing cores. Further embodiments can be implemented using one or more CPUs with a microprocessor architecture specifically adapted for highly parallel, computationally intensive applications (e.g., media and interactive entertainment applications) for applications configured to perform graphics processing during game execution.

[0175] The memory 1404 stores applications and data used by the CPU 1402 and the GPU 1416. The storage 1406 is a non-volatile storage and other computer-readable medium for applications and data, and may include fixed disk drives, removable disk drives, flash memory devices, and CD-ROM, DVD-ROM, Blu-ray, HD-DVD, or other optical storage devices, as well as signal transmission and storage media. The user input devices 1408 communicate user input from one or more users to the device 1400. Examples may include a keyboard, a mouse, a joystick, a touchpad, a touch screen, a still or video recorder / camera, and / or a microphone. The network interface 1409 enables the device 1400 to communicate with other computer systems over an electronic communications network. The network interface 1409 may include wired or wireless communications over local and wide area networks (e.g., the Internet). The audio processor 1412 is adapted to generate analog or digital audio output from instructions and / or data provided by the CPU 1402, the memory 1404, and / or the storage device 1406. The components of the device 1400 (e.g., the CPU 1402, the graphics subsystem, e.g., GPU 1416, the memory 1404, the data storage device 1406, the user input devices 1408, the network interface 1409, and the audio processor 1412) are coupled via one or more data buses 1422.

[0176] A graphics subsystem 1414 is further coupled to the data bus 1422 and the components of the device 1400. The graphics subsystem 1414 includes at least one graphics processing unit (GPU) 1416 and a graphics memory 1418. The graphics memory 1418 includes a display memory (e.g., a frame buffer) used to store pixel data for each pixel of an output image. The graphics memory 1418 may be integrated in the same device as the GPU 1416, connected to the GPU 1416 as a separate device, and / or implemented within the memory 1404. Pixel data may be provided to the graphics memory 1418 directly from the CPU 1402. Alternatively, the CPU 1402 provides the GPU 1416 with data and / or instructions that define a desired output image. From the desired output image, the GPU 1416 generates pixel data for one or more output images. The data and / or instructions that define the desired output image may be stored in the memory 1404 and / or the graphics memory 1418. In one embodiment, GPU 1416 includes 3D rendering capabilities for generating pixel data for output images from instructions and data that define geometry, lighting, shading, texture, motion, and / or camera parameters for a scene. GPU 1416 may further include one or more programmable execution units capable of executing shader programs.

[0177] Graphics subsystem 1414 periodically outputs pixel data from graphics memory 1418 for an image to be displayed on display device 1410 or projected by a projection system (not shown). Display device 1410 can be any device capable of displaying visual information in response to a signal from device 1400, such as CRT, LCD, plasma, and OLED displays. Device 1400 can provide analog or digital signals to display device 1410, for example.

[0178] Other embodiments for optimizing the graphics subsystem 1414 may include multi-GPU rendering of geometry for an application by pre-testing the geometry against screen space (which may be interleaved) before rendering objects for an image frame. The graphics subsystem 1414 may be configured as one or more processing devices.

[0179] For example, in one embodiment, graphics subsystem 1414 may be configured to perform multi-GPU rendering of geometry for an application. Multiple graphics subsystems may be running the graphics and / or rendering pipeline for a single application. That is, graphics subsystem 1414 includes multiple GPUs used to render one or more individual images of an image or sequence of images when executing the application.

[0180] In another embodiment, the graphics subsystem 1414 includes multiple GPU devices, which are coupled to perform graphics processing for a single application running on a corresponding CPU. For example, multiple GPUs can perform multi-GPU rendering of geometry for an application by pre-testing the geometry against a screen region (which may be interleaved) before rendering objects for an image frame. In another example, multiple GPUs can perform alternating frame rendering, where GPU1 renders a first frame, GPU2 renders a second frame, and so on in successive frame cycles until the last GPU is reached. The first GPU then renders the next video frame (e.g., if there are only two GPUs, GPU1 renders the third frame). That is, the GPUs rotate when rendering frames. Rendering operations can overlap. GPU2 may start rendering the second frame before GPU1 finishes rendering the first frame. In another embodiment, multiple GPU devices can be assigned different shader operations in the rendering and / or graphics pipeline. The master GPU is doing the main rendering and compositing. For example, in a group containing three GPUs, master GPU1 may perform the main rendering (e.g., first shader operations) and compositing of the output from slave GPU2 and slave GPU3. Slave GPU2 may perform second shader (e.g., fluid effects such as rivers) operations, and slave GPU3 may perform third shader (e.g., particle smoke) operations. Master GPU1 composites the results from each of GPU1, GPU2, and GPU3. In this manner, different GPUs may be assigned to perform different shader operations (e.g., flag waving, wind, smoke, fire, etc.) to render a video frame.In yet other embodiments, each of the three GPUs may be assigned to a different object and / or portion of the scene corresponding to a video frame. In the above embodiments and implementations, these operations may occur in the same frame cycle (concurrent parallel) or in different frame cycles (sequential parallel).

[0181] Accordingly, this disclosure describes methods and systems configured for multi-GPU rendering of geometry for an application by pre-testing the geometry against a screen region (which may be interleaved) before rendering an object for an image frame or for each of one or more image frames in a sequence of image frames when the application is executed.

[0182] It is understood that the various embodiments defined herein may be combined or assembled into specific implementations using the various features disclosed herein. Thus, the examples provided are merely some possible examples and are not limited to the various implementations possible by combining various elements to define further implementations. In some examples, some implementations may include fewer elements without departing from the spirit of the disclosed implementations or equivalent implementations.

[0183] Embodiments of the present disclosure may be practiced by a variety of computer system configurations (e.g., hand-held devices, microprocessor systems, microprocessor-based or programmable consumer electronics, minicomputers, mainframe computers, etc.) and may also be practiced in distributed computing environments where tasks are performed by remote processing devices that are linked through a wire-based or wireless network.

[0184] With the foregoing embodiments in mind, it will be appreciated that embodiments of the present disclosure may employ various computer-implemented operations involving data stored in computer systems. These operations are those requiring physical manipulations of physical quantities. Any of the operations described herein that form part of the embodiments of the present disclosure are useful machine operations. Embodiments of the present disclosure also relate to devices or apparatus for performing these operations. The apparatus may be specially constructed for the required purposes, or the apparatus may be a general-purpose computer selectively activated or configured by a computer program stored in the computer. In particular, various general-purpose machines may be employed with computer programs written in accordance with the teachings herein, or it may be more convenient to construct more specialized apparatus to perform the required operations.

[0185] The present disclosure can also be embodied as computer readable code on a computer readable medium. The computer readable medium can be any data storage device that can store data. The data can then be read by a computer system. Examples of the computer readable medium include hard drives, network attached storage (NAS), read only memory, random access memory, CD-ROM, CD-R, CD-RW, magnetic tape, and other optical and non-optical data storage devices. The computer readable medium can include computer readable tangible media distributed over network-coupled computer systems such that the computer readable code is stored and executed in a distributed manner.

[0186] Although the operations of the method have been described in a particular order, it will be appreciated that other housekeeping operations may be performed between operations, or operations may be coordinated to occur at slightly different times, or may be distributed in a system that allows processing operations at various intervals associated with the processing, so long as the processing of the overlay operation is performed in the desired manner.

[0187] Although the foregoing disclosure has been described in some detail for clarity of understanding, it will be apparent that certain modifications and variations can be practiced within the scope of the appended claims. Thus, the present embodiments are to be considered as illustrative and not restrictive, and the embodiments of the present disclosure should not be limited to the details given herein, but may be modified within the scope of the appended claims and their equivalents.

Claims

1. 1. A method for performing graphics processing, comprising: Rendering graphics for an application using multiple graphics processing units (GPUs); dividing a responsibility for the rendering of the graphics geometry among the plurality of GPUs based on a plurality of screen regions, each GPU having a corresponding division of the responsibility known to the plurality of GPUs, the screen regions in the plurality of screen regions being interleaved; assigning pieces of geometry of the image frames generated by the application to the GPU for geometry pre-testing; performing the geometry pre-test on the GPU to generate information regarding the piece of geometry and its relationship to each of the plurality of screen regions; Using the information in each of the multiple GPUs when rendering the image frame.

2. 2. The method of claim 1 , further comprising: skipping rendering of the piece of geometry on a rendering GPU when the information indicates that the piece of geometry does not overlap with any screen area allocated to the rendering GPU for object rendering, the rendering GPU being one of the multiple GPUs.

3. Further, providing the information as a hint to a rendering GPU, the rendering GPU being one of the plurality of GPUs; the information is taken into account by the rendering GPU when received before rendering of the piece of geometry begins at the rendering GPU; The method of claim 1 , wherein the piece of geometry is fully rendered in the rendering GPU when the information is received after rendering of a first piece of geometry has begun.

4. further comprising: allocating a plurality of pieces of geometry of the image frame to the plurality of GPUs for geometry pre-testing; The method of claim 1 , further comprising allocating pieces of geometry within the plurality of pieces of geometry uniformly or non-uniformly across the plurality of GPUs.

5. The method of claim 4 , further comprising allocating the multiple pieces of geometry such that consecutive pieces of geometry are processed by different GPUs.

6. 6. The method of claim 5, wherein a first GPU performs geometry pre-testing on more pieces of geometry than a second GPU, or the first GPU performs geometry pre-testing while the second GPU does not perform geometry pre-testing at all.

7. The method of claim 1 , wherein the multiple screen regions are configured to reduce imbalances in rendering times between the multiple GPUs.

8. The method of claim 1 , wherein each of the plurality of screen regions is non-uniform in size.

9. The method of claim 1 , wherein the plurality of screen regions changes dynamically.

10. The method of claim 1 , wherein the piece of geometry corresponds to geometry that a draw call uses or produces.

11. The method of claim 1 , further comprising: subdividing geometry used or generated by draw calls of the application into multiple pieces of geometry including the piece of geometry for which the GPU generates information.

12. The method of claim 1 , wherein the pieces of geometry are individual primitives.

13. The method of claim 1 , wherein the information about the piece of geometry includes a vertex count or a primitive count.

14. The method of claim 1 , wherein the information about the piece of geometry includes a particular set of primitives to render or a particular set of vertices to render.

15. Furthermore, using a common rendering command buffer for the plurality of GPUs, The method of claim 1 , further comprising restricting execution of commands in the common rendering command buffer to one or more of the multiple GPUs.

16. The method of claim 1 , wherein the information may or may not be generated depending on characteristics of the piece of geometry.

17. The method of claim 1 , further comprising generating said information using a scan converter at a rasterization stage.

18. The method of claim 1 , further comprising generating said information using one or more shaders in a geometry processing stage.

19. The method of claim 18 , wherein the one or more shaders use one or more dedicated instructions to accelerate the generation of the information.

20. The method of claim 18 , wherein the one or more shaders do not perform allocations to a position cache or a parameter cache.

21. further comprising: dividing pieces of geometry among the GPUs for geometry pre-testing; The method of claim 1 , wherein successive pieces of geometry are processed by different GPUs.

22. 22. The method of claim 21, further comprising dynamically adjusting the divisions of the pieces of geometry based on performance of each of the GPUs during geometry pre-testing.

23. The method of claim 1 , wherein one or more of the multiple GPUs are part of a larger GPU configured as multiple virtual GPUs.

24. 1. A computer system comprising: A processor is included. a memory coupled to the processor having instructions stored thereon that, when executed by the computer system, cause the computer system to perform a method for executing a graphics pipeline; The method comprises: Rendering graphics for an application using multiple graphics processing units (GPUs); dividing a responsibility for the rendering of the graphics geometry among the plurality of GPUs based on a plurality of screen regions, each GPU having a corresponding division of the responsibility known to the plurality of GPUs, the screen regions in the plurality of screen regions being interleaved; assigning pieces of geometry of the image frames generated by the application to the GPU for geometry pre-testing; performing the geometry pre-test on the GPU to generate information regarding the piece of geometry and its relationship to each of the plurality of screen regions; A computer system that uses the information in each of the multiple GPUs when rendering the image frame.

25. The computer system further comprises:

25. The computer system of claim 24, further comprising: skipping rendering of the piece of geometry on a rendering GPU when the information indicates that the piece of geometry does not overlap with any screen area allocated to the rendering GPU for object rendering, the rendering GPU being one of the multiple GPUs.

26. The method further comprises: providing said information as a hint to a rendering GPU, said rendering GPU being one of said plurality of GPUs; the information is taken into account by the rendering GPU when received before rendering of the piece of geometry begins at the rendering GPU; 25. The computer system of claim 24, wherein the piece of geometry is completely rendered in the rendering GPU when the information is received after rendering of a first piece of geometry has begun.

27. 1. A method for performing graphics processing, comprising: Rendering graphics for an application using multiple graphics processing units (GPUs); dividing a responsibility for the rendering of the graphics geometry among the plurality of GPUs based on a plurality of screen regions, each GPU having a corresponding division of the responsibility known to the plurality of GPUs; Rendering a first plurality of pieces of geometry on the plurality of GPUs during a rendering phase of a previous image frame generated by an application; generating statistics for the rendering of the previous image frame; assigning a second plurality of pieces of geometry of a current image frame generated by the application to the plurality of GPUs for geometry testing based on the statistics; performing a geometry test on the second plurality of pieces of geometry in the current image frame to generate information regarding each piece of the second plurality of pieces of geometry and its relationship to each of the plurality of screen regions, the geometry test being performed on each of the plurality of GPUs based on the allocation; The method further comprising: using the information generated for each of the second plurality of pieces of geometry when rendering the geometry on the multiple GPUs.

28. Further, providing the information as a hint to a rendering GPU, the rendering GPU being one of the plurality of GPUs; the information is taken into account by the rendering GPU when received prior to rendering of a piece of geometry in the second plurality of pieces of geometry; 28. The method of claim 27, wherein the piece of geometry in the second plurality of pieces of geometry is fully rendered in the rendering GPU when the information is received after rendering of the piece of geometry in the second plurality of pieces of geometry has begun.

29. 28. The method of claim 27, further comprising allocating pieces of geometry in the second plurality of pieces of geometry uniformly or non-uniformly to the multiple GPUs.

30. further determining that a first GPU has finished rendering the first plurality of pieces of geometry before a second GPU has finished rendering the first plurality of pieces of geometry, the first GPU rendering one or more pieces of the first plurality of pieces of geometry that overlap any screen area assigned to the first GPU for object rendering, and the second GPU rendering one or more pieces of the first plurality of pieces of geometry that overlap any screen area assigned to the second GPU for object rendering; assigning a first number of the second plurality of pieces of geometry to the first GPU for geometry testing; assigning a second number of the second plurality of pieces of geometry to the second GPU for geometry testing; 28. The method of claim 27, wherein the first number is greater than the second number.

31. 31. The method of claim 30, wherein the second number is zero.

32. When using the information:

28. The method of claim 27, further comprising: skipping rendering of a piece of geometry in the second plurality of pieces of geometry on the rendering GPU if the information indicates that the piece of geometry does not overlap with any screen area allocated to a rendering GPU for object rendering, the rendering GPU being one of the plurality of GPUs.

33. splitting the second plurality of pieces of geometry among the plurality of GPUs for geometry pre-testing; 28. The method of claim 27, wherein successive pieces of geometry are processed by different GPUs.

34. 34. The method of claim 33, further comprising dynamically adjusting the divisions of the second plurality of pieces of geometry based on performance of each of the plurality of GPUs during geometry pre-testing.

35. 34. The method of claim 33, wherein the first GPU processes more pieces of geometry during geometry pre-testing than the second GPU.

36. 28. The method of claim 27, wherein pieces of geometry in the second plurality of pieces of geometry correspond to geometry that a draw call uses or generates.

37. 30. The method of claim 27, wherein one or more of the multiple GPUs are part of a larger GPU configured as multiple virtual GPUs.

38. A non-transitory computer readable medium for carrying out a method, comprising: The computer readable medium comprises: having program instructions for rendering graphics for an application using a plurality of graphics processing units (GPUs); program instructions for dividing a responsibility for the rendering of the graphics geometry among the plurality of GPUs based on a plurality of screen regions, each GPU having a corresponding division of the responsibility known to the plurality of GPUs; program instructions for rendering a first plurality of pieces of geometry on the plurality of GPUs during a rendering phase of a previous image frame generated by an application; generating statistics for the rendering of the previous image frame; and program instructions for allocating a second plurality of pieces of geometry of a current image frame generated by the application to the plurality of GPUs for geometry testing based on the statistics; performing a geometry test on the second plurality of pieces of geometry in the current image frame to generate information regarding each piece of the second plurality of pieces of geometry and its relationship to each of the plurality of screen regions, the geometry test being performed on each of the plurality of GPUs based on the assignment; A non-transitory computer-readable medium having program instructions for using the information generated for each of the second plurality of pieces of geometry when rendering the geometry on the multiple GPUs.

39. and further comprising program instructions for providing the information as a hint to a rendering GPU, the rendering GPU being one of the plurality of GPUs; the information is taken into account by the rendering GPU when received prior to rendering of a piece of geometry in the second plurality of pieces of geometry; 40. The non-transitory computer-readable medium of claim 38, wherein when the information is received after rendering of the piece of geometry in the second plurality of pieces of geometry has begun, the piece of geometry in the second plurality of pieces of geometry is fully rendered in the rendering GPU.

40. In the method, 40. The non-transitory computer-readable medium of claim 38, further comprising: allocating pieces of geometry in the second plurality of pieces of geometry uniformly or non-uniformly to the multiple GPUs.

41. the programming instructions further comprising: determining that a first GPU has finished rendering the first plurality of pieces of geometry before a second GPU has finished rendering the first plurality of pieces of geometry, the first GPU rendering one or more pieces of the first plurality of pieces of geometry that overlap any screen area assigned to the first GPU for object rendering, and the second GPU rendering one or more pieces of the first plurality of pieces of geometry that overlap any screen area assigned to the second GPU for object rendering; program instructions for allocating a first number of the second plurality of pieces of geometry to the first GPU for geometry testing; program instructions for allocating a second number of the second plurality of pieces of geometry to the second GPU for geometry testing; 40. The non-transitory computer-readable medium of claim 38, wherein the first number is greater than the second number.

42. The program instructions for using the information include:

39. The non-transitory computer-readable medium of claim 38, further comprising program instructions for skipping rendering of a piece of geometry in the second plurality of pieces of geometry in the rendering GPU when the information indicates that the piece of geometry does not overlap with any screen area allocated to a rendering GPU for object rendering, the rendering GPU being one of the plurality of GPUs.

43. and further comprising program instructions for dividing the second plurality of pieces of geometry among the plurality of GPUs for geometry pre-testing; 40. The non-transitory computer-readable medium of claim 38, wherein consecutive pieces of geometry are processed by different GPUs.

44. 44. The non-transitory computer readable medium of claim 43, further comprising program instructions for dynamically adjusting the divisions of the second plurality of pieces of geometry based on performance of each of the plurality of GPUs during geometry pre-testing.

45. 1. A computer system comprising: A processor is included. a memory coupled to the processor having instructions stored thereon that, when executed by the computer system, cause the computer system to perform a method for graphics processing, the method comprising: Rendering graphics for an application using multiple graphics processing units (GPUs); dividing a responsibility for the rendering of the graphics geometry among the plurality of GPUs based on a plurality of screen regions, each GPU having a corresponding division of the responsibility known to the plurality of GPUs; Rendering a first plurality of pieces of geometry on the plurality of GPUs during a rendering phase of a previous image frame generated by an application; generating statistics for the rendering of the previous image frame; assigning a second plurality of pieces of geometry of a current image frame generated by the application to the plurality of GPUs for geometry testing based on the statistics; performing a geometry test on the second plurality of pieces of geometry in the current image frame to generate information regarding each piece of the second plurality of pieces of geometry and its relationship to each of the plurality of screen regions, the geometry test being performed on each of the plurality of GPUs based on the allocation; The computer system uses the information generated for each of the second plurality of pieces of geometry when rendering the geometry on the multiple GPUs.

46. The method further comprises: providing said information as a hint to a rendering GPU, said rendering GPU being one of said plurality of GPUs; the information is taken into account by the rendering GPU when received prior to rendering of a piece of geometry in the second plurality of pieces of geometry; 46. ​​The computer system of claim 45, wherein when the information is received after rendering of the piece of geometry in the second plurality of pieces of geometry has begun, the piece of geometry in the second plurality of pieces of geometry is completely rendered in the rendering GPU.

47. In the method, 46. ​​The computer system of claim 45, wherein pieces of geometry in the second plurality of pieces of geometry are allocated uniformly or non-uniformly to the multiple GPUs.

48. The method further comprises: determining that a first GPU has finished rendering the first plurality of pieces of geometry before a second GPU has finished rendering the first plurality of pieces of geometry, the first GPU rendering one or more pieces of the first plurality of pieces of geometry that overlap any screen area assigned to the first GPU for object rendering, and the second GPU rendering one or more pieces of the first plurality of pieces of geometry that overlap any screen area assigned to the second GPU for object rendering; assigning a first number of the second plurality of pieces of geometry to the first GPU for geometry testing; assigning a second number of the second plurality of pieces of geometry to the second GPU for geometry testing; 46. ​​The computer system of claim 45, wherein the first number is greater than the second number.

49. In the method, when the information is used, 46. ​​The computer system of claim 45, further comprising: skipping rendering of a piece of geometry in the second plurality of pieces of geometry on the rendering GPU if the information indicates that the piece of geometry does not overlap with any screen area allocated to a rendering GPU for object rendering, the rendering GPU being one of the plurality of GPUs.

50. The method further comprises: splitting the second plurality of pieces of geometry among the plurality of GPUs for geometry pre-testing; 46. ​​The computer system of claim 45, wherein successive pieces of geometry are processed by different GPUs.

51. The method further comprises:

51. The computer system of claim 50, further comprising: dynamically adjusting the divisions of the second plurality of pieces of geometry based on performance of each of the plurality of GPUs during geometry pre-testing.

52. 1. A method for performing graphics processing, comprising: Rendering graphics for an application using multiple graphics processing units (GPUs); dividing a responsibility for the rendering of the graphics geometry among the plurality of GPUs based on a plurality of screen regions, each GPU having a corresponding division of the responsibility known to the plurality of GPUs; assigning pieces of geometry of an image frame to the plurality of GPUs for geometry testing; setting a first GPU state that configures one or more shaders to perform the geometry test; performing geometry tests on the pieces of geometry on the GPUs to generate information regarding each piece of geometry and its relationship to each of the screen regions; setting a second GPU state that configures the one or more shaders to perform rendering; using the information generated for each of the multiple pieces of geometry when rendering the multiple pieces of geometry on the multiple GPUs.

53. When using the information:

53. The method of claim 52, further comprising skipping rendering of the piece of geometry on a rendering GPU if the information indicates that the piece of geometry does not overlap with any screen area allocated to the rendering GPU for object rendering, the rendering GPU being one of the multiple GPUs.

54. Further, providing the information as a hint to a rendering GPU, the rendering GPU being one of the plurality of GPUs; the information is taken into account by the rendering GPU when received prior to rendering of the piece of geometry; 53. The method of claim 52, wherein the piece of geometry is fully rendered in the rendering GPU when the information is received after rendering of the piece of geometry has begun.

55. allocating pieces of geometry within the plurality of pieces of geometry evenly or non-uniformly across the plurality of GPUs; 53. The method of claim 52, further comprising allocating the multiple pieces of geometry such that consecutive pieces of geometry are processed by different GPUs.

56. 53. The method of claim 52, wherein a first GPU performs geometry pre-testing on more pieces of geometry than a second GPU, or the first GPU performs geometry pre-testing while the second GPU does not perform geometry pre-testing at all.

57. 53. The method of claim 52, wherein, depending on the first GPU state or the second GPU state, when executing commands in a rendering command buffer, the commands cause output of the information about the piece of geometry or cause output of vertex position and parameter information for later use in one or more rendering stages.

58. 58. The method of claim 57, wherein the command affecting the GPU configuration is interpreted in a number of ways depending on the first GPU state or the second GPU state.

59. In the command buffer, generating first information for a first piece of geometry and its relationship to the plurality of screen regions and rendering the first piece of geometry; 53. The method of claim 52, further comprising interleaving the generation of second information for a second piece of geometry and its relationship to the plurality of screen regions and the rendering of the second piece of geometry.

60. 53. The method of claim 52, wherein the hardware context is maintained or recorded and read.

61. 53. The method of claim 52, wherein one or more of the multiple GPUs are part of a larger GPU configured as multiple virtual GPUs.

62. 1. A method for performing graphics processing, comprising: Rendering graphics for an application using multiple graphics processing units (GPUs); dividing a responsibility for the rendering of the graphics geometry among the plurality of GPUs based on a plurality of screen regions, each GPU having a corresponding division of the responsibility known to the plurality of GPUs; assigning pieces of geometry of an image frame to the plurality of GPUs for geometry testing; interleaving a first set of shaders that perform geometry tests and rendering on the first set of pieces of geometry with a second set of shaders that perform geometry tests and rendering on the second set of pieces of geometry; the geometry test generating corresponding information regarding each piece of geometry in the first set or the second set and its relationship to each of the plurality of screen regions; The method, wherein the corresponding information is used by the multiple GPUs when the multiple GPUs render the geometry.

63. skipping rendering of the piece of geometry in the first set at the rendering GPU when the information indicates that the piece of geometry in the first set does not overlap with any screen area allocated to a rendering GPU for object rendering, the rendering GPU being one of the plurality of GPUs; 63. The method of claim 62, further comprising skipping rendering of the piece of geometry in the second set at the rendering GPU when the information indicates that the piece of geometry in the second set does not overlap with any screen area allocated to the rendering GPU for object rendering.

64. In the interleaving, configuring the first set of shaders in a command buffer to perform geometry tests on the first set of pieces of geometry; performing geometry tests on the first set of pieces of geometry using the first set of shaders in the plurality of GPUs to generate first information regarding each piece of geometry in the first set and its relationship to each of the plurality of screen regions; configuring the first set of shaders to perform rendering of the first set of pieces of geometry; skipping rendering of a first piece of geometry in the first set of pieces of geometry at a first rendering GPU when the first information indicates that the first piece of geometry does not overlap any screen area allocated to the first rendering GPU for object rendering; configuring the second set of shaders in a command buffer to perform geometry tests on the second set of pieces of geometry; performing geometry tests on the second set of pieces of geometry using the second set of shaders in the plurality of GPUs to generate second information regarding each piece of geometry in the second set and its relationship to each of the plurality of screen regions; configuring the second set of shaders to perform rendering of the second set of pieces of geometry; 63. The method of claim 62, further comprising skipping rendering of a second piece of geometry in the second set of pieces of geometry at a second rendering GPU when the second information indicates that the second piece of geometry does not overlap with any screen area allocated to the second rendering GPU for object rendering.

65. Further, providing the corresponding information as a hint to a rendering GPU, the rendering GPU being one of the plurality of GPUs; the information is taken into account by the rendering GPU when received prior to the rendering of a corresponding piece of geometry; 63. The method of claim 62, wherein the corresponding piece of geometry is fully rendered in the rendering GPU when the information is received after rendering of the corresponding piece of geometry has begun.

66. allocating pieces of geometry within the plurality of pieces of geometry evenly or non-uniformly across the plurality of GPUs; 63. The method of claim 62, further comprising allocating the multiple pieces of geometry such that consecutive pieces of geometry are processed by different GPUs.

67. 63. The method of claim 62, wherein one or more of the multiple GPUs are part of a larger GPU configured as multiple virtual GPUs.

68. 1. A computer system comprising: A processor; a memory coupled to the processor having instructions stored thereon that, when executed by the computer system, cause the computer system to perform a method for graphics processing, the method comprising: Rendering graphics for an application using multiple graphics processing units (GPUs); dividing a responsibility for the rendering of the graphics geometry among the plurality of GPUs based on a plurality of screen regions, each GPU having a corresponding division of the responsibility known to the plurality of GPUs; assigning pieces of geometry of an image frame to the plurality of GPUs for geometry testing; setting a first GPU state that configures one or more shaders to perform the geometry test; performing geometry tests on the pieces of geometry on the GPUs to generate information regarding each piece of geometry and its relationship to each of the screen regions; setting a second GPU state that configures the one or more shaders to perform rendering; A computer system that uses the information generated for each of the multiple pieces of geometry when rendering the multiple pieces of geometry on the multiple GPUs.

69. When using the information:

69. The method of claim 68, further comprising skipping rendering of the piece of geometry on a rendering GPU if the information indicates that the piece of geometry does not overlap with any screen area allocated to a rendering GPU for object rendering, the rendering GPU being one of the multiple GPUs.

70. providing said information as a hint to a rendering GPU, said rendering GPU being one of said plurality of GPUs; the information is taken into account by the rendering GPU when received prior to rendering of the piece of geometry; 69. The method of claim 68, wherein the piece of geometry is fully rendered in the rendering GPU when the information is received after rendering of the piece of geometry has begun.

71. allocating pieces of geometry within the plurality of pieces of geometry evenly or non-uniformly across the plurality of GPUs; 69. The method of claim 68, further comprising allocating the multiple pieces of geometry such that consecutive pieces of geometry are processed by different GPUs.

72. 69. The method of claim 68, wherein a first GPU performs geometry pre-testing on more pieces of geometry than a second GPU, or the first GPU performs geometry pre-testing while the second GPU does not perform geometry pre-testing at all.

73. 69. The method of claim 68, wherein, depending on the first GPU state or the second GPU state, when executing commands in a rendering command buffer, the commands cause output of the information about the piece of geometry or cause output of vertex position and parameter information for later use by one or more rendering stages.

74. 74. The method of claim 73, wherein the command affecting the GPU configuration is interpreted in a number of ways depending on the first GPU state or the second GPU state.

75. Additionally, in the command buffer: generating first information for a first piece of geometry and its relationship to the plurality of screen regions and rendering the first piece of geometry; 70. The method of claim 68, further comprising interleaving the generation of second information for a second piece of geometry and its relationship to the plurality of screen regions and the rendering of the second piece of geometry.

76. 69. The method of claim 68, wherein the hardware context is maintained or recorded and read.

77. 69. The method of claim 68, wherein one or more of the multiple GPUs are part of a larger GPU configured as multiple virtual GPUs.

Images