Texture filtering with dynamic dispatching

Abstract

The present disclosure relates to texture filtering with dynamic scheduling. A texture filtering unit is described that includes a data path block and a control block. The data path block includes one or more parallel compute pipelines, each pipeline containing at least one hardware logic component configured to receive a plurality of inputs and generate an output value as part of a texture filtering operation. The control block includes a plurality of sequencers and an arbiter. Each sequencer executes a microprogram that defines a sequence of operations to be performed by one or more pipelines in the data path block as part of the texture filtering operation, and the arbiter controls access by the sequencers to one or more pipelines in the data path based on predefined priority rules.

Description

[0001] This application is a divisional application of the application filed on April 2, 2019, with application number 201910260593.8 and invention title "Texture Filtering with Dynamic Scheduling". Technical Field

[0002] This disclosure relates to texture filtering with dynamic scheduling. background In 3D computer graphics, much information contained within a scene is encoded as surface properties of 3D geometry. Therefore, texture mapping, as an efficient technique for encoding this information into bitmaps, is a major part of the image rendering process. Reading directly from a texture often does not provide satisfactory image quality because the projection of 3D geometry typically requires some form of resampling, and thus, as part of rendering the scene, the graphics processing unit (GPU) performs texture filtering. For example, this might be because the pixel center (in the rendered scene) is not aligned with the texel center in the texture (where the texture comprises an array of texels, such that texels in the texture resemble pixels in the image), and in different cases, pixels can be larger or smaller than texels.

[0003] There are many different methods for texture filtering, including volumetric filtering, anisotropic filtering, and trilinear filtering, and these methods can be applied in various combinations in various examples. Filtering can be a computationally intensive operation, and the hardware required to implement it can be substantial.

[0004] The embodiments described below are provided as examples only and are not intended to limit the implementation of any or all of the shortcomings of known methods for implementing texture filtering in hardware.

[0005] Overview This overview is provided to introduce, in a simplified form, the selection of concepts that will be further described in the detailed description below. This overview is not intended to identify key or essential features of the claimed subject matter, nor is it intended to limit the scope of the claimed subject matter.

[0006] A texture filtering unit is described, comprising a data path block and a control block. The data path block includes one or more computation pipelines (and in various examples, a plurality of parallel computation pipelines), each containing at least one hardware logic unit configured to receive multiple inputs and generate output values ​​as part of a texture filtering operation. The control block includes multiple sequencers and an arbiter. Each sequencer executes a microprogram that defines a sequence of operations performed by one or more pipelines in the data path block as part of the texture filtering operation, and the arbiter controls the sequencer's access to one or more pipelines in the data path based on predefined priority rules.

[0007] A first aspect provides a graphics processing unit including a texture filtering unit implemented in hardware logic, the texture filtering unit comprising: a plurality of inputs arranged to receive one or more texture values ​​and a plurality of filter coefficients, the plurality of filter coefficients including coefficients associated with a plurality of different texture filtering methods; a data path block including one or more computation pipelines, each pipeline containing at least one hardware logic component configured to receive a plurality of inputs and generate output values ​​as part of a texture filtering operation; and a control block including a plurality of sequencers and an arbitrator, wherein each sequencer includes a plurality of hard-coded microprograms and hardware logic arranged to select one of the microprograms based on one or more control inputs, wherein each microprogram defines a sequence of operations performed by the pipelines in the data path block as part of a texture filtering operation, and different microprograms implement different combinations of texture filtering methods, and wherein the arbitrator includes hardware logic arranged to control the sequencer's access to the computation pipelines according to priority rules.

[0008] The second aspect provides a method for texture filtering within a GPU, the GPU including a texture filtering unit, and the texture filtering unit including a data path block and a control block, the data path block including one or more computation pipelines, and the control block including multiple sequencers and an arbitrator, the method comprising: selecting a microprogram in each sequencer based on one or more control inputs, wherein the microprogram defines a sequence of operations performed by the pipelines in the data path block as part of a texture filtering operation, and different microprograms implement different combinations of texture filtering methods; executing the selected microprogram in each sequencer and sending a sequence of requests for accessing one of the pipelines in the data path block to the arbitrator, each request corresponding to an operation in the sequence defined by the selected microprogram; and in the arbitrator, assigning a pipeline in the data path block to one of the sequencers based on the received requests and priority rules.

[0009] The texture filtering unit described herein can be embodied in hardware on an integrated circuit. A method for manufacturing the texture filtering unit at an integrated circuit manufacturing system can be provided. An integrated circuit definition dataset can be provided, which, when processed in an integrated circuit manufacturing system, configures the system to manufacture the texture filtering unit. A non-transitory computer-readable storage medium can be provided, on which a computer-readable description of the integrated circuit is stored, which, when processed, causes a layout processing system to generate a circuit layout description used in the integrated circuit manufacturing system for manufacturing the texture filtering unit.

[0010] An integrated circuit manufacturing system may be provided, comprising: a non-transitory computer-readable storage medium storing a computer-readable integrated circuit description describing a texture filtering unit thereon; a layout processing system configured to process the integrated circuit description to generate a circuit layout description of the integrated circuit embodying the texture filtering unit; and an integrated circuit generation system configured to manufacture the texture filtering unit according to the circuit layout description.

[0011] Computer program code for performing any of the methods described herein may be provided. A non-transitory computer-readable storage medium having computer-readable instructions stored thereon may be provided, which, when executed at a computer system, cause the computer system to perform any of the methods described herein.

[0012] As will be apparent to those skilled in the art, the above features can be combined as appropriate, and can be combined with any aspect of the examples described herein. Attached Figure Description

[0013] The example will now be described in detail with reference to the accompanying drawings, in which: Figure 1 This is a schematic diagram of an example graphics processing unit (GPU) pipeline; Figure 2 This is a schematic diagram of the first example texture filtering unit; Figure 3A , Figure 3B and Figure 3C Graphical representations of three different texture filtering operations that can be implemented by the texture filtering unit as described herein are shown; Figure 4 This is a schematic diagram of the second example texture filtering unit; Figure 5 yes Figure 2 or Figure 4 A flowchart illustrating an example method for the operation of the control block within a texture filtering unit; Figure 6 A computer system in which a texture filtering unit as described herein is implemented is shown; and Figure 7 An integrated circuit manufacturing system for generating integrated circuits embodying texture filtering units as described herein is shown.

[0014] The accompanying drawings illustrate various examples. Those skilled in the art will recognize that the element boundaries shown in the figures (e.g., boxes, groups of boxes, or other shapes) represent one example of a boundary. In some examples, it is possible that one element can be designed as multiple elements, or multiple elements can be designed as one element. Where appropriate, common reference numerals are used throughout the drawings to indicate similar features. Detailed description The following description is presented by way of example to enable those skilled in the art to make and use the invention. The invention is not limited to the embodiments described herein, and various modifications to the disclosed embodiments will be apparent to those skilled in the art.

[0015] The embodiments will now be described by way of example only.

[0016] Texture filtering is implemented in dedicated hardware within the GPU, and as mentioned above, texture filtering is a computationally intensive operation, thus this hardware can be quite large. To increase hardware throughput, efficient hardware utilization is crucial; however, scheduling the different parts of the filtering operation can be very complex, and therefore, in known systems, scheduling is done manually.

