Patent Description:
Subsequently, the application can playback the graphics processing operations by rebuilding the memory based on the determined modified memory, and sending the stored graphics processing operations back to the GPU for execution. This process can be useful in debugging graphics operations or otherwise evaluating the GPU performance based on modifying operating parameters, etc. This process, however, can also be time consuming and proprietary in requiring the CPU to analyze each possible GPU graphics processing operation. <NPL> presents a novel framework for debugging GPU stream programs through automatic dataflow recording and visualization. The disclosed debugging system can help programmers locate errors that are common in general purpose stream programs but very difficult to debug with existing tools. A stream program is first compiled into an instrumented program using a compiler. This instrumenting compiler automatically adds to the original program dataflow recording code that saves the information of all GPU memory operations into log files. The resulting stream program is then executed on the GPU. With dataflow recording, the debugger automatically detects common memory errors such as out-of-bound access, uninitialized data access, and race conditions. These errors are extremely difficult to debug with existing tools. When the instrumented program terminates, either normally or due to an error, a dataflow visualizer is launched and it allows the user to examine the memory operation history of all threads and values in all streams. Thus the user can analyze error sources by tracing through relevant threads and streams using the recorded dataflow. <NPL> discloses GLTraceSim, a new graphics memory tracing and replay framework for studying the memory behavior of graphics workloads and how they interact in heterogeneous CPU/GPU memory systems. GLTraceSim efficiently generates GPU memory access traces and their corresponding, synchronized, CPU render thread memory traces. The resulting traces can then be replayed in both high-level models and detailed fullsystem simulators. We evaluate GLTraceSim on a range of graphics workloads from browsers to games. Our results show that GLTraceSim can efficiently generate graphics memory traces, and use these traces to study graphics performance in heterogeneous CPU/GPU memory systems. We show that understanding the impact of graphics workloads is essential, as they can cause slowdowns in co-running CPU applications of <NUM>-<NUM>%, depending on the memory technology. <CIT> relates to facilitating performance analysis for processing including capturing a state of a processing unit and capturing a plurality of commands submitted to the processing unit for processing. Both the captured state and the captured plurality of commands are also saved. The saved state and commands can be used for analysis, such as by processing only a subset of the commands or processing a modified set of the commands. <CIT> relates to debugging a graphics application executing on a target device. The graphics application may execute CPU instructions to generate graphics commands to graphics hardware for generation of graphics on a display. A breakpoint for the graphics application may be detected at a first time. In response to detecting the breakpoint, one or more graphics commands which were executed by the graphics hardware proximate to the first time may be displayed. Additionally, source code corresponding to CPU instructions which generated the one or more graphics commands may be displayed.

It is the object of the present invention to provide an enhanced method for debugging graphics operations.

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

In an example, a method for capturing and executing graphics processing operations is provided. The method includes activating a memory trap function to cause a graphics processing unit (GPU) to report memory accesses in executing graphics processing operations, receiving, based on activating the memory trap function and for each of a sequence of executed graphics processing operations executed by the GPU, a sequence of memory accessing commands and associated portions of memory modified based on executing the sequence of executed graphics processing operations, storing, in a repository, each of the sequence of multiple memory accessing commands and associated portions of memory, and providing, to the GPU, at least a portion of the sequence of multiple memory accessing commands and associated portions of memory to emulate re-executing of the sequence of executed graphics processing operations by the GPU.

In another example, a computing device for capturing and executing graphics processing operations is provided. The computing device includes a memory storing one or more parameters or instructions for executing an operating system and one or more applications, a display interface configured for communicating signals to display images on a display, and at least one processor coupled to the memory and the display interface. The at least one processor is configured to activate a memory trap function to cause a GPU to report memory accesses in executing graphics processing operations, receive, based on activating the memory trap function and for each of a sequence of executed graphics processing operations executed by the GPU, a sequence of memory accessing commands and associated portions of memory modified based on executing the sequence of executed graphics processing operations, store, in a repository, each of the sequence of multiple memory accessing commands and associated portions of memory, and provide, to the GPU, at least a portion of the sequence of multiple memory accessing commands and associated portions of memory to emulate re-executing of the sequence of executed graphics processing operations by the GPU.

