JP7334358B2 - System and method for efficient multi-GPU rendering of geometry by pre-testing on interleaved screen regions before rendering - Google Patents

Description

TECHNICAL FIELD This disclosure relates to graphics processing and, more particularly, to multi-GPU cooperation when rendering images for applications.

In recent years, there has been a continuing effort towards online services that allow online or cloud gaming in a streaming format between a cloud gaming server and clients connected through a network. Streaming formats are becoming more and more popular. because of the availability of game titles on demand, the ability to run more complex games, the ability to network between players in the case of multiplayer gaming, the ability to share assets between players, and the ability to share assets between players and/or spectators. The ability to share instant experiences, the ability for friends to watch as they play video games, and the ability for friends to participate in ongoing game play.

A cloud gaming server may be configured to provide resources to one or more clients and/or applications. That is, cloud gaming servers may be configured with resources capable of high throughput. For example, there is a limit to the performance that an individual graphics processing unit (GPU) can achieve. When it is desirable to render a single image with multiple GPUs to render a more complex scene, or to use more complex algorithms (e.g., materials, lighting, etc.) when generating the scene There is However, using these graphics processing units evenly is difficult to achieve. Furthermore, even if there are multiple GPUs to process images for an application using conventional techniques, it is not possible to support a corresponding increase in both screen pixel count and geometry density (with 4 GPUs, It is impossible to write four times as many pixels to the image and/or process four times as many vertices or primitives).

It is against this background that the embodiments of the present disclosure have been made.

Embodiments of the present disclosure use multiple GPUs in concert to render a single image, e.g., multi-GPU rendering of geometry to an application by pre-testing on screen regions (which may be interleaved) before rendering. about doing

Embodiments of the present disclosure disclose a method for performing graphics processing. The method includes rendering graphics for an application using multiple graphics processing units (GPUs). The method divides the responsiveness for rendering graphics geometry among multiple GPUs based on multiple screen regions, each GPU having a corresponding division of responsiveness known to the multiple GPUs. Screen regions are interleaved. The method includes assigning multiple pieces of geometry of an image frame to multiple GPUs for geometry testing. The method includes assigning a GPU a piece of geometry of an image frame generated by the application for geometry testing. The method includes performing geometry tests on the GPU to generate information about pieces of geometry and their relationship to each of a plurality of screen regions. The method includes using the information to render a piece of geometry on each of a plurality of GPUs, wherein using the information may, for example, render the piece of geometry any screen area assigned to a given GPU. It can include skipping rendering completely if it is determined that there is no overlap.

In another embodiment, a non-transitory computer-readable medium for performing the method is disclosed. A computer-readable medium includes program instructions for rendering graphics for an application using multiple graphics processing units (GPUs). The computer-readable medium is program instructions for dividing the responsibility for rendering graphics geometry among multiple GPUs based on multiple screen regions, each GPU having a responsibility known to the multiple GPUs. and the screen regions in the plurality of screen regions are interleaved. A computer-readable medium includes program instructions for allocating to a GPU a piece of geometry of an image frame generated by an application for geometry pre-testing. A computer-readable medium includes program instructions for performing geometry pre-testing on a GPU to generate information about pieces of geometry and their relationship to each of a plurality of screen regions. A computer-readable medium includes program instructions for using information at each of a plurality of GPUs when rendering image frames.

In yet another embodiment, a computer system is disclosed. The computer system comprises a processor and a memory coupled to the processor and in which instructions are stored which, when executed by the computer system, cause the computer system to perform a method for performing graphics processing. and including. The method includes rendering graphics for an application using multiple graphics processing units (GPUs). The method divides responsiveness for rendering graphics geometry among multiple GPUs based on multiple screen regions, each GPU having a corresponding division of responsiveness known to the multiple GPUs; Screen regions in multiple screen regions are interleaved. The method includes assigning a GPU a piece of geometry of an image frame generated by the application for geometry pre-testing. The method includes performing geometry pre-testing on the GPU to generate information about a piece of geometry and its relationship to each of a plurality of screen regions. The method includes using information on each of a plurality of GPUs when rendering image frames.

Embodiments of the present disclosure disclose a method for performing graphics processing. The method includes rendering graphics for an application using multiple graphics processing units (GPUs). The method divides responsiveness for rendering graphics geometry among multiple GPUs based on multiple screen regions, each GPU having a corresponding division of responsiveness known to multiple GPUs. including doing The method includes performing a geometry test in a GPU pretest on multiple pieces of geometry of an image frame generated by the application to generate information about each piece of geometry and its relationship to each of multiple screen regions. include. The method is to render the plurality of pieces of geometry on each of the plurality of GPUs using the information generated for each of the plurality of pieces of geometry, wherein using the information includes, for example, the geometry , including skipping rendering entirely if it is determined that a piece of .

In another embodiment, a non-transitory computer-readable medium for performing the method is disclosed. A computer-readable medium includes program instructions for rendering graphics for an application using multiple graphics processing units (GPUs). The computer readable medium is program instructions for dividing the responsibility for rendering graphics geometry among multiple GPUs based on multiple screen regions, each GPU having a responsibility known to the multiple GPUs. contains program instructions, with corresponding divisions of A computer readable medium for performing geometry tests in a GPU pretest on multiple pieces of geometry of an image frame generated by an application to generate information about each piece of geometry and its relationship to each of multiple screen regions. program instructions. The computer-readable medium is program instructions for rendering a plurality of pieces of geometry on each of a plurality of GPUs using information generated for each of the plurality of pieces of geometry, wherein using the information is , for example, programming instructions that skip rendering entirely if it is determined that a piece of geometry does not overlap any screen regions assigned to a given GPU.

In yet another embodiment, a computer system is disclosed. The computer system comprises a processor and a memory coupled to the processor and in which instructions are stored which, when executed by the computer system, cause the computer system to perform a method for performing graphics processing. and including. The method includes rendering graphics for an application using multiple graphics processing units (GPUs). The method divides the responsiveness for rendering graphics geometry among multiple GPUs based on multiple screen regions, each GPU having a corresponding division of responsiveness known to the multiple GPUs. The method includes performing a geometry test in a GPU pre-test on multiple pieces of geometry of an image frame generated by the application to generate information about each piece of geometry and its relationship to each of multiple screen regions. include. The method renders the plurality of pieces of geometry on each of the plurality of GPUs using the information generated for each of the plurality of pieces of geometry, and when using the information, for example, the pieces of geometry are: Skip rendering entirely if it is determined not to overlap any screen regions allocated to a given GPU.

Embodiments of the present disclosure disclose a method for performing graphics processing. The method includes rendering graphics for an application using multiple graphics processing units (GPUs). The method divides responsiveness for rendering graphics geometry among multiple GPUs based on multiple screen regions, each GPU having a corresponding division of responsiveness known to multiple GPUs. including doing The method includes rendering a first plurality of pieces of geometry on the plurality of GPUs during a rendering phase of previous image frames generated by the application. The method includes generating statistics for rendering of previous image frames. The method includes allocating a second plurality of pieces of geometry of the current image frame generated by the application to the plurality of GPUs for geometry testing based on the statistical values. The method performs a geometry test on a second plurality of pieces of geometry in the current image frame to relate each piece of the second plurality of pieces of geometry and its relationship to each of a plurality of screen regions. Information is generated and geometry tests are performed on each of the multiple GPUs based on allocation. The method renders the second plurality of pieces of geometry on each of the plurality of GPUs using the information generated for each of the second plurality of pieces of geometry, and when using the information, e.g. , skipping rendering entirely if it is determined that the piece of geometry does not overlap any screen regions allocated to the given GPU.

In another embodiment, a non-transitory computer-readable medium for performing the method is disclosed. A computer-readable medium includes program instructions for rendering graphics for an application using multiple graphics processing units (GPUs). The computer readable medium is program instructions for dividing the responsibility for rendering graphics geometry among multiple GPUs based on multiple screen regions, each GPU having a responsibility known to the multiple GPUs. contains programming instructions, with corresponding divisions of The computer-readable medium includes program instructions for rendering a first plurality of pieces of geometry on a plurality of GPUs during a rendering phase of previous image frames generated by an application. A computer-readable medium includes program instructions for generating statistics for rendering of previous image frames. The computer-readable medium includes program instructions for allocating a second plurality of pieces of geometry of the current image frame generated by the application to the plurality of GPUs for geometry testing based on the statistical values. The computer readable medium performs a geometry test on the second plurality of pieces of geometry in the current image frame to relate each piece of the second plurality of pieces of geometry and its relationship to each of the plurality of screen regions. Having programming instructions for generating information, geometry tests are performed on each of a plurality of GPUs based on allocation. The computer-readable medium has programming instructions for rendering a second plurality of pieces of geometry on each of a plurality of GPUs using information generated for each of the second plurality of pieces of geometry. , the rendering can be skipped entirely if, for example, it is determined that a piece of geometry does not overlap any screen regions assigned to a given GPU when using the information.

In yet another embodiment, a computer system is disclosed. The computer system comprises a processor and a memory coupled to the processor and in which instructions are stored which, when executed by the computer system, cause the computer system to perform a method for performing graphics processing. and including. The method includes rendering graphics for an application using multiple graphics processing units (GPUs). The method divides the responsiveness for rendering graphics geometry among multiple GPUs based on multiple screen regions, each GPU having a corresponding division of responsiveness known to the multiple GPUs. The method renders a first plurality of pieces of geometry on the plurality of GPUs during a rendering phase of previous image frames generated by the application. The method includes generating statistics for rendering of previous image frames. The method includes allocating a second plurality of pieces of geometry of the current image frame generated by the application to the plurality of GPUs for geometry testing based on the statistical values. The method performs a geometry test on a second plurality of pieces of geometry in the current image frame to relate each piece of the second plurality of pieces of geometry and its relationship to each of a plurality of screen regions. Information is generated and geometry tests are performed on each of the multiple GPUs based on allocation. The method renders the second plurality of pieces of geometry on each of the plurality of GPUs using the information generated for each of the second plurality of pieces of geometry, and when using the information, e.g. , skipping rendering entirely if it is determined that the piece of geometry does not overlap any screen regions allocated to the given GPU.

Embodiments of the present disclosure disclose methods for performing graphics processing. The method includes rendering graphics for an application using multiple graphics processing units (GPUs). The method divides the responsiveness for rendering graphics geometry among multiple GPUs based on multiple screen regions, each GPU having a corresponding division of responsiveness known to the multiple GPUs. The method assigns multiple pieces of geometry for an image frame to multiple GPUs for geometry testing. The method includes setting a first state that configures one or more shaders to perform the geometry test. The method includes performing geometry tests on multiple pieces of geometry on multiple GPUs to generate information about each piece of geometry and its relationship to each of multiple screen regions. The method includes setting a second state that configures one or more shaders to perform rendering. The method renders the plurality of pieces of geometry on each of the plurality of GPUs using the information generated for each of the plurality of pieces of geometry, and when using the information, for example, the pieces of geometry are: Skip rendering entirely if it is determined not to overlap any screen regions allocated to a given GPU.

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

In yet another embodiment, a computer system is disclosed. The computer system comprises a processor and a memory coupled to the processor and storing instructions which, when executed by the computer system, cause the computer system to perform a method for performing graphics processing. and including. The method includes rendering graphics for an application using multiple graphics processing units (GPUs). The method divides the responsiveness for rendering graphics geometry among multiple GPUs based on multiple screen regions, each GPU having a corresponding division of responsiveness known to the multiple GPUs. The method includes assigning multiple pieces of geometry 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 the geometry test. The method includes performing geometry tests on multiple pieces of geometry on multiple GPUs to generate information about each piece of geometry and its relationship to each of multiple screen regions. The method includes setting a second state that configures one or more shaders to perform rendering. The method renders the plurality of pieces of geometry on each of the plurality of GPUs using the information generated for each of the plurality of pieces of geometry, and when using the information, for example, the pieces of geometry are: Skip rendering entirely if it is determined not to overlap any screen regions allocated to a given GPU.

Embodiments of the present disclosure disclose methods for performing graphics processing. The method includes rendering graphics for an application using multiple graphics processing units (GPUs). The method divides the responsiveness for rendering graphics geometry among multiple GPUs based on multiple screen regions, each GPU having a corresponding division of responsiveness known to the multiple GPUs. The method includes assigning multiple pieces of geometry of an image frame to multiple GPUs for geometry testing. The method comprises a first set of shaders performing geometry testing and rendering on a first set of pieces of geometry and a second set of shaders performing geometry testing and rendering on a second set of pieces of geometry. and interleaving the set of shaders. A geometry test generates corresponding information about each piece of geometry in the first set or the second set and its relationship to each of the plurality of screen regions. Multiple GPUs use the corresponding information to render each piece of geometry in the first set or the second set. When using the information, for example, skip rendering entirely if it is determined that a piece of geometry does not overlap any screen regions assigned to a given GPU.

In another embodiment, a non-transitory computer-readable medium for performing the method is disclosed. A computer-readable medium includes program instructions for rendering graphics for an application using multiple graphics processing units (GPUs). The computer-readable medium has program instructions for dividing the responsibility for rendering graphics geometry among a plurality of GPUs based on a plurality of screen regions, each GPU having a responsibility known to the plurality of GPUs. has a corresponding division of A computer-readable medium includes program instructions for assigning multiple pieces of geometry of an image frame to multiple GPUs for geometry testing. The computer-readable medium includes a first set of shaders for performing geometry testing and rendering on a first set of pieces of geometry and a second set of shaders for performing geometry testing and rendering on a second set of pieces of geometry. It contains programming instructions for interleaving two sets of shaders. A geometry test generates corresponding information about each piece of geometry in the first set or the second set and its relationship to each of the plurality of screen regions. Multiple GPUs use the corresponding information to render each piece of geometry in the first set or the second set. When using the information, for example, skip rendering entirely if it is determined that a piece of geometry does not overlap any screen regions assigned to a given GPU.

