HK1228552B - A method and system for interactive graphics streaming - Google Patents

Description

Method and system for interactive graphics streaming

Technical Field

The present invention is in the field of interactive graphics streaming. More particularly, but not exclusively, the present invention relates to interactive graphics streaming from an application on a server for display by a GPU on a remote client.

Background Art

In the field of interactive graphical applications, such as computer games, users typically download or obtain these applications via physical media and execute them locally on their devices.

However, some providers of interactive graphics applications desire the flexibility and control of executing the graphics application at a server and streaming the rendered graphics from the application across a network to the user for display on the user's device.

The current state of the art for this form of streaming graphical content is to execute the application on a dedicated server that provides a CPU, memory, backing store, and a graphics processing unit (GPU) that renders the application's output into a frame buffer of pixels. The resulting pixels are then retrieved and encoded into a traditional video stream (e.g., h.264) and sent to the client.

This approach has many disadvantages. First, the server must be extremely powerful enough to run computationally and graphics-intensive applications for many users simultaneously; this results in high power usage (and therefore high cooling costs), which is a significant issue in determining commercial viability.

Second, existing video standards (such as h.264) are inherently 'lossy,' meaning they lose image fidelity during the encoding process. Compression artifacts can be reduced by increasing the bandwidth requirements of the stream, but there are hard limits on the bandwidth going into the user's premises and soft limits on the amount of bandwidth going out of the data center where the server is co-located. This means that these systems must accept the introduction of compression artifacts into the content stream to be viable.

Third, real-time video compression is a hugely computationally intensive process, where the bandwidth requirements of the resulting stream are a function of the amount of compression processing already allocated. This increases server load and system latency.

Fourth, thousands of consumer devices (e.g., tablets, mobile devices, and smart TVs) increasingly contain powerful GPUs, which are a vastly underutilized resource when all application graphics processing occurs on the server.

Fifth, display resolutions are increasing rapidly, with many devices now offering 2560*1600 pixels and "4K smart TVs" (4096-pixel wide displays) just around the corner. Pixel-based compression systems (such as h.264) mean that achieving the fidelity required for these displays requires increasing the bandwidth of the encoded video stream.

Therefore, it would be desirable if an interactive graphics streaming system could be developed in which applications are executed on a server and graphics are rendered by a local GPU on a client device.

One such system is described in the following article by P. Eisert and P. Fechteler: "Low Delay Streaming of Computer Graphics", 15th IEEE International Conference on Image Processing, ICIP 2008. However, the approach described in this article involves blanking the server memory at the client. This blanking is bandwidth intensive and may not even require blanking the entire graphics data (for example, the resolution limitations of a particular client device may not support high-resolution textures).

The MPEG-4 standard describes the transmission of compressed geometric meshes and textures to remote devices and can be adapted to provide an interactive graphics streaming system. However, implementing MPEG-4 for a single interactive application would require modifications to the application. Furthermore, the MPEG-4 standard would potentially require retransmission of graphics data from the server to the client for each new stream, resulting in inefficient use of bandwidth between the server and the client.

Therefore, what is desired is an interactive graphics streaming system that provides improved use of bandwidth between a server and a client, that can accommodate varying client device capabilities, and that requires little or no reprogramming of the interactive graphics application.

It is an object of the present invention to provide a method and system for interactive graphics streaming that meets the above expectations while overcoming the shortcomings of the prior art or at least providing a useful alternative.

Summary of the Invention

According to a first aspect of the present invention, there is provided a method of streaming interactive computer graphics from a server to a client device, the method comprising:

a) intercepting a plurality of graphics instructions transmitted from an application to a graphics processing unit (GPU) at the server;

b) processing the graphics instructions at the server to generate graphics data;

c) generating, at the server, index information for at least a portion of the graphic data;

d) transmitting the index information to the client device instead of the graphic data;

e) extracting corresponding graphic data stored at the client device using the index information; and

f) rendering computer graphics at a graphics processing unit (GPU) at the client device using the corresponding graphics data.

The graphics data may include one or more of a graphics state, a collection of static resources, and dynamic resources.

A plurality of objects within the graphics data may be hashed to generate the index information.

