CN115298686B - System and method for efficient multi-GPU rendering of geometry by pre-testing for interleaved screen areas prior to rendering - Google Patents

Abstract

A method for graphics processing. The method includes rendering graphics for an application using a plurality of Graphics Processing Units (GPUs). The method includes dividing responsibilities for rendering geometry of graphics between a plurality of GPUs based on the interleaved plurality of screen regions, each GPU having a corresponding division of responsibilities known to the plurality of GPUs. The method includes assigning geometries of image frames generated by the application to the GPU for geometry pre-testing. The method includes performing a geometry pre-test at the GPU to generate information about the geometry and its relationship to each of the plurality of screen regions. The method includes using the information at each of the plurality of GPUs in rendering the image frames.

Description

Geometry mapping by pre-testing against interleaved screen areas before rendering System and method for efficient multi-GPU rendering of graphics

Technical field

This disclosure relates to graphics processing, and more specifically to multi-GPU collaboration in rendering images for applications.

Background technique

In recent years, there has been a push for online services that allow online gaming or cloud gaming in a streaming format between cloud gaming servers and clients connected through the network. Due to the availability of game titles on demand, the ability to perform more complex games, the ability to network between players for multi-player games, asset sharing between players, instant experience sharing between players and/or viewers, allowing friends to watch friends play Video games, letting friends join their friends' ongoing gaming sessions, etc., the streaming format is becoming increasingly popular.

A cloud gaming server may be configured to provide resources to one or more clients and/or applications. That is, cloud gaming servers can be configured with resources capable of high throughput. For example, there is a limit to the performance a single graphics processing unit (GPU) can achieve. In order to render more complex scenes or use more complex algorithms (such as materials, lighting, etc.) when generating the scene, it may be necessary to use multiple GPUs to render a single image. However, equivalent use of these graphics processing units is difficult to achieve. Additionally, even if multiple GPUs were used to process images for the application using traditional techniques, they would not be able to support the corresponding increase in screen pixel count and geometry density (e.g., four GPUs would not be able to write four times the pixels and/or process four times the vertices of the image or primitive).

It is against this background that embodiments of the present disclosure arise.

Contents of the invention

Embodiments of the present disclosure involve using multiple GPUs to collaborate to render a single image, such as multi-GPU rendering of geometry for an application by pre-testing for potentially interleaved screen areas prior to rendering.

Embodiments of the present disclosure disclose a method for graphics processing. The method includes using multiple graphics processing units (GPUs) to render graphics for the application. The method includes dividing the responsibility for rendering the geometry of the graphics among multiple GPUs based on multiple screen areas, each GPU having a corresponding division of responsibilities known to the multiple GPUs. Screen areas are staggered. The method includes allocating multiple geometries of an image frame to multiple GPUs for geometry testing. The method includes allocating the geometry of image frames generated by the application to the GPU for geometry testing. The method includes performing a geometry test at the GPU to generate information about the geometry and its relationship to each of a plurality of screen areas. The method includes using the information to render the geometry at each of a plurality of GPUs, where using the information may include, for example, skipping entirely if it has been determined that the geometry does not overlap any screen area allocated to the given GPU. Over rendering.

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 responsibility for rendering geometry of a graphic among a plurality of GPUs based on a plurality of screen areas, each GPU having a corresponding division of responsibilities known to the plurality of GPUs, wherein said Screen areas within multiple screen areas are interleaved. The computer-readable medium includes program instructions for allocating geometry of image frames generated by an application to a GPU for geometry pre-testing. The computer-readable medium includes program instructions for performing geometry pretesting at a GPU to generate information about the geometry and its relationship to each of a plurality of screen areas. The computer-readable medium includes program instructions for using the information at each of a plurality of GPUs when rendering image frames.

In another embodiment, a computer system is disclosed, including a processor and a memory, the memory being coupled to the processor and having instructions stored therein that, if executed by the computer system, cause the computer system to perform operations for graphics Processing method. The method includes using multiple graphics processing units (GPUs) to render graphics for the application. The method includes dividing responsibilities for rendering geometry between a plurality of GPUs based on a plurality of screen areas, each GPU having a corresponding division of responsibilities known to the plurality of GPUs, wherein the screen areas of the plurality of screen areas It's staggered. The method includes allocating the geometry of image frames generated by the application to the GPU for geometry pre-testing. The method includes performing a geometry pretest at the GPU to generate information about the geometry and its relationship to each of a plurality of screen areas. The method includes using the information at each of multiple GPUs when rendering image frames.

Embodiments of the present disclosure disclose a method for graphics processing. The method includes using multiple graphics processing units (GPUs) to render graphics for the application. The method includes dividing the responsibility for rendering the geometry of the graphics among multiple GPUs based on multiple screen areas, each GPU having a corresponding division of responsibilities known to the multiple GPUs. The method includes performing geometry testing at a pre-test GPU on a plurality of geometries of an image frame generated by an application to generate information about each geometry and its relationship to each of the plurality of screen areas. The method includes rendering, at each of a plurality of GPUs, using information generated for each of a plurality of geometries, wherein using the information includes, for example, if it has been determined that the geometry does not match the If any screen area overlaps a given GPU, rendering is skipped entirely.

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 responsibility for rendering geometry of a graphic among a plurality of GPUs based on a plurality of screen areas, each GPU having a corresponding division of responsibility known to the plurality of GPUs. The computer-readable medium includes means for performing, at a pre-test GPU, a geometry test on a plurality of geometries of an image frame generated by an application to generate information about each geometry and its relationship to each of the plurality of screen areas. information program instructions. The computer-readable medium includes program instructions for rendering, at each of a plurality of GPUs, information generated for each of a plurality of geometries, wherein using the information includes, for example, if Make sure that the geometry does not overlap any screen area allocated to the given GPU, then skip rendering entirely.

In another embodiment, a computer system is disclosed, including a processor and a memory, the memory being coupled to the processor and having instructions stored therein that, if executed by the computer system, cause the computer system to perform operations for graphics Processing method. The method includes using multiple graphics processing units (GPUs) to render graphics for the application. The method includes dividing the responsibility for rendering the geometry of the graphics among multiple GPUs based on multiple screen areas, each GPU having a corresponding division of responsibilities known to the multiple GPUs. The method includes performing geometry testing at a pre-test GPU on a plurality of geometries of an image frame generated by an application to generate information about each geometry and its relationship to each of the plurality of screen areas. The method includes rendering, at each of a plurality of GPUs, using information generated for each of a plurality of geometries, wherein using the information includes, for example, if it has been determined that the geometry does not match the If any screen area overlaps a given GPU, rendering is skipped entirely.

Embodiments of the present disclosure disclose a method for graphics processing. The method includes using multiple graphics processing units (GPUs) to render graphics for the application. The method includes dividing the responsibility for rendering the geometry of the graphics among multiple GPUs based on multiple screen areas, each GPU having a corresponding division of responsibilities known to the multiple GPUs. The method includes rendering a first plurality of geometries at a plurality of GPUs during a rendering phase of a previous image frame generated by an application. The method includes generating statistics for the rendering of a previous image frame. The method includes allocating a second plurality of geometries of a current image frame generated by an application to a plurality of GPUs for geometry testing based on statistical data. The method includes performing a geometry test on a second plurality of geometric figures on a current image frame to generate information about each of the second plurality of geometric figures and its relationship to each of a plurality of screen areas, wherein Geometry tests are performed on each of multiple GPUs based on allocation. The method includes rendering at each of a plurality of GPUs using information generated for each of the second plurality of geometries, wherein using the information may include, for example, if the geometry has been determined If the graphic does not overlap any screen area allocated to a given GPU, rendering is skipped entirely.

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 responsibility for rendering geometry of a graphic among a plurality of GPUs based on a plurality of screen areas, 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 geometries at a plurality of GPUs during a rendering phase of a previous image frame generated by an application. The computer-readable medium includes program instructions for generating statistical data for rendering a previous image frame. The computer-readable medium includes program instructions for allocating a second plurality of geometries of a current image frame generated by an application to a plurality of GPUs for geometry testing based on statistical data. The computer-readable medium includes means for performing a geometry test on a second plurality of geometric figures on a current image frame to generate a graph with respect to each of the second plurality of geometric figures and each of the plurality of screen areas. Information related to program instructions on which geometry testing is based is allocated to execution at each of multiple GPUs. The computer-readable medium includes program instructions for rendering, at each of a plurality of GPUs, information generated for each of the second plurality of geometries, wherein the information is used This can include, for example, skipping rendering entirely if it has been determined that the geometry does not overlap any screen area allocated to a given GPU.

In another embodiment, a computer system is disclosed, including a processor and a memory, the memory being coupled to the processor and having instructions stored therein that, if executed by the computer system, cause the computer system to perform operations for graphics Processing method. The method includes using multiple graphics processing units (GPUs) to render graphics for the application. The method includes dividing the responsibility for rendering the geometry of the graphics among multiple GPUs based on multiple screen areas, each GPU having a corresponding division of responsibilities known to the multiple GPUs. The method includes rendering a first plurality of geometries at a plurality of GPUs during a rendering phase of a previous image frame generated by an application. The method includes generating statistics for the rendering of a previous image frame. The method includes allocating a second plurality of geometries of a current image frame generated by an application to a plurality of GPUs for geometry testing based on statistical data. The method includes performing a geometry test on a second plurality of geometric figures on a current image frame to generate information about each of the second plurality of geometric figures and its relationship to each of a plurality of screen areas, wherein Geometry tests are performed on each of multiple GPUs based on allocation. The method includes rendering at each of a plurality of GPUs using information generated for each of the second plurality of geometries, wherein using the information may include, for example, if the geometry has been determined If the graphic does not overlap any screen area allocated to a given GPU, rendering is skipped entirely.

Embodiments of the present disclosure disclose a method for graphics processing. The method includes using multiple graphics processing units (GPUs) to render graphics for the application. The method includes dividing the responsibility for rendering the geometry of the graphics among multiple GPUs based on multiple screen areas, each GPU having a corresponding division of responsibilities known to the multiple GPUs. The method includes allocating multiple geometries of an image frame to multiple GPUs for geometry testing. The method includes setting a first state that configures one or more shaders to perform geometry testing. The method includes performing geometry tests on multiple geometries at multiple GPUs to generate information about each geometry and its relationship to each of the multiple screen areas. The method includes setting a second state that configures one or more shaders to perform rendering. The method includes rendering, at each of a plurality of GPUs, using information generated for each of a plurality of geometries, wherein using the information includes, for example, if it has been determined that the geometry does not match the If any screen area overlaps a given GPU, rendering is skipped entirely.

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 responsibility for rendering geometry of a graphic among a plurality of GPUs based on a plurality of screen areas, each GPU having a corresponding division of responsibility known to the plurality of GPUs. The computer-readable medium includes program instructions for allocating multiple geometries of an image frame to multiple GPUs for geometry testing. The computer-readable medium includes program instructions for setting a first state that configures one or more shaders to perform geometry testing. The computer-readable medium includes program instructions for performing geometry testing on a plurality of geometries at a plurality of GPUs to generate information about each geometry and its relationship to each of a plurality of screen areas. 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 includes program instructions for rendering, at each of a plurality of GPUs, information generated for each of a plurality of geometries, wherein using the information includes, for example, if Make sure that the geometry does not overlap any screen area allocated to the given GPU, then skip rendering entirely.

In another embodiment, a computer system is disclosed, including a processor and a memory, the memory being coupled to the processor and having instructions stored therein that, if executed by the computer system, cause the computer system to perform operations for graphics Processing method. The method includes using multiple graphics processing units (GPUs) to render graphics for the application. The method includes dividing the responsibility for rendering the geometry of the graphics among multiple GPUs based on multiple screen areas, each GPU having a corresponding division of responsibilities known to the multiple GPUs. The method includes allocating multiple geometries of an image frame to multiple GPUs for geometry testing. The method includes setting a first state that configures one or more shaders to perform geometry testing. The method includes performing geometry tests on multiple geometries at multiple GPUs to generate information about each geometry and its relationship to each of the multiple screen areas. The method includes setting a second state that configures one or more shaders to perform rendering. The method includes rendering, at each of a plurality of GPUs, using information generated for each of a plurality of geometries, wherein using the information includes, for example, if it has been determined that the geometry does not match the If any screen area overlaps a given GPU, rendering is skipped entirely.

Embodiments of the present disclosure disclose a method for graphics processing. The method includes using multiple graphics processing units (GPUs) to render graphics for the application. The method includes dividing the responsibility for rendering the geometry of the graphics among multiple GPUs based on multiple screen areas, each GPU having a corresponding division of responsibilities known to the multiple GPUs. The method includes allocating multiple geometries of an image frame to multiple GPUs for geometry testing. The method includes interleaving a first set of shaders performing geometry testing and rendering on a first set of geometries with a second set of shaders performing geometry testing and rendering on a second set of geometries. The geometry test generates corresponding information about each geometry in the first or second group and its relationship to each of the plurality of screen areas. The plurality of GPUs render each geometry in the first or second group using corresponding information, where using the information includes, for example, completely rendering the geometry if it has been determined that it does not overlap any screen area allocated to the given GPU. Skip rendering.

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 responsibility for rendering geometry of a graphic among a plurality of GPUs based on a plurality of screen areas, each GPU having a corresponding division of responsibility known to the plurality of GPUs. The computer-readable medium includes program instructions for allocating multiple geometries of an image frame to multiple GPUs for geometry testing. The computer-readable medium includes program instructions for interleaving a first set of shaders performing geometry testing and rendering on a first set of geometries with a second set of shaders performing geometry testing and rendering on a second set of geometries. The geometry test generates corresponding information about each geometry in the first or second group and its relationship to each of the plurality of screen areas. The plurality of GPUs render each geometry in the first or second group using corresponding information, where using the information includes, for example, completely rendering the geometry if it has been determined that it does not overlap any screen area allocated to the given GPU. Skip rendering.

In another embodiment, a computer system is disclosed, including a processor and a memory, the memory being coupled to the processor and having instructions stored therein that, if executed by the computer system, cause the computer system to perform operations for graphics Processing method. The method includes using multiple graphics processing units (GPUs) to render graphics for the application. The method includes dividing the responsibility for rendering the geometry of the graphics among multiple GPUs based on multiple screen areas, each GPU having a corresponding division of responsibilities known to the multiple GPUs. The method includes allocating multiple geometries of an image frame to multiple GPUs for geometry testing. The method includes interleaving a first set of shaders performing geometry testing and rendering on a first set of geometries with a second set of shaders performing geometry testing and rendering on a second set of geometries. The geometry test generates corresponding information about each geometry in the first or second group and its relationship to each of the plurality of screen areas. The plurality of GPUs render each geometry in the first or second group using corresponding information, where using the information includes, for example, completely rendering the geometry if it has been determined that it does not overlap any screen area allocated to the given GPU. Skip rendering.

Other aspects of the 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 disclosure.

Description of the drawings

The present disclosure may best be understood by reference to the following description taken in conjunction with the accompanying drawings, in which:

1 is a schematic diagram of a system for providing games over a network between one or more cloud gaming servers configured to enable multiple GPUs to cooperate to render a single image, including by Pre-test geometry for potentially interleaved screen areas to perform multi-GPU (graphics processing unit) rendering of geometry for your application.

Figure 2 is a schematic diagram of a multi-GPU architecture in which multiple GPUs cooperate to render a single image, according to one embodiment of the present disclosure.

3 is a schematic diagram of multiple graphics processing unit resources configured for multi-GPU rendering of geometry for an application by pre-testing the geometry for potentially interleaved screen areas, according to one embodiment of the present disclosure.

