Search Images Maps Play YouTube News Gmail Drive More »
Sign in
Screen reader users: click this link for accessible mode. Accessible mode has the same essential features but works better with your reader.

Patents

  1. Advanced Patent Search
Publication numberUS20050140688 A1
Publication typeApplication
Application numberUS 10/747,966
Publication dateJun 30, 2005
Filing dateDec 29, 2003
Priority dateDec 29, 2003
Also published asCN1910621A, CN1910621B, US7133047, US7697010, US20050140689, US20090051697, US20100118028
Publication number10747966, 747966, US 2005/0140688 A1, US 2005/140688 A1, US 20050140688 A1, US 20050140688A1, US 2005140688 A1, US 2005140688A1, US-A1-20050140688, US-A1-2005140688, US2005/0140688A1, US2005/140688A1, US20050140688 A1, US20050140688A1, US2005140688 A1, US2005140688A1
InventorsKim Pallister
Original AssigneeKim Pallister
Export CitationBiBTeX, EndNote, RefMan
External Links: USPTO, USPTO Assignment, Espacenet
Method and mechanism for programmable filtering of texture map data in 3D graphics subsystems
US 20050140688 A1
Abstract
A system, method and apparatus to provide flexible texture filtering. A programmable texture filtering module is introduced into the graphics processing pipeline of a graphic coprocessor and graphic processor integrated with the host. A program from a defined instruction set may then be loaded into texture processing cores to process texture data consistent with the program.
Images(4)
Previous page
Next page
Claims(22)
1. A method comprising:
fetching coordinate data for a pixel to be rendered;
fetching texel values corresponding to the pixel;
filtering the texel values through a programmable filter; and
outputting a filtered texture value for the pixel.
2. The method of claim 1 wherein filtering texel values comprises:
reading a control register; and
using at least one location specified in the control register as a source location.
3. The method of claim 1 wherein fetching coordinate data comprises:
retrieving X, Y, Z coordinate data from a vertex pipeline.
4. The method of claim 1 further comprising:
writing coordinate fraction data to a plurality of registers.
5. The method of claim 1 wherein outputting comprises:
writing the filtered texture value to a register; and
signaling a processor that the filtered texture value is available.
6. An apparatus comprising:
a fragment processing module;
a programmable texture filtering module in communication with the fragment processing module to programmably filter texture data corresponding to at least one pixel; and
a frame buffer processing module to combine filtered texture data with an existing frame buffer.
7. The apparatus of claim 6 wherein the programmable texture filtering module comprises:
a plurality of control registers;
a plurality of source registers;
a plurality of temporary registers; and
at least one output register.
8. The apparatus of Clam 7 wherein the source registers are read only.
9. The apparatus of claim 7 wherein the plurality of control registers comprises:
a status register;
an address register;
an offset register; and
a plurality of fraction registers.
10. The apparatus of claim 7 where the plurality of the control registers comprise:
at least one sampling register have a bit corresponding to each of the source registers to indicate if sampling of a corresponding source register is required.
11. The apparatus of claim 6 wherein the programmable texture filtering module comprises:
a plurality of processing cores to execute an instruction set.
12. The apparatus of claim 6 wherein a subset of the plurality of cores are to execute a filtering program on at least one pixel in parallel.
13. A system comprising:
a memory,
a plurality of texture processing cores (TPC) coupled to the memory to programmably filter texture data;
a fragment processing module to apply the filtered texture data to at least one fragment; and
a display to display an image created using the at least one fragment.
14. The system of claim 13 wherein the plurality of TPC and the fragment processing module are integrated with a host processor.
15. The system of claim 13 wherein the plurality of TPCS and the fragment processing module reside in a graphics coprocessor.
16. The system of claim 13 comprising:
a register set associated with each TPC of the plurality.
17. The system of claim 15 further comprising:
an accelerated graphics port coupling the graphics coprocessor to the memory.
18. A computer readable storage media containing executable computer program instructions which when executed cause a digital processing system to perform a method comprising:
fetching coordinate data for a pixel to be rendered;
fetching texel values corresponding to the pixel;
filtering the texel values through a programmable filter; and
outputting a filtered texture value for the pixel.
19. The computer readable storage media of claim 18 which when executed cause a digital processing system to perform a method further comprising:
reading a control register; and
using at least one location specified in the control register as a source location.
20. The computer readable storage media of claim 18 which when executed cause a digital processing system to perform a method further comprising:
retrieving X, Y, Z coordinate data from a vertex pipeline.
21. The computer readable storage media of claim 18 which when executed cause a digital processing system to perform a method further comprising:
writing coordinate fraction data to a plurality of registers.
22. The computer readable storage media of claim 18 which when executed cause a digital processing system to perform a method further comprising:
writing the filtered texture value to a register; and
signaling a processor that the filtered texture value is available.
Description
BACKGROUND

