Patent Description:
The present disclosure is better understood, and its numerous features and advantages made apparent to those skilled in the art by referencing the accompanying drawings.

A graphics pipeline for processing three-dimensional (<NUM>-D) graphics is formed of a sequence of fixed-function hardware block arrangements supported by programmable shaders and a memory. These arrangements are usually specified by a graphics application programming interface (API) processing order such as specified in specifications of Direct 3D <NUM>, Microsoft DX <NUM>/<NUM> or Khronos Group OpenGL/Vulkan APIs. One example of a graphics pipeline includes a geometry front-end that is implemented using a vertex shader and a hull shader that operate on high order primitives such as patches that represent a <NUM>-D model of a scene.

The geometry front-end provides the high order primitives like curved surface patches and tessellation factors generated by the hull shader to a tessellator that is implemented as a fixed function hardware block in some embodiments. Tessellation allows detail to be dynamically added and subtracted from a 3D polygon mesh based on control parameters. The tessellator generates lower order primitives (such as triangles, lines, and points) from the input higher order primitives based on tessellation parameters (also referred to herein as tessellation factors) which control the degree of fineness of the 3D polygon mesh. The tessellation allows for producing smoother surfaces than would be generated by the original 3D polygon mesh. Lower order primitives such as polygons are formed of interconnected vertices. For example, common objects like meshes include a plurality of triangles formed of three vertices. The lower order primitives are provided to a geometry back-end that includes a geometry shader to replicate, shade or subdivide the lower order primitives. For example, massive hair generation can be provided via functionality of the geometry shader.

Vertices of the primitives generated by the portion of the graphics pipeline that handles the geometry workload in object space are then provided to the portion that handles pixel workloads in image space, e.g., via primitive, vertex, and index buffers as well as cache memory buffers. The pixel portion includes the arrangements of fixed function hardware combined with programmable pixel shaders to perform culling, rasterization, depth testing, color blending, and the like on the primitives to generate fragments or pixels from the input geometry primitives. The fragments are individual pixels or subpixels in some cases. A programmable pixel shader then shades the fragments to merge with scene frame image for display.

<FIG> disclose systems and techniques to improve the efficiency and bandwidth of graphics processing pipelines. In some embodiments, a method of bypassing writing tessellation factors to and reading tessellation factors from a graphics memory includes detecting, at a hull shader of a graphics processing pipeline of a graphics processing unit (GPU), whether all the tessellation factors for a patch, or at least a threshold percentage of the tessellation factors for all patches in a thread group, have the same value, and whether at least a threshold percentage of the tessellation factors indicates either that the patches of the thread group are to be culled or that the patches of the thread group are to be passed to the tessellator. If at least the threshold percentage of the tessellation factors for a thread group indicate that the patches of the thread group are to be culled (referred to herein as having tessellation factors with a value of zero), the hull shader bypasses writing the tessellation factors to the graphics memory and sends a message to the patch fetcher indicating that the tessellation factors for the thread group are to be discarded. In response to receiving the message, the patch fetcher bypasses reading tessellation factors for the thread group from the graphics memory and discards the patches of the thread group.

If the hull shader determines that at least the threshold percentage of the tessellation factors for the thread group indicates that the patches of the thread group are to be passed to the tessellator stage (referred to herein as having tessellation factors with a value of one), the hull shader bypasses writing the tessellation factors for the thread group to the graphics memory and sends a message to the patch fetcher indicating that all of the tessellation factors for the thread group are indicate that the patches of the thread group are to be passed to the tessellator stage. In response to receiving the message, the patch fetcher bypasses reading the tessellation factors from the graphics memory and provides the patches of the thread group to the tessellator stage.

In some embodiments, if the hull shader determines that at least the threshold percentage of the tessellation factors for the thread group have values that are equal to each other but that are neither zero nor one, the hull shader writes a single instance of the value of the tessellation factors to the memory and sends a message to the patch fetcher indicating that the single value of the tessellation factors stored at the graphics memory applies to all of the tessellation factors for the patches of the thread group. In response to receiving the message, the patch fetcher reads the single tessellation factor from the graphics memory and applies the single tessellation factor to each of the patches in the thread group before providing the patches to the tessellator.

If the tessellation factors for the patches of the thread group do not have values that are equal to each other, in some embodiments, the hull fetcher performs integer compression to write more than one compressed tessellation factor for a patch in a single word to the graphics memory. For example, an isoline patch is associated with two tessellation factors. Thus, in some embodiments, the hull fetcher writes both tessellation factors for an isoline patch in a single word to the graphics memory. Similarly, a triangle patch is associated with four tessellation factors. In some embodiments, the hull fetcher writes all four tessellation factors associated with a triangle patch in a single word to the graphics memory. A quad patch is associated with six tessellation factors. In some embodiments, the hull fetcher writes the first three tessellation factors associated with a quad patch in a first single word to the graphics memory and writes the remaining three tessellation factors associated with the quad patch in a second single word to the graphics memory.