4 is a schematic diagram of a rendering architecture implementing a graphics pipeline configured for multi-GPU processing such that multiple GPUs cooperate to render a single image, in accordance with one embodiment of the present disclosure.

5 is a flowchart illustrating a method for graphics processing including multi-GPU rendering of geometry for an application by pre-testing for interleaved screen areas prior to rendering, according to one embodiment of the present disclosure.

Figure 6A is a schematic diagram of a screen subdivided into quadrants when performing multi-GPU rendering, in accordance with one embodiment of the present disclosure.

6B is a schematic diagram of a screen subdivided into multiple interleaved regions when performing multi-GPU rendering, according to one embodiment of the present disclosure.

7A is a schematic diagram of a rendering command buffer shared by multiple GPUs collaborating to render a single image frame, including a pretest and rendering portion of the geometry portion, according to one embodiment of the present disclosure.

7B-1 illustrates an image including four objects rendered by multiple GPUs, and shows the screen area responsibility of each GPU in rendering the objects of the image, according to one embodiment of the present disclosure.

Figure 7B-2 is a table illustrating the rendering performed by each GPU when rendering the four objects of Figure 7B-1 according to one embodiment of the present disclosure.

Figure 7C is an illustration of geometry pre-testing and geometry performed by one or more GPUs when rendering an image frame (eg, the image of Figure 7B-1) through the cooperation of multiple GPUs, in accordance with one embodiment of the present disclosure. Schematic diagram of the rendered execution.

Figure 8A illustrates object testing for screen area when multiple GPUs collaborate to render a single image, according to one embodiment of the present disclosure.

8B illustrates testing of portions of an object of a screen area when multiple GPUs collaborate to render a single image, according to one embodiment of the present disclosure.

9A-9C illustrate various strategies for allocating screen areas to corresponding GPUs when multiple GPUs collaborate to render a single image, according to one embodiment of the present disclosure.

10 is a schematic diagram illustrating various distributions of GPU allocations for performing geometry pretesting on multiple geometries in accordance with an embodiment of the present disclosure.

11A is a diagram illustrating geometry pre-testing and rendering of a previous image frame by multiple GPUs and using statistics collected during rendering in the current image frame to affect the rendering of the current image, according to one embodiment of the present disclosure. Illustration of pre-test distribution of frame geometry to multiple GPUs.

11B is a flowchart illustrating a graphics processing method according to one embodiment of the present disclosure, including geometry pre-testing and rendering of a previous image frame by multiple GPUs and using data collected during rendering in the current image frame. Statistics to influence the pre-test distribution of the geometry of the current image frame to multiple GPUs.

12A is a schematic diagram illustrating the use of a shader configured to perform both pre-testing and rendering of the geometry of an image frame in two passes through a portion of a command buffer, in accordance with one embodiment of the present disclosure.

12B is a flowchart illustrating a graphics processing method including performing pre-testing of the geometry of an image frame using the same set of shaders in two passes through a portion of a command buffer, in accordance with one embodiment of the present disclosure. and rendering both.

13A is a schematic diagram illustrating the use of a shader configured to perform both geometry testing and rendering for different sets of geometries using corresponding commands, according to one embodiment of the present disclosure. Individual parts of the buffer are interleaved.

13B is a flowchart illustrating a graphics processing method including using separate portions of corresponding command buffers to interleave pre-testing and rendering of geometry for image frames for different sets of geometries, according to one embodiment of the present disclosure.

Figure 14 illustrates components of an example apparatus that may be used to perform aspects of various embodiments of the present disclosure.

Detailed ways

Although the following detailed description contains many specific details for purposes of illustration, one of ordinary skill in the art will appreciate that many variations and modifications of the following details are within the scope of the present disclosure. Accordingly, the various aspects of the present disclosure described below are set forth without any loss of the generality of the appended claims of this specification and without the imposition of any limitations on such claims.

Generally speaking, there are limits to the performance a single GPU can achieve, derived from, for example, the limits on how big a GPU can be. In embodiments of the present disclosure, in order to render more complex scenes or use more complex algorithms (eg, materials, lighting, etc.), it is desirable to use multiple GPUs to render a single image. 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 for potentially interleaved screen areas. Multiple GPUs collaborate to generate images. Divide rendering responsibilities between multiple GPUs based on screen area. Before rendering geometry, the GPU generates information about the geometry and its relationship to the screen area. This allows the GPU to render the geometry more efficiently or avoid rendering it entirely. As an advantage, this allows multiple GPUs to render more complex scenes and/or images in the same amount of time, for example.

With the above general understanding of various implementations in mind, example details of implementations will now be described with reference to the various figures.

Throughout this specification, references to "application" or "game" or "video game" or "game application" are intended to mean any type of interactive application that is directed by executing input commands. For illustrative purposes only, interactive applications include applications for gaming, word processing, video processing, video game processing, and the like. Furthermore, the terms introduced above are interchangeable.

Throughout this specification, various embodiments of the present disclosure are described with respect to multi-GPU processing or rendering of geometry for applications using an exemplary architecture with four GPUs. However, it should be understood that any number of GPUs (eg, two or more GPUs) may cooperate when rendering geometry for an application.

1 is a schematic diagram of a system for performing multi-GPU processing when rendering images (eg, image frames) for an application, according to one embodiment of the present disclosure. According to embodiments of the present disclosure, the system is configured to provide games between one or more cloud gaming servers over a network, and is more specifically configured for the cooperation of multiple GPUs to render a single image of an application. Cloud gaming involves executing a video game on a server to generate game-rendered video frames, which are then sent to the client for display. In particular, system 100 is configured for efficient multi-GPU rendering of geometry for applications by pre-testing for potentially interleaved screen areas prior to rendering.

While FIG. 1 illustrates enabling multi-GPU rendering of geometry between one or more cloud gaming servers of a cloud gaming system, other embodiments of the present disclosure implement multi-GPU rendering of geometry between one or more cloud gaming servers of a cloud gaming system, other embodiments of the present disclosure include Performing zone testing within a high-end graphics card (PC or gaming console) provides applications with efficient multi-GPU rendering of geometry.

It should also be understood that in various implementations (eg, in a cloud gaming environment or in a stand-alone system), multi-GPU rendering of geometry may be performed using physical GPUs or virtual GPUs, or a combination of both. For example, a virtual machine (eg, an instance) may be created using a hypervisor of host hardware (eg, located in a data center) that utilizes one or more components of a hardware layer (such as multiple CPUs, memory modules, GPUs, network interfaces, communications components, etc.) . These physical resources can be arranged in racks, such as CPU racks, GPU racks, memory racks, etc., where the physical resources in the rack can be accessed using a top-of-rack switch that facilitates assembly and access for The structure of the instance's components (for example, when building the instance's virtualized components). Typically, a hypervisor can present multiple guest operating systems configured with multiple instances of virtual resources. That is, each operating system may be configured with a corresponding set of virtualization resources supported by one or more hardware resources (eg, located in a corresponding data center). For example, each operating system may be supported by a virtual CPU, multiple virtual GPUs, virtual memory, virtualized communications components, etc. Additionally, an instance's configuration can be moved from one data center to another to reduce latency. GPU utilization defined for a user or game can be used when saving a user's game session. GPU utilization can include any number of configurations described in this article to optimize fast rendering of video frames for a gaming session. In one embodiment, GPU utilization defined for a game or user can be transferred between data centers as a configurable setting. The ability to transfer GPU utilization settings effectively moves game play from data center to data center in situations where users are connected to play games in different geographical locations.

According to one embodiment of the present disclosure, the system 100 provides games via a cloud gaming network 190 where the games are executed on a client device 110 (eg, a thin client) remote from the corresponding user who is playing the game. System 100 may provide game controls over cloud gaming network 190 via network 150 to one or more users playing one or more games in single-player or multi-player modes. In some embodiments, cloud gaming network 190 may include multiple virtual machines (VMs) running on a host's hypervisor, where one or more VMs are configured to execute using hardware resources available to the host's hypervisor. Game processor module. Network 150 may include one or more communications technologies. In some embodiments, network 150 may include fifth generation (5G) network technology with advanced wireless communication systems.

In some embodiments, wireless technology may be used to facilitate communication. Such technologies may include, for example, 5G wireless communications technology. 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 geographic areas called cells. Analog signals representing sound and images are digitized in the phone, converted by an analog-to-digital converter and transmitted as a bit stream. All 5G wireless devices in a cell communicate via radio waves with the local antenna array and low-power automatic transceivers (transmitters and receivers) in the cell through frequency channels allocated by transceivers from a frequency pool that is reused in other cells. . Local antennas connect to the telephone network and the Internet via high-bandwidth fiber optic or wireless backhaul connections. As in other cell networks, mobile devices crossing from one cell to another are automatically transferred to the new cell. It should be understood that 5G networks are only an example type of communication network and that embodiments of the present disclosure may utilize earlier generations of wireless or wired communications, as well as newer generations of wired or wireless technologies after 5G.

As shown, cloud gaming network 190 includes game servers 160 that provide access to a plurality of video games. 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 executing on one or more hosts. For example, game server 160 may manage a virtual machine that supports a game processor that instantiates game instances for users. As such, multiple game processors of game server 160 associated with multiple virtual machines are configured to execute multiple instances of one or more games associated with multiple users' game play. In this manner, the backend server supports streaming of media (eg, video, audio, etc.) for gaming of multiple gaming applications to multiple corresponding users. That is, game server 160 is configured to stream data (eg, rendered images and/or frames corresponding to game play) over network 150 back to corresponding client device 110 . In this manner, computationally complex gaming applications can be executed at the backend server in response to controller input received and forwarded by client device 110 . Each server is capable of rendering images and/or frames, which are then encoded (eg, compressed) and streamed to the corresponding client device for display.

For example, multiple users may access cloud gaming network 190 via communication network 150 using corresponding client devices 110 configured to receive streaming media. In one embodiment, client device 110 may be configured as a thin client that provides communication with a backend server (eg, including game title processing engine 111 ) configured to provide computing functionality. Cloud gaming network 190) interface. In another embodiment, the client device 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 utilized to receive video games generated by the video game executing at the backend server. Streaming content, or other content provided by backend server support. For local processing, the game title processing engine includes basic processor-based functionality for executing video games and services associated with video games. In this case, the game logic may be stored locally on the client device 110 and used to execute the video game.

Each client device 110 may request access to a different game from the cloud gaming network. For example, cloud gaming network 190 may execute one or more game logic built on game title processing engine 111 , as executed using CPU resources 163 and GPU resources 365 of game server 160 . For example, game logic 115a in cooperation with the game name processing engine 111 may be executed on the game server 160 for one client, and game logic 115b in cooperation with the game name processing engine 111 may be executed on the game server 160 for a second client. , ...and the game logic 115n cooperating with the game name processing engine 111 may be executed on the game server 160 for the Nth client.

In particular, a client device 110 corresponding to a user (not shown) is configured for requesting access to a game through a communication network 150 such as the Internet, and for rendering display images (eg, images) generated by a video game executed by the game server 160 frame), in which the encoded image is transmitted to the client device 110 for display in association with the corresponding user. For example, a user may interact through client device 110 with an instance of a video game executing on a game processor of game server 160 . More specifically, instances of video games are executed by game title processing engine 111 . Corresponding game logic (eg, executable code) 115 that implements the video game is stored and accessible through a data store (not shown) and used to execute the video game. The game title processing engine 111 is capable of supporting multiple video games using multiple game logics (eg, game applications), each game logic being selectable by the user.

For example, the client device 110 is configured to interact with the game title processing engine 111 associated with the corresponding user's game play, such as through input commands for driving the game play. In particular, client device 110 may receive input from various types of input devices, such as game controllers, tablets, keyboards, gestures captured by cameras, mice, touch pads, and the like. Client device 110 may be any type of computing device having at least memory and a processor module capable of connecting to game server 160 over network 150 . The backend game title processing engine 111 is configured to generate a rendered image that is transmitted over the network 150 for display at a corresponding display associated with the client device 110 . For example, through a cloud-based service, game rendering images may be delivered by an instance of the corresponding game (eg, game logic) executing on the game execution engine 111 of the game server 160 . That is, client device 110 is configured to receive an encoded image (eg, encoded from a game-rendered image generated by executing a video game) and to display the rendered image on display 11 . In one embodiment, display 11 includes a HMD (eg, displaying VR content). In some implementations, the rendered image may be wirelessly or wired, directly from a cloud-based service, or via client device 110 (e.g., Remote Play) to stream to your smartphone or tablet.

In one embodiment, game server 160 and/or game title processing engine 111 includes basic processor-based functionality for executing games and services associated with game applications. For example, game server 160 includes central processing unit (CPU) resources 163 and graphics processing unit (GPU) resources 365 that are configured to perform processor-based functions including 2D or 3D rendering, physics simulation, scripting, audio, Animation, graphics processing, lighting, shading, rasterization, ray tracing, shadows, culling, transforms, artificial intelligence, and more. In addition, the CPU and GPU groups can implement services for gaming applications, including in part memory management, multi-thread management, quality of service (QoS), bandwidth testing, social networking, social friend management, social network communication with friends, communication channels , texting, instant messaging, chat support, and more. In one embodiment, one or more applications share specific GPU resources. In one embodiment, multiple GPU devices may be combined to perform graphics processing for a single application executing on a corresponding CPU.

In one embodiment, cloud gaming network 190 is a distributed game server system and/or architecture. In particular, a distributed game engine executing game logic is configured to correspond to a corresponding instance of the game. Typically, a distributed game engine takes every function of the game engine and distributes those functions for execution by multiple processing entities. Individual functionality can be further distributed across one or more processing entities. The processing entity may be configured in different configurations, including physical hardware, and/or as virtual components or virtual machines, and/or as virtual containers, where a container is different from a virtual machine in that it is virtualized and is running on a virtualized operating system. Examples of gaming applications. The processing entity may utilize and/or rely on servers and their underlying hardware on one or more servers (computing nodes) of the cloud gaming network 190, where the servers may be located on one or more racks. The coordination, allocation, and management of the various processing entities performing these functions are performed by the distributed synchronization layer. In this manner, the execution of these functions is controlled by a distributed synchronization layer to generate media (e.g., video frames, audio, etc.) for the game application in response to the player's controller input. The distributed synchronization layer is able to efficiently perform (e.g., through load balancing) these functions across distributed processing entities so that critical game engine components/functions are distributed and reassembled for more efficient processing.

Figure 2 is a schematic diagram of an exemplary multi-GPU architecture 200 in which multiple GPUs cooperate to render a single image for a corresponding application, according to one embodiment of the present disclosure. It should be understood that in various embodiments of the present disclosure, many architectures are possible in which multiple GPUs cooperate to render a single image, although not explicitly described or shown. For example, multi-GPU rendering of geometry for an application by performing area testing at render time may be implemented between one or more cloud gaming servers of a cloud gaming system, or may be performed on a standalone system such as a high-end server that includes multiple GPUs. graphics card (PC or game console), etc.

Multi-GPU architecture 200 includes a CPU 163 and a plurality of GPUs configured for multi-GPU rendering for a single image of an application and/or for each image in a sequence of images of the application. In particular, CPU 163 and GPU resources 365 are configured to perform processor-based functions including 2D or 3D rendering, physics simulation, scripting, audio, animation, graphics processing, lighting, shading, rasterization, ray tracing, shading , culling, transformation, artificial intelligence, etc., as mentioned above.

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