1. Field of the Invention

The embodiments of the invention relate to computer graphics. More specifically, embodiments of the invention relate to processing of texture map data.

2. Background

Graphics applications, and particularly three dimensionally (3D) graphic applications have long been one of the most processing intensive activities performed by personal computers. To improve graphic processing capabilities, graphics co-processors have proliferated and are widely available on most modern day personal computers. Graphic coprocessors are specialized integrated circuits designed to quickly perform processing intensive tasks required by graphic applications.

The transformation of scene information (source data) into 3D images (display output) requires a number of operations. These operations in aggregate are referred to as a 3D graphics rendering pipeline. The operations performed by the pipeline can be grouped into certain fundamental functionalities. One of these functionalities is texture mapping. Texture mapping is a process in which the one, two or three dimensional image representing an object surface properties (such as appearance, reflectivity, or other such properties) is applied to a three dimensional mesh representing the object in a final rendering. While a two dimensional image is most commonly used, other dimensionalities are possible.

It is frequently the case when a texture image is applied to an object in a final rendering, there is disparity between a number of sample texture elements (texels) and the source texture image and the number of picture elements (pixels) to which the image is mapped. When the number of texels in a given range is less than the number of pixels, then the texture is required to be upsampled. When upsampling a texture, a scheme must be used to fill intermediate values. This scheme is referred to herein as “texture filtering” and has largely been performed by a fixed function state machine. Most current graphic coprocessor support four types of texture filtering; point sampling, bilinear filtering, trilinear filtering and anisotropic filtering. As the filtering methods become increasingly complex, the state machine required to perform them becomes increasingly complex and requires increased real estate within the graphics coprocessor. This coupled with the fact that uses for texture data continues to expand, for example, texture data is being used for lighting and other surface properties in addition to color, renders the commonly employed linear interpolation inefficient or even insufficient.

BRIEF DESCRIPTION OF THE DRAWINGS

Embodiments of the invention are illustrated by way of example and not by way of limitation in the figures of the accompanying drawings in which like references indicate similar elements. It should be noted that different references to “an” or “one” embodiment in this disclosure are not necessarily to the same embodiment, and such references mean at least one.

FIG. 1A is a block diagram of a system of one embodiment of the invention.

FIG. 1B is a diagram of texture sampling in one embodiment of the invention.

FIG. 2 is a flow diagram of the setup of the textured filtering module in one embodiment of the invention.

FIG. 3 is a flow diagram of texture filtering in one embodiment of the invention.

DETAILED DESCRIPTION

FIG. 1A is a block diagram of a system of one embodiment of the invention. A host processor 100 is coupled by a bus 102 to a memory 104. A graphics coprocessor 106 is also coupled to the bus 102. Additionally, graphics coprocessor 106 may be coupled to memory 104 by an accelerated graphics port (AGP) 112. The AGP may adhere to Accelerated Graphics Port AGP V3.0 Interface Specification Rev. 1.0 published September 2002 (hereinafter the AGP Specification). AGP 112 allows rapid access to graphics data residing in memory 104. Also coupled to the bus are framebuffer 108 and display 110. In some embodiments, framebuffer 108 may be contained within memory 104. Graphics coprocessor 106 includes pixel processing pipeline 120. Within the pixel processing pipeline 120 is a vertex processing module 122, primitive assembly module 124, a fragment processing module 126 and a framebuffer processing module 128. Vertex processing module 122 in operation receives vertex data, which may include, for example, 3D positional information, color information and other similar information related to vertices in the graphic image. In one embodiment, vertex data is of the form V=X, Y, Z, Tu, Tv, RGB. In this expression, X, Y, Z are the three dimensional Cartesian coordinates of the vertex, Tu and Tv are the two dimensional coordinate of the corresponding texel in the texture map and RGB are the red, green and blue color values at the vertex. Other forms and contents of vertex data are also contemplated.

Vertex processing module does three-dimensional transformations on 3D positional data conveyed, and may, for example, applies lighting. The processed vertices are passed to the primitive assembly module, which receives connectivity data. The connectivity data may include indices to permit assembly of primitives, typically triangles, based on the vertices and indices received.

The primitives are passed to the fragment processing module 126 which processes the primitives to identify fragments and apply texture data to build an output. As used herein, “fragment” refers to a pixel or group of contiguous pixels that are to be consistently processed to generate the output. The fragment processing exchanges data relating to texture mapping the fragments with a texture filter module 130.