In another example, a computer-readable medium, including code executable by one or more processors for capturing and executing graphics processing operations is provided. The code includes code for activating a memory trap function to cause a GPU to report memory accesses in executing graphics processing operations, receiving, based on activating the memory trap function and for each of a sequence of executed graphics processing operations executed by the GPU, a sequence of memory accessing commands and associated portions of memory modified based on executing the sequence of executed graphics processing operations, storing, in a repository, each of the sequence of multiple memory accessing commands and associated portions of memory, and providing, to the GPU, at least a portion of the sequence of multiple memory accessing commands and associated portions of memory to emulate re-executing of the sequence of executed graphics processing operations by the GPU.

To the accomplishment of the foregoing and related ends, the one or more examples comprise the features hereinafter fully described and particularly pointed out in the claims. The following description and the annexed drawings set forth in detail certain illustrative features of the one or more examples. These features are indicative, however, of but a few of the various ways in which the principles of various examples may be employed, and this description is intended to include all such examples and their equivalents.

Described herein are various examples related to capturing and executing graphics processing operations. A memory trapping function can be enabled to facilitate reporting of memory modifications by a graphics processing unit (GPU). The memory trapping function can determine when portions of memory are modified, and for a given portion of memory can report at least the occurrence of the modification. In one example, each portion of memory may include an indicator specifying whether to enable trapping for the portion of memory, and the memory trapping function can determine to report modification of the memory based on the indicator. For example, the memory trapping function can be implemented in a memory allocator of the GPU, and can notify a central processing unit (CPU) (e.g., via an interrupt handler) when memory is modified by a graphics processing operation performed by the GPU. The CPU can accordingly store memory accessing commands and the associated modified memory in a repository for subsequently playing back the memory accessing commands to emulate the graphics processing operations.

Performing the memory trapping function and notification at the GPU can provide a fast and robust mechanism to capture the GPU processing operations, or at least modifications to memory that occur as a result of the GPU operations, as opposed to using the CPU to analyze rendering instructions sent to the GPU. For example, using the CPU to analyze GPU processing operations as they are sent to the GPU may require complex logic on the CPU to interpret each GPU processing operation, and may also require modification to accommodate new GPU commands. Using memory trapping at the GPU, however, can be performed more efficiently and may allow for capturing memory modifications in real time (or near real time).

Turning now to <FIG>, examples are depicted with reference to one or more components and one or more methods that may perform the actions or operations described herein, where components and/or actions/operations in dashed line may be optional. Although the operations described below in <FIG> are presented in a particular order and/or as being performed by an example component, the ordering of the actions and the components performing the actions may be varied, in some examples, depending on the implementation. Moreover, in some examples, one or more of the following actions, functions, and/or described components may be performed by a specially-programmed processor, a processor executing specially-programmed software or computer-readable media, or by any other combination of a hardware component and/or a software component capable of performing the described actions or functions.

<FIG> is a schematic diagram of an example of a computing device <NUM> and/or related components for rendering images, which can be displayed on a display device (not shown). For example, computing device <NUM> can include or can otherwise be coupled with a processor <NUM> and/or memory <NUM>, where the processor <NUM> and/or memory <NUM> can be configured to execute or store instructions or other parameters related to generating rendering instructions for rendering images for displaying, as described herein. Computing device <NUM> can execute an operating system <NUM> (e.g., via processor <NUM> and/or memory <NUM>) for providing an environment for executing one or more applications <NUM>, such as one or more applications <NUM> that produce or otherwise obtain images for display. The application <NUM> can include substantially any application that generates streams of images for displaying at a frame rate, such as a game, a video streaming service, etc., for example. The computing device <NUM> can also include a GPU <NUM> for processing rendering instructions, and/or communicating associated commands to a display interface <NUM> to cause display of one or more images on a display, which may be coupled to the computing device <NUM> via a display port.

In an example, display interface <NUM> can be communicatively coupled with the processor <NUM> and/or memory <NUM> for communicating with a display via a display port <NUM>. Display port <NUM>, as referred to herein, can include one or more of various types of ports, including a high definition multimedia interface (HDMI) port, a display serial interface (DSI) port, a mobile industry processor interface (MIPI) DSI port, a universal serial bus (USB) port, a Firewire port, or other embedded or external wired or wireless display ports that can allow communications between computing device <NUM> and the display.