Each patch primitive type (e.g., isoline, triangle, and quad) is associated with either two, four, or six tessellation factors. Particularly for tessellation factors equal to zero or one, more bandwidth can be consumed writing and reading the tessellation factors to and from the graphics memory than is saved by any reduction in granularity of the tessellated primitives that are produced using the tessellation factors. By reducing the amount of data written to and read from the graphics memory, the graphics processing pipeline improves bandwidth and efficiency of the GPU.

<FIG> is a block diagram of a processing system <NUM> for implementing reduced bandwidth tessellation factors in accordance with some embodiments. The processing system <NUM> includes a central processing unit (CPU) <NUM>, a system memory <NUM>, a graphics processing subsystem <NUM> including a graphics processing unit (GPU) <NUM>, and a display device <NUM> communicably coupled together by a system data bus <NUM>. As shown, the system data bus <NUM> connects the CPU <NUM>, the system memory <NUM>, and the graphics processing subsystem <NUM>. In other embodiments, the system memory <NUM> connects directly to the CPU <NUM>. In some embodiments, the CPU <NUM>, portions of the graphics processing subsystem <NUM>, the system data bus <NUM>, or any combination thereof, is integrated into a single processing unit. Further, in some embodiments, the functionality of the graphics processing subsystem <NUM> is included in a chipset or in some other type of special purpose processing unit or co-processor.

The CPU <NUM> executes programming instructions stored in the system memory <NUM>, operates on data stored in the system memory <NUM>, sends instructions and/or data (e.g., work or tasks to complete) to the graphics processing unit <NUM> to complete, and configures portions of the graphics processing subsystem <NUM> for the GPU <NUM> to complete the work. In some embodiments, the system memory <NUM> includes dynamic random access memory (DRAM) for storing programming instructions and data for processing by the CPU <NUM> and the graphics processing subsystem <NUM>.

In various embodiments, the CPU <NUM> sends instructions intended for processing at the GPU <NUM> to command buffers. In some embodiments, the command buffer is located, for example, at system memory <NUM> coupled to the system data bus <NUM>. In other embodiments, the CPU <NUM> sends graphics commands intended for the GPU <NUM> to a separate memory communicably coupled to the system data bus <NUM>. The command buffer temporarily stores a stream of graphics commands that include input to the GPU <NUM>. The stream of graphics commands includes, for example, one or more command packets and/or one or more state update packets. In some embodiments, a command packet includes a draw command (also interchangeably referred to as a "draw call") instructing the GPU <NUM> to execute processes on image data to be output for display. For example, a draw command instructs the GPU <NUM> to render pixels defined by a group of one or more vertices (e.g., defined in a vertex buffer) stored in memory. The geometry defined by the group of one or more vertices corresponds, in some embodiments, to a plurality of primitives to be rendered.

The GPU <NUM> receives and processes work transmitted from the CPU <NUM>. For example, in various embodiments, the GPU <NUM> processes the work to render and display graphics images on the display device <NUM>, such as by using one or more graphics pipelines <NUM>. The graphics pipeline <NUM> includes fixed function stages and programmable shader stages. The fixed function stages include typical hardware stages included in a fixed function pipeline of a GPU. The programmable shader stages include streaming multiprocessors. Each of the streaming multiprocessors is capable of executing a relatively large number of threads concurrently. Further, each of the streaming multiprocessors is programmable to execute processing tasks relating to a wide variety of applications, including but not limited to linear and nonlinear data transforms, filtering of video and/or audio data, modeling operations (e.g., applying of physics to determine position, velocity, and other attributes of objects), and so on. In other embodiments, the graphics processing subsystem <NUM> is used for non-graphics processing.

As also shown, the system memory <NUM> includes an application program <NUM> (e.g., an operating system or other application), an application programming interface (API) <NUM>, and a GPU driver <NUM>. The application program <NUM> generates calls to the API <NUM> for producing a desired set of results, typically in the form of a sequence of graphics images. The graphics processing subsystem <NUM> includes a GPU data bus <NUM> that communicably couples the GPU <NUM> to a graphics memory <NUM>. In various embodiments, the GPU uses graphics memory <NUM> and system memory <NUM>, in any combination, for memory operations. The CPU <NUM> allocates portions of these memories for the GPU <NUM> to execute work. For example, in various embodiments, the GPU <NUM> receives instructions from the CPU <NUM>, processes the instructions to render graphics data and images, and stores images in the graphics memory <NUM>. Subsequently, the GPU <NUM> displays graphics images stored in the graphics memory <NUM> on the display device <NUM>. The graphics memory <NUM> stores data and programming used by the GPU <NUM>. As illustrated in <FIG>, the graphics memory <NUM> includes a frame buffer <NUM> that stores data for driving the display device <NUM>.