The dynamic resource may include a vertex buffer, and index information may be generated for a plurality of modified portions of the vertex buffer. The vertex buffer may be divided into a plurality of blocks, and index information may be generated for a run of the plurality of modified blocks. Index information may be generated for a modified run of the plurality of modified blocks such that the run extends from a first modified bit within a first block in the run to a last modified bit within a last block in the run. The vertex buffer may be divided into a plurality of stripes corresponding to a plurality of vertex fields, and index information may be generated for the plurality of modified stripes.

The method of the first aspect may further include synchronizing the graphics data between the server and the client. When the graphics data includes textures, only the data of the used textures may be synchronized. A configuration file of the client device may determine synchronization of the graphics data. The configuration file of the client device may determine synchronization of the graphics data by allocating multiple lower-resolution graphics to multiple higher-resolution graphics at the client device.

The rendered graphics can be displayed on a display at the client device. The client device can receive user input in response to the displayed graphics, and the user input can be transmitted back to the application executing on the server. The user input can be transmitted at least in part using UDP. State transition events can be synthesized on the server.

The application may be selected by a user from a plurality of applications for execution on the server.

According to a further aspect of the present invention, there is provided a system for transmitting interactive computer graphics streams, comprising:

a server configured to intercept a plurality of graphics instructions transmitted from an application to a graphics processing unit (GPU) at the server, process the graphics instructions to generate graphics data, generate index information for at least a portion of the graphics data, and transmit the index information to a client device in place of the graphics data; and

A client device is configured to extract corresponding graphics data stored at the client device using the index information and render a plurality of computer graphics at a graphics processing unit (GPU) at the client device using the corresponding graphics data.

BRIEF DESCRIPTION OF THE DRAWINGS

Embodiments of the present invention will now be described, by way of example only, and with reference to the accompanying drawings, in which:

FIG1 shows a hardware diagram illustrating a system according to an embodiment of the present invention;

FIG2 shows a block diagram illustrating a processing pipeline according to an embodiment of the present invention;

FIG3 shows a flow chart illustrating a method according to an embodiment of the present invention;

FIG4 shows a block diagram illustrating the interaction between a client player and a server according to an embodiment of the present invention;

FIG5 shows a flowchart illustrating interception of graphics instructions according to an embodiment of the present invention;

FIG6 shows a flowchart illustrating creation of a hash key set according to an embodiment of the present invention;

FIG7 shows a flowchart illustrating compression of graphics commands according to an embodiment of the present invention; and

FIG8 : shows a block diagram illustrating hashing of vertex buffer blocks according to an embodiment of the present invention.

DETAILED DESCRIPTION

The present invention provides a method and system for streaming interactive graphics from a server to a client device.

The system collects the output of applications executing on the server and uses semantically driven compression to enable local rendering of the output in real time on the client using its own graphics processing unit (GPU).User input on the client device is fed back to the server to enable interaction with the executing application.

The data that drives the application and the processing of that data remain secure on the server, while the graphical results are streamed for rendering on the client device.

This enables client devices to leverage their GPUs to shift processing costs from the server while retaining the security advantages of a client-server architecture.

In FIG. 1 , an interactive graphics streaming system 100 according to an embodiment of the present invention is shown.

The system 100 includes a server 101 and at least one client device 102. The server 101 and the client device 102 can communicate via a communication network 103.

The server 101 may include a central processing unit 104 configured to execute an application module, an interceptor module, a processing module, and a communication module.

The client device 102 may include a central processing unit 105 configured to execute the second processing module, a local memory 106 configured to store indexed graphics data, and a graphics processing unit (GPU) 107 configured to render graphics. The client device 102 may also include a user input 108 and a display device 109. The display device 109 may be configured to display rendered graphics to the user. The client device 102 may be further configured to receive input from the user in response to the displayed graphics and transmit the input to the server 101.

In FIG. 2 , a graphics processing pipeline 200 according to an embodiment of the present invention will be described.

There is shown an application module 201. The application module 201 may be a standard software implementation of an application that generates images in response to user input, such as a computer game application.

The application module 201 generates graphics instructions intended for transmission to a local graphics processing unit (GPU).

