Constant multiplication with texture unit of graphics processing unit
Summary by NHIP
GPU Texture Constant Multiplication
The method processes graphics data by having a GPU texture unit multiply fetched texture data by at least one constant. This multiplication occurs after the unit applies texture filtering to the data and outputs the result directly to a raster operations pipeline while bypassing shader processors.
Claim Score by NHIP
Abstract
A texture unit of a graphics processing unit (GPU) may receive a texture data. The texture unit may receive the texture data from the memory. The texture unit may also multiply, by a multiplier circuit of the texture unit, the texture data by at least one constant, where the constant is not associated with a filtering operation, and where the texture data comprises at least one texel. The texture unit may also output, by the texture unit, a result of multiplying the texture data by the at least one constant.

Term
9.6 yearsleft in the term
Expires 28 April 2036.
- Priority and filed
- Granted
- Today
- Expires
27 claims: 3 independent, 24 dependent
- 1A method of processing graphics data, the method comprising:receiving, by a graphics processing unit (GPU) that includes a shader unit, a compiled shader program, the shader unit including one or more shader processors and a texture unit, the compiled shader program being written for execution on the one or more shader processors;fetching, by the texture unit, texture data from a graphics memory, wherein the texture unit includes one or more hardware units separate from any shader processor of the GPU, wherein the one or more hardware units included in the texture unit include dedicated hardware for performing texture filtering;executing the compiled shader program by the GPU, wherein execution of the compiled shader program by the GPU causes the one or more hardware units included in the texture unit to multiply the texture data by at least one constant, wherein the one or more hardware units in the texture unit are configured to multiply the texture data by the at least one constant after the one or more hardware units included in the texture unit apply a texture filtering operation to the texture data, and wherein the texture data comprises at least one texel;and outputting, by the texture unit to a raster operations pipeline and bypassing any shader processor in the GPU, a result of multiplying the texture data by the at least one constant, wherein the result comprises a product of the texture data and the constant.
- 10Broadest claimClaim Score 41, average(NHIP)A computing device for processing graphics, the computing device comprising:a memory configured to store texture data;a shader unit that comprises one or more shader processors and a texture unit, wherein the texture unit is configured to: fetch the texture data from the memory;wherein: one or more hardware units included in the texture unit include dedicated hardware for performing texture filtering, the one or more hardware units being separate from any shader processor in a graphics processing unit, the texture unit includes a multiplier circuit, and execution of a compiled shader program by the computing device causes the multiplier circuit to multiply the texture data by at least one constant, wherein the multiplier circuit is configured to multiply the texture data by the at least one constant after the texture unit applies a texture filtering operation to the texture data, and wherein the texture data comprises at least one texel, the shader program being written for execution on the one or more shader processors;and output, to a raster operations pipeline and bypassing any shader processor in the computing device, a result of multiplying the texture data by the at least one constant, wherein the result comprises a product of the texture data and the constant.
- 19A non-transitory computer-readable medium having instructions stored thereon that, when executed, cause one or more processors to:receive, by a graphics processing unit (GPU) that includes a shader unit, a compiled shader program, the shader unit including one or more shader processors and a texture unit, the compiled shader program being written for execution on the one or more shader processors;fetch, by the texture unit, texture data, wherein the texture unit includes one or more hardware units separate from any shader processor in the GPU, wherein the one or more hardware units included in the texture unit include dedicated hardware for performing texture filtering;execute the compiled shader program by the GPU, wherein execution of the compiled shader program by the GPU causes the one or more hardware units included in the texture unit to multiply the texture data by at least one constant, wherein the one or more hardware units in the texture unit are configured to multiply the texture data by the at least one constant after the one or more hardware units included in the texture unit apply a texture filtering operation to the texture data, and wherein the texture data comprises at least one texel;and output, by the texture unit to a raster operations pipeline and bypassing any shader processor in the GPU, a result of multiplying the texture data by the at least one constant, wherein the result comprises a product of the texture data and the constant.
Independent claims3
75 paragraphs in 5 sections, as filed
TECHNICAL FIELD
0001The present disclosure relates to using a texture unit of a graphics processing unit for multiplication operations.
BACKGROUND
0002Visual content for display, such as content for graphical user interfaces and video games, may be generated by a graphics processing unit (GPU). A GPU may convert two-dimensional or three-dimensional (3D) objects into a two-dimensional (2D) pixel representation that may be displayed. Converting information about 3D objects into a bit map that can be displayed is known as pixel rendering, and requires considerable memory and processing power. In some examples, GPUs may include one or more texture units and one or more shader processors. The texture units may be responsible for addressing and filtering textures. The shader processors may receive the filtered textures from the texture units and implement shader stages of a graphics rendering pipeline to perform pixel rendering.
SUMMARY
0003The techniques of this disclosure include modifying or expanding a texture unit (also referred to as a texture pipe, texture engine, or texture mapping unit) of a graphics processing unit to perform multiplication operations on filtered values. In an example, a texture unit may multiply each color value for a texel by a respective filter weight. The texture unit may then add the result of each of these multiplications together as a filtered value for a current texel. Rather than passing this filtered value to a shader processor to perform multiplication, the texture unit may also multiply the filtered value by a constant. Performing the multiplication with the texture unit may result in a power savings, because the shader processor does not need to be activated to perform the multiplication.
0004In one example, a method of processing graphics includes receiving, by a texture unit of a graphics processing unit (GPU), texture data, multiplying, by the texture unit, the texture data by at least one constant, wherein the constant is not associated with a filtering operation, and wherein the texture data comprises at least one texel, and outputting, by the texture unit, a result of multiplying the texture data by the at least one constant.
0005In another example, a computing device for processing graphics includes a memory configured to store texture data, and a texture unit configured to receive the texture data from the memory, multiply, by a multiplier circuit of the texture unit, the texture data by at least one constant, wherein the constant is not associated with a filtering operation, and wherein the texture data comprises at least one texel, and output, by the texture unit, a result of multiplying the texture data by the at least one constant.
0006In another example, a non-transitory computer-readable medium has instructions stored thereon that, when executed, cause one or more processors to receive, by a texture unit of a graphics processing unit (GPU), texture data, multiply, by the texture unit, the texture data by at least one constant, wherein the constant is not associated with a filtering operation, and wherein the texture data comprises at least one texel, and output, by the texture unit, a result of multiplying the texture data by the at least one constant.
0007The details of one or more aspects of the present disclosure are set forth in the accompanying drawings and the description below. Other features, objects, and advantages of the present disclosure will be apparent from the description and drawings, and from the claims.
BRIEF DESCRIPTION OF DRAWINGS
<figref idref="DRAWINGS">FIG. 1</figref> is a block diagram illustrating an example computing device that may be configured to implement one or more aspects of this disclosure.
<figref idref="DRAWINGS">FIG. 2</figref> is a conceptual diagram illustrating an example texture unit, according to aspects of this disclosure.
<figref idref="DRAWINGS">FIGS. 3A and 3B</figref> are flow diagrams illustrating example operations of a GPU.
<figref idref="DRAWINGS">FIG. 4</figref> is a flowchart illustrating a process for a texture unit to perform multiplication operations, according to aspects of this disclosure.
DETAILED DESCRIPTION
0012A GPU may apply and render one or more textures to each polygon of a scene. As part of rendering the scene, the GPU may be configured to filter the textures before converting a three-dimensional representation of the scene to a two-dimensional grid of pixels, a process referred to as rasterization.
0013Texture filtering or texture smoothing may be used to determine the texture color for a texture mapped pixel using the colors of nearby texels. In general, texels (also referred to as texture elements) may be the fundamental units of texture space. A texture may be represented by an array of texels, which contain color and/or alpha values (e.g., transparency values or opacity values) for a particular texture in a particular colorspace. Mathematically, texture filtering may be considered to be a type of anti-aliasing. However, texture filtering may be directed to filtering out high frequencies from the texture fill, whereas other anti-aliasing techniques may generally focus on visual edges. In general, texture filtering allows a texture to be applied at many different shapes, sizes and angles while minimizing blurriness, shimmering and blocking. Example texture filtering techniques include bilinear filtering and trilinear filtering.
0014Filtering may be performed by a texture unit, which may be included as part of a pixel processing pipeline. The texture unit may include both programmable and fixed function hardware designed to apply textures (texels) to pixels. The texture unit may include dedicated hardware for performing texture filtering, whereby one or more texel values are multiplied by one or more filter coefficient values. The texture unit may store filtering results in an accumulator, and add the filtering results to produce a final filtered texel.
0015In some instances, filtered texels may be multiplied by a constant value after filtering. For example, a constant associated with a color or lighting gain may be applied to filtered texels. To apply the constant, the texture unit may pass the filtered texels to a shader processor (also referred to as a shader pipe), which uses arithmetic logic units (ALUs) to multiply the received texels by the constant value. However, the shader processor may consume a relatively large amount of power and may include a number of components that are not necessary to perform the multiplication operation. Accordingly, powering the entire shader processor to multiply texture data by a constant may be relatively inefficient.
0016The techniques of this disclosure include modifying and/or expanding a texture unit (or texture engine) to perform multiplication operations on filtered texel values. In an example, a texture unit may multiply each color value for a texel by a respective filter weight. The texture unit may then add the result of each of these multiplications together as a filtered value for a current texel. Rather than passing this filtered value to a shader processor to apply a constant, the texture unit may also multiply the filtered value by a constant. Performing the multiplication with the texture unit may save power, because the shader processor does not need to be activated to perform the multiplication. That is, the texture unit may bypass the shader processor, which allows the shader processor to remain powered down (or performing another task) during the texture filtering operation.
0017In some examples, a texture unit may be expanded to include separate multiplier logic. In other examples, a multiplier circuit of a texture unit may be configured to perform both a filtering function and a constant multiplication function. In such examples, a multiplexer may be used to select the appropriate function. For example, a multiplexer may be used to determine whether to apply a trilinear weight to a texel or a constant to a texel using the same multiplier unit.
0018A constant buffer may store the constants being applied by the texture unit. The texture unit may incorporate logic that provides flexibility in the manner in which constants are applied to texture values. For example, the texture unit may incorporate logic that allows different constant values to be applied to respective texture values of a particular texel.
0019<figref idref="DRAWINGS">FIG. 1</figref> is a block diagram illustrating an example computing device <b>10</b> that may be configured to implement one or more aspects of this disclosure. Computing device <b>10</b> may be a computing device including but not limited to video devices, media players, set-top boxes, wireless handsets such as mobile telephones and so-called smartphones, personal digital assistants (PDAs), desktop computers, laptop computers, gaming consoles, video conferencing units, tablet computing devices, and the like.
0020In the example of <figref idref="DRAWINGS">FIG. 1</figref>, computing device <b>10</b> includes central processing unit (CPU) <b>12</b>, GPU <b>14</b>, and system memory <b>16</b>. Computing device <b>10</b> also includes transceiver module <b>19</b>, user interface <b>20</b>, and display <b>21</b>. It should be understood, however, that other examples of computing device <b>10</b> may include more, fewer, or an alternative arrangement of components than those shown.
0021For example, computing device <b>10</b> may include a speaker and a microphone, neither of which are shown in <figref idref="DRAWINGS">FIG. 1</figref>, to effectuate telephonic communications in examples where computing device <b>10</b> is a mobile wireless telephone, or a speaker where computing device <b>10</b> is a media player. Computing device <b>10</b> may also include a video camera. In another example, certain units such as transceiver module <b>19</b> or a display processor associated with display <b>21</b> may be part of the same integrated circuit (IC) as CPU <b>12</b> and/or GPU <b>14</b>, may both be external to the IC or ICs that include CPU <b>12</b> and/or GPU <b>14</b>, or may be formed in the IC that is external to the IC that includes CPU <b>12</b> and/or GPU <b>14</b>.
0022CPU <b>12</b> may comprise a general-purpose or a special-purpose processor that controls operation of computing device <b>10</b>. For example, CPU <b>12</b> may include one or more processors, such as one or more microprocessors, application specific integrated circuits (ASICs), field programmable gate arrays (FPGAs), digital signal processors (DSPs), or other equivalent integrated or discrete logic circuitry. As described in greater detail below, CPU <b>12</b> may issue one or more graphics rendering commands to GPU <b>14</b> to cause GPU <b>14</b> to render graphics data.
0023GPU <b>14</b> may include a programmable pipeline of processing components having a highly-parallel structure that provides efficient processing of complex graphic-related operations. GPU <b>14</b> may include one or more processors, such as one or more microprocessors, application specific integrated circuits (ASICs), field programmable gate arrays (FPGAs), digital signal processors (DSPs), or other equivalent integrated or discrete logic circuitry. GPU <b>14</b> may also include one or more processor cores, such that GPU <b>14</b> may be referred to as a multi-core processor. GPU <b>14</b> may, in some instances, be integrated into a motherboard of computing device <b>10</b>. In other instances, GPU <b>14</b> may be present on a graphics card that is installed in a port in the motherboard of computing device <b>10</b> or may be otherwise incorporated within a peripheral device configured to interoperate with computing device <b>10</b>.
0024GPU <b>14</b> may output rendered data to system memory <b>16</b>, e.g., frame buffer <b>18</b> of system memory <b>16</b>. System memory <b>16</b> may store an operating system (not shown) that controls the operation of components of computing device <b>10</b>. System memory <b>16</b> may also be used by software or applications (as described below) executed by computing device <b>10</b> to store information during program execution. System memory <b>16</b> may include a computer-readable storage medium or computer-readable storage device. In some examples, system memory <b>16</b> may include one or more of a short-term memory or a long-term memory. System memory <b>16</b> may include, for example, random access memories (RAM), dynamic random access memories (DRAM), static random access memories (SRAM), magnetic hard discs, optical discs, flash memories, or forms of electrically programmable memories (EPROM) or electrically erasable and programmable memories (EEPROM).
0025Frame buffer <b>18</b> stores destination pixels for GPU <b>14</b>. Each destination pixel may be associated with a unique screen pixel location. In some examples, frame buffer <b>18</b> may store color components and a destination alpha value for each destination pixel. For example, frame buffer <b>18</b> may store Red, Green, Blue, Alpha (RGBA) components for each pixel where the “RGB” components correspond to color values and the “A” component corresponds to a destination alpha value (e.g., a transparency value that may be used in compositing, which may also be referred to as opacity). Although frame buffer <b>18</b> and system memory <b>16</b> are illustrated as being separate memory units, in other examples, frame buffer <b>18</b> may be part of system memory <b>16</b>.
0026Transceiver module <b>19</b> may include circuitry to allow wireless or wired communication between computing device <b>10</b> and another device or a network. Transceiver module <b>19</b> may include modulators, demodulators, amplifiers and other such circuitry for wired or wireless communication.
0027User interface <b>20</b> may allow a user to provide input to computing device <b>10</b>. Examples of user interface <b>20</b> include, but are not limited to, a trackball, a mouse, a keyboard, and other types of input devices. User interface <b>20</b> may also be a touch screen and may be incorporated as a part of display <b>21</b>.
0028Display <b>21</b> may display image content generated by GPU <b>14</b>, e.g., such as rendered graphics data from frame buffer <b>18</b>. Display <b>21</b> may be a liquid crystal display (LCD), an organic light emitting diode display (OLED), a cathode ray tube (CRT) display, a plasma display, or another type of display device. Display <b>21</b> may include a display processor that retrieves images from system memory <b>16</b> and outputs values that cause the pixels of display <b>21</b> to illuminate to display the image.
0029In operation, CPU <b>12</b> may execute one or more software applications <b>24</b>. Software applications <b>24</b> may include any application that utilizes the functionality of GPU <b>14</b>. For example, software applications <b>24</b> may include a graphical user interface (GUI) application, an operating system, a portable mapping application, a computer-aided design program for engineering or artistic applications, a video game application, or another type of software application that uses 2D or 3D graphics.
0030Software applications <b>24</b> may include one or more drawing instructions that instruct GPU <b>14</b> to render a graphical user interface (GUI) and/or a graphics scene. For example, the drawing instructions may include instructions that define a set of one or more graphics primitives to be rendered by GPU <b>14</b>. In some examples, the drawing instructions may, collectively, define all or part of a plurality of windowing surfaces used in a GUI. In additional examples, the drawing instructions may, collectively, define all or part of a graphics scene that includes one or more graphics objects within a model space or world space defined by the application.
0031Software applications <b>24</b> may use graphics application programming interface (API) <b>26</b> to invoke GPU driver <b>28</b>. Example graphics APIs include an Open Graphics Library (OpenGL®) API, an Open Graphics Library Embedded Systems (OpenGL ES) API, a Direct3D API, an X3D API, a RenderMan API, a WebGL API, an Open Computing Language (OpenCL™), RenderScript or any other heterogeneous computing APIs, or any other public or proprietary standard graphics or compute API.
0032GPU driver <b>28</b> may issue one or more commands to GPU <b>14</b> for rendering one or more graphics primitives into displayable graphics images. For example, software applications <b>24</b> may invoke GPU driver <b>28</b>, via graphics API <b>26</b>, to provide primitive definitions to GPU <b>14</b>. In some instances, GPU driver <b>28</b> may provide primitive definitions to GPU <b>14</b> in the form of a list of drawing primitives, e.g., triangles, rectangles, triangle fans, triangle strips, etc. The primitive definitions may include vertex specifications that specify one or more vertices associated with the primitives to be rendered. The vertex specifications may include positional coordinates for each vertex and, in some instances, other attributes associated with the vertex, such as, e.g., color coordinates, normal vectors, and texture coordinates. The primitive definitions may also include primitive type information (e.g., triangle, rectangle, triangle fan, triangle strip, etc.), scaling information, rotation information, and the like. Hence, based on the instructions issued by software applications <b>24</b> to GPU driver <b>28</b>, GPU driver <b>28</b> may formulate one or more commands that specify one or more operations for GPU <b>14</b> to perform in order to render the primitive.
0033In some examples, GPU driver <b>28</b> may include a compiler configured to compile the commands as one or more shader programs, and to download the compiled shader programs to GPU <b>14</b>. The compiled shader programs may include one or more instructions that control the operation of shader units <b>32</b> within GPU <b>14</b>. The shader programs may be written in a high level shading language, such as, e.g., an OpenGL Shading Language (GLSL), a High Level Shading Language (HLSL), a C for Graphics (Cg) shading language, an OpenCL C kernel, etc.
0034GPU <b>14</b> includes shader units <b>32</b> for executing the shader programs. In some examples, shader units <b>32</b> may be referred to “unified shaders,” and may perform a variety of shading operations for rendering graphics. For example, shader units <b>32</b> may execute the shader programs to implement a variety of shader stages (which may collectively be referred to as a shader pipe) of a graphics processing pipeline. The shader programs may include vertex shader programs that may be executed by shader units <b>32</b> to perform the functions of a vertex shader stage, hull shader programs that may be executed by shader units <b>32</b> to perform the functions of a hull shader stage, domain shader programs that may be executed by shader units <b>32</b> to perform the functions of a domain shader stage, geometry shader programs that may be executed by shader units <b>32</b> to perform the functions of a geometry shader stage and/or pixel shader programs that may be executed by shader units <b>32</b> to perform the functions of a pixel shader.
0035In the example of <figref idref="DRAWINGS">FIG. 1</figref>, shader units <b>32</b> each have shader processors <b>34</b> and a texture unit <b>36</b> having constant unit <b>38</b>. Shader processors <b>34</b> may include a plurality of processing elements for operating on multiple vertices or pixels in a parallel manner. For example, shader processors <b>34</b> may each include one or more components for fetching and decoding operations, one or more ALUs for carrying out arithmetic calculations, one or more memories, caches, and registers.
0036Texture unit <b>36</b> may include one or more hardware units separate from shader processors <b>34</b> that are configured to operate on one or more texture data, such as one or more of texture data <b>40</b>A-<b>40</b>N (“texture data <b>40</b>”) stored to graphics memory <b>42</b>. Texture unit <b>36</b> may include both programmable and fixed function hardware designed to apply textures (texels) to pixels. In some examples, texture unit <b>36</b> may be a dedicated set of hardware units that are dedicated to operating on texture data <b>40</b>, such as dedicated to performing texture filtering on texture data <b>40</b> or configured to calculate dot products of texture data <b>40</b> and the like. As described below with respect to <figref idref="DRAWINGS">FIG. 2</figref>, texture unit <b>36</b> may include a texture data cache and logic (e.g., adders, multipliers, and/or other digital circuitry) for performing operations on texture data <b>40</b>. While texture unit <b>36</b> is shown in the example of <figref idref="DRAWINGS">FIG. 1</figref> as being included in shader units <b>32</b>, it should be understood that, in other examples, texture unit <b>36</b> may also be disposed outside of shader units <b>32</b>.
0037Each of texture data <b>40</b>A-<b>40</b>N may comprise texture elements, also referred to as texels, which are the fundamental units of texture space. Each of texture data <b>40</b>A-<b>40</b>N may be, but is not necessarily limited to, a one-dimensional, two-dimensional, or three-dimensional texture, or a one-dimensional, two-dimensional, or three-dimensional array of texture. Texture data <b>40</b> may include multiple textures (e.g., textures <b>40</b>A, <b>40</b>B, etc.). In one example, a texture data (e.g., texture data <b>40</b>A) of texture data <b>40</b> may include an array of texture elements, also known as texels, which contain color and alpha values for the texture data.
0038In some examples, each texture data of texture data <b>40</b>A-<b>40</b>N may be a two-dimensional image that GPU <b>14</b> maps to three-dimensional graphics. For instance, a pixel in a texture data (e.g., texture data <b>40</b>A), also referred to as a texel, may be identified by a (u, v) coordinate, and a texture data (e.g., texture data <b>40</b>A) may be made up of an array of texels. In some examples, GPU <b>14</b> may map the (u, v) coordinates of the array of texels of a texture data (e.g., texture data <b>40</b>A) to (x, y, z, w) coordinates. GPU <b>14</b> may also perform additional graphics processing on the texels of a texture data (e.g., texture data <b>40</b>A) (e.g., additional graphics processing on the red-green-blue (RGB) values of the texels). In some examples, a block may include one or more texels, so that a texture may include multiple blocks that each includes one or more texels. In some examples, a block may include a quad, which may be a block of four texels.
0039Graphics memory <b>42</b> may be an on-chip storage or memory that physically integrated into the integrated circuit of GPU <b>14</b> for storing texture data <b>40</b> and/or pixel data. Because graphics memory <b>42</b> is on-chip, GPU <b>14</b> may be able to read values from or write values to graphics memory <b>42</b> more quickly than reading values from or writing values to system memory <b>16</b> via a system bus.
0040In operation, texture unit <b>36</b> may perform texture filtering (also referred to as texture smoothing) on texture data <b>40</b> to determine a texture color for a texture mapped pixel using colors of nearby texels. Texture unit <b>36</b> may output the result of operating on the one or more texture data <b>40</b>. In some instances, shader processors <b>34</b> may instruct texture unit <b>36</b> to perform operations on texture data <b>40</b>, and texture unit <b>36</b> may send the results of operating on texture data <b>40</b> to shader processors <b>34</b> for further processing, e.g., for shading operations.
0041As noted above, texture unit <b>36</b> may typically be limited to performing a particular set of operations, e.g., associated with a texture pipe for filtering texture data <b>40</b>. For example, texture unit <b>36</b> may include dedicated hardware for performing texture filtering, whereby one or more texel values (e.g., of texture data <b>40</b>) are multiplied by one or more filter coefficient values. Texture unit <b>36</b> may store filtering results in an accumulator, and add the filtering results to produce a final filtered texel. Texture unit <b>36</b> may store the output to graphics memory <b>42</b> or pass the output to shader processors <b>34</b> for further operations.
0042In some instances, texture unit <b>36</b> may send the output to shader processors <b>34</b> to perform a multiplication operation. For example, shader processors <b>34</b> may multiply output from texture unit <b>36</b> by a constant associated with a color or lighting gain (or for any other reason). In this example, GPU <b>14</b> may utilize one or more components for fetching and decoding operations, one or more ALUs for carrying out arithmetic calculations, one or more memories, caches, and registers to apply the constant, which, in some instances, may be relatively inefficient.
0043According to aspects of this disclosure, texture unit <b>36</b> may be configured to multiply texture data <b>40</b> (e.g., including one or more texels) by one or more constants. As described herein, a constant may be any real number or set of real numbers not associated with a filtering operation. Texture unit <b>36</b> may use constant unit <b>38</b> to multiply texture data <b>40</b> by the one or more constants.
0044Constant unit <b>38</b> may include programmable or fixed function hardware for performing the multiplication. In some examples, constant unit <b>38</b> may incorporate at least some of the circuitry of texture unit <b>36</b> that is used to perform filtering operations. That is, as noted above, texture unit <b>36</b> may include programmable or fixed function logic for filtering texture data <b>40</b>, and constant unit <b>38</b> may reuse at least some of such hardware. In an example, as described in greater detail below with respect to <figref idref="DRAWINGS">FIG. 2</figref>, constant unit <b>38</b> may include multiplier logic that is used for trilinear filtering of texture data <b>40</b> to also multiply texture data <b>40</b> by the one or more constants.
0045Constant unit <b>38</b> may apply one or more constants, as specified by software applications <b>24</b>. For example, software applications <b>24</b> may include one or more drawing instructions that instruct GPU <b>14</b> to render or manipulate a graphics scene (e.g., apply a gain to a graphics scene). According to aspects of this disclosure, graphics API <b>26</b> may invoke GPU driver <b>28</b> with instructions to multiply texture data <b>40</b> with one or more constants. In some examples, graphics API <b>26</b> may designate constant unit <b>38</b> to perform the multiplication (rather than, for example, shader processors <b>34</b>).
0046GPU driver <b>28</b> may issue one or more commands to GPU <b>14</b> for multiplying texture data <b>40</b> by the one or more constants. Constant unit <b>38</b> may multiply texture data <b>40</b> by the one or more constants fetched from constant buffer <b>44</b> in accordance with the commands received from GPU driver <b>28</b>. Constant buffer <b>44</b> may include one or more registers for storing the constants. Constants stored to constant buffer <b>44</b> may each include an index.
0047In some examples, constant unit <b>38</b> may fetch the one or more constants from constant buffer <b>44</b>. In other examples, a processing unit associated with shader processors <b>34</b> may be responsible for fetching the one or more constants from constant buffer <b>44</b>. For example, a constant fetch unit responsible for fetching constants for shader processors <b>34</b> may also be responsible for fetching constants for constant unit <b>38</b>. This constant fetch unit may be a separate processing unit from texture unit <b>36</b>. In still other examples, GPU driver <b>28</b> may load constants from constant buffer <b>44</b> to texture unit <b>36</b>.
0048In some examples, constant unit <b>38</b> may multiply texture data <b>40</b> by a single constant. In other examples, constant unit <b>38</b> may multiply texture data <b>40</b> by more than one constant. For example, constant unit <b>38</b> may multiply each element of an array of texture data <b>40</b> (e.g., an alpha element, a red element, a green element and a blue element) by a respective constant, which may vary by component. In some examples, constant unit <b>38</b> may multiply fewer than all elements of texture data <b>40</b> by one or more constants.
0049In some examples, constant unit <b>38</b> may include swizzle logic to increase flexibility. For example, the swizzle logic may allow constant unit <b>38</b> to multiply any component of texture data <b>40</b> to any constant of a set of constants. In an example for purposes of illustration, texture data <b>40</b>A may include an alpha component, a red component, a green component and a blue component. Constant unit <b>38</b> may initially be configured to apply a first constant to the alpha component, a second constant to the red component, a third constant to the green component, and a fourth constant to the blue component. Constant unit <b>38</b> may use swizzle logic to, as an example, instead apply the third constant to the alpha component, or any other variation thereof.
0050In this way, according to aspects of this disclosure, hardware capability is incorporated to texture unit <b>36</b> that allows texture unit <b>36</b> to perform a constant multiply on texture output. In some examples, texture unit <b>36</b> may operate with dedicated hardware to perform an initial texture fetch of texture data <b>40</b> (which may also be included in constant unit <b>38</b>). In such examples, GPU <b>14</b> may execute a shader program for multiplying texture data <b>40</b> by a constant without any use of shader processors <b>34</b>, which may result in a power savings (versus powering shader processors <b>34</b> to perform the multiplication). That is, GPU <b>14</b> may bypass shader processors <b>34</b>, thereby leaving shader processors <b>34</b> idle and/or allowing shader processors <b>34</b> to perform other shading operations concurrently with the multiplication.
0051<figref idref="DRAWINGS">FIG. 2</figref> is a conceptual diagram illustrating texture unit <b>36</b> of <figref idref="DRAWINGS">FIG. 1</figref> in greater detail. In the example of <figref idref="DRAWINGS">FIG. 2</figref>, texture unit <b>36</b> includes texture data cache <b>60</b>, bilinear filtering logic <b>62</b> including multipliers (MUL) <b>64</b>A-<b>64</b>D (collectively, multipliers <b>64</b>) and accumulator (ADD) <b>66</b>, trilinear filtering logic <b>68</b> including multiplier <b>70</b> and accumulator <b>72</b>, and texture unit output <b>74</b>. Texture unit <b>36</b> also includes a multiplexer <b>76</b> that receives trilinear weight <b>78</b> and one or more constants <b>80</b> as inputs. It should be understood that the components shown in the example of <figref idref="DRAWINGS">FIG. 2</figref> are provided for purposes of illustration, and other texture units having more, fewer, or an alternative arrangement of components may be used to carry out the techniques described herein for multiplying texture data by one or more constants.
0052Texture data cache <b>60</b> may be configured to store texture data <b>40</b>. In some examples, texture data cache <b>60</b> may be a level one (L1) cache, which may store texture data <b>40</b> retrieved from graphics memory <b>42</b>.
0053Bilinear filtering logic <b>62</b> may be used to apply bilinear filtering to texels of texture data <b>40</b>. For example, texel coordinates may typically be stored at a certain precision (e.g., 8:8 fixed point). In some instances, texture unit <b>36</b> may only use the integer portion to index the texels during texel fetching. With bilinear interpolation, texture unit <b>36</b> may fetch four texels and use the fractional portion of the texel coordinate to determine a weight factor for each of the four texels, so that the final value of the texel is a mix of the four fetched texels.
0054In the example of <figref idref="DRAWINGS">FIG. 2</figref>, multipliers <b>64</b> may receive four texels (e.g., of texture data <b>40</b>) from texture data cache <b>60</b>, as well as corresponding bilinear weights <b>65</b> (also referred to as filter coefficient values). Multipliers <b>64</b> may multiply the texels by the appropriate bilinear weights <b>65</b> and send the results to accumulator <b>66</b>. Accumulator <b>66</b> may add the results to produce a final bilinearly filtered texel.
0055In some examples, bilinear filtering logic <b>62</b> may send the filtered texel to trilinear filtering logic <b>68</b>, which may be configured to apply trilinear filtering to texels of texture data <b>40</b>. That is, trilinear filtering logic <b>68</b> may interpolate the results of bilinear filtering using multiplier <b>70</b> and trilinear weight <b>78</b>. Accumulator <b>72</b> may add the results to produce a final trilinearly filtered texel.
0056The results of filtering using bilinear filtering logic <b>62</b> and trilinear filtering logic <b>68</b> (in instances in which trilinear filtering is performed) may be output to texture unit output <b>74</b>. In some examples, as noted above, texture unit output <b>74</b> may pass the filtered texture data to shader processors <b>34</b> for further processing.
0057According to aspects of this disclosure, texture unit <b>36</b> also includes constant unit <b>38</b>, which may be used to multiply texture data <b>40</b> by one or more constants <b>80</b>. In the example of <figref idref="DRAWINGS">FIG. 2</figref>, constant unit <b>38</b> includes multiplier <b>70</b> and multiplexer <b>76</b>. Multiplexer <b>76</b> may multiplex trilinear weight <b>78</b> and constants <b>80</b>. For example, multiplexer <b>76</b> provide either trilinear weight <b>78</b> or constants <b>80</b> to multiplier <b>70</b>, depending on whether trilinear filtering or constant multiplication is to be performed for a particular processing cycle. In this example, constant unit <b>38</b> may leverage multiplier <b>70</b> from trilinear filtering logic <b>68</b> to apply texels by constants <b>80</b>. In some examples, constant unit <b>38</b> may also include one or more components for fetching constants <b>80</b> from constant buffer <b>44</b>.
0058Texture unit <b>36</b> may use constant unit <b>38</b> to multiply unfiltered texture data, bilinearly filtered texture data, or trilinearly filtered texture data by one or more constants <b>80</b>. For example, texture unit <b>36</b> may pass unfiltered texture data <b>40</b> from texture data cache <b>60</b> to multiplier <b>70</b> without applying bilinear weights <b>65</b>. In this example, multiplexer <b>76</b> may provide constants <b>80</b> to multiplier <b>70</b>, and multiplier <b>70</b> may multiply the unfiltered texture data <b>40</b> by constants <b>80</b>.
0059In instances in which texture unit <b>36</b> performs bilinear filtering, multipliers <b>64</b> may multiply texels from texture data cache <b>60</b> by the appropriate bilinear weights <b>65</b> and send the results to accumulator <b>66</b>. Accumulator <b>66</b> may add the results to produce bilinearly filtered texture data. Multiplexer <b>76</b> may provide constants <b>80</b> to multiplier <b>70</b>, and multiplier <b>70</b> may multiply the result from bilinear filtering logic <b>62</b> by the constants <b>80</b> received from multiplexer <b>76</b>. In this way, constant unit <b>38</b> may multiply bilinearily filtered texture data by one or more constants.
0060In instances in which texture unit <b>36</b> performs trilinear filtering, multiplexer <b>76</b> may provide trilinear weight <b>78</b> to multiplier <b>70</b>. Multiplier <b>70</b> may apply trilinear weight <b>78</b> to the result from bilinear filtering logic <b>62</b>. Accumulator <b>72</b> may add the results to produce trilinearly filtered texture data. Multiplexer <b>76</b> may also provide constants <b>80</b> to multiplier <b>70</b>, and multiplier <b>70</b> may multiply the result from trilinear filtering logic <b>68</b> by the constants <b>80</b> received from multiplexer <b>76</b>. In this way, constant unit <b>38</b> may multiply trilinearly filtered texture data by one or more constants.
0061In some instances, texture unit <b>36</b> may perform trilinear filtering using two processing cycles in order to blend two different mipmaps (e.g., sequences of texture at different resolutions). For example, texture unit <b>36</b> may carry out two processing cycles to execute the following equation: <br />Tri-weight_for_Map_n*Bilinear_filtered_texel_for_Map_n+Tri-weight_for_Map_n−1*Bilinear_filtered_texel_for_Map_n−1<br /> When added together, trilinear weights <b>78</b> (i.e., Tri-weight_for_Map_n and Tri-weight_for_Map_n−1) may typically equal 1.0.
0062Texture unit <b>36</b> may perform the first half of the equation above in a first processing cycle and the second half of the equation above in a second processing cycle. For example, in a first processing cycle, multiplexer <b>76</b> may provide a first trilinear weight <b>78</b> (e.g., Tri-weight_for_Map_n) to multiplier <b>70</b> and multiplier <b>70</b> may apply the first trilinear weight <b>78</b> to a bilinearly filtered texel of a first mipmap (e.g., Bilinear_filtered_texel_for_Map_n). No addition is performed in the first processing cycle. In a second processing cycle, multiplexer <b>76</b> may provide a second trilinear weight <b>78</b> (e.g., Tri-weight_for_Map_n−1) to multiplier <b>70</b> and multiplier <b>70</b> may apply the second trilinear weight <b>78</b> to a bilinearly filtered texel of a second mipmap (e.g., Bilinear_filtered_texel_for_Map_n−1). In addition, accumulator <b>72</b> may add the weighted bilinearly filtered texels.
0063According to aspects of this disclosure, texture unit <b>36</b> may perform an additional processing cycle to multiply the trilinearily filtered data by one or more constants <b>80</b>. For example, in a third processing cycle, multiplexer <b>76</b> may provide constants <b>80</b> to multiplier <b>70</b>. Multiplier <b>70</b> may multiply constants <b>80</b> by the trilinearily filtered texture data, e.g., from the first two processing cycles.
0064<figref idref="DRAWINGS">FIGS. 3A and 3B</figref> are flow diagrams illustrating examples of multiplying texture data by a constant. In the example of <figref idref="DRAWINGS">FIG. 3A</figref>, an initial interpolator <b>100</b> may perform an initial texture fetch of texture data. According to aspects of this disclosure, initial interpolator <b>100</b> may comprise dedicated hardware for performing the texture fetch, such that a shader processor of a GPU (e.g., shader processors <b>34</b> of GPU <b>14</b>) does not need to be powered to fetch the texture data. The texture data may include i and j coordinates that specify a location within a texture surface, and texture identifiers t# and s# that specify a particular texture from a set of textures.
0065Texture pipe <b>102</b> may, in some examples, correspond to texture unit <b>36</b> of GPU <b>14</b> (<figref idref="DRAWINGS">FIG. 2</figref>). Texture pipe <b>102</b> may be configured to map texture data (such as texture data <b>40</b>) and apply one or more filters to the texture data. For example, texture pipe <b>102</b> may perform bilinear filtering, trilinear filtering, and/or other filtering operations.
0066In the example, of <figref idref="DRAWINGS">FIG. 3A</figref>, shader pipe <b>104</b> may receive the texture data from texture pipe <b>102</b>. Shader pipe <b>104</b> may multiply the texture data by one or more constants. For example, ALUs of shader pipe <b>104</b> may perform a MUL operation to multiply the texture data by the one or more constants. Shader pipe <b>104</b> may then pass pixel shaded pixels to render output pipeline <b>106</b>. Render output pipeline <b>106</b> may perform antialiasing or other operations to merge sample values prior to being written to a frame buffer, such as frame buffer <b>18</b> (<figref idref="DRAWINGS">FIG. 1</figref>).
0067According to aspects of this disclosure, as shown in the example of <figref idref="DRAWINGS">FIG. 3B</figref>, texture pipe <b>102</b> may be modified to perform multiplication by one or more constants. For example, as described above with respect to <figref idref="DRAWINGS">FIG. 2</figref>, texture pipe <b>102</b> may be configured to reuse certain hardware from texture filtering units to perform constant multiplication. In such an example, initial interpolator <b>100</b> may be responsible for fetching the texture data and texture pipe <b>102</b> may be responsible for multiplying the texture data by one or more constants. Accordingly, a GPU may bypass shader pipe <b>104</b> and pass the pixel shaded pixel directly to render output pipeline <b>106</b>. In this example, shader pipe <b>104</b> may perform shading operations concurrently with the multiplication performed by texture pipe <b>102</b>.
0068<figref idref="DRAWINGS">FIG. 4</figref> is a flowchart illustrating a process for a texture unit to perform multiplication operations, according to aspects of this disclosure. While the process is described with respect to GPU <b>14</b> and texture unit <b>36</b> (<figref idref="DRAWINGS">FIG. 1</figref>), it should be understood that the process may likewise by carried out be a variety of other processors and/or circuitry.
0069In the example of <figref idref="DRAWINGS">FIG. 4</figref>, texture unit <b>36</b> may receive texture data <b>40</b> (<b>120</b>). In some examples, texture unit <b>36</b> may be configured with hardware to fetch texture data <b>40</b> from graphics memory <b>42</b>. Texture data <b>40</b> may include arrays of texels of a variety of colorspaces. Texture unit <b>36</b> may, in some instances, also perform filtering operations (<b>122</b>). For example, texture unit <b>36</b> may perform bilinear filtering, trilinear filtering, or any other filtering operations to filter texture data <b>40</b>.
0070According to aspects of this disclosure, constant unit <b>38</b> of texture unit <b>36</b> may fetch one or more constants from a constant buffer (<b>124</b>). In addition, constant unit <b>38</b> may multiply texture data by the one or more constants (<b>126</b>). For example, constant unit <b>38</b> may leverage filtering logic of texture unit <b>36</b> to perform the multiplication. Texture unit <b>36</b> may then output the result of the multiplication (<b>128</b>). For example, texture unit <b>36</b> may output the result to a raster operations pipeline and bypass a shader pipe configured to receive texture data from texture unit <b>36</b>.
0071It should be understood that the techniques shown in <figref idref="DRAWINGS">FIG. 4</figref> are provided for purposes of illustration only. In other examples, the process may include more, fewer, or an alternative arrangement of steps than those show. For example, as described above, filtering operations may not be performed for all texture data.
0072In one or more examples, 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 may include computer data storage media or communication media including any medium that facilitates transfer of a computer program from one place to another. Data storage media may be any available media that can be accessed by one or more computers or one or more processors to retrieve instructions, code and/or data structures for implementation of the techniques described in this disclosure. 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 in the form of instructions or data structures and that can be accessed by a computer. 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.
0073The code may be executed by one or more processors, such as one or more digital signal processors (DSPs), general purpose microprocessors, application specific integrated circuits (ASICs), field programmable logic arrays (FPGAs), or other equivalent integrated or discrete logic circuitry. Accordingly, the term “processor” and “processing unit,” as used herein may refer to any of the foregoing structure or any other structure suitable for implementation of the techniques described herein. In addition, in some aspects, the functionality described herein may be provided within dedicated hardware and/or software modules configured for encoding and decoding, or incorporated in a combined codec. Also, the techniques could be fully implemented in one or more circuits or logic elements.
0074The techniques of this disclosure may be implemented in a wide variety of devices or apparatuses, including a wireless handset, an integrated circuit (IC) or a set of ICs (i.e., a chip set). Various components, modules or units are described in this disclosure to emphasize functional aspects of devices configured to perform the disclosed techniques, but do not necessarily require realization by different hardware units. Rather, as described above, various units may be combined in a codec hardware unit or provided by a collection of interoperative hardware units, including one or more processors as described above, in conjunction with suitable software and/or firmware.
0075Various aspects of the disclosure have been described. These and other embodiments are within the scope of the following claims.
Contents5
5 sheets
Sheet 1 Sheet 2 Sheet 3 Sheet 4 Sheet 5
Every citation, both ways
| Document | Relation | Office | Cited during |
|---|---|---|---|
| US2004075661A1 | Cites | United States of America | Search report |
| US2005259104A1 | Cites | United States of America | Search report |
| US2006028482A1 | Cites | United States of America | Search report |
| US2006125825A1 | Cites | United States of America | Search report |
| US2007279434A1 | Cites | United States of America | Search report |
| US2009147017A1 | Cites | United States of America | Search report |
| US2009251476A1 | Cites | United States of America | Search report |
| US2011025700A1 | Cites | United States of America | Applicant |
| US2014267318A1 | Cites | United States of America | Search report |
| US2015084975A1 | Cites | United States of America | Applicant |
| US2015228091A1 | Cites | United States of America | Applicant |
| US2015279090A1 | Cites | United States of America | Search report |
| US5886701A | Cites | United States of America | Search report |
| US6236413B1 | Cites | United States of America | Search report |
| US6366290B1 | Cites | United States of America | Applicant |
| US7274373B1 | Cites | United States of America | Applicant |
| US7486290B1 | Cites | United States of America | Search report |
| WO9641314A1 | Cites | World Intellectual Property Organization (WIPO) | Applicant |
| US20040075661A1 | Cites | United States of America | Search report |
| US20050259104A1 | Cites | United States of America | Search report |
| US20060028482A1 | Cites | United States of America | Search report |
| US20060125825A1 | Cites | United States of America | Search report |
| US20070279434A1 | Cites | United States of America | Search report |
| US20090147017A1 | Cites | United States of America | Search report |
| US20090251476A1 | Cites | United States of America | Search report |
| US20110025700A1 | Cites | United States of America | Applicant |
| US20140267318A1 | Cites | United States of America | Search report |
| US20150084975A1 | Cites | United States of America | Applicant |
| US20150228091A1 | Cites | United States of America | Applicant |
| US20150279090A1 | Cites | United States of America | Search report |
| Rakos, “Efficient Gaussian blur with linear sampling,” Sep. 2010, 17 pp. | Non-patent | – | Applicant |
| Steen, “Utilizing Texture Units for Image Processing”, May 2011, 27 pp. XP055222013, Retrieved from the Internet: URL: http://www.nvidia.de/content/PDF/isc-2011/Steen.pdf [retrieved on Oct. 19, 2015] Slide 3 Slides 6-7 Convolution filters. | Non-patent | – | Applicant |
| Ewins J.P., et al., “Implementing an Anisotropic Texture Filter”, Computers and Graphics, Elsevier, GB, vol. 24, No. 2, Apr. 1, 2000 (Apr. 1, 2000), XP004236371, pp. 253-267. | Non-patent | – | Applicant |
| Ewins J.P., et al., “MIP-MAP Level Selection for Texture Mapping”, IEEE Transactionson Visualization and Computer Graphics, IEEE Service Center, Los Alamitos, CA, US, vol. 4, No. 4, Oct. 1, 1998 (Oct. 1, 1998), XP000831199, pp. 317-329. | Non-patent | – | Applicant |
| International Search Report and Written Opinion—PCT/US2017/021628—ISA/EPO—dated May 15, 2017. | Non-patent | – | Applicant |
| Kilgariff E., et al., “The GeForce 6 Series GPU Architecture”, 20050731-20050804, Jul. 31, 2005 (Jul. 31, 2005), XP058318201, pp. 29-es. | Non-patent | – | Applicant |
| Knittel G., et al., “Hardware for Superior Texture Performance”, Computers and Graphics, Elsevier, GB, vol. 20, No. 4, Jul. 1, 1996 (Jul. 1, 1996), XP004025141, pp. 475-481. | Non-patent | – | Applicant |
| Nam B-G., et al., “Development of a 3-D Graphics Rendering Engine with Lighting Acceleration for Handheld Multimedia Systems”, IEEE Transactions on Consumer Electronics, IEEE USA, vol. 51, No. 3, Aug. 2005 (Aug. 2005), XP002769836, pp. 1020-1027. | Non-patent | – | Applicant |
| Response to Written Opinion dated May 15, 2017, from International Application No. PCT/US2017/021628, filed on Feb. 27, 2018, 18 pp. | Non-patent | – | Applicant |
| “Sampler Object,” Khronos.org, accessed from https://www.khronos.org/opengl/wiki/Sampler_Object, last edited Sep. 19, 2017, 7 pp. | Non-patent | – | Applicant |
| Second Written Opinion from International Application No. PCT/US2017/021628, dated Mar. 29, 2018, 4 pp. | Non-patent | – | Applicant |
| Rakos, “Efficient Gaussian blur with linear sampling,” Sep. 2010, 17 pp. | Non-patent | – | Applicant |
| Steen, “Utilizing Texture Units for Image Processing”, May 2011, 27 pp. XP055222013, Retrieved from the Internet: URL: http://www.nvidia.de/content/PDF/isc-2011/Steen.pdf [retrieved on Oct. 19, 2015] Slide 3 Slides 6-7 Convolution filters. | Non-patent | – | Applicant |
| EWINS, J.P. WALLER, M.D. WHITE, M. LISTER, P.F.: "Implementing an anisotropic texture filter", COMPUTERS AND GRAPHICS., ELSEVIER., GB, vol. 24, no. 2, 1 April 2000 (2000-04-01), GB, pages 253 - 267, XP004236371, ISSN: 0097-8493, DOI: 10.1016/S0097-8493(99)00159-4 | Non-patent | – | Applicant |
| EWINS J. P., ET AL.: "MIP-MAP LEVEL SELECTION FOR TEXTURE MAPPING.", IEEE TRANSACTIONS ON VISUALIZATION AND COMPUTER GRAPHICS., IEEE SERVICE CENTER, LOS ALAMITOS, CA., US, vol. 04., no. 04., 1 October 1998 (1998-10-01), US, pages 317 - 329., XP000831199, ISSN: 1077-2626, DOI: 10.1109/2945.765326 | Non-patent | – | Applicant |
| International Search Report and Written Opinion—PCT/US2017/021628—ISA/EPO—dated May 15, 2017. | Non-patent | – | Applicant |
| Kilgariff E., et al., “The GeForce 6 Series GPU Architecture”, 20050731-20050804, Jul. 31, 2005 (Jul. 31, 2005), XP058318201, pp. 29-es. | Non-patent | – | Applicant |
| KNITTEL, G. SCHILLING, A. KUGLER, A. STRA@?ER, W.: "Hardware for superior texture performance", COMPUTERS AND GRAPHICS., ELSEVIER., GB, vol. 20, no. 4, 1 July 1996 (1996-07-01), GB, pages 475 - 481, XP004025141, ISSN: 0097-8493, DOI: 10.1016/0097-8493(96)00019-2 | Non-patent | – | Applicant |
| BYEONG-GYU NAM ET AL: "Development of a 3-D graphics rendering engine with lighting acceleration for handheld multimedia systems", IEEE TRANSACTIONS ON CONSUMER ELECTRONICS, IEEE SERVICE CENTER, NEW YORK, NY, US, vol. 51, no. 3, 1 August 2005 (2005-08-01), NEW YORK, NY, US, pages 1020 - 1027, XP002769836, ISSN: 0098-3063, DOI: 10.1109/TCE.2005.1510517 | Non-patent | – | Applicant |
| Response to Written Opinion dated May 15, 2017, from International Application No. PCT/US2017/021628, filed on Feb. 27, 2018, 18 pp. | Non-patent | – | Applicant |
| “Sampler Object,” Khronos.org, accessed from https://www.khronos.org/opengl/wiki/Sampler_Object, last edited Sep. 19, 2017, 7 pp. | Non-patent | – | Applicant |
| Second Written Opinion from International Application No. PCT/US2017/021628, dated Mar. 29, 2018, 4 pp. | Non-patent | – | Applicant |
5 members in 4 offices; this record represents the family
Priority claims2
| Document | Office | Kind | Date |
|---|---|---|---|
| 201615141519 | United States of America | A | |
| US201615141519 | – | – | – |
Members5
| Document | Office | Kind | |
|---|---|---|---|
| US2017316540A1 | United States of America | A1 | |
| WO2017189105A1 | World Intellectual Property Organization (WIPO) | A1 | |
| US10089708B2This record | United States of America | B2 | |
| CN109074673A | China | A | |
| EP3449467A1 | European Patent Office (EPO) | A1 |
82 transactions on the USPTO file
Allowed after 3 non-final rejections, 1 final rejection and 1 RCE.
- Non-final rejections
- 3
- Final rejections
- 1
- RCEs
- 1
- Appeals
- 0
Over time
Point at a mark for the transactionTransactions
| Event | Code | |
|---|---|---|
| Payment of Maintenance Fee, 4th Year, Large EntityM1551 | M1551 | |
| Recordation of Patent Grant MailedPGM/ | PGM/ | |
| Patent Issue Date Used in PTA CalculationAllowedPTAC | PTAC | |
| Email NotificationEML_NTR | EML_NTR | |
| Issue Notification MailedAllowedWPIR | WPIR | |
| Dispatch to FDCD1935 | D1935 | |
| Application Is Considered Ready for IssuePILS | PILS | |
| Issue Fee Payment VerifiedN084 | N084 | |
| Issue Fee Payment ReceivedIFEE | IFEE | |
| Electronic ReviewELC_RVW | ELC_RVW | |
| Email NotificationEML_NTF | EML_NTF | |
| Mail Notice of AllowanceAllowedMN/=. | MN/=. | |
| Notice of Allowance Data Verification CompletedAllowedN/=. | N/=. | |
| Examiner's Amendment CommunicationEX.A | EX.A | |
| Information Disclosure Statement consideredIDSC | IDSC | |
| Date Forwarded to ExaminerFWDX | FWDX | |
| Electronic Information Disclosure StatementEIDS. | EIDS. | |
| Information Disclosure Statement (IDS) FiledWIDS | WIDS | |
| Mail Interview Summary - Applicant Initiated - TelephonicMEXAT | MEXAT | |
| Response after Non-Final ActionA... | A... | |
| Interview Summary - Applicant Initiated - TelephonicEXAT | EXAT | |
| Electronic ReviewELC_RVW | ELC_RVW | |
| Email NotificationEML_NTF | EML_NTF | |
| Mail Non-Final RejectionNon-final rejectionMCTNF | MCTNF | |
| Non-Final RejectionNon-final rejectionCTNF | CTNF | |
| Information Disclosure Statement consideredIDSC | IDSC | |
| Date Forwarded to ExaminerFWDX | FWDX | |
| Disposal for a RCE / CPA / R129AbandonedABN9 | ABN9 | |
| Information Disclosure Statement (IDS) FiledM844 | M844 | |
| Request for Continued Examination (RCE)RCEX | RCEX | |
| Information Disclosure Statement (IDS) FiledWIDS | WIDS | |
| Workflow - Request for RCE - BeginBRCE | BRCE | |
| Email NotificationEML_NTR | EML_NTR | |
| Mail Advisory Action (PTOL - 303)MCTAV | MCTAV | |
| Advisory Action (PTOL-303)CTAV | CTAV | |
| Date Forwarded to ExaminerFWDX | FWDX | |
| Response after Final ActionA.NE | A.NE | |
| Electronic ReviewELC_RVW | ELC_RVW | |
| Email NotificationEML_NTF | EML_NTF | |
| Mail Final Rejection (PTOL - 326)Final rejectionMCTFR | MCTFR | |
| Final RejectionFinal rejectionCTFR | CTFR | |
| Information Disclosure Statement consideredIDSC | IDSC | |
| Email NotificationEML_NTR | EML_NTR | |
| Application ready for PDX access by participating foreign officesCCRDY | CCRDY | |
| PG-Pub Issue NotificationPG-ISSUE | PG-ISSUE | |
| Date Forwarded to ExaminerFWDX | FWDX | |
| Response after Non-Final ActionA... | A... | |
| Mail Interview Summary - Applicant Initiated - TelephonicMEXAT | MEXAT | |
| Interview Summary - Applicant Initiated - TelephonicEXAT | EXAT | |
| Electronic request for Examiner InterviewM865E | M865E | |
| Electronic Information Disclosure StatementEIDS. | EIDS. | |
| Information Disclosure Statement (IDS) FiledWIDS | WIDS | |
| Electronic ReviewELC_RVW | ELC_RVW | |
| Email NotificationEML_NTF | EML_NTF | |
| Mail Non-Final RejectionNon-final rejectionMCTNF | MCTNF | |
| Non-Final RejectionNon-final rejectionCTNF | CTNF | |
| Date Forwarded to ExaminerFWDX | FWDX | |
| Response after Non-Final ActionA... | A... | |
| Mail Interview Summary - Applicant Initiated - TelephonicMEXAT | MEXAT | |
| Interview Summary - Applicant Initiated - TelephonicEXAT | EXAT | |
| Electronic ReviewELC_RVW | ELC_RVW | |
| Email NotificationEML_NTF | EML_NTF | |
| Mail Non-Final RejectionNon-final rejectionMCTNF | MCTNF | |
| Non-Final RejectionNon-final rejectionCTNF | CTNF | |
| Information Disclosure Statement consideredIDSC | IDSC | |
| Case Docketed to Examiner in GAUDOCK | DOCK | |
| Electronic Information Disclosure StatementEIDS. | EIDS. | |
| Information Disclosure Statement (IDS) FiledWIDS | WIDS | |
| Case Docketed to Examiner in GAUDOCK | DOCK | |
| Application Dispatched from OIPEOIPE | OIPE | |
| Email NotificationEML_NTR | EML_NTR | |
| Application Is Now CompleteCOMP | COMP | |
| Filing ReceiptFLRCPT.O | FLRCPT.O | |
| Sent to Classification ContractorPGPC | PGPC | |
| FITF set to YES - revise initial settingFTFS | FTFS | |
| Patent Term Adjustment - Ready for ExaminationPTA.RFE | PTA.RFE | |
| Cleared by OIPE CSRL194 | L194 | |
| IFW Scan & PACR Auto Security ReviewSCAN | SCAN | |
| PTO/SB/69-Authorize EPO Access to Search ResultsSREXR141 | SREXR141 | |
| Applicants have given acceptable permission for participating foreignAPPERMS | APPERMS | |
| Entity Status Set To Undiscounted (Initial Default Setting or Status Change)BIG. | BIG. | |
| Initial Exam Team nnIEXX | IEXX |
4 legal events, as the office reported them to INPADOC
Over the term
Point at a mark for the eventEvents
| Event | Code | |
|---|---|---|
| Maintenance fee paymentMAFP | MAFP | |
| Maintenance fee paymentMAFP | MAFP | |
| Information on status: patent grantGrantedPATENTED CASESTCF | STCF | |
| AssignmentAS | AS |
Numbers
- Publication
- 10089708
- Publication, DOCDB
- 10089708
- Publication, EPODOC
- US10089708
- Application
- 15141519
- Application, DOCDB
- 201615141519
- Application, EPODOC
- US201615141519
Titles
- English
- Constant multiplication with texture unit of graphics processing unit
Patent term adjustment
- Applicant delay
- −8 days
- Net adjustment
- 0 days
Classification
- CPC, 6
- G06T1/20
- G06T15/005
- G06T1/60
- G06T15/04
- G06T2200/28
- G06T15/80
- IPC, 5
- G06T15 80
- G06T15 04
- G06T1 20
- G06T1 60
- G06T15 00
- USPC, 1
- 345418000