Additionally, each GPU is connected to one another via a bus 240, which, depending on the architecture, may be approximately equal to or slower in speed than bus 220 used for communication between a corresponding GPU and its corresponding memory. For example, GPU-A is connected to each of GPU-B, GPU-C, and GPU-D via bus 240 . Likewise, GPU-B is connected to each of GPU-A, GPU-C, and GPU-D via bus 240 . In addition, GPU-C is connected to each of GPU-A, GPU-B, and GPU-D via bus 240 . Further, GPU-D is connected to each of GPU-A, GPU-B, and GPU-C via bus 240 .

CPU 163 is connected to each GPU via a lower speed bus 230 (eg, bus 230 is slower than bus 220 used for communication between the corresponding GPU and its corresponding memory). Specifically, the CPU 163 is connected to each of GPU-A, GPU-B, GPU-C, and GPU-D.

3 is a schematic diagram of a graphics processing unit resource 365 configured to geometrically shape image frames generated by an application by pre-testing for potentially interleaved screen areas prior to rendering, in accordance with one embodiment of the present disclosure. Multi-GPU rendering. For example, game server 160 may be configured to include GPU resources 365 in cloud gaming network 190 of FIG. 1 . As shown, GPU resource 365 includes multiple GPUs, such as GPU 365a, GPU 365b...GPU 365n. As previously mentioned, various architectures may include multiple GPUs cooperating to render a single image by performing multi-GPU rendering of geometry for the application through zone testing at render time, such as between one or more cloud gaming servers of a cloud gaming system. Multi-GPU rendering of geometry can be implemented in a stand-alone system such as a personal computer or game console that includes a high-end graphics card with multiple GPUs, etc.

Specifically, in one embodiment, game server 160 is configured to perform multi-GPU processing when rendering a single image of an application, such that multiple GPUs cooperate to render a single image, and/or to render one or more of a sequence of images when executing an application. Multiple images each. For example, in one embodiment, game server 160 may include a CPU and GPU group configured to perform multi-GPU rendering on each of one or more images in an application's sequence of images, where one CPU and GPU group may Implement the application's graphics and/or rendering pipeline. CPU and GPU groups can be configured as one or more processing devices. As previously mentioned, GPUs and GPU groups may include CPU 163 and GPU resources 365 configured to perform processor-based functions including 2D or 3D rendering, physics simulation, scripting, audio, animation, graphics processing, lighting , shading, rasterization, ray tracing, shadows, culling, transforms, artificial intelligence, and more.

GPU resources 365 are responsible and/or configured for rendering objects (e.g., writing color or normal vector values of object pixels to a multi-render target-MRT) and executing synchronized computing kernels (e.g., full-screen effects on the resulting MRT); The synchronized calculations to be performed and the objects to be rendered are specified by commands contained in the rendering command buffer 325 that the GPU will execute. In particular, GPU resource 365 is configured to render objects and perform synchronous computations (e.g., during the execution of a synchronous compute kernel) upon execution of commands from rendering command buffer 325 , where the commands and/or operations may depend on other operations, Make them execute in sequence.

For example, GPU resource 365 is configured to perform synchronized computations and/or rendering of objects using one or more render command buffers 325 (eg, render command buffer 325a, render buffer 325b...render command buffer 325n). In one embodiment, each GPU in GPU resources 365 may have their own command buffer. Alternatively, the GPUs in GPU resource 365 may use the same command buffer or the same set of command buffers when each GPU is rendering substantially the same set of objects (eg, due to the small size of the region). Additionally, each GPU in GPU resources 365 may support the ability for commands to be executed by one GPU but not another GPU. For example, a flag on a draw command or a prediction in a render command buffer allows a single GPU to execute one or more commands in the corresponding command buffer, while other GPUs will ignore these 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.

The performance of synchronized calculations (e.g. the execution of synchronized calculation kernels) and the rendering of objects are part of the overall rendering. For example, if a video game runs at 60Hz (e.g., 60 frames per second), then all object rendering and execution of synchronized computing cores for an image frame must typically complete in approximately 16.67 milliseconds (e.g., one frame at 60Hz). As mentioned previously, operations performed when rendering objects and/or executing synchronous compute kernels are ordered such that operations may depend on other operations (e.g., a command in a render command buffer may require a command in that render command buffer. Other commands can be executed before completing execution).

In particular, each render command buffer 325 contains various types of commands, including commands that affect the corresponding GPU configuration (e.g., commands that specify the location and format of a render target), as well as commands that render objects and/or execute synchronous computing kernels. . For purposes of illustration, synchronous computations performed when executing a synchronous computation kernel may include performing full-screen effects when objects are all rendered to one or more corresponding multiple render targets (MRTs).

Additionally, when the GPU resource 365 is an image frame rendering object, and/or executes a synchronous computation kernel when generating an image frame, the GPU resource 365 is configured via the registers of each GPU 365a, 365b...365n. For example, GPU 365a is configured via its registers 340 (eg, register 340a, register 340b...register 340n) to perform the rendering or compute core execution in a certain manner. That is, the values stored in register 340 define the hardware context (e.g., GPU configuration or GPU status). Each GPU 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 the rendering or compute kernel execution in a certain manner; ... ...and GPU 365n is configured via its registers 370 (eg, register 370a, register 370b...register 370n) to perform this rendering or compute core execution in a certain manner.

Some examples of GPU configuration include the location and format of render targets (such as MRT). Additionally, other examples of GPU configurations include operating procedures. For example, when rendering an object, you can compare the Z value of each pixel of the object to the Z buffer in various ways. For example, object pixels are only written if the object Z value matches the value in the Z buffer. Instead, object pixels 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 being performed is defined in the GPU configuration.

4 is a simplified schematic diagram of a rendering architecture implementing a graphics pipeline 400 configured for multi-GPU processing such that multiple GPUs cooperate to render a single image, in accordance with one embodiment of the present disclosure. Graphics pipeline 400 illustrates the general process of rendering an image using a 3D (three-dimensional) polygon rendering process. Graphics pipeline 400 for rendering images outputs corresponding color information for each pixel in the display, where the color information may represent texture and shading (eg, color, shading, etc.). Graphics pipeline 400 may be implemented within client device 110, game server 160, game title processing engine 111, and/or GPU resources 365 of Figures 1 and 3. That is, various architectures may include multiple GPUs cooperating to render a single image by performing multi-GPU rendering of geometry for the application through zone testing at render time, such as between one or more cloud gaming servers of a cloud gaming system Implement multi-GPU rendering of geometry, or within a stand-alone system such as a personal computer or game console that includes high-end graphics cards with multiple GPUs, and so on.

As shown, the graphics pipeline receives input geometry 405. For example, geometry processing stage 410 receives input geometry 405 . For example, input geometry 405 may include vertices within a 3D game world, as well as information corresponding to each vertex. A given object in the game world may be represented using polygons (e.g., triangles) defined by vertices, where the surfaces of the corresponding polygons are then processed through the graphics pipeline 400 to achieve final effects (e.g., color, texture, etc.). Vertex attributes can include normals (e.g., which direction is normal to the geometry at that location), color (e.g., RGB - red, green, and blue triples, etc.), and texture coordinates/mapping information.

Geometry processing stage 410 is responsible for (and capable of) both vertex processing (eg, via vertex shaders) and primitive processing. In particular, the geometry processing stage 410 may output the set of vertices that define the primitives and pass them to the next stage of the graphics pipeline 400, as well as output the positions (to be precise, homogeneous coordinates) of these vertices and various other parameters. These locations are placed in location cache 450 for later shader level access. Other parameters are placed in parameter cache 460, again for access by subsequent shader levels.

Geometry processing stage 410 may perform various operations, such as performing lighting and shading calculations on primitives and/or polygons. In one embodiment, because the geometry stage is capable of processing primitives, it can perform backface culling and/or clipping (e.g., test against the view frustum), thereby reducing the load on downstream stages (e.g., rasterization stage 420, etc.) . In another embodiment, a geometry level may generate primitives (eg, having functionality equivalent to a traditional geometry shader).

The primitives output by the geometry processing stage 410 are fed to a rasterization stage 420, which converts the primitives into raster images composed of pixels. In particular, rasterization stage 420 is configured to project objects in the scene onto a two-dimensional (2D) image plane defined by a viewing position in the 3D game world (eg, camera position, user eye position, etc.). At a simple level, rasterization stage 420 looks at each primitive and determines which pixels are affected by the corresponding primitive. In particular, rasterizer 420 divides primitives into pixel-sized fragments, where each fragment corresponds to a pixel in the display. It is important to note that when an image is displayed, one or more fragments may affect the color of the corresponding pixel.

As mentioned previously, rasterization stage 420 may also perform additional operations such as clipping (identifying and ignoring fragments outside the viewing frustum) and culling (ignoring fragments occluded by closer objects) for the viewing position. Regarding clipping, the geometry processing stage 410 and/or the rasterization stage 420 may be configured to identify and ignore primitives that are outside the view frustum defined by the viewing position in the game world.

The pixel processing stage 430 uses the parameters created by the geometry processing stage and other data to generate values such as the resulting color of the pixel. In particular, processing stage 430 performs shading operations on the fragment at the pixels at its core to determine how the primitive's color and brightness change with available lighting. For example, pixel processing stage 430 may determine the depth, color, normal, and texture coordinates (eg, texture detail) of each fragment, and may further determine appropriate lightness, darkness, and color levels for the fragment. In particular, pixel processing stage 430 calculates characteristics of each segment, including color and other attributes (eg, z-depth represents distance from the viewing position, and alpha value represents transparency). Additionally, pixel processing stage 430 applies lighting effects to segments based on available lighting affecting the corresponding segment. Additionally, pixel processing stage 430 can apply shadow effects to each fragment.

The output of pixel processing stage 430 includes processed fragments (eg, texture and shading information) and is passed to output merging stage 440 in the next stage of graphics pipeline 400 . The output combining stage 440 uses the output of the pixel processing stage 430 and other data such as values already in memory to generate the final color for the pixel. For example, the output binning stage 440 may optionally blend the values between fragments and/or pixels determined from the pixel processing stage 430 with the values of the MRT that have been written to that pixel.

The color value for each pixel in the display may be stored in a frame buffer (not shown). These values are scanned into the corresponding pixels when the corresponding image of the scene is displayed. In particular, the display reads color values from each pixel's framebuffer row by row, left to right or right to left, top to bottom or bottom to top, or in any other pattern, and displays the image Use these pixel values to illuminate the pixels.

With the detailed description of the cloud gaming network 190 (eg, in the game server 160) and the GPU resources 365 of FIGS. 1-3, the flow diagram 500 of FIG. Interleaved screen areas pre-test geometry to implement graphics processing methods for multi-GPU rendering of geometry for image frames generated by an application. In this manner, multiple GPU resources are used to efficiently perform the rendering of objects while executing the application. As previously mentioned, various architectures may include multiple GPUs cooperating to render a single image by performing multi-GPU rendering of geometry for an application through zone testing at render time, such as within one or more cloud gaming servers of a cloud gaming system , or within a standalone system such as a personal computer or game console including a high-end graphics card with multiple GPUs, etc.

At 510, the method includes rendering graphics for the application using multiple graphics processing units (GPUs) that cooperate to generate the image. In particular, multi-GPU processing is performed when rendering a single image frame and/or each of one or more image frames in a sequence of image frames for real-time applications.

At 520, the method includes dividing responsibilities for rendering geometry of the graphics among multiple GPUs based on multiple screen areas. That is, each GPU has a corresponding division of responsibilities (e.g., corresponding screen area) known to all GPUs. More specifically, each GPU is responsible for rendering geometry in a corresponding set of screen areas of a plurality of screen areas, where the corresponding set of screen areas includes one or more screen areas. For example, a first GPU has a first division of responsibility for rendering objects in a first set of screen areas. Likewise, the second GPU has a second division of responsibility for rendering objects in a second set of screen areas. This is repeatable for the remaining GPUs.

At 530, the method includes allocating to the first GPU a first geometry of the image frame generated during execution of the application for geometry testing. For example, an image frame may include one or more objects, where each object may be defined by one or more geometric shapes. That is, in one embodiment, geometry pretesting and rendering is performed on one geometry as an entire object. In other embodiments, geometry pretesting and rendering is performed on one geometry that is part of the entire object.

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

At 540, the method includes performing geometry pretesting at the first GPU to generate information about how the geometry relates to the plurality of screen areas. In particular, the first GPU generates information about the geometry and how it relates to each of the multiple screen areas. For example, a geometry pretest by a first GPU may determine whether the geometry overlaps a specific screen area allocated to the corresponding GPU for object rendering. The first geometry may overlap with an area of the screen where the other GPU is responsible for object rendering, and/or may overlap with an area of the screen where the first GPU is responsible for object rendering. In one embodiment, before rendering of the geometry is performed by any of the plurality of GPUs, a geometry test is performed by the shader in the corresponding command buffer executed by the first GPU. In other embodiments, geometry testing is performed in hardware, such as in rasterization stage 420 of graphics pipeline 400 .

Geometry pretesting is typically performed in implementations by multiple GPUs simultaneously for all geometries of corresponding image frames. That is, each GPU performs geometry pretesting for its portion of the geometry corresponding to the image frame. In this way, GPU geometry pretesting allows each GPU to know which geometries to render and which to skip. In particular, when a corresponding GPU performs geometry pretesting, it tests its geometry portion against the screen area of each of the multiple GPUs used to render image frames. For example, if there are four GPUs, then each GPU can perform geometry testing on a quarter of the image frame geometry, especially if the geometry is evenly distributed to the GPUs for geometry testing. Therefore, although each GPU performs geometry pretests only for its geometry portion of the corresponding image frame, because geometry pretests are typically performed simultaneously across multiple GPUs in implementations for all geometries of an image frame, the resulting Information indicating how all geometries (e.g. geometries) in the image frame are related to the screen areas of all GPUs, where the screen areas are each assigned to the corresponding GPU for object rendering, and/or where rendering can be done on geometries (e.g. The entire object or part of the object) is executed.

At 550, the method includes using the information at each of the plurality of GPUs when rendering the geometry (eg, including rendering the geometry entirely or skipping rendering of the geometry). That is, the geometry is rendered using the information at each of multiple GPUs, where the test results (eg information) of the geometry are sent to the other GPUs such that the information is known to each GPU . For example, geometries (eg, multiple geometries) in an image frame are often rendered simultaneously by multiple GPUs in implementations. In particular, when a geometry overlaps any screen area allocated to the corresponding GPU for object rendering, that GPU will render the geometry based on that information. On the other hand, when the geometry does not overlap any screen area allocated to the corresponding GPU for object rendering, the GPU can skip rendering of the geometry based on this information. This information therefore allows all GPUs to more efficiently render the geometry in the image frame, and/or avoid rendering that geometry entirely. For example, rendering can be performed by shaders in corresponding command buffers executed by multiple GPUs. As will be described more fully below in Figures 7A, 12A, and 13A, shaders may be configured to perform one or both of geometry testing and/or rendering based on the corresponding GPU configuration.

According to one embodiment of the present disclosure, in some architectures, if a corresponding rendering GPU receives the corresponding information in time to use it, the GPU will use the information when deciding which geometry within the corresponding image to render. That is, this information can serve as a reminder. Otherwise, the rendering GPU will handle the geometry as usual. Using the example where the information may indicate whether the geometry overlaps any screen area assigned to the rendering GPU (eg, the second GPU), if the information indicates that the geometry does not overlap, the rendering GPU may skip rendering the geometry entirely. Furthermore, if only a plurality of the geometries do not overlap, the second GPU may skip rendering of at least those of the geometries that do not overlap with any screen area allocated to the second GPU for object rendering. On the other hand, this information can indicate that there is overlap of geometry, in which case the second GPU or rendering GPU will render the geometry. Likewise, this information may indicate that certain geometry overlaps any screen area allocated to the secondary GPU or rendering GPU for object rendering. In this case, the second GPU or rendering GPU will only render those overlapping geometries. In yet another embodiment, if the information is not available, or if the information is not generated or received in a timely manner, the second GPU will perform rendering normally (eg, rendering geometry). Therefore, the information provided as prompts can improve the overall efficiency of the graphics processing system if received in a timely manner. If the information is not received in a timely manner, the graphics processing system can still function normally without this information.