These instructions may be intercepted by the interceptor module 202 and, therefore, usefully, the application module 201 does not have to be modified to function in embodiments of the graphics processing system of the present invention.

The interceptor module 202 can redirect all of these instructions to the processing module 203. Therefore, the device executing the application module 201 does not need a graphics processing unit (GPU) or need not use a graphics processing unit.

The processing module 203 may process graphics instructions to generate graphics data, such as graphics states, static resources, or dynamic resources.

Then, the processing module 203 may use the graphic data to generate index information.

The index information may be transmitted to a remote device via the communication module 204 .

The second processing module 205 on the remote device may receive this index information and may retrieve the graphics data corresponding to the index information from the local memory at the remote device.

This graphics data may be utilized by a renderer 206 at a graphics processing unit (GPU) at the remote device to render graphics.

In FIG3 , a method 300 of streaming interactive graphics from a server to a client device will be described.

In step 301 , an interactive graphics application executing on a server generates graphics instructions for a graphics processing unit (GPU).

In step 302, these instructions are intercepted, for example, by an interceptor module.

In step 303, the intercepted instructions are processed by a processing module to generate graphic data. The graphic data may include graphic states, static resources, and/or dynamic resources.

In step 304, index information for the graphic data is generated. For example, objects in the graphic data may be hashed to generate a hash code.

In one embodiment, when the dynamic resource is a vertex buffer, the vertex buffer can be partitioned and hashed to reduce unnecessary retransmissions of the entire vertex buffer after changes. For example, the vertex buffer can be divided into multiple blocks, and a hash can be generated for each run of multiple modified blocks. A run of blocks can be a modified run of blocks, such that a hash is generated from the first change of the first block of the run to the last change of the last block of the run.

In step 305 , this index information is transmitted to the client device instead of the graphic data.

In step 306 , the index information is used to retrieve corresponding graphics data at the client device.

In step 307, this graphics data is transmitted to a graphics processing unit (GPU) at the client device for rendering of the graphics.

In step 308, the graphic may be displayed to the user.

In step 309, the user may provide input that is fed back to the interactive graphics application executing on the server.

In one embodiment, the method further includes the step of synchronizing graphics data between the server and the client. During synchronization, only a portion of the graphics data may be transmitted. For example, mipmaps may be removed from the graphics data prior to transmission and regenerated at the client, reduced-resolution textures may be sent instead of high-resolution textures based on the resolution capabilities of the client device, and actual utilized texture data may be transmitted to the client device.

One embodiment of the present invention will be described with reference to FIG. 4 to FIG. 8 .

This embodiment allows the server to provide multiple applications that can be called remotely from the client device. The application logic running on the server and the graphical output of the application are streamed to the client device over the Internet for local rendering.

It will be understood that the various features described in connection with this embodiment may be implemented in full to present this system or may be implemented in part to present a potentially less efficient system.

As shown in Figure 4, the process begins with a client player application running on a client device (PC, tablet, smart TV, mobile device). This player application uses TCP/IP to connect to a "carousel" running on a server that displays currently available applications. An application is selected and a session is initiated for the client using a TCP connection that switches to the launched application, allowing the application to continue communicating with the client.

This embodiment requires lossless downstream communication. Therefore, TCP or lossless UDP protocols can be advantageously used for downstream communication, and the (lossy but low-latency) UDP protocol can be used for upstream client input communication. Upstream client input (such as locator devices, keyboards, joysticks) can all be sent in an "absolute form" along with the actual "state transition events" being synthesized on the server for the running application. This approach can allow UDP packets to be dropped without missing potentially important state transition events that change the behavior of the application. For example, the mouse moves as the button is pressed, rather than the mouse moving when the button is not pressed.

In normal operation, the side effect of an application calling a 3D graphics driver will be the calculation of pixels that are written to the frame buffer and displayed. As shown in Figure 5, the process of this embodiment operates by intervening in an existing application running on a server using an agent that directs the graphics command stream and all associated resources to the system of the present invention.

The proxy manages the transmission of the data to the remote client device where it is rendered and the current image is created.

The amount of data streamed from an application to a 3d graphics system is typically large and difficult to deliver to a remote client without the aid of a semantically driven compression process as described below.