In yet another embodiment, a computer system is disclosed. The computer system comprises a processor and a memory coupled to the processor and storing instructions which, when executed by the computer system, cause the computer system to perform a method for performing graphics processing. and including. The method includes rendering graphics for an application using multiple graphics processing units (GPUs). The method divides the responsiveness for rendering graphics geometry among multiple GPUs based on multiple screen regions, each GPU having a corresponding division of responsiveness known to the multiple GPUs. The method includes assigning multiple pieces of geometry of an image frame to multiple GPUs for geometry testing. The method comprises a first set of shaders performing geometry testing and rendering on a first set of pieces of geometry and a second set of shaders performing geometry testing and rendering on a second set of pieces of geometry. pairs of shaders. A geometry test generates corresponding information about each piece of geometry in the first set or the second set and its relationship to each of the plurality of screen regions. Multiple GPUs use the corresponding information to render each piece of geometry in the first set or the second set. When using the information, for example, skip rendering entirely if it is determined that a piece of geometry does not overlap any screen regions assigned to a given GPU.

Other aspects of the disclosure will become apparent from the accompanying drawings, which, taken together with the following detailed description, illustrate, by way of example, the principles of the disclosure.

The present disclosure may best be understood by referring to the accompanying drawings in conjunction with the following description.

Embodiments of the present disclosure provide gaming over a network among one or more cloud gaming servers configured to cooperatively execute multiple GPUs (graphics processing units) to render a single image. FIG. 2 is a diagram of a system for , including multiple GPUs that render geometry for applications by pre-testing the geometry for screen regions (which may be interleaved). FIG. 2 is a diagram of a multi-GPU architecture in which multiple GPUs work together to render a single image, according to one embodiment of the present disclosure; FIG. 4 is an illustration of multiple graphics processing unit resources configured for multi-GPU rendering of geometry to an application by pretesting the geometry against screen regions (which may be interleaved) according to one embodiment of the present disclosure; is. 1 is a diagram of a rendering architecture implementing a graphics pipeline configured for multi-GPU processing so that multiple GPUs work together to render a single image, in accordance with an embodiment of the present disclosure; FIG. [0014] Figure 4 is a flow diagram illustrating a method for performing graphics processing including multi-GPU rendering of geometry for an application by pre-testing on interleaved screen regions before rendering, according to one embodiment of the present disclosure; FIG. 4 is a diagram of a screen subdivided into quadrants when doing multi-GPU rendering, according to one embodiment of the present disclosure; FIG. 4 is a diagram of a screen subdivided into multiple interleaved regions when performing multi-GPU rendering, in accordance with an embodiment of the present disclosure; FIG. 4 is a diagram of a rendering command buffer shared by multiple GPUs working together to render a single image, including a geometry pretest portion and a rendering portion, in accordance with an embodiment of the present disclosure; [0014] Fig. 4 is a diagram illustrating an image containing four objects rendered by multiple GPUs, showing the screen area responsiveness for each GPU when rendering the objects of the image, in accordance with an embodiment of the present disclosure; 7B-1 is a table illustrating the rendering each GPU does when rendering the four objects of FIG. 7B-1, according to one embodiment of the present disclosure; According to one embodiment of the present disclosure, performing geometry pre-testing and geometry rendering performed by one or more GPUs when rendering an image frame through coordination of multiple GPUs (e.g., the image of FIG. 7B-1). It is a figure which illustrates. FIG. 4 illustrates an object test for screen regions when multiple GPUs work together to render a single image, in accordance with an embodiment of the present disclosure; [0014] Figure 4 illustrates testing a portion of an object against screen regions when multiple GPUs work together to render a single image, in accordance with an embodiment of the present disclosure; 4A-C are diagrams illustrating various strategies for allocating screen area to corresponding GPUs when multiple GPUs work together to render a single image, according to one embodiment of the present disclosure. [0014] Figure 4 illustrates various distributions of GPU allocation for geometry pre-testing on multiple pieces of geometry, in accordance with an embodiment of the present disclosure; According to one embodiment of the present disclosure, multiple GPUs pre-test and render the geometry of previous image frames and use statistics collected during rendering to pre-test the geometry of the current image frame to the current image frame. FIG. 2 illustrates influencing allocation to multiple GPUs in . According to one embodiment of the present disclosure, multiple GPUs pre-test and render the geometry of previous image frames and use statistics collected during rendering to pre-test the geometry of the current image frame to the current image frame. 1 is a flow diagram illustrating a method for performing graphics processing including influencing allocation to multiple GPUs in . [0015] Figure 4 illustrates using a shader configured to both pre-test and render the geometry of an image frame in two passes through a portion of the command buffer, in accordance with an embodiment of the present disclosure; According to one embodiment of the present disclosure, for performing graphics processing that includes both pre-testing and rendering the geometry of an image frame with the same set of shaders in two passes through a portion of the command buffer. Figure 2 is a flow diagram illustrating the method; [0014] Figure 4 illustrates using a shader configured to perform both geometry testing and rendering, according to one embodiment of the present disclosure, wherein geometry testing and rendering performed on different sets of pieces of geometry are performed by: FIG. 4B is interleaved with separate portions of the corresponding command buffers; According to one embodiment of the present disclosure, a method for performing graphics processing that includes interleaving pre-testing and rendering of image frame geometry for different sets of pieces of geometry with separate portions of corresponding command buffers. is a flow diagram illustrating the . 1 illustrates components of an example device that can be used to carry out aspects of various embodiments of the present disclosure; FIG.

Although the following detailed description includes many specific details for purposes of illustration, many variations and modifications to the following details are within the scope of the disclosure as will be appreciated by those skilled in the art. be. Accordingly, the aspects of the disclosure set forth below are set forth without any loss of generality to, or imposing limitations on, the claims following this description.

Generally speaking, there is a limit to the performance that an individual GPU can achieve, which is derived, for example, from the limits on how large the GPU can be. In embodiments of the present disclosure, it is desirable to render a single image using multiple GPUs to render more complex scenes or to use more complex algorithms (e.g., materials, lighting, etc.) . In particular, various embodiments of the present disclosure describe methods and systems configured to perform multi-GPU rendering of geometry for applications by pre-testing the geometry against screen regions (which may be interleaved). do. Multiple GPUs work together to generate an image. Responsibility or responsibility for rendering is divided among 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 altogether. For example, this has the advantage that multiple GPUs can render more complex scenes and/or images in the same amount of time.

Based on the foregoing general understanding of various embodiments, detailed example embodiments will now be described with reference to various drawings.

Throughout the specification, references to "application" or "game" or "video game" or "gaming application" are intended to represent any type of interactive application directed through the execution of input commands. there is By way of example only, interactive applications include applications for gaming, word processing, video processing, video game processing, and the like. Moreover, the terms introduced above are interchangeable.

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

FIG. 1 is a diagram of a system for multi-GPU processing when rendering images (eg, image frames) for an application, according to one embodiment of the present disclosure. According to an embodiment of the present disclosure, a system is configured to provide gaming over a network between one or more cloud gaming servers, and more specifically, multiple GPUs are coordinated to run single applications. configured to render one image. Cloud gaming involves running a video game on a server to generate game-rendered video frames. This is then sent to the client for display. Specifically, system 100 is configured for efficient multi-GPU rendering of geometry for applications by pre-testing screen regions (which may be interleaved or interleaved) before rendering.

While FIG. 1 illustrates an implementation of multi-GPU rendering of geometry across one or more cloud gaming servers of a cloud gaming system, other embodiments of the present disclosure may include standalone systems (e.g., personal computers or Efficient multi-GPU rendering of geometry for applications is provided by performing region testing during rendering in gaming consoles, including high-end graphics cards with multiple GPUs.

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

According to one embodiment of the present disclosure, system 100 provides gaming via cloud gaming network 190 . The game is running remotely from the client device 110 (eg, thin client) of the corresponding user playing the game. System 100 may provide gaming control for one or more users playing one or more games over cloud gaming network 190 over network 150 in either single-player mode or multiplayer mode. In some embodiments, the cloud gaming network 190 may include multiple virtual machines (VMs) running on the host machine's hypervisor. One or more virtual machines are configured to run game processor modules using hardware resources available to the host's hypervisor. Network 150 may include one or more communication 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 communication technologies. 5G is the fifth generation cellular network technology. A 5G network is a digital cellular network, where the service area covered by a provider is divided into small geographical areas called cells. Analog signals representing sounds and images are digitized within the phone, converted by an analog-to-digital converter, and transmitted as a stream of bits. All 5G wireless devices within a cell communicate over the air using local antenna arrays and low power automated transceivers (transmitters and receivers) within the cell, and this communication is reused in other cells. It takes place on a frequency channel assigned by the transceiver from a pool of frequencies. The local antenna is connected to the telephone network and the Internet by high-bandwidth fiber optic or wireless backhaul connections. As with other cell networks, when a mobile device traverses from one cell to another, it is automatically transferred to the new cell. Of course, a 5G network is merely an example of a type of communication network, and embodiments of the present disclosure may use previous generations of wireless or wireline communications, as well as later generations of wireline or wireless technologies that will come after 5G. good.

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

For example, multiple users may access cloud gaming network 190 via communications network 150 with corresponding client devices 110 configured to receive streaming media. In one embodiment, client device 110 is configured as a thin client to communicate with a backend server (eg, cloud gaming network 190) configured to provide computing functionality (eg, including game title processing engine 111). Intercommunication may be provided. 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 the video game running on the back end server may be It may be used to receive streaming content that it produces, or for 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 the video game. The game logic may then be stored on the local 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 be executing one or more game logic built on game title processing engine 111 to execute using CPU resources 163 and GPU resources 365 of game server 160. good. For example, game logic 115a may work with game title processing engine 111 and be running on game server 160 for one client, and game logic 115b may work with game title processing engine 111 and run on a second client. , and the game logic 115n cooperates with the game title processing engine 111 to execute on the game server 160 for the nth client. may

Specifically, a corresponding user's (not shown) client device 110 requests access to a game over a communications network 150 (eg, the Internet) and is generated by a video game executed by a game server 160 . is configured to render a displayed image (eg, an image frame) to be displayed. The encoded images are sent to the client device 110 and displayed in relation to the corresponding user. For example, a user may interact through client device 110 with an instance of a video game running 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. Game title processing engine 111 can support multiple video games with multiple game logics (eg, gaming applications), each game logic selectable by a user.

For example, the client device 110 is configured to interact with the game title processing engine 111 associated with the corresponding user's gameplay, eg, through input commands used to drive the gameplay. In particular, client device 110 may receive input from various types of input devices, such as game controllers, tablet computers, keyboards, gestures captured by video cameras, mice, touch pads, and the like. Client device 110 may be any type of computing device having at least a memory and processor module that can be connected to game server 160 via network 150 . The backend game title processing engine 111 is configured to generate rendered images. The rendered image is sent over network 150 and displayed on a corresponding display associated with client device 110 . For example, through a cloud-based service, game-rendered images may be submitted by an instance of a corresponding game (eg, game logic) running on game execution engine 111 of game server 160 . That is, client device 110 is configured to receive encoded images (eg, encoded from game-rendered images generated through execution of a video game) and to display the rendered images on display 11 . there is In one embodiment, display 11 includes an HMD (eg, for displaying VR content). In some embodiments, the rendered image is streamed to a smartphone or tablet, wirelessly or wired, directly from a cloud-based service or via a client device 110 (e.g., PlayStation Remote Play). good too.

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

In one embodiment, cloud gaming network 190 is a distributed gaming server system and/or architecture. Specifically, distributed game engines that execute game logic are configured as corresponding instances of corresponding games. Generally, a distributed game engine takes each of the functions of the game engine and distributes those functions to multiple processing entities for execution. Individual functions can also be distributed across one or more processing entities. Processing entities may be configured in different configurations (eg, physical hardware) and/or as virtual components or virtual machines and/or as virtual containers. A container differs from a virtual machine because it virtualizes an instance of a gaming application running on a virtualized operating system. The processing entity may use and/or rely on the servers and underlying hardware of cloud gaming network 190 (reside on one or more servers (computation nodes)). Servers may be placed in one or more racks. A distributed synchronization layer coordinates, allocates, and manages the execution of these functions for the various processing entities. As such, the distributed synchronization layer controls the execution of these functions to enable the generation of media (eg, video frames, audio, etc.) to the gaming application in response to controller inputs by the player. The distributed synchronization layer efficiently performs these functions across distributed processing entities (e.g., through load balancing) to distribute and reassemble critical game engine components/functions to make them more efficient. processing can take place.

FIG. 2 is a diagram of a typical multi-GPU architecture 200 in which multiple GPUs work together to render a single image of a corresponding application, according to one embodiment of the present disclosure. Of course, many architectures for multiple GPUs working together to render a single image are possible in various embodiments of the present disclosure, but are not explicitly described or illustrated. For example, multi-GPU rendering of geometry to an application by performing area tests during rendering may be performed between one or more cloud gaming servers of a cloud gaming system, or a standalone system (e.g., personal computer or gaming consoles, including high-end graphics cards with multiple GPUs).

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

For example, although four GPUs are shown in GPU resource 365 of multi-GPU architecture 200, any number of GPUs may be used when rendering images for an application. Each GPU is connected to a corresponding dedicated memory (eg, random access memory (RAM)) via high speed bus 220 . 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 via bus 220 to memory 210D (eg, RAM).

Furthermore, each GPU is connected to each other via bus 240 . Bus 240 may be approximately equal in speed or slower than bus 220 used for communication between the corresponding GPU and its corresponding memory, depending on the architecture. For example, GPU-A is connected via bus 240 to each of GPU-B, GPU-C, and GPU-D. GPU-B is also connected to each of GPU-A, GPU-C, and GPU-D via bus 240 . Additionally, GPU-C is connected to each of GPU-A, GPU-B, and GPU-D via bus 240 . Furthermore, GPU-D is connected to each of GPU-A, GPU-B, and GPU-C via bus 240 .

CPU 163 is connected to each of the GPUs via a slower 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.

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

Specifically, in one embodiment, game server 160 is configured to perform multi-GPU processing when rendering a single image of an application, with multiple GPUs working together to render the single image. , and/or render each of the one or more images in the sequence of images when executing the application. For example, in one embodiment, game server 160 may include a group of CPUs and GPUs configured to perform multi-GPU rendering of one or more of each image in an application's sequence of images. Here, one CPU and GPU group may be running graphics and/or rendering pipelines for applications. A group of CPUs and GPUs can be configured as one or more processing devices. As previously mentioned, GPUs and GPU groups may include CPUs 163 and GPU resources 365 . CPU 163 and GPU resources 365 are used for processor-based functions (e.g., 2D or 3D rendering, physics simulation, scripting, audio, animation, graphics processing, lighting, shading, rasterization, ray tracing, shadowing, culling, transformations, artificial intelligence, etc.).

GPU resources 365 are responsible for rendering objects (e.g., writing color or normal vector values for pixels of objects to multiple render targets—MRTs) and executing synchronous computation kernels (e.g., performing full-screen effects on the resulting MRTs). ) and/or configured to do so. The synchronous computations to be performed and the objects to be rendered are specified by commands contained in the rendering command buffer 325 executed by the GPU. In particular, GPU resource 365 is configured to render objects and perform synchronous computation (eg, while executing synchronous computation kernels) when executing commands from rendering command buffer 325 . , commands and/or actions may depend on other actions such that they are performed sequentially.

