Permanent memory for graphics hardware

Abstract

Graphics card, including: a graphics processor, GPU (18) on the graphics card; a volatile memory (48) on the graphics card, the volatile memory (48) being associated with the GPU (18); an interface on the graphics card to enable communication with a solid state drive (SSD) (34); a bridge chip (70) on the graphics card to enable communication between the GPU (18) and the interface on the graphics card via a Peripheral Components Interconnect express, PCIe bus (24) on the graphics card, wherein the PCIe bus (24) on the graphics card serves to enable GPU control of the SSD (34); and wherein the GPU (18) is used to access the SSD (34) for data when the data is not stored in the volatile memory on the graphics card, wherein the GPU (18) serves to request the data from a CPU if the data is not stored on the SSD (34).

Description

BACKGROUND

[0001] Game engines can be highly optimized pieces of software that provide a framework for 3D (three-dimensional) rendering, user interaction, scene management, physical modeling, artificial intelligence, and other capabilities required for a given game application. Game applications can use hardware-accelerated graphics APIs (application programming interfaces) to support the capabilities of a local GPU (graphics processing unit). This support may include offloading graphical and non-graphical computation to the GPU to maintain interactive frame rates. In particular, the normal method may be to transfer content from the host system's disk, decode / decompress the content into system memory if necessary, and then transfer the content to the GPU using an API (e.g., DirectX or OpenGL APIs).This process is typically bound by the disk input / output (IO) capabilities of the host system. Accordingly, there can be significant overhead imposed by the host system's hardware during memory operations (e.g., loading, transferring, and saving game assets to / from volatile memory associated with the GPU). Indeed, such overhead may be encountered every time the application initializes or updates itself during runtime.

[0002] US 2008 / 0106552 A1 discloses loading texture data into a remote primary or local memory of a graphics processor and generating and loading alternative texture data if certain texture data is present in the local memory.

[0003] US 6704021 B1 discloses loading a vertix buffer via a temporary vertix buffer.

[0004] US 7 075 541 B2 discloses systems and methods for balancing a load between multiple graphics processors rendering different parts of a frame. BRIEF DESCRIPTION OF THE DRAWINGS

[0005] The various advantages of the embodiments of the invention will be apparent to those skilled in the art upon reading the following description and the appended claims and upon reference to the following drawings in which: Fig. 1 is a block diagram of an example conceptual computing architecture according to an embodiment; Fig. 2 is a flowchart of an example method for processing content according to an embodiment; Fig. 3A is a block diagram of an example process flow for texture content contained in persistent memory of a GPU, according to one embodiment; Fig.3B is a block diagram of an example process flow for texture content not contained in persistent memory of a GPU, according to one embodiment; Fig. 4A and Fig. 4B are block diagrams of examples of systems according to embodiments; and Fig. 5A and Fig. 5B are block diagrams of examples of driver stacks according to embodiments, DETAILED DESCRIPTION

[0006] The invention relates to a graphics card, a data processing system equipped therewith and a storage medium as defined in the patent claims.

[0007] Embodiments may provide a computer-readable storage medium including a set of stored instructions that, when executed by a processor, cause a computer to recognize a request for content and determine whether persistent memory associated with a graphics processing unit (GPU) contains the content.

[0008] Embodiments may also provide a device including a graphics processing unit (GPU), persistent memory associated with the GPU, and a computer-readable storage medium. The computer-readable storage medium may include a set of stored instructions that, when executed by a processor, cause the device to recognize a request for content and determine whether persistent memory contains the content. The computer-readable storage medium may be part of or separate from persistent memory.

[0009] Other embodiments may include a system having a host device with a central processing unit (CPU) for executing a graphics application. The system may also include a graphics processor (GPU), persistent memory associated with the GPU, and volatile memory associated with the GPU. Furthermore, the system may include a computer-readable storage medium including a set of stored instructions that, when executed by a processor, cause the system to detect a request for texture content from the graphics application and determine whether the persistent memory contains the texture content. The instructions may also cause the system to allocate a buffer resource to the texture content if the persistent memory contains the texture content and return an identifier of the buffer resource to the host device.The instructions may also cause the system to transfer the texture content to the buffer resource when a graphics optimization criterion is met and to transfer the texture content from the buffer resource to volatile memory via a DMA (direct memory access) request.