This embodiment of the present invention works by leveraging the knowledge of what the data flowing from the application to the graphics system represents and how to process that data in an efficient manner. This data stream can be viewed as extending state, evolving state, and side effects (usually GPU commands) on the remote device.

This embodiment allows the observation that when generating frames at 30 Hz, the working set of graphics assets evolves at a more moderate rate, since there is generally geometric inter-frame coherence. The inventors also observed that because the data stream is generated by an application with a fixed scheduling sequence at a certain granularity, this can be used to avoid transmitting data previously sent to the client device.

When a client connects to a service, as part of the handshake protocol, it gives the server:

A client profile that details its graphics capabilities and requested resolution. These graphics capabilities are used to ensure that the proxy emulates what the client is capable of performing.

A set of hash keys, where each key uniquely identifies a blob of data that the client has cached locally. This cache can be populated indefinitely from a CDN (Content Delivery Network) or from removable media (such as a USB flash drive) from previous sessions.

The hash key set ensures that the server will always use the hash key (also known as the data digest) instead of resending the data, thereby reducing bandwidth requirements. Figure 6 shows the general technique.

Hash keys are typically much smaller than the data they represent, typically 64-bit or 128-bit keys. However, bandwidth can be further reduced by maintaining a small additional cache (e.g., 256 entries) of indices to the hash keys of recently used data blobs. This allows the size of "Send Resource Update" commands to be reduced.

Graphics Commands

As shown in FIG7 , graphics commands are captured as they are issued by the application and delayed until as late as possible to be encoded using lossless entropy coding (such as Huffman coding), deduplicated relative to the client's historical graphics commands, and compressed using a sliding window dictionary.

The trigger for firing a command stream is the manifestation of a side-effect command (such as a draw command or an end-of-frame command), at which point all relevant state that has been changed by the application is resolved to ensure that it is synchronized on the remote device.

The amount of data required to apply a graphics command frame (when clearly application dependent) is typically low, since the graphics commands (but not necessarily the graphics parameters) used in the current frame are very similar to the graphics commands of the previous frame.

Identifying Changed States

There are several types of states used in real-time graphics, and each state can be handled differently:

Graphics state

Static resources

Dynamic resources

Graphics State

The graphics state includes all states that control the operation of the client graphics system. This includes the render state (RenderState) and miscellaneous fixed-function controls (e.g., viewport size, framebuffer clear color), as well as shaders and shader constants. These states are handled by gradually fading server-client state to reduce unnecessary transfers and bursts of wrapped public render state into custom code used by graphics applications—for example, when creating a new texture to use, almost all graphics programs also set the downscaling and upscaling filtering and wrapping mode. All of this can be compressed into a single low-overhead command.

Shader constants (also called uniforms) are a method used by graphics applications to parameterize their shader code. They are presented to the application as a linear register file with N 4-tuples, where N is typically greater than 128. This register file is used in any way the application sees fit, meaning that embodiments of the present invention require careful processing of this file to ensure, for example, that the entire register file is not transferred every time a shader is used. A number of procedures can be used to reduce bandwidth:

Identify common values, such as 0.0 and 1.0

Lossy re-encoding to lower precision (e.g. half-float and ranged integers)

Per-shader blanking register files to reduce jitter

Run-length encoding changes

Static resources

The lifecycle of static resources is such that, once created, they are simply referenced as part of the graphics processing until they are no longer needed, at which time they are disposed of.

For static assets, this works in a straightforward manner, as any reads/writes made by the application to the asset can be intercepted and the contents of the hash can be checked against the set of hash keys.

As part of the standard 3D graphics API (application programming interface), when an application interacts with a graphics resource, it must provide flags indicating its intent. These flags are used by regular graphics drivers to optimize performance on the local machine.

In this embodiment, the flag can be repurposed to help identify resources that are likely to remain unchanged. In the current embodiment, if a resource is marked as "WRITE_ONLY" and all memory for this resource has been referenced, it can be assumed that this is a static resource - for example, a static geometry mesh. This static resource can be hashed, checked against a hash key set, and optionally delivered to the client device.

As mentioned above, shader code is always static and performs hash key set detection. Client devices use different shader languages, so automatic shader decoding can be used on the server to convert shaders written in HLSL to shaders written in GLSL before hashing.