For example, GPU resource 365 may use one or more rendering command buffers 325 (eg, rendering command buffer 325a, rendering buffer 325b, . configured to render. In one embodiment, each GPU in GPU resources 365 may have its own command buffer. Alternatively, when substantially the same set of objects are being rendered by each GPU (e.g., due to the small size of the regions), the GPUs in GPU resources 365 may use the same command buffers or the same set of command buffers. may Additionally, each of the GPUs in GPU resource 365 may support that commands can be executed by one GPU but not by another. For example, a flag on a drawing command or predication in the rendering command buffer may cause a single GPU to execute one or more commands in the corresponding command buffer, while other GPUs may execute the command. ignore. 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.

Performing synchronous computation (eg, executing synchronous computation kernels) and rendering objects are part of the overall rendering. For example, if a video game is running at 60 Hz (e.g., 60 frames/sec), execution of all object rendering and synchronous computation kernels for an image frame is typically approximately 16.67 ms (e.g., 1 frame at 60 Hz). must be completed within As mentioned above, the actions taken when rendering an object and/or executing a synchronous computation kernel are ordered, and actions may depend on other actions (e.g., a command in the rendering command buffer may execution may need to complete before other commands in the rendering command buffer can execute).

Specifically, each of the rendering command buffers 325 contains various types of commands (eg, commands that affect the corresponding GPU configuration (eg, commands that specify the location and format of the render target), as well as commands to render objects. and/or commands to execute synchronous computational kernels). For illustrative purposes, synchronous computation when running a synchronous computation kernel includes full-screen effects when objects are all rendered to one or more corresponding Multiple Render Targets (MRTs). may include performing

Additionally, when GPU resources 365 render an object for an image frame and/or execute a synchronous computation kernel when generating an image frame, GPU resources 365 register each GPU 365a, 365b . Configured via For example, GPU 365a is configured through its registers 340 (eg, registers 340a, 340b . . . 340n) to perform its rendering or compute kernel execution in a particular manner. That is, the values stored in registers 340 are used in the hardware context ( for example, GPU configuration or GPU state). Each of the GPUs in GPU resources 365 is similarly configured such that GPU 365b performs its rendering or kernel processing in a particular manner through its registers 350 (eg, registers 350a, 350b . . . 350n). GPU 365n, through its registers 370 (e.g., registers 370a, 370b, . It may be configured to calculate

Some examples of GPU configuration include render target (eg, MRT) location and format. Another example of the GPU configuration is an operating procedure. For example, when rendering an object, the Z value of each pixel of the object can be compared to the Z-buffer in various ways. For example, write an object pixel only if the object Z value matches the value in the Z buffer. Alternatively, an object pixel can be written only if the object Z value is equal to or less than the value in the Z buffer. The type of test to perform is defined within the GPU configuration.

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

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 and information corresponding to each vertex in a 3D gaming world. A given object in the gaming world can be represented using polygons (eg, triangles) defined by vertices. The surfaces of the corresponding polygons are then processed through the graphics pipeline 400 to achieve final effects (eg, colors, textures, etc.). Vertex attributes include normal (e.g. which direction is perpendicular to that location in the geometry), color (e.g. RGB - red, green, blue tricolor, etc.), and texture coordinates/mapping information. may

Geometry processing stage 410 is responsible (and capable of) both vertex processing (eg, via a vertex shader) and primitive processing. Specifically, the geometry processing stage 410 defines a set of vertices that define a primitive and send it to the next stage of the graphics pipeline 400, as well as the positions (more precisely, homogeneous coordinates) for those vertices and other Various parameters may be output. The location is placed in the location cache 450 for access by later shader stages. Other parameters are placed in parameter cache 460, also for access by later shader stages.

Various operations may be performed by geometry processing stage 410 . For example, performing lighting and shadowing calculations on primitives and/or polygons. In one embodiment, since the geometry stage can process primitives, it can perform backface culling and/or clipping (e.g., testing against the view frustum) so that downstream stages (e.g., raster less load on the Rization stage 420, etc.). In another embodiment, the geometry stage may generate primitives (eg, with functionality equivalent to a traditional geometry shader).

The primitives output by geometry processing stage 410 are fed into rasterization stage 420, which converts the primitives into a raster image of pixels. Specifically, the rasterization stage 420 projects the objects in the scene onto a two-dimensional (2D) image plane defined by the viewing location (eg, camera location, user eye location, etc.) within the 3D gaming world. It is configured. At a simplistic level, rasterization stage 420 looks at each primitive to determine which pixels are affected by the corresponding primitive. Specifically, the rasterizer 420 divides primitives into pixel-sized fragments. Each fragment corresponds to a pixel in the display. It is important to note that when displaying an image, more than one fragment can contribute to the color of the corresponding pixel.

Further operations may be performed by the rasterization stage 420 as previously described. For example, viewing location clipping (identifying and ignoring fragments outside the view frustum) and culling (ignoring fragments obscured by closer objects). In connection with clipping, geometry processing stage 410 and/or rasterization stage 420 may be configured to identify and ignore primitives outside the view frustum defined by the viewing location within the gaming world. .

The pixel processing stage 430 may use the parameters (as well as other data) formed by the geometry processing stage to generate values such as the resulting color of the pixel. Specifically, the pixel processing stage 430 essentially performs shading operations on the fragments to determine how the color and brightness of the primitives vary with available lighting. For example, pixel processing stage 430 may determine depth, color, normal, and texture coordinates (eg, texture detail) for each fragment, and may also determine appropriate levels of light, darkness, and color for the fragment. may be determined. Specifically, the pixel processing stage 430 computes features for each fragment. For example, color and other attributes (eg, z-depth for distance from viewing location, and alpha value for transparency). In addition, pixel processing stage 430 applies lighting effects to fragments based on the available lighting affecting the corresponding fragments. In addition, pixel processing stage 430 may apply shadowing effects to each fragment.

The output of pixel processing stage 430 contains processed fragments (eg, texture and shading information) and is sent to the next stage of graphics pipeline 400, 440 output merger stage. Output merger stage 440 uses the output of pixel processing stage 430 as well as other data (eg, values already in memory) to generate the final color for the pixel. For example, output merger stage 440 may perform arbitrary blending of values between fragments and/or pixels determined from pixel processing stage 430 and values already written to the MRT for that pixel. good.

Color values for each pixel in the display may be stored in a frame buffer (not shown). Scanning these values into the corresponding pixels is done when displaying the corresponding image of the scene. Specifically, the display reads the color values from the frame buffer for each pixel row by row, left to right or right to left, top to bottom or bottom to top, or in any other pattern; Illuminate the pixels that use these pixel values when displaying the image.

With the detailed description of cloud gaming network 190 (eg, in game server 160) and GPU resources 365 of FIGS. 1-3, flow diagram 500 of FIG. 1 illustrates a method for performing graphics processing when performing multi-GPU rendering of geometry on image frames generated by an application by pre-testing the geometry on . In this manner, multiple GPU resources are used to efficiently render objects when executing an application. As noted above, various architectures may include multiple GPUs working together to render a single image by performing multi-GPU rendering of geometry for an application through region testing during rendering. Rendering may be performed, for example, within one or more cloud gaming servers of a cloud gaming system, or within a standalone system (e.g., a personal computer or gaming console that includes a high-end graphics card with multiple GPUs), etc. done.

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

At 520, the method includes dividing responsiveness for rendering graphics geometry among multiple GPUs based on multiple screen regions. That is, each GPU has a corresponding division or division (eg, corresponding screen region) of responsiveness known to all GPUs. More specifically, each GPU has a responsibility to render geometry within a corresponding set of screen regions of a plurality of screen regions. A corresponding set of screen areas includes one or more screen areas. For example, a first GPU has a first division of responsiveness for rendering objects within a first set of screen regions. The second GPU also has a second division of responsiveness for rendering objects within a second set of screen regions. This is repeated for the remaining GPUs.

At 530, the method includes assigning the first GPU a first piece or fragment of the geometry of the image frame generated during execution of the application for geometry testing. For example, an image frame may contain one or more objects. Each object may be defined by one or more pieces of geometry. That is, in one embodiment, geometry pre-testing and rendering is performed on a piece of geometry that is the entire object. In other embodiments, geometry pre-testing and rendering is performed on pieces of geometry that are part of the entire object.

For example, multiple GPUs are each assigned a corresponding portion of the geometry associated with the image frame. Specifically, for geometry pre-testing purposes, all parts of the geometry are assigned to corresponding GPUs. In one embodiment, the geometry may be evenly distributed among multiple GPUs. For example, if there are four GPUs in the plurality, each GPU may process a quarter of the geometry in the image frame. In other embodiments, geometry may be allocated unevenly among multiple GPUs. For example, in an example using four GPUs for multi-GPU rendering of image frames, one GPU may process more image frame geometry than another GPU.

At 540, the method includes performing a geometry pre-test on the first GPU to generate information on how pieces of geometry relate to multiple screen regions. Specifically, the first GPU generates information for a piece of geometry and how it relates to each of the multiple screen regions. For example, a geometry pre-test by a first GPU may determine whether a piece of geometry overlaps a particular screen area allocated to the corresponding GPU for object rendering. The first piece of geometry may overlap a screen region with responsiveness for object rendering by another GPU and/or overlap a screen region with responsiveness for object rendering by the first GPU. You can wrap. In one embodiment, before any of the GPUs render geometry, the shader in the corresponding command buffer performed by the first GPU performs geometry tests. In other embodiments, geometry testing is performed by hardware, such as in rasterization stage 420 of graphics pipeline 400 .

Geometry pre-testing is typically performed on all geometries of corresponding image frames simultaneously by multiple GPUs in an embodiment. That is, each GPU performs a geometry pre-test on its portion of the geometry of the corresponding image frame. Thus, the GPU's geometry pre-testing allows each GPU to know which pieces of geometry to render and which pieces of geometry to skip. Specifically, when the corresponding GPU performs the geometry pre-test, the corresponding GPU tests that portion of the geometry against screen regions of each of the multiple GPUs used to render the image frame. For example, if there are four GPUs, each GPU may perform a geometry test on a quarter of the geometry of the image frame, especially for the purpose of geometry testing, if the geometry is evenly allocated to the GPUs. Thus, even though each GPU performs geometry pre-tests only on its portion of the geometry of the corresponding image frame, geometry pre-tests are typically performed on all geometry of an image frame across multiple GPUs in embodiments. , the generated information indicates how all geometry (eg, pieces of geometry) in the image frame relate to all GPU screen areas. Each screen region is allocated to a corresponding GPU for object rendering, and/or rendering may be performed on pieces of geometry (eg, whole objects or portions of objects).

At 550, the method includes using information on each of the plurality of GPUs when rendering a piece of geometry (e.g., rendering the piece of geometry entirely or skipping rendering of the piece of geometry). to include that). That is, the information is used on each of multiple GPUs to render a piece of geometry. Send geometry test results (eg, information) to other GPUs so that information is known to each GPU. For example, geometry (eg, pieces of geometry) within an image frame are typically rendered concurrently by multiple GPUs in an embodiment. Specifically, when a piece of geometry overlaps any screen region allocated to the corresponding GPU for object rendering, the GPU renders that piece of geometry based on the information. On the other hand, when a piece of geometry does not overlap any screen regions allocated to the corresponding GPU for object rendering, the GPU may informedly skip rendering that piece of geometry. Therefore, the information allows all GPUs to render the geometry in the image frame more efficiently and/or avoid rendering that geometry altogether. For example, rendering may be done by shaders in corresponding command buffers to be executed by multiple GPUs. Shaders may be configured to perform one or both of geometry testing and/or rendering based on the corresponding GPU configuration, as described more fully below in FIGS. 7A, 12A, and 13A.

According to one embodiment of the present disclosure, in some architectures, if the corresponding rendering GPU receives the corresponding information in time to use it, the GPU uses that information to determine which geometry to render in the corresponding image. Used when deciding whether to That is, the information can be taken as a hint. Otherwise, the rendering GPU processes the piece of geometry as it normally does. Using the example where the information may indicate whether the geometry overlaps any screen regions assigned to the rendering GPU (e.g., the second GPU), if the information indicates that the geometry does not overlap: The rendering GPU may skip rendering geometry entirely. Also, if only pieces of geometry do not overlap, then the second GPU skips rendering at least those pieces of geometry that do not overlap any of the screen regions allocated to the second GPU for object rendering. good too. On the other hand, the information may indicate that there is overlap for the geometry, in which case the second or rendering GPU renders the geometry. The information may also indicate when a particular piece of geometry overlaps any screen area allocated to a second or rendering GPU for object rendering. In that case, the second or rendering GPU renders only the overlapping pieces of geometry. In yet other embodiments, the second GPU performs rendering normally (eg, renders geometry) if the information is not available, or if the information is not generated or received in time. Thus, information provided as hints, if received in time, can increase the overall efficiency of the graphics processing system. If the information is not received in time, the graphics processing system will still operate properly in the absence of such information.

In one embodiment, one GPU (eg, a pre-test GPU) is dedicated to performing geometry pre-tests and generating information. That is, the dedicated GPU is not used to render objects (eg, pieces of geometry) within the corresponding image frames. Specifically, as described above, graphics for an application are rendered using multiple GPUs. Responsibility for rendering graphics geometry is divided among multiple GPUs based on multiple screen regions (which may be interleaved). Each GPU has a corresponding division of responsiveness known to multiple GPUs. A geometry test is performed on the pieces of geometry of the image frame generated by the application on the pre-test GPU to generate information about each piece of geometry and its relationship to each of the multiple screen regions. Multiple pieces of geometry are rendered on each of multiple GPUs using information generated for each of the multiple pieces of geometry. That is, the information is used when rendering each piece of geometry by the corresponding rendering GPU from the GPU used to render the image frame.

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

Specifically, FIG. 6A is a 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 the four GPUs [GPU-A, GPU-B, GPU-C, and GPU-D] in a one-to-one relationship. For example, GPU-A is assigned to quadrant A, GPU-B is assigned to quadrant B, GPU-C is assigned to quadrant C, and GPU-D is assigned to quadrant D.

Geometry can be culled. For example, the CPU 163 can check the bounding box against each quadrant frustum and request each GPU to render only objects that overlap its corresponding frustum. As a result, each GPU is responsible for rendering only part of the geometry. For illustrative purposes, screen 610 shows pieces of geometry, each piece being a corresponding object, and screen 610 shows objects 611-617 (eg, pieces of geometry). Since no objects overlap quadrant A, GPU-A renders no objects. GPU-B renders objects 615 and 616 (because part of object 615 lies within quadrant B, the CPU culling test correctly concludes that GPU-B must render it ). GPU-C renders objects 611 and 612 . GPU-D renders objects 612 , 613 , 614 , 615 and 617 .

In FIG. 6A, when the screen 610A is divided into quadrants AD, the amount of work that each GPU has to do can be very different. This is because in some cases there can be disproportionate amounts of geometries in one quadrant. For example, quadrant A has no pieces of geometry, but quadrant D has five pieces of geometry or at least a portion of at least five pieces of geometry. Thus, GPU-A assigned to quadrant A is unused, while GPU-D assigned to quadrant D is disproportionately busy rendering objects in the corresponding image.

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

Specifically, four GPUs (eg, GPU-A, GPU-B, GPU-C, and GPU-D) are used to render images for the corresponding applications. Each GPU has a responsibility to render geometry that overlaps the corresponding region. That is, each GPU is assigned to a corresponding set of regions. For example, GPU-A has a responsibility to each of the regions labeled A in the corresponding set, and GPU-B has a responsibility to each of the regions labeled B in the corresponding set. GPU-C has a responsibility to each of the regions labeled C in the corresponding set, and GPU-D has a responsibility to each of the regions labeled D in the corresponding set. are doing.

Additionally, the regions are interleaved in a specific pattern. In order to interleave regions (and have a higher number of regions), the amount of work that each GPU has to do can be much more balanced. For example, the pattern interleaving the screen 610B includes alternating rows (eg, regions ABAB, etc. and regions CDCD, etc.). Other patterns of interleaving regions are also supported in embodiments of the present disclosure. For example, patterns include regions of repeated sequences, uniformly distributed regions, non-uniformly distributed regions, regions of repeatable row sequences, regions of random sequences, regions of random row sequences, and so on. good too.

Choosing the number of regions is important. For example, if the distribution of regions is too fine (eg, too many regions to be optimal), each GPU must still process most or all of the geometry. For example, it may be difficult for the GPU to check the object's bounding box against all regions for which it has responsiveness. Also, even if bounding boxes can be checked in a timely manner, small region sizes may result in each GPU having to process most of the geometry. This is because every object in the image overlaps at least one region of each GPU (e.g., a GPU can only partially overlap objects in at least one region within the set of regions assigned to that GPU). process the entire object, even if it overlaps one region).

As a result, the choice of the number of regions, the pattern of interleaving, etc. is important. Choosing too few or too many regions, or choosing too few or too many regions for interleaving, or choosing inefficient patterns for interleaving can lead to inefficiencies when performing GPU processing (e.g. , each GPU processes most or all of the geometry). In such a case, even if there are multiple GPUs to render the image, due to GPU inefficiency, it is not possible to support a corresponding increase in both screen pixel count and geometry density (i.e., four A GPU cannot write four times as many pixels and process four times as many vertices or primitives). The following embodiments are directed, inter alia, to improvements in culling strategy (FIGS. 7A-7C) and culling granularity (FIGS. 8A-8B).

7A-7C are diagrams illustrating rendering a single image and/or each of at least one or more images in an image sequence using multiple GPUs, in embodiments of the present disclosure. The choice of four GPUs is made merely to briefly illustrate multi-GPU rendering when rendering images while running an application, and of course any number of GPUs may be used for multi-GPU rendering in various embodiments. number of GPUs may be used.

Specifically, FIG. 7A is a diagram of a rendering command buffer 700A shared by multiple GPUs that jointly render a single image frame, according to one embodiment of the present disclosure. That is, in this example, multiple GPUs each use the same rendering command buffer (eg, buffer 700A), and each GPU executes all commands within the rendering command buffer. A plurality of commands (a complete set) are loaded into render command buffer 700A and used to render the corresponding image frames. Of course, one or more rendering command buffers may be used to generate the corresponding image frames. In one example, the CPU generates one or more draw calls for the image frame. A draw call includes commands that are placed in one or more rendering command buffers to be executed by one or more GPUs in GPU resources 365 of FIG. 3 when performing multi-GPU rendering of the corresponding image. included. In some implementations, CPU 163 may request one or more GPUs to generate all or part of the draw calls used to render the corresponding images. Additionally, FIG. 7A may show the full set of commands contained within the rendering command buffer 700A, or FIG. 7A may show a portion of the full set of commands contained within the rendering command buffer 700A. There are cases.

The GPUs typically render simultaneously when performing multi-GPU rendering of one or more of each image or images in an image sequence, in embodiments. Rendering an image can be decomposed into multiple phases. In each phase the GPUs must be synchronized and the faster GPU must wait until the slower GPU completes. The commands shown in FIG. 7A for rendering command buffer 700A illustrate one phase. Although FIG. 7A shows commands for only one phase, rendering command buffer 700A may contain commands for more than one phase when rendering an image. FIG. 7A shows only a portion of all commands and does not show commands for other phases. In the piece of rendering command buffer 700A shown in FIG. 7A illustrating one phase, there are four objects to render (eg, object 0, object 1, object 2, and object 3). This is shown in FIG. 7B-1.

As shown, the piece of rendering command buffer 700A shown in FIG. 7A is one or more executing commands for geometry tests, rendering of objects (eg, pieces of geometry), and commands from rendering command buffer 700A. Contains commands for configuring the state of the rendering GPU. For purposes of illustration only, the pieces of rendering command buffer 700A shown in FIG. Contains commands (710-728) to use. In some implementations, geometry pre-testing and rendering of objects to that image and/or execution of synchronous computational kernels must occur within a frame period. Two processing sections are shown within rendering command buffer 700A. Specifically, processing section 1 includes pre-testing or geometry testing 701 and section 2 includes rendering 702 .

Section 1 involves performing a geometry test 701 of objects in the image frame. Each object may be defined by one or more pieces of geometry. Pretests or geometry tests 701 may be performed by one or more shaders. For example, each GPU used in multi-GPU rendering of the corresponding image frame is assigned a portion of the image frame's geometry and a geometry test is performed. In one embodiment, all portions may be allocated for pre-testing. The assigned portion may include one or more pieces of geometry. Each piece may contain the entire object, or it may contain a portion of the object (eg, vertices, primitives, etc.). Specifically, a geometry test is performed on a piece of geometry to generate information about how that piece of geometry relates to each of the multiple screen regions. For example, a geometry test may determine whether a piece of geometry overlaps a particular screen area allocated to the corresponding GPU for object rendering.

As shown in FIG. 7A, the Geometry Test 701 of Section 1 (eg, Geometry Pretest) includes commands to configure the state of one or more GPUs that execute commands from the rendering command buffer 700A, and Geometry Tests. Contains commands for doing Specifically, the GPU state of each GPU is configured before the GPU performs geometry tests 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 the purpose of executing commands for geometry tests. As shown, command 710 configures the GPU state so that geometry test commands 711-712 can be performed properly. 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 tests on object2. Command 715 also configures the GPU state so that geometry test command 716 can perform geometry tests on object 3 . Of course, GPU states may be configured for one or more geometry test commands (eg, test commands 711 and 712).

As previously described, when executing commands in rendering command buffer 700A used for geometry testing and/or rendering objects and/or executing synchronous computation kernels on corresponding images, the values stored in the registers are , defines the hardware context (eg, GPU configuration) for the corresponding GPU. As shown, GPU state may change throughout the processing of commands in rendering command buffer 700A. Each subsequent section of the command may be used to configure the GPU state. As applied to FIG. 7A, as well as throughout the specification, when referring to setting GPU state, GPU state may be set in a variety of ways. For example, the CPU or GPU can set values in random access memory (RAM). The GPU checks the values in RAM. In another example, the state may be internal to the GPU, for example when calling the command buffer twice as a subroutine and the internal GPU state is different between the two subroutine calls.

Section 2 involves rendering 702 the objects in the image frame. pieces of geometry are rendered). Rendering 702 may be performed by one or more shaders in command buffer 700A. As shown in FIG. 7A, Section 2 Rendering 702 includes commands to configure the state of one or more GPUs that execute commands from rendering command buffer 700A and commands to render. Specifically, the GPU state for each GPU is configured before the GPU renders the corresponding object (eg, piece of geometry). For example, commands 721, 723, 725, and 727 are each used to configure the GPU state of one or more GPUs for the purpose of executing commands for rendering. As shown, command 721 configures the GPU state so that render command 722 can render object 0 . Command 723 configures the GPU state so that render command 724 can render object 1 . Command 725 configures the GPU state so that render command 726 can render object 2 . Command 727 also configures the GPU state so that render command 728 can render object 3 . Although FIG. 7A shows that GPU state is configured for each rendering command (eg, render object 0, etc.), it should be appreciated that GPU state may be configured for one or more rendering commands. may be configured.

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