[0010] With reference now to Fig.1, an architecture 10 includes a host device with a CPU 12, volatile memory, such as system memory 14, and persistent storage, such as disk 16. The illustrated architecture 10 also includes a GPU 18 with associated persistent memory (non-volatile memory, NVM) 20 and associated volatile memory, such as GDDR (graphics double data rate) memory 22. As discussed in more detail, the GPU 18 and NVM 20 may reside on the same or separate cards / substrates. The NVM 20 may be a NAND-based SSD (solid state disk), a USB (Universal Serial Bus, e.g., USB Specification 2.0, USB Implementers Forum) flash storage device, a hard disk drive (HDD), etc. The GPU 18 and its associated memories 20, 22 may communicate with the CPU 12 via a graphics bus 24, such as a PCI Express Graphics (PEG, e.g.Peripheral Components Interconnect / PCI Express x16 Graphics 150W-ATX Spezifikation 1,0, PCI Special Interest Group)-Bus, oder Accelerated Graphics Port-(z. B. AGP V3.0 Schnittstellenspezifikation, September 2002)-Bus.

[0011] By providing a dedicated NVM 20 to the GPU 18, the illustrated architecture 10 represents a more balanced platform where advanced graphics rendering and compute capabilities can be facilitated. As discussed in more detail, the ability to quickly transfer graphical content from the NVM 20 to the GDDR 22 can allow content to bypass the traditional GPU loading mechanism and can therefore provide significantly improved loading times for graphics applications. For example, the content / assets loaded into the 3D graphics pipeline can be stored in the NVM 20 for later use, and the stored data can be loaded and restored within the 3D graphics pipeline at a later time in the same state in which the data existed when it was stored. Consequently, loading performance can be improved.

[0012] Other load time performance improvements may involve the use of procedurally generated content. Such content can result from a variety of algorithmic techniques that may require high computational power. Instead of generating procedural content at load time, procedural assets can be generated once and then stored in the NVM 20 for later retrieval. This approach can reduce the amount of potentially redundant content generation, which can further improve load times. In particular, such an approach can be used in dynamic LOD (level-of-detail) systems, where computationally expensive mesh subdivision or simplification can be applied only once per single object. Different versions of each mesh (at different LODs) can be pre-computed in this way and cached in the NVM 20 for later use.Accordingly, LOD levels can be calculated only once for an application and may persist across multiple load cycles. Architecture 10 may enable other benefits to be achieved, as will be discussed in more detail.

[0013] Fig.2 shows a method 26 for processing content. The method 26 may be implemented as a set of executable device driver instructions stored in a machine- or computer-readable storage medium, such as RAM (random access memory), ROM (read-only memory), PROM (programmable ROM), flash memory, etc., in fixed-functionality hardware using circuit technology, such as ASIC (application-specific integrated circuit), CMOS (complementary metal oxide semiconductor), or TLL (transistor-transistor logic), or any combination thereof. For example, computer program code for performing operations shown in the method 26 may be written in any combination of one or more programming languages, including an object-oriented programming language, such as C++ or the like, and conventional procedural programming languages, such as the "CC" programming language or similar programming languages.Additionally, the method 26 may be implemented as embedded logic using any of the aforementioned circuit technologies.

[0014] With continued reference to Fig. 2 and Fig.3A, processing block 28 provides for detecting a request (e.g., "read request") for content. In one example, the read request is received and processed by a driver stack 44 acting as an interface between a host device / system domain 36 and a GPU domain 38. The content may include texture content, vertex content, and / or procedurally generated content, as previously discussed, where the read request may be received from a graphics application executing on a CPU in the host system domain 36. If it is determined at block 30 that an NVM, such as an SSD 34, associated with the GPU domain 38 contains the requested content, a buffer resource may be allocated for the content at block 32. Block 40 provides for returning an identifier of the buffer resource (e.g., "resource handler") to the host system domain 36.