In one embodiment, one GPU (eg, the pretest GPU) is dedicated to performing geometry pretests to generate information. That is, the dedicated GPU is not used to render objects (such as geometry) in the corresponding image frame. Specifically, as mentioned earlier, multiple GPUs are used to render the app's graphics. Responsibility for rendering the geometry of a graphic is divided between multiple GPUs based on multiple screen areas that can be interleaved, with each GPU having a corresponding division of responsibilities known to multiple GPUs. Geometry testing is performed at the pre-test GPU on a plurality of geometries of image frames generated by the application to generate information about each geometry and its relationship to each of the plurality of screen areas. The plurality of geometries are rendered at each of the plurality of GPUs using information generated for each of the plurality of geometries. That is, this information is used when each of the geometries is rendered by a corresponding one of the GPUs used to render the image frame.

Figures 6A-6B show renderings of a screen subdivided into regions and sub-regions purely for illustrative purposes. It will be appreciated that the number of subdivided regions and/or sub-regions may be selected to enable efficient multi-GPU processing of an image and/or each of one or more images in a sequence of images. That is, the screen can be subdivided into two or more areas, each of which can be further divided into sub-areas. In one embodiment of the present disclosure, the screen is subdivided into four quadrants, as shown in Figure 6A. In another embodiment of the present disclosure, the screen is subdivided into a larger number of staggered areas, as shown in Figure 6B. The following discussion of Figures 6A-6B is intended to illustrate the inefficiencies that occur when performing multi-GPU rendering on multiple screen areas assigned to multiple GPUs; Figures 7A-7C and 8A-8B illustrate the More efficient rendering of some embodiments of the invention.

In particular, FIG. 6A is a schematic diagram of a screen 610A subdivided into quadrants (eg, four regions) when performing multi-GPU rendering. As shown, screen 610A is subdivided into four quadrants (eg, A, B, C, and D). Each quadrant is assigned to one of 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.

Geometry can be culled. For example, CPU 163 may examine the bounding box of each quadrant's frustum and request that each GPU render only objects that overlap with its corresponding frustum. The result is that each GPU is responsible for rendering only part of the geometry. For purposes of illustration, screen 610 shows geometric figures, each of which is a corresponding object, with screen 610 showing objects 611 - 617 (eg, geometric figures). GPU-A will render no objects because no objects overlap Quadrant A. GPU-B will render objects 615 and 616 (since part of object 615 exists in quadrant B, the CPU's culling test will correctly conclude that GPU-B must render it). GPU-C will render objects 611 and 612. GPU-D will render objects 612, 613, 614, 615 and 617.

In Figure 6A, when screen 610A is divided into quadrants A-D, the amount of work each GPU must perform may be very different because in some cases a disproportionate amount of geometry may be in one quadrant. For example, quadrant A does not have any geometric figures, while quadrant D has five geometric figures, or at least parts of five geometric figures. Therefore, GPU-A assigned to quadrant A will be idle, while GPU-D assigned to quadrant D will be extremely busy rendering objects in the corresponding image.

Figure 6B illustrates another technique when subdividing the screen into regions. In particular, screen 610B is not subdivided into quadrants, but into multiple interleaved regions when performing multi-GPU rendering on a single image or on each of one or more images in a sequence of images. In that case, screen 610B is subdivided into a larger number of interleaved areas (eg, greater than four quadrants) while using the same amount of GPU for rendering (eg, four). The objects (611-617) shown in screen 610A are also displayed in the same corresponding locations in screen 610B.

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

Furthermore, these areas are interlaced in specific patterns. Due to the interleaving of regions (and a greater number of regions), the amount of work each GPU has to perform may be more balanced. For example, the staggered pattern of screen 610B includes alternating rows including areas A-B-A-B, etc., and areas C-D-C-D, etc. Other modes of interleaving regions are supported in embodiments of the present disclosure. For example, a pattern may include a repeating sequence of regions, uniformly distributed regions, unevenly distributed regions, repeatable region sequence rows, random region sequence, random region sequence rows, etc.

The number of areas chosen is important. For example, if the distribution of regions is too fine (e.g., the number of regions is too large to optimize), each GPU will still have to process most or all of the geometry. For example, it can be difficult to check object bounding boxes against all areas that the GPU is responsible for. Furthermore, even if bounding boxes could be checked in time, due to the small region sizes, the result would be that each GPU would likely have to process a large portion of the geometry, since every object in the image overlaps with at least one region of each GPU (e.g., The GPU processes the entire object, even if only a portion of the object overlaps at least one region in a set of regions assigned to the GPU).

Therefore, it is important to choose the number of zones, staggering pattern, etc. Selecting too few or too many regions, or too few or too many regions for interleaving, or selecting an inefficient mode for interleaving can result in inefficiencies in performing GPU processing (e.g., each GPU processing geometry most or all). In these cases, although multiple GPUs are used to render the image, they are unable to support the corresponding increase in screen pixel count and geometry density due to GPU inefficiency (i.e. four GPUs cannot write four times the pixels and process four times the vertices or primitives). The following embodiments address improvements in the culling strategy (Figs. 7A-7C) and culling granularity (Figs. 8A-8B), as well as other advances.

7A-7C are schematic diagrams illustrating the use of multiple GPUs to render a single image and/or each of at least one or more images in a sequence of images, in embodiments of the present disclosure. Four GPUs were chosen purely for ease of illustration of multi-GPU rendering when rendering images while executing the application, and it is understood that in various implementations, any number of GPUs may be used for multi-GPU rendering.

In particular, FIG. 7A is a schematic diagram of a rendering command buffer 700A shared by multiple GPUs cooperating to render a single image frame, according to one embodiment of the present disclosure. That is, in this example, multiple GPUs each use the same render command buffer (eg, buffer 700A), and each GPU executes all commands in the render command buffer. Multiple commands (complete sets) are loaded into rendering command buffer 700A and used to render corresponding image frames. It can be appreciated that one or more rendering command buffers may be used to generate corresponding image frames. In one example, the CPU generates one or more draw calls for an image frame, wherein the draw calls include placement in one or more render command buffers for one or more GPUs of GPU resource 365 of FIG. 3 to execute the corresponding image. Command executed during multi-GPU rendering. In some implementations, CPU 163 may request one or more GPUs to generate all or some of the draw calls used to render the corresponding image. Additionally, the entire set of commands contained in rendering command buffer 700A may be shown in FIG. 7A , or FIG. 7A may show a portion of the entire set of commands contained in rendering command buffer 700A.

When performing multi-GPU rendering of each of one or more images in an image or sequence of images, the GPUs typically render simultaneously in implementations. The rendering of an image can be divided into multiple stages. During each stage, the GPUs need to be synchronized, so the faster GPU has to wait until the slower GPU completes. The commands for rendering command buffer 700A shown in Figure 7A illustrate one stage. Although commands for only one stage are shown in Figure 7A, the rendering command buffer 700A may include commands for one or more stages when rendering an image. Figure 7A only shows a portion of all commands, so Commands for other phases are not shown. In the rendering command buffer 700A shown in FIG. 7A illustrating one stage, there are four objects to be rendered (eg, object 0, object 1, object 2, and object 3), as shown in FIG. 7B-1 .

As shown, the rendering command buffer 700A shown in FIG. 7A includes commands for geometry testing, object (eg, geometry) rendering, and one or more commands for configuring the execution of commands from the rendering command buffer 700A. A command to render the state of the GPU. For purposes of illustration only, rendering command buffer 700A shown in FIG. 7A includes commands for geometry pretesting, rendering objects, and/or executing synchronous compute kernels when rendering corresponding images for corresponding applications (710- 728). In some embodiments, geometry pre-testing and execution of object rendering and/or synchronization calculation kernels for this image must be performed within one frame period. Two processing stages are shown in render command buffer 700A. In particular, processing segment 1 includes pre-testing or geometry testing 701 , and segment 2 includes rendering 702 .

Section 1 includes performing geometry testing 701 on objects in the image frame, where each object may be defined by one or more geometries. Pre-testing or geometry testing 701 may be performed by one or more shaders. For example, in one embodiment, each GPU used in a multi-GPU rendering of a corresponding image frame is assigned a portion of the geometry of the image frame to perform geometry testing, where each portion may be assigned for pre-testing. The allocated portion may include one or more geometries, where each geometry may include the entire object, or may include a portion of the object (eg, vertices, primitives, etc.). In particular, geometry testing is performed on a geometry to generate information about how the geometry relates to each of multiple screen areas. For example, a geometry test can determine whether a geometry overlaps a specific screen area allocated to the corresponding GPU for object rendering.

As shown in Figure 7A, Segment 1 geometry test 701 (eg, a pre-test of geometry) includes commands for configuring the state of one or more GPUs executing commands from rendering command buffer 700A, and for Command to perform geometry testing. In particular, the GPU state of each GPU is configured before the GPU performs geometry testing on the corresponding object. For example, commands 710, 713, and 715 are each used to configure the GPU state of one or more GPUs for execution of commands for geometry testing. As shown, command 710 configures the GPU state so that geometry test commands 711-712 can be executed correctly, where command 711 performs a geometry test on object 0, and command 712 performs a geometry test on object 1. Similarly, command 713 configures the GPU state so that geometry test command 714 can perform geometry testing on object 2. Likewise, command 715 configures the GPU state so that geometry test command 716 can perform geometry testing on object 3. It will be appreciated that the GPU state may be configured for one or more geometry test commands (eg, test commands 711 and 712).

As previously mentioned, when executing commands in rendering command buffer 700A for performing geometry testing and/or rendering objects for corresponding images and/or executing synchronous computing kernels, the values stored in the registers define the values used for the corresponding Hardware background of the GPU (e.g. GPU configuration). As shown, the GPU state may be modified throughout the processing of commands in rendering command buffer 700A, and each subsequent segment of the command may be used to configure the GPU state. As applied to Figure 7A, and as mentioned throughout this specification when setting the GPU state, the GPU state can be set in a variety of ways. For example, the CPU or GPU can set a value in random access memory (RAM), where the GPU will check the RAM for that value. In another example, the state may be internal to the GPU, such as when a command buffer is called twice as a subroutine, the internal GPU state is different between the two subroutine calls.

Segment 2 includes performing rendering 702 of objects in the image frame, where geometry is rendered). Rendering 702 may be performed by one or more shaders in command buffer 700A. As shown in Figure 7A, rendering 702 of segment 2 includes commands for configuring the state of one or more GPUs executing commands from rendering command buffer 700A, as well as commands for performing rendering. In particular, the GPU state of each GPU is configured before the GPU renders the corresponding object (such as geometry). For example, commands 721, 723, 725, and 727 are each used to configure the GPU state of one or more GPUs for execution of commands for rendering. As shown in the figure, 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; And command 727 configures the GPU state so that render command 728 can render object 3. Although FIG. 7A illustrates that the GPU state is configured for each rendering command (eg, render object 0, etc.), it should be understood that the GPU state may be configured for one or more rendering commands.

As mentioned before, each GPU used in the multi-GPU rendering of the corresponding image frame renders the corresponding geometry based on the information generated during the geometry pre-test. Specifically, information known to each GPU provides relationships between objects and screen areas. When rendering corresponding geometries, if this information is received in time, the GPU can use this information to render these geometries efficiently. Specifically, as the information indicates, a GPU performs rendering of a geometry when it overlaps any one or more screen areas allocated to the corresponding GPU for object rendering. On the other hand, this information may indicate that the first GPU should skip rendering the geometry entirely (eg, the geometry does not overlap with any screen area that the first GPU is assigned to be responsible for object rendering). In this way, each GPU only renders geometry that overlaps the screen area or areas for which it is responsible for object rendering. This way, this information is provided as a hint to each GPU such that if it is received before rendering begins, it is considered by each GPU that is performing rendering geometry. In one embodiment, if information is not received in time, rendering proceeds normally, such that the corresponding geometry is fully rendered by the corresponding GPU, regardless of whether the geometry overlaps any screen area allocated to the GPU for object rendering.

For illustration purposes only, the four GPUs divide the corresponding screen into the area between them. As mentioned before, each GPU is responsible for rendering objects in a corresponding set of regions, where a corresponding set includes one or more regions. In one embodiment, rendering command buffer 700A is shared by multiple GPUs collaborating to render a single image. That is, the GPUs for multi-GPU rendering of a single image or each of one or more images in a sequence of images share a common command buffer. In another embodiment, each GPU may have its own command buffer.

Alternatively, in yet another implementation, each GPU may be rendering slightly different sets of objects. This may occur when it can be determined that a particular GPU does not need to render a particular object because it does not overlap its corresponding screen area, such as in a corresponding set. Multiple GPUs can still use the same command buffer (e.g., share a command buffer), as long as the command buffer supports the ability for commands to be executed by one GPU but not the other, as mentioned previously. For example, execution of commands in shared rendering command buffer 700A may be limited to one of the rendering GPUs. This can be achieved in a number of ways. In another example, flags can be used on the corresponding command to indicate which GPUs should execute it. Likewise, prediction can be implemented using bits in the render command buffer to say which GPU is doing what under what conditions. Examples of predictions include - "If this is GPU-A, skip the following X commands".

In yet another embodiment, multiple GPUs may still use the same command buffer since each GPU is rendering substantially the same set of objects. For example, when the area is relatively small, each GPU can still render all objects, as mentioned earlier.

Figure 7B-1 illustrates screen 700B showing an image including four objects rendered by multiple GPUs using render command buffer 700A of Figure 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 for potentially interleaved screen areas before rendering the geometry corresponding to objects in the image frame.

In particular, geometry rendering responsibilities are divided between multiple GPUs via screen regions, where multiple screen regions are configured to reduce rendering time imbalances across multiple GPUs. For example, screen 700B shows each GPU's screen area responsibility in 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 on screen 700B. Screen 700B is more finely divided by quadrants than shown in Figure 6A in an effort to balance pixel and vertex load between the GPUs. Additionally, screen 700B is divided into areas that may be interleaved. For example, interleaving includes multi-line regions. Each of rows 731 and 733 includes area A alternating with area B. Each of rows 732 and 734 includes a region C alternating with a region D. More specifically, in one pattern, rows including areas A and B alternate with rows including areas C and D.

As mentioned before, in order to achieve GPU processing efficiency, various techniques can be used when dividing the screen into regions, such as increasing or decreasing the number of regions (e.g., choosing the right number of regions), interleaving regions, increasing or decreasing the number of regions for interleaving. number of regions, selecting a specific mode when interleaving regions and/or subregions, etc. In one embodiment, each of the plurality of screen areas is uniform in size. In one embodiment, each of the plurality of screen areas is not uniform in size. In yet another embodiment, the number and size of the multiple screen areas change dynamically.