In one example, GPU <NUM> can be part of the display interface <NUM> (e.g., a processor on a circuit board of the display interface <NUM>). In another example, GPU <NUM>, display interface <NUM>, etc., can be integrated with processor <NUM>. Substantially any combination of hardware can be possible such that GPU <NUM>, display interface <NUM>, etc., can communicate with processor <NUM> via a bus to facilitate providing the rendering instructions to the GPU <NUM>. GPU <NUM> can process the rendering instructions to render an image, and can initiate display of at least a portion of the image on the display by transmitting associated signals to the display via display port <NUM> of display interface <NUM>.

In an example, GPU <NUM> can include a memory allocator <NUM> for allocating portions of memory (e.g., memory <NUM>) for use in executing graphics processing operations. For example, the memory allocator <NUM> may request portions of memory from a memory controller associated with memory <NUM>, such as to obtain physical memory corresponding to virtual memory addresses specified to the GPU <NUM> for performing graphics processing operations. The memory allocator <NUM> can also include a memory trapping function <NUM> for detecting and reporting when portions of memory <NUM> are modified by the GPU <NUM>. For example, the memory trapping function <NUM> can provide an indication of the portion of memory modified (e.g., at one or more levels of granularity, such as a page of memory, which may be of a configured size, a byte of memory, etc.) and/or an indication of a memory accessing command (e.g., read, write, etc.). In addition, memory trapping function <NUM> may provide a mechanism for activating the memory trapping and for specifying a callback function, interrupt handler or channel, etc. for the memory trapping function <NUM> to instantiate when memory modification is detected.

Application <NUM> can include a memory modification tracking component <NUM> for activating the memory trapping function <NUM> and/or tracking memory modifications reported by the GPU <NUM>. The memory modification tracking component <NUM> can include a callback component <NUM>, which may be the callback function, interrupt handler or channel, etc., and may be specified when activating the memory trapping function <NUM>, and a logging component <NUM> for logging, in a command/resource repository <NUM>, memory accessing commands and related memory resources reported by the memory trapping function <NUM>. The command/resource repository <NUM> can include substantially any data storage mechanism in the computing device <NUM>, such as memory <NUM>, a hard drive, database, file, etc. In addition, the application <NUM> may optionally include a memory trapping function <NUM> for capturing modifications to memory <NUM> performed by the processor <NUM> (e.g., within the context of the application or otherwise). In this example, application <NUM> may also register the callback component <NUM> (or another callback component <NUM>) with memory trapping function <NUM> for detecting and/or reporting memory modification performed by the processor <NUM>. For example, portions of memory <NUM> assigned to memory allocator <NUM> can be marked for trapping functionality, as described herein, and memory trapping function <NUM> and/or memory trapping function <NUM> can respectively detect and/or report memory modifications made to the portions of memory <NUM> by the GPU <NUM> or processor <NUM>.

Application <NUM> can further include a playback component <NUM> for emulating re-execution of the graphics processing operations based on the memory accessing commands and corresponding memory resources stored in the command/resource repository <NUM>. In one example, playback component <NUM> can allow for modifying settings of the GPU <NUM>, modifying portions of the commands, etc. to debug or evaluate performance during re-execution of the graphics processing operations. In another example, playback component <NUM> can generate the graphics processing operations based on the memory accessing commands and associated modified memory resources to playback the graphics processing operations. In any case, at least the capture and storage of graphics processing operations, or data for recreating the graphics processing operations, can occur efficiently by using the memory trapping function <NUM> in the GPU <NUM>.

<FIG> is a flowchart of an example of a method <NUM> for efficiently and robustly capturing and re-executing graphics processing operations. For example, method <NUM> can be performed by a computing device <NUM>, and is accordingly described with reference to <FIG>, as a non-limiting example of an environment for carrying out method <NUM>.

In method <NUM>, optionally at action <NUM>, an initial state of a memory is stored in a repository. In an example, memory modification tracking component <NUM>, e.g., in conjunction with processor <NUM>, memory <NUM>, etc., can store, in the repository (e.g., command/resource repository <NUM>), an initial state of the memory (e.g., memory <NUM> and/or a portion thereof). For example, memory modification tracking component <NUM> can store the initial state of a portion of memory <NUM> dedicated to GPU <NUM> and/or to a corresponding set of graphics processing operations, such to track modification of the memory based on performance of the graphics processing operations. For example, where the GPU <NUM> operates at a memory page granularity (e.g., <NUM> kilobyte (KB) pages, <NUM> KB pages, <NUM> megabyte (MB) pages, etc.), memory modification tracking component <NUM> can store an initial state of multiple pages of memory <NUM> related to performing graphics processing operations.