[0015] At block 42, it may be determined whether one or more optimization criteria are met. The optimization criteria may be used by the driver stack 44 to re-request, consolidate, or otherwise optimize requests. For example, advanced implementations may involve optimizing the file system for streaming loads, optimizing spatial locality of accesses, and / or batching read and write requests, etc. Additionally, some form of data compression on the SSD-34 file system may be beneficial to improve the speed of data loads. Simply put, read access of the actual content to the allocated buffer resource may be delayed until it is "performant," urgent, or otherwise appropriate for read accesses to be performed. If the optimization criteria are met, illustrated block 46 provides for transferring the content to the allocated buffer resource.The content may be transferred from the buffer resource to an associated volatile memory, such as DDR memory 48, at block 50. In one example, the transfer to DDR memory 48 is performed via one or more DMA (direct memory access) requests.

[0016] With continued reference to Fig. 2 and Fig.3B, if it is determined at block 30 that the requested content does not reside in SSD 34, block 52 provides for obtaining the content from the memory of the host system domain 36. For example, in the illustrated example, a read / decode is performed on disk 16, and the results are transferred to system memory 14. The content may then be presented to driver stack 44, which returns a handle for a buffer resource associated with DDR memory 48. Additionally, a write may be performed from DDR memory 48 to SSD 34 so that the next time the content is requested, it is retrieved from SSD 34 in GPU domain 38.

[0017] With reference now to Fig. 4A and Fig.5A, a hardware implementation and its corresponding driver stack are shown. In particular, a host device / system 54 may be part of a mobile platform, such as a laptop, personal digital assistant (PDA), wireless smartphone, media player, imaging device, mobile internet device (MID), etc., or any combination thereof. The system 54 may also be part of a fixed platform, such as a PC (personal computer), server, workstation, etc. The illustrated system 54 includes a plurality of CPUs 12 and system memory 14, which may include DDR SDRAM (synchronous dynamic random access memory, e.g., DDR3 SDRAM JEDEC Standard JESD79-3C, April 2008) modules. The system memory 14 modules may be embodied as a SIMM (single inline memory module), DIMM (dual inline memory module), SODIMM (small outline DIMM), and so on.The illustrated CPUs 12 communicate with the system memory 14 via a northbridge 62.

[0018] The CPUs 12 may also communicate with the disk 16 via the northbridge 62 and a southbridge 64. In the illustrated example, the southbridge 64 and disk 16 communicate via a Serial ATA (SATA, e.g., SATA Rev. 3.0 specification, May 27, 2009, SATA International Organization / SATA-IO) bus 66. The host system 54 may include a graphics bus 24 (e.g., PCI-e slot), wherein a graphics card 68 including the GPU 18, DDR memory 48, SSD 34, and a bridge 70 may be coupled (e.g., plugged in) to the graphics bus 24. Therefore, in the illustrated "board model," SSD access by the GPU 18 may be achieved through a direct physical connection on the graphics card 68, which may be mounted either directly on the board of the host system 54 or elsewhere in the system chassis, and connected with a cable.The graphics card 68 can be modified to include a dedicated board bus and / or disk controller to support the SSD.