Each of the GPUs is responsible for rendering objects in a corresponding set of regions, where each group can include one or more regions. Therefore, GPU-A is responsible for rendering objects in each A region in the corresponding group, GPU-B is responsible for rendering objects in each B region in the corresponding group, and GPU-C is responsible for rendering objects in each C region in the corresponding group. and GPU-D are responsible for rendering objects in each D region in the corresponding group. There may also be GPUs that have other responsibilities such that they may not be performing rendering (e.g. executing asynchronous compute kernels that execute over multiple frame cycles, performing culling for rendering GPUs, etc.).

For each GPU, the amount of rendering to be performed is different. Figure 7B-2 illustrates a table showing the rendering performed by each GPU when rendering the four objects of Figure 7B-1, according to one embodiment of the present disclosure. As shown in the table, after geometry pre-testing, it can 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 is rendered; and object 3 is rendered by GPU-B, GPU-C, and GPU-D. There may still be some imbalanced rendering because GPU A only needs to render object 2, while GPU D needs to render objects 1, 2, and 3. Overall, however, with the interleaving of screen areas, the rendering of objects within an image is reasonably balanced between the multiple GPUs used for the multi-GPU rendering of an image or the rendering of each of one or more images in a sequence of images.

Figure 7C is a schematic diagram illustrating the rendering of each object performed by each GPU when multiple GPUs collaborate to render a single image frame, such as image frame 700B shown in Figure 7B-1, in accordance with one embodiment of the present disclosure. . In particular, Figure 7C illustrates object 0- executed by each of four GPUs (eg, GPU-A, GPU-B, GPU-C, and GPU-D) using the shared render command buffer 700A of Figure 7A 3 rendering process.

In particular, two rendering timing diagrams are shown relative to timeline 740 . Rendering timing diagram 700C-1 shows multi-GPU rendering of object 0-3 of the corresponding image in one rendering stage, where each GPU does not have any information about the overlap between object 0-3 and the screen area. Perform rendering. Rendering timing diagram 700C-2 illustrates a multi-GPU rendering of objects 0-3 of a corresponding image in the same rendering phase, where the information generated during geometry testing of the screen area (e.g., performed prior to rendering) is consistent with the information used to pass the corresponding The GPU pipeline renders objects 0-3 shared by each GPU. Rendering timing diagrams 700C-1 and 700C-2 each illustrate the time it takes for each GPU to process each geometry (eg, perform geometry testing and rendering). In one embodiment, a geometry is a complete object. In another embodiment, a geometric figure may be part of an object. For purposes of illustration, the example of Figure 7C shows a rendering of geometric figures, where each geometric figure corresponds to an object (eg, its entirety). In each of rendering timing diagrams 700C-1 and 700C-2, there is no geometry (e.g., primitives of an object) that overlaps at least one screen area of the corresponding GPU (e.g., in a corresponding set of areas). Objects (such as geometric figures) are represented by boxes drawn with dashed lines. On the other hand, objects with geometry that overlap at least one screen area of the corresponding GPU (eg, in a corresponding set of areas) are represented by boxes drawn with solid lines.

Rendering timing diagram 700C-1 shows rendering of objects 0-3 using four GPUs (eg, GPU-A, GPU-B, GPU-C, and GPU-D). Vertical line 755a indicates the beginning of the object's rendering phase, while vertical line 755b illustrates the end of the object's rendering phase in rendering timing diagram 700C-1. The illustrated start and end points of the rendering stages along timeline 740 represent synchronization points where each of the four GPUs is synchronized in executing the corresponding GPU pipeline. For example, at vertical line 755b indicating the end of the rendering phase, all GPUs must wait for the slowest GPU (e.g., GPU-B) to complete the rendering of objects 0-3 through the corresponding graphics pipeline before entering the next rendering phase.

Geometry pretesting is not performed in render timing diagram 700C-1. Therefore, each GPU must process each object through the corresponding graphics pipeline. If there are no pixels to be drawn for the object in any area allocated to the corresponding GPU for object rendering (for example, in the corresponding group), the GPU may not be able to fully render the object through the graphics pipeline. For example, when objects do not overlap, only the geometry processing stage of the graphics pipeline is executed. However, this still takes some time to process.

In particular, GPU-A will not fully render objects 0, 1, and 3 because they do not overlap with any screen area allocated to GPU-A for object rendering (e.g., in the corresponding group). Renderings of these three objects are shown in dashed boxes, indicating that at least the geometry processing stage was executed, but the graphics pipeline was not fully executed. GPU-A renders object 2 entirely because the object overlaps at least one of the screen areas allocated to GPU-A for rendering. The rendering of object 2 is shown in a solid box, indicating that all stages of the corresponding graphics pipeline are executed. Similarly, GPU-B does not completely render object 1 (shown with a dashed box) (i.e. performs at least the geometry processing level), but does fully render objects 0, 2, and 3 (shown with a solid box) because those The object overlaps at least one screen area allocated to GPU-B for rendering (eg, in the corresponding group). Likewise, GPU-C does not fully render objects 0 and 2 (shown with dashed boxes) (i.e., performs at least the geometry processing level), but does fully render objects (shown with solid boxes) because those objects are different from those assigned to At least one screen area used by GPU-C for rendering (eg, in corresponding groups) overlaps. Further, GPU-D will not fully render object 0 (shown with a dashed box) (i.e., perform at least one geometry processing stage), but will fully render objects 1, 2, and 3 (shown with a solid box) because those objects Overlaps with at least one screen area allocated to GPU-D for rendering (e.g., in the corresponding group).

Rendering timing diagram 700C-2 shows geometry pre-testing 701' and rendering 702' of object 0-3 using multiple GPUs. Vertical line 750a indicates the beginning of the rendering phase of the object (eg, including geometry pretesting and rendering), while vertical line 750b illustrates the end of the rendering phase of the object in rendering timing diagram 700C-2. The start and end points along timeline 740 of the rendering phase shown in timing diagram 700C-2 represent synchronization points where each of the four GPUs is synchronized in executing the corresponding GPU pipeline, as previously described. For example, at vertical line 750b indicating the end of the rendering stage, all GPUs must wait for the slowest GPU (e.g., GPU-B) to complete the rendering of objects 0-3 through the corresponding graphics pipeline before entering the next rendering stage.

First, the geometry pretest 701' is performed by the GPUs, where each GPU performs the geometry pretest for a geometry subset of the image frame for all screen areas, where each screen area is assigned to a corresponding GPU for object rendering. As mentioned before, each GPU is assigned to a corresponding part of the geometry associated with the image frame. The geometry pretest generates information about how a particular geometry relates to each screen area, such as whether the geometry overlaps any screen area (eg, in a corresponding group) assigned to the corresponding GPU for object rendering. This information is shared with each GPU used to render the image frame. For example, geometry pretest 701' shown in Figure 7C includes having GPU-A perform a geometry pretest on object 0, GPU-B performing a geometry pretest on object 1, and GPU-C performing a geometry pretest on object 2. Graphics pretest, and let GPU-D perform geometry pretest on object 3. Depending on the object being tested, the time it takes to perform the geometry pretest may vary. For example, a geometry pretest for object 0 takes less time than a geometry pretest for object 1. This may be due to object size, amount of overlapping screen area, etc.

After the geometry pretest, each GPU performs rendering of all objects or geometry that intersects its screen area. In one embodiment, each GPU begins rendering its geometry once geometry testing is complete. That is, there is no synchronization point between geometry testing and 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 completes geometry pretesting of object 1 and therefore before GPU-B starts rendering objects 0, 2, and 3.

Vertical line 750a is aligned with vertical line 755a such that each of rendering timing diagrams 700C-1 and 700C-2 begins rendering object 0-1 at the same time. However, the rendering of object 0-3 shown in rendering timing diagram 700C-2 is performed in a shorter time than the rendering shown in rendering timing diagram 700C-1. That is, vertical line 750b indicating the end of the rendering phase of lower timing diagram 700C-2 occurs earlier than the end of the rendering phase of upper timing diagram 700C-1 as indicated by vertical line 755b. Specifically, render objects 0-3 are implemented when performing multi-GPU rendering of an image's geometry for an application, including pre-testing the geometry for a screen area before rendering and providing the results of the geometry pre-testing as information (e.g., a hint). The speed is increased by 745. As shown, velocity increase 745 is the time difference between vertical line 750b of timing diagram 700C-2 and vertical line 755b of timing diagram 700C-1.

Increased speed is achieved through the generation and sharing of information generated during geometry pretesting. For example, during geometry pretest, GPU-A generates information indicating that object 0 only needs to be rendered by GPU-B. Therefore, GPU-B is told that it should render object 0, while other GPUs (such as GPU-A, GPU-C, and GPU-D) can skip the rendering of object 0 entirely because object 0 is not the same as those assigned to these GPUs for Any areas where objects are rendered (such as within corresponding groups) overlap. For example, these GPUs are not required to perform the geometry processing stage, and without geometry pretest, these GPUs will process this stage even though they will not fully render object 0, as shown in timing diagram 700C-1. Likewise, during the geometry pretest, GPU-B generates information indicating that object 1 should be rendered by GPU-C and GPU-D and that GPU-A and GPU-B can skip rendering of object 1 entirely because object 1 is not related to Any areas assigned to GPU-A or GPU-B for object rendering (e.g., within their respective groups) overlap. Likewise, during the geometry pretest, GPU-C generates information indicating that object 2 should be rendered by GPU-A, GPU-B, and GPU-D and that GPU-C can skip rendering of object 2 entirely because object 2 is not related to Any regions allocated to GPU-C for object rendering (e.g., within corresponding groups) overlap. Further, during the geometry pretest, GPU-D generates information indicating that object 3 should be rendered by GPU-B, GPU-C, and GPU-D and that GPU-A can skip the rendering of object 3 entirely because object 3 is not related to Any regions allocated to GPU-A for object rendering (e.g., within corresponding groups) overlap.

Because the information generated by the geometry pretest is shared between GPUs, each GPU can determine which objects to render. Therefore, after performing a geometry pretest and sharing the test results with all GPUs, each GPU has information about which objects or geometries need to be rendered by the corresponding GPU. 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.

Specifically, GPU A performs geometry processing on Object 1 and determines that Object 1 can be skipped by GPU-B because Object 1 is not associated with any region allocated to GPU-B for object rendering (e.g., in the corresponding group) overlapping. Furthermore, Object 1 is not fully rendered by GPU-A because it does not overlap with any area allocated to GPU-A for object rendering (e.g., in the corresponding group). Since it is determined that Object 1 does not overlap any area assigned to GPU-B before GPU-B begins geometry processing on Object 1, GPU-B skips rendering of Object 1.

8A-8B illustrate object testing for screen areas 820A and 820B, where the screen areas may be interleaved (eg, screen areas 820A and 820B show a portion of a display). In particular, multi-GPU rendering of an object is performed on a single image frame or on each of one or more image frames in a sequence of image frames by performing geometry testing before rendering the object in the screen. As shown, GPU-A is assigned the responsibility of rendering objects in screen area 820A. GPU-B is assigned the responsibility of rendering objects in screen area 820B. Generates information for "geometry", where the geometry can be an entire object or a portion of an object. For example, a geometric shape may be an object 810, or a portion of an object 810.

Figure 8A illustrates object testing for screen area when multiple GPUs collaborate to render a single image, according to one embodiment of the present disclosure. As mentioned before, the geometry can be an object such that the geometry corresponds to the geometry used or generated by the corresponding draw call. During the geometry pre-test, it may be determined that object 810 overlaps area 820A. That is, portion 810A of object 810 overlaps area 820A. In this case, GPU-A is tasked with rendering object 810 . Likewise, during geometry pre-testing, it may be determined that object 810 overlaps region 820B. That is, portion 810B of object 810 overlaps area 820B. In this case, GPU-B is also tasked with rendering object 810.

8B illustrates testing of portions of an object of a screen region and/or a screen sub-region when multiple GPUs collaborate to render a single image frame, in accordance with one embodiment of the present disclosure. That is, geometry can be part of an object. For example, object 810 may be split into multiples such that the geometry used or generated by the draw call is subdivided into smaller geometries. In one embodiment, each of the geometries is approximately the size of the allocated location cache and/or parameter cache. In that case, information (such as one or more hints) is generated for those smaller geometries during geometry testing, where this information is used by the rendering GPU, as described previously.

For example, object 810 is segmented into smaller objects such that the geometry used for area testing corresponds to these smaller objects. As shown, object 810 is segmented into geometric shapes "a", "b", "c", "d", "e" and "f". After the geometry pretest, GPU-A only renders geometries "a", "b", "c", "d" and "e". That is, GPU-A can skip rendering geometry "f". Furthermore, after the geometry pre-test, GPU-B only renders geometries "d", "e" and "f". That is, GPU-B can skip rendering geometries "a", "b", and "c".

In one embodiment, since the geometry processing stage is configured to perform both vertex processing and primitive processing, it is possible to perform geometry pretesting on one geometry using a shader in the geometry processing stage. For example, the geometry processing stage generates information (eg, hints), such as by testing the bounding frustum of the geometry against the GPU screen area, which may be performed by a software shader operation. In one embodiment, the test is accelerated through the use of dedicated instructions or instructions implemented through hardware, thereby implementing a software/hardware solution. That is, one or more specialized instructions are used to accelerate the generation of information about the geometry and its relationship to the screen area. For example, the homogeneous coordinates of the vertices of a geometry's primitives are provided as input to the geometry pretest instructions of the geometry processing stage. This test can generate a Boolean return value for each GPU that indicates whether the primitive overlaps any screen area assigned to that GPU for object rendering (for example, in the corresponding group). In this way, the information (such as hints) generated during geometry pretesting about the corresponding geometry and its relationship to the screen area is generated by the shader in the geometry processing stage.

In another embodiment, geometry pretesting of a geometry may be performed at the hardware rasterization level. For example, a hardware scan converter may be configured to perform geometry pretesting such that the scan converter generates information about all screen areas allocated to multiple GPUs for object rendering of corresponding image frames.

In yet another embodiment, the geometries may be primitives. That is, parts of the object used for geometry pretesting can be primitives. Thus, information (e.g., hints) generated by one GPU during geometry pretest indicates whether individual triangles (e.g., representation primitives) need to be rendered by another rendering GPU.

In one embodiment, information generated during geometry pretesting and shared by the GPUs used for rendering includes the number of primitives that overlap any screen area (eg, in the corresponding group) assigned to the corresponding GPU for object rendering. (e.g. surviving primitive count). This information can also include the number of vertices used to build or define these primitives. That is, the information includes surviving vertex counts. Therefore, when rendering, the corresponding rendering GPU can use the provided vertex count to allocate space in the position cache and parameter cache. For example, in one embodiment, unnecessary vertices do not have any allocated space, which can improve rendering efficiency.

In other embodiments, the information (eg, hints) generated during the geometry pretest includes specific primitives that overlap (eg, as an exact match) any screen area (eg, in the corresponding group) assigned to the corresponding GPU for object rendering. of surviving primitives). That is, the information generated by the rendering GPU includes a specific set of primitives used for rendering. This information can also include the specific vertices used to build or define these primitives. That is, the information generated by the rendering GPU includes a specific set of vertices used for rendering. For example, this information can save other rendering GPU time during its geometry processing stage when rendering geometry.

In other embodiments, there may be processing overhead (software or hardware) associated with generating information during geometry testing. In this case, it may be beneficial to skip generating information for certain geometries. That is, the information provided as a hint is generated for some objects but not for others. For example, geometry (eg, an object or a portion of an object) that represents a skybox or a large swath of terrain may include large triangles. In this case, each GPU used for multi-GPU rendering of the image frame or each of one or more image frames in the sequence of image frames may need to render these geometries. That is, information may or may not be generated depending on the properties of the corresponding geometric figure.