At action <NUM>, a memory trapping function is activated to cause a GPU to report memory accesses in executing graphics processing operations. In an example, memory modification tracking component <NUM>, e.g., in conjunction with processor <NUM>, memory <NUM>, etc., can activate the memory trapping function (e.g., memory trapping function <NUM> on the GPU <NUM>) to cause the GPU (e.g., GPU <NUM>) to report memory accesses in executing graphics processing operations. For example, memory modification tracking component <NUM> can activate the memory trapping function via a function call to the GPU <NUM>. Memory modification tracking component <NUM> may include a handle or other identifier of the callback component <NUM> in the activation request/command send to the GPU <NUM> to allow the memory trapping function <NUM> to call the callback component <NUM> when memory modification is detected. In addition, for example, memory modification tracking component <NUM> may indicate portions of memory (e.g., pages) for which to activate the memory trapping function <NUM>, and/or GPU <NUM> can activate the memory trapping function <NUM> on the specified portions or otherwise on all portion relevant to the graphics processing operations.

In another example, the processor <NUM> (e.g., via application <NUM> or another application) can also execute graphics processing operations that result in modifying portions of memory <NUM>. In this example, a memory trapping function, not shown, can also be activated for the processor (e.g., CPU) <NUM>. In one example, memory trapping function <NUM> may be able to detect modification of the memory <NUM> regardless of whether GPU <NUM> or processor <NUM> modifies the memory, and can act as a memory trapping function for both operations.

In an example, activating the memory trapping function at action <NUM> may optionally include, at action <NUM>, setting an indication, for each of multiple portions of memory, to enable the memory trapping function for each of the portions. For example, each portion of memory may have an associated bit or other indicator specifying whether memory trapping is enabled for the portion of memory. Memory modification tracking component <NUM> and/or GPU <NUM> may set the bit or other indicator for a set of portions (e.g., pages) relevant to the graphics processing operations or for specific portions that may be indicated when activating the memory trapping function <NUM>.

At action <NUM>, for each of a sequence of executed graphics processing operations, a sequence of multiple memory accessing commands and associated portions of memory modified based on executing the sequence of executed graphics processing operations is received. In an example, memory modification tracking component <NUM>, e.g., in conjunction with processor <NUM>, memory <NUM>, etc., can receive, for each of the sequence of executed graphics processing operations, the sequence of multiple memory accessing commands and associated portions of memory modified based on executing the sequence of executed graphics processing operations. For example, the application <NUM>, and/or another application, processor, etc., can provide graphics processing operations to the GPU <NUM> (e.g., as a set of rendering instructions) to facilitate rendering of graphics for display. For example, the GPU <NUM> can be designed to efficiently process graphics processing operations concurrently with (e.g., separately from) CPU operations.

The GPU <NUM> can accordingly perform the graphics processing operations, and for each memory modification (e.g., where a bit indicator for an associated portion of memory is set), the memory trapping function <NUM> can callback to the memory modification tracking component <NUM> via the specified callback component <NUM>. The callback may include an indication of the portion (e.g. page) of memory modified by the GPU in performing the graphics processing operation and one or more associated memory accessing commands (e.g., read, write, etc.). Thus, for example, memory modification tracking component <NUM> can receive an indication of the portion of memory modified and the corresponding memory accessing command(s) via the callback component <NUM>. For example, memory modification tracking component <NUM> can receive the indications of the portion of memory modified by the GPU and the one or more associated memory accessing commands corresponding to the graphics processing operations as each operation is performed (e.g., a callback can occur for each graphics processing operation). This can allow for storing copies of the portions of memory and the associated memory accessing commands in sequence, in one example. In other examples, the processor <NUM> may execute graphics processing operations as well, for which memory trapping can be performed, as described above, for reporting memory accessing commands and/or associated portions of memory (e.g., via callback component <NUM> or another registered callback).