Likewise, the vertex declaration describing the vertex buffer layout is static.

Most textures are also static assets, but this poses a problem of being large resources. The current embodiment mitigates this problem by:

Only transmit textures that are actually used. A further refinement could be to identify the parts of the texture that are actually used by examining the geometry's texture coordinates, which specify the area of the texture atlas on the map.

Control the capabilities of the proxy graphics driver to reduce the apparent minimum texture size that will be accepted from the application. This takes advantage of the fact that graphics applications are designed to run on a wide range of performance profiles, with applications generally requiring varying fidelity based on the characteristics and performance of the user's graphics driver. By changing the proxy driver capabilities, the application can be indirectly controlled.

Identifying textures where mipmaps can be generated on the client from the top-level texture reduces the amount of data sent by 33%. A further refinement could be to collect data from previous game sessions to determine which mipmap of a texture is actually used. For 3D content, it is not uncommon to have textures with a much higher resolution than required at runtime.

Use hash key sets to replace lower resolution assets that better match client device capabilities. This can be driven out of the client configuration file and performed on a per-application basis.

Dynamic Resources

As with static resources, 3D applications often have resources that evolve over time, and these 3D applications pose challenges for bandwidth-constrained client devices. The most common way to edit dynamic resources is to use a special buffer called a vertex buffer that contains geometric information. The format of this vertex buffer is flexible and is defined by a previously declared vertex declaration that describes the different fields and offsets of the vertex buffer so that the graphics hardware can interpret the data.

Resources that are dynamically updated by applications use a lock/unlock paradigm to ensure that consumers of data, the graphics hardware, and producers of data, the applications, do not conflict.

It's common for 3D applications to lock a vertex buffer containing geometry, make changes, and then use that data to draw some element of the display. Locking APIs typically provide parameters that indicate which portion of the vertex buffer will be edited; however, these parameters are often set by the application for the entire buffer, since the application's "agreement" with the locking operation is simply to not change data currently in use by the graphics hardware.

This problem can be solved by introducing a hashed lock buffer between the application and the vertex buffer.As with other parts of the invention, information about how to process vertex buffers from previously declared structures and empirical knowledge about how vertex buffers are used in practice can be exploited.

The hashed lock buffer splits the vertex buffer into fixed-length blocks. In the current embodiment, 1024-byte blocks are used, but this can be adjusted for performance reasons. Each block tracks whether it is "dirty" (has been changed and therefore will need to be synchronized with the client device), whether it can be "clean" (has been synchronized, whether the application can ever overwrite the data), and where in the dirty block the change started.

This metadata is accumulated for each block as the application performs lock-edit-unlock operations.When the data must be parsed because it is to be used by a drawing command, the client device must synchronize with the server.

To ensure a match is obtained in the hash key set, the same run of changed data must be accurately identified. Identifying the included runs will produce different hashes and therefore does not allow to avoid sending large amounts of data. The current embodiment uses runs of dirty blocks to identify areas that need to be updated.

These regions are further refined by using the start of the first block and the end of the last block where the data differs, resulting in a "corrected run of dirty blocks." Furthermore, using currently valid vertex declarations ensures that the data is processed at the correct granularity, i.e., the hash does not begin in the middle of the vertex structure because the first few bytes just don't differ. By using vertex declarations, this embodiment wraps around to the start of the complete vertex and finishes at the end of the complete vertex.

The next problem is that for graphics applications, it is common and encouraged to store different vertex data types in the vertex buffer. However, it is not common to update all fields of the vertex. For example, the vertex color and vertex texture coordinates can be constant, but the vertex position can vary.

A (pseudocode) vertex declaration might look like this:

When a fixup run for a polluted block can be hashed and such an embodiment of the system will operate, bandwidth can be further reduced by using vertex declarations in the operations for processing the fixup run for a polluted block on a per-stripe basis.

That is, the system can go across the vertex buffer (optionally compressed) and hash similar types of data together, so that in this example the system generates three hashes for the three fields that each vertex has. The result is that the system will find the color strip and the texture coordinate strip in the key set and will not need to send those strips to the client device. A changing vertex position will need to be sent if and only if the system has not seen that vertex position before. For example, for a looping animation, this will quickly fill the key set with matching hashes.