9A-9C illustrate various strategies for allocating screen areas to corresponding GPUs when multiple GPUs collaborate to render a single image, according to one embodiment of the present disclosure. To achieve GPU processing efficiency, various techniques can be used when dividing the screen into regions, such as increasing or decreasing the number of regions (e.g., choosing the right amount of regions), interleaving regions, increasing or decreasing the number of regions used for interleaving, Select specific modes when interleaving areas, etc. For example, multiple GPUs are configured to perform multi-GPU rendering of geometry for image frames generated by the application by pre-testing the geometry for interleaved screen areas before rendering objects in the corresponding images. The configuration of the screen areas in Figures 9A-9C is designed to reduce any rendering time imbalance between multiple GPUs. The complexity of the test (e.g. overlapping corresponding screen areas) varies depending on how the screen area is allocated to the GPU. As shown in the schematic diagrams shown in Figures 9A-9C, the bold box 910 is the outline of the corresponding screen or display used in rendering the image.

In one embodiment, the multiple screen areas or each of the multiple areas have a uniform size. In one embodiment, each of the plurality of screen areas is not uniform in size. In yet another embodiment, the number and size of the screen areas in the plurality of screen areas dynamically change.

In particular, FIG. 9A illustrates a simple mode 900A of screen 910. Each screen area is uniform in size. For example, the size of each region may be a rectangle with dimensions that are powers of 2 pixels. For example, each area might be 256x256 pixels in size. As shown in the figure, the zone allocation is a checkerboard pattern in which one row of A and B zones alternates with another row of B and C zones. Pattern 900A can be easily tested during geometry pre-testing. However, there may be some rendering inefficiencies. For example, the screen area allocated to each GPU is substantially different (i.e., screen area C and area D have smaller coverage in screen 910), which may result in an imbalance in the rendering time of each GPU.

FIG. 9B illustrates a pattern 900B of screen area of screen 910. Each screen or subarea is uniformly sized. Screen areas are allocated and distributed to reduce imbalances in rendering times between GPUs. For example, allocating GPUs to screen areas in mode 900B results in a nearly equal amount of screen pixels being allocated to each GPU across screen 910 . That is, the screen area is allocated to the GPU to equalize the screen area or coverage in screen 910 . For example, if the size of each area might be 256x256 pixels, each area would have approximately the same coverage in screen 910. Specifically, a set of screen areas A covers an area of 6x256x256 pixels, a set of screen areas B covers an area of 5.75x256x256 pixels, a set of screen areas C covers an area of 5.5x256x256 pixels, and a set of screen areas D Covers an area of 5.5x256x256 pixels.

9C illustrates a pattern 900C of screen area of screen 910. Each screen area is not uniformly sized. That is, the area of the screen allocated to the GPU for rendering objects may not be uniformly sized. In particular, screen 910 is divided so that each GPU is assigned the same number of pixels. For example, if a 4K monitor (3840x2160) is divided vertically into four areas, each area will be 520 pixels tall. However, typically GPUs perform many operations in 32x32 pixel blocks, and 520 pixels is not a multiple of 32 pixels. Thus, in one embodiment, pattern 900C may include a block with a height of 512 pixels (a multiple of 32), and other blocks with a height of 544 pixels (also a multiple of 32). Other implementations may use different sized blocks. Mode 900C shows an equal amount of screen pixels allocated to each GPU by using non-uniform screen areas.

In yet another embodiment, the application's needs in performing image rendering change over time, and the screen area is dynamically selected. For example, if it is known that most of the rendering time is spent in the lower half of the screen, it is advantageous to allocate the area in such a way that an almost equal amount of screen pixels in the lower half of the display is allocated for rendering the corresponding image of each GPU. That is, the area allocated to each GPU for rendering the corresponding image can dynamically change. For example, changes can be applied based on game mode, different games, screen size, mode selected for the region, etc.

Figure 10 is a schematic diagram illustrating various distributions of GPU-to-geometry allocations for performing geometry pre-testing in accordance with one embodiment of the present disclosure. That is, Figure 10 shows the distribution of responsibilities for generating information during geometry pre-testing across multiple GPUs. As mentioned before, each GPU is assigned to a corresponding portion of the image frame's geometry, where that portion can be further divided into objects, parts of objects, geometries, multiple geometries, etc. Geometry pre-testing involves determining whether a particular geometry overlaps any screen area or areas allocated to the corresponding GPU for object rendering. Geometry pre-testing is typically performed in implementations by the GPU for all geometries (eg, all geometries) of the corresponding image frame simultaneously. In this way, geometry testing is performed collaboratively by the GPUs, allowing each GPU to know which geometries to render, and which geometries to skip rendering, as described previously.

As shown in Figure 10, each geometric figure can be an object, a part of an object, etc. For example, the geometry may be part of an object, such that the size of the geometry is approximately the size of the allocated location cache and/or parameter cache, as previously described. Purely for illustration, object 0 (eg, specified for rendering by command 722 in render command buffer 700A) is split into geometries "a", "b", "c", "d", "e", and "f" , such as object 810 in Figure 8B. Likewise, object 1 (eg, specified for rendering by command 724 in render command buffer 700A) is split into geometries "g", "h", and "i". Additionally, object 2 (eg, specified for rendering by command 724 in render command buffer 700A) is split into geometries "j", "k", "l", "m", "n", and "o". To distribute the responsibility for geometry testing to the GPU, the geometries can be ordered (e.g., a-o).

Distribution 1010 (eg, row ABCDABCDABCD...) shows an even distribution of responsibility for performing geometry testing across multiple GPUs. In particular, instead of having one GPU occupy the first quarter of the geometry (e.g. in a block, such as GPU A occupies the first four of approximately 16, including "a", "b", "c" and "d" for geometry testing), and the second GPU takes the second quarter, and so on, with allocations to the GPUs being staggered. That is, contiguous geometries are assigned to different GPUs. For example, geometry "a" is assigned to GPU-A, geometry "b" is assigned to GPU-B, geometry "c" is assigned to GPU-C, geometry "d" is assigned to GPU-D, geometry "e" ” is assigned to GPU-A, geometry “f” is assigned to GPU-B, geometry “g” is assigned to GPU-C, and so on. As a result, processing of geometry tests is roughly balanced between GPUs (eg, GPU-A, GPU-B, GPU-C, and GPU-D).

Distribution 1020 (eg row ABBCDABBCDABBCD...) shows an asymmetric distribution of responsibility for performing geometry testing across multiple GPUs. Asymmetric distribution can be advantageous when some GPUs have more time than other GPUs to perform geometry tests while rendering corresponding image frames. For example, one GPU may have completed object rendering for the previous frame or frames of the scene earlier than the other GPUs, and therefore (because it is expected to complete this frame earlier too) it may be allocated more geometry to use. For performing geometry tests. Likewise, allocation to GPUs is staggered. As shown in the figure, GPU-B is allocated more geometry than other GPUs for geometry pre-testing. For example, geometry "a" is assigned to GPU-A, geometry "b" is assigned to GPU-B, geometry "c" is also assigned to GPU-B, geometry "d" is assigned to GPU-C, geometry Geometry "e" is assigned to GPU-D, geometry "f" is assigned to GPU-A, geometry "g" is assigned to GPU-B, geometry "h" is also assigned to GPU-B, geometry "i" is assigned To GPU-C etc. Although the distribution of geometry testing to GPUs may be unbalanced, the combined processing of complete stages (e.g., geometry pretest and geometry rendering) may end up being roughly balanced (e.g., each GPU takes approximately the same amount of time to perform Geometry pretesting and geometry rendering).

11A-11B illustrate the use of statistics for one or more image frames when distributing responsibility for performing geometry testing among multiple GPUs. For example, based on statistics, some GPUs can process more or less geometry during geometry testing to generate information that is useful when rendering.

In particular, FIG. 11A is a diagram illustrating geometry pre-testing and rendering of a previous image frame by multiple GPUs and using statistics collected during rendering to affect the current image frame, in accordance with one embodiment of the present disclosure. Illustration of a pre-test distribution of the geometry of the current image frame to multiple GPUs. Purely for illustration, in the second frame 1100B of Figure 11A, GPU-B processes twice as much geometry (eg, during pre-testing) as the other GPUs (eg, GPU-A, GPU-C, and GPU-D). The distribution and allocation of more geometries to GPU-B to perform geometry pretesting in the current image frame is based on statistics collected during the rendering of the previous image frame or several image frames.

For example, timing diagram 1100A shows geometry pretest 701A and rendering 702A for a previous image frame, with four GPUs (eg, GPU-A, GPU-B, GPU-C, and GPU-D) used for both processes. . The distribution of geometry (e.g., multiple geometries) from the previous image frame is evenly distributed between GPUs. This is shown by the roughly balanced performance of each GPU on the Geometry Pretest 701A.

Rendering statistics collected from one or more image frames can be used to determine how to perform geometry testing and rendering of the current image frame. That is, the statistical data may be provided as information used when performing geometry testing and rendering of subsequent image frames (eg, the current image frame). For example, statistics collected during the rendering of an object (such as geometry) from the previous image frame may indicate that GPU-B completed the rendering earlier than the other GPUs. In particular, GPU-B has an idle time 1130A after rendering its portion of the geometry that overlaps any screen area assigned to GPU-B for object rendering (eg, in the corresponding group). Each of the other GPU-A, GPU-C, and GPU-D performs rendering approximately until the end of the corresponding frame period of the previous image frame 710.

When the application is executed, the previous image frame and the current image frame can be generated for a specific scene. Therefore, objects may be roughly similar in number and location from one scene to another. In this case, the time it takes for the GPU to perform geometry pretesting and rendering will be similar between multiple image frames in the image frame sequence. That is, it is reasonable to speculate based on statistical data that GPU-B will also have idle time while performing geometry testing and rendering in the current image frame. Therefore, GPU-B can be allocated more geometries for geometry pre-testing in the current frame. For example, by having GPU-B process more geometry during the geometry pretest, the result is that GPU-B finishes rendering the objects in the current image frame in roughly the same time as the other GPUs. That is, each of GPU-A, GPU-B, GPU-C, and GPU-D performs rendering approximately until 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 reduced such that it takes less time to render the current image frame when rendering statistics are used. Accordingly, the statistics of the rendering of the previous frame and/or multiple previous frames may be used to adjust the geometry pretest, such as the distribution of geometry (eg, multiple geometries) across GPUs in the current image frame.

11B is a flowchart 1100B illustrating a graphics processing method including geometry pre-testing and rendering of a previous image frame by multiple GPUs and use in a current image frame during rendering, in accordance with one embodiment of the present disclosure. Statistics collected to influence pre-test distribution of the geometry of the current image frame to multiple GPUs. FIG. 11A is a schematic diagram illustrating the use of statistics in the method of flowchart 1100B to determine distribution of geometry (eg, multiple geometries) allocations among GPUs for image frames. As mentioned previously, various architectures may include multiple GPUs cooperating to render a single image by performing multi-GPU rendering of geometry for an application, such as within one or more cloud gaming servers of a cloud gaming system, or within a stand-alone system ( Such as within a personal computer or gaming console including a high-end graphics card with multiple GPUs, etc.

In particular, at 1110, the method includes using multiple GPUs to render graphics for the application, as previously described. At 1120, the method includes dividing responsibilities for rendering geometry of the graphics among multiple GPUs based on multiple screen areas. Each GPU has a corresponding division of responsibilities known to multiple GPUs. More specifically, each GPU is responsible for rendering geometry in a corresponding set of screen areas of a plurality of screen areas, where the corresponding set of screen areas includes one or more screen areas, as previously described. In one embodiment, the screen areas are interleaved (eg, when the display is divided into sets of screen areas for geometry pre-testing and rendering).

At 1130, the method includes rendering, at the plurality of GPUs, a first plurality of geometries of a previous image frame generated by the application. For example, timing diagram 1100A illustrates the timing of performing geometry testing of geometry in a previous image frame and rendering of an object (eg, geometry). At 1140, the method includes generating statistics for the rendering of the previous image frame. That is, statistics can be collected while rendering the previous image frame.

At 1150 , the method includes allocating a second plurality of geometries of the current image frame generated by the application to a plurality of GPUs for geometry testing based on the statistics. That is, these statistics can be used to assign the same, less, or more geometry used for geometry testing to a specific GPU when rendering the next or current image frame. In some cases, statistics may indicate that geometries in the second plurality of geometries should be distributed evenly across multiple GPUs when performing geometry testing.

In other cases, statistics may indicate that geometries in the second plurality of geometries should be distributed non-uniformly across multiple GPUs when performing geometry testing. For example, as shown in timeline 1100A, statistics may indicate that GPU-B completed rendering before any other GPU in the previous image frame. In particular, it may be determined that the first GPU (eg, GPU-B) completes rendering the first plurality of geometries (eg, a portion of the geometry) before the second GPU (eg, GPU-A) completes rendering the first plurality of geometries (eg, a portion of the geometry). As previously described, the first GPU (e.g., GPU-B) renders one or more geometries of the first plurality of geometries that overlap with any screen area allocated to the first GPU for object rendering, and the second GPU (eg, GPU-A) renders one or more geometries of the first plurality of geometries that overlap any screen area allocated to the second GPU for object rendering. Therefore, because it is expected based on statistics that the first GPU (e.g. GPU-B) will take less time to render the second plurality of geometries than the second GPU (e.g. GPU-A), more geometries can be rendered in The current image frame is assigned to the first GPU for geometry pre-testing. For example, a first number of a second plurality of geometries may be assigned to a first GPU (eg, GPU-B) for geometry testing, and a second number of a second plurality of geometries may be assigned to a second GPU (e.g., GPU-B) For example, GPU-A) is used for geometry testing where the first quantity is higher than the second quantity (GPU-A may not be assigned any geometry at all if the temporal imbalance is large enough). In this way, GPU-B processes more geometry than GPU-A during the geometry test. For example, timing diagram 1100B shows that GPU-B has been allocated more geometry and is spending more time performing geometry tests than the other GPUs.

At 1160 , the method includes performing a geometry pretest on the second plurality of geometries at the current image frame to generate information about each of the second plurality of geometries and their relationship to each of the plurality of screen areas. Information. Geometry pretesting is performed at each of multiple GPUs based on allocation. Geometry pretesting is performed at the pretest GPU on a plurality of geometries of image frames generated by the application to generate information about each geometry and its relationship to each of the plurality of screen areas.

At 1170 , the method includes using the information generated for each of the second plurality of geometries to render the plurality of geometries during a rendering stage (e.g., including fully rendering the geometry at the corresponding GPU or skipping the rendering). In implementations, rendering is typically performed simultaneously at each GPU. In particular, multiple geometries of the current image frame are rendered at each of multiple GPUs using information generated for each of the geometries.

In other embodiments, the distribution of geometry to the GPU for generating information is dynamically adjusted. That is, the allocation of geometry for the current image frame used to perform geometry pretesting can be dynamically adjusted during the rendering of the current image frame. For example, in the example of timing diagram 1100B, it may be determined that GPU-A is performing geometry pretesting on its assigned geometry at a slower rate than expected. Therefore, geometry assigned to GPU-A for geometry pretesting can be reassigned on the fly, such as reassigning a geometry from GPU-A to GPU-B, so that GPU-B is now tasked with rendering the current A geometry pretest is performed on this geometry during the frame period of the image frame.

Figures 12A-12B illustrate another strategy for handling the render command buffer. Previously, a strategy was described with reference to Figures 7A-7C, in which a command buffer contains commands for geometry pre-testing of an object (eg, geometry), followed by commands for rendering the object (eg, geometry). Figures 12A-12B illustrate geometry pre-testing and rendering strategies using shaders capable of performing either operation depending on the GPU configuration.

