Patent Publication Number: US-11023993-B2

Title: Apparatus and method for verifying fragment processing related data in graphics pipeline processing

Description:
CROSS REFERENCE TO RELATED APPLICATIONS 
     The present application is related to the following co-pending U.S. patent applications: U.S. patent application Ser. No. 14/648,713, entitled “METHOD AND APPARATUS FOR ESTIMATING A FRAGMENT COUNT FOR THE DISPLAY OF AT LEAST ONE THREE-DIMENSIONAL OBJECT,” filed on Jun. 1, 2015; U.S. patent application Ser. No. 14/746,948, entitled “APPARATUS AND METHOD FOR VERIFYING THE INTEGRITY OF TRANSFORMED VERTEX DATA IN GRAPHICS PIPELINE PROCESSING,” filed on Jun. 23, 2015; U.S. patent application Ser. No. 14/747,023, entitled “APPARATUS AND METHOD FOR VERIFYING THE ORIGIN OF TEXTURE MAP IN GRAPHICS PIPELINE PROCESSING,” filed on Jun. 23, 2015; and U.S. patent application Ser. No. 14/746,980, entitled “APPARATUS AND METHOD FOR VERIFYING IMAGE DATA COMPRISING MAPPED TEXTURE IMAGE DATA,” filed on Jun. 23, 2015. 
     FIELD OF THE INVENTION 
     The present invention relates generally to the field of graphics processing and more specifically to an apparatus and method for verifying fragment texture data and/or attribute data thereof of GPU accelerated graphics processing. 
     BACKGROUND 
     A typical computing system includes a central processing unit (CPU) and a graphics processing unit (GPU). Some GPUs are capable of very high performance using a relatively large number of small, parallel execution threads on dedicated programmable hardware processing units. The specialized design of such GPUs usually allows these GPUs to perform certain tasks, such as rendering 3-D scenes, much faster than a CPU. However, the specialized design of these GPUs also limits the types of tasks that the GPU can perform. The CPU is typically a more general-purpose processing unit and therefore can perform most tasks. Consequently, the CPU usually executes the overall structure of the software application and configures the GPU to perform specific tasks in the graphics pipeline (the collection of processing steps performed to transform 3-D images into 2-D images). 
     Such graphics processing units (GPUs) are performance optimized but lack fault detection and handling required for functional safety. Functional safety is a primary issue when displaying safety relevant information to a user. Safety relevant or safety related information represents information, an erroneous content of which might be directly responsible for death, injury or occupational illness, or the erroneous content of which may be the basis for decisions relied on, which might cause death, injury, other significant harms or other significant actions. Safety relevant or safety related information may be the output of safety critical application typically operated in a safety critical environment, which is one in which a computer software activity (process, functions, etc.) whose errors, such as inadvertent or unauthorized occurrences, failure to occur when required, erroneous values, or undetected hardware failures can result in a potential hazard, or loss of predictability of system outcome. 
     The lack of fault detection and handling required for functional safety in prior art graphics processing units (GPUs) may result in an unnoticed displaying of an erroneous or incomplete image, for example due to a fault in the hardware or software, which may result in a dangerous action for a user relying on the information conveyed by the wrong image. 
     Accordingly, what is needed in the art is a fault detection and handling required for functional safety for graphics processing units (GPUs) processing graphical content including safety relevant information to be presented to a user. 
     SUMMARY 
     The present invention provides an apparatus for verifying fragment processing related data, a method of operating thereof and a non-transitory, tangible computer readable storage medium bearing computer executable instructions for verifying fragment processing related data as described in the accompanying claims. Specific embodiments of the invention are set forth in the dependent claims. These and other aspects of the invention will be apparent from and elucidated with reference to the embodiments described hereinafter. 
    
    
     
       BRIEF DESCRIPTION OF THE DRAWINGS 
       The accompanying drawings, which are incorporated herein and form a part of the specification, illustrate the present invention and, together with the description, further serve to explain the principles of the invention and to enable a person skilled in the pertinent art to make and use the invention. 
         FIG. 1  schematically illustrates a diagram of a surround view system according to an example of the present invention; 
         FIG. 2  schematically illustrates a block diagram of a computing system with a graphics processing subsystem according to an example of the present invention; 
         FIG. 3 a    schematically illustrates a further block diagram of an except section of the graphics processing pipeline executed at the graphics processing subsystem as illustratively shown in  FIG. 1  according to an example of the present invention; 
         FIG. 3 b    schematically illustrates another block diagram of an except section of the graphics processing pipeline executed at the graphics processing subsystem as illustratively shown in  FIG. 1  according to an example of the present invention; 
         FIG. 4  shows a schematic diagram illustrating the verification of the fragment processing related data by a comparator unit according to an example of the present invention; 
         FIG. 5 a    shows a schematic diagram illustrating the frame buffer with component layers according to an example of the present invention; 
         FIG. 5 b    shows a schematic diagram illustrating the frame buffer with component layers according to an example of the present invention; 
         FIG. 6  schematically illustrates a flow diagram relating to the functionality of the comparator unit of  FIGS. 3 a  and 3 b    according to an example of the present invention; and 
         FIG. 7  schematically illustrates a flow diagram relating to the generation of reference data according to an example of the present invention. 
     
    
    
     DETAILED DESCRIPTION 
     Embodiments of the present disclosure will be described below in detail with reference to drawings. Note that the same reference numerals are used to represent identical or equivalent elements in figures, and the description thereof will not be repeated. The embodiments set forth below represent the necessary information to enable those skilled in the art to practice the invention. Upon reading the following description in light of the accompanying drawing figures, those skilled in the art will understand the concepts of the invention and will recognize applications of these concepts not particularly addressed herein. It should be understood that these concepts and applications fall within the scope of the disclosure and the accompanying claims. 
     In today&#39;s car instrument panels integrate information originating from various sources in from of graphical representations on one or more displays. Typical sources generating graphical representations may be classified in safety relevant sources and non-safety relevant sources. Safety relevant sources are sources, which generate graphical representations to be displayed to a user of the car, which convey safety relevant information to the car&#39;s user. 
     Safety relevant information generated by safety relevant sources may comprises information relating to, for example, the current velocity of the car, head lamp control, engine temperature, ambient environment, condition and status of a brake system including e.g. an anti-lock braking system (ABS) or an electronic brake-force distribution system (EBD), condition and status of an electrical steering system including e.g. an electronic stability control system (ESC), a traction control system (TCS) or anti-slip regulation system (ASR), or indications and status of advanced driver assistance systems (ADAS) including e.g. an adaptive cruise control (ACC) system, a forward collision warning (FCW) system, a lane departure warning (LDW) system, a blind spot monitoring (BSM) system, a traffic sign recognition (TSR) system, just to name a few. 
     Non-safety relevant information generated by non-safety relevant sources may comprises information relating to, for example, a navigation system, a multimedia system, and comfort equipment such as automatic climate control, just to name a few. 
     The information generated by safety and non-safety relevant sources are composed and presented in form of graphical representations on the one or more displays of the car. It is immediately understood that fault detection and handling required for functional safety have to be implemented allow detecting whether at least the graphical representations conveying safety relevant information are displayed completely and unaltered to the user of the car such. In particular, graphics processing units (GPU), which allow to efficiently generate complex graphical representations on displays, represent a major challenge for implementing fault detection and handling required for functional safety. 
     In particular, safety relevant information may be comprised in graphical representations provided in form of texture image data to be mapped on one or more object surfaces defined on the basis of graphics primitives. The texture image data may be dynamically generated image data such as a video stream of image frame data or may be provided in form of static image data or precomputed image data such as from a look-up table comprising engine status related symbols, traffic signs, traffic maps etc. 
     In case safety relevant information is provided in form of texture image data, the texture mapping or texture sampling process is crucial since any software and/or hardware failures occurring in conjunction with the texture processing at the graphics processing units (GPU) may render the graphical representations of the safety relevant information unrecognizable for a user, who is addressed by the displayed safety relevant information. 
       FIG. 1  shows is a schematic block diagram of a computing system  100  with a programmable graphics processing subsystem  150  according to an example of the present application. As shown, the computing system  100  includes a system data bus  110 , a central processing unit (CPU)  120 , one or more data input/output units  130 , a system memory  140 , and a graphics processing subsystem  150 , which is coupled to a one or more display devices  180 . In further examples, the CPU  120 , at least portions of the graphics processing subsystem  150 , the system data bus  110 , or any combination thereof, may be integrated into a single processing unit. Further, the functionality of the graphics processing subsystem  150  may be included in a chipset or in some other type of special purpose processing unit or co-processor. 
     The system data bus  110  interconnects the CPU  120 , the one or more data input/output units  130 , the system memory  140 , and the graphics processing subsystem  150 . In further examples, the system memory  140  may connect directly to the CPU  120 . The CPU  120  receives user input and/or signals from one or more the data input/output units  130 , executes programming instructions stored in the system memory  140 , operates on data stored in the system memory  140 , and configures the graphics processing subsystem  150  to perform specific tasks in the graphics pipeline. For example, the CPU  120  may read a rendering method and corresponding textures a data storage, and configure the graphics processing subsystem  150  to implement this rendering method. The system memory  140  typically includes dynamic random access memory (DRAM) used to store programming instructions and data for processing by the CPU  120  and the graphics processing subsystem  150 . The graphics processing subsystem  150  receives instructions transmitted by the CPU  120  and processes the instructions in order to render and display graphics images on the one or more display devices  180 . 
     The system memory  140  includes an application program  141 , an application programming interface (API)  142 , high-level shader programs  143 , and a graphics processing unit (GPU) driver  144 . The application program  141  generates calls to the API  142  in order to produce a desired set of results, typically in form of a sequence of graphics images. The application program  141  also transmits one or more high-level shading programs  143  to the API  142  for processing within the GPU driver  144 . The high-level shading programs  143  are typically source code text of high-level programming instructions that are designed to operate on one or more shaders within the graphics processing subsystem  150 . The API  142  functionality is typically implemented within the GPU driver  144 . The GPU driver  144  is configured to translate the high-level shading programs  143  into machine code shading programs that are typically optimized for a specific type of shader (e.g., vertex, geometry, or fragment) of the graphics pipeline. 
     The graphics processing subsystem  150  includes a graphics processing unit (GPU)  170 , a GPU local memory  160 , and a GPU data bus  165 . The GPU  170  is configured to communicate with the GPU local memory  160  via the GPU data bus  165 . The GPU  170  may receive instructions transmitted by the CPU  120 , process the instructions in order to render graphics data and images, and store these images in the GPU local memory  160 . Subsequently, the GPU  170  may display certain graphics images stored in the GPU local memory  160  on the one or more display devices  180 . 
     The GPU  170  includes one or more streaming multiprocessors  175 - 1  to  175 -N. Each of the streaming multiprocessors  175  is capable of executing a relatively large number of threads concurrently. Particularly, each of the streaming multiprocessors  175  can be programmed to execute processing tasks relating to a wide variety of applications, including but not limited to linear and nonlinear data transforms, filtering of video and/or audio data, modeling operations (e.g. applying of physics to determine position, velocity, and other attributes of objects), and so on. Furthermore, each of the streaming multiprocessors  175  may be configured as one or more programmable shaders (e.g., vertex, geometry, or fragment) each executing a machine code shading program (i.e., a thread) to perform image rendering operations. The GPU  170  may be provided with any amount GPU local memory  160 , including none, and may use GPU local memory  160  and system memory  140  in any combination for memory operations. 
     The GPU local memory  160  is configured to include machine code shader programs  165 , one or more storage buffers  162  and a configurable number of frame buffers  161 - 1 ,  161 - 2 . The machine code shader programs  165  may be transmitted from the GPU driver  144  to the GPU local memory  160  via the system data bus  110 . The machine code shader programs  165  may include a machine code vertex shading program, a machine code geometry shading program, a machine code fragment shading program, or any number of variations of each. The storage buffers  162  are typically used to store shading data, generated and/or used by the shading engines in the graphics pipeline. E.g. the storage buffers  162  may comprise one or more vertex data buffers, at least one texture buffer  162 - 1 ,  162 - 2  and/or one or more feedback buffers. Each frame buffer  161 - 1 ,  161 - 2  may store displayable image data for at least one two-dimensional surface that may be used to drive the display devices  180 . Furthermore, the frame buffers  161 - 1 ,  161 - 2  may include more than one two-dimensional surface. For instance the GPU  170  may be configured to render one two-dimensional surface while a second two-dimensional surface is used to drive the display devices  180 . 
     The display devices  180  are one or more output devices capable of emitting a visual image corresponding to an input data signal. For example, a display device may be built using a cathode ray tube (CRT) monitor, a liquid crystal display, an image projector, or any other suitable image display system. The input data signals to the display devices  180  are typically generated by scanning out the contents of one or more frames of image data that is stored in the one or more frame buffers  161 - 1 ,  161 - 2 . 
     It should be noted that the memory of the graphics processing subsystem  150  is any memory used to store graphics data or program instructions to be executed by programmable graphics processor unit  170 . The graphics memory may include portions of system memory  140 , the local memory  160  directly coupled to programmable graphics processor unit  170 , storage resources coupled to the streaming multiprocessors  175  within programmable graphics processor unit  170 , and the like. Storage resources can include register files, caches, FIFOs (first in first out memories), and the like. 
       FIG. 2  shows a schematic block diagram of a programmable graphics pipeline  200  implementable within the GPU  170  of the graphics processing subsystem  150  exemplified in  FIG. 1 , according to one example of the application. 
     As shown, the shader programming model includes the application program  141 , which transmits high-level shader programs to the graphics driver  144 . The graphics driver  144  then generates machine code programs that are used within the graphics processing subsystem  150  to specify shader behavior within the different processing domains of the graphics processing subsystem  150 . 
     The high-level shader programs transmitted by the application program  141  may include at least one of a high-level vertex shader program, a high-level geometry shader program and a high-level fragment shader program. Each of the high-level shader programs is transmitted through an API  142  to a compiler/linker  210  within the graphics driver  144 . The compiler/linker  210  compiles the high-level shader programs  143  into assembly language program objects. Under shader programming model, domain-specific shader programs, such as high-level vertex shader program, high-level geometry shader program, and high-level fragment shader program, are compiled using a common instruction set target, supported by an instruction set library. With the instruction set, application developers can compile high-level shader programs in different domains using a core set of instructions. For example, compiler/linker  210  translates the high-level shader programs designated for different domains (e.g., the high-level vertex shader program, the high-level geometry shader program, and the high-level fragment shader program), which are written in high-level shading language, into distinct compiled software objects in the form of assembly code. 
     The program objects are transmitted to the microcode assembler  215 , which generates machine code programs, including a machine code vertex shader program, a machine code geometry shader program and a machine code fragment shader program. The machine code vertex shader program is transmitted to a vertex processing unit  225  for execution. Similarly, the machine code geometry shader program is transmitted to a primitive processing/geometry shader unit  235  for execution and the machine code fragment shader program is transmitted to a fragment processing unit  245  for execution. 
     The compiler/linker  210  and the microcode assembler  215  form the hardware related driver layer of the graphics driver  144 , which interfaces with the application program  141  through the application program interface, API,  142 . 
     In an example of the present application, shader programs may be also transmitted by the application program  141  via assembly instructions  146 . The assembly instructions  146  are transmitted directly to the GPU microcode assembler  215 , which then generates machine code programs, including a machine code vertex shader program, a machine code geometry shader program and a machine code fragment shader program. 
     A data assembler  220  and the vertex shader unit  225  interoperate to process a vertex stream. The data assembler  220  is a fixed-function unit that collects vertex data for high-order surfaces, primitives, and the like, and outputs the vertex data to vertex shader unit  225 . The data assembler  220  may gather data from buffers stored within system memory  140  and GPU local memory  160 , such as the vertex buffer  162 - 1 , as well as from API calls from the application program  141  used to specify vertex attributes. The vertex shader unit  225  is a programmable execution unit that is configured to execute a machine code vertex shader program, transforming vertex data as specified by the vertex shader programs. For example, vertex shader unit  225  may be programmed to transform the vertex data from an object-based coordinate representation (object space) to an alternatively based coordinate system such as world space or normalized device coordinates (NDC) space. The vertex shader unit  225  may read vertex attribute data directly from the GPU local memory  160 . The vertex shader unit  225  may read texture map data as well as uniform data that is stored in GPU local memory  160  through an interface (not shown) for use in processing the vertex data. The vertex shader  225  represents the vertex processing domain of the graphics processing subsystem  150 . 
     A primitive assembler unit  230  is fixed-function unit that receives transformed vertex data from vertex shader unit  225  and constructs graphics primitives, e.g., points, lines, triangles, or the like, for processing by the geometry shader unit  235  or the rasterizer unit  240 . The constructed graphics primitives may include a series of one or more vertices, each of which may be shared amongst multiple primitives, and state information, such as a primitive identifier, defining the primitive. In alternative examples, a second primitive assembler (not shown) may be included subsequent to the geometry shader  235  in the data flow through the graphics pipeline  200 . Each primitive may include a series of one or more vertices and primitive state information defining the primitive. A given vertex may be shared by one or more of the primitives constructed by the primitive assembly unit  230  throughout the graphics pipeline  200 . For example, a given vertex may be shared by three triangles in a triangle strip without replicating any of the data, such as a normal vector, included in the given vertex. 
     The geometry shader unit  235  receives the constructed graphics primitives from the primitive assembler unit  230  and performs fixed-function viewport operations such as clipping, projection and related transformations on the incoming transformed vertex data. In the graphics processing subsystem  150 , the geometry shader unit  235  is a programmable execution unit that is configured to execute machine code geometry shader program to process graphics primitives received from the primitive assembler unit  230  as specified by the geometry shader program. For example, the geometry shader unit  235  may be further programmed to subdivide the graphics primitives into one or more new graphics primitives and calculate parameters, such as plane equation coefficients, that are used to rasterize the new graphics primitives. The geometry shader unit  235  may read data directly from the GPU local memory  160 . Further, the geometry shader unit  235  may read texture map data that is stored in GPU local memory  160  through an interface (not shown) for use in processing the geometry data. The geometry shader unit  235  represents the geometry processing domain of the graphics processing subsystem  150 . The geometry shader unit  235  outputs the parameters and new graphics primitives to a rasterizer unit  240 . It should be noted that the geometry shader unit  235  is an optional unit of the graphics pipeline. The data processing of the geometry shader unit  235  may be omitted. 
     The rasterizer unit  240  receives parameters and graphics primitives from the primitive assembler unit  230  or the geometry shader unit  235 . The rasterizer unit  240  is a fixed-function unit that scan-converts the graphics primitives and outputs fragments and coverage data to the fragment shader unit  245 . 
     The fragment shader unit  245  is a programmable execution unit that is configured to execute machine code fragment shader programs to transform fragments received from rasterizer unit  245  as specified by the machine code fragment shader program. For example, the fragment shader unit  245  may be programmed to perform operations such as perspective correction, texture mapping, shading, blending, and the like, to produce shaded fragments that are output to a raster operations unit  250 . The fragment shader unit  245  may read data directly from the GPU local memory  160 . Further, the fragment shader unit  245  may read texture map data as well as uniform data that is stored in GPU local memory  160 , such as the texture buffer  162 - 2 , through an interface (not shown) for use in processing the fragment data. 
     The raster operations unit  250  or per-fragment operations unit optionally performs fixed-function computations such as near and far plane clipping and raster operations, such as stencil, z test and the like, and outputs pixel data as processed graphics data for storage in a buffer in the GPU local memory  160 , such as the frame buffer  161 . In particular, the raster operations unit  250  optionally performs near and far plane clipping and raster operations using the fragment data and pixel data stored in a frame buffer  161  at a pixel position associated with processed fragment data and the output data from the raster operations unit  250  is written back to the frame buffer  161  at the pixel position associated with the output data. 
     In the following examples of the present application will be described with reference to  FIGS. 3 a  and 3 b   . Referring now to  FIG. 3 a   , a further block diagram of a graphics processing pipeline of  FIG. 2  executed at the graphics processing subsystem as exemplified with reference to  FIG. 1  is schematically illustrates. 
     The graphics processing pipeline  200  may be logically partitioned into a geometry processing section  260  comprising the vertex shader unit, primitive assembler  230  and geometry shader  235  and a fragment processing section comprising the fragment shader unit  245  and the optional raster operations unit  250 , each of which performs a variety of computational functions. Some of these functions are table lookup, scalar and vector addition, multiplication, division, coordinate-system mapping, calculation of vector normals, calculation of derivatives, interpolation, filtering, and the like. Geometry processing section and fragment processing are optionally configured such that data processing operations are performed in multiple passes through graphics processing section or in multiple passes through fragment processing section. Each pass through programmable graphics processing section or fragment processing section may conclude with optional processing by a raster operations unit  250 . 
     Geometry processing section receives a stream of program instructions (vertex program instructions and geometry shader program instructions) and data and performs vector floating-point operations or other processing operations using the data. 
     In particular, a vertex refers to a data structure, which describes position of a point in 2D or 3D space and further attributes associated therewith. A set of vertices defines the location of corners of one or more surfaces constructed of basic graphical elements, which are also denoted as primitives, and other attributes of the surfaces. Each object to be displayed is typically approximated as a polyhedral. A polyhedral a solid in three dimensions with flat faces, straight edges and sharp corners or vertices. The flat faces are joined at their edges. The flat faces are modeled as primitives, the corners of which are defined by a respective set of vertices. The set of vertices define inter alia the location and orientation of the primitive in space. The attributes of a vertex may include a color value at the vertex point, a reflectance value of the surface at the vertex, one or more textures stored in one or more texture buffers and texture coordinates of the surface at the vertex, and the normal of an approximated curved surface at the location of the vertex. The vertex data is provided as an ordered list of vertices, a vertex stream, to the graphics pipeline described herein. The interpretation of the stream of vertices associates each vertex with one or more primitives out of a list of predefined primitives supported by the graphics processing pipeline, such as e.g. point primitives, line primitives, polygon primitives, triangle primitives, quad primitives and variants thereof. 
     Data processed by geometry processing section and program instructions are passed to the rasterizer unit  240 , which interfaces the geometry processing section with the fragment processing section. The rasterizer unit  240  is a sampling unit that processes primitives and generates sub-primitive data, such as fragment data, including parameters associated with fragments (texture identifiers, texture coordinates, and the like). The rasterizer unit  240  converts the primitives into sub-primitive data by performing scan conversion on the data processed by geometry processing section. The rasterizer unit  240  may be configured to generate fragments in form one pixel fragment blocks or in form of N×M fragment blocks comprising contiguous and/or continuous regions of fragments, e.g. blocks comprising eight contiguous pixel fragments, where N and M are both integers. The rasterizer unit  240  outputs fragment data to fragment shader unit  245 . The fragment data may include a coverage mask for each pixel group that indicates which pixels are covered by the fragment. In particular, the rasterizer unit  240  provides pixel fragments, pixel fragment blocks and/or associated attributes to fragment shader unit  245 . 
     The fragment shader unit  245  of the graphics pipeline  200  is configured to perform texture mapping to apply a texture map to the surface of a primitive. Texture maps are provided in at least one texture buffer  162 - 1 , which is in particular a read-only buffer. The texture maps stored in the texture buffer are two-dimensional data but can be one- or three-dimensional as well. To allows for texture mapping, the vertices of the primitive are associated with coordinates in the texture map, and each pixel of the surface defined by the primitive is then associated with specific texture coordinates in the texture map. Texturing is achieved by modifying the color of each pixel of the surface defined by the primitive with the color of the texture map at the location indicated by that pixel&#39;s texture coordinates to produce shaded fragments. The texturing of the surface of the primitive is specified by the machine code fragment shader program executed by the fragment shader unit  245 . 
     The fragment shader unit  245  may comprise any graphics processing logic and/or hardware, software, and/or firmware, capable of receiving the fragment data and eventually associated attributes from the rasterizer unit  240  and, in response, providing texture read requests to a texture sampler unit comprised by the fragment shader unit  245 , which is configured to retrieve one or more texels from the texture buffer and shades the fragments based thereon. 
     The raster operations unit  250  optionally performs near and far plane clipping and raster operations using the fragment data and pixel data stored in the frame buffer  161  at a pixel position (data array entry specified by (x, y)-coordinates) associated with processed fragment data. The output data from raster operations unit  250  is written back to the frame buffer  161  at the pixel position associated with the output data. 
     In order to allow for verifying the texture mapping or texture sampling, storage capacity available in the frame buffer  161  is used for storing data relating to the texture mapping operation used by the fragment shader unit  245  for texture mapping according to an example of the present application. The texture mapping related data comprises for instance texture coordinates and/or further data associated with the fragment data received from the rasterizer unit  240 . 
     The texture mapping related data is recorded in the frame buffer  161  by the fragment shader unit  245  configured accordingly. A comparator unit  300  is coupled to the frame buffer  161  and arranged to verify the texture mapping related data recorded therein by the fragment shader unit  245  in that the stored texture mapping related data is compared to reference data. The reference data is for instance provided to the comparator unit  300  through the driver layer of the interfacing the graphics processing subsystem  150  with the applications program  141  using the graphics processing subsystem  150  for generating images for being displayed to the user thereof. The reference data is for instance provided by the aforementioned compiler/linker  210  and microcode assembler  215  of the driver layer to the comparator unit  300 . The reference data is determined on the basis of the vertex specification, the primitive definitions and/or the shader programs provided by an application program  141 . 
     In an example of the present application, the comparator unit  300  is configured to determine a checksum based on the texture mapping related data recorded in the frame buffer  161 . The checksum may be for instance determined in accordance with a cyclic redundancy check (CRC) algorithm, a known checksum algorithm, a cryptographic hash function algorithm or a non-cryptographic hash function algorithm. The checksum may be also determined on the basis of any proprietary function. For verification, the reference data comprise one or more checksums to be compared to the checksum determined from the recorded texture mapping related data. The reference data may be provided in form of precomputed reference data, in particular, in form of one or more precomputed checksums. 
     Referring now to  FIG. 3 b   , another block diagram of a graphics processing pipeline of  FIG. 2  executed at the graphics processing subsystem as exemplified with reference to  FIG. 1  is schematically illustrates. It should be noted that only alterations with respect to the example described above with reference to  FIG. 3 a    will be set forth in the following. The above description applies likewise to the example schematically illustrated in  FIG. 3   b.    
     In order to allow for verifying the texture mapping or texture sampling, a separate data buffer e.g. a second frame buffer  161 - 2  is allocated and associated with the fragment shader unit  245  according to another example of the present application. The separate data buffer is operated as a data buffer for storing the data relating to the texture mapping operation available to the fragment shader unit  245  for texture mapping. 
     The texture mapping related data is recorded in the second frame buffer  161 - 2  by the fragment shader unit  245  configured accordingly. A comparator unit  300  is coupled to the second frame buffer  161 - 2  and arranged to verify the texture mapping related data recorded therein by the fragment shader unit  245  in that the stored texture mapping related data is compared to reference data. The reference data is for instance provided to the comparator unit  300  through the driver layer of the interfacing the graphics processing subsystem  150  with the applications program  141  using the graphics processing subsystem  150  for generating images for being displayed to the user thereof. The reference data is for instance provided by the aforementioned compiler/linker  210  and microcode assembler  215  of the driver layer to the comparator unit  300 . The reference data is determined on the basis of the vertex specification, the primitive definitions and/or the shader programs provided by an application program  141 . 
     In an example of the present application, the comparator unit  300  is configured to determine a checksum based on the texture mapping related data recorded in the second frame buffer  161 - 2 . The checksum may be for instance determined in accordance with a cyclic redundancy check (CRC) algorithm, checksum algorithm a cryptographic hash function algorithm or a non-cryptographic hash function algorithm. For verification, the reference data comprise one or more checksums to be compared to the checksum determined from the recorded texture mapping related data stored in the second frame buffer  161 - 2 . The reference data may be provided in form of precomputed reference data, in particular, in form of one or more precomputed checksums. 
     An exemplifying illustration of the recording operation as exemplified above with reference to  FIGS. 3 a  and 3 b    is further illustrated in the schematic diagram of  FIG. 4 . The frame buffer  161  is provided to store the displayable image data generated by the fragment shader unit  245  for being displayed on the one or more display devices  180  to a user. The image data generated by the fragment shader unit  245  comprises one or more texture-mapped or shaded fragments. For each fragment generated by the rasterizer unit  240  based on a rasterization of a primitive the fragment shader unit  245  receives fragment data comprising texture coordinates, colors and further associated data, on the basis of which the machine code fragment shader program executed at the fragment shader unit  245  controls the output of a color value and/or depth value to be stored in the frame buffer  161  as part of the displayable image data. The color value may be determined from one or more texels retrieved from a texture buffer  162 - 2  and supplied to a texel filter unit, which is configured to generate filtered texture samples from the texture data in the texture buffer  161 . The texel filter unit may be arranged to apply nearest-neighbor interpolation, bilinear interpolation, trilinear interpolation or anisotropic interpolation, just to name a selection of filtering algorithms usable by such a texture filtering unit to determine the color value of a shaded fragment. 
     The texture mapping related data used by the fragment shader unit  245  e.g. to determine a color value of a fragment on the basis of texture data, a color value of a shaded or texture-mapped fragment, is recorded to be available to the comparator unit  300  for verification with respect to reference data. The texture mapping related data comprises in particular texture coordinates used for each texture-mapped fragment. 
     As schematically illustrated in  FIG. 5 a   , a frame buffer is a memory buffer for storing a typically two-dimensional array of pixel data forming at least one frame of image data for being displayed to a user on a displaying device. The pixel data typically comprise one or more pixel color values. Each pixel color value comprises a predefined bit size. For instance the pixel data of a color image may comprise three color component values each having a predefined bit size of e.g. 4 bits or 8 bits. The plurality of values relating to one component is also denoted as channels. The pixel data may comprise component values such as a transparency or alpha value, a depth value and the like. 
     The exemplary frame buffer  161  schematically illustrated in  FIG. 5 a    comprise the three color channels designated as “red” channel, “green” channel and “blue” channels as well as an “alpha” channel. Hence, the frame buffer  161  stores four component value for each pixel. The alpha or transparency information is an optional information, which may not be used and hence is available for storing data therein. According to an embodiment of the present application, the alpha channel of the frame buffer  161  is used to record texture mapping related data. As aforementioned, the recorded texture mapping related data comprises for instance a texture coordinate (x, y). For verification purpose, a checksum value determined from the texture coordinate (x, y) is sufficient and reduces the required memory capacity for storing the recorded texture mapping related data. The checksum may be for instance determined in accordance with a cyclic redundancy check (CRC) algorithm, a known checksum algorithm, a cryptographic hash function algorithm, a non-cryptographic hash function algorithm or on the basis of any proprietary function. For instance, a proprietary function may any function linking two or more values to determine a function value such as the exemplar proprietary checksum function:
 
 f ( x,y )=( x+y )· x·y  
 
     In OpenGL coding, a texture color and the checksum value determined from the texture coordinate may be assigned to the frame buffer bound to the fragment shader unit  245 : 
     
       
         
           
               
               
             
               
                   
                   
               
             
            
               
                   
                 P = texture2D(sampler, textureCoordinate); 
               
               
                   
                 C = checkFunction(textureCoordinate.x, textureCoordinate.y); 
               
               
                   
                 gl_FragColor = vec4(P.x, P.y, P.z, C); 
               
               
                   
                   
               
            
           
         
       
     
     Those skilled in the art will understand that a frame buffer  161  may be allocated with one or more additional channels providing a storage capacity sufficient to record the texture mapping related data comprising in particular texture coordinates in the form as recorded without determining checksums thereof. 
     As schematically illustrated in  FIG. 5 b   , the separate data buffer for storing texture mapping related data is provided. According to an example of the present application, the separate data buffer is a second frame buffer  161 - 2  allocated and associated with the fragment shader unit  245  to be used as the separate data buffer. 
     Accordingly, the channels of the second frame buffer  161 - 2  available to record texture mapping related data as illustratively shown in  FIG. 5 b    depicting a frame buffer  161 - 2  for a two-dimensional array of RGBa pixel values forming displayable image data. The illustrated frame buffer  161 - 2  comprises the three color channels “red”, “green”, “blue” and one “alpha” channel. Each channel may be used to store values of the recorded texture mapping related data. For instance, a two-dimensional texture coordinate of each fragment may be recorded in the second frame buffer  161 - 2 . In OpenGL coding, the recording may be performed by binding two frame buffers, e.g. “gl_FragData[0]” and “gl_FragData[1]”: 
     glDrawBuffers(2, buffers); 
     and writing the texture coordinate of each fragment into the bound second frame buffer gl_FragData[1]: 
     
       
         
           
               
               
             
               
                   
                   
               
             
            
               
                   
                 gl_FragData[0] = texture2D(sampler, textureCoordinate); 
               
               
                   
                 gl_FragData[1] = vec4(textureCoordinate.x, textureCoordinate.y, 
               
               
                   
                 0.0f, 0.0f); 
               
               
                   
                   
               
            
           
         
       
     
     A more efficient storing of (two-dimensional) texture coordinates in the second frame buffer  161 - 2  may be achieved by writing two texture coordinates to each array element thereby more efficiently exploiting the storage capacity of the second frame buffer  161 - 2 : 
     
       
         
           
               
             
               
                   
               
             
            
               
                 gl_FragData[1] = vec4(textureCoordinate_1.x, textureCoordinate_1.y, 
               
               
                 textureCoordinate_2.x, textureCoordinate_2.y); 
               
               
                   
               
            
           
         
       
     
     For instance, the second frame buffer  161 - 2  is allocated to store an array with K×L pixels each having a bit width of 32 bits. Hence, at the most four coordinate components each having a size of 8 bits may be stored in an array element. 
     Those skilled in the art will understand that the aforementioned checksum value determined from a texture coordinate may be also used in conjunction with the second frame buffer  161 - 2  to record the texture mapping related data of several fragments; for instance: 
     
       
         
           
               
             
               
                   
               
             
            
               
                 C_1 = checkFunction(textureCoordinate_1.x, textureCoordinate._1.y); 
               
               
                 C_2 = checkFunction(textureCoordinate_2.x, textureCoordinate._2.y); 
               
               
                 C_3 = checkFunction(textureCoordinate_3.x, textureCoordinate._3.y); 
               
               
                 C_4 = checkFunction(textureCoordinate_4.x, textureCoordinate._4.y); 
               
               
                 gl_FragData[1] = vec4(C_1, C_2, C_3, C_4); 
               
               
                   
               
            
           
         
       
     
     It should be noted that OpenGL implements methods to recall the individual components of the pixel values in a frame buffer. 
     The recorded texture coordinates may comprise normalized texture coordinates, which are defined on the basis of a frame of reference extending within a range [0, 1] in each dimension, wherein the (non-normalized) texture coordinates are defined on a frame of reference extending to the texture image size in each respective dimension. In particular, normalized texture coordinates may be recorded to comply with the available bit width of the array elements of the second frame buffer  161 - 2 . 
     The aforementioned recording to texture mapping related data for the sake of verification may be also employed in graphics processing subsystems using tile-base rendering. Graphics processing subsystems often make use of high-seed on-chip memory with limited size as tile buffer. For graphics processing, the image data to be stored in the frame buffer is partitioned into tiles each having a size complying with such a tile buffer. The tiles are rendered one at a time. For each tile, all the primitives that affect is are rendered into the tile buffer and once the tile is complete, the image data storing in the tile buffer is copied into the frame buffer  161 - 1 , which is e.g. arranged at the main memory of the graphics processing subsystems, which is power consuming and has a limited bandwidth in relationship to an on-chip memory. 
     From the above description those skilled in the art understand that the texture mapping related data is recorded for each tile and accordingly compared to reference data for each tile. There is no need to resolve the recorded texture mapping related data. 
     Referring now to  FIG. 6 , flow diagram relating to the functionality of the comparator unit of  FIG. 3  according to an example of the present invention is schematically shown. Those skilled in the art will understand from the following description that the present application should not be understood to be limited to recording of texture mapping related data and verification thereof. In an example of the present application, data relating to the processing of one or more fragments at the fragment shader unit  245  are recorded and compared to reference data for verification thereof. 
     At a stage S 100 , a data buffer for storing fragment processing related data is optionally allocated. In one example of the present application, the data buffer may be a second frame buffer  161 - 2  in addition to the first frame buffer  161 - 1  storing the image data to be displayed to a user. In OpenGL code, two frame buffers may be allocated 
     glDrawBuffers(2, buffers); 
     The fragment processing related data comprises in particular texture mapping related data but is not limited thereto. The fragment processing related data may further comprise depth (z−) data, blending data, and the like. The texture mapping related data may further comprise texture coordinate data, normalized coordinate data and/or texel processing related data. Texel processing related data may comprise texel filtering data. 
     At a stage S 110 , fragment data is received from the rasterizer unit  240  by the fragment shader unit  245  and the fragment shader unit  245  processes the fragments on the basis of and in accordance with the received fragment data. 
     At a stage  120 , the fragment processing related data is recorded in one of the frame buffer and the optionally separate data buffer. The fragment processing related data may be part of the fragment data received from the rasterizer unit  240 . The fragment processing related data is recorded in the frame buffer or the data buffer in particular for each fragment comprised in the fragment data received from the rasterizer  240  and processed at the fragment shader unit  245 . The fragment processing related data recorded in the frame buffer or the data buffer comprises texture mapping related data, which is in particular recorded for each texture-mapped fragment produced by the fragment shader unit  245 . 
     As exemplified above, each call of a texture sampling in the fragment shader program in OpenGL code may be supplemented with an instruction to record the texture coordinate in the separated data buffer: 
     
       
         
           
               
               
             
               
                   
                   
               
             
            
               
                   
                 gl_FragData[0] = texture2D(sampler, textureCoordinate); 
               
               
                   
                 gl_FragData[1] = vec4(textureCoordinate.x, textureCoordinate.y, 
               
               
                   
                 0.0f, 0.0f); 
               
               
                   
                   
               
            
           
         
       
     
     The texture coordinates may be recorded in form of normalized coordinates in the separate data frame: 
     
       
         
           
               
               
             
               
                   
                   
               
             
            
               
                   
                 gl_FragData[0] = texture2D(sampler, textureCoordinate); 
               
               
                   
                 gl_FragData[1] = vec4(textureCoordinate.normalized_x, 
               
               
                   
                 textureCoordinate.normalized_x, 0.0f, 0.0f); 
               
               
                   
                   
               
            
           
         
       
     
     In an example of the present application, checksum values are determined one the basis of the fragment processing related data at a stage S 125  and recorded in one of the frame buffer and separate data buffer at a stage S 126 . A checksum value is recorded in the frame buffer or the data buffer in particular for each fragment comprised in the fragment data received from the rasterizer  240  and processed at the fragment shader unit  245 . A checksum value recorded in the frame buffer or the data buffer comprises a checksum value determined on the basis of texture mapping related data, which is in particular recorded for each texture-mapped fragment produced by the fragment shader unit  245   
     As exemplified above, each call of a texture sampling in the fragment shader program in OpenGL code may be supplemented with an instruction to record the texture coordinate in the alpha channel of the frame buffer: 
     
       
         
           
               
               
             
               
                   
                   
               
             
            
               
                   
                 P = texture2D(sampler, textureCoordinate); 
               
               
                   
                 C = checkFunction(textureCoordinate.x, textureCoordinate.y); 
               
               
                   
                 gl_FragColor = vec4(P.x, P.y, P.z, C); 
               
               
                   
                   
               
            
           
         
       
     
     For verification, the fragment processing related data recorded in one of the frame buffer and data buffer is compared to reference data, is for instance provided by the application program  141  or generated at the driver layer of the graphics driver  144 . 
     In an example of the present application, the data recorded in the frame buffer or the data buffer is compared to the reference data at a stage S 130 . In case of a mismatch, a fault indication signal is generated and issued at a stage S 150 . The fault indication signal indicates that the recorded fragment processing related data does not comply with the reference data. 
     In an example of the present application, a comparison checksum is generated on the basis of the fragment processing related data recorded in one of the frame buffer and the data buffer at a stage S 135  and the generated comparison checksum is compared to a reference checksum comprised by the reference data at a stage S 136 . In case of a mismatch, a fault indication signal is generated and issued at a stage S 150  indicating that the recorded fragment processing related data does not comply with the reference data. 
     As already described above, the recording of the fragment processing related data in the data buffer and comparing of the recorded fragment processing related data to reference data may be performed tile-wise. 
     Referring now to  FIG. 7 , a schematic flow diagram is shown illustrating the generation of reference data for comparing according to an example of the present invention. The reference data are determined in a reference run, which is for instance performed at a reference processing system. 
     In order to omit unnecessary repetitions, the operation stages S 100  to S 126  described above in detail with reference to  FIG. 6 . The recorded fragment processing related data or the checksums data thereof are obtained from the first frame buffer  161 - 1  or the second frame buffer  161 - 2  operated as separate data buffer in a step S 160 . A checksum of the determined from the obtained data may be determined at stage S 165 . 
     The reference data, which may comprise recorded fragment processing related data, checksums of recorded fragment processing related data, a checksum determined on the basis of recorded fragment processing related data and/or a checksum of checksums of recorded fragment processing related data as illustrated by the schematic flow diagram exemplified in  FIG. 7  may be included into the application program  141  and made available to the comparator unit  300  by the application program  141  for comparison at run time of the fragment processing related data recorded at run time during generation of image data by the graphics processing subsystem  150  in response to the application program  141  controlling the graphics processing subsystem  150 . 
     It should be noted that the comparator unit  300  may be applied to verify the integrity of fragment processing related data, which is not dynamically generated at run-time. The comparator unit  300  may be applied to verify the integrity of fragment processing related data, which is obtainable by a reference run as aforementioned. For instance, the comparator unit  300  may be applied to verify the integrity of fragment processing related data, which is persistent with respect to the run time and a reference run of the application program  141 . 
     According to a more general example of the present application, an apparatus for verifying fragment processing related data is provided. The apparatus comprises at least one data buffer  161 - 1 ,  161 - 2 ; a graphics processing pipeline  200  with a fragment shader unit  245 , and a comparator unit  300 . The at least one data buffer  161 - 1 ,  161 - 2  is provided to record fragment processing related data. The fragment shader unit  245  is coupled to the at least one data buffer  161 - 1 ,  161 - 2 . The fragment shader unit  245  is further configured to receive fragment data and configured record fragment processing related data in the at least one data buffer  161 - 1 ,  161 - 2  on processing one or more fragments in accordance with the received fragment data. The comparator unit  300  is coupled to the at least one data buffer  161 - 1 ,  161 - 2 . The comparator unit  300  is further configured to compare the recorded fragment processing related data in the at least one data buffer  161 - 1 ,  161 - 2  to reference data and to issue a fault indication signal in case the recorded fragment processing related data and the reference data mismatch, e.g. the recorded fragment processing related data and the reference data do not comply with each other. 
     According to an example of the present application, the comparator unit  300  is further configured to determine a checksum based on the recorded fragment processing related data in the at least one data buffer  161 - 1 ,  161 - 2  and compare the checksum to the reference data comprising a reference checksum. 
     According to an example of the present application, the at least one data buffer  161 - 1 ,  161 - 2  comprises a first frame buffer  161 - 1 , which is provided for storing displayable image data. 
     According to an example of the present application, the frame buffer  161 - 1  is further arranged for recording the fragment processing related data. 
     According to an example of the present application, the at least at least one data buffer  161 - 1 ,  161 - 2  further comprises a second data buffer  161 - 2 . The second data buffer  161 - 2  is provided for recording the fragment processing related data. 
     According to an example of the present application, the second data buffer  161 - 2  is a second frame buffer  161 - 2 . 
     According to an example of the present application, the fragment shader unit  245  is coupled to the first frame buffer  161 - 1  and configured to output processed fragments to the first frame buffer  161 - 1 . 
     According to an example of the present application, the processed fragments comprise texture-mapped fragments. 
     According to an example of the present application, the fragment shader unit  245  is configured to receive a stream of fragment data generated by a rasterizer unit  240  arranged upstream to the fragment shader unit  245  in the graphics processing pipeline  200 . 
     According to an example of the present application, the fragment shader unit  245  is configured to record texture coordinates in the least one data buffer  161 - 1 ,  161 - 2 . 
     According to an example of the present application, the fragment shader unit  245  is configured to record texture coordinates in the least one data buffer  161 - 1 ,  161 - 2  for each texture-mapped fragment. 
     According to an example of the present application, wherein the comparator unit  300  is further configured to compare tile-wise the recorded fragment processing related data to reference data. 
     According to an example of the present application, a method for verifying fragment processing related data is provided, which comprises providing at least one data buffer  161 - 1 ,  161 - 2  for recording fragment processing related data; receiving fragment data at a fragment shader unit  245  of a graphics processing pipeline  200 ; recording fragment processing related data in the at least one data buffer  161 - 1 ,  161 - 2  on processing a fragment in accordance with the received fragment data using the fragment shader unit  245 ; comparing the recorded fragment processing related data in the at least one data buffer  161 - 1 ,  161 - 2  to reference data; and issuing a fault indication signal in case the recorded fragment processing related data and the reference data mismatch. 
     According to an example of the present application, the least one data buffer  161 - 1 ,  161 - 2  comprises a first frame buffer  161 - 1 . The recording further comprises recording fragment processing related data in one channel of the first frame buffer  161 - 1 . 
     According to an example of the present application, the method further comprises outputting processed fragments to the first frame buffer  161 - 1 . 
     According to an example of the present application, the least one data buffer  161 - 1 ,  161 - 2  further comprises a second data buffer  161 - 2 . The recording further comprises recording fragment processing related data to the second data buffer  161 - 2 . 
     According to an example of the present application, the method further comprises determining a checksum based on the recorded fragment processing related data; and comparing the checksum with the reference data comprising a reference checksum. 
     According to an example of the present application, the method further comprises recording texture coordinates in the at least one data buffer  161 - 1 ,  161 - 2  for each texture-mapped fragment. 
     According to an example of the present application, the method further comprises tile-wise comparing the recorded fragment processing related data to reference data. 
     According to an example of the present application, a non-transitory, tangible computer readable storage medium is provided bearing computer executable instructions for verifying fragment processing related data, wherein the instructions, when executing on one or more processing devices, cause the one or more processing devices to perform a method comprising: receiving fragment data at a fragment shader unit  245  of a graphics processing pipeline  200 ; recording fragment processing related data in at least one data buffer  161 - 1 ,  161 - 2  on processing a fragment in accordance with the received fragment data using the fragment shader unit  245 ; comparing the recorded fragment processing related data in the at least one data buffer  161 - 1 ,  161 - 2  to reference data; and issuing a fault indication signal in case the recorded fragment processing related data and the reference data mismatch. The at least one data buffer  161 - 1 ,  161 - 2  is provided for recording fragment processing related data. 
     Descriptions made above with reference to  FIG. 1  through  FIG. 7  may be applied to the present embodiment as is and thus, further detailed descriptions will be omitted here. 
     The processing method and apparatus according to the above-described examples may use one or more processors, which may include a microprocessor, central processing unit (CPU), digital signal processor (DSP), or application-specific integrated circuit (ASIC), as well as portions or combinations of these and other processing devices. 
     The examples described herein refer to flowchart illustrations of the apparatus and method for graphics processing using a comparator unit. It will be understood that each block of the flowchart illustrations, and combinations of blocks in the flowchart illustrations, can be implemented by computer program instructions. These computer program instructions can be provided to one or more processors of a general purpose computer, special purpose computer, or other programmable data processing apparatus to produce a machine, such that the instructions, which execute via the one or more processors of the computer or other programmable data processing apparatus, may implement the functions specified in the flowchart block or blocks. 
     Each block of the flowchart illustrations may represent a unit, module, segment, or portion of code, which comprises one or more executable instructions for implementing the specified logical function(s). It should also be noted that in some alternative implementations, the functions noted in the blocks may occur out of the order. For example, two blocks shown in succession may in fact be executed substantially concurrently or the blocks may sometimes be executed in the reverse order, depending upon the functionality involved. 
     The terms “module”, and “unit,” as used herein, may refer to, but is not limited to, a software or hardware component, such as a Field Programmable Gate Array (FPGA) or Application Specific Integrated Circuit (ASIC), which performs certain tasks. A module or unit may be configured to reside on an addressable storage medium and configured to execute on one or more processors. Thus, a module or unit may include, by way of example, components, such as software components, object-oriented software components, class components and task components, processes, functions, attributes, procedures, subroutines, segments of program code, drivers, firmware, microcode, circuitry, data, databases, data structures, tables, arrays, and variables. The functionality provided for in the components and modules/units may be combined into fewer components and modules/units or further separated into additional components and modules. 
     Those of skill in the art would further understand that information and signals may be represented using any of a variety of different technologies and techniques. For example, data, instructions, commands, information, signals, bits, symbols, and chips that may be referenced throughout the above description may be represented by voltages, currents, electromagnetic waves, magnetic fields or particles, optical fields or particles, or any combination thereof. 
     Those of skill would further appreciate that the various illustrative logical blocks, modules, circuits, and algorithm steps described in connection with the disclosure herein may be implemented as electronic hardware, computer software, or combinations of both. To illustrate clearly this interchangeability of hardware and software, various illustrative components, blocks, modules, circuits, and steps have been described above generally in terms of their functionality. Whether such functionality is implemented as hardware or software depends upon the particular application and design constraints imposed on the overall system. Skilled artisans may implement the described functionality in varying ways for each particular application, but such implementation decisions should not be interpreted as causing a departure from the scope of the present disclosure. 
     The various illustrative logical blocks, modules, and circuits described in connection with the disclosure herein may be implemented or performed with a general-purpose processor, a digital signal processor (DSP), an application specific integrated circuit (ASIC), a field programmable gate array (FPGA) or other programmable logic device, discrete gate or transistor logic, discrete hardware components, or any combination thereof designed to perform the functions described herein. A general-purpose processor may be a microprocessor, but in the alternative, the processor may be any conventional processor, controller, microcontroller, or state machine. A processor may also be implemented as a combination of computing devices, e.g., a combination of a DSP and a microprocessor, a plurality of microprocessors, one or more microprocessors in conjunction with a DSP core, or any other such configuration. 
     The processing method according to the above-described examples may be recorded in tangible non-transitory computer-readable media including program instructions to implement various operations embodied by a computer. The media may also include, alone or in combination with the program instructions, data files, data structures, and the like. Examples of tangible, non-transitory computer-readable media include magnetic media such as hard disks, floppy disks, and magnetic tape; optical media such as CD ROM disks and DVDs; magneto-optical media such as optical discs; and hardware devices that are specially configured to store and perform program instructions, such as read-only memory (ROM), random access memory (RAM), flash memory, and the like. Examples of program instructions include both machine code, such as produced by a compiler, and files containing higher level code that may be executed by the computer using an interpreter. The described hardware devices may be configured to act as one or more software modules in order to perform the operations of the above-described embodiments, or vice versa. 
     An exemplary storage medium is coupled to the processor such that the processor can read information from, and write information to, the storage medium. In the alternative, the storage medium may be integral to the processor. The processor and the storage medium may reside in an ASIC. The ASIC may reside in a user terminal. In the alternative, the processor and the storage medium may reside as discrete components in a user terminal. 
     In one or more exemplary designs, the functions described may be implemented in hardware, software, firmware, or any combination thereof. If implemented in software, the functions may be stored on or transmitted over as one or more instructions or code on a computer-readable medium. Computer-readable media includes both computer storage media and communication media including any medium that facilitates transfer of a computer program from one place to another. A storage media may be any available media that can be accessed by a general purpose or special purpose computer. By way of example, and not limitation, such computer-readable media can comprise RAM, ROM, EEPROM, CD-ROM or other optical disk storage, magnetic disk storage or other magnetic storage devices, or any other medium that can be used to carry or store desired program code means in the form of instructions or data structures and that can be accessed by a general-purpose or special-purpose computer, or a general-purpose or special-purpose processor. Also, any connection is properly termed a computer-readable medium. For example, if the software is transmitted from a website, server, or other remote source using a coaxial cable, fiber optic cable, twisted pair, digital subscriber line (DSL), or wireless technologies such as infrared, radio, and microwave, then the coaxial cable, fiber optic cable, twisted pair, DSL, or wireless technologies such as infrared, radio, and microwave are included in the definition of medium. Disk and disc, as used herein, includes compact disc (CD), laser disc, optical disc, digital versatile disc (DVD), floppy disk and Blu-ray disc where disks usually reproduce data magnetically, while discs reproduce data optically with lasers. Combinations of the above should also be included within the scope of computer-readable media. 
     Those skilled in the art will recognize that the boundaries between the illustrated logic blocks and/or functional elements are merely illustrative and that alternative embodiments may merge blocks or elements or impose an alternate decomposition of functionality upon various blocks or elements. Thus, it is to be understood that the architectures depicted herein are merely exemplary, and that in fact many other architectures can be implemented which achieve the same functionality. 
     Any arrangement of components to achieve the same functionality is effectively associated such that the desired functionality is achieved. Hence, any two components herein combined to achieve a particular functionality can be seen as associated with each other such that the desired functionality is achieved, irrespective of architectures or intermedial components. Likewise, any two components so associated can also be viewed as being operably connected, or operably coupled, to each other to achieve the desired functionality. 
     Furthermore, those skilled in the art will recognize that boundaries between the above described operations merely illustrative. The multiple operations may be combined into a single operation, a single operation may be distributed in additional operations and operations may be executed at least partially overlapping in time. Moreover, alternative embodiments may include multiple instances of a particular operation, and the order of operations may be altered in various other embodiments. 
     Also for example, the examples, or portions thereof, may implemented as soft or code representations of physical circuitry or of logical representations convertible into physical circuitry, such as in a hardware description language of any appropriate type. 
     Also, the invention is not limited to physical devices or units implemented in non-programmable hardware but can also be applied in programmable devices or units able to perform the desired device functions by operating in accordance with suitable program code, such as mainframes, minicomputers, servers, workstations, personal computers, notepads, personal digital assistants, electronic games, automotive and other embedded systems, cell phones and various other wireless devices, commonly denoted in this application as “computer systems”. 
     However, other modifications, variations and alternatives are also possible. The specifications and drawings are, accordingly, to be regarded in an illustrative rather than in a restrictive sense. 
     In the claims, any reference signs placed between parentheses shall not be construed as limiting the claim. The word ‘comprising’ does not exclude the presence of other elements or steps then those listed in a claim. Furthermore, the terms “a” or “an”, as used herein, are defined as one or more than one. Also, the use of introductory phrases such as “at least one” and “one or more” in the claims should not be construed to imply that the introduction of another claim element by the indefinite articles “a” or “an” limits any particular claim containing such introduced claim element to inventions containing only one such element, even when the same claim includes the introductory phrases “one or more” or “at least one” and indefinite articles such as “a” or “an”. The same holds true for the use of definite articles. Unless stated otherwise, terms such as “first” and “second” are used to distinguish arbitrarily between the elements such terms describe. Thus, these terms are not necessarily intended to indicate temporal or other prioritization of such elements. The mere fact that certain measures are recited in mutually different claims does not indicate that a combination of these measures cannot be used to advantage. 
     The previous description of the disclosure is provided to enable any person skilled in the art to make or use the disclosure. Various modifications to the disclosure will be readily apparent to those skilled in the art, and the generic principles defined herein may be applied to other variations without departing from the spirit or scope of the disclosure. Thus, the disclosure is not intended to be limited to the examples and designs described herein but is to be accorded the widest scope consistent with the principles and novel features disclosed herein.