[0017] This paper describes a texture filtering unit comprising a data path portion and a control portion, which can be implemented within a GPU. In various examples, the data path portion comprises multiple independent computation pipelines, each receiving multiple inputs and generating output values ​​as part of the texture filtering operation. In other examples, the data path portion may include a single computation pipeline. The control portion controls access to the computation pipelines and uses multiple non-programmable sequencers and arbitrators to perform dynamic scheduling. The control portion may additionally pass data transaction protocols to and from the texture filtering unit.

[0018] Each filtering operation typically involves multiple computations, thus requiring the same pipeline to be used multiple times and / or multiple pipelines to be used. Therefore, the output generated by the computational pipeline can be an intermediate value that requires further processing (by one of the computational pipelines), or it can be the final output of the texture filtering operation. Each texture value input to the texture filtering unit (and thus the input to the texture filtering operation) contributes only to a single output (i.e., the value of a single filter); however, multiple inputs typically contribute to each output, and depending on whether interleaving is used, these inputs are not necessarily received immediately after each other.

[0019] Each sequencer operates on one of a set of predefined, hard-coded operating modes, where a particular mode is selected at any given time based on one or more control inputs. Each hard-coded operating mode involves a different combination of filtering methods and defines a sequence of operations performed on a set of input data to produce the final output of the texture filtering operation. An arbitrator controls which sequencer has the right to access each of the computation pipelines at any given time, based on predefined rules. This may cause individual sequencers to stall, but the computation pipeline does not. This increases hardware efficiency and throughput without requiring additional pipelines in the data path (e.g., no dedicated pipelines for each operating mode or for each sequencer). The throughput advantage can be particularly pronounced when switching between operating modes, as manually optimizing the transitions between sequences in a known system is impractical. Using sequencers and arbitrators in this way also provides the ability to handle interleaved signals (e.g., for each color change in an image) and is flexible (e.g., because utilization is not significantly reduced if three color changes are computed instead of four). The ability to support serial and interleaved modes also reduces the FIFO's need for external multiplexers or serial inputs to the texture filtering unit.

[0020] Figure 1 A schematic diagram of an example graphics processing unit (GPU) pipeline 100 is shown, which can be implemented in hardware within the GPU and includes a texture filtering unit 102. Figure 1As shown, pipeline 100 includes a geometry processing stage 104 and a rasterization stage 106. Data generated by geometry processing stage 104 can be directly passed to rasterization stage 106, and / or some data can be written by geometry processing stage 104 to memory (e.g., parameter memory). Figure 1 (not shown in the image), and then read from memory by the rasterization stage 106.

[0021] The geometry processing stage 104 includes a vertex shader 108 and a tessellation unit 110. In various examples, it may also include a tiling unit. Figure 1 (Not shown in the image). Between vertex shader 108 and tessellation unit (or tessellation unit) 110, there may be one or more optional hull shaders. Figure 1 (Not shown in the image). The geometry processing stage 104 may also include... Figure 1 Other elements not shown, such as memory and / or other elements.

[0022] Vertex shader 108 is responsible for performing per-vertex computations. Unlike the vertex shader, hardware tessellation unit 110 (and any optional shell shader) computes per-patch rather than per-vertex. Tessellation unit 110 outputs primitives.

[0023] Rasterization stage 106 renders some or all of the primitives generated by geometry processing stage 104. Rasterization stage 106 includes a texture filtering unit 102, a pixel shader 112, and may include... Figure 1 Other components not shown. The structure and operation of the texture filtering unit 102 will be described in detail below.

[0024] Figure 2 This is a schematic diagram of the first example texture filtering unit 200, which can be implemented as follows: Figure 1 The texture filtering unit 102 in the pipeline 100. For example... Figure 2As shown, the texture filtering unit 200 includes several inputs, including multiple filter coefficients 202 and two texture value inputs: INPUT 0 204 and INPUT 1 206. These texture values ​​204, 206 are input data that are filtered in a filtering operation performed by the texture filtering unit, and the exact filtering operation performed is specified at least in part by the filter coefficients 202. In various examples, the texture filtering unit 200 may receive one texture value per clock cycle (via INPUT0 or INPUT 1); however, in other examples, the texture filtering unit may be configured to receive two or more texture values ​​per clock cycle (e.g., four texture values ​​per clock cycle), and in cases where more than two texture values ​​are input in a single clock cycle, the texture filtering unit 200 may include additional inputs for this purpose. Figure 2 (Not shown in the image). The received texture values ​​(e.g., which may be the result of bilinear filtering) are typically floating-point values ​​(e.g., a full-precision binary floating-point format that may be referred to as F32); however, the hardware and methods described herein can be used with texture values ​​in any format (e.g., half-precision binary floating-point format (F16) or integer format).

[0025] The texture filtering unit 200 also includes a control block 208 and a data path block 210. The control block 208 includes multiple sequencers 212, arbitrators 214, and multiplexers 216. In various examples, such as... Figure 2 As shown, data path block 210 may include four identical sequencers 212. In other examples, there may be a different number of sequencers. Data path block 210 includes multiple parallel, independent pipelines 218-219 and a set of scratchpad registers 220 for each sequencer 212 (e.g., in...). Figure 2 In the example shown, there are four sets of temporary registers (one for each sequencer). In various examples, each set of temporary registers 220 may include five or six registers. In other examples, there may be a different number of registers in each set of temporary registers 220, and in some examples, the temporary registers 220 may be replaced by alternative memory structures (e.g., FIFOs or other memories) configured to have similar functionality.

[0026] Data path block 210 also includes one or more multiplexers 222-223 that control where intermediate values ​​are stored. Specifically, the first multiplexer 222 (which may be referred to as a storage multiplexer) controls where the intermediate values ​​are stored (i.e., in which set of temporary registers 220), and the second multiplexer 223 (which may be referred to as a source multiplexer) controls what value (whether an input value or an intermediate value) is input to each of pipelines 218-219. In other examples, multiplexers 222-223 may be replaced by alternative logic that performs similar switching and / or selection functions. Figure 2 In the example shown, the operation of these multiplexers 222-223 is controlled by control block 208, for example, as controlled by... Figure 2 The control lines shown are from arbitrator 214 via multiplexer 216 to multiplexers 222-223 and pipeline 218. In various examples, arbitrator 214 selects the sequencer instruction to be executed and sends the instruction to its storage destination in parallel with computation via the pipeline. The arbitrator then controls the multiplexing and write-enable of the temporary registers. However, in other examples, the control of multiplexers 222-223 can be implemented as a separate pipeline, FIFO, or other state machine.

[0027] Although Figure 2 Various signal lines are shown, but each signal line can represent multiple signals, and there can be... Figure 2 Additional signals not shown in the diagram, and Figure 4 Another example is shown.