For illustrative purposes only, four GPUs divide their corresponding screens into regions between them. As mentioned above, each GPU has the responsibility to render objects in a corresponding set of regions. A corresponding set contains one or more regions. In one embodiment, the rendering command buffer 700A is shared by multiple GPUs that cooperate to render a single image. That is, the GPUs used for multi-GPU rendering of one or more images in a single image or sequence of images share a common command buffer. In another embodiment, each GPU may have its own command buffer.

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

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

An example screen 700B is shown in FIG. 7B-1. Screen 700B shows an image including four objects rendered by multiple GPUs using rendering command buffer 700A of FIG. 7A, according to one embodiment of the present disclosure. According to one embodiment of the present disclosure, multi-GPU rendering of geometry enables applications to pre-test geometry against screen regions (which may be interleaved) before rendering pieces of geometry corresponding to objects in image frames. performed for

Specifically, the responsiveness to geometry rendering is divided by the screen area between multiple GPUs. Multiple screen regions are configured to reduce rendering time imbalances among multiple GPUs. For example, screen 700B shows the screen area responsiveness for each GPU when rendering the object of the image. Four GPUs (GPU-A, GPU-B, GPU-C, and GPU-D) are used to render the objects in the image shown on screen 700B. In order to balance pixel and vertex loads across GPUs, screen 700B is divided into smaller quadrants than shown in FIG. 6A. Additionally, screen 700B is divided into regions that can be interleaved. For example, interleaving includes multiline regions. Rows 731 and 733 each have regions A alternating with regions B. FIG. Rows 732 and 734 each have regions C alternating with regions D. FIG. More specifically, rows containing regions A and B alternate with rows containing regions C and D in the pattern.

As mentioned above, various techniques may be used when dividing the screen into regions to achieve GPU processing efficiency. For example, to increase or decrease the number of regions (e.g., to choose the correct amount of regions), to interleave regions, to interleave and select particular patterns when interleaving regions and/or sub-regions. Increase or decrease the number of regions, and so on. In one embodiment, each of the plurality of screen areas is of uniform size. In one embodiment, each of the plurality of screen regions are non-uniform in size. In still other embodiments, the number and sizing of multiple screen areas is dynamically varied.

Each GPU has a responsibility in rendering objects within a corresponding set of regions. Each set may contain one or more regions. GPU-A is therefore responsible for rendering objects in each A region in the corresponding set, GPU-B is responsible for rendering objects in each B region in the corresponding set, and GPU-C is responsible for rendering objects in each C region in the corresponding set, and GPU-D is responsible for rendering objects in each D region in the corresponding set. There may be GPUs with other responsiveness, and they may not render (eg, do asynchronous computation kernels that run over multiple frame periods, do culling for rendering GPUs, etc.).

