Smart access streaming

Abstract

Systems, apparatuses, and methods for rendering textures by prefetching texture data are disclosed. Source texture data is identified based at least in part on one or more programmable instructions. Pre-fetching of the source texture data is caused based on a level of detail associated with the source texture data. Further, a list of data blocks of source texture data and a mapping between each data block and a corresponding allocated memory address space allocated to each data block on the memory device are maintained. In response to a request to load a given data block, the list is used to load the given data block from the memory device.

Description

Background Technology

[0001] Description of related technologies Texture mapping is a technique that applies detailed textures to the surface of virtual objects. Because the distance of virtual objects from the camera varies from scene to scene, the resolution of the texture applied to the object will also vary. To address these variations, texture maps in a multi-level asymptotic texture structure (i.e., a multi-level asymptotic texture) can be generated to improve the rendering speed of the graphics pipeline. A multi-level asymptotic texture is a collection of bitmap images with successively decreasing resolutions of textures. A multi-level asymptotic texture may include multiple versions of the same texture, each with a different resolution. These different versions can be referred to as a "multi-level asymptotic texture hierarchy" or simply a "hierarchy." By using low-resolution multi-level asymptotic texture hierarchy images when objects are far from the camera, fewer texture elements need to be loaded when rendering the object. These texture elements are also called "texels," where a "texel" is defined as a discrete element that serves as the smallest unit of a texture. A texture's "texel" is analogous to a "pixel" in a digital image.

[0002] A common approach to retrieving multi-level asymptotic textures on a GPU is through the use of pixel shaders. Traditionally, the GPU computes the Level of Detail (LOD) of the rendered texture and issues an interrupt to the kernel driver. In response, the application queries the GPU for the associated LOD value. Based on the LOD value, the application retrieves the texture data from storage and allocates memory of the desired type as its final destination. The retrieved data is then copied to a hierarchy buffer. The application can then access the hierarchy buffer to copy the texture data to its pre-identified final destination. These conventional methods of accessing texture data involve traversing many application and / or kernel layers, and can therefore lead to significant software overhead and latency issues.

[0003] In light of the above, there is a need for improved systems and methods for efficiently accessing texture data. Attached Figure Description

[0004] The advantages of the methods and mechanisms described herein can be better understood by referring to the following description in conjunction with the accompanying drawings, in which: Figure 1 It is a block diagram of a specific implementation of a computing system.

[0005] Figure 2 It is a block diagram of another specific implementation of the computing system.

[0006] Figure 3 It is a block diagram of a specific implementation of processor-initiated data transfer between memory devices.

[0007] Figure 4Examples of methods for rendering elements of a scene using sampler-based feedback are provided.

[0008] Figure 5 An example is given of a method for enabling processing circuitry to directly access texture data from a memory device.

[0009] Figure 6 Examples of methods for rendering elements of a scene using prefetched texture data are provided. Detailed Implementation

[0010] In the following description, numerous specific details are set forth to provide a thorough understanding of the methods and mechanisms presented herein. However, those skilled in the art will recognize that various specific implementations can be practiced without these specific details. In some cases, well-known structures, components, signals, computer program instructions, and techniques have not been shown in detail to avoid obscuring the methods described herein. It should be understood that, for simplicity and clarity, the elements shown in the accompanying drawings are not necessarily drawn to scale. For example, the dimensions of some of these elements may be enlarged relative to others.

[0011] Systems, apparatus, and methods for rendering textures by prefetching texture data are disclosed. The source texture data is identified, at least in part, based on one or more programmable instructions, such as synchronization instructions. The processor identifies desired blocks of source texture data by mapping the locations of the identified data blocks and is configured to request the data blocks without central processor intervention. Furthermore, a list of texture data blocks included in the source texture data and a mapping between each data block and its corresponding location in a memory device are maintained. In response to a request to load a given data block, the list is used and the given data block is loaded from the memory device without invoking the CPU. This avoids the system overhead and latency problems associated with traditional CPU management of intermediate resources and copies.