[0028] Texture filtering unit 200 takes multiple texture values ​​as input (via inputs 204, 206) and, under the control of control block 208, generates a single filtered output in data path block 210 (which is output via output terminal 224). Filtering is implemented by computational logic blocks within pipelines 218-219, and these computational logic blocks can be, for example, addition units, multipliers, or two-dimensional dot product units (DP2, which, given four inputs a, b, c, d, outputs ac + bd, and also allows efficient computation of (c - 1)). a+c b) Three-input addition, fused multiplication and addition (FMA), etc. Figure 2In the example shown, the first pipeline (pipeline 0) 218 ​​includes a single DP2, and the second pipeline (pipeline 1) 219 includes a single addition unit. In other examples, pipelines may include additional and / or different computational logic blocks (e.g., the first pipeline 218 may include a multiplier instead of DP2, or either pipeline may include a second or additional computational logic block). A single texture filtering operation may require several passes through one or both of pipelines 218-219 (as described in more detail below), and intermediate results (i.e., results whose pipeline output is not the final filtered output value) are stored in temporary registers 220 for the corresponding sequencers (i.e., the sequencers that control the pipelines when intermediate results are generated). These intermediate results can then be input from temporary registers 220 to one of pipelines 218-219 as input for subsequent pipeline passes. In various examples, the final filtered output value can also be stored in temporary register 220 (e.g., when the final filtered output value cannot yet be sent to the output, but the texture filtering unit wants to continue further computation without delay). Then, when these stored final filtered output values ​​can be output but bypass computational logic blocks (e.g., DP2), they are piped back. This ability to store the final filtered output value significantly improves performance when alternating between simple and complex filtering functions (e.g., between Aniso-2 and Aniso-16).

[0029] In various examples, the texture filtering unit 200 is arranged to perform any combination of volumetric filtering, anisotropic filtering, and trilinear filtering using pipelines 218-219; however, in other examples, the texture filtering unit 200 is arranged to perform any combination of different sets of two or more filtering methods, and can perform any kind of linear filtering, and bilinear filtering can also be performed in various examples. Therefore, the coefficients 202 input to the texture filtering unit 200 include at least one coefficient for each filtering method that the texture filtering unit 200 can implement, such as vfrac, afrac, and tfrac (collectively referred to as...). (frac), where vfrac is the coefficient for volumetric filtering, afrac is the coefficient for anisotropic filtering, and tfrac is the coefficient for trilinear filtering. In various examples, the values ​​of the coefficients may change every clock cycle, or may change less frequently, or may be constant (e.g., vfrac may change every clock cycle, afrac may change less frequently, and tfrac may be constant). When only an appropriate subset of the filtering methods is used, the coefficients of those unused methods may be set to default values ​​(e.g., in the case of no anisotropic filtering, the coefficient afrac may be set to one), or a separate enable signal 203 may be provided.

[0030] In the example of providing enable signals 203, these signals may have values ​​specifying whether each filtering method (or mode) is enabled, as well as any necessary parameters for that filtering method (e.g., anisotropic filtering mode). For example, as described in detail below, three enable signals may be provided, although certain combinations (e.g., {0,0,0}) may not be allowed or may have special meanings (e.g., causing an input to the output to be bypassed): Texture filtering unit 200 is arranged to perform filtering using one or more arbitrary combinations of a set of filtering methods, and as described above, this can involve computation using multiple input texture values ​​and multiple passes through one or two of pipelines 218-219 (each pass using a different input value, where the input value can be an input texture value or an intermediate value calculated in a previous pass through the pipeline). An example of a texture filtering operation is shown below. Figures 3A-3C As shown.

[0031] Figure 3A A graphical representation of the operations performed when texture filtering is combined with volumetric filtering and anisotropy-2 (e.g., where vol_en=1 and ani_rt=1) is shown. In this example, volumetric interpolation is first performed using two consecutive operations in the first pipeline 218, including DP2 (block 302, i.e., passing through the first pipeline 218 twice), and then DP2 is again used for anisotropic multiplication and final addition (block 304, i.e., passing through the first pipeline 218 a third time). If trilinear filtering is also used (e.g., where vol_en=1, tri_en=1 and ani_rt=1), DP2 can again be used for trilinear interpolation (block 306, i.e., passing through the first pipeline 218 a fourth time). The total number of inputs is given by: Therefore, if only volume filtering and anisotropy-2 filtering are used, there are only 4 inputs (2... 2 1=4), while if trilinear filtering is also used, there are 8 inputs (2 2 2=8). In this example, it can be seen that the second pipeline 219 is not used at all. With two inputs per input transaction, the number of transactions is given by dividing the number of inputs by 2, and Figures 3A-3C The numbers at the top of the diagram showing the order of operations refer to these transactions, not the inputs.

[0032] Figure 3B A graphical representation of the operations performed when texture filtering involves anisotropy -4+ is shown, where this refers to all anisotropic modes starting from 4 (e.g., where vol_en=0 and ani_rt>1), and Figure 3B The square brackets surrounding the input transactions indicate those patterns that will not occur for anisotropy-4. In this example, a second pipeline 219, including an addition unit, is used to process all 16 input texture values ​​(1) in two groups of consecutive 1×8 operations. 16 Summing is performed using 1=16 (block 312, i.e., 8 passes through the second pipeline 219). In Figure 3B In the example shown, before the first pipeline 218 (including DP2) is used for anisotropic multiplication and final addition (block 316, i.e., through the first pipeline 218, and different anisotropic coefficients can be used, for example, so DP2 is used), the group (0-6) is then accumulated using multiple operations utilizing the second pipeline 219 (block 314, i.e., through the second pipeline 219 6 more times) as: ((((0+1)+4)+6)+((2+3)+5)). If trilinear filtering is also used (e.g., where vol_en=0, tri_en=1 and ani_rt=15), DP2 can again be used for trilinear interpolation (block 306, i.e., through the first pipeline 218 a second time), and the total number of input texture values ​​used is 32 (1 16 2=32). It will be recognized that... Figure 3B The grouping of the input shown is just one example, and other examples may accumulate the grouping in different ways.

[0033] Figure 3C This illustrates a graphical representation of the operations performed when texture filtering involves volumetric filtering and anisotropy-4+ (e.g., where vol_en=1 and ani_rt=15, such that 2...). 16 1 = 32 inputs, although compared to Figure 3B Similar to the middle, Figure 3CThe square brackets surrounding the input transactions indicate those patterns that will not occur for anisotropy-4. In this example, volume interpolation is first performed using multiple consecutive operations of the first pipeline 218, including DP2 (block 302, i.e., 16 passes through the first pipeline 218), and then, in this example, the anisotropic inputs (0-13) are accumulated using multiple consecutive operations of the second pipeline 219, including the addition unit (block 312, i.e., 13 passes through the second pipeline 219): ((((((0+1)+4)+6)+8)+10)+12)+((((((2+3)+5)+7)+9)+11)+13)).

[0034] As mentioned above, Figure 3C The accumulation order shown is for illustrative purposes only and other orders may be used alternatively. The aniso_last inputs (14-15) are added together (block 322, i.e., passing through the second pipeline 219 again), and then the first pipeline 218 (including DP2) is used for anisotropic multiplication and final addition (block 316, i.e., passing through the first pipeline 218 once). If trilinear filtering is also used (e.g., where vol_en=1, tri_en=1, and ani_rt=15), DP2 can again be used for trilinear interpolation (block 306, i.e., passing through the first pipeline 218 again), and the total number of input texture values ​​used is 64 (2 16 2=64).