In various embodiments, the GPU <NUM> includes one or more compute units, such as one or more processing cores <NUM> that include one or more processing units <NUM> that execute a thread concurrently with execution of other threads in a wavefront, such as according to a single-instruction, multiple-data (SIMD) execution model. The processing units <NUM> are also interchangeably referred to as SIMD units. The SIMD execution model is one in which multiple processing elements share a single program control flow unit and program counter and thus execute the same program but are able to execute that program with different data. The processing cores <NUM> of the GPU <NUM> are also interchangeably referred to as shader cores or streaming multiprocessors (SMXs). The number of processing cores <NUM> that are implemented in the GPU <NUM> is a matter of design choice.

Each of the one or more processing cores <NUM> executes a respective instantiation of a particular work-item to process incoming data, where the basic unit of execution in the one or more processing cores <NUM> is a work-item (e.g., a thread). Each work-item represents a single instantiation of, for example, a collection of parallel executions of a kernel invoked on a device by a command that is to be executed in parallel. A work-item is executed by one or more processing elements as part of a thread group (e.g., a work-group) executing at a processing core <NUM>. In various embodiments, the GPU <NUM> issues and executes single processing unit <NUM>. Multiple wavefronts are included in a "thread group," which includes a collection of work-items designated to execute the same program. A thread group is executed by executing each of the wavefronts that make up the thread group. In some embodiments, the wavefronts are executed sequentially on a single processing unit <NUM> or partially or fully in parallel on different SIMD units. In other embodiments, all wavefronts from a thread group are processed at the same processing core <NUM>. Wavefronts are also interchangeably referred to as warps, vectors, or threads. In some embodiments, wavefronts include instances of parallel execution of a shader program, where each wavefront includes multiple work-items that execute simultaneously on a single processing unit <NUM> in line with the SIMD paradigm (e.g., one instruction control unit executing the same stream of instructions with multiple data). A scheduler <NUM> performs operations related to scheduling various wavefronts on different processing cores <NUM> and processing units <NUM>, as well as performing other operations for orchestrating various tasks on the graphics processing subsystem <NUM>.

The parallelism afforded by the one or more processing cores <NUM> is suitable for graphics related operations such as pixel value calculations, vertex transformations, tessellation, geometry shading operations, and other graphics operations. The graphics pipeline <NUM> accepts graphics processing commands from the CPU <NUM> and thus provides computation tasks to the one or more processing cores <NUM> for execution in parallel. Some graphics pipeline operations, such as pixel processing and other parallel computation operations, require that the same command stream or compute kernel be performed on streams or collections of input data elements. Respective instantiations of the same compute kernel are executed concurrently on multiple processing units <NUM> in the one or more processing cores <NUM> in order to process such data elements in parallel. As referred to herein, for example, a compute kernel is a function containing instructions declared in a program and executed on a processing core <NUM>. This function is also referred to as a kernel, a shader, a shader program, or a program.

As described below in more detail with respect to <FIG>, the GPU <NUM> includes a graphics pipeline <NUM> that reduces the number of tessellation factors written to and read from the graphics memory <NUM>. Abstract patch types include isoline, triangle, and quad. An isoline patch is a horizontal line defined by two tessellation factors. A triangle patch is a triangle defined by three outer tessellation factors and one inner tessellation factor, for a total of four tessellation factors. A quad patch is a square defined by four outer tessellation factors and two inner tessellation factors, for a total of six tessellation factors. In some embodiments, each tessellation factor includes <NUM> bits. Thus, writing all of the tessellation factors for all of the patches of a thread group to the graphics memory <NUM> and reading all of the tessellation factors for the patches of the thread group from the graphics memory <NUM> consumes significant bandwidth. The graphics pipeline <NUM> detects whether at least a threshold percentage of the tessellation factors for a thread group of patches are the same and, in some embodiments, whether at least the threshold percentage of the tessellation factors for a thread group of patches are either zero (i.e., indicate that the patches are to be culled) or one (i.e., indicate that the patches are to be passed to a tessellator stage of the graphics pipeline <NUM>). In some embodiments, the threshold is programmable and is set to a relatively high value, such as <NUM>%. In response to detecting that the threshold percentage of the tessellation factors for the thread group are the same (or, additionally in some embodiments, that the threshold percentage of the tessellation factors are either zero or one), the graphics pipeline <NUM> bypasses writing and reading at least a subset of the tessellation factors for the thread group of patches to and from the graphics memory <NUM>, thus reducing bandwidth and increasing efficiency of the graphics pipeline <NUM>.