In particular, FIG. 12A is an illustration of a shader configured to perform both pre-testing and rendering of the geometry of an image frame in two passes through a portion of command buffer 1200A, in accordance with one embodiment of the present disclosure. Schematic diagram used. That is, a shader used to execute commands in command buffer 1200A may be configured to perform geometry pretesting when properly configured, or to perform rendering when properly configured.

As shown, the portion of command buffer 1200A shown in Figure 12A is executed twice, with each execution resulting in a different action; the first execution results in execution of the geometry pretest, while the second execution results in execution of the geometry render. This can be accomplished in a number of ways, for example, the portion of the command buffer described in 1200A can be explicitly called twice as a subroutine, with different states (e.g., register settings or values in RAM) before each call Explicitly set to a different value. Alternatively, the portion of the command buffer described in 1200A may be implicitly executed twice, such as by using special commands to mark the beginning and end of the portion to execute twice, and for the first and end of the portion of the command buffer. The second execution implicitly sets a different configuration (e.g. register settings). When a command in portion of command buffer 1200A is executed (e.g., a command to set state or a command to execute a shader), the result of the command is different based on the GPU state (e.g., causing a geometry pretest to be performed versus performing a render ). That is, the commands in command buffer 1200A may be configured for geometry pretesting or rendering. In particular, portions of command buffer 1200A include commands for configuring the state of one or more GPUs that execute commands from rendering command buffer 1200A, and for performing shaders that perform geometry pretesting or rendering depending on the state. The command. For example, commands 1210, 1212, 1214, and 1216 are each used to configure the state of one or more GPUs to execute shaders that perform geometry pretesting or rendering depending on the state. As shown, command 1210 configures the GPU state so that shader 0 can execute via command 1211 and perform geometry pretesting or rendering. Likewise, command 1212 configures the GPU state so that shader 1 can be executed via command 1213 to perform geometry pretesting or rendering. Additionally, command 1214 configures the GPU state so that shader 2 can be executed via command 1215 to perform geometry pretesting or rendering. Finally, command 1216 configures the GPU state so that shader 3 can be executed via command 1217 to perform geometry pretesting or rendering.

On the first pass 1291 through the command buffer 1200A, based on the GPU state explicitly or implicitly set as described above and the GPU state configured by commands 1210, 1212, 1214, and 1216, the corresponding shader performs geometry pre-processing. test. For example, shader 0 is configured to perform geometry pretesting (e.g., based on the object shown in Figure 7B-1) on object 0 (e.g., a geometry), and shader 1 is configured to perform geometry on object 1 Pretest, shader 2 is configured to perform geometry pretest on object 2, and shader 3 is configured to perform geometry pretest on object 3.

In one embodiment, commands may be skipped or interpreted differently based on GPU status. For example, certain commands that set the state (parts of 1210, 1212, 1214, and 1216) may be skipped based on the GPU state being explicitly or implicitly set as described above; for example, if shader 0 is configured to be executed via command 1210 If less GPU state is required to be configured for geometry pretesting than is required when configuring for geometry rendering, it may be beneficial to skip the unnecessary portion of setting the GPU state since GPU state setting incurs overhead. As another example, certain commands that set state (parts of 1210, 1212, 1214, and 1216) may be interpreted differently based on the GPU state being explicitly or implicitly set as described above; for example, if executed via command 1210 Shader 0 requires a different GPU state configured for geometry pretesting than when configured for geometry rendering, or if Shader0 executed via command 1210 requires different inputs for geometry pretesting than for geometry rendering.

In one embodiment, shaders configured for geometry pretest do not allocate space in the position cache and parameter cache, as previously described. In another embodiment, a single shader is used to perform pretesting or rendering. This can be done in a variety of ways, such as via external hardware state that the shader can inspect (e.g., set explicitly or implicitly as described above), or via input to the shader (e.g., via the command buffer in the first command settings that are interpreted differently in the first and second passes).

In the second pass 1292 through the command buffer 1200A, the corresponding shader executes the corresponding image based on the GPU state explicitly or implicitly set as described above, and the GPU state configured by commands 1210, 1212, 1214, and 1216 Rendering of frame geometry. For example, shader 0 is configured to perform rendering of object 0 (eg, a geometry) (eg, based on the object shown in Figure 7B-1). Likewise, 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.