[0035] It can be seen that, Figures 3A-3C The filtering operation does not involve floating-point accumulation. By constructing the operation in this way, latency is reduced because there is no need to wait for the result to become available before more input can be processed.

[0036] The order in which input values ​​and / or intermediate values ​​are input into each of the pipelines (e.g., to achieve...) Figures 3A-3C(Any of the texture filtering operations shown) is controlled by control block 208. As described above, each sequencer 212 operates on one of a set of predefined and hard-coded operation modes, where the selected mode defines a filtering operation applied to a stream of input texture values ​​or multiple interleaved streams of input texture values. The sequencer's selection of the operation mode depends on enable signal 203 (which may be referred to as control input or mode input). Each of the hard-coded operation modes is defined in microprogram (or microcode) 226, which is non-programmable and synthesized into hardware, and includes a state machine running on stored functions, a program counter 227, and a loop counter in various programs (in some examples) (e.g., if the same microprogram 226 is shared between multiple modes and the loop is not flat, then the program counter will jump backward during the loop). The microprogram defines a sequence of operations to be performed on a set of input data to generate the final output of the texture filtering operation. Any jumps in the microprogram depend only on the control input, not on the texture values ​​themselves. However, there may be some limited exceptions to this in various examples. For instance, there may be multiple predefined input texture values ​​that stop the computation sequence and trigger the output of the input texture values. In various examples, the mode input for the jump in the control program can be one of the enable signal 203 or ani_rt (i.e., the anisotropy ratio, as described above). Therefore, different microprograms can be provided to implement this. Figures 3A-3C Each of the filtering operations shown, and in various examples, each scheduler can be the same, that is, it can include the same set of microprograms, and in various examples there can be 5 or 7 microprograms (and thus, the mode of operation), each microprogram being associated with a different combination of filtering methods.

[0037] As described herein, the use of microprograms reduces the complexity of the sequencer 212's behavior (e.g., compared to attempting to optimize a sequence of all interleaved patterns and having smooth transitions between patterns), and thus reduces the sequencer's size (e.g., in terms of hardware logic area). By enabling jumps within microprograms based on control inputs, the number of microprograms within each sequencer is reduced, and therefore the area of ​​each sequencer is reduced. While all sequencers are described as identical above, in other examples, the size of the sequencer can be further reduced by having different subsets of microprograms within different sequencers.

[0038] In various examples, microprogram 226 is written such that all store instructions are pipelined within data path 210 (e.g., such that the “instruction packet” entering data path 210 contains the destination of the computation result, such as the location in scratch register 220). This allows a single sequencer to be stopped when resources are unavailable without having to stop the data path (unless something downstream of the texture filtering unit is stopped). To prevent hazard, the microprogram does not issue a store command to the scratch register before the last read of the scratch register, and the microprogram explicitly includes the necessary delays. Furthermore, the microprogram includes the necessary delays when reading intermediate values ​​to ensure that the intermediate values ​​have been written to scratch register 220 before being read. Microprogram 226 can therefore be described as hazard-free.

[0039] like Figure 2 As shown, control block 208 includes multiple sequencers 212 (e.g., four sequencers), and the sequencers 212 have overlapping activities, meaning that more than one sequencer 212 may need to use the same pipeline simultaneously (e.g., two or more sequencers may need to use the first pipeline 218 or the second pipeline 219 simultaneously). The sequencers 212 therefore indicate their status to arbitrator 214 (e.g., in the form of a request to access resources, which include pipelines 218-219 and may also include output 224). Arbitrator 214 grants access to resources (e.g., pipelines 218-219) according to a fixed priority scheme (i.e., based on predefined rules). In various examples, arbitrator 214 prioritizes requests for resources involving new input texture values ​​(e.g., INPUT 0 204 or INPUT 1 206), or otherwise implements a fixed prioritization (e.g., a round-robin arbitration scheme or other prioritization scheme) among sequencers 212. Figure 2 As shown, arbitrator 214 controls access to resources in the data path via multiplexer 216 within control block 208. The output from multiplexer 216 includes control signals that control the operation of source multiplexer 223 in data path 210, and thus control which values ​​are input to each of pipelines 218-219 in any given clock cycle. In some examples, multiplexer 216 outputs multiple control signals to independently control the input to each of pipelines 218-219.

[0040] like Figures 3A-3C As shown, not all filtering operations use the same pipeline in the same order. Therefore, for example, if a sequencer performs operations on the first input stream of texture values ​​as follows: Figure 3A The first filtering operation shown only requests the use of the first pipeline 218, and executes... Figure 3B The second sequencer shown in the filtering operation primarily requests the use of the second pipeline 219. At the moment when both sequencers request the use of the first pipeline 218, the arbitrator 214 handles the operation being performed involving the new input texture (e.g., Figure 3A The sequencer in operation 302) is prioritized, and fixed priority among sequencers is implemented in other ways (e.g., as described above).

[0041] like Figures 3A-3C As shown, the final output is always generated by the DP2 operation, therefore, as Figure 2 As shown, the output from the first pipeline 218 is connected to the output 224 of the texture filtering unit 200, and the output from the second pipeline 219 is not connected, but is only connected to the multiplexer 222 that controls the storage of the temporary register 220. However, in other examples, where the texture filtering unit 200 performs a texture filtering operation in which the final operation is addition (as performed by the second pipeline 219), the output from the second pipeline 219 is additionally (or alternatively) connected to the output 224 of the texture filtering unit 200.

