Efficient TLB entry management for the render operands residing in the tiled memory

[0002] 1. Field of the Invention

[0003] The present invention relates to microprocessor systems, and more particularly, to translation lookaside buffers for use is conjunction with high performance microprocessors.

[0004] 2. Art Background

[0005] In order to avoid frequent, cycle consuming accesses of main memory, a graphics accelerator system frequently utilizes cache memory. Cache memory is typically comprised of a relatively small amount of static random access memory (SRAM) which is both physically faster than main memory and arranged such that it can be addressed more rapidly than main memory. The graphics accelerator within the system uses the faster cache memory to capture and store information as it is used. The information is stored within the cache memory in accordance with a predetermined mapping policy. Examples of such mapping policies include, direct mapping, set associative making, and fully associative mapping. The storage of information in a cache memory allows the graphics accelerator to quickly and advantageously obtain this information from the cache memory rather than from main memory. The intelligent design and use of a cache memory can substantially enhance the performance of the overall system.

[0006] Graphic accelerator systems also typically utilize virtual addressing. Virtual addressing enables the system to effectively create a virtual memory space larger than the actual physical memory space. A graphics accelerator can then advantageously operate in virtual address space using virtual addresses. Frequently, however, these virtual addresses must be translated into physical addresses. One way of accomplishing this translation of virtual addresses into physical addresses is to regularly access translation tables stored in main memory. However, regularly accessing translation tables in main memory tends to slow overall system performance. Accordingly, in order to avoid the need to regularly access translation tables in main memory to accomplish address translation, graphics accelerator systems often use a translation lookaside buffer (TLB) to store or cache recently generated virtual to physical address translations.

[0007] A translation lookaside buffer (TLB) can be thought of as a special type of cache memory. As with other types of caches, a TLB is typically comprised of a relatively small amount of memory specially designed to be quickly accessible. A TLB typically incorporates both a tag array and a data array. Within the tag array, each tag line stores a virtual address. This tag line is then associated with a corresponding data line in the data array which stores the physical address translation for the virtual address. Thus, prior to seeking a translation of a virtual address from translation tables in main memory, a graphics accelerator can first refer to the TLB to determine whether the physical address translation of the virtual address is presently stored in the TLB. In the event that the virtual address and corresponding physical address are presently stored is the TLB, the TLB responsively outputs the corresponding physical address, and a time-consuming access of main memory is avoided.

[0008] Further details are explained below with the help of the examples illustrated in the attached drawings in which:

[0009] FIG. 1 illustrates one embodiment of a graphics display system.

[0010] FIG. 2 is a block diagram of one embodiment of a paging unit.

[0011] FIG. 3 illustrates one embodiment of a translation lookaside buffer.

[0012] FIG. 4 illustrates one embodiment of how a page entry appears when stored in the translation lookaside buffer.

[0013] FIG. 5 illustrates one embodiment of tiled memory.

[0014] A method for representing a three-dimensional surface in a single entry of a translation lookaside buffer as a square surface is disclosed.

[0015] An efficient TLB entry management is described. In the following description, for purposes of explanation, numerous specific details including line sizes and bit values are set forth in order to provide a satisfactory understanding of the present invention. However, it will be apparent to one skilled in the art that such specific details are not essential to the practice of the present invention. Additionally, it will be appreciated that while the description which follows will refer to a particular architecture and particular translation lookaside buffer (TLB), the present invention is in no way limited to a particular processor, graphics accelerator, or TLB. In a number of figures, well known electrical structures and circuits are shown in block diagram form in order not to obscure the present invention unnecessarily.

[0016] Graphics display devices can display three-dimensional polygons (i.e. primitives). Turning now to FIG. 1 of the drawings, a block diagram of a computer graphics architecture 100 for displaying polygons is shown. A central processing unit (CPU) 110, which has a computer graphics application running thereon, generates a series of primitives for display on a display monitor (not shown). Generally, these primitives are three-dimensional polygons that provide the framework of the displayed object to which a particular texture is applied. The CPU 110 keeps track of the different types of textures available to the application and issues a command to a graphics accelerator (GA) 140 to map a specific one of these textures onto a corresponding primitive. Upon receiving this command from the CPU 110, the GA 140 engages in a rendering process wherein it retrieves specific texels (i.e. texture pixels) from a stored texture in main memory 130 and subsequently maps such texels on corresponding pixels of the primitive. The GA 140 can store the data retrieved from main memory 130 in a small on-chip cache 150.