The amount of rendering to do varies from GPU to GPU. FIG. 7B-2 illustrates a table showing the rendering each GPU makes when rendering the four objects of FIG. 7B-1, according to one embodiment of the present disclosure. As shown in the table, after the geometry pre-test, object 0 is rendered by GPU-B, object 1 is rendered by GPU-C and GPU-D, object 2 is rendered by GPU-A, It may be determined that it is being rendered by GPU-B and GPU-D, and that object 3 is being rendered by GPU-B, GPU-C and GPU-D. Since GPU A only needs to render object 2 and GPU D needs to render objects 1, 2 and 3, there may still be some unbalanced rendering. Overall, however, the interleaving of screen regions allows the rendering of objects within an image to be reasonably balanced between multiple GPUs used for multi-GPU rendering of images or rendering of one or more of each image in an image sequence. be done.

FIG. 7C illustrates the rendering of each object by each GPU when multiple GPUs work together to render a single image frame (eg, image frame 700B shown in FIG. 7B-1), according to one embodiment of the present disclosure. It is a figure which illustrates. Specifically, FIG. 7C illustrates object 0-3 rendering performed by each of the four GPUs (eg, GPU-A, GPU-B, GPU-C, and GPU-D) using the shared rendering command buffer 700A of FIG. 7A. rendering process.

Specifically, two rendering timing diagrams are shown against time axis 740 . Rendering timing diagram 700C-1 shows multi-GPU rendering of objects 0-3 of the corresponding image in one phase of rendering. Each GPU renders in the absence of any information about the overlap between objects 0-3 and the screen area. Rendering timing diagram 700C-2 shows multi-GPU rendering of objects 0-3 of the corresponding image in the same phase of rendering. Information generated during a screen region geometry test (eg, performed prior to rendering) is shared by each GPU and used to render objects 0-3 through the corresponding GPU pipeline. Rendering timing diagrams 700C-1 and 700C-2 respectively show the time each GPU takes to process each piece of geometry (eg, perform geometry testing and rendering). In one embodiment, the piece of geometry is the entire object. In another embodiment, the piece of geometry may be part of the object. For illustration purposes, the example of FIG. 7C shows a rendering of a piece of geometry. Each piece of geometry corresponds to an object (eg, in its entirety). In each of rendering timing diagrams 700C-1 and 700C-2, objects (eg, object primitives) that have no overlapping geometry (eg, object primitives) with at least one screen region (eg, within a corresponding set of regions) of the corresponding GPU. For example, a piece of geometry) is represented by a dashed box. On the other hand, objects that have geometry that overlaps at least one screen region (eg, within the corresponding set of regions) of the corresponding GPU are represented by boxes drawn with solid lines.

Rendering timing diagram 700C-1 shows the rendering of objects 0-3 using four GPUs (eg, GPU-A, GPU-B, GPU-C, and GPU-D). In rendering timing diagram 700C-1, vertical line 755a indicates the beginning of the rendering phase for the object, and vertical line 755b indicates the ending of the rendering phase for the object. The start and end points along the timeline 740 for the illustrated rendering phases represent synchronization points. Each of the four GPUs is synchronized when executing the corresponding GPU pipeline. For example, at vertical line 755b, which marks the end of a phase of rendering, all GPUs are forced to process object 0 through the corresponding graphics pipeline, with the slowest GPU (eg, GPU-B) running through the corresponding graphics pipeline before moving on to the next phase of rendering. I have to wait to finish rendering ~3.

In render timing diagram 700C-1, no geometry pre-testing is done. Therefore, each GPU must process each object through a corresponding graphics pipeline. A GPU does not render an object completely through the graphics pipeline if there are no pixels to draw for the object in any region (e.g., within the corresponding set) allocated to the corresponding GPU for object rendering. There is For example, only the geometry processing stage of the graphics pipeline is executed when objects do not overlap. However, this again takes some time to process.

Specifically, GPU-A does not render objects 0, 1, and 3 completely. This is because they do not overlap any of the screen regions (eg, in corresponding sets) allocated to GPU-A for object rendering. Renderings of these three objects are shown in boxes with dashed lines. This indicates that at least the geometry processing stage is done, but the graphics pipeline is not fully done. GPU-A renders object 2 completely. This is because the object overlaps at least one screen area allocated to GPU-A for rendering. A rendering of object 2 is shown in a box with a solid line. This indicates that all stages of the corresponding graphics pipeline are performed. Similarly, GPU-B does not fully render object 1 (indicated by the box with dashed lines) (i.e., does at least the geometry processing stage), but objects 0, 2, and 3 (indicated by boxes with solid lines). fully rendered. This is because these objects overlap at least one screen region (eg, in the corresponding set) allocated to GPU-B for rendering. Also, GPU-C does not fully render objects 0 and 2 (indicated by boxes with dashed lines) (i.e., does at least the geometry processing stage), but fully renders objects (indicated by boxes with solid lines). . This is because these objects overlap at least one screen region (eg, in the corresponding set) allocated to GPU-C for rendering. Furthermore, the GPU-D does not fully render object 0 (indicated by the box with dashed lines) (i.e., does at least the geometry processing stage), but renders objects 1, 2, and 3 (indicated by boxes with solid lines). Render completely. This is because these objects overlap at least one screen region (eg, in the corresponding set) allocated to GPU-D for rendering.

Rendering timing diagram 700C-2 shows geometry pre-testing 701' and rendering 702' of objects 0-3 using multiple GPUs. In rendering timing diagram 700C-2, vertical line 750a indicates the start of the phase of rendering for the object (eg, including geometry pretest and rendering), and vertical line 750b indicates the end of the phase of rendering for the object. The start and end points along the timeline 740 for the phases of rendering shown in timing diagram 700C-2 represent synchronization points. As mentioned above, each of the four GPUs is synchronized when executing the corresponding GPU pipeline. For example, at the vertical line 750b, which marks the end of the rendering phase, all GPUs have the slowest GPU to finish rendering objects 0-3 through their corresponding graphics pipelines before moving on to the next rendering phase. (eg GPU-B).

First, the GPU performs a geometry pre-test 701'. Each GPU performs a geometry pre-test on a subset of the image frame's geometry for all screen regions. Each screen area is assigned to a corresponding GPU for object rendering. As previously mentioned, each GPU is assigned a corresponding portion of the geometry associated with the image frame. A geometry pre-test determines how a particular piece of geometry relates to each of the screen regions (e.g., any screen region allocated to the corresponding GPU for object rendering (e.g., the corresponding ) in the set that overlaps or not). This information is shared by each GPU used to render the image frame. For example, the 701′ geometry pretest shown in FIG. and having GPU-D perform a geometry pre-test on object 3 . Depending on the object being tested, the time to do the geometry pretest can vary. For example, the geometry pretest for object 0 takes less time than running the geometry pretest for object 1 . This may be due to object sizing, number of overlapping screen regions, etc.

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

Vertical line 750a is aligned with vertical line 755a such that rendering timing diagrams 700C-1 and 700C-2, respectively, begin simultaneously to render objects 0-1. However, the rendering of objects 0-3 shown in rendering timing diagram 700C-2 takes less time than the rendering shown in rendering timing diagram 700C-1. That is, the vertical line 750b indicating the end of the rendering phase for the lower timing diagram 700C-2 appears earlier than the end of the rendering phase for the upper timing diagram 700C-1 indicated by the vertical line 755b. Specifically, when doing multi-GPU rendering of the geometry of an image to an application (including pre-testing the geometry against screen regions before rendering) and providing the result of the geometry pre-test as information (e.g., a hint): A speed increase 745 when rendering objects 0-3 is realized. As illustrated, 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.

Speed increases are realized through the generation and sharing of information generated during geometry pre-testing. For example, during geometry pretest, GPU-A generates information indicating that object 0 only needs to be rendered on GPU-B. Thus, GPU-B is informed that it should render object 0, and the other GPUs (eg GPU-A, GPU-C, and GPU-D) may skip rendering object 0 entirely. . This is because object 0 does not overlap any regions (eg, in the corresponding set) allocated to these GPUs for object rendering. For example, these GPUs are not required to run the geometry processing stage, but on the other hand, as shown in timing diagram 700C-1, even if these GPUs do not fully render object 0, without geometry pre-test This stage has been processed. Also during the geometry pretest, GPU-B states that object 1 should be rendered by GPU-C and GPU-D, even if GPU-A and GPU-B skip rendering of object 1 entirely. Generate good information. This is because Object 1 does not overlap any regions (eg, in respective corresponding sets) allocated to GPU-A or GPU-B for object rendering. Also during the geometry pretest, GPU-C states that object 2 should be rendered by GPU-A, GPU-B, and GPU-D, and GPU-C skips rendering of object 2 entirely. Generates information indicating that This is because object 2 does not overlap any regions (eg, in the corresponding set) allocated to GPU-C for object rendering. Additionally, during the geometry pretest, GPU-D states that object 3 should be rendered by GPU-B, GPU-C, and GPU-D, and GPU-A skips rendering of object 3 entirely. Generates information indicating that This is because object 3 does not overlap any region (eg, in the corresponding set) allocated to GPU-A for object rendering.

Information generated from the geometry pre-test is shared between GPUs so each GPU can decide which objects to render. Therefore, after the geometry pre-test is done and the results from the test are shared by all GPUs, each GPU has information on which objects or pieces of geometry the corresponding GPU needs to render. . For example, GPU-A renders object 2, GPU-B renders objects 0, 2, and 3, GPU-C renders objects 1 and 3, and GPU-D renders objects 1, 2, and Render 3.

Specifically, GPU A performs geometry processing on object 1 and determines that object 1 can be skipped by GPU-B. This is because Object 1 does not overlap any regions (eg, in the corresponding set) allocated to GPU-B for object rendering. Additionally, Object 1 is not fully rendered by GPU-A. This is because object 1 does not overlap any regions (eg, in the corresponding set) allocated to GPU-A for object rendering. Since the determination that object 1 does not overlap any regions allocated to GPU-B is made before GPU-B begins geometry processing for object 1, GPU-B skips rendering object 1. FIG.

Figures 8A-8B show object tests for screen areas 820A and 820B. Screen regions may be interleaved (eg, screen regions 820A and 820B represent portions of the display). Specifically, multi-GPU rendering of objects is performed by performing a geometry test on each of one or more image frames in a single image frame or sequence of image frames before rendering the object in the screen. As shown, GPU-A is assigned the responsibility of rendering objects within screen region 820A. GPU-B is assigned the responsibility of rendering objects within screen region 820B. Information for a "piece of geometry" is generated. A piece of geometry can be an entire object or a portion of an object. For example, a piece of geometry can be object 810 or part of object 810 .

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

FIG. 8B is a diagram illustrating testing of a portion of an object for screen regions and/or screen sub-regions when multiple GPUs work together to render a single image frame, according to one embodiment of the present disclosure. That is, a piece of geometry can be part of an object. For example, object 810 may be divided into pieces, and the geometry that draw calls use or generate is subdivided into smaller pieces of geometry. In one embodiment, each piece of geometry is roughly the size that a position cache and/or parameter cache are allocated. In that case, information (eg, a hint or hints) is generated for those smaller pieces of geometry during geometry testing. As mentioned above, the information is used by the rendering GPU.

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

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

In another embodiment, geometry pre-testing on a piece of geometry can be done at the hardware rasterization stage. For example, the hardware scan converter is configured to perform a geometry pre-test such that the scan converter generates information about all screen regions allocated to multiple GPUs for object rendering of the corresponding image frames. You may do so.

In still other embodiments, a piece of geometry can be a primitive. That is, some of the objects used for geometry pre-testing may be primitives. Thus, information (eg, hints) generated by one GPU during geometry pretest indicates whether individual triangles (eg, representing primitives) should be rendered by another rendering GPU.

In one embodiment, the information generated during the geometry pretest and shared by the GPUs used for rendering includes any screen regions (e.g., corresponding set ) and the number of overlapping primitives (eg, number of primitives remaining). Information may also include the number of vertices used to construct or define these primitives. That is, the information includes the number of remaining vertices. Therefore, when rendering, the corresponding rendering GPU may use the supplied vertex count to allocate space for the position and parameter caches. For example, in one embodiment, rendering efficiency may be increased because no space is allocated for vertices that are not needed.

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

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

9A-9C illustrate various strategies for allocating screen area to corresponding GPUs when multiple GPUs work together to render a single image, according to one embodiment of the present disclosure. Various techniques may be used when dividing the screen into regions to achieve GPU processing efficiency. For example, increasing or decreasing the number of regions (e.g., to select the correct amount of region), interleaving regions, or increasing the number of regions to interleave and select a particular pattern when interleaving regions. increase or decrease, and so on. For example, multiple GPUs perform multi-GPU rendering of geometry for image frames generated by an application by pre-testing the geometry against interleaved screen regions before rendering objects in the corresponding images. is configured to The configuration of the screen regions of Figures 9A-9C is designed to reduce even the slight imbalance in rendering times between multiple GPUs. The complexity of the test (eg, overlapping corresponding screen regions) varies depending on how the screen regions were allocated to the GPU. As shown in the diagrams shown in FIGS. 9A-9C, the bold box 910 outlines the corresponding screen or display used when rendering the image.

In one embodiment, each of the plurality of screen regions or regions is of uniform size. In one embodiment, each of the plurality of screen regions are non-uniform in size. In still other embodiments, the number and sizing of screen areas in the plurality of screen areas dynamically change.

Specifically, FIG. 9A illustrates a simple pattern 900A for screen 910 . Each screen area is of uniform size. For example, the size of each region may be a rectangle with dimensions that are powers of two pixels. For example, each region may be 256×256 pixels in size. As shown, the region allocation is a checkboard pattern, with one row of A and B regions alternating with another row of B and C regions. Pattern 900A can be easily tested during geometry pre-test. However, some rendering inefficiencies may exist. For example, the screen area allocated to each GPU is substantially different (ie, less coverage for screen regions C and D within screen 910). This can lead to an imbalance in rendering times for each GPU.