[0042] In examples where the final output is always generated by the DP2 operation (e.g., in cases like...), Figures 3A-3C In the example shown), arbitrator 214 can control the use of any microprogram (e.g., Figure 3A Block 304 or block 306 in Figure 3B and Figure 3C The order of output results is controlled by access to the first pipeline 218 of the final DP2 operation in block 316 or block 306, and in various examples, the operation can be prevented from starting (via arbitrator 214) if no output is ready. This means that no additional storage device is needed at output 224 (e.g., to store more than one result). However, in other examples, a storage device can be provided before output 224, and the final result can be stored in that storage device, and the final result can be output in the order controlled by control block 208, or, as mentioned above, the output can be stored in temporary register 220 (or temporary register) if no output is ready.

[0043] although Figure 2 The first pipeline 218 in the texture filtering unit 200 is shown to include DP2, but in other examples it may include a single multiplier unit. By using a multiplier instead of DP2, the size of the pipeline (e.g., the area of ​​the hardware) is reduced; however, the use of DP2 (or separate multipliers and adders that perform the same function) ensures that simple interpolation is completely accurate.

[0044] Figure 4 This is a schematic diagram of the second example texture filtering unit 400, which can be implemented as follows: Figure 1 The texture filtering unit 102 in the pipeline 100. This texture filtering unit 400 includes all the elements shown in the first example texture filtering unit 200 as described above, and additional signal streams (e.g., signals enabling sequencers to indicate what input they want, which input is the last, when they are idle, stop signals, etc.) and register levels (many of which may also appear in the first example texture filtering unit 200, but are only shown for clarity) are described below. Figure 2 (The text is omitted here), and also includes a main controller unit 402. In this example, the main controller 402 instructs any of the sequencers 212 when they can begin processing the filtering sequence (i.e., starting a new texture filtering operation by executing a microprogram) and which sequence the next input belongs to. Additionally, the main controller unit 402 tracks the order in which the sequencers should produce outputs, and thus ensures that outputs are generated from the texture filtering unit 400 in the correct order.

[0045] exist Figure 2 and Figure 4 In the example shown, data path 210 includes only a single DP2 and a single addition unit. In other examples, data path 210 may include different combinations of computational logic blocks. In many examples, the resources within the data path (i.e., the computational logic blocks within the data path) are limited, meaning the total throughput of the computational logic blocks within the pipeline is less than the throughput that the sequencer can request.

[0046] As described above, the sequencer can operate on either an input stream of texture values ​​or an interleaved stream of texture values. When using interleaving, inputs that contribute to the output of a single filter may not be received consecutively. The use of interleaved streams can be achieved by signaling the texture filtering units 102, 200, and 400 using an additional enable (or control) signal 203: Interleaving the input streams of texture values ​​can be used, where, for example, multiple texture values ​​(e.g., R and G values) are accessed from memory simultaneously, but need to be filtered individually (e.g., color filtering is performed separately for each color). This improves efficiency because texture values ​​for different streams (e.g., RGBA) can be stored contiguously, and by using interleaving, it avoids the need to deserialize the texture values ​​(which is expensive for long sequences).

[0047] In the above examples, texture filtering units 200 and 400 are arranged to implement any one or more of volumetric filtering, anisotropic filtering, and trilinear filtering. In another example, texture filtering units can be arranged to implement any combination of volumetric filtering, anisotropic filtering, trilinear filtering, and bilinear filtering (e.g., by changing the microprogram). To enable bilinear filtering without significantly reducing the final output rate, the number of inputs to the texture filtering units configured to receive texture values ​​can be increased (e.g., inputs 204 and 206), and the number of computation pipelines in the data path block can be increased (e.g., by adding multiple pipelines similar to the first pipeline 218, each including DP2 and additional temporary register entries).

[0048] Figure 5 yes Figure 2 or Figure 4 The flowchart illustrates an example method of the operation of control block 208 within texture filtering units 200, 400. As described above, each sequencer 212 selects microprogram 226 based on control input (e.g., based on enable signal 203) (block 502). Sequencer 212 then executes the selected microprogram and sends a request to arbitrator 214 for the use of data path resources (e.g., pipelines 218-219) (block 504). Arbitrator 214 allocates data path resources to sequencer 212 based on the request received from sequencer 212 and predefined priority rules (block 506). As described above, arbitrator 214 can prioritize those requests where new input texture values ​​will be input into the pipeline (i.e., for those requests involving only intermediate value processing), and a fixed prioritization scheme can then be applied among sequencers. Also as described above, arbitrator 214 can pre-allocate output slots (and thus, in various examples, the DP2 pipeline). If provided, the main controller 402 also controls which sequencer to start next.

[0049] In most cases, the hardware and methods described in this paper achieve high utilization of data path resources, such as pipelines and computational logic blocks. This is in contrast to known systems, which often suffer from unused logic, reduced performance, and / or more complex and difficult-to-maintain sequencing schemes. The hardware and methods described in this paper are self-organizing and result in utilization patterns that are difficult to predict precisely. The current complexity of optimizing systems for serial and interleaved sequences is avoided, and it is possible to guarantee that microprograms are risk-free without any significant performance degradation because the program becomes less intensive after processing the input and does not prevent other sequencers from processing the input.

[0050] In the context of texture filtering within a GPU, the techniques described above can also be used in other applications involving floating-point operations, which include the evaluation of a sum of multiple products (SOP) followed by an accumulation phase. In such examples, the texture filtering unit described above can be alternatively referred to as a computation unit, and the filter coefficients can be replaced by SOP coefficients. Examples of other applications include coordinate transformations, depth calculations, and some common shader calculations.

[0051] Another example describes a graphics processing unit comprising a computation unit implemented in hardware logic, the computation unit including: a plurality of inputs arranged to receive a plurality of SOP coefficients and one or more input values ​​per clock cycle, the plurality of SOP coefficients including coefficients associated with a plurality of different SOPs (e.g., to perform operations such as transformation or shading); a data path block comprising a plurality of parallel computation pipelines, each pipeline containing at least one hardware logic component configured to receive a plurality of inputs and generate output values ​​as part of SOP computation; and a control block comprising a plurality of sequencers and arbitrators, wherein each sequencer comprises a plurality of hard-coded microprograms and hardware logic arranged to select one of the microprograms based on one or more control inputs, wherein each microprogram defines a sequence of operations to be performed by the pipelines in the data path block as part of SOP computation, and different microprograms implement different SOPs, and wherein the arbitrator comprises hardware logic arranged to control the sequencer's access to the computation pipelines according to predefined priority rules.

[0052] Figure 6 A computer system 600 in which the graphics processing system described herein can be implemented is shown. The computer system includes a CPU 602, a GPU 604, a memory 606, and other devices 614 such as a display 616, a speaker 618, and a camera 620. A GPU pipeline 100 including texture filtering units as described above is implemented within the GPU 604. The components of the computer system can communicate with each other via a communication bus 622.

[0053] Figures 1-5 It is shown as comprising multiple functional blocks. This is merely illustrative and not intended to limit the strict division between the different logical elements of these entities. Each functional block may be provided in any suitable manner. It should be understood that the intermediate values ​​described herein as being formed by the texture filtering unit (or more specifically, the coefficient merging logic block within the texture filtering unit) do not need to be physically generated by hardware logic at any point, and may only represent logical values ​​that conveniently describe the processing performed by the texture filtering unit between its inputs and outputs.

[0054] The texture filtering unit described herein can be implemented in hardware on an integrated circuit. The texture filtering unit described herein can be configured to perform any of the methods described herein. Generally, any of the functions, methods, techniques, or components described above can be implemented in software, firmware, hardware (e.g., fixed logic circuitry), or any combination thereof. The terms “module,” “function,” “component,” “element,” “unit,” “block,” and “logic” are used herein to generally denote software, firmware, hardware, or any combination thereof. In the case of a software implementation, a module, function, component, element, unit, block, or logic represents program code that performs a specific task when executed on a processor. The algorithms and methods described herein can be executed by one or more processors that execute code that causes one or more processors to perform the algorithm / method. Examples of computer-readable storage media include random access memory (RAM), read-only memory (ROM), optical disk, flash memory, hard disk storage, and other memory devices that can store instructions or other data using magnetic, optical, or other technologies and can be accessed by a machine.

[0055] As used herein, the terms computer program code and computer-readable instructions refer to any type of executable code intended for a processor, including code expressed in machine language, interpreted language, or scripting language. Executable code includes binary code, machine code, bytecode, code defining integrated circuits (such as hardware description languages ​​or netlists), and code expressed in programming languages ​​such as C, Java, or OpenCL. Executable code can be, for example, any type of software, firmware, script, module, or library that, when properly executed, processed, interpreted, compiled, or run in a virtual machine or other software environment, causes the processor of a computer system that supports the executable code to perform the tasks specified by the code.

[0056] A processor, computer, or computer system can be any type of device, machine, or special-purpose circuit, or a collection or portion thereof, having processing capabilities that enable it to execute instructions. A processor can be any type of general-purpose or special-purpose processor, such as a CPU, GPU, system-on-a-chip, state machine, media processor, application-specific integrated circuit (ASIC), programmable logic array, field-programmable gate array (FPGA), physical processing unit (PPU), radio processing unit (RPU), digital signal processor (DSP), general-purpose processor (e.g., general-purpose GPU), microprocessor, any processing unit designed to accelerate tasks outside of a CPU, etc. A computer or computer system may include one or more processors. Those skilled in the art will recognize that such processing capabilities are incorporated into many different devices, and therefore the term "computer" includes set-top boxes, media players, digital radio devices, PCs, servers, mobile phones, personal digital assistants, and many other devices.

[0057] It is also intended to include software that defines the configuration of hardware as described herein, such as HDL (Hardware Description Language) software, for designing integrated circuits or configuring programmable chips to perform desired functions. That is, a computer-readable storage medium may be provided having computer-readable program code encoded thereon in the form of an integrated circuit definition dataset, which, when processed (i.e., run) in an integrated circuit manufacturing system, configures the system to manufacture texture filtering units configured to perform any of the methods described herein, or to manufacture texture filtering units including any of the devices described herein. The integrated circuit definition dataset may, for example, be an integrated circuit description.

[0058] Therefore, a method for manufacturing texture filtering units as described herein can be provided at an integrated circuit manufacturing system. Furthermore, an integrated circuit definition dataset can be provided, which, when processed in an integrated circuit manufacturing system, enables the method for manufacturing texture filtering units to be executed.

[0059] Integrated circuit definition datasets can be in the form of computer code, such as netlists or code for configuring programmable chips, hardware description languages ​​(including register-transfer level (RTL) code) defining integrated circuits at any level, high-level circuit representations such as Verilog or VHDL, and low-level circuit representations such as OASIS (RTM) and GDSII. Higher-level representations that logically define integrated circuits (such as RTL) can be processed at a computer system configured to generate a manufacturing definition of the integrated circuit within a software environment, including definitions of circuit elements and rules for combining these elements, to generate a manufacturing definition of the integrated circuit thus defined by that representation. If the software executes at the computer system to define the general state of the machine, one or more intermediate user steps (e.g., providing commands, variables, etc.) may be required for the computer system configured to generate the manufacturing definition of the integrated circuit to execute the code defining the integrated circuit, thereby generating the manufacturing definition of the integrated circuit.

[0060] Now refer to Figure 7 This describes an example of processing integrated circuit definition datasets at an integrated circuit manufacturing system in order to configure the system to manufacture texture filtering units.

[0061] Figure 7 An example of an integrated circuit (IC) manufacturing system 702 configured to manufacture texture filtering units (or GPUs incorporating texture filtering units as described in any of the examples herein) is shown. Specifically, the IC manufacturing system 702 includes a layout processing system 704 and an integrated circuit generation system 706. The IC manufacturing system 702 is configured to receive an IC definition dataset (e.g., defining texture filtering units as described in any of the examples herein), process the IC definition dataset, and generate an IC (e.g., embodying texture filtering units as described in any of the examples herein) based on the IC definition dataset. The processing of the IC definition dataset configures the IC manufacturing system 702 to manufacture integrated circuits embodying texture filtering units as described in any of the examples herein.

[0062] The layout processing system 704 is configured to receive and process an IC definition dataset to determine a circuit layout. Methods for determining a circuit layout based on an IC definition dataset are known in the art and may involve, for example, synthesizing RTL code to determine a gate-level representation of the circuit to be generated, for example, in terms of logic components (e.g., NAND, NOR, AND, OR, MUX, and FLIP-FLOP components). The circuit layout can be determined based on the gate-level representation of the circuit by determining the location information of the logic components. This can be done automatically or with user intervention to optimize the circuit layout. Once the layout processing system 704 has determined the circuit layout, it can output a circuit layout definition to the IC generation system 706. For example, the circuit layout definition may be a circuit layout description.

[0063] As is known in the art, IC generation system 706 generates ICs according to a circuit layout definition. For example, IC generation system 706 can implement a semiconductor device fabrication process to generate an IC, which may involve a multi-step sequence of photolithography and chemical processing steps during which electronic circuitry is progressively created on a wafer made of semiconductor material. The circuit layout definition may be in the form of a mask that can be used during the photolithography process to generate an IC according to the circuit definition. Alternatively, the circuit layout definition provided to IC generation system 706 may be in the form of computer-readable code, which IC generation system 706 can use to form an appropriate mask for use during IC generation.

[0064] Different processes performed by the IC manufacturing system 702 can all be implemented at one location, for example, by one party. Alternatively, the IC manufacturing system 702 can be a distributed system, such that some processes can be performed at different locations and by different parties. For example, some of the following stages can be performed at different locations and / or by different parties: (i) synthesizing RTL code representing an IC definition dataset to form a gate-level representation of the circuit to be generated; (ii) generating a circuit layout based on the gate-level representation; (iii) forming a mask according to the circuit layout; and (iv) manufacturing the integrated circuit using the mask.

[0065] In other examples, processing of an integrated circuit definition dataset at an integrated circuit manufacturing system can configure the system to manufacture texture filtering units without processing the IC definition dataset to determine circuit layout. For example, an IC definition dataset can define the configuration of a reconfigurable processor (e.g., an FPGA), and processing of that dataset can configure the IC manufacturing system to generate a reconfigurable processor with that defined configuration (e.g., by loading configuration data into the FPGA).

[0066] In some embodiments, when an integrated circuit manufacturing definition dataset is processed in an integrated circuit manufacturing system, the integrated circuit manufacturing system may enable the integrated circuit manufacturing system to generate devices as described herein. For example, the integrated circuit manufacturing system references the above... Figure 7 The configuration described herein, based on the integrated circuit manufacturing definition dataset, enables the manufacture of devices as described in this paper.

[0067] In some examples, the integrated circuit definition dataset may include software that runs on or in combination with hardware defined at the dataset. Figure 7 In the example shown, the IC generation system can also be configured by the integrated circuit definition dataset to load firmware onto the integrated circuit according to the program code defined at the integrated circuit definition dataset during the manufacturing of the integrated circuit, or otherwise provide program code to the integrated circuit for use with the integrated circuit.

[0068] Those skilled in the art will recognize that storage devices for storing program instructions can be distributed across a network. For example, a remote computer can store examples of processes described as software. A local or terminal computer can access the remote computer and download part or all of the software to run the program. Alternatively, a local computer can download fragments of software on demand, or execute some software instructions at a local terminal while executing others at a remote computer (or computer network). Those skilled in the art will also recognize that, by utilizing conventional techniques known to those skilled in the art, all or part of the software instructions can be executed by dedicated circuitry (e.g., DSPs, programmable logic arrays, etc.).

[0069] The methods described herein can be executed by a computer configured with software in a machine-readable form stored on a tangible storage medium. This software can be, for example, a computer program comprising computer-readable program code that configures the computer to perform the methods, or a computer program comprising computer program code suitable for performing all steps of any of the methods described herein when the program is run on a computer, and wherein the computer program can be embodied on a computer-readable storage medium. Examples of tangible (or non-transitory) storage media include disks, thumb drives, memory cards, etc., and do not include propagated signals. The software can be adapted to execute on a parallel or serial processor, such that the method steps can be executed in any suitable order or simultaneously.

[0070] The hardware components described herein can be generated from a non-transitory computer-readable storage medium on which computer-readable program code is encoded.

[0071] The memory storing machine-executable data used in implementing the disclosed aspects can be a non-transitory medium. A non-transitory medium can be volatile or non-volatile. Examples of volatile non-transitory media include semiconductor-based memories such as SRAM or DRAM. Examples of techniques that can be used to implement non-volatile memories include optical and magnetic memory technologies, flash memory, phase-change memory, and resistive RAM.

[0072] The specific reference to "logic" refers to a structure that performs one or more functions. Examples of logic include circuits arranged to perform these functions (one or more). For example, such circuits may include transistors and / or other hardware elements available during the manufacturing process. As an example, such transistors and / or other elements may be used to form circuits or structures that implement and / or include memory (e.g., registers, flip-flops, or latches), logic units (e.g., Boolean operations), mathematical units (e.g., adders, multipliers, or shifters), and interconnections. Such elements may be provided as custom circuits or standard cell libraries, macros, or at other levels of abstraction. Such elements may be interconnected in a particular arrangement. Logic may include fixed-function circuitry, and the circuitry may be programmed to perform one or more functions; such programming may be provided by firmware or software updates or control mechanisms. Logic identified as performing a function may also include logic that implements constituent functions or sub-processes. In the example, hardware logic has circuitry that implements fixed-function operations, or multiple operations, state machines, or processes.

[0073] When compared with known implementations, the implementation of the concepts set forth in this application in devices, apparatuses, modules, and / or systems (and in the methods implemented herein) can result in performance improvements. Performance improvements may include one or more of increased computational performance, reduced latency, increased throughput, and / or reduced power consumption. During the manufacture of such devices, apparatuses, modules, and systems (e.g., in integrated circuits), performance improvements may be traded off against physical implementation, thereby improving the manufacturing process. For example, performance improvements may be traded off against layout area to match the performance of known implementations but using less silicon. This can be accomplished, for example, by reusing functional blocks in a serialized manner or sharing functional blocks among units of the device, apparatus, module, and / or system. Conversely, the concepts set forth in this application may be traded off to produce improvements (such as reduced silicon area) in the physical implementation of the device, apparatus, module, and system for improved performance. This can be accomplished, for example, by manufacturing multiple instances of the module within a predetermined area budget.

[0074] As will be apparent to those skilled in the art, any range or device values ​​given herein can be extended or altered without losing the desired effect.

[0075] It will be understood that the benefits and advantages described above may apply to one embodiment or to several embodiments. The embodiments are not limited to those that solve any or all of the stated problems or have any or all of the stated benefits and advantages.

[0076] Any reference to an item “an” refers to one or more of those items. The term “comprising” is used herein to mean including the identified method blocks or elements, but such blocks or elements are not included in a unique list, and the apparatus may contain additional blocks or elements, and the method may include additional operations or elements. Furthermore, blocks, elements, and operations are not implicitly closed on their own.

[0077] The steps of the method described herein can be performed in any suitable order or simultaneously when appropriate. The arrows between the boxes in the accompanying drawings indicate an example order of method steps, but are not intended to exclude other orders or the parallel execution of multiple steps. Furthermore, individual blocks can be removed from any method without departing from the spirit and scope of the subject matter described herein. Aspects of any example described above can be combined with aspects of any of the other examples described to form further examples without losing the desired effect. Where elements in the accompanying drawings are shown connected by arrows, it will be appreciated that these arrows only indicate one example communication flow (including data and control messages) between elements. Flow between elements can occur in either direction or in both directions.

[0078] The applicant hereby independently discloses each individual feature described herein, as well as any combination of two or more such features, to the extent that such features or combinations can be implemented based on this specification as a whole in accordance with common general knowledge of those skilled in the art, regardless of whether such features or combinations of features solve any problem disclosed herein. In view of the foregoing description, it will be apparent to those skilled in the art that various modifications can be made within the scope of this invention.

[0079] This application also provides the following items: Project 1. A graphics processing unit, the graphics processing unit including a texture filtering unit implemented in hardware logic, the texture filtering unit comprising: Multiple input terminals are arranged to receive one or more texture values ​​and multiple filter coefficients, the multiple filter coefficients including coefficients associated with multiple different texture filtering methods; A data path block, comprising one or more computation pipelines, each computation pipeline containing at least one hardware logic unit configured to receive multiple inputs and generate output values ​​as part of a texture filtering operation; and The control block includes multiple sequencers and arbitrators. Each sequencer includes multiple hard-coded microprograms and hardware logic, the hardware logic being arranged to select one of the microprograms based on one or more control inputs. Each microprogram defines a sequence of operations to be executed by the pipeline in the data path block as part of a texture filtering operation, and different microprograms implement different combinations of texture filtering methods. The arbitrator includes hardware logic configured to control the sequencer's access to the computation pipeline according to priority rules.

[0080] Project 2. The graphics processing unit according to Project 1, wherein each operation in the sequence of operations defined by the microprogram generates an intermediate value except for the final operation in the sequence, and the final operation in the sequence generates an output value, and wherein the data path block further includes a temporary register, wherein the temporary register is arranged to store the intermediate values ​​generated by one of the computation pipelines when the operation is performed in the microprogram.

[0081] Project 3. The graphics processing unit according to Project 2, wherein the temporary registers include a set of temporary registers for each sequencer in the control block, wherein the set of temporary registers for the sequencer is arranged to store the intermediate values ​​generated by one of the computational pipelines when one of the operations in the sequence defined by the selected microprogram is executed.

[0082] Project 4. The graphics processing unit according to Project 2, wherein the temporary register is further arranged to store output values, and wherein one of the computation pipelines includes a bypass path that bypasses the hardware logic components within one of the computation pipelines.

[0083] Project 5. A graphics processing unit according to any one of Projects 2-4, wherein, for each intermediate value generated by one of the computational pipelines, the control block outputs a destination for the intermediate result.

[0084] Project 6. The graphics processing unit according to Project 5, wherein the destination for the intermediate result is the location in the temporary register.

[0085] Project 7. A graphics processing unit according to Project 1, wherein each sequencer is arranged to send a sequence of requests for access to one of the pipelines in the data path block to the arbitrator when a selected microprogram is executed, each request corresponding to an operation in the sequence defined by the selected microprogram, and wherein the hardware logic in the arbitrator is arranged to control access to the computational pipeline by applying the priority rules to the requests received from the sequencer.

[0086] Project 8. The graphics processing unit according to Project 1, wherein the priority rule prioritizes access to operations involving new input texture values.

[0087] Project 9. The graphics processing unit according to Project 1, wherein the control block further includes a main controller unit arranged to indicate when the sequencer can begin executing the microprogram and to control the order in which the outputs are output from the texture filtering unit via the output terminal.

[0088] Item 10. The graphics processing unit according to Item 1, wherein any state transition in the microprogram is controlled based on the control input rather than on the texture value.

[0089] Project 11. The graphics processing unit according to Project 1, wherein the data path block comprises two parallel computing pipelines.

[0090] Project 12. The graphics processing unit according to Project 11, wherein the first of the two pipelines includes a two-dimensional dot product unit, and the second of the two pipelines includes an addition unit.

[0091] Project 13. The graphics processing unit according to Project 1, wherein the data path block includes multiple parallel computing pipelines.

[0092] Project 14. The graphics processing unit according to Project 1, wherein the control block includes four sequencers.

[0093] Item 15. The graphics processing unit according to Item 1, wherein the input texture values ​​include multiple interleaved texture values ​​from different streams accessed simultaneously from memory.

[0094] Project 16. A method for texture filtering within a GPU, the GPU including a texture filtering unit, the texture filtering unit including a data path block and a control block, the data path block including one or more computation pipelines, the control block including a plurality of sequencers and arbitrators, the method comprising: In each sequencer, a microprogram is selected based on one or more control inputs, wherein the microprogram defines a sequence of operations to be performed by the pipeline in the data path block as part of a texture filtering operation, and different microprograms implement different combinations of texture filtering methods; In each sequencer, a selected microprogram is executed, and a sequence of requests for access to one of the pipelines in the data path block is sent to the arbitrator, each request corresponding to an operation in the sequence defined by the selected microprogram; and In the arbitrator, the pipeline in the data path block is assigned to one of the sequencers based on the received request and priority rules.

[0095] Item 17. The method described in Item 16 further includes: Output values ​​are generated in the pipeline as part of the texture filtering operation.

[0096] Item 18. According to the method described in Item 17, generating the output value as part of the texture filtering operation includes: Intermediate values ​​are generated based on each operation in the sequence of operations defined by the microprogram, except for the final operation in the sequence; Generate an output value based on the final operation in the sequence; and The intermediate value is stored in a temporary register in the data path block.

[0097] Item 19. The method according to Item 18 further includes: In response to the inability to output an output value, the output value is stored.

[0098] Item 20. The method according to Item 19, wherein the output value is stored in the temporary register, and wherein the method further comprises: The stored output value from the texture filtering unit is output via a bypass path in the computation pipeline, wherein the bypass path bypasses any computation logic block within the computation pipeline.

Claims

1. A graphics processing unit, the graphics processing unit including a computing unit implemented in hardware logic, the computing unit comprising: Multiple input terminals are arranged to receive multiple product summation SOP coefficients and one or more input values ​​per clock cycle, the multiple SOP coefficients including coefficients associated with multiple different SOPs; A data path block, comprising one or more computation pipelines, each computation pipeline containing at least one hardware logic unit configured to receive multiple inputs and generate output values ​​as part of an SOP operation; as well as The control block includes multiple sequencers and arbitrators. Each sequencer includes multiple hard-coded microprograms (226) and hardware logic arranged to select one of the microprograms based on one or more control inputs. Each microprogram defines a sequence of operations to be executed by the pipeline in the data path block as part of the SOP calculation, and different microprograms implement different SOPs. The arbitrator includes hardware logic arranged to control access to the computation pipeline by the plurality of sequencers according to priority rules.

2. The graphics processing unit according to claim 1, wherein, The priority rule prioritizes accesses to operations involving new input values.

3. The graphics processing unit according to claim 1, wherein, Each operation in the sequence of operations defined by the microprogram generates an intermediate value, except for the final operation in the sequence, and the final operation in the sequence generates an output value. The data path block further includes a temporary register, which is arranged to store the intermediate values ​​generated by one of the computation pipelines when the operation is performed in the microprogram.

4. The graphics processing unit according to claim 3, wherein, The temporary registers include a set of temporary registers for each sequencer in the control block, wherein the set of temporary registers for the sequencer is arranged to store the intermediate values ​​generated by one of the computational pipelines when one of the operations in the sequence defined by the selected microprogram is executed.

5. The graphics processing unit according to claim 3, wherein, The temporary register is also arranged to store output values, and one of the computation pipelines includes a bypass path that bypasses the hardware logic components within the computation pipeline.

6. The graphics processing unit according to any one of claims 3-5, wherein, For each intermediate value generated by one of the computational pipelines, the control block outputs the destination for the intermediate result.

7. The graphics processing unit according to claim 6, wherein, The destination of the intermediate result is the location in the temporary register.

8. The graphics processing unit according to claim 1, wherein, Each sequencer is arranged to send a sequence of requests to the arbitrator for access to one of the pipelines in the data path block when a selected microprogram is executed, each request corresponding to an operation in the sequence defined by the selected microprogram, and wherein the hardware logic in the arbitrator is arranged to control access to the computation pipeline by applying the priority rules to the requests received from the sequencer.

9. The graphics processing unit according to claim 1, wherein, After the priority rule prioritizes access to operations involving new input values, a fixed priority scheme is applied among the sequencers.

10. The graphics processing unit according to claim 1, wherein, The control block also includes a main controller unit, which is arranged to indicate when the sequencer can begin executing the microprogram and to control the order in which the outputs are output from the computing unit via the output terminal.

11. The graphics processing unit according to claim 1, wherein, Control any state transitions in the microprogram based on the control inputs rather than on the input values.

12. The graphics processing unit according to claim 1, wherein, The data path block includes multiple parallel computing pipelines.

13. The graphics processing unit according to claim 1, wherein, All the sequencers in the control block are identical.

14. The graphics processing unit according to claim 1, wherein, The input values ​​include multiple interleaved input values ​​from different streams accessed simultaneously from the memory.

15. A method for evaluating a sum of multiple products, SOP, within a graphics processing unit (GPU), the GPU including a computation unit, and the computation unit including a data path block and a control block, the data path block including one or more computation pipelines, the control block including a plurality of sequencers and arbitrators, the method comprising: In each sequencer, a microprogram is selected based on one or more control inputs, wherein the microprogram defines a sequence of operations to be performed by the pipeline in the data path block as part of the SOP calculation, and different microprograms implement different SOPs; In each sequencer, a selected microprogram is executed, and a sequence of requests for access to one of the pipelines in the data path block is sent to the arbitrator, each request corresponding to an operation in the sequence defined by the selected microprogram; and In the arbitrator, the pipeline in the data path block is assigned to one of the sequencers based on the received request and priority rules.

16. The method according to claim 15, wherein, The priority rule prioritizes accesses to operations involving new input values.

17. The method of claim 15, further comprising: Output values ​​are generated in the pipeline as part of the SOP calculation.

18. The method according to claim 17, wherein, Generating output values ​​as part of the SOP calculation includes: Intermediate values ​​are generated based on each operation in the sequence of operations defined by the microprogram, except for the final operation in the sequence; Generate an output value based on the final operation in the sequence; and The intermediate value is stored in a temporary register in the data path block.

19. The method of claim 18, further comprising: In response to the inability to output an output value, the output value is stored.

20. The method according to claim 19, wherein, The output value is stored in the temporary register, and the method further includes: The stored output value from the computing unit is output via a bypass path in the computing pipeline, wherein the bypass path bypasses any computing logic block within the computing pipeline.

Images