Buffer reuse

In the current embodiment, the system interfaces with the Microsoft DirectX 3D graphics API and exploits additional semantic insights gained from flag parameters provided when the application locks vertex buffers and a "best practices" calling sequence supported by Microsoft.

A common use case for vertex buffer locking is to gradually fill a buffer with dynamically generated geometry until the buffer is full and then start again from the beginning. To ensure that the graphics hardware can continue to operate at full speed, the graphics API introduces two additional flags for this application: NO_OVERWRITE and DISCARD.

NO_OVERWRITE means that the application promises to never overwrite any data it has previously written to the buffer. The reason for this promise is so that the graphics hardware can remain confident and future-proof when using memory mapping, direct memory access (DMA), or any other means of accessing this data.

DISCARD means that the application indicates that the buffer is "write once" and will not be read from it subsequently. The reason for this commitment is that it allows the graphics hardware to continue operating on existing buffers while the application fills new buffers and while buffers are unlocked, quietly swapping buffers inside the driver and disposing of other buffers that it knows will never be needed again.

Application developers are encouraged to use these two flags together by gradually filling the NO_OVERWRITE buffer with graphics data, extracting portions of it. When the point is reached where no more data can fit into the buffer, the developer locks the buffer with the DISCARD flag and begins filling it again from the beginning. This system allows the graphics hardware to operate at maximum efficiency.

This embodiment of the invention uses this knowledge to identify when the system detects a short dirty run of blocks at the beginning of the DISCARD buffer after the same buffer locked for OVERWRITE is most likely associated, as shown in Figure 8. This short dirty run of blocks in the DISCARD buffer will most likely not match the hash key set and will need to be sent.

Therefore, a new DISCARD buffer run can be treated as a continuation of the previous run at the end of the buffer to ensure that the hash key sets match.

Potential advantages of some embodiments of the present invention are:

a) No specialized, power-hungry GPU is required on the server, and therefore standard servers can be used. This in turn means the number of users per server can be higher, reducing operating costs.

b) The present invention can be resolution independent and, unlike pixel-based video compression, can play back at high resolutions without increasing streaming bandwidth requirements.

c) For some applications running at high resolutions, bandwidth requirements can be extremely low (<1 Mbs) due to reliance on compression that exploits knowledge of what is being compressed.

d) The present invention may not require changes to existing executable applications and therefore does not require access to source code for modification and can therefore be used on existing and legacy software.

e) Arbitrary new content can be injected into the stream in real time to repurpose it for new devices and platforms. For example, overlays for virtual buttons can be created when running on a tablet computer, banner ads around content can be introduced, and images used to insert ads into the virtual world of a video game can be replaced.

f) Fine-grained resource usage information from users can be collected to help refine where assets are kept on the CDN (Content Delivery Network) and remove redundant data from the stream for future users.

Although the present invention has been illustrated by the description of its embodiments, and although the embodiments have been described in considerable detail, applicants do not intend that the scope of the appended claims be limited or in any way restricted to such details. Additional advantages and modifications will readily occur to those skilled in the art. Therefore, the present invention in its broader aspects is not limited to the specific details, representative apparatus and methods, and illustrative examples shown and described. Accordingly, departures from such details may be made without departing from the spirit or scope of applicants' overall inventive concept.

Claims (23)