At action <NUM>, each of the sequence of multiple memory accessing commands and associated portions of memory is stored in the repository. In an example, logging component <NUM>, e.g., in conjunction with processor <NUM>, memory <NUM>, memory modification tracking component <NUM>, etc., can store, in the repository (e.g., command/resource repository <NUM>), each of the sequence of multiple memory accessing commands and associated portions of memory. For example, logging component <NUM> can store the memory accessing commands performed (e.g., by the GPU <NUM>) in executing the graphics processing operations (e.g., read, write, etc.) and copies of the associated portions of memory (e.g., pages of memory <NUM>) affected by the memory accessing commands in the command/resource repository <NUM>. This can allow for emulating playback of the graphics processing operations, as described further herein, by providing the memory accessing commands and/or relevant portions of memory to the GPU <NUM> for re-execution. Moreover, for example, the GPU <NUM> may block processing of graphics processing operations based on the callback to allow the application <NUM> to copy the portion of the memory without conflict, and memory modification tracking component <NUM> can accordingly notify the GPU <NUM> once storing is completed (e.g., by setting a register on the GPU based on completion of the storing) to allow the GPU <NUM> to unblock and continue processing of the graphics processing operations.

Additionally, optionally at action <NUM>, the indication to disable the memory trapping function for each of the portions of memory can be set based on storing the associated portions of memory. In an example, memory modification tracking component <NUM>, e.g., in conjunction with processor <NUM>, memory <NUM>, etc., can set, based on storing the associated portions of memory, the indication to disable the memory trapping function for each of the portions of memory. In this example, the memory trapping function <NUM> need not determine whether these portions of memory are modified in subsequent graphics processing operations. In some examples described further herein, however, the CPU may also execute graphics processing operations or modify resources used by the GPU, and have an associated memory trapping function. In this example, the memory modification tracking component <NUM> (e.g., based on a callback from a memory trapping function <NUM> executing on the processor <NUM>, e.g., via the application <NUM>) can enable a memory trapping function on the CPU (e.g., on processor <NUM>) where the CPU modifies the portion of the memory in performing graphics processing operations. Accordingly, such modifications by the CPU can also be captured and reported using callback component <NUM> (or another callback component registered with the memory trapping function <NUM>).

At action <NUM>, at least a portion of the sequence of multiple memory accessing commands and associated portions of memory is provided to the GPU to emulate re-execution of the sequence of executed graphics processing operations by the GPU. In an example, playback component <NUM>, e.g., in conjunction with processor <NUM>, memory <NUM>, etc., can provide, to the GPU (e.g., GPU <NUM>), at least the portion of the sequence of multiple memory accessing commands and associated portions of memory to emulate re-execution of the sequence of executed graphics processing operations by the GPU <NUM>. For example, this can allow for efficient playback of the GPU processing operations, or at least the corresponding modifications to memory, for debugging, evaluating GPU <NUM> performance, etc. Playback component <NUM> can also provide the initial state of the memory to the GPU <NUM> as a starting point for executing the multiple memory accessing commands on the associated portions of memory to emulate re-execution of the sequence of executed graphics processing operations. Additionally, as described further herein, GPU settings, graphics processing operation parameters, etc. can be modified in playing back the GPU processing operations to evaluate how the modifications may impact GPU <NUM> performance.

Optionally, at action <NUM> (e.g., in addition to providing the memory accessing commands and associated portions of memory to the GPU), a portion of the sequence of multiple memory accessing commands and associated portions of memory can be analyzed to generate a portion of the sequence of executed graphics processing operations. In an example, playback component <NUM>, e.g., in conjunction with processor <NUM>, memory <NUM>, etc., can analyze the portion of the sequence of multiple memory accessing commands and associated portions of memory to generate a portion of the sequence of executed graphics processing operations. For example, an ordering of the memory accessing commands may be indicative of certain GPU graphics processing operations, and the portions of memory can indicate on which portions (e.g., pages) of memory the graphics processing operations are performed. Thus, the sequence of executed graphics processing operations can be reconstructed for playing back on the GPU <NUM> as a set of graphics processing operations (e.g., in addition to the explicit memory accesses).

<FIG> is a flowchart of an example of a method <NUM> for playing back or emulating playback of graphics processing operations. For example, method <NUM> can be performed by a computing device <NUM>, and is accordingly described with reference to <FIG>, as a non-limiting example of an environment for carrying out method <NUM>.