[0012] Now for reference Figure 1A block diagram of a specific embodiment of a computing system 100 is shown. In one embodiment, system 100 includes a central processing circuit (e.g., CPU 180) and accelerated processing circuitry (e.g., GPU 105, FPGA, etc.). System 100 also includes system memory 125. Furthermore, GPU 105 includes at least an command processor 135, a control unit 140, a dispatch unit 150, computing units 155A-N, a memory controller 120, a global data share 170, a layer 1 (L1) cache 165, and a layer 2 (L2) cache 160. In various embodiments, computing unit 155 includes an interface configured to access local and / or external memory storing data (e.g., source image texture data, etc.). In other embodiments, GPU 105 includes other components, omitting one or more of the illustrated components, having multiple instances of the components (even in... Figure 1 (Only one example is shown in the figure), and / or organized in other suitable ways. System 100 may also include other components not shown to avoid obscuring the figures.

[0013] In various embodiments, computing system 100 executes any software application from various types of software applications. As part of executing a given software application, the host CPU 180 of computing system 100 initiates work to be executed on GPU 105. In one embodiment, command processor 135 receives a core from host CPU 180, and command processor 135 uses dispatch unit 150 to issue corresponding wavefronts to computing units 155A-N. In one embodiment, the wavefront initiated on a given computing unit 155A-N includes multiple work items executed on the single instruction multiple data (SIMD) units of the given computing unit 155A-N. The wavefronts executed on computing units 155A-N include VGPRs 157A-N and corresponding Local Data Shares (LDS) 158A-N located on computing units 155A-N. It should be noted that VGPRs 157A-N represent any number of VGPRs.

[0014] In one implementation, GPU 105 executes a single-pass compute shader downsampling kernel to downsample the source image texture stored in system memory 125. The downsampling kernel executes all multilevel asymptotic texture levels in a single compute shader pass to generate the source image texture, rather than performing a separate pass for each multilevel asymptotic texture level. This helps reduce latency and power consumption associated with downsampling the texture. Furthermore, GPU 105 is configured to identify and prefetch texture data before requesting access to data via shader code execution and to store the texture data in an accessible memory device. Each time a texture is rendered, GPU 105 can directly access the texture data from the accessible memory device without causing an interrupt to CPU 180. These and other implementations are described below.

[0015] Turn now Figure 2 This describes a block diagram of another specific embodiment of computing system 200. In this embodiment, system 200 includes various components, including a host system 251, a GPU 202, and texture memory 230. In one embodiment, host system 251 may be a gaming system or a personal computer. Furthermore, an application 226 (e.g., a video game) is executed by host system 251, operating on the central processing unit (CPU) 224 of host system 251. Data generated as a result of the execution of application 226 is stored in system memory 226 of host system 251. GPU 202 includes shader 204, identification circuitry 206, prefetching circuitry 208, rendering circuitry 210, and GPU memory 212. System 200 may be incorporated into different devices, allowing GPU 202 to interact with CPU 224. Depending on the configuration, GPU 202 may be located inside or outside host system 251. In a specific implementation, shader 204 includes circuitry configured to perform one or more operations, including but not limited to executing shader code to request access to texture data during texture rendering.

[0016] In a specific implementation, textures are used during the execution of application 226 to render one or more frames or other elements of the scene. As mentioned herein, a texture is data that can be used to execute instructions (e.g., applying an image or pattern to a 3D model or background, or other computations that do not necessarily require calculation). In one example, when texture data is applied to a 3D model, it may be referred to as a “texel.” Texture data is used to add detail, color, and visual interest to a scene or object displayed on a display device and is an important part of creating realistic and immersive graphics. Other uses of texture data (e.g., application-specific purposes) are also possible and conceivable. See again Figure 2In one specific implementation, the identification circuit 206 is configured to identify the source texture data that will be needed to render a specific texture when an element of the application session of application 226 is executed.

[0017] In one implementation, source texture data is identified before shader code is executed to access specific texture data used to render a given texture. In one example, source texture data includes frame or scene information for the application session and the corresponding textures that will be needed to render those frames or scenes during execution. For example, in a video game application, source texture data includes digital images or patterns to be mapped onto the surface of a 3D model or 2D image during gameplay.

[0018] In a specific implementation, the identification circuit 206 is configured to identify source texture data based on one or more programmable instructions. In an example, the programmable instructions include synchronization instructions in the shader code of shader 204. Synchronization instructions are used to control the ordering of operations between different threads executing on GPU 202. These instructions are typically used to ensure access to shared resources such as memory and texture data in a consistent and predictable manner. Some examples of synchronization instructions in shader code include memory barriers, atomic operations, semaphore operations, etc. In one implementation, the identification of source texture data is performed based on application-controlled program code executing on GPU 202. Before rendering the scene, GPU 202 is configured to identify a dataset (e.g., vertices, object coordinates, texture references, etc.), and based on the dataset, it can be determined how far a particular object in the scene is from the observer's viewpoint. Furthermore, in a specific implementation, GPU 202 determines different texture images that best represent how the object should look on the display based on this distance between the object and the observer. Based on the dataset and texture images, the identification circuit 206 identifies the source texture data to be used when rendering the texture.

[0019] In one implementation, prefetch circuit 208 prefetches identified source texture data, such as source texture data initially stored in system memory 220. In another implementation, prefetch circuit 208 is configured to prefetch data blocks of the source texture data, for example, based on determining which texture blocks will be needed at what level of detail (LOD) associated with the source texture data. Furthermore, in one implementation, identification circuit 206 may identify the source texture data before it is used to process the texture, so that prefetch circuit 208 prefetches data blocks using level of detail (LOD) information corresponding to the execution of application 226.

[0020] In one example, when the execution of application 226 involves rendering a large 3D environment (such as a game world), textures are typically patterned and repeated to create large surfaces. To reduce texture repetition, texture tileization can be used to ensure that only a unique texture is available. In one implementation, prefetch circuit 208 prefetches data blocks containing source texture data that include tiled data. In another implementation, LOD (Level of Detail) can be used in conjunction with the tiled data to dynamically adjust the texture resolution based on the distance from the viewer. When the viewer is far away, the program can use lower-resolution textures created from smaller texture tiles, which are less noticeable due to their reduced size. As the viewer moves closer, the program can switch to higher-resolution textures created from larger texture tiles, which will provide more visual detail and sharpness. Prefetch circuit 208 can also use LOD information to prefetch tiled data.

[0021] In one implementation, data blocks are prefetched by prefetch circuitry 208 and loaded onto texture memory 230. In the example, the data blocks include texture tiles and / or multilevel asymptotic texture extents associated with source texture data. In this implementation, multilevel asymptotic textures can be used to generate textures for a specific scene to be rendered. In various implementations, data can be managed in a tiled format. For example, when using texture tiles to create textures, smaller texture tiles are tiled to create larger textures. For example, texture tiles can be loaded as separate 2D images. The processing unit can then determine how the tiles should be arranged and repeated to create the larger texture. This may involve scaling, rotating, or flipping the tiles as needed to properly fit the surface. Furthermore, multilevel asymptotic textures can also be used to create textures. In another example, a multilevel asymptotic texture is a pre-computed downsampled version of a texture that is generated to improve performance during texture filtering. When rendering a texture at a distance, individual pixels may become too small to distinguish, resulting in aliasing artifacts. Multi-level asymptotic textures help solve this problem by providing a series of smaller, pre-computed versions of the texture that can be used instead of the full texture when rendering at a certain distance.

[0022] In a specific implementation, the prefetch circuit 208 further generates a mapping between each data block and the corresponding memory address space allocated to each data block in the texture memory 230. According to a specific implementation, the prefetch circuit 208 is configured to prefetch each data block and load it into the texture memory 230, and create a mapping defining the memory location in the texture memory 230 where each data block is loaded. In one implementation, the mapping may also include the correlation between each block of the source texture data and its corresponding LOD value. The prefetch circuit 208 is also configured to create and maintain a list including a mapping of each data block in the texture memory 230, its corresponding LOD value, and its associated memory address space. In a specific implementation, the list is stored in the texture memory 230 as mapping 234. In other implementations, the list may also be stored at any other memory location accessible by the GPU 202. Furthermore, data blocks are prefetched and stored in the texture memory 230 as data blocks 232.

[0023] like Figure 2 As depicted, texture memory 230 is a form of digital storage device that ensures fast access to data block 232. In one or more embodiments, texture memory 230 may utilize dedicated RAM specifically designed for fast read and write operations, which enhances the performance of graphics hardware in rendering 3D visuals. However, dedicated RAM is not required. In embodiments, texture memory 230 may reside on GPU 202, as shown, or within the system graphics card. In other embodiments, texture memory 230 may also be part of system memory 220. Furthermore, in embodiments, texture memory 230 is non-volatile memory (NVM), such as flash memory, electrically erasable programmable read-only memory (EEPROM), ferroelectric random access memory (FRAM), magnetoresistive random access memory (MRAM), non-volatile random access memory (NVRAM), volatile memory (such as ROM), or combinations thereof.

[0024] Advantageously, prefetching data blocks and maintaining the mapping between each data block and its corresponding memory address space enables direct communication between the GPU 202 and the memory device 230 during scene rendering. This allows for a significant reduction in the amount of data-related content retrieved from the texture memory 230 without requiring extensive logical management on the application 226 side or during the runtime of the operating system (OS) of the host system 251. In one implementation, the prefetch circuitry 208 generates a list as a table of file content offsets or handles, allowing the GPU 202 to directly issue a read request when texture data is needed to process the texture. By enabling the GPU 202 to directly access memory, the system and method presented herein avoid the overhead that would otherwise be incurred by interrupts and using the CPU to access and manage data.

[0025] Depending on the implementation, when application 226 is executed and a given texture is to be rendered, shader 204 identifies the Level of Detail (LOD) required to render the texture. Rendering circuitry 210 issues a memory request to texture memory 230 to access one or more data blocks corresponding to the identified LOD, based on the identified LOD. In other implementations, the request to access one or more data blocks may be further issued in response to application-specific conditions and the identified LOD (or conditions other than the identified LOD). In one example, the memory request is a direct memory access (DMA) request. In one implementation, based on the mapping between data blocks and corresponding LOD information as defined in data map 232, rendering circuitry 210 accesses the data blocks and determines whether these data blocks are ready for consumption. When it is determined that the data blocks are ready for consumption, rendering circuitry 210 loads tiles into GPU memory 206 and uses the loaded data blocks to render a scene or frame.

[0026] The systems and methods described in this paper enable the identification and prefetching of texture data before data is needed to render textures, significantly improving sampler-based feedback use cases (such as...). Figure 5 The techniques described herein allow the GPU 202 to directly identify and initiate the loading of required data from texture memory 230, for example, based on LOD (Level of Detail), instead of utilizing the traditional path of issuing interrupts to the driver and calculating the data location in response to the interrupts. Furthermore, multiple memory requests to the driver stack and graphics driver to copy data from texture memory 230 to the hierarchical buffer and from the hierarchical buffer to GPU-accessible resources are avoided. Advantageously, the overhead of the host system 251 is reduced, and faster data processing and better utilization of the high-bandwidth memory resources of the GPU 206 are achieved. CPU 224 resources can therefore be used for better purposes, such as improving frame rendering latency overhead. This significantly improves the responsiveness of the application (e.g., when scenes require rapid switching due to user interaction), thus significantly improving immersion.

[0027] In some specific implementations, refer to Figure 2 The described circuits (such as, but not limited to, the identification circuit 206, the prefetch circuit 208, the rendering circuit 210, etc.) are implemented in hardware to achieve fast processing. Furthermore, in some embodiments, these circuits may be combined into a single circuit or multiple circuits. Such embodiments are envisioned. Moreover, software implementations of the aforementioned circuits are not excluded. For example, in some embodiments, the functionality of the identification circuit 206, the prefetch circuit 208, and the rendering circuit 210 may be integrated into software, for example, into the shader code executed by the shader 204.

[0028] Figure 3This illustrates a processor-initiated data transfer between memory devices. As shown in the figure, GPU 302 accesses memory device 306 (in a specific implementation, memory device 306 is a texture memory, such as...). Figure 2 (as described) to acquire data (e.g., texture data). In a specific implementation, GPU 302 loads the texture data ready for consumption into a local memory location accessible to GPU 302, such as GPU memory 304.

[0029] In one implementation, before the texture is rendered by GPU 302, the texture data associated with the rendering is identified by GPU 302 and prefetched and loaded into a memory device, such as memory device 306. In the example, memory device 306 is a non-volatile memory (NVM) device. In this implementation, the texture data prefetched and stored at memory device 306 is stored in an accessible cache buffer 310 using a cache buffer driver (not shown). For example, data from main system memory (e.g., ...) Figure 2 Texture data in the system memory 220 described herein is transferred from the cache buffer driver to the cache buffer 310. Furthermore, the cache buffer driver maintains data consistency between the cache and main memory and ensures that the data in the cache buffer 310 is up-to-date.

[0030] In a specific implementation, texture data prefetched at cache buffer 310 is mapped to the corresponding memory address space in memory device 306, and this mapping is also stored as a list in cache buffer 310 during prefetching. In this implementation, instead of acting as an intermediary to synchronize tasks on GPU 302 and memory device 306, the host CPU defines a memory address space, instructing GPU 302 that memory device 306 has delivered texture data to the assigned memory address space and that GPU 302 can process it when needed. In one example, the memory address space is defined as a synchronization state in a variable, and the value within the variable defines the state of the texture data. Because memory device 306 and GPU 302 communicate using a negotiation protocol (e.g., as defined by the system programmer), GPU 302 uses specific states to determine if data is ready for consumption without requiring host interrupts or other system references.

[0031] As described above, the GPU 302 performs the prefetching of texture data from system memory based at least in part on Level of Detail (LOD) information associated with the texture data. In a specific implementation, the list stored in cache buffer 310 also includes a mapping between data blocks of texture data with associated LOD values. In the example, this association is stored in cache buffer 310 in the form of a lookup table. Other specific implementations that store this association in cache buffer 310 are envisioned.

[0032] Depending on the implementation, when a scene needs to be rendered using a texture, GPU 302 retrieves data blocks from prefetched texture data from memory device 306. In one example, the data blocks are selected based at least in part on the LOD value determined for the texture to be rendered. In this implementation, the LOD value is identified by a shader program or code executing on GPU 302. Using the mapping between LOD values ​​and corresponding data blocks, GPU 302 identifies data blocks to be loaded into a local memory device, such as GPU memory 304.

[0033] In a specific implementation, to access one or more data blocks, GPU 302 sends a memory request, such as a DMA request, to memory device 306. In response to the request, the request is stored in memory command queue 308. In a specific implementation, command queue 308 stores commands such as read and write requests, and these commands are executed in the order they are received. Once it is determined that a data block is ready for consumption, it is loaded from cache buffer 310 into GPU memory 304 for GPU 302 to access. GPU 302 can use the data block to render a texture and can continue to access other data blocks independently of memory device 406 while rendering a texture.

[0034] In one implementation, GPU 402 accesses texture data from memory device 306 using a non-volatile memory access (e.g., NVMe) interface. For example, memory device 306 may include a solid-state drive (SSD), allowing GPU 302 to use an NVMe communication interface specifically designed for accessing the SSD via the host system's Peripheral Component Interconnect High-Speed ​​(PCIe) bus.

[0035] In a specific implementation, the system and method described herein allow GPU 302 to directly access command queue 308 of memory device 306 (e.g., a non-volatile memory device) to access texture data directly from memory device 306, without requiring GPU 302 to generate an interrupt signal to the CPU for the same purpose. Doing so makes texture data directly available to GPU 302 for further texture processing and rendering, thereby eliminating the significant overhead of transferring requests at each of these steps. In one implementation, GPU 302 can determine at runtime which LOD a particular texture requires and can dynamically pull the associated texture data from memory device 306. This contrasts with requiring GPU 302 to emit an interrupt signal to the core driver, which is then presented to the CPU and forwarded by the CPU to the memory stack, all of which introduces overhead.

[0036] Now go to Figure 4 The flowchart 400 illustrates elements that use sampler-based feedback to render a scene. Arrows in flowchart 400 depict how the computation process occurs in a computing system such as a game system or a personal computer.

[0037] As depicted, during texture rendering, the shader identifies the rendered Level of Detail (LOD) value (box 402). As described earlier, the LOD value is identified in response to the shader program executed by the GPU. The LOD value can be used to dynamically adjust the texture resolution of objects based on their distance from the viewer. Based on the identified LOD, the GPU sends an interrupt to the kernel driver (box 404). In the example, the GPU sends an interrupt to the driver to invoke the texture data required to render the scene with the determined LOD value.

[0038] In response to an interrupt, the driver triggers an operating system (OS) event (box 406) to the application being executed. In one example, the OS event indicates a request to retrieve texture data from a memory device (e.g., host system memory). The OS event may be triggered against the host system's CPU.

[0039] In response to an OS event, the CPU reads the LOD value and determines the appropriate texture data and the memory location where the requested texture data is stored (box 408). In a specific implementation, the CPU identifies the appropriate texture data based on the configuration settings of the scene being rendered and the application being executed. Furthermore, once the relevant texture data location is identified, the CPU sends a memory request (e.g., a DMA request) to the memory controller of the memory device (box 410) to retrieve the texture data.

[0040] In response to the memory request, the CPU loads texture data (e.g., including texture tiles and multi-level asymptotic texture extents) from the memory device into the host system buffer (box 412). Furthermore, once the texture data is ready for consumption, the CPU sends a hierarchical request (e.g., another DMA request) to the GPU (box 414). Once the GPU receives the hierarchical request, it is configured to send another DMA request to the memory device to access the texture data (box 416). In response to the GPU's DMA request to access the texture data, the CPU updates the texture data, for example, by sending another memory request to the memory device to indicate what texture data resides on the memory device (box 418).

[0041] Once the resident texture data is identified and updated, the LOD value is clamped to the resident texture data during sampling using the texture data (box 420). When clamping the LOD to the texture data, the CPU limits the LOD to a specific range based on the available texture data. Instead of dynamically adjusting the LOD based on distance or object size, the LOD value is clamped within a predetermined range. The GPU is configured to use the texture data to render the texture (box 422). This process is repeated for each individual texture to be rendered.

[0042] Now go to Figure 5 An example is illustrated in method 500 for enabling a graphics processing unit to directly access texture data from a memory device. Figure 4 Obtaining texture data using conventional methods can lead to the generation of interrupts to the driver and the calculation of the location of the texture data in response to the interrupts. Initiating multiple memory requests to the driver stack and graphics driver to copy texture data from memory to a hierarchical buffer and from the hierarchical buffer to GPU-accessible resources can result in system overhead and latency issues. In contrast, method 500 utilizes prefetching of texture data to reduce latency and overhead by enabling the processor to communicate directly with the memory device without invoking the host CPU. Furthermore, clamping based on the LOD of the resident texture data can be eliminated because the data can be predicted and prefetched at least partially based on different LOD values ​​before the shader code is executed to request access to the texture data, allowing the LOD value to be dynamically adjusted based on distance or object size.

[0043] As described above, texture data is required for rendering textures. Texture data may include multi-level asymptotic texture extents, texture tiles, or other data to render textures based on appropriate Level of Detail (LOD) values. According to a specific implementation depicted using method 500, this texture data is predicted by the GPU, allowing the GPU to prefetch the texture data before needing to access it. In one implementation, prefetching includes the CPU transferring the predicted texture data to a memory drive based on the LOD value (box 502). Furthermore, the memory device loads the prefetched texture data into an accessible cache (box 504).

[0044] In one implementation, when a texture is to be rendered, the shader executes a shader program to identify the Level of Detail (LOD) associated with the texture to be rendered (box 506). In another implementation, based on the identified LOD, the GPU identifies the texture data blocks to be accessed. According to the implementation, in order to access these texture data blocks, the GPU issues a Direct Memory Access (DMA) request via a memory driver to a memory device storing the prefetched texture data (box 508). Thus, using a DMA request, the GPU is able to access texture data blocks without invoking additional processing units (e.g., the CPU). Furthermore, the GPU renders the texture based on the accessed texture data (box 510).

[0045] The technique described in method 500 allows the GPU to directly identify and initiate the loading of such data from the memory device, for example, based on LOD, before needing to access the required texture data. Furthermore, it eliminates the need for multiple communication paths that involve issuing interrupts to the memory driver and then calculating the data location in response to those interrupts. It also avoids initiating multiple memory requests to the driver storage stack and graphics driver to copy data from the memory device to GPU-accessible resources. Advantageously, this reduces host system overhead and enables faster data processing and better utilization of the GPU's high-bandwidth memory resources.

[0046] Figure 6 A method 600 for rendering a texture using prefetched texture data is illustrated. As shown, method 600 is divided into two sub-methods. The flowchart depicted on the left side of the page illustrates the method for prefetching texture data, while the flowchart on the right side of the page illustrates the method for rendering a texture using the prefetched data. These sub-methods are labeled as follows. In a specific implementation, the prefetching of texture data is performed before the execution of shader code to request access to the texture data. During prefetching, the source texture data is identified by the GPU (box 602). In a specific implementation, one or more programmable instructions (e.g., synchronization instructions) are used to identify the source texture data. The source texture data may include texture tiles and multi-level asymptotic textures associated with rendering a given texture.

[0047] In a specific implementation, the GPU induces prefetching of the identified source texture data (box 604). In the example, the GPU prefetches the source texture data from system memory or any other memory location. Furthermore, the prefetching of the source texture data is performed at least in part based on the Level of Detail (LOD) value associated with the texture data. As described above, the LOD value can be used to dynamically adjust the texture resolution of an object based on its distance from the viewer.

[0048] Once the source texture data is fetched from a memory device, for example, into an accessible cache, the GPU generates a mapping between the (data) blocks of texture data and their locations in the cache. In a specific implementation, to enable direct communication between the GPU and the cache without CPU intervention, the GPU uses the mapping to access the required data blocks during rendering. In a specific implementation, the prefetching of the source texture data and the generation of the mapping are performed before the shader code requesting access to the source texture data is executed (i.e., method blocks 602-606).

[0049] To render a texture, the shader code executed in the GPU identifies the LOD value of the current texture to be rendered (box 608). In a specific implementation, the texture to be rendered is determined based on the scene or frame to be displayed on the display device. The GPU then sends a memory request to access a prefetched block of data to the cache (box 610). In a specific implementation, the memory request is a DMA request. In response to receiving a response to the sent memory request from the cache, the GPU is configured to select a data block from the data blocks based on the identified LOD (box 612). In one implementation, the selection of the data block is performed at least in part based on a mapping generated during prefetching.

[0050] The GPU further determines whether the selected block is ready for consumption (condition box 614). If the selected block is not ready for consumption (condition box 614, "No" branch), the GPU is configured to wait for the data block to become ready for consumption. Once the data block is ready for consumption (condition box 614, "Yes" branch), the GPU loads the data block into GPU memory (box 616). Furthermore, the loaded data block is used to render a texture (box 618).

[0051] It should be emphasized that the specific embodiments described above are merely non-limiting examples. Many variations and modifications will become apparent to those skilled in the art once the above disclosure is fully understood. The following claims are intended to be interpreted as covering all such variations and modifications.

Claims

1. A processor, the processor comprising: Prefetch circuit, the prefetch circuit being configured to: Use direct memory access to induce prefetching of texture data from the memory device to the cache; as well as Generate a mapping that identifies the location of the block containing the texture data in the cache; and Rendering circuit, the rendering circuit being configured as follows: Receive a request to load a given data block; as well as The given data block is retrieved from the cache based at least in part on the mapping.

2. The processor of claim 1, wherein the mapping further includes the association of the blocks of the texture data with corresponding level of detail values.

3. The processor of claim 1, wherein the request includes a level of detail associated with the given data block.

4. The processor of claim 1, wherein the processor further comprises a shader configured to execute a shader program to identify the level of detail associated with the given data block.

5. The processor of claim 1, wherein the rendering circuitry is further configured to: In response to an indication that the given data block is ready for consumption, the given data block is loaded from the cache into a memory location accessible to the processor, at least in part based on the direct memory access; and Use the given data block to render the texture.

6. The processor of claim 1, wherein the prefetch circuitry is configured to prefetch the texture data before the rendering circuitry receives a request to access the texture data.

7. The processor of claim 1, wherein the mapping is generated before the rendering circuit receives a request to access the texture data.

8. The processor of claim 1, wherein the texture data includes one or more of a texture tile associated with a texture corresponding to a scene and a multi-level asymptotic texture range.

9. A method, the method comprising: The processor's prefetch circuitry uses direct memory access to cause the prefetching of texture data from the memory device to the cache; as well as Generate a mapping that identifies the location of the block containing the texture data in the cache; as well as The rendering circuitry receives a request to load a given data block. as well as The given data block is retrieved from the cache based at least in part on the mapping.

10. The method of claim 9, wherein the mapping further includes the association of the blocks of the texture data with corresponding level of detail values.

11. The method of claim 9, wherein the request includes at least a level of detail associated with the given data block.

12. The method according to claim 9, further comprising: Execute the shader program to identify the level of detail associated with the given data block.

13. The method according to claim 9, further comprising: In response to an indication that the given data block is ready for consumption, the rendering circuitry loads the given data block from the cache into a memory location accessible by the processor, at least in part based on the direct memory access. as well as The rendering circuit uses the given data block to render the texture.

14. The method according to claim 9, further comprising: The texture data is prefetched by the prefetch circuit before the rendering circuit receives a request to access the texture data.

15. The method of claim 9, wherein the mapping is generated before the rendering circuit receives a request to access the texture data.

16. The method of claim 9, wherein the texture data comprises one or more of a texture tile associated with a texture corresponding to a scene and a multi-level asymptotic texture extent.

17. A system comprising: Central processing circuit; and The acceleration processing circuit is configured to: This causes texture data to be prefetched from the central processing circuit to the cache; A mapping is generated of the location of the blocks that identify texture data in the cache, wherein the mapping enables direct memory access between the accelerated processing circuitry and the cache; Receive a request to load a given block of the texture data; as well as The given block is accessed from the memory device based at least in part on the mapping.

18. The system of claim 17, wherein the acceleration processing circuit is further configured to: In response to an indication that the given block is ready for consumption, the given block is loaded from the cache into a memory location accessible by the accelerated processing circuitry, at least in part based on the access; and Use the given block to render the texture.

19. The system of claim 17, wherein the acceleration processing circuit is configured to prefetch the texture data before receiving a request to access the texture data by the acceleration processing circuit.

20. The system of claim 17, wherein the mapping is generated before the accelerated processing circuit receives a request to access the texture data.

Images