<FIG> depicts a graphics pipeline that is capable of processing high-order geometry primitives to generate rasterized images of three-dimensional (3D) scenes while storing and retrieving from memory a reduced amount of tessellation factors in accordance with some embodiments. <FIG> shows various elements and pipeline stages associated with a GPU. In some embodiments the graphics pipeline includes other elements and stages that are not illustrated in <FIG>. It should also be noted that <FIG> is only schematic, and that, for example, in some embodiments in practice the shown functional units and pipeline stages share hardware circuits, even though they are shown schematically as separate stages in <FIG>. It will also be appreciated that each of the stages, elements and units of the graphics processing pipeline <NUM> are implemented as desired and accordingly include, for example, appropriate circuitry and/or processing logic for performing the associated operation and functions.

In various embodiments, the graphics processing pipeline <NUM> is configured to render graphics as images that depict a scene which has three-dimensional geometry in virtual space (sometimes referred to herein as "world space"), but potentially a two-dimensional geometry. The graphics processing pipeline <NUM> typically receives a representation of a three-dimensional scene, processes the representation, and outputs a two-dimensional raster image. These stages of graphics processing pipeline <NUM> process data that is initially properties at end points (or vertices) of a geometric primitive, where the primitive provides information on an object being rendered. Typical primitives in three-dimensional graphics include triangles and lines, where the vertices of these geometric primitives provide information on, for example, x-y-z coordinates, texture, and reflectivity.

Throughout the graphics processing pipeline <NUM>, data is read from and written to one or more memory units, which are generally denoted in <FIG> as graphics memory <NUM>. The graphics memory <NUM> includes a hierarchy of one or more memories or caches that are used to implement buffers and store tessellation factors, vertex data, texture data, and the like. The graphics memory <NUM> is implemented using some embodiments of the system memory <NUM> shown in <FIG>.

The graphics memory <NUM> contains video memory and/or hardware state memory, including various buffers and/or graphics resources utilized in the rendering pipeline. In various embodiments, one or more individual memory units of the graphics memory <NUM> is embodied as one or more video random access memory unit(s), one or more caches, one or more processor registers, and the like, depending on the nature of data at the particular stage in rendering. Accordingly, it is understood that graphics memory <NUM> refers to any processor accessible memory utilized in the graphics processing pipeline <NUM>. A processing unit, such as a specialized GPU, is configured to perform various operations in the pipeline and read/write to the graphics memory <NUM> accordingly.

The early stages of the graphics processing pipeline <NUM> include operations performed in world space before a scene is rasterized and converted to screen space as a set of discrete picture elements suitable for output on the pixel display device. Throughout the graphics processing pipeline <NUM>, various resources contained in the graphics memory <NUM> are utilized at the pipeline stages and inputs and outputs to the stages are temporarily stored in buffers contained in the graphics memory <NUM> before the final values of the images are determined.

An input assembler stage <NUM> is configured to access information from the graphics memory <NUM> that is used to define objects that represent portions of a model of a scene. For example, in various embodiments, the input assembler stage <NUM> reads primitive data (e.g., points, lines and/or triangles) from user-filled buffers and assembles the data into primitives that will be used by other pipeline stages of the graphics processing pipeline <NUM>. As used herein, the term "user" refers to the application program <NUM> or other entity that provides shader code and three-dimensional objects for rendering to the graphics processing pipeline <NUM>. The input assembler stage <NUM> assembles vertices into several different primitive types (such as line lists, triangle strips, or primitives with adjacency) based on the primitive data include in the user-filled buffers and formats the assembled primitives for use by the rest of the graphics processing pipeline <NUM>.

In various embodiments, the graphics processing pipeline <NUM> operates on one or more virtual objects defined by a set of vertices set up in world space and having geometry that is defined with respect to coordinates in the scene. For example, the input data utilized in the graphics processing pipeline <NUM> includes a polygon mesh model of the scene geometry whose vertices correspond to the primitives processed in the rendering pipeline in accordance with aspects of the present disclosure, and the initial vertex geometry is set up in the graphics memory during an application stage implemented by a CPU.

