Abstract:
A method and apparatus are provided for shading and texturing computer graphic images in a tile based rendering system using dynamically rendered textures. Scene space geometry is derived for a dynamically rendered texture and passed to a tiling unit which derives scene space geometry for a scene which references the textures. Scene space geometry for a scene that references the dynamically rendered texture is also derived and passed to the tiling unit. The tiling unit uses object data derived from the scene space geometry to detect reference to areas of dynamically rendered textures, as yet un-rendered. These are then dynamically rendered.

Description:
FIELD OF THE INVENTION 
       [0001]    This invention relates to a three-dimensional computer graphics rendering system in particular to methods and apparatus associated with rendering of textures in a tile based rendering system. 
       BACKGROUND TO THE INVENTION 
       [0002]    Within real time computer graphics it is common to perform renders to surfaces which can then be used as textures in subsequent renders i.e. the rendered surface becomes a new texture or a “Dynamically Rendered” texture. For example in order to render a scene that includes reflections of the scene it is common to first render the scene to an environment texture map. This map is then used during the shading of objects to produce a reflection of the environment on the objects. This may be used, for example to show a reflection in a mirrored building. 
         [0003]    In addition to environment mapping it is common for modern computer graphics applications to use a technique called shadow mapping. The shadow mapping technique renders the depth of objects from the perspective of light sources within the scene into texture maps. These texture maps are used during the subsequent rendering of objects to determine if each pixel is in shadow with respect to the light sources. This is done by comparing the depth of the object pixel being rendered to a depth that is stored at the equivalent location within a “shadow map” texture, for example if the depth of the object is greater than that in the shadow map then it is behind another object with respect to the light source and therefore the illuminating effect of the light source should not be applied during the rendering of that pixel. It is very common for textures associated with shadow maps to be very large e.g. 2048×2048 or greater, with larger texture sizes generally being required for higher quality rendering. 
         [0004]    It should be noted that there are many variations on the above techniques and that the above two are included as examples and that the scope of the invention is not limited to these techniques. 
         [0005]    In modern graphics applications these renders to textures and the subsequent reads from them can use a significant percentage of the available memory bandwidth to render a scene at interactive frame rates. Furthermore it is not unusual for much of the data rendered into these textures to not be subsequently used. For example  FIG. 1  illustrates a previously rendered texture  100  subdivided into regions T 0  to T 23  and a region  110  that maps a portion of the texture  100  into the triangle  120 . As can be seen only tiles T 3 , T 8 , T 9 , T 14  to T 16 , T 21  and T 22  of the previously rendered texture need to have been rasterised in order to satisfy the mapping of the texture to the triangle  120 . 
         [0006]    Tile based rendering systems are well-known. These subdivide an image into a plurality of rectangular blocks or tiles. The way in which this is done and the subsequent texturing and the shading performed is shown schematically in  FIG. 2 . 
         [0007]    Firstly, a primitive/command fetch unit  201  retrieves command and primitive data from a memory and passes this to a geometry processing unit  202 . This transforms the primitive and command data into screen space using well-known methods. 
         [0008]    This data is then supplied to a tiling unit  203  which inserts object data from the screen space geometry into object lists for each one of a set of defined rectangular regions or tiles. An object list for each tile contains primitives that exist wholly or partially in that tile. The list exists for every tile on the screen, although some object lists may have no data in them. These object lists are fetched by a tile parameter fetch unit  205  which supplies them tile by tile to a hidden surface removal unit (HSR)  206  which removes surfaces which will not contribute to the final scene (usually because they are obscured by another surface). The HSR unit processes each primitive in the tile and passes only data for visible pixels to a shading unit  208 . 
         [0009]    The shading unit takes the data from the HSR and uses it to fetch textures using the texture unit  210  and applies shading to each pixel within a visible object using well-known techniques. The shading unit then feeds the textured and shaded data to an on chip tile buffer  212 . As the data is temporarily stored in the on chip tile buffer external memory bandwidth associated with temporary storage eliminated. 
         [0010]    Once each tile has been textured and shaded, the resultant data is written to an external scene buffer  214 . 
       SUMMARY OF THE INVENTION 
       [0011]    Preferred embodiments of the present invention provide a method and apparatus that enable a tile based rendering system to rasterise and store rendered texture surfaces only where they are to be used by subsequent renders. This is accomplished in an embodiment of the invention by performing the tiling phase as described above for all texture surfaces but deferring the rasterisation phase of those dynamically rendered texture surfaces to the point at which they are referenced. As the rendering of the scene that uses the “demand based texture renders” (e.g.  100  from  FIG. 1 ) potentially only references a small area of each texture within each tile the system can render one or more texture tiles at the point of reference into a small write back cache for immediate use within the main render. Due to the localised nature of the references it is highly likely that the rendered data will continue to reside within the cache subsystem for any tiles for which it is required, thereby substantially reducing the memory bandwidth associated with both the rendering of the textures and their subsequent use. 
     
    
     
       BRIEF DESCRIPTION OF THE DRAWINGS 
         [0012]    Preferred embodiments of the invention will now be described in detail by way of example with reference to the accompanying drawings in which: 
           [0013]      FIG. 1  illustrates schematically how a small region of a previously rendered texture may be subsequently referenced for texturing an object; 
           [0014]      FIG. 2  shows a schematic diagram of a known tile based rendering system as discussed above; 
           [0015]      FIG. 3  illustrates the operation of demand based texture rendering embodying the invention; 
           [0016]      FIG. 4  illustrates the modifications to a tile based rendering system for demand based texture rendering in an embodiment of the invention; and 
           [0017]      FIG. 5  illustrates the modifications to the texture pipeline required to implement demand based texture rendering in an embodiment of the invention. 
       
    
    
     DETAILED DESCRIPTION OF PREFERRED EMBODIMENTS 
       [0018]      FIG. 3  illustrates the operation of demand mode texture rasterisation in a tile based system. An application  300  first generates geometry  305  for an image which is to be rendered to a texture as in  100  in  FIG. 1 . This geometry is processed at  310  using well known techniques to produce screen space geometry that is passed to a tiling unit  315  which generates tile screen space parameters  320  as described for a tile based rendering system. It should be noted that the current state of each tile within the texture i.e. if it has been rendered is indicated by a valid flags table  358 . This table is generally stored within memory and contains a status flag for each tile that indicates if it has been rendered, all flags are initially cleared to indicate that no tiles have been rendered. Each time a tile is rendered a flag corresponding to that tile is set. 
         [0019]    The application then switches to the rendering of a main scene at  330  by producing main scene geometry  335  which is then processed into screen space by geometry processor  340  and tiled at  345  to produce an object list for each tile. The resulting main scene parameters  350  are then rasterised a tile at a time at  355 . During the rasterisation process the rasterisation hardware (not shown) detects areas of dynamic texture e.g. an environment map that are required but are not present in the texture store. These correspond to texturing of the type discussed with reference to  FIG. 1  above. The rasteriser determines if each texture tile (as shown in  FIG. 1 ) has been rendered by reading the tile valid flags  358 . When the rasteriser determines that a texture tile has not yet been rendered the rasteriser switches from rasterising the main scene to rasterising parameters for the texture tiles required by the texture render  320  that are associated with the required region. The subsequent rasterisation process  375  produces texture image data for T 3   380  (from  FIG. 1 ) which is written to a cache  360 . A corresponding valid flag for the texture tile is then set and the rasterisation hardware then switches back to rasterising the main scene  355  at  385 . This process is repeated for all regions of the scene which are found to be required from the dynamic texture. For example from  FIG. 1  regions T 3 , T 8 , T 9 , T 14 , T 15 , T 16 , T 21  and T 22 . It should be noted that the remaining regions of the dynamic texture are not rasterised saving significant memory bandwidth and processing overhead. 
         [0020]    It should be noted that the texture tile data written to the cache may either be written back to memory (not shown) or discarded when it is evicted from the cache  360 . In the case where the data is discarded it may be re-created again in the future as described above if the tile (e.g. T 3 ) is referenced again. This approach allows very large texture surfaces to be represented by the memory associated with the tiled geometry parameters only. Where texture data is discarded instead of being writtenback to memory the corresponding valid flags  358  are cleared to indicate that the texture is no longer present. 
         [0021]      FIG. 4  illustrates a system that implements tile based demand mode rendering of texture surfaces using dynamic textures as discussed above. It should be noted that the tiling/geometry processing units equivalent to these shown in  FIG. 2  are not shown here. Tile parameter fetch unit  410  fetches the tiled parameter lists as per a normal tile based rendering system and passes the object data to the hidden surface removal unit (HSR)  420 . This removes surfaces which will not contribute to the final scene (usually because they are obscured by another surface) using well known methods. The HSR unit processes each primitive in the tile and passes only data for surfaces visible at pixels to a shading unit  430 . 
         [0022]    The shading unit  430  takes the objects from the HSR unit  420  and applies shading and texturing to each pixel within each visible object using well-known techniques, these technique include issuing texture requests to a texture sampling unit (TSU)  460 . 
         [0023]    The TSU is illustrated in  FIG. 5 . The texture address unit  500  takes texture sample requests and calculates the X and Y address for each texture fetch using well known methods. The X and Y address is passed to the tile address calculation unit  550  which determines the address of the tile that the requested texture fetches will reside within. This calculation typically removes low order bits from the X and Y addresses to form a tile X and Y address, these values are then multiplied together and added to a base address to form the address of a “Tile valid flag” stored in the tile valid table ( FIG. 4   480 ), which is stored in memory, it should be noted that other methods of address calculation could be used. The address of the valid flag is passed to the valid flag fetch unit  560  that retrieves the specified flag from valid flag table in memory. This flag is then emitted as the “Not present” signal  570 . It should be noted that the valid flag fetch unit  560  could operate through a memory cache in order to improve its performance. The valid flag fetch unit also passes the valid flag to the address converter  520  which converts the X,Y address to a linear memory address using well known methods. If the valid flag indicates that a texture tile is not present then the address converter unit halts execution. If the valid flag indicates that a texture tile is present then the address converter unit passes the calculated texture address to the texture cache unit  530  which retrieves the texture data from either internal or external memory as necessary. The retrieved data is passed to the texture filtering unit  540  which filters the returned data using well known techniques, the resulting filtered data being passed back to the shading unit  430  in  FIG. 4 . 
         [0024]    If the flag indicates that the texture tile hasn&#39;t already been rasterised the “not present” signal  570  is sent to the context switch unit (CSU)  400  in  FIG. 4  indicating that it needs to switch to rasterising a tile of the texture that “missed” i.e. the texture was not available. This occurs for dynamically rendered textures, such as environment textures. 
         [0025]    The CSU then instructs all units within the rasteriser to switch to rasterising the requested texture i.e. the missed texture tile. It should be noted that the CSU could rasterise a single missing tile or multiple tiles within the locality of the missing texture. The CSU  400  may be implemented as a hardware module, a separate programmable processor/micro controller or using a “Host” processor and device interrupts. 
         [0026]    As the system rasterises each tile indicated by the CSU a buffer  440  outputs each completed texture tile to memory via a cache  470 . This cache will typically use the well known caching type of “write back caching” so that the data resides locally within the cache when the tiles indicated by the CSU have been rasterised. The CSU then updates the tile valid flags  480  for the tiles that it has rasterised to indicate that they are now present. The cache will now store the dynamically mapped texture required for rasterisation of tiles which were flagged as requiring that texture. 
         [0027]    On completion of the rasterisation process for the required tile(s) the CSU switches the rasterisation units back to processing the original render and allows the address converter  520  in  FIG. 5  to proceed to issue the texture address to the cache unit as described above. As the texture tiles that were rasterised now sit locally within the cache any texture fetches for them now access the cache so reducing memory bandwidth associated with those fetches, i.e. dynamically mapped textures stored in the cache. 
         [0028]    It should be noted that the cache could be replaced with a memory buffer that discards tiles rather than writing them back to memory when making space for new tile data. In these circumstances the discarded tiles that are references again will need to be rasterised again using the above process.