[0019] In particular, the CPUs may include 12 processor cores (not shown) to execute a host OS (operating system) 56, application software 58, and a driver stack 60, where each core may be fully functional with instruction fetch units, instruction decoders, level one (L1) cache, execution units, etc. In general, the driver stack 60 may include, at the lowest level, a kernel mode driver (KMD) 72 that provides "ring-0" access to the hardware on the graphics card 68. A user mode driver (UMD) 74 may reside on the illustrated KMD 72 and expose certain features of the graphics hardware on a per-application basis. Therefore, failures in the UMD 74 may represent application-level exceptions, while KMD 72 failures may be system-wide. In the illustrated example, an OpenGL (e.g., OpenGL 4.0, the Khronos Group, March 10, 2010) API 76 and a DirectX (e.g.,DirectX® 11 (Microsoft Corporation, Redmond, WA) API 78 is extended at the driver level to add hardware-specific extensions to each API. In addition, a native API 80 can be used to extend DirectX for GPU-SSD operations, and OpenGL can be enhanced through a standard extension interface. Specific APIs are described herein merely to facilitate discussion. Finally, application software 58 sits atop the illustrated DirectX API 78, OpenGL API 76, and native API 80, which can support the capabilities of each.

[0020] In the board example shown, the driver stack 60 accounts for the specific components used in the physical implementation of the graphics card 68. The host driver stack 60 can be constructed in several ways: the software stack for both the graphics adapter and the SSD can be implemented in the host OS 56, the SSD drivers can be implemented on a µOS (micro-OS) 82 running independently on the graphics card 68, etc. In the first case, the GPU 18 can be considered a passive device subordinate to the host OS 56, and the drivers for the SSD 34 and the GPU 18 can be combined as a single unit consisting of driver instructions to be executed by the CPUs 12. In the second case, the GPU 18 can be considered autonomous from the host OS 56, which relies on its own µOS 82 to service IO requests.In this case, the SSD driver may be implemented as an SSD-KMD 84 specific to the µOS 82, with the GPU 18 executing the instructions for SSD-KMD 84 and the host driver stack 60 simply forwarding IO requests to be sent to the graphics card 68.

[0021] With reference now to Fig. 4B and Fig.5B, alternative hardware configuration and corresponding driver implementation are shown using a "cooperative model." In the illustrated example, a graphics card 86 includes a GPU 88 and DDR memory 48, with an SSD 90 coupled to a separate memory card 92. Therefore, the graphics bus 24 (24a-24b) may include a first bus 24a coupled to the graphics card 86 and a second bus 24b coupled to the memory card 92. In the cooperative model, the graphics hardware may be unmodified and combined with a commercially available PCI-e-based SSD 90 (e.g., SSD devices from manufacturers such as Addonics, DDRdrive, and Dolphin, Fuji Xerox, Fusion-io, Intel, Micron, and SanDisk).Instead of attaching the SSD 90 to a traditional HDD and maintaining HDD mounting form factors, the SSD 90 can be implemented entirely on a PCI-e expansion board, which can set a cap on disk throughput compared to PCI-e (e.g., 32 Gb / s). Compared to SATA throughput (e.g., 4.8 Gb / s), such a solution can offer greater throughput at lower mounting costs.

[0022] Therefore, the integration of the GPU 88 and the SSD 90 may simply involve plugging each corresponding card 86, 92 into adjacent memory slots. Furthermore, the mechanics of integration may be handled by a graphics driver stack 94 on the host system 96. Generally, the graphics driver stack 94 may have low-level access to an SSD driver to facilitate direct memory accesses between the DDR memory 48 and the SSD 90. This approach may increase traffic over the graphics bus 24, resulting in lower performance than the board-level solution. Although the traffic generated between the GPU 88 and the SSD 90 may compete with traffic between the GPU 88 and the host system 96, a variety of driver-level optimizations (e.g., including data caching and I / O scheduling) can mitigate this contention.

[0023] Specifically, in the illustrated example, the SSD 90 and the graphics adapter for the GPU 88 can cooperate in many different ways. One scenario may involve an SSD card KMD 98 and a graphics card KMD 100 exposing a low-level interface that allows the SSD 90 to directly access the DDR memory 48 contained on the graphics card 86. Another possible scenario may involve the graphics card 86 exposing SSD hooks into which lines can be placed via a published interface. Many other configurations exist, but a generalization is that the SSD card KMD 98 and graphics card KMD 100 may be independent pieces of software, possibly from different manufacturers, with a low-level interface that enables interoperability between the two devices. Example pipeline integration

[0024] The above techniques can be designed for interoperability with existing graphics pipelines, such as DirectX pipelines. While parts of this discussion may refer to DirectX, the approaches described herein can be easily extended to other scenarios, such as OpenGL pipelines. The basic structure of SSD reads and writes can be consistent with the traditional DirectX command buffer—the set of commands typically used to dispatch draw and state change requests can be enhanced with a small number of IO commands to ensure IO requests are executed in sequence.

[0025] The fundamental storage unit in this software architecture can be a DirectX buffer resource containing texture, vertex, or other content used during rendering. When buffers are written to the SSD, all runtime state information associated with the buffer can be written to the file system along with the corresponding data. Similarly, when buffer data is restored from the SSD, the runtime state of this resource can be restored to the same state the buffer was in when it was saved. Each IO request can contain a string corresponding to a specific file path in a hierarchical file system.

[0026] The way the command buffer is used in read and write requests can be slightly different. For example, a read request may issue an SSD_READ_QUERY command, which is inserted into a queue and host blocks. When the SSD_READ_QUERY request is served, the path can be extracted from the command, and the local file system can verify that the file exists. If the file is valid, a file descriptor can be used to allocate a buffer with an identical configuration to the one used when the file was originally saved. Once the buffer is allocated, a valid resource handle can be returned to the caller, and an SSD_READ_DEFFERED command can be inserted into the command buffer. Up to this point, only the file descriptor can be obtained from the file system.Reading the contents of the allocated buffer can be delayed until an optimization criterion is met. The driver can ensure that the contents of a buffer are loaded from memory before its first access, but before that, the driver can have the freedom to re-query, consolidate, and otherwise optimize requests if necessary.

[0027] Write requests can be much simpler than read requests, as there may be no need to delay access, as the caller isn't waiting for a valid resource handle to return. When a write request is issued, an "SSD_WRITE" command can be inserted into the command buffer. When this command is dispatched, the path can be extracted, and the buffer resource and its descriptor can be written to the SSD. There are many opportunities for optimization despite delay, although these can be highly specific to the driver implementation.

[0028] The above software architecture may culminate in the essential read and write operations necessary for using a GPU-side file system. Since the functionality may fall outside the DirectX or other API specifications, a native API 80 may be created to provide abstraction around the enhanced driver. The native API 80 may include additional features for manipulating and querying the file system. These features may include directory management functions, including creating, deleting, copying, moving, and listing. The native API 80 may also include support for reading, writing, renaming, and deleting individual files, as well as page files, late-binding mechanisms, and file security. Below are some examples of some of the native API 80 functional specifications that may be provided. Write configuration APIERROR API0FileStoreBuffer(const APICONTEXT in_context, const char*in_pFileName,APIBUFFER in_buffer)

[0029] This function can write the configuration and contents of "in-buffer" to the GPU-side file system at the path specified in "in_pFileName." The buffer contents are written to disk, including a header containing information about how to allocate the API buffer resource and how to configure it when reclaimed by API0FileLoadBuffer. The buffer can be guaranteed to be written to disk before the specified buffer is modified.

[0030] Parameter: in_context [in] The context associated with the APIBuffer asset in_pFileName [in] The path of the file to which the buffer should be written in_buffer [in] The buffer resource to be written

[0031] Returns: API_SUCCESS; The buffer was written successfully. API_ALREADY_EXISTS; The specified file name already exists. API_DOES_NOT_EXIST; A directory in the file path cannot be accessed. API_INVALID_HANDLE; The buffer handle is invalid. API_OUT_OF_MEMORY; There is not enough space to save the file. API_NOT_SUPPORTED; There is no GPU-side storage device. Load file APIERROR API0FileLoadBuffer(const APICONTEXT in_context, const char*in_pFileName,APIBUFFER*out_buffer)

[0032] This function can load a file that was previously saved using the API0FileLoadBuffer function. It loads the file specified in "in_pFileName," reads the file header, creates an appropriate buffer resource, and loads the file contents accordingly. If successful, the handle pointed to by "out_buffer" contains the same state and contents as when it was saved. This buffer can be allocated according to its configuration and can be freed using the API0FileDestroyBuffer function, which ensures it is freed in a manner consistent with its creation. This function can return successfully if the specified file is found and an appropriate buffer is allocated. The actual reading from disk to the buffer memory can be delayed but will occur before the buffer is first accessed.

[0033] Parameter: in_context [in] The context associated with the APIBuffer asset in_pFileName [in] The path of the file from which the buffer should be read out_buffer [out] The buffer resource to be created

[0034] Returns: API_SUCCESS; The buffer was written successfully. API_ALREADY_EXISTS; The specified file name already exists. API_DOES_NOT_EXIST; The request file is not available. API_INVALID_HANDLE; The buffer handle is invalid. API_NOT_SUPPORTED; There is no LRB-side storage device. Release buffer APIERROR API0FileDestroyBuffer(const APICONTEXT in_context,APIBUFFER in_buffer)

[0035] This function can free a buffer obtained using the API0FileLoadBuffer function. This function can ensure that the buffer is cleared in a manner consistent with its creation. Because APIFile can handle both native and DirectX shared interfaces, the underlying freeing process can vary from case to case.

[0036] Parameter: in_context [in] The context to be used with the APIBuffer when loading is connected in_buffer [in] The buffer resource to be released

[0037] Returns: API_SUCCESS; The buffer was successfully released. API_INVALID_HANDLE; The buffer handle is invalid. API_NOT_SUPPORTED; There is no LRB-side storage device. Delete file APIERROR API0FileDelete(const APICONTEXT in_context, const char*in_pName)

[0038] This function can delete an existing file saved using the API0FileStoreBuffer function. If "pFileName" refers to a directory, the directory must be empty for successful deletion.

[0039] Parameter: in_context [in] The context execution context in_pName [in] The name of the file to be deleted or Directory

[0040] Returns: API_SUCCESS; The file or directory was successfully deleted. API_DOES_NOT_EXIST; The request file or directory is not available. API_RETRY; The request directory is not empty. API_NOT_SUPPORTED; There is no LRB-side storage device. List file APIERROR API0FileGetDirectoryList(const APICONTEXT in_context, constchar*in_pName,API_FILE_DIR_LIST*out_fileNames)

[0041] This function is used to get a list of file names contained within the specified directory.

[0042] Parameter: in_context [in] The context execution context in_pName [in] The name of the directory to list out_fileNames [out] A structure containing all file names within the specified directory contains

[0043] Returns: API_SUCCESS; The file or directory listing was successfully obtained. API_DOES_NOT_EXIST; The request directory is not available. API_NOT_SUPPORTED; There is no LRB-side storage device. Share list APIERROR API0FileFreeDirectoryList (API_FILE_DIR_LIST*inout_fileNames)

[0044] This function releases an existing API_FILE_DIR_LIST structure obtained from a previous call to API0FileGetDirectoryList.

[0045] Parameter: inout_fileNames [in / out] The address of the file list to be shared

[0046] Returns: API_SUCCESS; The directory was successfully shared. API_INVALID_POlNTER; The specified directory listing is invalid. Create directory APIERROR API0FileNewDirectory (const APICONTEXT in_context, const char*in_pName)

[0047] This function creates a new directory on the GPU-side mass storage device.

[0048] Parameter: in_context [in] The context execution context in_pName [in] The name of the directory to be created

[0049] Returns: API_SUCCESS; The directory was created successfully. API_ALREADY_EXISTS; The specified directory already exists. API_DOES_NOT_EXIST; A directory in the file path cannot be accessed. API_OUT_OF_MEMORY; There is not enough space to create the directory. API_NOT_SUPPORTED; There is no LRB-side storage device.

[0050] Therefore, the techniques described herein can provide a number of improvements for graphics applications, such as combining texture techniques with large SSD storage capabilities. One example is gigapixel image manipulation, where the working set of pixels can far exceed the amount of GDDR memory available on the graphics hardware. By placing persistent memory closer to the GPU, the response time and size of the supported virtual texture maps can be improved. Furthermore, real-time megatextures can support this capability, adding considerable depth and realism to 3D games.

[0051] An additional benefit may involve expanding the types of algorithms that can be applied to non-graphical GPG programmability techniques (e.g., general-purpose computation on graphics processing units / GPGPUs). These techniques can utilize a GPU as a high-performance swap engine, thereby supporting the data parallelism capabilities of its microarchitecture. While this technique can be powerful, it can traditionally only work for a very limited set of algorithms due to the costly transfer from GPU to host system memory over the graphics bus (potentially for each compute pass). However, adding a local SSD to the GPU pipeline can enable applications to mask this latency.By combining local storage of partial results, consolidating transfers, and other techniques, a major limitation of GPGPU-based approaches can be mitigated using the techniques described herein.

[0052] Embodiments of the present invention can be applied to all types of semiconductor integrated circuit (IC) chips. Examples of these IC chips include, but are not limited to, processors, controllers, chipset components, programmable logic arrays (PLA), memory chips, network chips, and the like. Additionally, in some drawings, signal conductor lines are shown with dashes. Some of these may be thicker to represent more significant signal paths, others may include labeling to indicate a number of associated signal paths, and / or they may include arrows at one or more ends to indicate the primary direction of data flow. However, this is not intended to be limiting in any way. Such additional details may be used in connection with one or more example embodiments to provide a better understanding of a circuit.All signal lines shown, whether with or without additional information, can comprise one or more outgoing signals in multiple directions and can be implemented with any suitable signaling scheme, e.g., digital or analog lines can be implemented with differential pairs, fiber optics, and / or asymmetric lines.

[0053] Sizes / models / values / ranges are provided as examples, although embodiments of the present invention are not limited thereto. As manufacturing techniques (e.g., photolithography) mature over time, it is expected that increasingly smaller devices will be produced. Furthermore, well-known power / ground connections to the IC chips and other components may or may not be shown in the figures for the sake of simplicity of illustration and discussion, and to avoid obscuring certain aspects of the inventive embodiments.Furthermore, arrangements may be shown in block diagram format in order not to obscure embodiments of the invention, and also to demonstrate that specific details relating to the implementation of such block diagram arrangements depend largely on the platform in which the invention is to be implemented, meaning that those skilled in the art should be familiar with such specific details. Where specific details (e.g., circuits) are recited to describe exemplary embodiments of the invention, those skilled in the art should recognize that embodiments of the invention may be implemented with or without variations of these specific details. The description is therefore to be understood as a non-limiting illustration.

[0054] For example, some embodiments may be implemented using a machine-readable or tangible computer-readable medium or product that can store an instruction or set of instructions that, when executed by a machine, can cause the machine to perform a method and / or operations consistent with the embodiments. Such a machine may, for example, include any suitable processing platform, computing platform, computing device, processing device, computer system, processing system, computer, processor, or the like, and may be implemented using any suitable combination of hardware and / or software.The machine-readable medium or product may, for example, include any suitable type of storage unit, storage device, storage product and / or storage medium, such as memory, removable or non-removable storage medium, erasable or non-erasable storage medium, writable or rewritable storage medium, digital or analog storage medium, hard disk, floppy disk, CD-ROM (Compact Disk Read Only Memory), CD-R (Compact Disk Recordable), CD-RW (Compact Disk Rewriteable), optical disk, magnetic disk, magneto-optical disk, removable memory cards or diskettes, various types of DVDs (Digital Versatile Disks), a tape, a cassette or the like.The instructions may include any suitable type of code, such as source code, compiled code, interpreted code, executable code, static code, dynamic code, encrypted code, and the like, and may be implemented using any suitable high-level, machine-oriented, object-oriented, visual, compiled and / or interpreted programming language.

[0055] Unless specifically stated otherwise, it is to be understood that terms such as "process," "compute," "determine," or the like refer to the action and / or processes of a computer, computer system, or similar electronic computing device that manipulates and / or converts data represented as physical (e.g., electronic) quantities within the registers and / or memory of the computer system into other data similarly represented as physical quantities within the memory, registers, or other such information storage, transmission, or display devices of the computer system. The embodiments are not limited in this context.

[0056] The term "coupled" is used herein to refer to any type of relationship, direct or indirect, between the components in question, and may refer to electrical, mechanical, fluid power, optical, electromagnetic, electromechanical, or other connections. Furthermore, the terms "first," "second," etc., are used herein only to simplify the discussion and carry no particular temporal or chronological significance unless otherwise indicated.

[0057] It will be apparent to those skilled in the art from the foregoing description that the broad techniques of the inventive embodiments can be implemented in a variety of forms. Therefore, while the inventive embodiments have been described in connection with specific examples thereof, the true scope of the inventive embodiments should not be so limited, since other modifications will be apparent to those skilled in the art upon review of the drawings, the specification, and the following claims.

Claims

[1] Graphics card, including: a graphics processor, GPU (18) on the graphics card; a volatile memory (48) on the graphics card, the volatile memory (48) being associated with the GPU (18); an interface on the graphics card to enable communication with a solid state drive (SSD) (34); a bridge chip (70) on the graphics card to enable communication between the GPU (18) and the interface on the graphics card via a Peripheral Components Interconnect express, PCIe bus (24) on the graphics card, wherein the PCIe bus (24) on the graphics card serves to enable GPU control of the SSD (34); and wherein the GPU (18) is used to access the SSD (34) for data when the data is not stored in the volatile memory on the graphics card, wherein the GPU (18) serves to request the data from a CPU if the data is not stored on the SSD (34). [2] The graphics card of claim 1, wherein the GPU (18), via the PCIe bus (24) on the graphics card, is to instruct the SSD (34) to perform a read operation, the read operation to provide a bus address of a portion of the volatile memory (48) on the graphics card. [3] The graphics card of claim 2, wherein the volatile memory (48) on the graphics card is for receiving an output of the read operation via the PCIe bus (24) on the graphics card. [4] The graphics card of claim 3, wherein the SSD (34) is accessible to the GPU (18) as local storage. [5] The graphics card of any of claims 1-4, wherein the GPU (18) is to request a unit of data via a host PCIe interface when the unit of data is not located on the SSD (34), and the volatile memory (48) on the graphics card is to receive the unit of data via the host PCIe interface. [6] The graphics card of claim 5, wherein the GPU (18) is for permanently storing the unit of data on the SSD (34) via the PCIe bus (24) on the graphics card, the PCIe bus on the graphics card being associated with the GPU (18). [7] The graphics card of claim 5 or 6, wherein the volatile memory (48) on the graphics card is a Graphics Double Data Rate (GDDR) memory. [8] The graphics card of claim 7, wherein the GPU (18) is configured to directly control the SSD (34) via the PCIe bus (24) on the graphics card. [9] Data processing system comprising: a host processor having one or more cores; a display controller; a display device for displaying an output of the display controller; and a graphics card according to any one of claims 1-8. [10] A non-transitory machine-readable storage medium storing instructions to cause one or more processors to perform operations to process data on a graphics card having a graphics processor, GPU (18) connected to an associated solid state drive, SSD (34) via a Peripheral Component Interconnect express, PCIe bus (24) on the graphics card associated with the GPU (18), the operations comprising: Receiving a request to the processor to perform an operation on a unit of data; instructing the SSD (34) to perform a read operation, wherein the read operation provides a bus address of a volatile memory (48) on the graphics card, the volatile memory (48) being associated with the GPU (18); Receiving the unit of data at the volatile memory (48), wherein the unit of data is received from the SSD (34) via the PCIe bus (24) on the graphics card; and Processing the unit of data via the GPU (18), wherein the operations additionally comprise permanently storing the unit of data on the SSD (34) after processing the unit of data, wherein the unit of data is stored on the graphics card via writing to the PCIe bus (24), The operations also include: Determining whether the unit of data is present in the volatile memory (48) on the graphics card before reading the unit of data from the SSD (34); and requesting the unit of data from a host processor connected to the graphics card if the unit of data is not stored on the SSD (34). [11] The non-transitory machine-readable medium of claim 10, wherein the operations additionally comprise: Receiving the unit of data at the volatile memory (48), wherein the unit of data is received from the host processor via a host PCIe interface; and permanent storage of the unit of data on the SSD (34) via the PCIe bus (24) on the graphics card after processing the unit of data via the GPU (18). [12] The non-transitory machine-readable medium of any of claims 10 and 11, wherein the operations additionally comprise configuring the GPU (18) to access the SSD (34) via the PCIe bus (24) on the graphics card and directly controlling the SSD (34) via the PCIe bus (24) on the graphics card.

Images