A vertex processing stage <NUM> includes various computations to process the vertices of the objects in world space geometry. In some embodiments, the vertex processing stage <NUM> includes a vertex shader stage <NUM> to perform vertex shader computations, which manipulate various parameter values of the vertices in the scene, such as position values (e.g., X-Y coordinate and Z-depth values), color values, lighting values, texture coordinates, and the like. Preferably, the vertex shader computations are performed by one or more programmable vertex shaders <NUM>. The vertex shader computations are performed uniquely for each zone that an object overlaps, and an object zone index is utilized during vertex shading to determine which rendering context and the associated parameters that the object uses, and, accordingly, how the vertex values should be manipulated for later rasterization. In various embodiments, the vertex shader stage <NUM> is implemented in software, logically receives a single vertex of a primitive as input, and outputs a single vertex. Some embodiments of vertex shaders implement single-instruction-multiple-data (SIMD) processing so that multiple vertices are processed concurrently.

The vertex processing stage <NUM> also optionally includes additional vertex processing computations, which subdivide primitives and generates new vertices and new geometries in world space. In the depicted embodiment, the vertex processing stage <NUM> includes a vertex shader stage <NUM>, a hull shader stage <NUM>, a patch fetcher <NUM>, a tessellator stage <NUM>, a domain shader stage <NUM>, and a geometry shader stage <NUM>. The hull shader stage <NUM> operates on input high-order patches or control points that are used to define the input patches. The hull shader stage <NUM> outputs tessellation factors and other patch data. Primitives generated by the hull shader stage <NUM> can be provided to the tessellator stage <NUM> by the patch fetcher <NUM>. The tessellator stage <NUM> receives objects (such as patches) from the hull shader stage <NUM> and generates information identifying primitives corresponding to the input object, e.g., by tessellating the input objects based on tessellation factors provided to the tessellator stage <NUM> by the hull shader stage <NUM>. Tessellation subdivides input higher-order primitives such as patches into a set of lower-order output primitives that represent finer levels of detail, e.g., as indicated by tessellation factors that specify the granularity of the primitives produced by the tessellation process. A model of a scene can therefore be represented by a smaller number of higher-order primitives (to save memory or bandwidth) and additional details can be added by tessellating the higher-order primitive.

The domain shader stage <NUM> inputs a domain location and, in some implementations, other patch data. The domain shader stage <NUM> operates on the provided information and generates a single vertex for output based on the input domain location and other information. A geometry shader stage <NUM> receives an input primitive and outputs up to four primitives that are generated by the geometry shader stage <NUM> based on the input primitive. In some embodiments, the geometry shader stage <NUM> retrieves vertex data from graphics memory <NUM> and generates new graphics primitives, such as lines and triangles, from the vertex data in graphics memory <NUM>. In particular, geometry shader stage <NUM> retrieves vertex data for a primitive, as a whole, and generates zero or more primitives. For example, geometry shader stage <NUM> can operate on a triangle primitive with three vertices.

Once the vertex processing stage <NUM> is complete, the scene is defined by a set of vertices which each have a set of vertex parameter values stored in the graphics memory <NUM>. In certain implementations, the vertex parameter values output from the vertex processing stage <NUM> include positions defined with different homogeneous coordinates for different zones.

The graphics processing pipeline <NUM> then proceeds to rasterization processing stages <NUM>. The rasterization processing stages <NUM> perform shading operations and other operations such as clipping, perspective dividing, scissoring, and viewport selection, and the like. In various embodiments, the rasterization processing stages <NUM> convert the scene geometry into screen space and a set of discrete picture elements (e.g., pixels used during the graphics processing pipeline, although it is noted that the term pixel does not necessarily mean that the pixel corresponds to a display pixel value in the final display buffer image). The virtual space geometry transforms to screen space geometry through operations that compute the projection of the objects and vertices from world space to the viewing window (or "viewport") of the scene that is made up of a plurality of discrete screen space pixels sampled by the rasterizer. In accordance with aspects of the present disclosure, the screen area includes a plurality of distinct zones with different rendering parameters, which include different rasterization parameters for the different zones.

The rasterization processing stage <NUM> depicted in the figure includes a primitive assembly stage <NUM>, which sets up the primitives defined by each set of vertices in the scene. Each vertex is defined by a vertex index, and each primitive is defined with respect to these vertex indices and stored in index buffers in the graphics memory <NUM>. The primitives should include at least triangles that are defined by three vertices each, but also include point primitives, line primitives, and other polygonal shapes. During the primitive assembly stage <NUM>, certain primitives are culled. For example, those primitives whose vertex indices and homogeneous coordinate space positions indicate a certain winding order are considered to be back-facing and therefore culled from the scene. Primitive assembly stage <NUM> also includes screen space transformations for the primitive vertices, which can include different screen space transform parameters for different zones of the screen area.