FIG. 9B illustrates a pattern 900B of screen areas for screen 910 . Each screen or subregion is of uniform size. Screen area is allocated and distributed to reduce the rendering time imbalance between GPUs. For example, pattern 900B assigns GPUs to screen regions so that the number of screen pixels assigned to each GPU across screen 910 is approximately equal. That is, the screen areas are allocated to the GPUs such that the screen areas or coverage within the screen 910 are equal. For example, if each region may be 256×256 pixels in size, the coverage of each region within screen 910 is approximately the same. Specifically, the set of screen regions A covers an area with a size of 6×256×256 pixels, the set of screen regions B covers an area with a size of 5.75×256×256 pixels, and the screen regions The set of C covers an area of size 5.5×256×256 pixels and the set of screen regions D covers an area of size of 5.5×256×256 pixels.

A pattern 900C of screen areas for screen 910 is illustrated in FIG. 9C. Each screen area is non-uniform in size. That is, the screen regions assigned responsiveness to rendering objects on the GPU may not be uniform in size. Specifically, the screen 910 is divided so that each GPU is assigned the same number of pixels. For example, if a 4K display (3840×2160) is divided vertically into 4 equal regions, each region will be 520 pixels high. However, GPUs typically do most of the work in 32x32 blocks of pixels, and 520 pixels is not a multiple of 32 pixels. Thus, in one embodiment, pattern 900C may include blocks that are 512 pixels high (a multiple of 32) and other blocks that are 544 pixels high (also a multiple of 32). Other embodiments may use blocks of different sizes. Pattern 900C shows that equal numbers of screen pixels are assigned to each GPU by using non-uniform screen areas.

In yet another embodiment, the screen area is dynamically selected as the application's needs when rendering images change over time. For example, if it is known that most of the rendering time is spent on the bottom half of the screen, then an approximately equal number of screen pixels in the bottom half of the display should be allocated to each GPU used to render the corresponding image. It is convenient to allocate regions to That is, the area allocated to each GPU used to render the corresponding image may be dynamically changed. For example, changes may be applied based on game modes, different games, screen sizes, patterns selected for regions, and the like.

FIG. 10 is a diagram illustrating various distributions of GPU allocations to pieces of geometry for the purpose of geometry pre-testing, according to one embodiment of the present disclosure. That is, FIG. 10 illustrates the distribution of responsiveness for generating information during geometry pre-testing among multiple GPUs. As previously mentioned, each GPU is assigned a corresponding portion of the geometry of the image frame. The portion may be further divided into objects, parts of objects, geometries, pieces of geometry, and the like. Geometry pre-testing involves determining whether a particular piece of geometry overlaps any screen region or screen regions allocated to the corresponding GPU for object rendering. Geometry pre-testing is typically performed by the GPU on all geometries (eg, all pieces of geometry) of the corresponding image frame at the same time in embodiments. In this way, the geometry tests are done cooperatively by the GPUs so that, as mentioned above, each GPU knows which pieces of geometry to render and which pieces of geometry to skip rendering. can be done.

As shown in FIG. 10, each piece of geometry can be an object, part of an object, or the like. For example, as noted above, a piece of geometry can be a portion of an object (eg, a piece that is approximately the size that a position and/or parameter cache is allocated). Purely for illustrative purposes, let object 0 (eg, designated to be rendered by command 722 in render command buffer 700A) be represented by pieces "a", "b", "c", "d", "e , and “f” (eg, object 810 in FIG. 8B). It also splits object 1 (eg, designated to be rendered by command 724 in rendering command buffer 700A) into pieces "g", "h", and "i". In addition, object 2 (eg, designated to be rendered by command 724 in render command buffer 700A) is rendered by pieces "j", "k", "l", "m", "n", and "o". ”. Pieces may be ordered (eg, a to o) for the purpose of distributing responsiveness to geometry tests to GPUs.

Distribution 1010 (eg, ABCDABCDABCD... rows) shows the even distribution of responsiveness to geometry tests among multiple GPUs. Specifically, let a GPU take the first quarter of the geometry (e.g., in a block, say GPU A uses 'a', 'b', 'c', and Interleave the assignments to the GPUs instead of taking the first 4 pieces out of a total of approximately 16 pieces including "d"), letting the second GPU take the second quarter, etc. That is, consecutive pieces of geometry are assigned to different GPUs. For example, piece 'a' is assigned to GPU-A, piece 'b' is assigned to GPU-B, piece 'c' is assigned to GPU-C, piece 'd' is assigned to GPU-D, Piece "e" is assigned to GPU-A, piece "f" is assigned to GPU-B, piece "g" is assigned to GPU-C, and so on. As a result, geometry test processing is roughly balanced across GPUs (eg, GPU-A, GPU-B, GPU-C, and GPU-D).

Distribution 1020 (eg, rows ABBCDABBCDABBCD...) indicates an asymmetric distribution of responsiveness to geometry tests among multiple GPUs. Asymmetric distribution may be advantageous if certain GPUs spend more time performing geometry tests than other GPUs when rendering corresponding image frames. For example, one GPU may have finished rendering an object for a previous frame or frames of the scene earlier than other GPUs, and thus (this frame is also expected to finish earlier). ), the GPU can be allocated more pieces of geometry for geometry testing. Again, the assignments to GPUs are interleaved. As shown, GPU-B is allocated more pieces of geometry for geometry pre-test than the other GPUs. To illustrate, piece 'a' is assigned to GPU-A, piece 'b' is assigned to GPU-B, piece 'c' is also assigned to GPU-B, and piece 'd' is assigned to GPU-C. piece 'e' is assigned to GPU-D, piece 'f' is assigned to GPU-A, piece 'g' is assigned to GPU-B, and piece 'h' is also assigned to GPU-B. , piece “i” is assigned to GPU-C, and so on. The allocation of geometry tests to GPUs may not be balanced, but the full phase combined processing (e.g., geometry pre-test and geometry rendering) may turn out to be roughly balanced. (Eg, each GPU spends approximately the same amount of time performing geometry pre-testing and geometry rendering).

11A-11B illustrate the use of statistics for one or more image frames when assigning responsiveness to geometry tests among multiple GPUs. For example, based on statistics, some GPUs may process more or fewer pieces of geometry during geometry testing to produce useful information when rendering.

Specifically, FIG. 11A illustrates the geometry of a current image frame using pre-testing and rendering of the geometry of previous image frames with multiple GPUs and statistics collected during rendering, according to one embodiment of the present disclosure. FIG. 10 illustrates the pre-testing of , and influencing the assignment of the pre-tests to multiple GPUs in the current image frame. Purely for illustrative purposes, in the second frame 1100B of FIG. 11A, GPU-B processes twice as many pieces of geometry as the other GPUs (eg, GPU-A, GPU-C, and GPU-D). (for example, during pre-testing). Allocating more pieces of geometry to GPU-B and performing a geometry pre-test on the current image frame will allow the statistics gathered during the rendering of the previous image frame or previous image frames based on.

For example, timing diagram 1100A shows geometry pretest 701A and rendering 702A for a previous image frame. Four GPUs (eg, GPU-A, GPU-B, GPU-C, and GPU-D) are used for both processes. The previous image frame geometry (eg, piece of geometry) allocation is evenly distributed among the GPUs. This is shown by the roughly balanced performance of the geometry pretest 701A by each GPU.

Rendering statistics collected from one or more image frames may be used to determine how to perform geometry testing and rendering of the current image frame. That is, the statistics may be provided as information for use in geometry testing and rendering subsequent image frames (eg, the current image frame). For example, statistics collected while rendering objects (eg, pieces of geometry) in previous image frames may indicate that GPU-B finished rendering earlier than the other GPUs. Specifically, GPU-B spends idle time 1130A after rendering that portion of geometry that overlaps any screen regions (e.g., in corresponding sets) allocated to GPU-B for object rendering. have. The other GPU-A, GPU-C, and GPU-D each perform rendering until approximately the end 710 of the corresponding frame period of the previous image frame.

A previous image frame and a current image frame may be generated for a particular scene when running an application. Therefore, objects from scene to scene may be approximately similar in number and location. In that case, the time to perform geometry pre-testing and rendering is similar for the GPU between multiple image frames in an image frame train. That is, based on statistics, it is reasonable to assume that GPU-B also has idle time when doing geometry testing and rendering in the current image frame. Therefore, GPU-B may be allocated more pieces of geometry for geometry pre-test in the current frame. For example, having GPU-B process more pieces of geometry during geometry pre-testing results in GPU-B finishing about the same time as the other GPUs after rendering the object in the current image frame. That is, GPU-A, GPU-B, GPU-C, and GPU-D each perform rendering until approximately the end 711 of the corresponding frame period of the current image frame. In one embodiment, the total time to render the current image frame is reduced, resulting in less time to render the current image frame when using the rendering statistics. Thus, geometry pre-testing (e.g., distribution of geometry (e.g., pieces of geometry) allocations among GPUs in the current image frame) using statistics on the previous frame and/or rendering of previous frame(s) ) may be adjusted.

FIG. 11B is a flow diagram 1100B illustrating a method for performing graphics processing, pre-testing and rendering geometry of previous image frames with multiple GPUs, and collecting during rendering, according to one embodiment of the present disclosure. using the statistics obtained to influence the assignment of pre-tests of the geometry of the current image frame to multiple GPUs in the current image frame. The diagram of FIG. 11A illustrates using statistics in the method of flow diagram 1100B to determine the allocation distribution of geometry (eg, pieces of geometry) among GPUs for an image frame. As noted above, various architectures may include multiple GPUs working together to render a single image by performing multi-GPU rendering of geometry for an application. For example, within one or more cloud gaming servers of a cloud gaming system, or within a standalone system (eg, a personal computer or gaming console that includes a high-end graphics card with multiple GPUs, etc.).

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

At 1130, the method includes rendering a first plurality of pieces of geometry on the GPU of previous image frames generated by the application. For example, timing diagram 1100A illustrates the timing of geometry testing of a piece of geometry and rendering of an object (eg, piece of geometry) in a previous image frame. At 1140, the method includes generating statistics for the rendering of previous image frames. That is, statistics may be collected when rendering previous image frames.

At 1150, the method includes assigning a second plurality of pieces of geometry of the current image frame generated by the application to a plurality of GPUs for geometry testing based on the statistical values. That is, these statistics may be used to allocate the same, fewer, or more pieces of geometry for a geometry test to a particular GPU when rendering the next or current image frame. In some cases, statistics may indicate that pieces in the second plurality of pieces of geometry should be evenly distributed among GPUs when geometry testing is performed.

In another case, when performing geometry tests, statistics may indicate that pieces in the second plurality of pieces of geometry should be unevenly allocated to GPUs. For example, a statistic may indicate that GPU-B finished rendering before any of the other GPUs in the previous image frame, as shown in timeline 1100A. Specifically, before the second GPU (eg, GPU-A) finishes rendering the first plurality of pieces of geometry (eg, a portion of the piece of geometry), the first GPU (eg, GPU-A) GPU-B) may be determined to have finished rendering the first plurality of pieces of geometry. As described above, the first GPU (eg, GPU-B) renders the first plurality of pieces of geometry that overlap any screen regions allocated to the first GPU for object rendering. Rendering one or more pieces, a second GPU (e.g., GPU-A) renders a first plurality of pieces of geometry that overlap any screen regions allocated to the second GPU for object rendering. Render one or more pieces of the pieces. Therefore, based on the statistics, the time required by the first GPU (eg, GPU-B) to render the second plurality of pieces of geometry is estimated by the second GPU (eg, GPU-A) , so more pieces of geometry may be allocated to the first GPU for geometry pretesting when rendering the current image frame. For example, a second plurality of pieces of the first number of geometry may be assigned to a first GPU (eg, GPU-B) for geometry testing, and a second plurality of pieces of the second number of geometry , may be assigned to a second GPU (eg, GPU-A) for geometry testing. The first number is greater than the second number (if the time imbalance is large enough, GPU-A may not be allocated any pieces). Thus, GPU-B processes more pieces of geometry during geometry testing than GPU-A. For example, timing diagram 1100B shows that GPU-B is allocated more pieces of geometry and spends more time performing geometry tests than the other GPUs.

At 1160, the method performs a geometry pre-test on the second plurality of pieces of geometry in the current image frame to test each piece of the second plurality of pieces of geometry and its on each of the plurality of screen regions. including generating information about relationships. A geometry pre-test is performed on each of the multiple GPUs based on allocation. A geometry pre-test is performed on multiple pieces of geometry of the image frame generated by the application in pre-test GP to generate information about each piece of geometry and its relationship to each of multiple screen regions.