[0017] The on-chip cache 150 includes a translation lookaside buffer (TLB), which increases the overall efficiency of the GA 140 by reducing the need to retrieve data from main memory 130. For example, graphics display systems utilize paging in order to manage memory resources. Paging is a memory management technique wherein a program is divided into uniform sized blocks called pages. Paging is used in support of various computer system features such as multi-tasking. In a paging system data is moved to and from system memory by pages.

[0018] A key aspect of paging is the translation of an address provided by a program, termed a virtual address, to a physical address. The physical address is the real address of the page of data in storage. The address translation scheme as utilized by a graphics accelerator, for example, is described with reference to FIG. 2. Referring to FIG. 2, a virtual address is provided to a paging unit. Note that a virtual address 201 is provided when servicing a page fault. A page fault occurs when a page accessed by an executing program is not in memory. The virtual address is first compared to entries in a translation lookaside buffer (TLB) 202. The TLB 202 is a cache of the most commonly referenced page table entries of a currently executing task. The page table entries contain the physical address for the page in a storage medium. If the virtual address is found, a TLB hit has occurred. Thus the desired physical address is found directly in the TLB. This is desirable since it avoids subsequent processing by the paging unit and results in an increased in speed in the translation of a virtual address to physical address.

[0019] If the virtual address is not found in the TLB 202, then the virtual address must be translated. A first portion of the virtual address is utilized to index to an entry in page directory 204. The page directory 204 is a table of indices into page table 205.

[0020] A second portion of the virtual address provides an offset to the page table index retrieved from the page directory 204 to create an index to one of the page table entries. Each page table entry in page table 205 contains the starting address of the page frame as well as statistical information about the page. This starting address is the desired physical address for the page.

[0021] With reference now to FIG. 3, this figure illustrates the basic organization of a translation lookaside buffer such as TLB 202. As shown, TLB 202 includes a tag array 303 and a data array 305. Tag array 303 provides for the stage of virtual address tags, while data array 305 provides for the storage of corresponding physical addresses. In the embodiment shown, both tag array 303 and data array 305 comprise 64 lines or entries. Each tag line in tag array 303 stores 80 bits, while each data line in data array stores 30 bits. In operation, a virtual address input (hereinafter referred to as the input address) is initially coupled to the TLB input. The input address is then compared to the virtual address tags stored in tag array 303. If the input address matches one of the virtual address tags, a TLB hit occurs, and the physical address corresponding to this virtual address tag is output from the TLB.

[0022] TLB 202 can be mapped in accordance with any one of a number of possible mapping policies. These might include, for example, direct mapping, set associative mapping, as fully associative mapping. To maximize the speed of operation, TLB 202 is advantageously mapped in accordance with a fully associative mapping policy. In operation, then, an input address is simultaneously compared to the virtual address tags in each and every tag line in tag array 303. Implementing such a capability, it will be appreciated, requires the use of N comparators, where N is equal to the number of tag lines, in this embodiment, 64. It will be appreciated that implementing a fully associative TLB, as opposed to a TLB mapped in accordance with one of the other mapping policies, will tend to require greater chip space.

[0023] Referring now to FIG. 4, this figure illustrates a small page entry if stored in the translation lookaside buffer 202. In particular, FIG. 4 illustrates a sample breakdown of bits in a tag line and corresponding data line in the case of a relatively small page size, for example, 4K words. This page size corresponds to the organization of information in main memory. In a virtual memory system, when a GA wishes to access a particular location in main memory, it specifies both a virtual address for the page in main memory, which must be translated into a physical address for the page, and the address within that page which does not need to be translated.

[0024] Referring now to FIG. 4, while deferring discussion of the first 16 process m bits shown, a first set of address bits in the tag line are reserved for the address within the page, while a second set of bits are reserved for the virtual address to be translated. In the small page size of 4K words, 12 bits are sufficient to describe the address within each page. Accordingly, as shown, bits 0-11 are reserved for a designation of the address within each page. The remaining bits, bits 12-63, comprise the virtual address to be translated which will be compared to corresponding bits from the input address to determine whether a TLB hit has occurred. The data line which corresponds to this tag line, comprises a similar number of bits for the address within the page, bits 0-11, and a set of bits 12-39 which define the physical address of the page.

[0025] Thus, it will be appreciated from FIG. 4 that the page size dictates a particular breakdown of the bits in the tag and data lines of a TLB. The embodiment shown in this figure additionally appends to each tag line a number of bits reserved for process ID information (bits 0-15). This information is used to designate the process which owns the particular TLB entry such that, for example, a first process is prevented from using the TLB entries belonging to a second process. In this way, protection is provided for without the need to flush the TLB whenever processes are changed.