The rasterization processing stage <NUM> performs clipping, a perspective divide to transform the points into homogeneous space and maps the vertices to the viewport. The raster data is snapped to integer locations that are then culled and clipped (to draw the minimum number of pixels), and per-pixel attributes are interpolated (from per-vertex attributes). In this manner, the rasterization processing stage <NUM> determines which pixel primitives overlap, clips primitives and prepares primitives for the pixel shader and determines how to invoke the pixel shader stage <NUM>.

In traditional geometry pipelines, the hull shader stage <NUM> writes all tessellation factors for all patches to the graphics memory <NUM> and the patch fetcher <NUM> reads all tessellation factors for all patches from the graphics memory <NUM>, which can waste computing resources and create processing bottlenecks. For example, frequently there are large runs in which all or a high percentage of the tessellation factors are the same. The hull shader stage <NUM> detects whether at least a threshold percentage of the tessellation factors for a thread group of patches are the same. If at least the threshold percentage of the tessellation factors for the thread group are the same, in some embodiments the hull shader stage <NUM> further detects whether at least the threshold percentage of the tessellation factors for the thread group either indicate that the patches of the thread group are to be culled (e.g., have a value of zero) or indicate that the patches of the thread group are to be passed to the tessellator stage <NUM> (e.g., have a value of one). In response to detecting that at least the threshold percentage of the tessellation factors for the thread group are the same, the hull shader stage <NUM> bypasses writing at least a subset of the tessellation factors to the graphics memory <NUM>. For example, in response to detecting that at least the threshold percentage of tessellation factors for a thread group of patches all have the same value of zero or one, the hull shader stage <NUM> sends a message to the patch fetcher <NUM>. The hull shader stage <NUM> bypasses writing the tessellation factors to the graphics memory <NUM> and the patch fetcher <NUM> bypasses reading the tessellation factors from the graphics memory <NUM> in response to receiving the message. In response to detecting that at least the threshold percentage of the tessellation factors for the thread group are the same, but are not equal to zero or one, the hull shader stage <NUM> writes a single instance of the value of the majority of tessellation factors to the graphics memory <NUM> and sends a message to the patch fetcher <NUM> indicating that the single value of the tessellation factors stored at the graphics memory <NUM> applies to all of the patches of the thread group.

<FIG> depicts the hull shader stage <NUM> of the graphics pipeline of <FIG> bypassing writing tessellation factors to the graphics memory <NUM> and sending an indication to a patch fetcher <NUM> of the graphics pipeline that all tessellation factors for a thread group have a value indicating that the patches of the thread group are to be culled in accordance with some embodiments. In response to the hull shader stage <NUM> detecting that at least the threshold percentage of the tessellation factors for the patches of a thread group have a value indicating that the patches of the thread group are to be culled (e.g., have a value of zero), the hull shader stage <NUM> bypasses writing the tessellation factors for the thread group to the graphics memory <NUM>. The hull shader stage <NUM> also sends a message <NUM> to the patch fetcher <NUM> indicating that all of the tessellation factors for all of the patches of the thread group have a value indicating that the patches of the thread group are to be culled (e.g., are equal to zero). In response to receiving the message <NUM>, the patch fetcher <NUM> bypasses reading tessellation factors for the thread group from the graphics memory <NUM>. Because a tessellation factor of zero culls patches, the patch fetcher <NUM> additionally discards the patches of the thread group rather than passing them to the tessellator stage (not shown).

<FIG> depicts the hull shader stage <NUM> of the graphics pipeline of <FIG> bypassing writing tessellation factors to the graphics memory <NUM> and sending an indication to a patch fetcher <NUM> of the graphics pipeline in response to detecting that at least the threshold percentage of the tessellation factors for a thread group have a value indicating that the patches of the thread group are to be passed to the tessellator stage in accordance with some embodiments. In response to the hull shader stage <NUM> detecting that at least the threshold percentage of the tessellation factors for the patches of a thread group have a value indicating that the patches of the thread group are to be passed to the tessellator stage (e.g., have a value of one), the hull shader stage <NUM> bypasses writing the tessellation factors for the thread group to the graphics memory <NUM>. The hull shader stage <NUM> also sends a message <NUM> to the patch fetcher <NUM> indicating that the tessellation factors for the patches of the thread group have a value indicating that the patches of the thread group are to be passed to the tessellator stage (e.g., are equal to one). In response to receiving the message <NUM>, the patch fetcher <NUM> bypasses reading tessellation factors for the thread group from the graphics memory <NUM>. The patch fetcher <NUM> additionally unrolls the patches of the thread group and passes them to the tessellator (not shown).