The texture filter module 130 communicates with fragment processing module 126 to supply texels for application to the pixels. In one embodiment, texture filter module 130 is programmable. In this context, programmable is deemed to mean capable of executing a software program consisting of one or more instructions from a defined instruction set. One example of an instruction set is set forth below in Table 1.

TABLE 1
Instruction Description
ADD A, B Adds A and B operands
SUB A, B Subtracts B from A
MUL A, B Multiples A by B
RCP A, B Makes A the reciprocal of B
CMP A, B, X Compares A, B according to immediate X,
places result in A
MIN A, B Compares A, B leaves minimum of two values in A
MAX A, B Compares A, B leaves maximum of two values in A
MOV A, B Moves B into A

Alternative instruction sets, either shorter or longer, may be employed in various embodiments of the invention.

In one embodiment, texture filter module 130 includes a plurality of texture processing cores (TPCs) 132 (16 TPC are shown in FIG. 1). Other embodiments may have more or fewer TPCs. In one embodiment, a single TPC exists. In one embodiment, each TPC 132 is capable of processing a pixel in parallel with each of the other TPC 132. Each core 132 may be provided with a register set 134 which may include various types of registers such as control registers, source registers, temporary registers and an output register.

In one embodiment, the control registers include a sampling register, a status register, an address register, an offset register, and a plurality of fraction registers. In one embodiment, the sampling register has one bit corresponding to each source registers indicating whether the source register should be sampled or not. For example, if there are sixteen source registers, the sampling register may be a sixteen bit register with one bit corresponding to each of the sixteen source registers. In one embodiment, the status register is used to indicate the status of the TPC after certain conditions, such as overflow, divide by zero, etc. In one embodiment, the address register may be a 32 bit register containing the address of the texture map data. In one embodiment, this register may be accessible only by an application programming interface (API) rather than providing direct access to a programmer. The offset register may be used to provide an offset into the texture data corresponding to the nearest texel coordinate. Fraction registers may be used to hold the fractional coordinate between the texel samples in each dimensionality. In one embodiment, these would be provided by the fragment processing module 126. In one embodiment above, where V=X, Y, Z, Tu, Tv, RGB; Tu and Tv correspond to a pixel to be texture mapped would be provided to the texture filtering module. As one example, an eight pixel one dimensional texture coordinate of 0.175 would fall between the second (0.125) and third (0.25) texel. It would equate to a fraction of 0.2. The fraction in this embodiment is found as (0.175−0.125)/0.125 or more generally, the coordinate less the closest lower increment divided by the increment value.

FIG. 1B is a diagram of texture sampling in one embodiment of the invention. In one embodiment, sixteen source registers are provided. With each register corresponding to one texel in a 4×4 grid surrounding the TuTv sampling location of the texture sample point and would correspond to pixels addressed in such a fashion. While TuTv mapps to a location between texels 5 and 6 and texels 9 and 10, the contribution of the sixteen texels in the patch to the texture value assigned to TuTv may be defined by the texture filtering program. In some embodiments, only texels 5, 6, 9 and 10 provide a contribution. In other embodiments, all sixteen texels may contribute. In still other embodiments, all diagonal prixels in the group may contribute. As illustrated, the programmable nature of the texture filtering module permits robust and flexible texture filtering options.

Temporary registers may be provided for optional use by a programmer performing intermediate calculations on sample data. An output register is provided to store the output once the filtering operation is complete. In one embodiment, a 32 bit register is provided to receive the final result. Larger registers may be employed, however, in some embodiments a 32 bit ARGB (alpha red green blue) value is deemed sufficient.

The actual filtering may be performed by the texture filtering module 130 by loading a desired filtering program into a textured processing core. The filtering program corresponds to a fragment to be processed. Within a region of an image, it may be desirable to apply various effects to the texture data accordingly. Thus, for a particular graphic image, there may be numerous filtering programs employed. For example, the filter program applied to a shiny part of a leather jacket on an image would likely to be different than the filter program applied to a scuffed part of a leather jacket. By using different programs in e texture filter module, the different effect can be accommodated. The usage of several filter programs during the course of rendering a given scene image is analogous to how, under the current-day fixed-function schemes, the rendering of a given scene may involve switching between the different fixed-function filtering states for different parts of the scene.

The program employed will influence which of the e.g. 16 texels are actually sampled to perform the texture filtering. In one embodiment, texture data may be arranged in memory to optimize access to the texels likely to be sampled. For example, if the sampling register indicates every fourth texel value is active, the texture data may be stored so that points 1, 5, 9 and 13 are contiguous in memory, points 2, 6, 10, etc. are contiguous. As another example, where every second texel is active, 1, 3, 5, 7, etc. are contiguous and 2, 4, 8, etc. are contiguous. This arrangement in memory may be performed by the host processor 100 or the graphic coprocessor 106.

