Patent Application
20240282281
This disclosure generally relates to a hardware architecture of a processor unit for rendering 2D content.
Text is a crucial component of 3-D environments and virtual worlds for user interfaces and wayfinding. Implementing text using standard antialiased texture mapping leads to blurry and illegible writing which hinders usability and navigation. While supersampling removes some of these artifacts, distracting artifacts can still impede legibility, especially for recent high-resolution head-mounted displays. There is a need for an analytic antialiasing technique that efficiently computes the coverage of text glyphs, over pixel footprints, designed to run at real-time rates and an ability to decomposes glyphs into piecewise-biquadratics and trapezoids that can be quickly area-integrated over a pixel footprint to provide crisp legible antialiased text, even when mapped onto an arbitrary surface in a 3-D virtual environment.
This invention is directed to an architecture of a 2D graphics engine (e.g., graphics processing unit, GPU) that is configured to render high-quality graphics while operating on an ultra-low power budget. Particular embodiments disclosed herein provide an improved technique for anti-aliasing. Anti-aliasing could be done in a variety of ways. Traditionally, anti-aliasing is achieved using Multi-Sample Anti-Aliasing (MSAA), which samples multiple points within a pixel area to determine what color the pixel should display. A more accurate anti-aliasing could be achieved with more sampling points, but sampling is computationally expensive. Instead of sampling, this invention converts 2D content definitions into primitive shapes (e.g., 2D horizontally-aligned trapezoids and quadratic curves) and leverages the known geometric properties of the primitives to perform analytic anti-aliasing (e.g., instead of sampling a pixel at multiple points, embodiments disclosed herein use geometry to compute how pixels/tiles are covered by the primitives). For example, the technique involves calculating the amount of pixel that is covered by a primitive (e.g., 11% of the pixel is covered by a trapezoid), then rendering the pixel shading based on thereof. This technique allows the rendering of high-quality images at low power.
In particular embodiments, a graphics engine performs anti-aliasing tile-by-tile. A scene may be broken down into individual tiles, each tile comprising a fixed number of pixels such as 32×32 pixels. For each tile, a “shape walker” component of the graphics engine determines evaluates the pixels within the tile and determines whether the pixels are completely inside, completely outside, or partially inside and partially outside a primitive that is covered in the tile. Pixels that are completely inside or completely outside the primitive do not need anti-aliasing, whereas pixels that intersect or overlap with an edge of the primitive (e.g., outer frame of the primitive) would need to be sent to the “integrator,” where more fine-grained pixel-level analytic anti-aliasing is needed. Particular embodiments disclosed herein provide a novel technique for achieving such tasks.
In particular embodiments, 2D scene that is to be rendered is divided into tiles, each tile having a pre-determined number of pixels (e.g., 16×16). Text and 2D content within the scene is defined as paths or contours, which is then converted into shapes of axis-aligned trapezoid or piecewise-biquadratic (simply quadratics) curves. These shapes are referenced as primitives. Then, for each tile, XRU-2D identifies the smallest bounding box within a tile that encompasses a portion of a primitive covered by the tile. Each row of pixels within the bounding box is then traversed row-by-row to determine pixels that overlap with the outer shape of the primitive. Once the overlapping pixels are identified, pixels that do not need to be anti-aliased are identified. The overlapping pixels are then sent to the integrator, while other pixels (pixels falling outside the primitive or fully inside the primitive) are assigned 0 and 1 weight values, respectively, and sent to a different process (not to an integrator). Subsequent steps involve, the integrator figuring out the coverage weight of the overlapping pixels against the primitive, which may be used to determine the pixel shading for anti-aliasing.
In particular embodiments, the technique of identifying the overlapping pixels discussed above involves one of two variations depending on whether the primitive is an axis-aligned trapezoid or a piecewise-biquadratic (simply quadratics) curve. If the primitive is a trapezoid, the method involves identifying the maximum and minimum Y values of the trapezoid (e.g., top and bottom size of the trapezoid) and Y-intercepts and slope of an edge (or both edges if two sides of the trapezoid fits into one tile). Then, the method continues by traversing row-by-row to identify, based on the slopes and Y-intercepts identified in the previous step, pixels that are overlapping with the shape of the trapezoid. Then, the overlapping pixels are sent to the integrator, and pixels that fall outside of the trapezoid are assigned weight 0 and pixels that fall inside the trapezoid are assigned weight 1. If the primitive is a curve, the same high-level steps of identifying overlapping pixels and applying weights to non-overlapping pixels are used, but in contrast to if the primitive is a trapezoid, quadratic formula is used to represent the curve rather than using Y-intercepts and slope.
In particular embodiments, a technique is disclosed for optimization of a graphics engine architecture by selectively rendering and updating portions of a display that needs to be updated. Conventional graphics pipeline utilizes a frame buffer where a rendered frame is stored until the graphics engine determines that the frame should be sent out to the display driver integrated circuit (DDIC). Embodiment disclosed herein removes the use of a frame buffer (e.g., in the DDR memory) along with the decision logic that takes place in the graphics engine that determines when the rendered frames should be sent out to the DDIC. Instead, the frame buffer is replaced with a small on-chip buffer (e.g., 2 tiles worth, not a full frame buffer). This way, the graphics pipeline can be shortened, which allows a reduction in power consumption. Without the frame buffer acting as an intermediary between the graphics engine and the DDIC, the rendered frames are sent directly by the graphics engine to the display buffer of the DDIC. This scheme, however, present a problem because the DDIC reads the rendered frames from the display buffer at a particular speed without regard to some decision logic. In other words, the DDIC lacks the capability of checking whether the frames in the display buffer have been already read/processed, meaning, if the graphics engine updates the display buffer too quickly, some of the rendered frame may be overwritten prematurely (e.g., before being read), resulting in tearing artifacts. To address this problem, embodiments herein presents a novel way of throttling the updating of the display frames, where the throttling decision logic is executed by the graphics engine that has the capability of directly updating the display buffer.
In one aspect, the graphics engine will not run and render content until it knows that the new content has been readout by the display buffer (i.e., the buffer in the display). The graphics engine uses the display's V/H sync signals to determine when a tile in the display buffer has been consumed. Horizontal Synchronization, or Hsync is a signal that is used to synchronize the start of the horizontal line scan of a frame with the graphics engine that rendered the frame. Vertical Synchronization, or Vsync, is similar to Hsync but is used to synchronize the start of the horizontal line scan of the next frame with the graphics engine that rendered the frame. The graphics engine herein uses such V/H sync signals to delay the rendering process until the display has had an opportunity to read the rendered frames, effectively throttling the rendering process to mitigate the premature overwriting of the rendered data. For example, if tile in the display buffer has not been read out (as determined by the V/H sync signals), the graphics engine will not flush its small buffer into the display buffer, and the graphics engine's compute logic will not run and render new content if its small on-chip buffer hasn't been flushed. If tile in the display buffer has been read, then the graphics engine will flush its small buffer and the graphics engine will render the next content since the small buffer is available.
In particular embodiments, the graphics engine determines which tiles to selectively render based on differential changes of content across the frames. The graphics engine maintains tile information of each of the tiles in a frame, which can be used to track primitives. And thus, for example, if the graphics engine determines that a new primitive was introduced in a frame, the graphics engine can select tiles that are covering the new primitive and render only those tiles and not the rest of the tiles in a frame.
The embodiments disclosed herein are only examples, and the scope of this disclosure is not limited to them. Particular embodiments may include all, some, or none of the components, elements, features, functions, operations, or steps of the embodiments disclosed above. Embodiments according to the invention are in particular disclosed in the attached claims directed to a method, a storage medium, a system and a computer program product, wherein any feature mentioned in one claim category, e.g. method, can be claimed in another claim category, e.g. system, as well. The dependencies or references back in the attached claims are chosen for formal reasons only. However, any subject matter resulting from a deliberate reference back to any previous claims (in particular multiple dependencies) can be claimed as well, so that any combination of claims and the features thereof are disclosed and can be claimed regardless of the dependencies chosen in the attached claims. The subject-matter which can be claimed comprises not only the combinations of features as set out in the attached claims but also any other combination of features in the claims, wherein each feature mentioned in the claims can be combined with any other feature or combination of other features in the claims. Furthermore, any of the embodiments and features described or depicted herein can be claimed in a separate claim and/or in any combination with any embodiment or feature described or depicted herein or with any of the features of the attached claims.
In particular embodiments, a driver 102 may be configured to decompose a scene received from an application 101 into individual shapes that can be more efficiently processed by a 2D graphics engine 103, such shapes are referred herein as “primitives.” A scene may consist of a number of 2D content and texts. 2D content and texts contained in a scene may be defined by “paths,” where each path is made up of lines, curves, arcs, or otherwise referred herein as “contours.” In an embodiment, an application 101 defines the paths within a scene. For example without limitation, a typical scene may contain between 2,000-20,000 paths. In an embodiment, each contour may be required to be “closed,” such that the first and last vertices of the contour are identical (e.g., at the same location). In an embodiment, a driver 102 may be configured to process each path in a scene by converting the contours of the path into one of two types of primitives: (1) horizontally aligned trapezoids and (2) piecewise-biquadratic curves. A horizontally aligned trapezoid, referred hereinafter as a “trapezoid” for brevity, comprises two parallel horizontal edges on the top and bottom sides of the trapezoid and two side edges connecting the top and bottom sides. A piecewise-biquadratic curve—referred hereinafter as a “quadratic curve” for brevity—is a 2-D region bounded by a quadratic curve and a line. An example process of converting the contours of a path into primitives is disclosed in the following paper: A. Ellis, W. Hunt, J. Hart, Nerf: Real-Time Analytic Antialiased Text for 3-D Environments, Computer Graphics forum, vol. 38, issue 8, November 2019, pp. 23-32.
In particular embodiments, a driver 102 may be configured to perform tiling operations by which a scene is segmented into a smaller data structure called a tile, or tile block. Each tile may be composed of a set of pixels. For example, a tile may be comprised of a 16-by-16 pixel block or a 32-by-32 pixel block. In an embodiment, a driver 102 may be configured to determine, for each tile in a scene, every primitive that is covered the tile, then store this information in a memory database 109 that is accessible by a graphics engine 103.
While recognizing the differences of terms “pixels” and “texels” as used in the field of art, any references to pixels herein may be interchangeable with references to texels and any references to texels herein may be interchangeable with references to pixels, for the purposes of describing the embodiments herein.
In particular embodiments, once the command controller 107 provides instructions to a tile controller 120 tiles to render, the tile controller 120 may be configured to gather all the primitive, blit, and/or filter information necessary to render the tiles. For every tile to be rendered, a tile controller 120 may begin the rendering process by fetching the tile data from a tile memory database 109, for example, through the input box 106 shown in
In particular embodiments, a shape walker 130 may be configured to determine the coverage weight of each pixel within a tile, the coverage weight representing how much of the pixel is covered by a primitive within the tile. In other words, a shape walker 130 may be configured to examine each of the pixels in the tile (or within the tile bounding box) to determine whether the pixels falls inside, outside, or partially intersects with an edge of a primitive (e.g., trapezoid or a quadratic curve). Pixels that are determined to be fully inside a primitive are given a coverage weight of 1, pixels determined to be that are fully outside a primitive is given a coverage weight of 0, and pixels that are intersecting with an edge of a primitive are sent to an integrator 140 for further processing (e.g., an integration step). Partially interacting, or overlapping, pixels require an integration step to precisely determine how much of the pixel overlaps with an edge of a primitive. This information is used for anti-aliasing at a later step in the rendering pipeline. For pixels that are assigned coverage weights of 0 or 1 by a shape walker 130, their respective coverage weights are provided to coverage buffers 151 or 152.
Traditional methods for anti-aliasing typically use sampling or Multi-Sample Anti-Aliasing (MSAA), which involves sampling points within a pixel area to determine the coverage weight for that pixel. For example, as illustrated in
In particular embodiments, a scene may be broken down into smaller units of pixels referred to as tiles. For example,
In an embodiment, a shape walker 130 may be configured to utilize an algorithm known as DDA (digital differential analyzer) line generating algorithm to determine whether a pixel intersects with an edge of a primitive. The technique of identifying intersecting pixels may involve first determining a function equation that represents an edge of a primitive (or otherwise referred as an “edge definition”), then utilizing an algorithm to determine whether a pixel overlaps/intersects with the edge represented by the function equation. For example, if a primitive is a trapezoid, a shape walker 130 may first determine the maximum and minimum Y values of the trapezoid (e.g., top and bottom edge of the trapezoid) and y-intercepts and slope of an edge (or both edges if two side edges of the trapezoid fits into one tile). The y-intercepts and slope may be used to determine a function equation (e.g., linear equation) that represents a corresponding edge. Then, the technique may continue by traversing row-by-row of the tile to identify, based on the function equation identified in the previous step, pixels that are intersecting with the edge of the trapezoid (e.g., the function equation). The intersecting pixels are sent to the integrator to determine the pixel coverage weight, and pixels that fall completely outside of the trapezoid are assigned coverage weight of 0 and pixels that fall completely inside the trapezoid are assigned coverage weight of 1. On the other hand, if the primitive is a quadratic curve, the same high-level technique of identifying the overlapping pixels and applying weights to non-overlapping pixels are used, but in contrast to if the primitive is a trapezoid, a quadratic formula is used to represent the curve rather than a linear equation.
In particular embodiments, a shape walker 130 may be configured to analyze each pixel position within a tile to determine whether the corresponding pixel overlaps/intersects with an edge of a primitive (e.g., trapezoid or curve). A shape walker 130 may be configured to process, for each primitive within a tile, a single edge at a time. For example, in the example shown in
Once the y-min, y-max, and function equation is determined for a particular edge contained in a tile, a shape walker 130 may be configured to traverse the tile row-by-row (e.g., from y-min to y-max) and determine, for each row, pixels that intersect with an edge of a trapezoid based on the function equation. For example, referring to
If the primitive is a quadratic curve, rather than a trapezoid, in accordance to particular embodiments, a shape walker 130 may be configured to analyze each pixel position within a tile to determine whether the corresponding pixel overlaps/intersects with an edge of a quadratic curve. As shown in
In particular embodiments, to determine the function equation for a curved edge of a quadratic curve, a shape walker 130 may be configured to determine the y-min and y-max values and y-intercepts of the curved edge. A shape walker 130 may then use this information and the three vertices of a quadratic curve (e.g., such as those shown in
In particular embodiments, once the x-min and x-max values that are defining the pixels intersecting with an edge of a primitive have been determined for each row within a tile, a shape walker 130 may be configured to assign each pixel within the tile a coverage weight or flagged for the integrator 140. Pixels that are overlapping with an edge of a primitive are flagged and provided to an integrator 140. Pixels that are fully outside a primitive are assigned a coverage weight of 0. Pixels that are fully inside a primitive are assigned a coverage weight of 0. A shape walker 130 may be configured to assign every pixel outside the bounding box a coverage weight of 0. To evaluate pixels that are inside the bounding box, a shape walker 130 may walk through each pixel row-by-row. For example, referring to
In particular embodiments, a shape walker 130 may be configured to examine, prior to determining coverage weights of pixels that are fully outside or inside a primitive and prior to flagging pixels that are intersecting with an edge of a primitive, whether the tile bounding box is bigger than a minimal threshold size. If the bounding box is smaller than a minimal threshold size (such as 1×1 pixel or 2×2 pixels), a shape walker 130 may be configured to send all of the pixels within the bounding box to an integrator 140 to determine their respective coverage weight, rather than going through the steps described in the preceding paragraphs. In an embodiment, determining whether the bounding box is bigger than a threshold size may be implemented for a trapezoid but not for a quadratic curve.
An integrator 140 may be configured to determine anti-alias pixel coverage weights for each pixel flagged by a shape walker 130. Pixels that are assigned a coverage weight by an integrator 140 are forwarded to a coverage buffer 151 or 152. An integrator 140 may only be responsible for determining coverage weights for pixels that are flagged by a shape walker 130, for example, pixels that intersect an edge of a primitive. As discussed above, coverage weights for pixels that are fully outside or fully inside a primitive are assigned by a shape walker 130. The technique of determining the anti-alias pixel coverage weights for each pixel flagged by a shape walker 130 (e.g., partially covered by a primitive) involves utilizing the well-understood property of a trapezoid or a quadratic curve function. An example of such a technique is disclosed in the following paper, which is incorporated herein: A. Ellis, W. Hunt, J. Hart, Nerf: Real-Time Analytic Antialiased Text for 3-D Environments, Computer Graphics forum, vol. 38, issue 8, November 2019, pp. 23-32.
In particular embodiments, coverage buffers 151 and 153 may be configured to store and maintain coverage weights for pixels, as determined by either a shape walker 130 or an integrator 140. In particular embodiments, two coverage buffers may be configured in a double buffer configuration such that one coverage buffer is assigned to the rasterization process while the other is assigned to the shading process, then alternating the roles as necessary. For example, referring to
In particular embodiments, each coverage buffer may be configured to store a coverage weight for each pixel within a tile. A coverage weight of zero represents full transparency, and a value of 1 (or in some embodiments 2{circumflex over ( )}10-1 (i.e., 1023)) represents a fully opaque. Intermediate values between full transparency and fully opaque represent partially transparent pixels that can be combined with a background image to yield a composite image. As discussed previously, in accordance to embodiments, instructions to update the coverage buffer for pixels that are fully transparent or fully opaque are received from a shape walker 130 and instructions to update the coverage buffer for pixels that are partially transparent are received from an integrator 140.
In particular embodiments, a shader 150 may be configured to perform fixed function shading of the pixels of a primitive. In particular embodiments, a shader 150 may be configured to perform any of the following types of shading operations: solid fill, gradient fill, and texturing. Texturing involves invoking a texture unit 170. In particular embodiments, a shader 150 performs shading operations tile by tile, and for each tile, pixel by pixel based on the coverage weight associated with each pixel. A shader 150 may be configured to determine the source color information and the determined information may be passed on to a color buffer 191 or 193 for blending operations. In an embodiment, a shader 150 generates the texture space coordinates by transforming the conversion matrix from the shader information into texel space coordinates. A shader 150 may then be configured to adjust for the shear and then clamps the output to send it to the texture block.
In particular embodiments, color buffers 191 and 193 may be configured to perform blending operations. In particular embodiments, two color buffers may be configured in a double buffer configuration to allow one color buffer to be updated while the other is being accessed. Color buffers 191 and 193 may receive the source color information and pixel coverage weights from a shader 150 or a blit and filtering unit 180. Based on a gamma correction mode, color buffers 191 and 193 may be configured to convert the input source color into gamma space before performing a blending operation. Once converted, the output may be converted back to linear space using the degamma unit. Such gamma conversion steps are optional. After color buffers 191 or 193 finishes the blending operations, the blended color data may be streamed out to the tile compress and store 195. The blended color data may be streamed out in a block by block fashion (e.g., 4×4 pixel arrays).
As discussed above, in an embodiment, a command controller 107 may determine, for each tile containing at least a portion of a primitive, a tile bounding box that encompasses the at least the portion of the primitive. This technique may be referred as a “culling” technique where tiles of a frame (e.g., 16×16 pixels) are culled using a smallest bounding box that encompasses a primitive being processed by the graphics processing unit (GPU), or a graphics system. Only the tiles covered by the primitive bounding box may be identified to the downstream GPU components in the rendering pipeline to allow the downstream GPU components to effectively ignore the empty tiles (i.e., tiles that are completely outside any primitive bounding box). This reduces the overall computing required and makes the system more efficient. Incorporating this culling technique, however, presents a challenge because the technique conflicts with some of the blending modes that are used to blend overlapping primitives. Examples of such blending modes may include blending modes that are referred to as src, sreln, srcOut, dstAtop, and dstln (hereinafter referred to as “special blending modes”). These special blending modes require access to both the tiles covering the destination primitive (tiles already in the color buffer) and the tiles covering the source primitive (tiles that are to be written into the color buffer). For example, the special blending modes may require access to the tiles covering the source primitive to update the color information of the pixels in those tiles while also requiring access to the tiles covering the destination primitive to clear/update/remove the color information of the pixels in the tiles covering the destination primitive. However, due to the culling technique, when a graphics system is processing a source primitive, the graphics system only has access to tiles covering the source primitive and do not have access to the tiles of the destination primitive. Embodiments disclosed herein provide a technique for addressing this challenge. Blending modes that do not require updating the pixels in the tiles covering the destination primitive are referred herein as “normal blending modes.” Operations that involve special blending modes may herein be referred to as “special blending operations.” Operations that involve normal blending modes may herein be referred to as “normal blending operations.”
References to a destination primitive herein may refer to a “shape” that is stored in a color buffer, which may be a primitive or a blend of multiple primitives that have been blended into the color buffer. References to a source primitive herein may similarly refer to a “shape” that is to be stored/blended into a color buffer, which may be a primitive.
In particular embodiment, a graphic system may be configured to implement the blending operations sequentially, primitive by primitive. This means that, when the system is processing a particular primitive, only the tiles covered by the primitive are processed by the system while other tiles are ignored. If, for example, a particular frame comprises multiple primitives, each of the primitive may be processed one at a time, in a sequence, which may require processing the same tiles multiple times if multiple primitives are covered by the tiles.
In particular embodiments, the task of clearing a destination primitive may first involve categorizing the tiles in a frame as “non-empty tiles” when the tiles cover a source primitive and as “empty tiles” when the tiles do not cover the source primitive. For example, in
In particular embodiments, when executing a special blending mode, a graphics system may clear a destination primitive from empty tiles by instructing the color buffer to bypass the primitive cull associated with a source primitive (e.g., bounding box of the source primitive) to allow the color buffer to gain access to previously inaccessible tiles (e.g., tiles that are beyond the source primitive's bounding box). The color buffer may then be configured to clear the empty tiles by updating the pixel values associated each pixel within the empty tiles (e.g., tiles that are beyond the source primitive's bounding box and associated with a destination primitive/shape). Alternatively, a graphics system may be configured to instruct the color buffer to process a dummy primitive (e.g., a primitive associated with clear color values) that overlaps the destination primitive, effectively “clearing” the color information of the destination primitive by replacing it with clear color information.
For non-empty tiles, the clearing task is a bit more complicated since only the destination primitive must be cleared from the non-empty tiles are covering both the destination primitive and the source primitive. For example, in
For clearing a destination primitive from non-empty tiles, in accordance to particular embodiments, a graphics system may maintain status bits for each of the pixels in the non-empty tiles that track the recent blending mode(s) that has been used for that pixel or whether the most recent blending mode used for that pixel is a normal blending mode or a special blending mode. The graphics system may use the status bits to identify pixels that have been touched by the most recent normal blending operation, i.e., pixels covering a destination primitive. In particular embodiments, a graphics system assigns a primitive a blending mode (normal blending mode or special blending mode) before the primitive is blended into a color buffer. For example, referring to
In particular embodiments, a graphics system may be configured to utilize status bit W0 to indicate whether a pixel has been touched by a normal blending mode and status bit W1 to indicate whether a pixel has been touched by a special blending mode. For example, status bits “00” (equivalent to side-by-side status bits W1 and W0) is used to indicate that a pixel has not been touched by any blending operations, and thus pixel values associated with the pixel should correspond to the background color of a frame. Status bits “01” is used to indicate that a pixel has been touched by a normal blending mode. Status bits “10” is used to indicate that a pixel has been touched by a special blending mode. Status bits “11” is used to indicate that a pixel has been touched by both normal and special blending modes. For example, in
In particular embodiments, at the end of each special blending operation, a graphics system may be configured to implement a “flag treatment step” by which status bits are reset such that status bits 00 remains as 00, status bits 01 are changed to 00, and status bits 10 and 11 are changed to 01. When the graphics system finishes blending a frame, the graphics system may be configured to export the color information of the pixels based on the current status bits: for pixels with status bits 00, the graphics system may export the background color information rather than retrieving the color information from the color memory; for pixels with status bits 01, the graphics system may export the color information from the color memory. Once the flag treatment step is executed at the end of a special blending operation, the graphics system may be able to identify pixels that have been touched by that special blending operations by searching for pixels that are associated with status bits 01. Other pixels in the frame should be associated with status bits 00 due to the resetting process discussed above with reference to the flag treatment step. And, as discussed above, when exporting the color information for pixels associated with status bits 00, the graphics system may not retrieve the color information from the color buffer, rather the system may simply retrieve/use the background color information. The use of the background color information when exporting the pixel color information is effectively equivalent to clearing the pixel values associated the pixels with status bits 00 since pixels without any value correspond to the background color. In other words, the flag treatment step effectively clears out the destination primitive since the pixels that has been touched only by a normal blending mode (status bits 00 and 01 before the flag treatment step) are changed to 00 and background color information is exported for those pixels. In some embodiments, the flag treatment step is executed not at the end of special blending operation but prior to the beginning of a subsequent blending mode that follows a special blending operation. In an embodiment, a graphics system also maintains additional status data indicating the previous blending mode that has touched a pixel, if any, to determine the transition between the blending operations.
References to pixel values or pixel color information as used herein may refer to any of the red, green, or blue color channels, and/or opaqueness channel.
In particular embodiments, a texture unit 170 may be configured to provide texture information for pixel covered by a primitive and shades the color of the pixel. If the covered pixel has texture fill, then corresponding texture image may be fetched and filtered to obtain the color information for the covered pixel. The covered pixel may then be shaded with the derived color.
In particular embodiments, a tile compress store 195 may be configured to receive the rendered tile data from color buffers 191 and 193. A tile compress store 195 may comprise a block encoder (e.g., hardware encoder) that is configured to encode the rendered tile data before being transmitted to a display driver 198. In particular embodiments, a tile compress store 195 may be responsible for encoding static assets (e.g., a blit such as an emoji, a company logo, or a watch face for a smart watch), which may be stored a memory external to the graphic engine 103 to be accessed at a later time point. Static images need to be encoded at low power but with high throughput. To achieve such a feat, when encoding an image (asset), a tile compress store 195 may use a “spatial prediction” technique that leverages the fact that some groups of pixels in an image comprises the same pixel values as other groups. Additional details for this technique are described below.
In an embodiment, a spatial predictor 901 may be configured to compare the texel values of the current block to previously processed blocks, if any, to determine whether the texel values of the current block matches the texel values of any of the previously processed blocks. For example, a spatial predictor 901 may compare the texel values of the current block with the texel values of up to four of the previously processed blocks. If a matching block is found, the spatial predictor 901 may forgo encoding the texel block of the current block and instead assign a block header to the current block that matches a block header of the matching block. Such a technique allows a block encoder 760 to skip the encoding process for the current block since the duplication of the block header allows the matching block's compressed block data to be utilized for both the current block and the matching block. However, there is a power-efficiency concern with the above described technique because texel-by-texel comparison of blocks requires a significant amount of compute power and memory storage. As a solution, embodiments disclose a technique of generating a hash code, or hash representation, to represent the texel values of each block and using the hash codes to make the comparison rather than comparing the actual texel values of the blocks. In an embodiment, a block encoder 760 may be configured to generate hash representations that are 32-bits or 64-bits. Notably, a 32-bit or 64-bit block hash comparison is significantly cheaper, computationally, than comparing the 4×4 block data.
There exists yet another problem with the technique discussed above with reference to comparing the hash codes. As shown in
Referring back to
In particular embodiments, a block analyzer 905 may be configured to analyze texel blocks and categorize them into one of two block variants: Flatblock or Codeblock. A block may be categorized as a Flatblock if all texels in the block have the same value. A block may be categorized as a Codeblock if some of the texels in the block have different values. Once a block is categorized as a Flatblock or a Codeblock, a block analyzer 905 may be configured to pass the block to a texel scheduler 910.
In particular embodiments, a texel scheduler 910 may be configured to schedule the texels in a block (e.g., Codeblock) in a sequence optimized for delta encoding. For example, the texels in a block may be scheduled in a Morton Order shown in
In particular embodiments, a delta coder 920 may be configured to encode a texel block using various techniques. For a Flatblock, a delta coder 920 may be configured encode the block using a single texel value since a Flatblock contains only a single texel value. For a Codeblock having multiple texel channels (e.g., R, G, B, opacity), a delta coder 920 may be configured to encode each texel channel separately from each other, and different encoding techniques may be used to encode each channel. The different encoding techniques used by a delta coder 92 may include a “flat” technique, “variable-length” technique, and an uncompressed technique which essentially involves “encoding” (e.g., storing) texel values as uncompressed. These encoding techniques may also be referred to as compression modes, for example, “variable length” mode, “flat” mode, or uncompressed mode. A particular channel of a Codeblock may be encoded using a “flat” technique if all of the values of the texels in the channel are the same. The flat technique involves using a single value to represent the entire channel. A particular channel of a Codeblock may be encoded using a “variable-length” technique if values of the texels within the channel differ from each other. The variable-length technique is a novel compression technique that produces different sizes of encoded data depending on the differences in the texel values within the block. As for the uncompressed technique, while it may involve storing the corresponding pixel values as uncompressed (e.g., without any compression), for the purposes of describing the embodiments herein, the uncompressed technique/mode may still be referred to as one of the “compression” techniques/modes used to “encode” texel values of a texel block, and its operations may be described as the process of “compressing” the texel values.
In particular embodiments, the variable-length technique may involve generating three groups of data to represent the encoded texel values: “symbolmask”; “rbits”; “rsymbols.” Data group rsymbols is used to represent the non-zero delta values of the texel values as arranged by a texel scheduler 910 (e.g., in a Morton Order). For example, if there are 16 texel values in a sequence, there would be 15 delta values, each delta value representing the difference of one texel value to the next in that sequence, or the difference of one texel value to the previous texel value in that sequence if considering how the sequence of texel values may be read by a block encoder 760. Data group rsymbols is used to represent only the non-zero delta of those 15 delta values. Data group symbolmask is used to provide a 1 to 1 mapping of the delta values that indicates whether each delta value is a zero value or non-zero value. Data group rbits is used to indicate the maximum number of bits required to represent each of the delta values, along with an additional bit to indicate whether the delta values are positive or negative values. In other words, rbits may be used to indicate the width of a symbol (e.g., a symbol being a delta value), and rbits may be referred to as a “symbol width.”
As discussed above, each texel channel within a Codeblock may be independently encoded using any of the techniques described above (e.g., flat technique, variable-length technique, or uncompressed). For example, for a Codeblock having three channels of texel values, a first channel of the three may be encoded using a flat technique, a second channel of the three may be encoded using the variable-length technique, and a third channel of the three may be stored as uncompressed.
In particular embodiments, after encoding a channel using the variable-length technique, a channel entropy coder 930 illustrated in
In particular embodiments, a channel data collator 940 may be configured to collate each of the encoded, or uncompressed, channels of texel values into a bit stream that results in the encoded block data. In particular embodiments, a channel data collator 940 may generate a block header for each texel block. A block header may comprise a pointer (e.g., an offset value) that indicates the location of the block data in the memory that is relative to block data associated other blocks of an image. A block header may comprise data that indicates whether the encoded texel block is compressed or uncompressed, the number of texel channels in the block, and if the block is compressed, the size or length of the compressed block data (e.g., measured in bits or bytes). In particular embodiment, as shown in
The encoding pipeline illustrated in
In particular embodiments, a blit and filtering unit 180 may be configured to retrieve static graphics content from a memory database 109 and, if necessary, perform decoding operations and/or transformation or filtering operations on the graphics content referred to as a “blit” operation. A blit operation refers to a hardware feature that moves a rectangular block of bits from main memory into display memory. In particular embodiments, a graphics system disclosed herein may store static graphic content, such as pre-rendered images (e.g., emoji), in a memory 109 that is external to the graphics engine. A blit and filtering unit 180 may be configured to retrieve content from the memory and perform transformation or filtering operations, then provide the transformed/filtered content to a color buffer. In particular embodiments, a blit and filtering unit 180 may be configured to update the input data based on the command it receives from a tile controller 120. A blit and filtering unit 180 may include a memory structure, for example, a single color buffer. Incoming source image information per tile may be buffered in this memory structure to improve the performance of the blit and filtering unit 180. A blit and filtering unit 180 may perform a set of predefined operations and filters. A blit and filtering unit 180 provides a power-performance-area (PPA) optimized solution to some common data rearrangement/movement (with filter) operations to the hardware. In particular embodiments, a blit and filtering unit 180 may comprises a decoder configured to decode static graphics content that has been encoded and stored in a memory database 109. A blit and filtering unit 180 may be configured to provide the decoded graphics content to a color buffer 191, 193.
In the embodiment illustrated in
As a way of definition, a single frame comprises multiple tiles, each tile being comprised of pixels.
In particular embodiments, the graphics engine 1512 may be configured to render tiles only when it knows that the new content has been readout by the display buffer (i.e., the buffer 1543 in the DDIC). To achieve this feat, the graphics engine 1512 uses the display's V/H sync signals to determine when a tile in the display buffer has been consumed. Horizontal Synchronization, or Hsync is a signal that is used to synchronize the start of the horizontal line scan of a frame, where the horizontal line scan corresponds to a single row of pixels in the frame. Vertical Synchronization, or Vsync, is similar to Hsync but is used to synchronize the start of the horizontal line scan of the next frame. In other words, H-sync signals get sent at the start of every line, whereas the V-sync signal gets sent at the end of a frame. H-sync signals can therefore be used to output pixels row-by-row of previously rendered tiles that are stored in the intermediate buffer or used to wait until it has passed a tile boundary, and then output the entire row of tiles. The V-sync signal can be used to trigger the rendering and/or sending of all subsequent tiles in the frame.
In an embodiment, the graphics engine 1514 receives the V/H sync signals from the DDIC 1532 and uses the signals to determine that certain rendered data has been read out by the display and delays the rendering process until such determination has been made, effectively throttling the rendering process and mitigating risk of the premature overwriting of the rendered data. For example, when the graphics engine 1514 first initiates rendering a series of tiles, the graphics engine 1514 may render the first row of pixels of the first tile, then wait to render the next row of pixels until it receives a Hsync signal from the DDIC 1532, in which case the graphics engine 1514 is able to determine that the first row of the tile has been read by the display. In some embodiments, multiple rows of a tile may be rendered at once, in which case, the graphics engine 1514 may be configured to receive multiple, respective Hsync signals before rendering the next set of rows. Continuing the example, when the graphics engine 1514 receives a Vsync signal, it is able to determine that the current frame has been fully read and the display is about to read the next frame. In this circumstance, the graphics engine 1514 may be configured to render all remaining tiles in the current frame given that the graphics engine 1514 is able to determine that the current frame has been fully read by the display. In one embodiment, the graphics engine 1514 may determine the number of subsequent tiles to render based on variety of factors, including but not limited to the speed at which the display reads the rendered content stored in the display buffer and/or the size of the frame or tiles.
In particular embodiments, the graphics engine determines which tiles to selectively render based on differential changes of content across the frames. The graphics engine maintains tile information of each of the tiles in a frame, which is then used to track the primitives shown in the frame. And thus, for example, if the graphics engine determines that a new primitive was introduced in a frame, the graphics engine can identify particular tiles that are covering the new primitive and render only those tiles and not the rest of the tiles in a frame.
The embodiments shown in
This disclosure contemplates any suitable network 2510. As an example and not by way of limitation, one or more portions of network 2510 may include a short-range wireless network (e.g., Bluetooth, Zigbee, etc.), an ad hoc network, an intranet, an extranet, a virtual private network (VPN), a local area network (LAN), a wireless LAN (WLAN), a wide area network (WAN), a wireless WAN (WWAN), a metropolitan area network (MAN), a portion of the Internet, a portion of the Public Switched Telephone Network (PSTN), a cellular telephone network, or a combination of two or more of these. Network 2510 may include one or more networks 2510.
Links 2550 may connect client system 2530, social-networking system 2560, and third-party system 2570 to communication network 2510 or to each other. This disclosure contemplates any suitable links 2550. In particular embodiments, one or more links 2550 include one or more wireline (such as for example Digital Subscriber Line (DSL) or Data Over Cable Service Interface Specification (DOCSIS)), wireless (such as for example Wi-Fi, Worldwide Interoperability for Microwave Access (WiMAX), Bluetooth), or optical (such as for example Synchronous Optical Network (SONET) or Synchronous Digital Hierarchy (SDH)) links. In particular embodiments, one or more links 2550 each include an ad hoc network, an intranet, an extranet, a VPN, a LAN, a WLAN, a WAN, a WWAN, a MAN, a portion of the Internet, a portion of the PSTN, a cellular technology-based network, a satellite communications technology-based network, another link 2550, or a combination of two or more such links 2550. Links 2550 need not necessarily be the same throughout network environment 2500. One or more first links 2550 may differ in one or more respects from one or more second links 2550.
In particular embodiments, client system 2530 may be an electronic device including hardware, software, or embedded logic components or a combination of two or more such components and capable of carrying out the appropriate functionalities implemented or supported by client system 2530. As an example and not by way of limitation, a client system 2530 may include a computer system such as a VR/AR headset, desktop computer, notebook or laptop computer, netbook, a tablet computer, e-book reader, GPS device, camera, personal digital assistant (PDA), handheld electronic device, cellular telephone, smartphone, augmented/virtual reality device, other suitable electronic device, or any suitable combination thereof. This disclosure contemplates any suitable client systems 2530. A client system 2530 may enable a network user at client system 2530 to access network 2510. A client system 2530 may enable its user to communicate with other users at other client systems 2530.
In particular embodiments, social-networking system 2560 may be a network-addressable computing system that can host an online social network. Social-networking system 2560 may generate, store, receive, and send social-networking data, such as, for example, user-profile data, concept-profile data, social-graph information, or other suitable data related to the online social network. Social-networking system 2560 may be accessed by the other components of network environment 2500 either directly or via network 2510. As an example and not by way of limitation, client system 2530 may access social-networking system 2560 using a web browser, or a native application associated with social-networking system 2560 (e.g., a mobile social-networking application, a messaging application, another suitable application, or any combination thereof) either directly or via network 2510. In particular embodiments, social-networking system 2560 may include one or more servers 2562. Each server 2562 may be a unitary server or a distributed server spanning multiple computers or multiple datacenters. Servers 2562 may be of various types, such as, for example and without limitation, web server, news server, mail server, message server, advertising server, file server, application server, exchange server, database server, proxy server, another server suitable for performing functions or processes described herein, or any combination thereof. In particular embodiments, each server 2562 may include hardware, software, or embedded logic components or a combination of two or more such components for carrying out the appropriate functionalities implemented or supported by server 2562. In particular embodiments, social-networking system 2560 may include one or more data stores 2564. Data stores 2564 may be used to store various types of information. In particular embodiments, the information stored in data stores 2564 may be organized according to specific data structures. In particular embodiments, each data store 2564 may be a relational, columnar, correlation, or other suitable database. Although this disclosure describes or illustrates particular types of databases, this disclosure contemplates any suitable types of databases. Particular embodiments may provide interfaces that enable a client system 2530, a social-networking system 2560, or a third-party system 2570 to manage, retrieve, modify, add, or delete, the information stored in data store 2564.
In particular embodiments, social-networking system 2560 may store one or more social graphs in one or more data stores 2564. In particular embodiments, a social graph may include multiple nodes—which may include multiple user nodes (each corresponding to a particular user) or multiple concept nodes (each corresponding to a particular concept)—and multiple edges connecting the nodes. Social-networking system 2560 may provide users of the online social network the ability to communicate and interact with other users. In particular embodiments, users may join the online social network via social-networking system 2560 and then add connections (e.g., relationships) to a number of other users of social-networking system 2560 to whom they want to be connected. Herein, the term “friend” may refer to any other user of social-networking system 2560 with whom a user has formed a connection, association, or relationship via social-networking system 2560.
In particular embodiments, social-networking system 2560 may provide users with the ability to take actions on various types of items or objects, supported by social-networking system 2560. As an example and not by way of limitation, the items and objects may include groups or social networks to which users of social-networking system 2560 may belong, events or calendar entries in which a user might be interested, computer-based applications that a user may use, transactions that allow users to buy or sell items via the service, interactions with advertisements that a user may perform, or other suitable items or objects. A user may interact with anything that is capable of being represented in social-networking system 2560 or by an external system of third-party system 2570, which is separate from social-networking system 2560 and coupled to social-networking system 2560 via a network 2510.
In particular embodiments, social-networking system 2560 may be capable of linking a variety of entities. As an example and not by way of limitation, social-networking system 2560 may enable users to interact with each other as well as receive content from third-party systems 2570 or other entities, or to allow users to interact with these entities through an application programming interfaces (API) or other communication channels.
In particular embodiments, a third-party system 2570 may include a local computing device that is communicatively coupled to the client system 2530. For example, if the client system 2530 is an AR/VR headset, the third-party system 2570 may be a local laptop configured to perform the necessary graphics rendering and provide the rendered results to the AR/VR headset 2530 for subsequent processing and/or display. In particular embodiments, the third-party system 2570 may execute software associated with the client system 2530 (e.g., a rendering engine). The third-party system 2570 may generate sample datasets with sparse pixel information of video frames and send the sparse data to the client system 2530. The client system 2530 may then generate frames reconstructed from the sample datasets.
In particular embodiments, the third-party system 2570 may also include one or more types of servers, one or more data stores, one or more interfaces, including but not limited to APIs, one or more web services, one or more content sources, one or more networks, or any other suitable components, e.g., that servers may communicate with. A third-party system 2570 may be operated by a different entity from an entity operating social-networking system 2560. In particular embodiments, however, social-networking system 2560 and third-party systems 2570 may operate in conjunction with each other to provide social-networking services to users of social-networking system 2560 or third-party systems 2570. In this sense, social-networking system 2560 may provide a platform, or backbone, which other systems, such as third-party systems 2570, may use to provide social-networking services and functionality to users across the Internet.
In particular embodiments, a third-party system 2570 may include a third-party content object provider (e.g., including sparse sample datasets described herein). A third-party content object provider may include one or more sources of content objects, which may be communicated to a client system 2530. As an example and not by way of limitation, content objects may include information regarding things or activities of interest to the user, such as, for example, movie show times, movie reviews, restaurant reviews, restaurant menus, product information and reviews, or other suitable information. As another example and not by way of limitation, content objects may include incentive content objects, such as coupons, discount tickets, gift certificates, or other suitable incentive objects.
In particular embodiments, social-networking system 2560 also includes user-generated content objects, which may enhance a user's interactions with social-networking system 2560. User-generated content may include anything a user can add, upload, send, or “post” to social-networking system 2560. As an example and not by way of limitation, a user communicates posts to social-networking system 2560 from a client system 2530. Posts may include data such as status updates or other textual data, location information, photos, videos, links, music or other similar data or media. Content may also be added to social-networking system 2560 by a third-party through a “communication channel,” such as a newsfeed or stream.
In particular embodiments, social-networking system 2560 may include a variety of servers, sub-systems, programs, modules, logs, and data stores. In particular embodiments, social-networking system 2560 may include one or more of the following: a web server, action logger, API-request server, relevance-and-ranking engine, content-object classifier, notification controller, action log, third-party-content-object-exposure log, inference module, authorization/privacy server, search module, advertisement-targeting module, user-interface module, user-profile store, connection store, third-party content store, or location store. Social-networking system 2560 may also include suitable components such as network interfaces, security mechanisms, load balancers, failover servers, management-and-network-operations consoles, other suitable components, or any suitable combination thereof. In particular embodiments, social-networking system 2560 may include one or more user-profile stores for storing user profiles. A user profile may include, for example, biographic information, demographic information, behavioral information, social information, or other types of descriptive information, such as work experience, educational history, hobbies or preferences, interests, affinities, or location. Interest information may include interests related to one or more categories. Categories may be general or specific. As an example and not by way of limitation, if a user “likes” an article about a brand of shoes the category may be the brand, or the general category of “shoes” or “clothing.” A connection store may be used for storing connection information about users. The connection information may indicate users who have similar or common work experience, group memberships, hobbies, educational history, or are in any way related or share common attributes. The connection information may also include user-defined connections between different users and content (both internal and external). A web server may be used for linking social-networking system 2560 to one or more client systems 2530 or one or more third-party system 2570 via network 2510. The web server may include a mail server or other messaging functionality for receiving and routing messages between social-networking system 2560 and one or more client systems 2530. An API-request server may allow a third-party system 2570 to access information from social-networking system 2560 by calling one or more APIs. An action logger may be used to receive communications from a web server about a user's actions on or off social-networking system 2560. In conjunction with the action log, a third-party-content-object log may be maintained of user exposures to third-party-content objects. A notification controller may provide information regarding content objects to a client system 2530. Information may be pushed to a client system 2530 as notifications, or information may be pulled from client system 2530 responsive to a request received from client system 2530. Authorization servers may be used to enforce one or more privacy settings of the users of social-networking system 2560. A privacy setting of a user determines how particular information associated with a user can be shared. The authorization server may allow users to opt in to or opt out of having their actions logged by social-networking system 2560 or shared with other systems (e.g., third-party system 2570), such as, for example, by setting appropriate privacy settings. Third-party-content-object stores may be used to store content objects received from third parties, such as a third-party system 2570. Location stores may be used for storing location information received from client systems 2530 associated with users. Advertisement-pricing modules may combine social information, the current time, location information, or other suitable information to provide relevant advertisements, in the form of notifications, to a user.
This disclosure contemplates any suitable number of computer systems 2600. This disclosure contemplates computer system 2600 taking any suitable physical form. As example and not by way of limitation, computer system 2600 may be an embedded computer system, a system-on-chip (SOC), a single-board computer system (SBC) (such as, for example, a computer-on-module (COM) or system-on-module (SOM)), a desktop computer system, a laptop or notebook computer system, an interactive kiosk, a mainframe, a mesh of computer systems, a mobile telephone, a personal digital assistant (PDA), a server, a tablet computer system, an augmented/virtual reality device, or a combination of two or more of these. Where appropriate, computer system 2600 may include one or more computer systems 2600; be unitary or distributed; span multiple locations; span multiple machines; span multiple data centers; or reside in a cloud, which may include one or more cloud components in one or more networks. Where appropriate, one or more computer systems 2600 may perform without substantial spatial or temporal limitation one or more steps of one or more methods described or illustrated herein. As an example and not by way of limitation, one or more computer systems 2600 may perform in real time or in batch mode one or more steps of one or more methods described or illustrated herein. One or more computer systems 2600 may perform at different times or at different locations one or more steps of one or more methods described or illustrated herein, where appropriate.
In particular embodiments, computer system 2600 includes a processor 2602, memory 2604, storage 2606, an input/output (I/O) interface 2608, a communication interface 2610, and a bus 2612. Although this disclosure describes and illustrates a particular computer system having a particular number of particular components in a particular arrangement, this disclosure contemplates any suitable computer system having any suitable number of any suitable components in any suitable arrangement.
In particular embodiments, processor 2602 includes hardware for executing instructions, such as those making up a computer program. As an example and not by way of limitation, to execute instructions, processor 2602 may retrieve (or fetch) the instructions from an internal register, an internal cache, memory 2604, or storage 2606; decode and execute them; and then write one or more results to an internal register, an internal cache, memory 2604, or storage 2606. In particular embodiments, processor 2602 may include one or more internal caches for data, instructions, or addresses. This disclosure contemplates processor 2602 including any suitable number of any suitable internal caches, where appropriate. As an example and not by way of limitation, processor 2602 may include one or more instruction caches, one or more data caches, and one or more translation lookaside buffers (TLBs). Instructions in the instruction caches may be copies of instructions in memory 2604 or storage 2606, and the instruction caches may speed up retrieval of those instructions by processor 2602. Data in the data caches may be copies of data in memory 2604 or storage 2606 for instructions executing at processor 2602 to operate on; the results of previous instructions executed at processor 2602 for access by subsequent instructions executing at processor 2602 or for writing to memory 2604 or storage 2606; or other suitable data. The data caches may speed up read or write operations by processor 2602. The TLBs may speed up virtual-address translation for processor 2602. In particular embodiments, processor 2602 may include one or more internal registers for data, instructions, or addresses. This disclosure contemplates processor 2602 including any suitable number of any suitable internal registers, where appropriate. Where appropriate, processor 2602 may include one or more arithmetic logic units (ALUs); be a multi-core processor; or include one or more processors 2602. Although this disclosure describes and illustrates a particular processor, this disclosure contemplates any suitable processor.
In particular embodiments, memory 2604 includes main memory for storing instructions for processor 2602 to execute or data for processor 2602 to operate on. As an example and not by way of limitation, computer system 2600 may load instructions from storage 2606 or another source (such as, for example, another computer system 2600) to memory 2604. Processor 2602 may then load the instructions from memory 2604 to an internal register or internal cache. To execute the instructions, processor 2602 may retrieve the instructions from the internal register or internal cache and decode them. During or after execution of the instructions, processor 2602 may write one or more results (which may be intermediate or final results) to the internal register or internal cache. Processor 2602 may then write one or more of those results to memory 2604. In particular embodiments, processor 2602 executes only instructions in one or more internal registers or internal caches or in memory 2604 (as opposed to storage 2606 or elsewhere) and operates only on data in one or more internal registers or internal caches or in memory 2604 (as opposed to storage 2606 or elsewhere). One or more memory buses (which may each include an address bus and a data bus) may couple processor 2602 to memory 2604. Bus 2612 may include one or more memory buses, as described below. In particular embodiments, one or more memory management units (MMUs) reside between processor 2602 and memory 2604 and facilitate accesses to memory 2604 requested by processor 2602. In particular embodiments, memory 2604 includes random access memory (RAM). This RAM may be volatile memory, where appropriate. Where appropriate, this RAM may be dynamic RAM (DRAM) or static RAM (SRAM). Moreover, where appropriate, this RAM may be single-ported or multi-ported RAM. This disclosure contemplates any suitable RAM. Memory 2604 may include one or more memories 2604, where appropriate. Although this disclosure describes and illustrates particular memory, this disclosure contemplates any suitable memory.
In particular embodiments, storage 2606 includes mass storage for data or instructions. As an example and not by way of limitation, storage 2606 may include a hard disk drive (HDD), a floppy disk drive, flash memory, an optical disc, a magneto-optical disc, magnetic tape, or a Universal Serial Bus (USB) drive or a combination of two or more of these. Storage 2606 may include removable or non-removable (or fixed) media, where appropriate. Storage 2606 may be internal or external to computer system 2600, where appropriate. In particular embodiments, storage 2606 is non-volatile, solid-state memory. In particular embodiments, storage 2606 includes read-only memory (ROM). Where appropriate, this ROM may be mask-programmed ROM, programmable ROM (PROM), erasable PROM (EPROM), electrically erasable PROM (EEPROM), electrically alterable ROM (EAROM), or flash memory or a combination of two or more of these. This disclosure contemplates mass storage 2606 taking any suitable physical form. Storage 2606 may include one or more storage control units facilitating communication between processor 2602 and storage 2606, where appropriate. Where appropriate, storage 2606 may include one or more storages 2606. Although this disclosure describes and illustrates particular storage, this disclosure contemplates any suitable storage.
In particular embodiments, I/O interface 2608 includes hardware, software, or both, providing one or more interfaces for communication between computer system 2600 and one or more I/O devices. Computer system 2600 may include one or more of these I/O devices, where appropriate. One or more of these I/O devices may enable communication between a person and computer system 2600. As an example and not by way of limitation, an I/O device may include a keyboard, keypad, microphone, monitor, mouse, printer, scanner, speaker, still camera, stylus, tablet, touch screen, trackball, video camera, another suitable I/O device or a combination of two or more of these. An I/O device may include one or more sensors. This disclosure contemplates any suitable I/O devices and any suitable I/O interfaces 2608 for them. Where appropriate, I/O interface 2608 may include one or more device or software drivers enabling processor 2602 to drive one or more of these I/O devices. I/O interface 2608 may include one or more I/O interfaces 2608, where appropriate. Although this disclosure describes and illustrates a particular I/O interface, this disclosure contemplates any suitable I/O interface.
In particular embodiments, communication interface 2610 includes hardware, software, or both providing one or more interfaces for communication (such as, for example, packet-based communication) between computer system 2600 and one or more other computer systems 2600 or one or more networks. As an example and not by way of limitation, communication interface 2610 may include a network interface controller (NIC) or network adapter for communicating with an Ethernet or other wire-based network or a wireless NIC (WNIC) or wireless adapter for communicating with a wireless network, such as a WI-FI network. This disclosure contemplates any suitable network and any suitable communication interface 2610 for it. As an example and not by way of limitation, computer system 2600 may communicate with an ad hoc network, a personal area network (PAN), a local area network (LAN), a wide area network (WAN), a metropolitan area network (MAN), or one or more portions of the Internet or a combination of two or more of these. One or more portions of one or more of these networks may be wired or wireless. As an example, computer system 2600 may communicate with a wireless PAN (WPAN) (such as, for example, a BLUETOOTH WPAN), a WI-FI network, a WI-MAX network, a cellular telephone network (such as, for example, a Global System for Mobile Communications (GSM) network), or other suitable wireless network or a combination of two or more of these. Computer system 2600 may include any suitable communication interface 2610 for any of these networks, where appropriate. Communication interface 2610 may include one or more communication interfaces 2610, where appropriate. Although this disclosure describes and illustrates a particular communication interface, this disclosure contemplates any suitable communication interface.
In particular embodiments, bus 2612 includes hardware, software, or both coupling components of computer system 2600 to each other. As an example and not by way of limitation, bus 2612 may include an Accelerated Graphics Port (AGP) or other graphics bus, an Enhanced Industry Standard Architecture (EISA) bus, a front-side bus (FSB), a HYPERTRANSPORT (HT) interconnect, an Industry Standard Architecture (ISA) bus, an INFINIBAND interconnect, a low-pin-count (LPC) bus, a memory bus, a Micro Channel Architecture (MCA) bus, a Peripheral Component Interconnect (PCI) bus, a PCI-Express (PCIe) bus, a serial advanced technology attachment (SATA) bus, a Video Electronics Standards Association local (VLB) bus, or another suitable bus or a combination of two or more of these. Bus 2612 may include one or more buses 2612, where appropriate. Although this disclosure describes and illustrates a particular bus, this disclosure contemplates any suitable bus or interconnect.
Herein, a computer-readable non-transitory storage medium or media may include one or more semiconductor-based or other integrated circuits (ICs) (such, as for example, field-programmable gate arrays (FPGAs) or application-specific ICs (ASICs)), hard disk drives (HDDs), hybrid hard drives (HHDs), optical discs, optical disc drives (ODDs), magneto-optical discs, magneto-optical drives, floppy diskettes, floppy disk drives (FDDs), magnetic tapes, solid-state drives (SSDs), RAM-drives, SECURE DIGITAL cards or drives, any other suitable computer-readable non-transitory storage media, or any suitable combination of two or more of these, where appropriate. A computer-readable non-transitory storage medium may be volatile, non-volatile, or a combination of volatile and non-volatile, where appropriate.
Herein, “or” is inclusive and not exclusive, unless expressly indicated otherwise or indicated otherwise by context. Therefore, herein, “A or B” means “A, B, or both,” unless expressly indicated otherwise or indicated otherwise by context. Moreover, “and” is both joint and several, unless expressly indicated otherwise or indicated otherwise by context. Therefore, herein, “A and B” means “A and B, jointly or severally,” unless expressly indicated otherwise or indicated otherwise by context.
The scope of this disclosure encompasses all changes, substitutions, variations, alterations, and modifications to the example embodiments described or illustrated herein that a person having ordinary skill in the art would comprehend. The scope of this disclosure is not limited to the example embodiments described or illustrated herein. Moreover, although this disclosure describes and illustrates respective embodiments herein as including particular components, elements, feature, functions, operations, or steps, any of these embodiments may include any combination or permutation of any of the components, elements, features, functions, operations, or steps described or illustrated anywhere herein that a person having ordinary skill in the art would comprehend. Furthermore, reference in the appended claims to an apparatus or system or a component of an apparatus or system being adapted to, arranged to, capable of, configured to, enabled to, operable to, or operative to perform a particular function encompasses that apparatus, system, component, whether or not it or that particular function is activated, turned on, or unlocked, as long as that apparatus, system, or component is so adapted, arranged, capable, configured, enabled, operable, or operative. Additionally, although this disclosure describes or illustrates particular embodiments as providing particular advantages, particular embodiments may provide none, some, or all of these advantages.