<FIG> depicts the hull shader stage <NUM> of the graphics pipeline of <FIG> writing a single instance of a value of a tessellation factor to the graphics memory <NUM> and sending an indication to a patch fetcher <NUM> of the graphics pipeline that the single tessellation factor value applies for all tessellation factors for a patch in accordance with some embodiments. In response to detecting that all of the tessellation factors associated with a patch <NUM> have the same value, the hull shader stage <NUM> bypasses writing all of the tessellation factors for the patch to the graphics memory <NUM>. Instead, the hull shader stage <NUM> writes a single instance of the tessellation factor <NUM> to the graphics memory <NUM> and sends a flag <NUM> to the patch fetcher <NUM> indicating that the single instance of the tessellation factor value applies to all tessellation factors corresponding to the patch <NUM>. In response to receiving the flag <NUM>, the patch fetcher <NUM> reads the patch <NUM> and the single instance of the tessellation factor <NUM> from the graphics memory <NUM>. The patch fetcher <NUM> applies to the tessellation factor <NUM> to all tessellation factors corresponding to the patch <NUM> and provides the patch <NUM> and the tessellation factor <NUM> to the tessellator stage <NUM>, which uses the tessellation factor to generate the final primitives.

<FIG> depicts a plurality of tessellation factors for a patch packaged in a single word in accordance with some embodiments. In some embodiments, a hull shader stage writes tessellation factors to a graphics memory in <NUM>-bit words. Each tessellation factor has a value between <NUM> and <NUM>. Accordingly, each tessellation factor can be written using <NUM> bits. To reduce the number of words being written to and read from the graphics memory <NUM>, in some embodiments the hull shader stage (not shown) packages a plurality of tessellation factors in a single word. For example, an isoline patch has two tessellation factors. The hull shader stage writes to the graphics memory (not shown) a single word <NUM> including a first tessellation factor TF-<NUM><NUM> and a second tessellation factor TF-<NUM><NUM> corresponding to an isoline patch. As another example, a triangle patch has four tessellation factors. The hull shader stage writes to the graphics memory a single word <NUM> including a first tessellation factor TF-<NUM><NUM>, a second tessellation factor TF-<NUM><NUM>, a third tessellation factor TF-<NUM><NUM>, and a fourth tessellation factor TF-<NUM><NUM> corresponding to a triangle patch. Similarly, a quad patch has six tessellation factors. Because all six <NUM>-bit tessellation factors cannot fit in a single <NUM>-bit word, the hull shader stage packages the six tessellation factors corresponding to a quad patch into two words. For example, the hull shader stage writes to the graphics memory a first word <NUM> including a first tessellation factor TF-<NUM><NUM>, a second tessellation factor TF-<NUM><NUM>, and a third tessellation factor TF-<NUM><NUM>, and a second word <NUM> including a fourth tessellation factor TF-<NUM><NUM>, a fifth tessellation factor TF-<NUM><NUM>, and a sixth tessellation factor TF-<NUM><NUM> corresponding to a quad patch. Thus, the hull shader stage reduces the number of words of tessellation factors being written to and read from the graphics memory from two to one (in the case of an isoline patch), from four to one (in the case of a triangle patch), and from six to two (in the case of a quad patch).

<FIG> is a flow diagram illustrating a method <NUM> for bypassing writing at least a subset of tessellation factors to memory in accordance with some embodiments. In some embodiments, the method is implemented by the graphics pipeline <NUM> of <FIG> or the graphics processing pipeline <NUM> of <FIG>.

At block <NUM>, the hull shader stage <NUM> determines whether at least a threshold percentage of the tessellation factors for all patches of a thread group have equal values. If, at block <NUM>, the hull shader stage <NUM> determines that at least the threshold percentage of the tessellation factors for all patches of the thread group do not have equal values, the method flow continues to block <NUM>. At block <NUM>, the hull shader stage <NUM> determines whether all of the tessellation factors for a patch of the thread group have equal values. If, at block <NUM>, the hull shader stage <NUM> determines that all of the tessellation factors for the patch do not have equal values, the method flow continues to block <NUM>. At block <NUM>, the hull shader stage <NUM> writes the tessellation factors for the patch to the graphics memory <NUM>. In some embodiments, the hull shader stage <NUM> writes a plurality of tessellation factors corresponding to the patch in a single word. For example, for an isoline patch having two tessellation factors, the hull shader stage <NUM> writes both tessellation factors for the isoline patch in a single word. For a triangle patch having four tessellation factors, the hull shader stage <NUM> writes all four tessellation factors for the triangle in a single word. For a quad patch having six tessellation factors, the hull shader stage <NUM> writes, e.g., the first three tessellation factors for the quad patch in a first word and the second three tessellation factors for the quad patch in a second word.