In method <NUM>, at action <NUM>, each of the sequence of multiple memory accessing commands and associated portions of memory can be stored in the repository. In an example, logging component <NUM>, e.g., in conjunction with processor <NUM>, memory <NUM>, memory modification tracking component <NUM>, etc., can store, in the repository (e.g., command/resource repository <NUM>), each of the sequence of multiple memory accessing commands and associated portions of memory, as described previously in reference to <FIG>. In addition, one or more of the actions described in <FIG> can occur to obtain the sequence of multiple memory accessing commands and associated portions of memory for storing in the repository. As described herein, one or more modifications can be made before playback to test performance of the GPU <NUM> in certain situations.

Optionally, at action <NUM>, one or more settings of the GPU can be modified. In an example, playback component <NUM>, e.g., in conjunction with processor <NUM>, memory <NUM>, etc., can modify one or more settings of the GPU. For example, playback component <NUM> can modify a cache behavior of the GPU <NUM>, a page size used by the GPU <NUM>, etc..

Optionally, at action <NUM>, one or more of at least a portion of the sequence of multiple memory accessing commands may be modified. In an example, playback component <NUM>, e.g., in conjunction with processor <NUM>, memory <NUM>, etc., can modify the one or more of at least the portion of the sequence of multiple memory accessing commands. For example, playback component <NUM> can modify the memory accessing commands to correspond to different graphics processing operations, to perform different memory accessing commands, etc. such to evaluate the performance of the GPU <NUM> in response. In another example, where the graphics processing operations are rebuilt based on the memory accessing commands and associated portions of memory, playback component <NUM> can modify one or more parameters of the graphics processing operations in this regard before playback.

At action <NUM>, at least a portion of the sequence of multiple memory accessing commands and associated portions of memory can be provided to the GPU to emulate re-execution of the sequence of executed graphics processing operations by the GPU. In an example, playback component <NUM>, e.g., in conjunction with processor <NUM>, memory <NUM>, etc., can provide, to the GPU (e.g., GPU <NUM>), at least the portion of the sequence of multiple memory accessing commands and associated portions of memory to emulate re-execution of the sequence of executed graphics processing operations by the GPU <NUM>. For example, playback component <NUM> can provide the information to emulate the re-execution after modifying the one or more settings or memory accessing commands to allow for debugging, evaluating performance of the GPU <NUM>, etc..

<FIG> illustrates an example of a communication flow <NUM> for a system for capturing graphics processing operations, or at least related memory modification, in a repository in accordance with examples described herein. A CPU <NUM> is shown, which may correspond to processor <NUM> (in <FIG>), and a GPU <NUM>, which can correspond to GPU <NUM>, where the CPU <NUM> and GPU <NUM> can communicate with one another to perform graphics processing operations. A memory <NUM> is also shown, which may correspond to memory <NUM> and which the CPU <NUM> and/or GPU <NUM> can access in performing the graphics processing operations. For example, the memory <NUM> can store one or more resources, which can correspond to the portions (e.g., pages) of memory described herein, including resource <NUM><NUM>,. resource N <NUM>. Memory <NUM> can also include a command buffer <NUM> for storing GPU commands for performing graphics processing operations on the GPU <NUM>. In addition, a repository <NUM> is shown for storing memory accessing commands <NUM> and copies of memory resources, such as resource copy <NUM><NUM>,. resource copy N <NUM>, as described herein.

The CPU <NUM> can load memory resources into memory <NUM> at <NUM>. For example, CPU <NUM> can load memory for performing a set of graphics processing operations, such as one or more pages or other portions of memory for the graphics processing operations, which may include resource <NUM><NUM>,. resource N <NUM>. The CPU <NUM> can also compose GPU commands for performing the graphics processing operations, which may include rendering instructions for rendering images to display, at <NUM>. The GPU commands can be stored in a command buffer <NUM> in memory <NUM>. The CPU <NUM> may additionally capture an initial state of the memory (e.g., of the loaded resources, such as resource <NUM><NUM>,. resource N <NUM>), which can be stored in the repository <NUM>.