At 1170, the method includes rendering the plurality of pieces of geometry during the rendering phase using the information generated for each of the second plurality of pieces of geometry (e.g., the corresponding GPU (including completely rendering a piece of geometry, or skipping rendering of that piece of geometry). Rendering is typically done concurrently on each GPU in an embodiment. Specifically, multiple pieces of geometry for the current image frame are rendered on each of multiple GPUs using the information generated for each piece of geometry.

In other embodiments, the distribution of pieces of geometry to GPUs to generate information is dynamically adjusted. That is, the assignment of pieces of geometry to the current image frame for geometry pretesting may be dynamically adjusted during rendering of the current image frame. For example, in the example of timing diagram 1100B, it may be determined that GPU-A was performing geometry pretests on its assigned piece of geometry at a slower rate than expected. Thus, a piece of geometry that was assigned to GPU-A for geometry pretesting can be reassigned on the fly (e.g., reassign a piece of geometry from GPU-A to GPU-B), and GPU- B is now tasked with performing a geometry pre-test on that piece of geometry during the frame period used to render the current image frame.

Figures 12A-12B illustrate another strategy for handling the rendering command buffer. Earlier, certain strategies were described in connection with FIGS. 7A-7C. Here, the command buffer contains commands to perform geometry pretests on an object (eg, piece of geometry) followed by commands to render the object (eg, piece of geometry). Figures 12A-12B show a geometry pre-testing and rendering strategy that uses shaders that can do either operation depending on the GPU configuration.

Specifically, FIG. 12A illustrates a shader configured to both pre-test and render the geometry of an image frame in two passes through a portion of command buffer 1200A, according to one embodiment of the present disclosure. FIG. 10 is a diagram illustrating the use; That is, the shader used to execute the commands in command buffer 1200A may be configured to either perform geometry pre-testing when properly configured, or render when properly configured. good.

As shown, the portion of command buffer 1200A shown in FIG. 12A is executed twice, with different actions resulting from each execution. The first execution results in geometry pre-testing and the second execution results in geometry rendering. This can be achieved in various ways. For example, the portion of the command buffer shown at 1200A can be explicitly called twice as a subroutine. Before each call, different states (eg, register settings or values in RAM) are explicitly set to different values. Alternatively, the portion of the command buffer shown at 1200A can be implicitly executed twice, for example by using special commands to mark the beginning and end of that portion and executing it twice, and This is possible by implicitly setting different configurations (eg, register settings) for the first and second executions of that portion of the buffer. When a command in a portion of command buffer 1200A is executed (e.g., a command to set state or a command to run a shader), based on the GPU state, the result of the command will be different (e.g., do a geometry pre-test). rendering). That is, commands in command buffer 1200A may be configured for geometry pre-testing or rendering. Specifically, a portion of command buffer 1200A contains commands for configuring one or more GPU states that execute commands from rendering command buffer 1200A and, depending on the state, either geometry pretest or rendering. and commands to run shaders to run. For example, commands 1210, 1212, 1214, and 1216 are each used to configure one or more GPU states for the purpose of executing shaders that either perform geometry pretesting or rendering depending on the state. . As shown, command 1210 configures the GPU state such that shader 0 may be executed via command 1211 to perform either geometry pretesting or rendering. Command 1212 also configures the GPU state so that shader 1 may 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 either geometry pretesting or rendering. Finally, command 1216 configures the GPU state so that shader 3 can be executed via command 1217 to perform either geometry pretesting or rendering.

In a first traversal 1291 through command buffer 1200A, the corresponding Shaders perform geometry pretests. For example, shader 0 is configured to perform a geometry pre-test on object 0 (eg, a piece of geometry) (eg, based on the object shown in FIG. 7B-1), shader 1 is configured to perform Shader 2 is configured to perform a geometry pre-test on object 2, and Shader 3 is configured to perform a geometry pre-test on object 3. is configured to

In one embodiment, commands may be skipped or interpreted differently based on GPU state. For example, certain commands that set state (parts 1210, 1212, 1214, and 1216) may be skipped based on the GPU state that is explicitly or implicitly set as described above. For example, when configuring shader 0, which is executed via command 1210, less GPU state needs to be configured for geometry pretest than when configuring for rendering geometry. It may be useful to skip unnecessary parts of the configuration. This is because setting the GPU state can have overhead. To give another example, the specific commands that set states (parts of 1210, 1212, 1214, and 1216) differ based on the GPU state that is explicitly or implicitly set as described above. may be interpreted. For example, if shader 0 executed via command 1210 needs to configure a different GPU state for geometry pre-testing than it is configured for rendering geometry, or A case where shader 0, which runs in , requires different inputs for geometry pretest and geometry rendering.