12B is a flowchart 1200B illustrating a graphics processing method that includes executing the geometry of an image frame using the same set of shaders in two passes through a portion of a command buffer, in accordance with one embodiment of the present disclosure. Pre-test and render both. As mentioned previously, various architectures may include multiple GPUs cooperating to render a single image by performing multi-GPU rendering of geometry for an application, such as within one or more cloud gaming servers of a cloud gaming system, or within a stand-alone system ( Such as within a personal computer or gaming console including a high-end graphics card with multiple GPUs, etc.

In particular, at 1210, the method includes using multiple GPUs to render graphics for the application, as previously described. At 1220, the method includes dividing responsibilities for rendering geometry of the graphics among multiple GPUs based on multiple screen areas. Each GPU has a corresponding division of responsibilities known to multiple GPUs. More specifically, each GPU is responsible for rendering geometry in a corresponding set of screen areas of a plurality of screen areas, where the corresponding set of screen areas includes one or more screen areas, as previously described. In one embodiment, the screen areas are interleaved (eg, when the display is divided into sets of screen areas for geometry pre-testing and rendering).

At 1230, the method includes allocating multiple geometries of the image frame to multiple GPUs for geometry testing. In particular, each of the multiple GPUs is assigned to a corresponding portion of the geometry associated with the image frame for geometry testing. As mentioned previously, in embodiments, the distribution of geometries may be evenly or unevenly distributed, where each section includes one or more geometries, or there may be no geometries at all.

At 1240, the method includes loading a first GPU state that configures one or more shaders to perform geometry pre-testing. For example, depending on the GPU state, the corresponding shader can be configured to perform different operations. Therefore, the first GPU state configures the corresponding shader to perform geometry pretesting. In the example of Figure 12A, this can be set in a variety of ways, such as by explicitly or implicitly setting state externally to the portion of the command buffer depicted in 1200A, as described above. In particular, the GPU state can be set in a variety of ways. For example, the CPU or GPU can set a value in random access memory (RAM), where the GPU will check the RAM for that value. In another example, the state may be internal to the GPU, such as when a command buffer is called twice as a subroutine, the internal GPU state is different between the two subroutine calls. Alternatively, command 1210 in Figure 12A may be interpreted differently or skipped based on state explicitly or implicitly set as described above. Based on this first GPU state, shader 0, executed by command 1211, is configured to perform geometry pretesting.

At 1250, the method includes performing geometry pretesting on the plurality of geometries at the plurality of GPUs to generate information about each geometry and its relationship to each of the plurality of screen areas. As mentioned before, the geometry pretest can determine whether a geometry overlaps any screen area allocated to the corresponding GPU for object rendering (e.g., in the corresponding group). Because geometry pretesting is typically performed by the GPU in implementations simultaneously for all geometries of a corresponding image frame, each GPU is able to know which geometries to render and which geometries to skip. This concludes the first pass through the command buffer, where the shader can be configured to perform each of geometry pretesting and/or rendering depending on the GPU state.

At 1260, the method includes loading a second GPU state that configures one or more shaders to perform rendering. As mentioned before, depending on the GPU state, the corresponding shader can be configured to perform different operations. Therefore, the second GPU state configures the corresponding shader (the same shader previously used to perform the geometry pretest) to perform rendering. In the example of Figure 12A, based on this second GPU state, shader 0 executed by command 1211 is configured to perform rendering.

At 1270 , the method includes using at each of the plurality of GPUs when rendering the plurality of geometries (e.g., including fully rendering the geometry at the corresponding GPU or skipping rendering of the geometry). Each generated message. As mentioned before, this information can indicate whether a geometry overlaps any screen area (eg, in the corresponding group) allocated to the corresponding GPU for object rendering. This information can be used to render each of the plurality of geometries at each of the plurality of GPUs such that each GPU can efficiently render only the at least one screen allocated to that corresponding GPU for object rendering (e.g., in corresponding groups) overlapping geometries. This concludes a second pass through the command buffer, where the shader can be configured to perform either geometry pretesting and/or rendering depending on the GPU state.

Figures 13A-13B illustrate another strategy for handling the render command buffer. Previously, a strategy was described with reference to Figures 7A-7C in which a command buffer contains commands for geometry pre-testing of an object (e.g., geometry), followed by commands for rendering the object (e.g., geometry), And another strategy using shaders that can perform either operation depending on the GPU configuration is described in Figures 12A-12B. 13A-13B illustrate a geometry testing and rendering strategy using a shader capable of performing geometry pre-testing or rendering, in accordance with an embodiment of the present disclosure, and wherein the process of geometry pre-testing and rendering is useful for different sets of geometries. The graphics are staggered.

In particular, FIG. 13A is a schematic diagram illustrating the use of a shader configured to perform both geometry pretesting and rendering, in which geometry pretesting and rendering are performed for different sets of geometries, according to one embodiment of the present disclosure. Rendering is interleaved using separate portions of the corresponding command buffer 1300A. That is, rather than executing portions of command buffer 1300A from start to finish, command buffer 1300A is dynamically configured and executed such that geometry pretesting and rendering are interleaved for different sets of geometry. For example, in the command buffer, some shaders (e.g., executed via commands 1311 and 1313) are configured to perform geometry pretesting on the first set of geometries, where after performing the geometry test, those same shaders (e.g., executed by commands 1311 and 1313) are then configured to perform rendering. After performing rendering on the first set of geometries, other shaders in the command buffer (e.g., executed via commands 1315 and 1317) are configured to perform geometry pretesting on the second set of geometries, where the geometry is After graphics pre-testing, those same shaders (eg, executed via commands 1315 and 1317) are then configured to perform rendering, and the rendering is performed using those commands for the second set of geometries. The benefit of this strategy is that imbalances between GPUs can be resolved dynamically, such as through asymmetric interleaving using geometry testing throughout the rendering process. An example of asymmetric interleaving of geometry tests was previously introduced in distribution 102 of FIG. 10 .

Because of the interleaved dynamics of geometry pretesting and rendering, configuration of the GPU (e.g., via register settings or values in RAM) occurs implicitly, that is, one aspect of the GPU configuration occurs outside of the command buffer. For example, a GPU register can be set to 0 (indicating that geometry pretesting should occur) or 1 (indicating that rendering should occur); interleaved traversal of the command buffer and the setting of this register can be set by the GPU based on the number of objects processed, primitives processed , imbalance between GPUs, etc. to control. Alternatively, the value in RAM can be used. As a result of this external configuration (meaning set outside the command buffer), when a command in that portion of command buffer 1300A is executed (eg, a command to set state or a command to execute a shader), based on the GPU state, the command The results are different (for example, causing geometry pretesting to perform versus performing rendering). That is, the commands in command buffer 1300A may be configured for geometry pretesting 1391 or rendering 1392. In particular, portions of command buffer 1300A include commands for configuring the state of one or more GPUs that execute commands from rendering command buffer 1300A, and for performing shaders that perform geometry pretesting or rendering depending on the state. The command. For example, commands 1310, 1312, 1314, and 1316 are each used to configure the state of the GPU in order to execute shaders that perform geometry pretesting or rendering depending on the state. As shown, command buffer 1310 configures the GPU state so that shader 0 can be executed via command 1311 to perform geometry pretesting or rendering of object 0. Likewise, command buffer 1312 configures the GPU state so that shader 1 can be executed via command 1313 to perform geometry pretesting or rendering of object 1 . Likewise, command buffer 1314 configures the GPU state so that shader 2 can be executed via command 1315 to perform geometry pretesting or rendering of object 2. Further, command buffer 1316 configures the GPU state so that shader 3 can be executed via command 1317 to perform geometry pretesting or rendering of object 3.

Geometry pretesting and rendering can be interleaved for different groups of geometries. For illustration purposes only, command buffer 1300A may be configured to first perform geometry pretesting and rendering for objects 0 and 1, and then command buffer 1300A is configured to perform a second time for geometry pretesting and rendering for objects 2 and 3. render. It will be appreciated that different numbers of geometries can be interleaved in different segments. For example, segment 1 shows the 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 shader performs geometry pre-testing. For example, shader 0 is configured to perform geometry pretesting (e.g., based on the object shown in Figure 7B-1) on object 0 (e.g., a geometry), and shader 1 is configured to perform geometry pretesting on object 1 Graphical pretest. Segment 2 shows the second pass 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 shader performs rendering. For example, shader 0 is configured to now perform the rendering of object 0, and shader 1 is configured to now perform the rendering of object 1.

An interleaving of geometry pre-testing and rendering performance on different sets of geometries is shown in Figure 13A. In particular, segment 3 shows the third portion of the 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 shader performs geometry pre-testing. For example, shader 2 (executed via command 1315) performs a geometry test (eg, based on the object shown in Figure 7B-1) on object 2 (eg, a geometry), and shader 3 (executed via command 1317) performs a geometry test on object 2 (eg, a geometry). 3Perform geometry testing. Segment 4 shows the fourth portion of the 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 shader performs rendering. For example, shader 2 (executed via command 1315) performs rendering of object 2, and shader 3 (executed via command 1317) performs rendering of object 3.

Note that the hardware background is preserved, or saved and restored. For example, the geometry pretest GPU background at the end of segment 1 needs to be used at the beginning of segment 3 to perform the geometry pretest. Likewise, rendering the GPU background at the end of segment 2 requires rendering at the beginning of segment 4.

In one embodiment, commands may be skipped or interpreted differently based on GPU status. For example, certain commands that set the state (parts of 1310, 1312, 1314, and 1316) may be skipped based on the implicitly set GPU state as described above; for example, if configuring shader 0 executed via command 1310 needs to be for geometry If a graphics test is configured with less GPU state than is required when configured for geometry rendering, it may be beneficial to skip the unnecessary portion of setting the GPU state since there is an overhead in setting the GPU state. As another example, certain commands that set state (parts of 1310, 1312, 1314, and 1316) may be interpreted differently based on the GPU state being implicitly set as described above; for example, if shader 0 is executed via command 1310 The GPU state that needs to be configured for geometry testing is different than when configured for geometry rendering, or if shader 0 executed via command 1310 requires different inputs for geometry testing than for geometry rendering.

In one embodiment, shaders configured for geometry pretest do not allocate space in the position cache and parameter cache, as previously described. In another embodiment, a single shader is used to perform pretesting or rendering. This can be done in a variety of ways, such as via external hardware state that the shader can check (e.g., set implicitly as described above), or via input to the shader (e.g., by passing the command buffer on the first and second passes). (set by commands interpreted differently in two passes).

13B is a flowchart illustrating a graphics processing method including using separate portions of corresponding command buffers to interleave pre-testing and rendering of geometry for image frames for different sets of geometries, according to one embodiment of the present disclosure. As mentioned previously, various architectures may include multiple GPUs cooperating to render a single image by performing multi-GPU rendering of geometry for an application, such as within one or more cloud gaming servers of a cloud gaming system, or within a stand-alone system ( Such as within a personal computer or gaming console including a high-end graphics card with multiple GPUs, etc.

In particular, at 1310, the method includes using multiple GPUs to render graphics for the application, as previously described. At 1320, the method includes dividing responsibilities for rendering geometry of the graphics among multiple GPUs based on multiple screen areas. Each GPU has a corresponding division of responsibilities known to multiple GPUs. More specifically, each GPU is responsible for rendering geometry in a corresponding set of screen areas of a plurality of screen areas, where the corresponding set of screen areas includes one or more screen areas, as previously described. In one embodiment, the screen areas are interleaved (eg, when the display is divided into sets of screen areas for geometry pre-testing and rendering).

At 1330, the method includes allocating multiple geometries of the image frame to multiple GPUs for geometry testing. In particular, each of the multiple GPUs is assigned to a corresponding portion of the geometry associated with the image frame for geometry testing. As mentioned before, the distribution of geometries can be evenly or unevenly distributed, where each section includes one or more geometries, or there may be no geometry at all.

At 1340, the method includes interleaving a first set of shaders in the command buffer with a second set of shaders, wherein the shaders are configured to perform both geometry pretesting and rendering. In particular, the first set of shaders is configured to perform geometry pretesting and rendering on the first set of geometries. Thereafter, a second set of shaders is configured to perform geometry pretesting and rendering on the second set of geometries. As previously mentioned, the geometry pretest generates corresponding information about each geometry in the first or second group and its relationship to each of the plurality of screen areas. Multiple GPUs use corresponding information to render each geometry in the first or second group. As mentioned before, the GPU state can be set in a variety of ways in order to perform geometry pretesting or rendering. For example, the CPU or GPU can set a value in random access memory (RAM), where the GPU will check the RAM for that value. In another example, the state may be internal to the GPU, such as when a command buffer is called twice as a subroutine, the internal GPU state is different between the two subroutine calls.

The interleaving process is further described. In particular, the first set of shaders of the command buffer is configured to perform geometry pretesting on the first set of geometries, as described previously. Geometry pretesting is performed on the first set of geometries at the plurality of GPUs to generate first information about each geometry in the first set and its relationship to each of the plurality of screen areas. The first set of shaders are then configured to perform the rendering of the first set of geometries, as described previously. Thereafter, the first information is used when rendering the plurality of geometries at each of the plurality of GPUs (eg, including fully rendering the first set of geometries at the corresponding GPU or skipping rendering of the first set of geometries). As mentioned before, this information indicates which geometries overlap the screen area allocated to the corresponding GPU for object rendering. For example, this information can be used to skip rendering the geometry at the GPU when the information indicates that the geometry does overlap any screen area allocated to the GPU for object rendering (eg, in the corresponding group).

The second set of shaders are then used for geometry testing and rendering of the second set of geometry. In particular, the command buffer's second set of shaders is configured to perform geometry pretesting on the second set of geometries, as previously described. Geometry testing is then performed on the second set of geometries at the plurality of GPUs to generate second information about each geometry in the second set and its relationship to each of the plurality of screen areas. The second set of shaders is then configured to perform the rendering of the second set of geometries, as previously described. Thereafter, rendering of the second set of geometries is performed at each of the plurality of GPUs using the second information. As mentioned before, this information indicates which geometries overlap the screen area (eg, of the corresponding group) allocated to the corresponding GPU for object rendering.

Although multiple GPUs are described above as processing geometry back-to-back (i.e., multiple GPUs perform geometry pretesting and then multiple GPUs perform rendering), in some embodiments the GPUs are not explicitly synchronized with each other, e.g. One GPU can be rendering a first set of geometries while a second GPU is performing geometry pretesting on a second set of geometries.

Figure 14 illustrates components of an example apparatus 1400 that may 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 potentially interleaved screen areas prior to rendering objects of an image frame, in accordance with an embodiment of the present disclosure. render. This block diagram illustrates an apparatus 1400 that may be incorporated into or may be a personal computer, a server computer, a game console, a mobile device, or other digital device, each of which may be suitable for practicing embodiments of the present invention. Apparatus 1400 includes a central processing unit (CPU) 1402 for running software applications and optionally an operating system. CPU 1402 may be composed of one or more homogeneous or heterogeneous processing cores.

According to various embodiments, CPU 1402 is one or more general-purpose microprocessors having one or more processing cores. Additional embodiments may be implemented using one or more CPUs having a microprocessor architecture particularly suited for highly parallel and computationally intensive applications such as media and interactive entertainment applications that are Configures graphics processing used during the execution of the game.

Memory 1404 stores applications and data for use by CPU 1402 and GPU 1416. Storage 1406 provides non-volatile storage and other computer-readable media for applications and data and may include fixed disk drives, removable disk drives, flash memory devices, and CD-ROMs, DVD-ROMs, Blu-ray Discs, HD -DVD or other optical storage devices, and signal transmission and storage media. User input device 1408 communicates user input from one or more users to device 1400, examples of which may include a keyboard, mouse, joystick, touch pad, touch screen, still or video recorder/camera, and/or microphone. Network interface 1409 allows device 1400 to communicate with other computer systems via electronic communications networks, and may include wired or wireless communications over local area networks and wide area networks such as the Internet. Audio processor 1412 is adapted to generate analog or digital audio output from instructions and/or data provided by CPU 1402, memory 1404, and/or storage 1406. The components of device 1400, including CPU 1402, graphics subsystem including GPU 1416, memory 1404, data storage 1406, user input device 1408, network interface 1409, and audio processor 1412, are connected via one or more data buses 1422.

Graphics subsystem 1414 further interfaces with data bus 1422 and components of device 1400 . Graphics subsystem 1414 includes at least one graphics processing unit (GPU) 1416 and graphics memory 1418 . Graphics memory 1418 includes display memory (eg, a frame buffer) that stores pixel data for each pixel of the output image. Graphics memory 1418 may be integrated in the same device as GPU 1416 , coupled with GPU 1416 as a separate device, and/or implemented within memory 1404 . Pixel data may be provided directly from CPU 1402 to graphics memory 1418. Alternatively, CPU 1402 may provide data and/or instructions defining a desired output image to GPU 1416, from which GPU 1416 generates pixel data for one or more output images. Data and/or instructions defining the desired output image may be stored in memory 1404 and/or graphics memory 1418 . In an embodiment, GPU 1416 includes 3D rendering capabilities for generating pixel data for an output image based on instructions and data that define the scene's geometry, lighting, shading, texturing, motion, and /or camera parameters. GPU 1416 may also include one or more programmable execution units capable of executing shader programs.

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

Other implementations for optimizing the graphics subsystem 1414 may include multi-GPU rendering of geometry for an application by pre-testing the geometry for potentially interleaved screen areas before rendering objects of an image frame. Graphics subsystem 1414 may be configured as one or more processing devices.

For example, in one embodiment, graphics subsystem 1414 may be configured to perform multi-GPU rendering of geometry for an application, where multiple graphics subsystems may implement graphics and/or rendering pipelines for a single application. That is, graphics subsystem 1414 includes multiple GPUs for rendering each of one or more images in an image or sequence of images when executing an application.

In other embodiments, graphics subsystem 1414 includes multiple GPU devices that are combined to perform graphics processing for a single application executing on a corresponding CPU. For example, multiple GPUs can perform multi-GPU rendering of geometry for an application by pre-testing the geometry for potentially interleaved screen areas before rendering the objects of the image frame. In other examples, multiple GPUs may perform an alternating form of frame rendering, where in sequential frame cycles, GPU 1 renders the first frame, and GPU 2 renders the second frame, and so on until the last GPU is reached, so The initial GPU renders the next video frame (for example, if there are only two GPUs, GPU 1 renders the third frame). That's GPU rotation when rendering frames. Rendering operations can overlap, where GPU 2 can start rendering the second frame before GPU 1 has finished rendering the first frame. In another embodiment, multiple GPU devices may be assigned different shader operations in a rendering and/or graphics pipeline. The main GPU is performing the main rendering and compositing. For example, in a group of three GPUs, master GPU 1 can perform the master rendering (e.g., a first shader operation) and composite output from slave GPU 2 and slave GPU 3, where slave GPU 2 can perform a second shader operation. (eg fluid effects such as river) operations, slave GPU 3 can perform third shader (eg particle smoke) operations where master GPU 1 synthesizes the results from each of GPU 1, GPU 2 and GPU 3. This way, different GPUs can be assigned to perform different shader operations (such as flag waving, wind, smoke generation, fire, etc.) to render video frames. In yet another embodiment, each of the three GPUs may be assigned to a different object and/or scene portion corresponding to a video frame. In the above embodiments and implementations, these operations may be performed in the same frame period (simultaneous parallelism) or in different frame periods (sequential parallelism).

Accordingly, the present disclosure describes configurations that provide for an application by pre-testing geometry for potentially interleaved screen areas before rendering an image frame or an object for each of one or more image frames in a sequence of image frames when the application is executed. Methods and systems for multi-GPU rendering of geometric figures.

It is to be understood that the various embodiments defined herein can be combined or assembled into specific embodiments using the various features disclosed herein. Therefore, the examples provided are only some of the possible examples and are not limited to the various implementations that are 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 or equivalent implementations.

Embodiments of the present disclosure may be practiced with a variety of computer system configurations including handheld devices, microprocessor systems, microprocessor-based or programmable consumer electronics, minicomputers, mainframe computers, and the like. Embodiments of the present disclosure may also be practiced in distributed computing environments where tasks are performed by remote processing devices based on wired or wireless network links.

With the above embodiments in mind, it should be understood that embodiments of the present disclosure may employ various computer-implemented operations involving data stored in a computer system. These operations are those requiring physical manipulation of physical quantities. Any operations described herein that form part of embodiments of the present disclosure are useful machine operations. Embodiments of the present disclosure also relate to apparatus or equipment for performing these operations. The device may be specially constructed for the required purposes, or the device may be a general purpose computer selectively activated or configured by a computer program stored in the computer. In particular, a variety of general purpose machines may be used with computer programs written in accordance with the teachings herein, or it may be more convenient to construct a more specialized apparatus to perform the required operations.

The disclosure may also be embodied as computer-readable code on a computer-readable medium. Computer-readable media is any data storage device that can store data that can subsequently be read by a computer system. Examples of computer-readable media include hard drives, network-attached storage (NAS), read-only memory, random-access memory, CD-ROMs, CD-Rs, CD-RWs, magnetic tape, and other optical and non-optical data storage devices . The computer-readable medium may include computer-readable tangible media distributed over network-coupled computer systems so that the computer-readable code is stored and executed in a distributed fashion.

Although the method operations are described in a specific order, it should be understood that other housekeeping operations may be performed between the operations, or the operations may be adjusted so that they occur at slightly different times, or may be distributed among the various operations allowed to be associated with the process. In a system where processing operations occur at intervals, it suffices as long as the processing of the overriding operation is performed in the expected manner.

Although the foregoing disclosure has been described in considerable detail for purposes of clarity of understanding, it will be apparent that certain changes and modifications may be practiced within the scope of the appended claims. Accordingly, the embodiments of the present invention are to be regarded as illustrative and not restrictive, and the disclosed embodiments are not limited to the details given herein, but may be modified within the scope and equivalents of the appended claims.

Claims (24)

1. A method for graphics processing, comprising: Use multiple graphics processing units (GPUs) to render graphics for your application; Responsibility for rendering the geometry of the figure is divided between the plurality of GPUs based on a plurality of screen areas, each GPU having a corresponding division of the responsibility known to the plurality of GPUs, wherein the plurality of Screen areas within screen areas are interleaved; allocating the geometry of the image frames generated by the application to the GPU for geometry pre-testing; performing the geometry pretest at the GPU to generate information regarding the geometry and its relationship to each of the plurality of screen areas; using the information at each of the plurality of GPUs when rendering the image frame; providing said information as a hint to a rendering GPU, wherein said rendering GPU is one of said plurality of GPUs, wherein said rendering GPU considers said information if said information is received before said rendering GPU begins rendering said geometry, Wherein the geometry is fully rendered at the rendering GPU when the information is received after rendering of the geometry has started. 2. The method of claim 1, further comprising: Rendering of the geometry is skipped at the rendering GPU when the information indicates that the geometry does not overlap any screen area allocated to the rendering GPU for object rendering, where the rendering GPU is One of the multiple GPUs mentioned above. 3. The method of claim 1, further comprising: assigning a plurality of geometries of the image frame to the plurality of GPUs for the geometry pre-testing, Wherein the geometries of the plurality of geometries are evenly or unevenly distributed among the plurality of GPUs. 4. The method of claim 3, wherein the plurality of geometries are allocated such that consecutive geometries are processed by different GPUs. 5. The method of claim 4, wherein a first GPU performs the geometry pretest on more geometries than a second GPU, or the first GPU performs the geometry pretest while the second GPU performs the geometry pretest. The second GPU does not perform geometry pretesting at all. 6. The method of claim 1, wherein the plurality of screen areas are configured to reduce imbalances in rendering times between the plurality of GPUs. 7. The method of claim 1, wherein each of the plurality of screen areas is not uniform in size. 8. The method of claim 1, wherein the plurality of screen areas change dynamically. 9. The method of claim 1, wherein the geometry corresponds to geometry used or generated by a draw call. 10. The method of claim 1, Where the geometry used or generated by the application's draw calls is subdivided into multiple geometries, including the geometry for which the GPU generated the information. 11. The method of claim 1, wherein the geometries are individual primitives. 12. The method of claim 1, wherein the information about the geometry includes a vertex count or a primitive count. 13. The method of claim 1, wherein the information about the geometry includes a specific set of primitives for rendering or a specific set of vertices for rendering. 14. The method of claim 1, further comprising: Using a common rendering command buffer for the multiple GPUs; and Limit execution of commands in the common rendering command buffer to one or more of the plurality of GPUs. 15. The method of claim 1, Depending on the nature of the geometry, the information may or may not be generated. 16. The method of claim 1, further comprising: The information is generated using a scan converter in the rasterization stage. 17. The method of claim 1, further comprising: The information is generated using one or more shaders in the geometry processing stage. 18. The method of claim 17, wherein the one or more shaders use one or more specialized instructions to accelerate generation of information. 19. The method of claim 17, wherein the one or more shaders do not perform allocation of position caches or parameter caches. 20. The method of claim 1, further comprising: partitioning a plurality of geometries among the plurality of GPUs for said geometry pretest, where consecutive geometries are processed by different GPUs. 21. The method of claim 20, further comprising: The partitioning of the plurality of geometries is dynamically adjusted during the geometry pre-test based on the performance of each of the plurality of GPUs. 22. The method of claim 1, wherein one or more of the plurality of GPUs are part of a larger GPU configured as a plurality of virtual GPUs. 23. A computer system comprising: processor; A memory coupled to the processor and having instructions stored therein that, if executed by the computer system, cause the computer system to perform a method for implementing a graphics pipeline, the method comprising: Use multiple graphics processing units (GPUs) to render graphics for your application; Responsibility for rendering the geometry of the figure is divided between the plurality of GPUs based on a plurality of screen areas, each GPU having a corresponding division of the responsibility known to the plurality of GPUs, wherein the plurality of Screen areas within screen areas are interleaved; Allocate the geometry of the image frames generated by the application to the GPU for geometry pre-testing; performing the geometry pretest at the GPU to generate information regarding the geometry and its relationship to each of the plurality of screen areas; using the information at each of the plurality of GPUs when rendering the image frame; providing said information as a hint to a rendering GPU, wherein said rendering GPU is one of said plurality of GPUs, wherein said rendering GPU considers said information if said information is received before said rendering GPU begins rendering said geometry, Wherein the geometry is fully rendered at the rendering GPU when the information is received after rendering of the geometry has started. 24. The computer system of claim 23, further comprising: Rendering of the geometry is skipped at the rendering GPU when the information indicates that the geometry does not overlap any screen area allocated to the rendering GPU for object rendering, wherein the rendering GPU is the multi- One of the GPUs.