Arranging memory requires a certain amount of processor resources, in one embodiment, a determination is made when the likely use of the texture data exceeds a threshold cost required to rearrange it. Thus, where the usage of the textured data justifies the cost to rearrange it, in one embodiment, the textured data is rearranged in memory to facilitate access. The threshold may be selected based on objective guidelines such as number of texels to be processed with a given program.

Once texture filtering is complete and the output generated, the output value may then be passed back to fragment processing module 126 to permit the output fragment to be built. The output built by the fragment processing module 126 is passed to framebuffer processing module 128. Framebuffer processing module 128 combines the pixels received with the existing framebuffer for output to display 110.

FIG. 2 is a flow diagram of the setup of the textured filtering module in one embodiment of the invention. At functional block 202, a texture filter program is loaded into a texture processing core of the texture filtering module. At functional block 204, the sampling register is initialized to indicate the texels surrounding a sample point that will be sampled as part of the filtering process. At decision block 206, a determination is made if the texels to be sampled in conjunction with the number of samplings required justify reorganization of the texture data in memory. If so, the texture data is reordered for efficient access at functional block 208. After reordering, or if no reordering is required, the address register is initialized at functional block 210.

FIG. 3 is a flow diagram of texture filtering in one embodiment of the invention. At functional block 302, the texture filter fetches the coordinate data for pixels to be rendered from the vertex pipeline. In one embodiment, these will be fetched from the fragment processing module. At functional block 304, texel values identified from the sampling register are fetched from memory. At functional block 306, fraction registers are loaded with the coordinate data. The texture processing cores are used to execute a filter program at functional block 308. At decision block 310, a determination is made if the execution of the filter program necessitates setting of a status flag. If the execution requires the status flag such as a divide by zero or overflow, the status register is loaded with an appropriate value at functional block 312. If no status flag is required, or after the status register has been loaded, the output value is loaded into the output register and the output is signaled to be available at functional block 314. At decision block 316, a determination is made if there are more pixels to be rendered using the existing filter program. If so, a flow continues. If not, it ends.

Although the above flow diagrams are arranged in a particular order, it should be understood that some of the operations may be performed in parallel or in a different order than depicted. Accordingly, such parallization or rearrangement is within the scope and contemplation of the embodiments of the invention. It should also be noted that while in only one embodiment, a single texture processing core may be present in the texture filter module, embodiments with multiple texture processing cores, pixels may be processed in parallel with each core following the flow depicted in FIG. 3.

In the foregoing specification, the invention has been described with reference to specific embodiments thereof. It will, however, be evident that various modifications and changes can be made thereto without departing from the broader spirit and scope of the invention as set forth in the appended claims. The specification and drawings are, accordingly, to be regarded in an illustrative rather than a restrictive sense.

Referenced by
Citing PatentFiling datePublication dateApplicantTitle
US7586492 *Dec 20, 2004Sep 8, 2009Nvidia CorporationReal-time display post-processing using programmable hardware
US7603506Jun 16, 2005Oct 13, 2009Broadcom CorporationMotherboard with video data processing card capability
US7612779 *Mar 7, 2005Nov 3, 2009Broadcom CorporationVideo data processing circuits and systems comprising programmable blocks or components
US7813562Sep 27, 2004Oct 12, 2010Intel CorporationLow-latency remote display rendering using tile-based rendering systems
US7961193Sep 22, 2009Jun 14, 2011Broadcom CorporationVideo data processing circuits and systems comprising programmable blocks or components
US8074008Sep 10, 2009Dec 6, 2011Broadcom CorporationMotherboard with video data processing card capability
US8208741Sep 17, 2010Jun 26, 2012Intel CorporationLow-latency remote display rendering using tile-based rendering systems
US8472732Nov 2, 2011Jun 25, 2013Intel CorporationLow-latency remote display rendering using tile-based rendering systems
US8768076Feb 4, 2013Jul 1, 2014Intel CorporationLow-latency remote display rendering using tile-based rendering systems
Classifications
U.S. Classification345/582
International ClassificationG06T15/00, G06T15/04, G09G5/00
Cooperative ClassificationG06T15/005, G06T15/04
European ClassificationG06T15/00A, G06T15/04
Legal Events
DateCodeEventDescription
Dec 29, 2003ASAssignment
Owner name: INTEL CORPORATION, CALIFORNIA
Free format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNOR:PALLISTER, KIM;REEL/FRAME:014860/0650
Effective date: 20031225