1. A method for streaming interactive computer graphics from a server to a client device, the method comprising: The application is executed on the server, and the application generates graphics instructions for the graphics processing unit (GPU) in the server. The server intercepts the generated graphical commands, which are transmitted from the application. The intercepted graphical commands are processed at the server to generate graphical data; During the execution of the application's instructions to generate other graphics, without transmitting all the generated graphics data to the client device, a portion of the generated graphics data and the graphics data stored on the client device are synchronized, wherein the synchronization is performed based on the client device's configuration file, which identifies the client device's graphics capabilities. At the server, at least a portion of the generated graphic data is indexed. The index information is transmitted to the client device in place of at least a portion of the generated graphic data. The index information is used at the client device to retrieve the corresponding graphic data stored at the client device; and The extracted graphics data is used to render computer graphics at the graphics processing unit (GPU) on the client device. 2. The method of claim 1, wherein the graphics data includes one or more of a set of graphics states, static resources, and dynamic resources. 3. The method of claim 1, wherein multiple objects in the graphic data are hashed to generate the index information. 4. The method of claim 2, wherein the dynamic resources include vertex buffers. 5. The method of claim 4, wherein the index information is generated for multiple portions of the vertex buffer. 6. The method of claim 5, wherein the vertex buffer is divided into multiple blocks, and index information is generated for the operation of the multiple blocks. 7. The method of claim 6, wherein the index information is generated by a correction run for the plurality of blocks such that the correction run extends from the first modified bit in the first block of the run to the last modified bit in the last block of the correction run. 8. The method of claim 4, wherein the vertex buffer is divided into multiple stripes corresponding to multiple vertex fields, and the index information is generated for the multiple stripes. 9. The method of claim 1, wherein the generated graphics data includes a low-resolution texture and a high-resolution texture, and the low-resolution texture is sent in place of the high-resolution texture based on the resolution capability of the client device. 10. The method of claim 1, wherein, when the graphics data includes textures, only the following textures included in the graphics data are synchronized: textures used to render computer graphics at the GPU of the client device. 11. The method of claim 1, wherein the configuration file of the client device includes the resolution requested by the client device, and the synchronized portion of the generated graphics data is determined based on the resolution requested by the client device. 12. The method of claim 11, wherein the synchronization comprises: transmitting a low-resolution graphic instead of a high-resolution graphic included in the generated graphic data. 13. The method of claim 1, wherein the rendered computer graphics are displayed on a display at the client device. 14. The method of claim 13, wherein the client device receives user input in response to the displayed computer graphics, and the user input is transmitted back to the executing application on the server. 15. The method of claim 14, wherein the user input may be transmitted at least partially using the User Datagram Protocol (UDP). 16. The method of claim 15, wherein a plurality of state transition events are synthesized on the server. 17. The method of claim 1, wherein the application is selected by the user from a plurality of applications for execution on the server. 18. The method of claim 1, wherein the graphics data stored at the client device comprises: a portion of graphics data received from the server, and graphics data generated at the client device. 19. A system for streaming interactive computer graphics, the system comprising: Client devices; and The server is configured to be used for: The application is executed, which generates graphics instructions for the graphics processing unit (GPU) in the server. The system intercepts generated graphics commands transmitted from the application, processes these commands to generate graphics data. During the execution of the application's instructions to generate other graphics, without transmitting all the generated graphics data to the client device, a portion of the generated graphics data and the graphics data stored on the client device are synchronized, wherein the synchronization is performed based on the client device's configuration file, which identifies the client device's graphics capabilities. At least a portion of the generated graphic data should be indexed. The index information is transmitted to the client device in place of at least a portion of the generated graphic data. The client device is configured to use the index information to extract the corresponding graphics data stored on the client device and to use the extracted graphics data to render multiple computer graphics on the graphics processing unit (GPU) of the client device. 20. The system of claim 19, wherein the generated graphics data includes a dynamic resource having a vertex buffer divided into multiple blocks, generating the graphics data includes modifying a portion of the previously generated blocks, and generating the index information for the modified blocks. 21. A server configured for use in the system of claim 19. 22. A client device configured for use with the system of claim 19. 23. A system for streaming interactive computer graphics, the system comprising: Client devices; and A server configured to: execute an application that generates graphics instructions for a graphics processing unit (GPU) in the server; intercept the generated graphics instructions transmitted from the application; process the intercepted graphics instructions to generate graphics data; synchronize a portion of the generated graphics data with graphics data stored on the client device without transmitting all of the generated graphics data to the client device, wherein the synchronization is performed based on a configuration file of the client device that identifies the graphics capabilities of the client device; generate index information for at least a portion of the generated graphics data; and transmit the index information to the client device in place of at least a portion of the generated graphics data. The client device is configured to extract corresponding graphics data stored on the client device using the index information; and to render computer graphics on the graphics processing unit (GPU) of the client device using the extracted graphics data. The graphics data stored on the client device includes: a portion of the graphics data received from the server, and graphics data generated on the client device based on information generated on the server.