[0026] Turning now to FIG. 5, this figure shows how the page size affects the entry of operands into the TLB. FIG. 5 shows a rectangular, tiled memory with a pitch equal to eight tiles. Each tile, or word, is 2 kilobytes (KB) of memory. A physical page of memory is two tiles, or 4 KB. Each entry in the TLB is 4 Quadwords (QW), or 4 tiles.

[0027] The graphics accelerator (GA) 140 shown in FIG. 1 may have both two-dimensional (2D) and three-dimensional (3D) rendering engines. In one embodiment, 3D operands (color, Z) are operated upon by the GA in a square quantity called a span, which is data corresponding to 4 by 4 pixels. In another embodiment, a blit engine is a 2D rendering engine which operates on the source and destination surfaces one pixel at a time (like a scanline renderer).

[0028] Based on the depth of the pixel in bits per pixel (bpp), the data that the rendering engine operates upon can be a rectangular quantity in terms of bits. For a 16 bpp 3D operand, a span corresponds to 4 quadwords (QWs) stacked in the Y direction (assuming the scanline is in X direction). Similarly, a QW corresponds to 4 pixels in a cache line for a 2D operand. Therefore, a square pixel surface of a 3D operand can result in a rectangular memory. When such an operand is placed in the virtual memory with 16 QWs×16 lines rectangular tiles, the traversal algorithm for walking the 3D primitive may jump into the tile in the Y-direction or in the X-direction. In other words, the accesses can come in the X-direction or Y-direction with equal probability. Therefore, it is advantageous to map a square surface (in terms of pixels) in the TLB. For a 2D primitive, the accesses can more likely come in the X-direction. When a TLB resource is shared by two types of render engines, the above access patterns are exploited to manage TLB entries efficiently.

[0029] With this background, the components of entry management are: (i) identifying the render engine and the surface format; (ii) interpreting the TLB entries; and (iii) prefetching the TLB entries for page (4K which is 2 tiles in X direction) misses.

[0030] The following describes how these components operate together. The TLB for the rendering engine has entries, where each entry stores translation data for two pages. Now the page table stored in memory has each entry having translation for two tiles (4 KB) adjacent in X-direction. Because tiled rectangular memory can have a pitch of 1, 2, 4, 8, 16 or 32 tiles, in order to represent a square surface (in terms of pixels) for 3D operands, translations for two pages in Y-direction (the pages which are pitch apart) are stored in a single TLB entry. Similarly for 2D operands, translation for two pages adjacent in X-direction are stored in a single TLB entry.

[0031] It is interesting to note that pitch of 1 or 2 tiles desolves into the case where pitch apart pages are in fact in adjacent in X-direction. Hence, for a non-tiled surface for any render engine and for a tiled surface with pitch of 1 or 2 tiles, the natural entry from the page table becomes the TLB entry, otherwise, two half entries are combined to make one entry. While looking up the TLB in the first case, bit 12 of incoming address[31:0] is masked out to zero and in the second case, the pitch bit is masked out. Essentially pitch bit is bit 13, 14, 15 or 16 of the incoming address because this bit corresponds to the pitch of the tiled surface. Masking the pitch bit works because when these entries are stored there are translations for both pages corresponding to pitch bit=0 and pitch bit=1. Further, tags for TLB entries are also stored the same way by masking the pitch bit. It should be noted that in hardware masking means forcing to 0.

[0032] A third component of entry management that is prefetching the TLB entries based on above thesis. When a TLB miss occurs, for a 2D engine or non-tiled accesses for 3D or tiled accesses for 3D with pitch of 1 or 2 tiles, only one entry is fetched. In the case of other pitches, for a 3D access, two entries from page table are fetched: one with pitch bit=0 and the other with pitch bit=1 based on the bit 12 of the address it is decided which half of the entries are kept. Therefore, two pages in Y-direction have now translation available in the same TLB entry and a TLB miss is used as an opportunity to prefetch the other entry.

[0033] TLB misses are reduced by prefetching the entries which can be most likely used. Further in a UMA device, because of a good number of memory clients (e.g. isoch stream with a burst accesses, latency for initiating a read is very high for a low priority client like this TLB request. High latency can adversely affect the 3D render engine efficiency. Here two TLB requests are pipelined and therefore the latency for the second transaction is obviated. Further, this method of entry management ties up both renderers with different access patterns in a seamless manner for performance enhancement. Tiled memory improves the memory efficiency of such a graphics sub-system and this invention takes the fullest advantage of further improving efficiency.