The CPU <NUM> can instruct the GPU <NUM> to execute GPU commands at <NUM>, which can include providing a handle, pointer, or other information regarding the command buffer <NUM>, corresponding resources (e.g., resource <NUM><NUM>,. resource N <NUM>, etc.). The GPU <NUM> can accordingly obtain GPU commands from the command buffer <NUM> in memory <NUM> at <NUM>. The GPU <NUM> can then execute the GPU commands, which result in performing memory accesses. Such as read operation <NUM>, write operation <NUM>, and read operation <NUM>. Where memory trapping is activated for the GPU <NUM>, as described, the read operation <NUM>, write operation <NUM>, and read operation <NUM> can also be copied into the repository <NUM>, which can include copying the commands themselves (or an indication thereof) in commands <NUM> and a copy of the impacted portion of memory as resource copy <NUM><NUM>,. resource copy N <NUM>.

For example, where the memory trapping is at the page level, executing the read operation <NUM>, write operation <NUM>, and read operation <NUM> can result in storing the page(s) of memory impacted by each operation, as described above. As described, this may include the GPU <NUM> calling back a callback function on the CPU <NUM> when the associated resource <NUM>, <NUM> is modified, and the CPU <NUM> can store the associated command(s) <NUM> and/or the corresponding resource copies <NUM>, <NUM> in the repository <NUM>. In another example, the CPU <NUM> can build a table of the resources as they are created (e.g., allocated to the GPU <NUM>), and then use the trapped page addresses from the callback function, instantiated by the GPU <NUM> when the resource is modified, to look up the memory ranges for the entirety of modified resources. Then, in this example, the CPU <NUM> can capture, and write to the repository <NUM>, the memory ranges corresponding to the entirety of modified resources. Once stored in the repository, the commands can be played back from the initial state to emulate re-execution of the graphics processing operations.

<FIG> illustrates an example of a communication flow <NUM> for a system for playing back graphics processing operations, or at least related memory modification, in accordance with examples described herein. A CPU <NUM> is shown, which may correspond to processor <NUM> (in <FIG>), and a GPU <NUM>, which can correspond to GPU <NUM>, where the CPU <NUM> and GPU <NUM> can communicate with one another to perform graphics processing operations. A memory <NUM> is also shown, which may correspond to memory <NUM> and which the CPU <NUM> and/or GPU <NUM> can access in performing the graphics processing operations. In addition, a repository <NUM> is shown for storing memory accessing commands <NUM> and copies of memory resources, such as resource copy <NUM><NUM>,. resource copy N <NUM>, as described herein. As described above, the repository can have been generated to include various memory accessing commands from a sequence of graphics processing operations and/or related copies of memory resources.

The CPU <NUM> can set an initial state for memory <NUM> at <NUM>, which can correspond to an initial state captured before executing graphics processing operations, such as at <NUM> in <FIG>. The CPU <NUM> can instruct the GPU <NUM> to execute memory accessing commands, corresponding to the previously executed graphics processing operations, at <NUM> such to emulate re-execution of the graphics processing operations. As described, one or more settings of the GPU <NUM>, commands <NUM>, etc. can be modified to debug and/or test performance of the GPU <NUM> in different states or environments. In this regard, GPU <NUM> can obtain the commands <NUM> and can begin executing the memory accessing commands, such as the read operation <NUM>, write operation <NUM>, and read operation <NUM>, which can correspond to read operation <NUM>, write operation <NUM>, and read operation <NUM>. For example, the GPU <NUM> can modify memory <NUM> based on the operations <NUM>, <NUM>, <NUM>, and corresponding copies of memory resources (e.g., pages or other portions of memory), including resource copy <NUM><NUM>,. resource copy N <NUM>, etc. to emulate playback of the graphics processing operations.

<FIG> illustrates an example of computing device <NUM> including additional optional component details as those shown in <FIG>. In one example, computing device <NUM> may include processor <NUM> for carrying out processing functions associated with one or more of components and functions described herein. Processor <NUM> can include a single or multiple set of processors or multi-core processors. Moreover, processor <NUM> can be implemented as an integrated processing system and/or a distributed processing system.

