The technology described herein relates to graphics processing systems, and in particular to tile-based graphics processing systems.
Graphics processing is normally carried out by first splitting the scene to be displayed into a number of similar basic components or “primitives”, which primitives are then subjected to the desired graphics processing operations. The graphics “primitives” are usually in the form of simple polygons, such as triangles.
Each primitive is at this stage defined by and represented as a set of vertices. Each vertex for a primitive has associated with it a set of data (such as position, colour, texture and other attributes data) representing the vertex. This data is then used, e.g., when rasterising and rendering the primitive(s) to which the vertex relates in order to generate the desired render output of the graphics processing system.
Once primitives and their vertices have been generated and defined, they can be processed by the graphics processing system, in order, e.g., to display the frame.
This process basically involves determining which sampling points of an array of sampling points covering the output area to be processed are covered by a primitive, and then determining the appearance each sampling point should have (e.g. in terms of its colour, etc.) to represent the primitive at that sampling point. These processes are commonly referred to as rasterising and rendering, respectively.
The rasterising process determines the sample positions that should be used for a primitive (i.e. the (x, y) positions of the sample points to be used to represent the primitive in the output, e.g. scene to be displayed). This is typically done using the positions of the vertices of a primitive.
The rendering process then derives the data, such as red, green and blue (RGB) colour values and an “Alpha” (transparency) value, necessary to represent the primitive at the sample points (i.e. “shades” each sample point). This can involve, as is known in the art, applying textures, blending sample point data values, etc.
(In graphics literature, the term “rasterisation” is sometimes used to mean both primitive conversion to sample positions and rendering. However, herein “rasterisation” will be used to refer to converting primitive data to sampling point addresses only.)
These processes are typically carried out by testing sets of one, or of more than one, sampling point, and then generating for each set of sampling points found to include a sample point that is inside (covered by) the primitive in question (being tested), a discrete graphical entity usually referred to as a “fragment” on which the graphics processing operations (such as rendering) are carried out. Covered sampling points are thus, in effect, processed as fragments that will be used to render the primitive at the sampling points in question. The “fragments” are the graphical entities that pass through the rendering process (the rendering pipeline). Each fragment that is generated and processed may, e.g., represent a single sampling point or a set of plural sampling points, depending upon how the graphics processing system is configured.
(A “fragment” is therefore effectively (has associated with it) a set of primitive data as interpolated to a given output space sample point or points of a primitive. It may also include per-primitive and other state data that is required to shade the primitive at the sample point (fragment position) in question. Each graphics fragment may typically be the same size and location as a “pixel” of the output (e.g. output frame) (since as the pixels are the singularities in the final display, there may be a one-to-one mapping between the “fragments” the graphics processor operates on (renders) and the pixels of a display). However, it can be the case that there is not a one-to-one correspondence between a fragment and a display pixel, for example where particular forms of post-processing, such as downsampling, are carried out on the rendered image prior to displaying the final image.)
(It is also the case that as multiple fragments, e.g. from different overlapping primitives, at a given location may affect each other (e.g. due to transparency and/or blending), the final pixel output may depend upon plural or all fragments at that pixel location.)
(Correspondingly, there may be a one-to-one correspondence between the sampling points and the pixels of a display, but more typically there may not be a one-to-one correspondence between sampling points and display pixels, as downsampling may be carried out on the rendered sample values to generate the output pixel values for displaying the final image. Similarly, where multiple sampling point values, e.g. from different overlapping primitives, at a given location affect each other (e.g. due to transparency and/or blending), the final pixel output will also depend upon plural overlapping sample values at that pixel location.)
FIG. 1 shows a typical computer graphics processing system, comprising a host processor (CPU) 1, a graphics processing unit (GPU) 3, and a memory 5 for storing data required by and/or generated by the host processor 1 and graphics processor 3.
When an application 2 that is executing on the host processor 1 requires graphics processing from the graphics processor 3, such as a frame to be displayed, the application 2 will send appropriate commands and data to a driver 4 for the graphics processor 3 that is running on the host processor 1.
The driver 4 will then send appropriate commands and data to the graphics processor 3 to cause it to generate the render output required by the application 2. The driver 4 sends commands and data to the graphics processor 3 by writing to data structures 6 in the memory 5, which data structures 6 are then read by the graphics processor 3.
The commands and data provided by the driver 4 will include commands to “draw” primitives to be rendered for the render output to be generated by the graphics processor 3, together with associated vertex data representing the vertices to be used for the primitives for the render output.
The commands sent to the graphics processor 3 cause the graphics processor 3 to read and process the vertex data to generate the render output. The graphics processor 3 will typically use the vertex data for a primitive to rasterise the primitive to one or more fragments each (potentially) applying to a region (area) of the render output. The fragments will then be rendered.
The completed render output (e.g. frame) may be written in a frame buffer 7 in the memory 5, from where it may be provided for display on a display device, such as a screen or printer.
Some graphics processing systems use so-called “tile-based” rendering. In tile-based rendering, the two-dimensional render output (i.e. the output of the rendering process, such as an output frame to be displayed) is rendered as a plurality of smaller area sub-regions, usually referred to as “tiles”. The tiles are each rendered separately (typically one-after-another). The rendered tiles are then recombined to provide the complete render output (e.g. frame for display). In such arrangements, the render output is typically divided (by area) into regularly-sized and shaped rendering tiles (they are usually e.g., squares or rectangles).
Other terms that are commonly used for “tiling” and “tile-based” rendering include “chunking” (the rendering tiles are referred to as “chunks”) and “bucket” rendering. The terms “tile” and “tiling” will be used hereinafter for convenience, but it should be understood that these terms are intended to encompass all alternative and equivalent terms and techniques.
The advantage of such tile-based rendering is that primitives that do not appear in a given tile do not have to be processed for that tile, and therefore can be ignored when the tile is processed. This can allow the overall amount of graphics processing necessary for a given render output to be reduced.
The Applicants have recognised that it may be desirable to perform a graphics processing operation for the entirety of a render output (e.g. frame) being generated. For example, when performing a stencil operation it may be desirable to first clear the stencil buffer for the entire render output (frame).
The Applicants further believe that there remains scope for improvements to performing graphics processing operations for an entire render output, particularly in the case of tile-based graphics processing systems.
Like reference numerals are used for like components where appropriate in the drawings.
USPTO Backgrounds
USPTO Backgrounds