In one embodiment, shaders configured for geometry pretest do not allocate space for position and parameter caches, as described above. In another embodiment, either pre-testing or rendering is performed using a single shader. This can be done in various ways. For example, through an external hardware state that the shader can check (e.g., as set explicitly or implicitly as described above), or through input to the shader (e.g., the command buffer (as set by commands that are interpreted differently on the first and second pass through).

In a second traversal 1292 through command buffer 1200A, the corresponding A shader performs the rendering of a piece of geometry for the corresponding image frame. For example, shader 0 is configured to perform rendering of object 0 (eg, piece of geometry) (eg, based on the object shown in FIG. 7B-1). Also, shader 1 is configured to render object 1, shader 2 is configured to render object 2, and shader 3 is configured to render object 3. It is

FIG. 12B illustrates graphics processing that includes both pre-testing and rendering the geometry of an image frame using the same set of shaders in two passes through a portion of the command buffer, according to one embodiment of the present disclosure; 1200B is a flow diagram illustrating a method for performing. As noted above, various architectures may include multiple GPUs working together to render a single image by performing multi-GPU rendering of geometry for an application. For example, within one or more cloud gaming servers of a cloud gaming system, or within a standalone system (eg, a personal computer or gaming console that includes a high-end graphics card with multiple GPUs), and the like.

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

At 1230, the method includes assigning multiple pieces of geometry for the image frame to multiple GPUs for geometry testing. Specifically, each of the multiple GPUs is assigned a corresponding portion of the geometry associated with the image frame for the purpose of geometry testing. As previously mentioned, the allocation of pieces of geometry may be evenly or unevenly distributed. In embodiments, each portion includes one or more pieces of geometry, or potentially no pieces of geometry.

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

At 1250, the method includes performing geometry pretests on multiple pieces of geometry on multiple GPUs to generate information about each piece of geometry and its relationship to each of multiple screen regions. As described above, the geometry pre-test determines whether a piece of geometry overlaps any screen regions (e.g., in the corresponding set) allocated to the corresponding GPU for object rendering. good too. Geometry pre-testing is typically done in an embodiment by a GPU on all the geometry of the corresponding image frame at the same time, so each GPU knows which piece of geometry to render and which piece of geometry to skip. can know This concludes the first traversal through the command buffer. Shaders may be configured to perform geometry pre-testing and/or rendering, respectively, depending on GPU state.

At 1260, the method includes loading a second GPU state that configures one or more shaders to perform rendering. As noted above, depending on the GPU state, the corresponding shader may 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 FIG. 12A, based on this second GPU state, shader 0 executed by command 1211 is configured to perform rendering.

At 1270, the method includes using the information generated for each of the plurality of pieces of geometry when rendering the plurality of pieces of geometry on each of the plurality of GPUs (e.g., the corresponding GPU (to include rendering a piece of geometry entirely or skipping the rendering of that piece of geometry). As previously mentioned, the information may indicate whether a piece of geometry overlaps any screen regions (eg, in the corresponding set) allocated to the corresponding GPU for object rendering. This information may be used to render each of the multiple pieces of geometry on each of multiple GPUs, each GPU having at least one screen (e.g., , in the corresponding set) can be efficiently rendered. This concludes the second traversal through the command buffer. Shaders may be configured to perform geometry pre-testing and/or rendering, respectively, depending on GPU state.

Figures 13A-13B illustrate another strategy for handling the rendering command buffer. Earlier, certain strategies were described in connection with FIGS. 7A-7C. Here, the command buffer contains commands for geometry pre-testing of objects (eg, pieces of geometry) followed by commands to render the objects (eg, pieces of geometry). Also in FIGS. 12A-12B, another approach using shaders that can perform either operation depending on the GPU configuration was described. Figures 13A-13B illustrate geometry testing and rendering strategies using shaders that can either perform geometry pre-testing or rendering. Here, according to embodiments of the present disclosure, the process of geometry pre-testing and rendering is interleaved for different sets of pieces of geometry.

Specifically, FIG. 13A is a diagram illustrating using a shader configured to perform both geometry pre-testing and rendering. According to one embodiment of the present disclosure, geometry pre-testing and rendering performed on different sets of pieces of geometry are interleaved using separate portions of the corresponding command buffer 1300A. That is, instead of running a portion of command buffer 1300A from start to finish, dynamically configure command buffer 1300A such that geometry pretesting and rendering are interleaved for different sets of pieces of geometry. Execute. For example, in the command buffer, some shaders (eg, executed via commands 1311 and 1313) are configured to perform geometry pretests on a first set of pieces of geometry. After performing geometry testing, these same shaders (executed by commands 1311 and 1313, for example) are then configured to render. After rendering to the first set of pieces of geometry, other shaders in the command buffer (e.g., executed via commands 1315 and 1317) render to the second set of pieces of geometry. It is configured to perform a geometry pre-test against After performing the geometry pretest, these same shaders (executed, for example, via commands 1315 and 1317) are then configured to render a second set of geometry. Pieces are done with these commands. The advantage of this strategy is that it allows dynamic handling of imbalances between GPUs, for example, by using asymmetric interleaving of geometry tests throughout rendering. An example of asymmetric interleaving of geometry tests was previously introduced in distribution 102 of FIG.

Geometry pre-testing and interleaving of rendering are done dynamically, so configuration of the GPU (eg, via register settings or values in RAM) is done implicitly. That is, aspects of GPU configuration occur outside the command buffer. For example, a GPU register may be set to 0 (indicating that geometry pre-testing should be done) or 1 (indicating that rendering should be done). The command buffer interleave traversal and setting of this register may be controlled by the GPU based on the number of objects processed, primitives processed, imbalance between GPUs, and so on. Alternatively, values in RAM can be used. As a result of this external configuration (meaning setting the command buffer externally), when a command in a portion of the command buffer 1300A (e.g., a command to set state or a command to execute a shader) is executed, Based on the GPU state, the command will have different results (e.g., do a geometry pretest versus do a render). That is, the commands in command buffer 1300A may be configured for geometry pretest 1391 or rendering 1392 . Specifically, some of the command buffers 1300A include commands to configure the state of one or more GPUs executing commands from the rendering command buffer 1300A, and depending on the state, either geometry pretesting or rendering. and commands to run shaders to run. For example, commands 1310, 1312, 1314, and 1316 are each used to configure the state of the GPU for the purpose of executing shaders that either perform geometry pretesting or rendering depending on the state. As shown, command buffer 1310 configures the GPU state such that shader 0 can be executed via commands 1311 to either geometry pretest or render object 0 . Command buffer 1312 also configures the GPU state so that shader 1 can be executed via commands 1313 to either geometry pre-test or render object 1 . Command buffer 1314 also configures the GPU state so that shader 2 can be executed via commands 1315 to either perform geometry pre-testing or rendering of object 2 . Additionally, command buffer 1316 configures the GPU state so that shader 3 can be executed via commands 1317 to either perform geometry pretesting or rendering of object 3 .

Geometry pre-testing and rendering may be interleaved for different sets of pieces of geometry. By way of example only, command buffer 1300A may be configured to perform geometry pre-testing and rendering of objects 0 and 1 first, and then command buffer 1300A may perform geometry pretesting and rendering of objects 2 and 3 second. Configured to perform geometry pre-testing and rendering. Of course, different numbers of pieces of geometry may be interleaved in different sections. For example, section 1 shows the first traversal through command buffer 1300A. Based on the GPU state implicitly set as described above, as well as the GPU state configured by commands 1310 and 1312, the corresponding shaders perform geometry pretests. For example, shader 0 is configured to perform a geometry pretest on object 0 (eg, a piece of geometry) (eg, based on the object shown in FIG. 7B-1), and shader 1 is configured to perform a geometry pre-test on object 1 is configured to perform a geometry pre-test. Section 2 shows a second traversal through command buffer 1300A. Based on the GPU state implicitly set as described above, as well as the GPU state configured by commands 1310 and 1312, the corresponding shader performs rendering. For example, shader 0 is configured to render object 0 next, and shader 1 is configured to render object 1 next.

FIG. 13A illustrates interleaving geometry pretest and rendering runs for different sets of pieces of geometry. Specifically, Section 3 shows a third partial traversal through command buffer 1300A. Based on the GPU state implicitly set as described above, as well as the GPU state configured by commands 1314 and 1316, the corresponding shader performs the geometry pre-test. For example, shader 2 (executed via command 1315) performs a geometry test on object 2 (eg, a piece of geometry) (eg, based on the object shown in FIG. 7B-1) and shader 3 (executed via command 1315) command 1317) performs a geometry test on object 3. Section 4 shows a fourth partial traversal through command buffer 1300A. Based on the GPU state implicitly set as described above, as well as the GPU state configured by commands 1314 and 1316, the corresponding shader performs rendering. For example, shader 2 (executed via command 1315) renders object 2 and shader 3 (executed via command 1317) renders object 3.

Note that the hardware context is preserved or recorded (or saved) and read (or restored). For example, the Geometry Pretest GPU Context at the end of Section 1 is needed at the beginning of Section 3 to do the Geometry Pretest. Also, the rendering GPU context at the end of section 2 is required for the beginning of section 4 to do the rendering.

In one embodiment, commands may be skipped or interpreted differently based on GPU state. For example, certain commands that set state (parts 1310, 1312, 1314, and 1316) may be skipped based on the GPU state implicitly set as described above. For example, if configuring shader 0, which is executed via command 1310, requires less GPU state to be configured for geometry testing than configuring for rendering geometry, the need for GPU state It may be useful to skip the configuration of parts that are This is because setting the GPU state can have overhead. To give another example, certain commands that set state (parts 1310, 1312, 1314, and 1316) may be interpreted differently based on the GPU state implicitly set as described above. good. For example, if shader 0 executed via command 1310 needs to configure a different GPU state for geometry pre-testing than it is configured for rendering geometry, or Shader 0, which runs in , requires different inputs for geometry testing and geometry rendering.

In one embodiment, shaders configured for geometry pretest do not allocate space for position and parameter caches, as described above. In another embodiment, either pre-testing or rendering is performed using a single shader. This can be done in various ways. For example, via an external hardware state that the shader can check (e.g., as implicitly set as described above), or via an input to the shader (e.g., the first and set by commands interpreted differently in the second pass).

FIG. 13B illustrates graphics processing including interleaving pre-testing and rendering of an image frame's geometry for different sets of pieces of geometry with separate portions of the corresponding command buffers, according to one embodiment of the present disclosure. FIG. 4 is a flow diagram illustrating a method for doing; As noted above, various architectures may include multiple GPUs working together to render a single image by performing multi-GPU rendering of geometry for an application. For example, within one or more cloud gaming servers of a cloud gaming system, or within a standalone system (eg, a personal computer or gaming console that includes a high-end graphics card with multiple GPUs), and the like.

Specifically, at 1310, the method includes rendering graphics for the application using multiple GPUs, as previously described. At 1320, the method includes dividing the responsiveness for rendering geometry of the graphics to multiple GPUs based on multiple screen regions. Each GPU has a corresponding division of responsiveness known to multiple GPUs. More specifically, as noted above, each GPU has a responsibility to render geometry within a corresponding set of screen regions of a plurality of screen regions. A corresponding set of screen regions includes one or more screen regions. In one embodiment, the screen regions are interleaved (eg, when the display is divided into sets of screen regions for geometry pre-testing and rendering).

At 1330, the method includes assigning multiple pieces of geometry for the image frame to multiple GPUs for geometry testing. Specifically, each of the multiple GPUs is assigned a corresponding portion of the geometry associated with the image frame for the purpose of geometry testing. As previously mentioned, the allocation of pieces of geometry may be evenly or unevenly distributed. Each portion contains one or more pieces of geometry, or potentially no pieces of geometry at all.

At 1340, the method includes interleaving the first set of shaders in the command buffer with the second set of shaders. Shaders are configured to perform both geometry pre-testing and rendering. Specifically, the first set of shaders is configured to perform geometry pre-testing and rendering on the first set of pieces of geometry. A second set of shaders is then configured to perform geometry pre-testing and rendering on the second set of pieces of geometry. As previously described, the geometry pretest generates corresponding information about each piece of geometry in the first set or the second set and its relationship to each of the plurality of screen regions. Multiple GPUs use the corresponding information to render each piece of geometry in the first set or the second set. As previously mentioned, the GPU state may be set in various ways to perform either geometry pre-testing or rendering. For example, the CPU or GPU can set values in random access memory (RAM). The GPU checks the values in RAM. In another example, the state may be internal to the GPU. For example, when calling a command buffer as a subroutine twice and the internal GPU state is different between the two subroutine calls.

The interleaving process is further explained. Specifically, as described above, the first set of shaders in the command buffer are configured to perform geometry pretests on the first set of pieces of geometry. Geometry pre-testing is performed on a first set of pieces of geometry on multiple GPUs to generate first information about each piece of geometry in the first set and its relationship to each of a plurality of screen regions. . And, as described above, the first set of shaders is configured to perform rendering of the first set of pieces of geometry. The first information is then used in rendering multiple pieces of geometry on each of the multiple GPUs (e.g., fully rendering the first set of pieces of geometry on the corresponding GPU or (to include skipping the rendering of a set of pieces). As previously mentioned, the information indicates which pieces of geometry overlap the screen area allocated to the corresponding GPU for object rendering. For example, using information to skip rendering a piece of geometry on the GPU if the piece of geometry does not overlap any screen regions (e.g., in the corresponding set) allocated to the GPU for object rendering. You may go when the information indicates.

A second set of shaders is then used for geometry testing and rendering of a second set of pieces of geometry. Specifically, as described above, the second set of shaders in the command buffer are configured to perform geometry pretests on the second set of pieces of geometry. Geometry tests are then performed on the second set of pieces of geometry on the plurality of GPUs to generate second information about each piece of geometry in the second set and its relationship to each of the plurality of screen regions. do. And, as described above, the second set of shaders is configured to perform the rendering of the second set of pieces of geometry. A second set of pieces of geometry is then rendered using the second information on each of the plurality of GPUs. As described above, the information indicates which pieces of geometry overlap the screen regions (eg, corresponding sets) allocated to the corresponding GPU for object rendering.

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

FIG. 14 illustrates components of an example device 1400 that can be used to implement aspects of various embodiments of this disclosure. For example, in FIG. 14, embodiments of the present disclosure enable multi-GPU rendering of geometry for applications by pre-testing geometry for screen regions (which may be interleaved) before rendering objects for image frames. A typical hardware system suitable for implementation is illustrated. Can the device 1400 illustrated in this block diagram incorporate a personal computer, server computer, gaming console, mobile device, or other digital device, each suitable for practicing embodiments of the present invention? Or they can be. Device 1400 includes a central processing unit (CPU) 1402 for executing 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. A further embodiment provides a microprocessor architecture specifically adapted for highly parallel, computationally intensive applications (e.g., media and interactive entertainment applications) in applications configured to perform graphics processing while a game is running. It can be implemented with one or more CPUs associated with it.

Memory 1404 stores applications and data used by CPU 1402 and GPU 1416 . Storage 1406 is non-volatile storage and other computer-readable media for applications and data, including fixed disk drives, removable disk drives, flash memory devices, and CD-ROMs, DVD-ROMs, Blu-rays, HD-DVDs, 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 may include keyboards, mice, joysticks, touch pads, touch screens, still or video recorders/cameras, and/or microphones. Network interface 1409 allows device 1400 to communicate with other computer systems through electronic communications networks. Network interface 1409 may include wired or wireless communications via local-area networks and wide-area networks (eg, 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 device 1406. Components of device 1400 (eg, CPU 1402, graphics subsystem, eg, GPU 1416, memory 1404, data storage 1406, user input device 1408, network interface 1409, and audio processor 1412) communicate one or more data buses 1422. connected through

Graphics subsystem 1414 is also coupled to data bus 1422 and the 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, frame buffers) used to store pixel data for each pixel of the output image. Graphics memory 1418 may be integrated in the same device as GPU 1416 , connected to GPU 1416 as a separate device, and/or implemented within memory 1404 . Pixel data can be provided directly from CPU 1402 to graphics memory 1418 . Alternatively, CPU 1402 provides GPU 1416 with data and/or instructions that define the desired output image. From the desired output image, GPU 1416 generates pixel data for one or more output images. Data and/or instructions defining a desired output image can be stored in memory 1404 and/or graphics memory 1418 . In one embodiment, GPU 1416 includes 3D rendering capabilities for generating pixel data for output images from instructions and data defining geometry, lighting, shading, textures, motion, and/or camera parameters for a scene. . GPU 1416 may further include one or more programmable execution units capable of executing shader programs.

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

Another embodiment for optimizing the graphics subsystem 1414 is to pre-test the geometry against screen regions (which may be interleaved) before rendering the object for an image frame, thereby optimizing the geometry for the application. Doing GPU rendering can be included. 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 applications. Multiple graphics subsystems may be performing graphics and/or rendering pipelines for a single application. That is, graphics subsystem 1414 includes multiple GPUs that are used to render one or more respective images of an image or sequence of images when executing an application.

In other embodiments, graphics subsystem 1414 includes multiple GPU devices. These are combined to perform graphics processing for a single application running on the corresponding CPU. For example, multiple GPUs can perform multi-GPU rendering of geometry for an application by pre-testing the geometry against screen regions (which may be interleaved) before rendering the object for an image frame. In another example, multiple GPUs can perform alternating forms of frame rendering. Here, GPU1 renders the first frame, GPU2 renders the second frame, and so on in successive frame cycles, until the last GPU is reached. The first GPU then renders the next video frame (eg, GPU1 renders the third frame if there are only two GPUs). That is, the GPU rotates when rendering a frame. Rendering operations can overlap. GPU2 may start rendering a second frame before GPU1 finishes rendering the first frame. In another implementation, multiple GPU devices may be assigned different shader operations in the rendering and/or graphics pipeline. The master GPU does the main rendering and compositing. For example, in a group containing three GPUs, master GPU1 may perform main rendering (eg, first shader operations) and compositing of output from slave GPU2 and slave GPU3. Slave GPU2 may perform a second shader (eg, fluid effects such as river) operation, and slave GPU3 may perform a third shader (eg, particle smoke) operation. Master GPU1 combines the results from each of GPU1, GPU2, and GPU3. In this way, different GPUs can be assigned to perform different shader operations (eg, waving flags, wind, smoke, fire, etc.) to render a video frame. In still other embodiments, each of the three GPUs can be assigned to a different object and/or portion of the scene corresponding to the video frame. In the embodiments and implementations described above, these operations can be performed in the same frame period (concurrently in parallel) or in different frame periods (sequentially in parallel).

Thus, the present disclosure pretests geometry against screen regions (which may be interleaved) prior to rendering objects for each of one or more image frames in an image frame or sequence of image frames when executing an application. describes a method and system configured for multi-GPU rendering of geometry for applications.

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

Embodiments of the present disclosure may be practiced with various computer system configurations (eg, handheld devices, microprocessor systems, microprocessor-based or programmable consumer electronics, minicomputers, mainframe computers, etc.). Embodiments of the present disclosure may also be practiced in distributed computing environments. Here, tasks are performed by remote processing devices linked through wire-based or wireless networks.

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

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

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

Although the foregoing disclosure has been described in some detail for clarity of understanding, it will be apparent that certain variations and modifications may be practiced within the scope of the appended claims. Accordingly, the embodiments are to be considered illustrative and not limiting, and the embodiments of the present disclosure should not be limited to the details shown herein, but the scope of the appended claims and May vary within equivalents.

Claims (24)

A method for performing graphics processing, comprising:
rendering graphics for an application using multiple graphics processing units (GPUs);
dividing the responsiveness for the rendering of the graphics geometry among the plurality of GPUs based on multiple screen regions, each GPU having a corresponding division of the responsiveness known to the plurality of GPUs; , the screen regions in the plurality of screen regions are interleaved;
assigning a GPU a piece of geometry of an image frame generated by said application for geometry pre-testing;
performing the geometry pretest on the GPU to generate information about the piece of geometry and its relationship to each of the plurality of screen regions;
using the information in each of the plurality of GPUs when rendering the image frame;
providing said information as a hint to a rendering GPU, said rendering GPU being one of said plurality of GPUs;
the information is considered by the rendering GPU if received before rendering of the piece of geometry begins in the rendering GPU;
A method, wherein said piece of geometry is fully rendered in said rendering GPU when said information is received after rendering of a first piece of geometry has begun. skipping rendering of the piece of geometry in the rendering GPU when the information indicates that the piece of geometry does not overlap any screen area allocated to the rendering GPU for object rendering; is one of the plurality of GPUs. further assigning multiple pieces of geometry of the image frames to the multiple GPUs for the geometry pre-test;
2. The method of claim 1, wherein the pieces of geometry in the plurality of pieces of geometry are distributed uniformly or non-uniformly across the plurality of GPUs. 4. The method of claim 3 , allocating the plurality of pieces of geometry such that successive pieces of geometry are processed by different GPUs. The first GPU performs the geometry pre-test on more pieces of geometry than the second GPU, or the first GPU performs the geometry pre-test and the second GPU performs the geometry pre-test. 5. The method of claim 4 , performing while not performing any . 2. The method of claim 1, wherein the multiple screen regions are configured to reduce rendering time imbalance between the multiple GPUs. 2. The method of claim 1, wherein each of the plurality of screen regions are non-uniform in size. 2. The method of claim 1, wherein the plurality of screen regions dynamically change. 2. The method of claim 1, wherein the piece of geometry corresponds to geometry that a draw call uses or generates. 2. The method of claim 1, wherein the application's draw calls use or generate geometry that is subdivided into multiple pieces of geometry, including the piece of geometry from which the GPU generates the information. 2. The method of claim 1, wherein the pieces of geometry are individual primitives. 2. The method of claim 1, wherein the information about the piece of geometry includes vertex counts or primitive counts. 2. The method of claim 1, wherein the information about the piece of geometry comprises a specific set of primitives for rendering or a specific set of vertices for rendering. Further, using a common rendering command buffer for the plurality of GPUs,
2. The method of claim 1, restricting execution of commands in the common rendering command buffer to one or more of the plurality of GPUs. 2. The method of claim 1, wherein the information may or may not be generated depending on characteristics of the piece of geometry. 2. The method of claim 1, further comprising generating said information using a scan converter in a rasterization stage. 2. The method of claim 1, further comprising generating the information using one or more shaders in a geometry processing stage. 18. The method of claim 17 , wherein said one or more shaders employ one or more dedicated instructions to accelerate said generation of said information. 18. The method of claim 17 , wherein the one or more shaders do not perform allocations to position caches or parameter caches. further dividing pieces of geometry among the plurality of GPUs for the geometry pre-test;
The method of claim 1, wherein successive pieces of geometry are processed by different GPUs. 21. The method of claim 20 , further dynamically adjusting divisions of the plurality of pieces of geometry based on respective performances of the plurality of GPUs during the geometry pre-test. 2. The method of claim 1, wherein one or more of the multiple GPUs are part of a larger GPU configured as multiple virtual GPUs. a computer system,
having a processor;
a memory coupled to the processor and storing instructions which, when executed by the computer system, cause the computer system to perform a method for executing a graphics pipeline;
The method includes:
rendering graphics for an application using multiple graphics processing units (GPUs);
dividing the responsiveness for the rendering of the graphics geometry among the plurality of GPUs based on multiple screen regions, each GPU having a corresponding division of the responsiveness known to the plurality of GPUs; , the screen regions in the plurality of screen regions are interleaved;
assigning a GPU a piece of geometry of an image frame generated by said application for geometry pre-testing;
performing the geometry pre-test on the GPU to generate information about the piece of geometry and its relationship to each of the plurality of screen regions;
using the information in each of the plurality of GPUs when rendering the image frame;
providing said information as a hint to a rendering GPU, said rendering GPU being one of said plurality of GPUs;
the information is considered by the rendering GPU if received before rendering of the piece of geometry begins in the rendering GPU;
A computer system, wherein said piece of geometry is fully rendered in said rendering GPU when said information is received after rendering of a first piece of geometry has begun. skipping rendering of the piece of geometry in the rendering GPU when the information indicates that the piece of geometry does not overlap any screen area allocated to the rendering GPU for object rendering; 24. The computer system of claim 23, wherein is one of said plurality of GPUs.