If, at block <NUM>, the hull shader stage <NUM> determines that at least the threshold percentage of the tessellation factors for the patch have equal values, the method flow continues to block <NUM>. At block <NUM>, the hull shader stage <NUM> writes a single instance of the tessellation factor to the graphics memory <NUM> and send a flag <NUM> to the patch fetcher indicating that the single instance of the tessellation factor applies for all tessellation factors corresponding to the patch.

If, at block <NUM>, the hull shader stage <NUM> determines that at least the threshold percentage of the tessellation factors for all patches of the thread group have equal values, the method flow continues to block <NUM>. At block <NUM>, the hull shader stage <NUM> determines whether at least the threshold percentage of the tessellation factors for all patches of the thread group have a value that indicates that the patches of the thread group are to be culled. If, at block <NUM>, the hull shader stage <NUM> determines that at least the threshold percentage of the tessellation factors for all of the patches of the thread group have a value that indicates that the patches of the thread group are to be culled, the method flow continues to block <NUM>. At block <NUM>, the hull shader stage <NUM> bypasses writing the tessellation factors for the thread group to the graphics memory <NUM> and sends a message <NUM> to the patch fetcher <NUM> indicating that the tessellation factors for the thread group have a value that indicates that the patches of the thread group are to be culled. In response to receiving the message <NUM>, the patch fetcher <NUM> bypasses reading tessellation factors for the thread group from the graphics memory <NUM> and culls (discards) the patches of the thread group.

At block <NUM>, if the hull shader stage <NUM> determines that at least the threshold percentage of the tessellation factors for all of patches of the thread group do not have a value that indicates that the patches of the thread group are to be culled, the method flow continues to block <NUM>. At block <NUM>, the hull shader stage <NUM> determines whether at least the threshold percentage of the tessellation factors for all of patches of the thread group have a value that indicates that the patches of the thread group are to be passed to the tessellator stage <NUM>. If, at block <NUM>, the hull shader stage determines that at least the threshold percentage of the tessellation factors for all of the patches of the thread group have a value that indicates that the patches of the thread group are to be passed to the tessellator stage <NUM>, the method flow continues to block <NUM>. At block <NUM>, the hull shader stage <NUM> bypasses writing the tessellation factors for the patches of the thread group to the graphics memory <NUM> and sends a message <NUM> to the patch fetcher <NUM> indicating that all of the tessellation factors for all of the patches of the thread group have a value that indicates that the patches of the thread group are to be passed to the tessellator stage <NUM>. In response to receiving the message <NUM>, the patch fetcher <NUM> unrolls the patches from the graphics memory <NUM> and provides the patches to the tessellator stage <NUM>. If, at block <NUM>, the hull shader stage <NUM> determines that at least the threshold percentage of the tessellation factors for all of the patches of the thread group do not have a value that indicates that the patches of the thread group are to be passed to the tessellator stage <NUM>, the method flow continues to block <NUM>. In this case, because the hull shader stage has determined that at least the threshold percentage of the tessellation factors for all of the patches of the thread group have equal values, at block <NUM>, the hull shader writes a single instance of the most common tessellator factor value to the graphics memory <NUM> and sends a flag <NUM> to the patch fetcher indicating that the single tessellator factor stored at the graphics memory <NUM> applies for all of the tessellation factors for all of the patches of the thread group.

A computer readable storage medium includes any non-transitory storage medium, or combination of non-transitory storage media, accessible by a computer system during use to provide instructions and/or data to the computer system. The computer readable storage medium in some embodiments is embedded in the computing system (e.g., system RAM or ROM), fixedly attached to the computing system (e.g., a magnetic hard drive), removably attached to the computing system (e.g., an optical disc or Universal Serial Bus (USB)-based Flash memory), or coupled to the computer system via a wired or wireless network (e.g., network accessible storage (NAS)).

In some embodiments, certain aspects of the techniques described above are implemented by one or more processors of a processing system executing software. The software includes one or more sets of executable instructions stored or otherwise tangibly embodied on a non-transitory computer readable storage medium. The executable instructions stored on the non-transitory computer readable storage medium are in source code, assembly language code, object code, or other instruction format that is interpreted or otherwise executable by one or more processors.

Note that not all of the activities or elements described above in the general description are required, that a portion of a specific activity or device are not necessarily required, and that one or more further activities could be performed, or elements included, in addition to those described.

Claim 1:
A method comprising:
in response to detecting, at a hull shader stage of a graphics pipeline of a graphics processing unit (GPU), that at least a threshold percentage of tessellation factors corresponding to a plurality of patches in a thread group has the same value, bypassing writing at least a subset of the tessellation factors corresponding to the plurality of patches to a graphics memory of the graphics pipeline.