Computing device <NUM> may further include memory <NUM>, such as for storing local versions of applications being executed by processor <NUM>, related instructions, parameters, etc. Memory <NUM> can include a type of memory usable by a computer, such as random access memory (RAM), read only memory (ROM), tapes, magnetic discs, optical discs, volatile memory, non-volatile memory, and any combination thereof. Additionally, processor <NUM> and memory <NUM> may include and execute an operating system executing on processor <NUM>, one or more applications, display drivers, etc., as described herein, and/or other components of the computing device <NUM>.

Further, computing device <NUM> may include a communications component <NUM> that provides for establishing and maintaining communications with one or more other devices, parties, entities, etc. utilizing hardware, software, and services as described herein. Communications component <NUM> may carry communications between components on computing device <NUM>, as well as between computing device <NUM> and external devices, such as devices located across a communications network and/or devices serially or locally connected to computing device <NUM>. For example, communications component <NUM> may include one or more buses, and may further include transmit chain components and receive chain components associated with a wireless or wired transmitter and receiver, respectively, operable for interfacing with external devices.

Additionally, computing device <NUM> may include a data store <NUM>, which can be any suitable combination of hardware and/or software, that provides for mass storage of information, databases, and programs employed in connection with examples described herein. For example, data store <NUM> may be or may include a data repository for applications and/or related parameters not currently being executed by processor <NUM>. In addition, data store <NUM> may be a data repository for an operating system, application, display driver, etc. executing on the processor <NUM>, and/or one or more other components of the computing device <NUM>.

Computing device <NUM> may also include a user interface component <NUM> operable to receive inputs from a user of computing device <NUM> and further operable to generate outputs for presentation to the user (e.g., via display interface <NUM> to a display device). User interface component <NUM> may include one or more input devices, including but not limited to a keyboard, a number pad, a mouse, a touch-sensitive display, a navigation key, a function key, a microphone, a voice recognition component, a gesture recognition component, a depth sensor, a gaze tracking sensor, any other mechanism capable of receiving an input from a user, or any combination thereof. Further, user interface component <NUM> may include one or more output devices, including but not limited to a display interface <NUM>, a speaker, a haptic feedback mechanism, a printer, any other mechanism capable of presenting an output to a user, or any combination thereof.

Computing device <NUM> includes a GPU <NUM>, as described herein, for rendering images based on rendering instruction received from processor <NUM>. GPU <NUM> can additional send signals via a display interface <NUM> to cause display of the rendered images on a display (not shown). Additionally, computing device <NUM> includes a memory modification tracking component <NUM>, as described herein, to track and capture modification of memory (e.g., memory <NUM>) caused by performing graphics processing operations. For example, memory modification tracking component <NUM> can store capture information in data store <NUM>, as described herein, for subsequent playback. Computing device <NUM> also includes a playback component <NUM> for providing the capture information back to the GPU <NUM> to emulate re-execution of the graphics processing operations, as described.

Accordingly, in one or more examples, one or more of the functions described may be implemented in hardware, software, firmware, or any combination thereof. By way of example, and not limitation, such computer-readable media can comprise RAM, ROM, EEPROM, CD-ROM or other optical disk storage, magnetic disk storage or other magnetic storage devices, or any other medium that can be used to carry or store desired program code in the form of instructions or data structures and that can be accessed by a computer. Disk and disc, as used herein, includes compact disc (CD), laser disc, optical disc, digital versatile disc (DVD), and floppy disk where disks usually reproduce data magnetically, while discs reproduce data optically with lasers.

Claim 1:
A method for capturing and executing graphics processing operations, comprising:
activating (<NUM>) a memory trap function (<NUM>, <NUM>) to cause a graphics processing unit (<NUM>, <NUM>), GPU, to report memory accesses in executing graphics processing operations; receiving (<NUM>), based on activating the memory trap function and for each of a sequence of executed graphics processing operations executed by the GPU, a sequence of multiple memory accessing commands and associated portions of memory modified based on executing the sequence of executed graphics processing operations, wherein the sequence of multiple memory accessing commands results from executing the sequence of executed graphics processing operations by the GPU;
storing (<NUM>), in a repository (<NUM>, <NUM>), each of the sequence of multiple memory accessing commands and associated portions of memory;
the method characterized by the further step of:
providing (<NUM>), to the GPU, at least a portion of the sequence of multiple memory accessing commands and associated portions of memory to emulate re-executing of the sequence of graphics processing operations by the GPU by executing the provided portion of the sequence of memory commands.