Graphics processing system

Abstract

The present invention relates to a graphics processor comprising one or more processing circuitry operable to implement a set of generic pipeline stages that may be configured as respective different shader stages to be executed for a processing pipeline. The appropriate pipeline configuration information is used to control the operation of the processing circuitry executing the desired processing pipeline. The suitable pipeline configuration information may be communicated to a local storage associated with the processing pipeline in response to execution of a command to perform a process using the processing pipeline (and thus the processing pipeline may also be reconfigured by updating the pipeline configuration information).

Description

[0001] The present invention relates to graphics processing and graphics processors, and in particular to the operation and configuration of graphics processors that execute a (graphics) processing pipeline.

[0002] Graphics processing is typically performed by first dividing the scene to be displayed (e.g., a 3-D model) into a number of similar basic components or "primitives," which are then subjected to the desired graphics processing operations. These graphics "primitives" are typically in the form of simple polygons, such as triangles.

[0003] Each primitive is typically defined by and represented as a set of vertices, where each vertex typically has associated with it a set of "attributes," i.e., a set of data values ​​for that vertex. These attributes will typically include positional data and other non-positional data (variables), such as the color, light, normal, texture coordinates, etc., that define the vertex in question.

[0004] For a given output to be generated by a graphics processing system (e.g., a frame to be displayed), there will typically be a set of vertices defined for the output in question. Primitives to be processed for the output are then indicated as including given vertices from that set of vertices for the graphics processing output being generated. Typically, the total output (e.g., a frame to be generated) will be divided into smaller processing units, referred to as "draw calls." Each draw call will have a corresponding set of vertices defined for it and a set of primitives that use those vertices.

[0005] Once the primitives and their vertices have been generated and defined, they can be processed by a graphics processing system in order to generate the desired graphics processing output (render target), such as a frame for display. This essentially involves rendering the primitives to generate the graphics processing output.

[0006] The rendering process uses vertex attributes associated with the vertices of the primitive being processed. To facilitate this operation, the vertices defined for a given graphics processing output (e.g., a draw call) are typically subjected to an initial so-called "vertex shading" operation before rendering the primitives.

[0007] A vertex shading operation typically produces a (transformed) vertex position and one or more outputs that are explicitly written by the vertex shader. (Attributes other than position that are output from a vertex shader are often called "variants").

[0008] Thus, a graphics processing pipeline will typically include one or more vertex shading stages (vertex shaders) that perform vertex shading operations, for example using initial vertex attribute values ​​defined for the vertices (and otherwise), in order to generate a desired set of output vertex attributes (i.e., appropriately "shaded" attributes) for use in subsequent pipeline stages of the graphics processing pipeline.

[0009] Once vertex attributes have been shaded, the "shaded" attributes are used when processing the vertices (and the primitives to which those vertices relate) in the remainder of the graphics processing pipeline.

[0010] For example, "vertex shaded" vertex positions and transformations may be used when rendering primitives to provide rendered output, such as when performing rasterization and / or fragment shading operations. In the case of a tile-based graphics processing pipeline (where a two-dimensional rendered output (target) is rendered as multiple smaller area sub-regions, often referred to as "tiles"), vertex shaded (transformed) positions may be used to categorize primitives relative to rendered tiles and / or derive a data structure for allowing categorization of primitives relative to rendered tiles.

[0011] Thus, a vertex shading operation in a graphics processing pipeline will process one or more (and typically multiple) vertices (which may be correspondingly viewed as corresponding "work items" of the shading operation) to produce one or more corresponding "vertex-shaded" attributes for each vertex (work item) processed (the one or more attributes may be correspondingly viewed as corresponding data elements of the vertex (work item) in question).

[0012] The graphics processing pipeline may also include various other (shading) stages that process respective work items and generate one or more respective data elements for each of the work items processed by the various other (shading) stages.

[0013] For example, in a higher-level geometry processing flow (e.g., where tessellation is enabled), the vertex shading stage described above may be followed by one or more tessellation stages, which typically include: a tessellation control shader (TCS) stage (e.g., which determines the amount of tessellation to be performed); a tessellation stage that performs the desired tessellation operation (e.g., by executing a tessellation shader and / or using (fixed-function) tessellation hardware circuitry); and a tessellation evaluation shader (TES) (which applies interpolation or other post-processing operations to the tessellated output). A higher-level graphics processing flow may also include other stages that perform vertex post-processing, such as, but not limited to, a transform feedback stage that captures primitives generated by vertex processing.

[0014] As another example, a graphics processing pipeline can be configured to implement so-called "task" and "mesh" shading stages (shaders) rather than performing vertex processing (shading) in the manner described above. In contrast to traditional vertex shading operations, where a vertex shader can simply load a certain number of vertices and then process (i.e., shade) those vertices, a mesh shading stage (mesh shader) can operate to create its own output vertices and primitives.

[0015] For example, a task shading stage (task shader) (sometimes also called an "amplification" shader) may be executed to determine how many sub-mesh shader workgroups should be launched in a subsequent mesh shading stage (mesh shader). Each mesh shader workgroup may then produce a corresponding set of output vertices and primitives (i.e., a "meshlet"), with all mesh shader workgroups working together to create the full output mesh (and thus mesh shaders may perform "compute" shader-like processing, where mesh shader workgroups collaboratively generate meshes).

[0016] The task shader may also optionally output a payload that is passed to any of its sub-mesh shader work groups.

[0017] The use of such "task" and "mesh" shaders can therefore provide greater flexibility to the application programmer, at least in some cases, compared to, for example, a graphics processing pipeline that implements more traditional vertex shading operations, because the inputs to and outputs from the "task" and "mesh" shaders can be customized.

[0018] Thus, a graphics processor can execute a graphics processing pipeline to support a desired graphics processing flow, and the graphics processor (hardware) can be configured accordingly to support the specific graphics processing pipeline desired to be executed by the graphics processor. In this regard, it is possible to execute any desired graphics processing pipeline in software, for example using general-purpose compute shader operations. However, this is generally not efficient, and therefore some level of hardware support is often provided for graphics processing pipelines, where pipeline stages are typically dedicated to performing certain processing operations for executing certain graphics processing pipelines.

[0019] However, the applicant believes that there is still room for improvement in the respect that a graphics processor will execute a (graphics) processing pipeline.

[0020] According to a first aspect of the present invention, there is provided a method for operating a graphics processor, the graphics processor comprising:

[0021] one or more processing circuits operable to implement a set of general pipeline stages, wherein respective ones of the general pipeline stages in the set of general pipeline stages are configurable as respective different shader stages to be executed as part of a processing pipeline,

[0022] The method includes:

[0023] obtaining, for one or more instances of execution of a processing pipeline, a set of pipeline configuration information, the set of pipeline configuration information comprising (at least) an indication of a respective set of one or more shader stages to be executed for the processing pipeline;

[0024] transferring the obtained set of pipeline configuration information to a storage device associated with the processing pipeline (processing circuit); and

[0025] Operation of the one or more processing circuits is controlled using the stored set of pipeline configuration information to execute the processing pipeline for the one or more instances of the processing pipeline execution.

[0026] According to a second aspect of the present invention, there is provided a graphics processor, the graphics processor comprising:

[0027] one or more processing circuits operable to implement a set of general pipeline stages, wherein respective ones of the general pipeline stages in the set of general pipeline stages are configurable as respective different shader stages to be executed as part of a processing pipeline,

[0028] The method includes:

[0029] In response to the graphics processor receiving a command to perform processing using the processing pipeline:

[0030] transferring a set of pipeline configuration information indicating (at least) a respective set of shader stages to be executed for the processing pipeline to a storage device associated with the processing pipeline (processing circuitry); and

[0031] The graphics processor uses the stored pipeline configuration information to control operation of the one or more processing circuits to execute the processing pipeline for the one or more instances of the processing pipeline execution.

[0032] The present invention relates generally to graphics processing systems / graphics processors, and in particular to the operation of a graphics processor to implement and support a novel and advantageous '(re)configurable' processing pipeline concept, as will be further explained below.

[0033] Specifically, a processing pipeline can be and is executed by a set of 'generic' (programmable) pipeline stages that can be configured to map to a corresponding desired set of (different) stages of the (graph) processing pipeline to be executed. Thus, this configuration of the (generic) pipeline stages can be and is preferably performed before and for a specific instance (or instances) of the processing pipeline execution, e.g., before any work is issued to the processing pipeline for the specific instance of the processing pipeline execution. Once configured, the processing pipeline can then be executed accordingly to process the 'grouping' of work items to generate the overall pipeline output.

[0034] The processing pipeline that can be (and is) performed by a graphics processor according to the present invention is therefore preferably hardware-implemented (e.g., rather than being performed entirely in software, such as using potentially less efficient general-purpose computer shaders), but the processing pipeline (hardware) is preferably configured in software, and is therefore preferably also reconfigurable in software as needed, such as for different instances of the processing pipeline execution (e.g., between rendering passes, or even within a rendering pass (e.g., between draw calls)).

[0035] This can then provide a more flexible and configurable approach, as the 'generic' pipeline stages can be configured and used to support a variety of different graphics processing flows (e.g. including more advanced geometry processing flows, such as utilising task / mesh shaders, tessellation shaders, transform feedback, etc.), and this is preferably done using the same underlying (generic) pipeline stage hardware (circuitry), but with the pipeline stages triggering different processing (e.g., and preferably, by triggering different (shader) program executions) depending on the specific configuration of the pipeline stages that define the processing pipeline.

[0036] For example, a desired graphics processing flow can be appropriately mapped onto a processing pipeline, and then the pipeline stages (hardware) are appropriately configured and programmed to support the graphics processing flow before one or more instances of the processing pipeline are executed. In this way, the same underlying hardware (circuitry) can be used to support multiple different graphics processing flows.

[0037] Thus, a graphics processor according to the present invention includes one or more processing circuits (referred to herein as "shader stage circuits") that may be used to implement a set of 'general-purpose' pipeline stages (where, as mentioned above, each general-purpose pipeline stage in the set of general-purpose pipeline stages may be configured as a respective different shader stage to be executed as part of a processing pipeline).

[0038] Prior to any instance of processing pipeline execution (e.g., where an instance may include executing the processing pipeline with respect to a single draw call, a set of draw calls, or some other suitable set of work for which the processing pipeline is to be executed), the processing pipeline may therefore need to be, and be, appropriately (re)configured to implement the desired set of shader stages using the shader stage circuitry to perform the desired sequence of pipelined processing operations.

[0039] The present invention particularly relates to the (initial) configuration and control of one or more processing (shader stage) circuits to implement a desired processing pipeline.

[0040] Thus, according to the present invention, prior to processing a given instance of pipeline execution (e.g., with respect to a draw call), a corresponding set of pipeline configuration information applicable to that instance of processing pipeline execution is preferably determined with respect to that instance of processing pipeline execution (and potentially for one or more other instances).

[0041] This determination is preferably made in advance in software, for example, and preferably on a host (e.g., a host) processor (e.g., a CPU) of a data processing system of which the graphics processor is a part. For example, the graphics processor may be requested to perform processing work for an application being executed on the host (host) processor, and the host (host) processor (the application being executed on the host processor) may also determine the desired processing pipeline configuration, e.g., including (at least) a set of shader stages to be executed for the processing pipeline. Information indicating this determination may then be appropriately provided to the graphics processor, e.g., as part of a set of commands issued from the host (host) processor to the graphics processor to cause the graphics processor to perform the processing work, and this pipeline configuration information may then be used by the graphics processor to control the execution of the processing pipeline in the desired manner, as will be further described below.

[0042] However, other arrangements are possible.

[0043] For example, in some embodiments, a graphics processor may be capable of populating its own command set, and in that case, the graphics processor (e.g., its command processing circuitry (job manager / command stream front end)) itself may be operable and configured to determine some or all of the pipeline configuration information to be used to control execution of the processing pipeline.

[0044] In this regard, various arrangements would be possible.

[0045] The determined pipeline configuration information may include any suitable and desired information that may be used to control execution of the processing pipeline.

[0046] In this regard, the determined pipeline configuration information should include (at least) an indication of a set of one or more shader stages (and preferably a plurality of shader stages) to be executed for one or more instances of execution of the processing pipeline to which the pipeline configuration information relates.

[0047] The set of shader stages to be executed for a particular instance (or instances) of a processing pipeline execution may generally be any suitable and desired shader stages that may be supported by a general-purpose pipeline stage.

[0048] In a preferred embodiment, the set of shader stages to be executed thus includes some or all of the available set of multiple shader stages that can be supported by a general-purpose pipeline stage for implementing a processing pipeline according to the present invention.

[0049] Typically, at least in the context of graphics processing, there may only be certain 'valid' combinations of shader stages associated with certain well-defined graphics processing flows (e.g., specified by a graphics API). For example, in the case of performing mesh shading, this should typically be followed by a task shader, and the mesh shader should typically be the last shader stage. Similarly, a graphics API may define certain graphics processing flows, including certain combinations of vertex, tessellation, geometry, and transform feedback shading. Therefore, the set of shader stages to be executed for a particular instance (or instances) of a processing pipeline should, and preferably will, correspond to the specific, defined (e.g., by the graphics API) processing flow that will be supported.

[0050] (However, an effect and benefit of the present invention is that the set of available multiple shader stages can potentially be expanded over time, for example to support new graphics processing flows, and this is still supported using the same underlying hardware (circuitry)).

[0051] After the initial pipeline configuration has been determined, however, having done so, associated pipeline configuration information may therefore be suitably obtained by the graphics processor, and the obtained pipeline configuration information may then be used to configure the processing pipeline and thereby control execution of the processing pipeline to perform the desired processing.

[0052] For example, pipeline configuration information (including information indicating the respective sets of shader stages to be executed for a graphics processing pipeline) is typically determined in advance, and therefore, once the set of pipeline configuration information has been determined, the pipeline configuration information can be, and preferably is, suitably stored (e.g., in (external) memory) so that the pipeline configuration information can subsequently be transmitted to the graphics processor and thereby used to configure and control the operation of the shader stage circuitry to control execution of the processing pipeline.

[0053] Specifically, according to the present invention, a graphics processor is operable and configured to obtain pipeline configuration information for a given instance of a graphics processing pipeline execution from any location where relevant pipeline configuration information is stored (including generating some or all of the pipeline configuration information by the graphics processor itself). Therefore, before executing a given instance of a processing pipeline execution to which a particular set of pipeline configuration information relates, the pipeline configuration information should and preferably should be transferred to a suitable (e.g., local) storage device associated with and usable by the processing pipeline (i.e., a storage device associated with the processing (shader stage) circuitry that implements the processing pipeline). Once the relevant pipeline configuration information has been transferred to the local storage device associated with the processing pipeline (processing (shader stage) circuitry), the processing pipeline can be executed accordingly to execute the specific instance or instances of the processing pipeline execution to which the pipeline configuration information relates.

[0054] In this regard, it should be understood that the local storage associated with a graphics processing pipeline (processing (shader stage) circuitry) may include any suitable and desired storage. Furthermore, the storage may be arranged and configured in any suitable and desired manner. For example, in a preferred embodiment, each pipeline stage is associated with a respective portion of the overall local storage associated with the graphics processing pipeline (processing (shader stage) circuitry), which respective portion may be (and is) used to store a relevant portion of the pipeline configuration information for that pipeline stage (and preferably only the portion of the pipeline configuration information relevant to that pipeline stage). Accordingly, the local storage associated with a processing pipeline (processing (shader stage) circuitry) may also include additional 'global' pipeline storage that may fully store the pipeline configuration information (i.e., all pipeline configuration information relevant to each of the pipeline stages).

[0055] Preferably, this storage is dedicated to storing pipeline configuration information (and is therefore preferably separate from any storage / memory (pool) used to store actual data packets / elements generated, for example, for / by the graphics processing pipeline).

[0056] In this regard, various arrangements would be possible.

[0057] As will be explained further below, the issuance of processing work to the processing pipeline is preferably controlled by the graphics processor's command processing circuitry (job manager / command stream front end). Specifically, the command processing circuitry (job manager / command stream front end) is preferably operable to receive higher-level commands from a host (e.g., a host) processor requesting the graphics processor to perform processing work for an application executing on the host processor. The command processing circuitry (job manager / command stream front end) is then operable to schedule or distribute the appropriate processing tasks to the graphics processor's processing units, including the processing pipeline. Accordingly, when a command relates to processing to be performed for / using a processing pipeline, the command processing circuitry (job manager / command stream front end) preferably identifies this and appropriately passes the command (or information derived from the command) to a command buffer for the processing pipeline.

[0058] Thus, issuing processing work to the processing pipeline is preferably triggered by executing a corresponding set of one or more commands within a command set for the graphics processor from a command buffer for the processing pipeline, which commands, when executed, trigger one or more instances of execution of the processing pipeline. Preferably, there is a single such command (referred to herein as a 'RUN_PIPELINE' command) operable to trigger one or more instances of graphics processing execution.

[0059] Thus, such a (RUN_PIPELINE) command may (and preferably is) included at appropriate points in the graphics processing command set to trigger one or more instances of processing pipeline execution as and when desired.

[0060] According to the present invention, the same corresponding (RUN_PIPELINE) command that triggers one or more instances of processing pipeline execution preferably also causes relevant pipeline configuration information to be transferred to local storage associated with the processing pipeline (processing (shader stage) circuitry).

[0061] For example, the input values ​​of the (RUN_PIPELINE) command found in the command's arguments preferably indicate corresponding pipeline configuration information to be used for the instance of processing pipeline execution to be triggered by the (RUN_PIPELINE) command. In other words, the pipeline configuration information, or at least information that can be used to identify the pipeline configuration information, is preferably indicated in the set of (RUN_PIPELINE) commands themselves.

[0062] Therefore, when the (RUN_PIPELINE) command is executed, the relevant pipeline configuration information is preferably transferred to a local storage device associated with the processing pipeline (processing (shader stage) circuit), and the relevant pipeline configuration is preferably indicated in the (same) (RUN_PIPELINE) command that triggers the execution of the graphics processing pipeline.

[0063] For example, in a preferred embodiment, pipeline configuration information may be initially transferred to the graphics processor by the command processing circuitry (job manager / command stream front end) for the graphics processor (e.g., from a location in (external) memory where the pipeline configuration information resides). In this case, the pipeline configuration information may be, and preferably is, initially loaded into a set of registers of the graphics processor (these registers may, for example, and preferably are, resident in the command processing circuitry (job manager / command stream front end) for the graphics processor, e.g., the registers may be operated on and used in the normal manner for such registers).

[0064] Execution of a (RUN_PIPELINE) command to trigger execution of a processing pipeline then preferably also causes relevant pipeline configuration information to be transferred from such registers into local storage associated with the processing pipeline (processing (shader stage) circuitry).

[0065] Therefore, the input arguments for the (RUN_PIPELINE) command preferably indicate which registers should be read and the data from those registers is then used to transfer the relevant pipeline configuration to the appropriate location within the local storage device associated with the processing pipeline (processing (shader stage) circuit). For example, in some cases, the required data values ​​may be loaded directly into registers and thus transferred directly to the local storage device associated with the processing pipeline (processing (shader stage) circuit). However, it may also be the case that an identifier for the required data (e.g., a pointer to the required data) is loaded into a register, which is then read and used to transfer the required data value to the local storage device associated with the processing pipeline (processing (shader stage) circuit).

[0066] In this regard, various arrangements would be possible.

[0067] Applicants have discovered that transferring pipeline configuration information to a local storage device associated with a processing pipeline (processing (shader stage) circuitry) in this manner can be particularly efficient because the (entire) set of pipeline configuration information can be efficiently transferred to such local storage device at once, i.e. in response to the (same) set of execute (RUN_PIPELLINE) commands (e.g., rather than the main (host) processor having to explicitly include a separate command for moving each item of pipeline configuration information from the register / location where it is stored to the local storage device associated with the processing pipeline (processing (shader stage) circuitry), which would potentially require many commands to do so).

[0068] Thus, a copy of the relevant pipeline configuration information can (and is) stored locally in association with a processing pipeline (processing (shader stage) circuit). The locally stored pipeline configuration information can then (and is) used to control the operation of one or more processing (shader stage) circuits to implement the corresponding set of shader stages that the pipeline configuration information indicates should be executed for the processing pipeline. This is preferably done by executing a corresponding set of 'generic' pipeline stages, as will be explained further below. The locally stored pipeline configuration information will therefore determine the specific processing operations performed by the corresponding (generic) pipeline stage to determine the output generated by the processing pipeline.

[0069] Pipeline configuration information may therefore include any (and all) suitable pipeline 'state' information that may be suitably used to configure / control execution of the graphics processing pipeline in this manner.

[0070] For example, as mentioned above, the processing pipeline executed by a graphics processor according to the present invention includes a number of 'generic' pipeline stages, wherein each (generic) pipeline stage is operable to process a 'group' of work items in a similar manner, i.e., is operable to perform the same basic sequence of processing operations, but different processing is actually performed by different pipeline stages (e.g., and in particular, by different pipeline stages that call different shader programs) based on the type of grouping and / or the configuration (state) of the pipeline stages at issue for the current instance of processing pipeline execution.

[0071] Therefore, in addition to information indicating the respective set of shader stages that should be executed for the processing pipeline, the pipeline configuration information may also and preferably includes information indicating the respective shader programs to be executed by each shader stage. This information may preferably be indicated in the form of a bit mask indicating which shader programs from the set of available shader programs (e.g., from a predetermined shader binding table) are to be executed for which shader stages.

[0072] However, various arrangements would be possible in this regard.

[0073] For a particular instance of processing pipeline execution, it may be necessary to store data generated by a given pipeline stage for subsequent use by other pipeline stages, and for those other pipeline stages to be able to appropriately access that data.

[0074] In order to facilitate the flow of data between pipeline stages, (each) (general) pipeline stage may therefore be associated with at least one memory pool that can be allocated for temporarily storing portions of the data of the groups of work items to be processed within that pipeline stage. Thus, in a preferred embodiment, at least some of the (general) pipeline stages are associated with respective memory pools that can be allocated for temporarily storing portions of the data of the groups of work items to be processed within that pipeline stage.

[0075] A given (general) pipeline stage can therefore allocate a corresponding portion of its memory pool for the corresponding packets processed / generated within that pipeline stage. However, there may then be one or more other later pipeline stages that also potentially need access to (the data of) the packets generated / processed by the earlier pipeline stages. That is, the data about the packets generated by a specific earlier pipeline stage may also be required as input for processing the corresponding (sub) packets in certain later pipeline stages. Therefore, such later pipeline stages should and preferably do also have access to any memory pool that stores data that such later pipeline stages may need. Such later pipeline stages may also preferably update the data within such memory pools, but may not perform new allocations within such memory pools.

[0076] That is, preferably, for a particular instance of processing pipeline execution (e.g., for a particular render pass or draw call within a render pass), only a single pipeline stage should be permitted to allocate portion of any given memory pool (and the memory pool is therefore associated with that single pipeline stage), but once a portion of a memory pool has been allocated for storing a particular group of data, other later pipeline stages that may need that data are preferably also able to access / update that memory pool as needed.

[0077] This memory allocation is also preferably performed in advance, for example, during the initial configuration of the processing pipeline. That is, while the processing pipeline is being configured, a set of memory pools is preferably configured, and appropriate access permissions to the respective memory pools are set for each of the pipeline stages. For example, appropriate indicators of which pipeline stages have access to which memory pools can be generated during the initial pipeline configuration. This indicator can, for example, take the form of a 'bit mask' per memory pool, indicating which pipeline stages have access to that memory pool, although other arrangements are of course possible.

[0078] Thus, access permissions may be flexibly reconfigured for different instances executing a graphics processing pipeline (e.g., between render passes or draw calls), but should, and therefore preferably are, fixed for a particular instance (or set of instances) of a graphics processing pipeline.

[0079] Although the preferred embodiment uses a memory pool, as described above, in general the memory available for (temporarily) storing data generated by / for different pipeline stages may be any suitable and desired memory, and various arrangements will be possible in this regard.

[0080] However, in all cases, the pipeline configuration should and preferably determines which pipeline stages can allocate portions of memory (or memory pools), and which pipeline stages can access portions of memory allocated by other shader stages. Therefore, the pipeline configuration information may also and preferably also include an indication of which of the shader stages to be executed for the graphics processing pipeline are permitted to allocate portions of memory for groups of work items being processed by the shader stage, and which shader stages are permitted to access portions of memory allocated by other shader stages. Preferably, the pipeline configuration information further indicates which shader stages can (and should) deallocate portions of memory allocated by other shader stages.

[0081] The initial, high-level pipeline configuration, preferably executed, for example, by software on a main (host) processor, may also configure (i.e., partition) the memory pools themselves and define the layout of each memory pool. This may typically involve dividing the (total) memory buffer into a suitable set of memory pools and then defining a corresponding layout for each memory pool. As part of this, the initial (software) pipeline configuration may also configure the desired packet size / format for each memory pool. The desired packet size / format for each memory pool is preferably also included in the pipeline configuration information that is communicated to the graphics processor and used to control the execution of the processing pipeline.

[0082] Thus, in an embodiment, the initial pipeline configuration may include dividing the memory buffers associated with and available to the graphics processing pipeline into a set of multiple memory pools, and determining which shader stages are permitted to access which memory pools. The pipeline configuration information transmitted to the graphics processor and used to control the execution of the processing pipeline therefore preferably includes (at least) information indicating this.

[0083] However, as needed, various other suitable pipeline configuration information may also be determined and appropriately stored for controlling subsequent processing pipeline execution. For example, other suitable pipeline configuration information may include a descriptor of the workgroup dimension for each pipeline stage, etc.

[0084] In general, the stored pipeline configuration information may include any (all) state information that may be used to control subsequent processing pipeline execution.

[0085] As mentioned above, the pipeline configuration information is preferably transmitted to a local storage device associated with the processing pipeline (processing (shader stage) circuit) as part of the execution of a set of (RUN_PIPELINE) commands that trigger the execution of the processing pipeline. In this regard, as mentioned above, the pipeline configuration information can be indicated in the (RUN_PIPELINE) command in any suitable manner as needed, for example, and preferably depending on the type of pipeline configuration information.

[0086] For example, overall pipeline configuration information (such as information indicating which shader stages should be enabled, which memory pools those shader stages have access to, etc.) may generally be excluded from application to multiple consecutive instances of a processing pipeline execution (i.e., consecutive draw calls). Furthermore, such information may require a relatively large data structure. Therefore, in a preferred embodiment, a pointer to a separate data structure containing such pipeline configuration information is provided, and the corresponding input argument of the (RUN_PIPELINE) command thus causes the pointer to be read and the relevant pipeline configuration information (i.e., the descriptor being pointed to) to be transferred to the local storage device associated with the processing pipeline (processing (shader stage) circuit).

[0087] For example, in a preferred embodiment, a pipeline 'descriptor' data structure is generated that includes a corresponding bit mask of which shader stages are enabled and also includes a corresponding per-memory pool bit mask of which shader stages are permitted to access the memory pool. This overall pipeline configuration information is preferably all included in the same pipeline descriptor data structure (although this need not be the case, of course), and the corresponding input arguments of the set of (RUN_PIPELINE) commands therefore preferably cause the appropriate pointer to the pipeline descriptor data structure to be read and the relevant descriptors to be transferred appropriately.

[0088] When a set of (RUN_PIPELINE) commands is executed, the pointer to the pipeline descriptor data structure (or structures) is therefore available to read the pipeline descriptor data structure into local storage associated with the processing pipeline (shader stage circuitry) accordingly.

[0089] However, other pipeline configuration information may exist, for example, that is specific to a draw call, and such pipeline configuration information can be, and preferably is, transferred more directly to local storage associated with the processing pipeline (processing (shader stage) circuitry). In this case, the pipeline configuration information may be actual data values ​​obtained using corresponding input arguments of a set of (RUN_PIPELINE) commands that trigger execution of the graphics processing pipeline and transferred directly to local storage associated with the processing pipeline (processing (shader stage) circuitry). Information stored in this manner may include, for example, dynamic shader stage configuration information, a set of fast access unified (FAU) units for each shader stage, and the like. For example, this type of data is expected to change between draw calls, and therefore, when processing a new draw call, it may be desirable (and preferably is done) to update such pipeline configuration information by issuing a new set of (RUN_PIPELINE) commands to trigger execution of the processing pipeline for that draw call.

[0090] In this regard, various arrangements for transferring pipeline configuration information to local storage associated with a processing pipeline (processing (shader stage) circuitry) would be possible.

[0091] It should also be understood that not all (identical) pipeline configuration information will need to be updated for each instance of a processing pipeline execution. Thus, in an embodiment, certain types of pipeline configuration information may be selectively transferred / not transferred to local storage associated with a processing pipeline (processing (shader stage) circuitry) in response to a particular execution of a set of (RUN_PIPELINE) commands (and in the event that the data value of a certain pipeline configuration information segment is not transferred by the execution of a (RUN_PIPELINE) command, a suitable default value (e.g., zero) or previous value may be used instead for that pipeline configuration information segment).

[0092] To control this, the set of (RUN_PIPELINE) commands may have associated modifiers or flags that may be used to select which pipeline configuration information is required, and therefore which input argument is being used (and therefore which register should be read from when the set of (RUN_PIPELINE) commands is executed).

[0093] While the examples so far have involved pipeline configuration information relating to the actual configuration / state of the pipeline (stage), it will be appreciated that the same set of (RUN_PIPELINE) commands may also, and preferably will, be used to transfer any other input data values ​​or parameters that may be desired for executing the processing pipeline to local storage associated with the processing pipeline (processing (shader stage) circuitry) as needed (such other data values ​​may not be related to the pipeline 'configuration' as such, but still be used when executing the processing pipeline). This may include any suitable and desired information identifying the index / vertex to be processed (e.g., index count, vertex count, index offset, vertex offset, vertex index array pointer, delta size, etc.). This may also include, for example, a descriptor for a tiler (when the graphics processing pipeline feeds a tiler), as well as information relating to parameters such as clipping, viewport, etc. to be used when executing the processing pipeline.

[0094] Thus, as mentioned above, a particular effect and benefit of using such a (RUN_PIPELINE) command is that multiple shader stages (circuits) can be efficiently configured / reconfigured at once when needed, wherein information required to execute an instance of the processing pipeline is preferably transferred to a local storage device associated with the processing pipeline (processing (shader stage) circuitry) in response to automatically (i.e., controlled by the graphics processor (hardware)) executing this (RUN_PIPELINE) command.

[0095] Thus, this may be more efficient, for example, than if the main (host) process had to explicitly do so using potentially many separate commands to incrementally transfer all relevant pipeline configuration information, thereby placing a significant burden on the application programmer.

[0096] It should be understood that after an initial pipeline configuration for a particular set of one or more instances of a processing pipeline execution (e.g., for a set of one or more draw calls), it may be desirable to reconfigure the processing pipeline, for example, for another instance of the processing pipeline execution (e.g., a new render pass, or a new draw call within the current render pass).

[0097] This can be, and preferably is, accomplished by reconfiguring the processing pipeline in the same manner as described above, for example by obtaining a new set of pipeline configuration information and transferring it to local storage associated with the processing pipeline (processing (shader stage) circuitry) prior to triggering one or more (new) instances of execution of the processing pipeline. Thus, preferably, this is triggered by another set of (RUN_PIPELINE) commands issued to the graphics processor, which trigger another (new) instance of execution of the graphics processing pipeline.

[0098] It will be appreciated that, in order to ensure correct (safe) behavior, when a processing pipeline is reconfigured between different instances of processing pipeline execution, the processing pipeline may need to be paused between those different instances. For example, and in particular, this may need to be done when memory access permissions change between instances of processing pipeline execution. Accordingly, appropriate wait conditions may be applied between instances of processing pipeline execution as needed to allow the processing pipeline to fully drain work from a previous instance before starting work for the next instance.

[0099] In this regard, various arrangements would be possible.

[0100] Thus, the present invention allows for a complete set of pipeline configuration information to be transferred to a local storage device associated with a processing pipeline (processing (shader stage) circuitry) as needed, and this is preferably done once, i.e., in response to executing a particular set of (RUN_PIPELINE) commands as described above. Other sets of (RUN_PIPELINE) commands may then be executed to transfer in a new set of pipeline configuration information for another instance of processing pipeline execution, and so on, to control the execution of the processing pipeline.

[0101] As discussed above, execution of a processing pipeline according to the present invention is generally triggered by a graphics processor executing a corresponding set of (RUN_PIPELINE) commands that control graphics processing pipeline operations for one or more instances of graphics processing pipeline execution (e.g., for one or more draw calls).

[0102] Therefore, execution of a graphics processing pipeline according to the present invention is preferably triggered by including appropriate commands into the graphics processor command set.

[0103] For example, many data processing systems include processing resources, such as graphics processors, that can perform processing tasks for, for example, application programs executing on, for example, a main (eg, host) processor (CPU) of the data processing system.

[0104] By providing a command (instruction) stream to be executed by the graphics processor to the main (host) processor, the graphics processor can be caused to perform processing tasks for an application program running on the main (host) processor. For example, a driver for the graphics processor may prepare a command set containing commands (instructions) to be executed by the graphics processor and provide this command set to the graphics processor. The graphics processor then executes the commands in the command set (the operations indicated by the commands).

[0105] Commands issued to the graphics processor may, for example, include commands to set parameters for processing tasks to be performed by the graphics processor, as well as commands to perform processing tasks using available processing circuitry / units of the graphics processor.

[0106] An appropriate command processing unit of the graphics processor (eg, a "command stream front end" / job manager) will then work through the commands, eg, executing the commands in sequence.

[0107] Thus, in an embodiment, one or more corresponding sets of (RUN_PIPELINE) commands may (and are) included in the set of commands that are prepared by the main (host) processor and to be executed by the graphics processor to trigger execution of the corresponding one or more instances of the processing pipeline.

[0108] The present invention also extends to and includes such operations where a master (host) processor prepares a command set for a graphics processor.

[0109] Therefore, according to another aspect of the present invention, there is provided a method of operating a data processing system, the data processing system comprising:

[0110] a main (eg, host) processor; and

[0111] A graphics processor, wherein the graphics processor comprises a set of one or more processing circuits operable to implement a set of general pipeline stages, wherein respective ones of the general pipeline stages in the set of general pipeline stages are configurable as respective different shader stages to be executed as part of a processing pipeline, the method comprising:

[0112] In response to a request from an application executing on a host processor for processing to be performed by the graphics processor, preparing, on the primary host processor, a command set including commands that trigger one or more instances of execution of a processing pipeline, wherein the commands to trigger one or more instances of execution of the processing pipeline, when executed, will cause:

[0113] A set of pipeline configuration information indicating a respective set of shader stages to be executed for the processing pipeline is transferred to a storage device associated with the processing pipeline; and

[0114] The graphics processor uses the stored pipeline configuration information to control operation of the one or more processing circuits to execute the processing pipeline for the one or more instances of the processing pipeline execution.

[0115] According to yet another aspect of the present invention, there is provided a data processing system, the data processing system comprising:

[0116] a main (eg, host) processor; and

[0117] A graphics processor, wherein the graphics processor comprises a set of one or more processing circuits operable to implement a set of general pipeline stages, wherein respective ones of the general pipeline stages in the set of general pipeline stages are configurable as respective different shader stages to be executed as part of a processing pipeline, the method comprising:

[0118] wherein the host processor is operable and configured to, in response to a request from an application executing on the host processor for processing to be performed by the graphics processor, prepare a command set including commands to trigger one or more instances of execution of a processing pipeline, wherein the commands to trigger one or more instances of execution of the processing pipeline, when executed, will cause:

[0119] A set of pipeline configuration information indicating a respective set of shader stages to be executed for the processing pipeline is transferred to a storage device associated with the processing pipeline; and

[0120] The graphics processor uses the stored pipeline configuration information to control operation of the one or more processing circuits to execute the processing pipeline for the one or more instances of the processing pipeline execution.

[0121] Thus, in accordance with these other aspects and as also discussed above, there is a set of one or more (RUN_PIPELINE) commands (and preferably a single such command) that, when executed, will trigger one or more instances of graphics processing pipeline execution. Furthermore, the same set of (RUN_PIPELINE) commands, when executed, will also cause a set of predetermined pipeline configuration information related to the one or more instances of processing pipeline execution to be executed to be transferred to the graphics processor, and specifically to a suitable local storage device associated with the processing pipeline (processing (shader stage) circuitry), for use thereby to control execution of the processing pipeline.

[0122] That is, the set of (RUN_PIPELINE) commands preferably includes a suitable identifier of the pipeline configuration information (e.g., by (directly) encoding a data value of a particular type of pipeline configuration information or by encoding a pointer to a data structure (e.g., a descriptor) containing such pipeline configuration information) to allow the relevant pipeline configuration information to be transferred to a local storage device, and the locally stored pipeline configuration information is then used by the graphics processor to appropriately configure / control the operation of the processing pipeline (processing (shader stage) circuitry) based on such pipeline configuration information, e.g., as described above.

[0123] As described above, each set of (RUN_PIPELINE) commands preferably relates to a specific instance or instances of execution of a processing pipeline. For example, a set of (RUN_PIPELINE) commands may correspond to a set of one or more draw calls to be processed using the processing pipeline. Thus, the set of (RUN_PIPELINE) commands may be followed by other suitable commands in the command set for the graphics processor as needed, including, for example, suitable commands that define the start and end of the set of one or more draw calls to which the (RUN_PIPELINE) command relates.

[0124] In this regard, various arrangements would be possible.

[0125] The present invention also extends to the operation of the graphics processor itself when executing a set of commands.

[0126] Therefore, according to another aspect of the present invention, there is provided a method for operating a graphics processor, the graphics processor comprising:

[0127] one or more processing circuits operable to implement a set of general pipeline stages, wherein respective ones of the general pipeline stages in the set of general pipeline stages are configurable as respective different shader stages to be executed as part of a processing pipeline,

[0128] The method includes:

[0129] In response to the graphics processor receiving a command to perform processing using the processing pipeline:

[0130] transferring a set of pipeline configuration information indicating a respective set of shader stages to be executed for the processing pipeline to a storage device associated with the processing pipeline (processing circuitry); and

[0131] The graphics processor uses the stored pipeline configuration information to control operation of the one or more processing circuits to execute the processing pipeline for the one or more instances of the processing pipeline execution.

[0132] According to yet another aspect of the present invention, a graphics processor is provided, the graphics processor comprising:

[0133] one or more processing circuits operable to implement a set of general pipeline stages, wherein respective ones of the general pipeline stages in the set of general pipeline stages are configurable as respective different shader stages to be executed as part of a processing pipeline,

[0134] In response to the graphics processor receiving a command to perform processing using the processing pipeline:

[0135] a set of pipeline configuration information indicating a respective set of shader stages to be executed for the processing pipeline is transferred to a storage device associated with the processing pipeline (processing circuitry); and

[0136] The graphics processor uses the stored pipeline configuration information to control operation of the one or more processing circuits to execute the processing pipeline for the one or more instances of the processing pipeline execution.

[0137] As will be appreciated by those skilled in the art, these additional aspects of the invention relating to the operation of the main (host) processor and / or graphics processor, as appropriate, may, and in one embodiment, do, include any one or more or all of the features of the present invention.

[0138] As mentioned above, the benefit and effect of the present invention is that the processing pipeline (stages) can be configured / programmed in advance to support different graphics processing flows.

[0139] According to the present invention, a graphics processing pipeline can thus be configured and reconfigured as needed for different instances of the processing pipeline execution using the same underlying (general purpose) pipeline stage hardware (circuitry) (i.e., a set of shader stage circuitry). This is accomplished by performing an initial pipeline configuration to determine appropriate pipeline configuration information, which is then passed to the pipeline stage hardware (circuitry) and used to configure a corresponding set of general purpose pipeline stages as a corresponding set of shader stages to be executed for the processing pipeline.

[0140] Therefore, preferably, there is an initial (software) configuration process, and this initial configuration process may include, for example, configuring memory for the graphics processing pipeline and binding the corresponding memory (pools) to different pipeline stages, configuring pipeline stages and binding shader programs to pipeline stages, etc., as well as any other pipeline configuration that may be expected to be performed at the rendering pass level.

[0141] Once the processing pipeline has been initially configured in this manner, processing work can then be issued to the graphics processing pipeline.

[0142] Thus, this may provide a more flexible and configurable approach for supporting graphics processing flows (eg, compared to more traditional fixed-function graphics processing pipelines).

[0143] Thus, the present invention may provide various benefits compared to other possible approaches.

[0144] The graphics processor (and processing pipeline) may otherwise be operated and configured in any suitable and desired manner, subject to the specific requirements of the present invention.

[0145] According to the present invention, each (generic) pipeline stage is preferably collectively operable and configured to perform a specific (identical) sequence of processing operations in response to an incoming packet of work items (although it will be understood that the actual sequence of processing operations performed by a given pipeline stage will depend on the configuration of that pipeline stage and / or the packet to be processed).

[0146] For example, each (generic) pipeline stage preferably includes a pipeline stage "front end" (circuitry) that is configured to receive incoming packets of work items and control further processing of the packets within that pipeline stage.

[0147] The pipeline stage "front end" (circuitry) is specifically operable and configured to perform a set of initial processing operations to process an incoming packet of work items to determine a corresponding set of packets of work items to be further processed within the pipeline stage.

[0148] In this regard, it should be understood that incoming packets of work items may be passed directly for further processing within a pipeline stage, e.g., if this is possible and desirable. Thus, at least some packets may pass directly through the pipeline stage "front end" (circuitry).

[0149] However, it may often be the case that further processing to be performed within a pipeline stage on a particular incoming (input) packet will output data elements that do not fit into a single (output) packet, in which case it may be necessary and preferable to generate corresponding multiple "sub" packets from the incoming packet. Accordingly, at least some of the packets may be processed to generate corresponding subpackets to be further processed within the pipeline stage.

[0150] Of course it may also be the case that the incoming packets do not need to be processed further within the pipeline stage.Therefore, at least some of the packets may be invalidated / deallocated within the pipeline stage.

[0151] Thus, initial processing operations performed by a pipeline stage "front end" (circuitry) preferably determine (e.g., generate) from an incoming group of work items corresponding zero or more groups of work items to be further processed within (the remainder of) the pipeline stage.

[0152] Depending on the results of these initial processing operations, the remaining packets (if any) will then be processed accordingly. This will depend on the configuration of the pipeline stages and / or the type of packet in question.

[0153] However, for at least some pipeline stages and for at least some groups of work items determined to be further processed within a given pipeline stage (whether they are the original groups of work items or, more typically, corresponding "sub" groups generated from the original groups of work items), the pipeline stage ("front end" (circuitry)) then allocates a corresponding portion of memory for that group (to store data for that group).

[0154] For these groups, once the corresponding portions of memory have been allocated for the groups of work items, the pipeline stage ("front end" (circuitry)) then issues the groups of work items to the set of shader cores of the graphics processor via a suitable (universal) shading interface for processing. The processing of the groups by the set of shader cores of the graphics processor can and typically will involve the execution by the programmable execution units of the shader cores of the shader cores of one or more corresponding shader programs designated for execution for the pipeline stage in question (where the shader programs triggered are determined based on the specific configuration of the pipeline stage, such that different pipeline stages may trigger different shader programs). For example, a pipeline stage configured as a vertex shading stage may trigger a vertex shader, while a pipeline stage configured as a mesh shading stage may trigger a mesh shader, and so on. However, the shader cores may generally perform any suitable and desired processing of the work items depending on the desired pipeline configuration.

[0155] As will be explained further below, each pipeline stage should therefore, and preferably does, have a 'generic' shading interface to the set of shader cores, via which shading requests can be sent.

[0156] After the required group processing (e.g., shading) has been performed for a given group of work items, the processed (shaded) output is returned to, for example, the pipeline stage that triggered the processing and written to the corresponding portion of memory allocated to that group, and the processed group of work items can then be (and is) available for output to, for example, the next pipeline stage in a graphics processing pipeline (or otherwise, for example, if the current pipeline stage is the last pipeline stage), and subsequently output from the pipeline stage as appropriate (e.g., for further processing).

[0157] For example, in a preferred embodiment, as will be explained further below, one, and preferably each, general pipeline stage is also operable and configured to keep track of the packets currently being processed within that pipeline stage. This is preferably done using a respective indicator (e.g., and preferably in the form of a respective packet header) that identifies the packet currently being processed within the pipeline stage (and this preferably includes both packets queued for coloring and packets for which coloring has already been performed but which have not yet been passed to the next pipeline stage).

[0158] Thus, a pipeline stage in the plurality of pipeline stages is preferably operable and configured to store a corresponding identifier of a packet currently being processed within the pipeline stage. The identifier may be stored in any suitable and desired manner. For example, in a preferred embodiment, the pipeline stage is operable and configured to maintain a packet 'buffer' (e.g., a queue) for storing the corresponding identifier of a packet currently being processed within the pipeline stage. However, other arrangements are of course possible.

[0159] Any processed packets can then be and preferably are provided for output from such packet buffer (queue) (e.g., to the next pipeline stage of the graphics processing pipeline, or otherwise depending on the pipeline stage in question), with packets preferably being pushed from the head of the packet queue, e.g. and preferably such that the packets are provided for output in the same order as they were added to the packet queue (e.g., in a "first in, first out" manner).

[0160] Preferably, each general pipeline stage also includes a pipeline stage "back end" (circuitry) that manages the delivery of (data of) the processed packets to the next processing stage (which may be the next pipeline stage, or another processing stage, for example, if the pipeline stage is the last pipeline stage).

[0161] For example, the pipeline stage "back end" (circuitry) may communicate with a suitable memory management system that is shared between the pipeline stages and that may control access by each pipeline stage to memory in which (data of) packets may be stored. Thus, after a given pipeline stage has allocated a portion of memory for a given packet, if another later pipeline stage potentially also needs (data of) that packet, access to the memory is preferably controlled by such a shared memory management system, as will be further described below.

[0162] The packets of work items available for output by a particular pipeline stage may therefore subsequently be pushed from the corresponding packet buffer (queue) maintained for that pipeline stage to the (i.e.) next pipeline stage in the processing pipeline, and, at least where the next pipeline stage is another 'general' pipeline stage, the packets of work items may then be processed by the next (general) pipeline stage in a similar manner, i.e., the packets are first processed by the next pipeline stage to determine corresponding (e.g., 'sub') packets to be processed within the next pipeline stage, and these (sub) packets (e.g., colored) are then further processed as appropriate and provided for output to another next pipeline stage in the processing pipeline, and so on, for example until the final stage of the processing pipeline is reached.

[0163] Thus, the (universal) pipeline stages within the processing pipeline may be configured / programmed to perform different processing operations (e.g., and specifically) by triggering different shader programs, such that the (universal) pipeline stages together may be configured and configured to perform a certain (pipelined) sequence of packet processing operations to generate output for the graphics processing pipeline. However, the (universal) pipeline stages may, and preferably are, at least operable to perform the same basic set of processing operations in response to receiving an incoming packet (i.e., as described above), and thus the (universal) pipeline stages may, and preferably are, implemented using the same general hardware circuitry.

[0164] Another aspect of the processing pipeline according to the present invention is that the (generic) pipeline stages are operable and configured to process work items at a "group" granularity, where a group comprises a collection of multiple work items, but the work items may comprise any suitable and desired collection of work items, e.g. depending on the pipeline stage in question and the processing to be performed on the group.

[0165] For example, in the context of geometry processing, work items within a group may include any of vertices, meshes, tasks, bounding boxes, primitives, etc., on which processing is to be performed.

[0166] Thus, each pipeline stage may be, and preferably is, operable and configured to generate data elements for a collection of work items (such as vertex attributes for vertices in the case of a vertex shading stage), and the pipeline stage is operable to process such collections of work items at a "pack" granularity.

[0167] Entities that pass through and have processing performed on them within pipeline stages of a graphics processing pipeline therefore include corresponding "packets" that include (data for) multiple work items (e.g., vertices, etc.) for which the corresponding pipeline stage is generating data.

[0168] Furthermore, as mentioned above, each (generic) pipeline stage may process incoming (input) packets of a work item in various different ways depending on the type of packet and / or the pipeline stage configuration, such that packets output by a particular pipeline stage may not (and typically will not) directly correspond to any incoming packets input to that particular pipeline stage (but the output packets will instead be "child" packets generated from processing of an incoming "parent" packet, where the parent packet was output from a previous pipeline stage (and where the output child packets may therefore in turn be parent packets of corresponding child packets generated in the next pipeline stage)).

[0169] In this regard, various arrangements will be possible depending on the configuration of the processing pipeline and the specific processing (shading) operations that the different pipeline stages of the processing pipeline are configured to perform.

[0170] This packet-based processing can therefore provide increased flexibility / configurability in the processing that can be supported by a graphics processing pipeline according to embodiments of the present invention, because the input / output of a particular pipeline stage can be more customized, for example, because the packets input to or output from a given pipeline stage can generally contain any suitable group of work items (which can be, for example, vertices, but can also be other geometry (or other) data), and these packets can be split, etc. to generate new sub-groups as needed. Likewise, the use of a processing pipeline according to the present invention can therefore further increase flexibility / configurability compared to more traditional graphics processing pipelines, for example, where each stage can have a more rigid format for input data (e.g., a traditional vertex shading stage can require vertex data in a specific format), which can limit the options of an application programmer.

[0171] Thus, according to the present invention, a processing pipeline is implemented using (at least) a plurality of 'generic' pipeline stages, wherein these (generic) pipeline stages are each operable to process 'groups' of work items in a similar manner, but are configurable to perform different processing operations depending on the particular configuration of the pipeline stage in question.

[0172] The effects and benefits of doing so then preferably facilitate a more flexible and configurable graphics processor arrangement, for example because there may be fewer restrictions on the inputs / outputs to each pipeline stage, and the pipeline stages may be configured to map to and therefore support a variety of different graphics processing flows as desired.

[0173] For example, in a particularly preferred embodiment, the processing pipeline is a geometry processing pipeline that processes raw geometry that has been defined for a particular graphics processing operation application into a suitable (e.g., screen space) format version of the geometry for subsequent rendering of the geometry to produce a desired output (e.g., an image or other output). However, the geometry processing supported and supportable in the present invention may include any suitable and desired sequence of one or more geometry processing stages that can be performed as part of a graphics processing pipeline. In a preferred embodiment, the geometry processing includes one or more of the following geometry processing stages, and preferably includes a plurality of geometry processing stages: a position shader (position shading); a vertex shader (vertex shading); a tessellation control shader (tessellation control shading); a task shader (task shading); a tessellation stage (tessellation shading); a mesh shader (mesh shading); a tessellation evaluation shader (tessellation evaluation shading); a geometry shader (geometry shading); and a transform feedback stage (transform feedback shading). Geometry processing may include one or more of these shader stages as required, and the (generic) pipeline stages may therefore be configured to support various geometry processing flows, for example and in particular, by configuring different pipeline stages to trigger different shader programs as required (and in this regard, it should also be noted that a particular pipeline stage is operable to trigger any desired shader program or programs, i.e., such that a particular pipeline stage can be mapped to multiple geometry processing (shader) stages).

[0174] For example, as discussed above, processing pipelines according to the present invention can and do include a number of 'generic' pipeline stages (and the present invention is particularly concerned with the operation and configuration of these (generic) pipeline stages).

[0175] However, subject thereto, the overall processing pipeline may generally comprise any suitable and desired pipeline stages, and may therefore also (and in some embodiments does) suitably include one or more other (i.e., 'non-general purpose') pipeline stages which may perform any other suitable processing operations as required. For example, the 'other' pipeline stages may suitably be provided as the first and / or last pipeline stages in the processing pipeline, which first and / or last pipeline stages supply packets to or drain primitive packets from (general purpose) pipeline stages and may therefore desirably operate differently from intermediate pipeline stages, and various arrangements will be possible in this regard.

[0176] A preferred embodiment relates to tile-based graphics processing including a binning stage for sorting geometry relative to tiles. In this case, the geometry processing operation preceding the binning stage generates corresponding (geometry) groups, each group containing data for the geometry to be processed. The binning stage then generates one or more data structures to allow groups storing data for the geometry to be applied to corresponding rendered tiles to be identified.

[0177] In these preferred embodiments, the processing pipeline according to the present invention can therefore perform geometry processing before the binning stage of the tile-based graphics processing flow, and can, for example, process raw geometry that has been defined for a particular graphics processing operation application into a suitable (e.g., screen space) format version of the geometry for subsequent re-rendering of the geometry to produce a desired output (e.g., an image or other output).

[0178] The geometry processing generates respective (geometry) groups, each group storing data for a set of one or more primitives to be processed. Preferably, the first stage of geometry processing (which preferably includes position shading and / or vertex shading (e.g., including both position shading and variation shading)) acts as an "input grouper" that generates initial groups storing data for a set of one or more primitives to be processed. These initial geometry groups are then preferably processed appropriately by (any) subsequent stages of geometry processing to generate, for example, modified versions of the initial geometry groups and / or to generate additional geometry groups as required. For example, a mesh shader may generate multiple groups from a single input group.

[0179] Thus, in some embodiments, the geometry processing pipeline includes an "input grouper" stage that can be, and preferably is, provided at the beginning (top) of the graphics processing pipeline and is operable to output initial groups storing data for a set of one or more primitives to be processed (and these initial groups are then passed from the "input grouper" stage to the next pipeline stage for further processing). The processing pipeline may thus include an input grouper stage that provides input groups to the processing pipeline.

[0180] Where present, the 'input packetizer' stage can be, and in some embodiments is, a dedicated 'input packetizer', i.e., different from the 'general purpose' pipeline stages described above. For example, the 'input packetizer' stage can be a dedicated (e.g., hardware) unit that simply creates input packets and outputs these packets to the next pipeline stage without performing any further processing (e.g., shading). Alternatively, the 'input packetizer' stage can include a shading interface, e.g., the 'input packetizer' stage can also be implemented by the (first) pipeline stage in the 'general purpose' pipeline stages. In this regard, various arrangements will be possible.

[0181] It should be understood that not all graphics processing flows may require such an "input grouper" stage. For example, when the geometry processing pipeline includes a task / mesh shading stage (so that task / mesh shading is performed instead of traditional vertex shading), a dedicated input grouper stage (circuitry) may not be required because the task / mesh shader can output its own vertices / primitives. Similarly, when the graphics processing pipeline is supporting general-purpose (i.e., non-graphics) processing work, such an "input grouper" stage may not be required.

[0182] Therefore, in an embodiment, the "input grouper" stage (if present) can be, and preferably is, selectively disabled in this case.

[0183] In this regard, as will be discussed further below, in a preferred embodiment, any pipeline stage may be selectively enabled / disabled in use, for example based on the desired configuration state of the graphics processing pipeline for a particular processing job (and such reconfiguration may be performed as needed, for example, between rendering passes or between draw calls within a rendering pass, etc.).

[0184] As discussed above, a processing pipeline according to the present invention is at least partially implemented by so-called 'generic' pipeline stages. That is, at least certain sections of the processing pipeline are implemented using such (generic) pipeline stages.

[0185] A processing pipeline implemented according to the present invention comprises a plurality of such (general) pipeline stages.

[0186] The plurality of (general) pipeline stages may generally be configured and arranged in various suitable ways.

[0187] However, in a particularly preferred embodiment, there is a continuous sequence of two or more (such as three, four, five or six) connected (universal) pipeline stages in the processing pipeline. Thus, a packet output from one universal pipeline stage can be provided as input to the next universal pipeline stage within such a sequence of connected (universal) pipeline stages, and so on.

[0188] Embodiments of the present invention are particularly concerned with the operation and configuration of these (generic) pipeline stages.

[0189] Each (generic) pipeline stage is at least collectively operable to perform a basic sequence of processing steps for an incoming packet of work items, e.g., as described above (although the pipeline stages can, and typically will, be configured to perform different processing operations to execute the desired processing pipeline).

[0190] For example, as mentioned above, the initial processing of an incoming packet of work items for a given one of the (general) pipeline stages can, and preferably does, determine the corresponding zero or more (sub-)packets to be processed within that pipeline stage based on the incoming packet of work items.

[0191] In this regard, various options exist depending on the overall configuration of the processing pipeline.

[0192] For example, in some cases, there may be a one-to-one correspondence between incoming (input) packets and outgoing packets for a particular processing stage. That is, an incoming (input) packet may pass directly through the initial processing, and then the packet may be processed (or not processed) within the pipeline stage as needed.

[0193] However, it is (more) common that an incoming packet to a given pipeline stage may generate multiple "child" packets to be processed by and output from that pipeline stage, so that the number of packets that are typically passed along the pipeline stage may be magnified along the graphics processing pipeline. An example of this would be a mesh shader for an instance that generates multiple packets from a single input packet. Of course, a given pipeline stage may also determine that an incoming packet does not need to be further processed within that pipeline stage, in which case the incoming packet is essentially discarded (and zero corresponding packets are output).

[0194] Thus, according to the present invention, incoming packets to one (and each) (general) pipeline stage may be (initially) processed to determine zero or more packets to be further processed within that pipeline stage, and the determined packets then further processed (colored, etc.) as required.

[0195] Thus, in an embodiment, one or more of the shader stages to be executed for the processing pipeline may be operable to generate, from an incoming packet of work items, a corresponding plurality of "sub-packets" to be further processed within the shader stage. In this case, the set of pipeline configuration information may (and preferably does) also include a corresponding set of one or more parameters for controlling the generation of sub-packets from the incoming packet of work items for the one or more of the shader stages to be executed for the processing pipeline.

[0196] Therefore, these parameters may be appropriately included for different shader stages to appropriately control the packet expansion / amplification performed within the different shader stages.

[0197] For example, in a preferred embodiment, to color a packet, a corresponding set of one or more workgroups for that packet can be (and are) sent to an appropriate (compute) shader endpoint of a shader core set, which then colors the packet by iterating over the workgroups in the corresponding workgroup array for that packet. Thus, in a preferred embodiment, these parameters may define, for a shader stage (and potentially each shader stage) to be executed for a processing pipeline, a corresponding set of workgroup sizes that are applied to packets issued from that shader stage to a shader core set for processing (i.e., coloring).

[0198] For example, certain shader stages may require a single (compute) thread per work item (eg, one vertex shading thread per vertex).

[0199] However, there may be other shader stages where work items are preferably processed by larger workgroups (eg, where multiple threads are preferably executed in parallel).

[0200] Therefore, a corresponding workgroup set size is preferably defined for the shader stage and preferably for each shader stage, and this indication is preferably also included in the pipeline configuration information set, which is transmitted to the local storage device associated with the processing pipeline (processing (shader stage) circuit) via the above-mentioned (RUN_PIPELINE) command.

[0201] In this regard, various arrangements would be possible.

[0202] For example, in some embodiments, or at least for some shader stages within a processing pipeline, this may be done in a 'static' manner, e.g. such that for a particular shader stage, a particular (fixed) workgroup set size for that shader stage is defined in advance for a given instance of execution of the processing pipeline, and an indication of this is then stored in a pipeline configuration information set for that instance of execution of the processing pipeline.

[0203] In other preferred embodiments, and / or for other shader stages within the processing pipeline, this can be done more dynamically, for example based on one or more heuristics applied within the shader stage when processing the group. In this case, the parameter can indicate how the workgroup set size should be selected so that the workgroup set size can be appropriately determined at runtime. This may be appropriate because typically the number of groups, and therefore the workgroups to be run, will be determined based on pipeline processing (i.e., at runtime).

[0204] For example, for different shader stages, the workgroup set size can be any of a default value, a specified value (e.g., a static value predefined in software), or a value calculated based on the number of work items to be processed. Thus, in a preferred embodiment, the workgroup set size can be determined by another (previous) shader stage.

[0205] Thus, in this regard, various arrangements for selecting a workgroup set size will be possible, and this may be indicated accordingly within the pipeline configuration information. In this regard, it will be appreciated that the pipeline configuration information preferably includes a corresponding set of one or more parameters for controlling the generation of subgroups from incoming groups of work items for one or more of the shader stages to be executed for the processing pipeline, and is preferably defined in terms of a workgroup set size, which is then indicated by the pipeline configuration information (rather than being tied to a specific shader stage, thereby again facilitating the use of general-purpose hardware to implement different shader stages).

[0206] Initial processing of incoming packets to determine zero or more packets to be further processed within that pipeline stage may be done in any suitable and desired manner, such as based on the type of packet and / or the configuration of the pipeline stage in question.

[0207] For example, in an embodiment, a group may need to be split into multiple "child" groups when dictated by the workgroup (job) size of the shader program specified for execution by the pipeline stage in question. This may also be the case where the data structure used to store the group is configured to store up to a (fixed) maximum number of work items, and where processing within a particular pipeline stage involves a scale-up of work items.

[0208] Thus, this determination can, and typically will, include generating a plurality of corresponding "child" packets from the incoming (parent) packet.

[0209] In some preferred embodiments, one (and preferably each) group of work items is associated with metadata, preferably in the form of a group header, which metadata indicates how many (if any) "sub" groups should be generated for that group. Thus, when a given pipeline stage receives an incoming packet, the pipeline stage ("front end" (circuitry)) is preferably operable to determine from such metadata (e.g., by reading the group header) how many (if any) "sub" group work groups should be invoked for the incoming packet, and then generate a corresponding number of sub-groups to be processed in the pipeline stage. Thus, the group metadata (e.g., group header) can be updated by processing within a given pipeline stage (e.g., by a shading operation), so that the updated metadata (packet header) can then be used accordingly by the next pipeline stage. In this case, as mentioned above, the work group set size of a pipeline stage can therefore be dynamically determined by the previous pipeline stage (and the pipeline configuration information should therefore indicate that this will be done).

[0210] In this regard, it should be understood that processing within a particular pipeline stage may thereby configure the (computational) context for the next pipeline stage.

[0211] For example, in the case where a particular pipeline stage is configured as a task shading stage (i.e., a task shader), the task shader execution may determine, for each task within a task group being processed within the task shading stage (task shader), how many corresponding mesh shader workgroups should be generated and processed within a subsequent mesh shading stage (mesh shader) in response to the mesh shading stage (mesh shader) receiving the task. Based on this, the associated group metadata (header) may be appropriately updated.

[0212] When a task group is passed from a task shading stage (task shader) to a subsequent mesh shading stage (mesh shader), the incoming task group should therefore generate a corresponding number of mesh shader workgroups, and this is preferably controlled by the mesh shading stage (mesh shader) "front end" reading the associated group metadata (header) of the incoming (task) group and using this to generate an appropriate number of mesh groups for processing within the mesh shader pipeline stage.

[0213] In this regard, various other examples would be possible.

[0214] Thus, packet metadata (headers) may be updated by pipeline stage processing to pass information between pipeline stages. In addition to this packet metadata (included in the packet header), subsequent pipeline stages when processing a given (child) packet may also need to use output data generated by processing the corresponding (parent) packet in an earlier pipeline stage.

[0215] Thus, when executing a processing pipeline in which one or more stages of the pipeline generate data for use by later stages of the pipeline, it may be necessary to store the data generated by the stage for subsequent use by other pipeline stages, and for those other pipeline stages to be able to appropriately access the data.

[0216] For a grouping of work items to be further processed within a pipeline stage (e.g., and in particular, for each "sub" grouping generated within a "front end" (circuitry) of a pipeline stage), the pipeline stage ("front end" (circuitry)) is then preferably operable to allocate, for the grouping of work items, a corresponding portion of a memory pool for (temporarily) storing data for that grouping.

[0217] The memory available for storing (data of) packets can generally be any suitable and desired memory and can be configured in a variety of ways. However, preferably, the memory available for storing (data of) packets is divided into multiple memory "pools", each memory pool being associated with one or more pipeline stages. This can then assist with memory management, and in particular, managing data dependencies between pipeline stages.

[0218] Therefore, preferably, a (general purpose) pipeline stage is associated with at least one memory pool that can be allocated for temporarily storing portions of data of a group of work items to be processed within the pipeline stage. In a preferred embodiment, at least some of the (general purpose) pipeline stages are associated with a respective memory pool that can be allocated for temporarily storing portions of data of a group of work items to be processed within the pipeline stage.

[0219] Preferably, each pipeline stage (including the input grouper, when present) other than the (final) (primitive) group drain stage has an associated memory pool from which, where present, each pipeline stage can allocate a corresponding portion of the data of the groupings of work items to be processed within that pipeline stage.

[0220] In this regard, various arrangements would be possible.

[0221] Thus, the first pipeline stage that has access to a given memory pool is permitted to allocate portions of that memory pool (and preferably only the first pipeline stage is permitted to allocate portions of that memory pool). Thus, any other pipeline stages that are permitted to access the memory pool are preferably able to read data from the memory pool, and preferably also to update data within the memory pool, but are preferably unable to allocate portions of the memory pool (and instead, those pipeline stages can, and typically will, be associated with another, separate memory pool from which they can allocate portions of work items processed / generated by those pipeline stages). As discussed above, memory pool access permissions are preferably determined and configured as part of the initial pipeline configuration.

[0222] As mentioned above, there is preferably a shared memory management system that is operable and configured to then manage any access to the memory pool by the pipeline stages (and enforce such access permissions).

[0223] The memory pools available and associated with the different (general) pipeline stages may reside in any suitable and desired memory accessible by the graphics processor. For example, in an embodiment, the memory pools from which the (general) pipeline stages can allocate respective portions may be partitioned from within the overall geometry buffer.

[0224] However, various arrangements are contemplated in this regard.

[0225] A packet of work items being processed by a particular pipeline stage (the data generated thereby) can thus be written to the associated memory pool for that pipeline stage (i.e., the memory pool from which the pipeline stage can allocate a corresponding portion). For example, as mentioned above, for a (sub)packet of work items to be further processed within a particular pipeline stage, a corresponding portion of the associated memory pool for that pipeline stage can be temporarily allocated as needed for use by that packet. An appropriate packet identifier (e.g., included in the packet header) can thus be written to the allocated portion of the associated memory pool to reserve that portion. Any data (elements) generated for the packet can then be written to the corresponding portion of the memory pool that has been allocated for that packet during its processing.

[0226] Furthermore, the data (elements) generated for the packet and stored in the corresponding portion of the memory pool may then be read from, and preferably also updated by, subsequent pipeline stages as needed.

[0227] Thus, throughout pipeline configuration, the initial allocation of memory (pools) to (general) pipeline stages and the setting of associated access permissions controls and facilitates the flow of data along the processing pipeline. For example, even when different (logical) pipeline stages share the same underlying physical circuitry, different (general) pipeline stages preferably have correspondingly different 'splits' of the memory pool from which they can allocate respective portions of the data (elements) generated for the packets they are processing (where other pipeline stages are potentially permitted to read / update data from this memory pool as appropriate based on the pipeline configuration, but are prohibited from allocating portions of this memory pool (and instead have their own associated memory pools from which they can allocate portions of the data (elements) generated for the packets processed by those pipeline stages).

[0228] After allocating the corresponding portion of memory to the group to which the memory is allocated, the pipeline stage ("front end" (circuitry) then proceeds to process the group, specifically by issuing the group of work items to a set of shader cores of the graphics processor for processing (e.g., shading). The set of shader cores preferably then executes the corresponding shader program (or set of shader programs) that has been designated for execution by the pipeline stage in question, e.g., based on the specific configuration of the pipeline stage / graphics processing pipeline.

[0229] A graphics processor may include any suitable and desired arrangement of shader cores. Thus, a set of shader cores may be any suitable and desired set of shader cores operable to execute shader programs. Each shader core preferably includes at least a programmable execution unit for executing a shader program, but a shader core may additionally include any suitable and desired elements that a graphics processor shader core may typically include.

[0230] The shader core set may include a single shader core, but preferably includes multiple shader cores. Where multiple shader cores are present, each shader core is operable to execute shader programs in a similar manner. The shader core (and each shader core) should include, and in one embodiment does include, appropriate circuitry (processing circuitry / logic) for performing the operations required for the shader core. Where multiple shader cores are present, each shader core may be provided as a separate circuit to other shader cores of the graphics processor, or the shader cores may share some or all of their circuitry (circuit elements). In this regard, various arrangements are possible.

[0231] As with memory (pool) allocation, the configuration of pipeline stages, including the binding of shader programs to pipeline stages, is preferably performed during the initial configuration of the processing pipeline. Thus, the functionality of each (generic) pipeline stage, for example and specifically the corresponding shader program (if any), which can be triggered when processing a group of work items, is preferably configured (e.g., programmed) in advance, for example based on the overall processing pipeline configuration.

[0232] Thus, corresponding information (e.g., pipeline state) indicating the configuration of a given (general) pipeline stage may be indicated in a suitable data structure associated with or accessible to the pipeline stage, and this information may be used to control which shader program(s) may be (and are) triggered by that pipeline stage when processing a work item. The state information is preferably configured before processing pipeline execution, and thus the state information may potentially and preferably be subsequently updated as needed, for example to reconfigure one or more corresponding shader programs executed by a particular pipeline stage.

[0233] Thus, each (generic) pipeline stage preferably has a corresponding shading interface via which shading requests can be submitted to the set of shader cores of the graphics processor (wherein this shading interface is also generic in that the (generic) pipeline stage can issue different types of shading requests as needed, depending on the configuration of the pipeline stage). Such (generic) shading requests can, for example, be issued to a generic (e.g., "compute") shader endpoint that is operable to trigger shader programs specified for different pipeline stages. When a pipeline stage is issuing a shading request to the set of shader cores of the graphics processor, the shading request should therefore and preferably also include an indication of which shader program(s) to execute. The shader program(s) can be indicated relative to a preconfigured 'shader binding table', for example, which includes a list of available shader programs.

[0234] However, various other arrangements would be possible in this regard.

[0235] Thus, in an embodiment, each (generic) pipeline stage is operable to send a shading request to the set of shader cores using the generic shading interface, the shading request including information that can be used by the set of shader cores to determine one or more corresponding shader programs to be executed for the pipeline stage in question.

[0236] To facilitate this, in a preferred embodiment, an indication of the respective shader programs designated for execution by a pipeline stage is stored as state information associated with or accessible by the pipeline stage in question, and wherein the pipeline stage, when issuing a packet of work items to the set of shader cores of the graphics processor for processing, is configured to indicate to the set of shader cores of the graphics processor one or more respective shader programs to be executed when a shading request is issued to the set of shader cores of the graphics processor. As mentioned above, this state information is preferably configured prior to an instance of execution of the graphics processing pipeline and can be subsequently updated to reconfigure the one or more respective shader programs executed by a particular pipeline stage (for another instance of execution of the graphics processing pipeline).

[0237] However, other arrangements are possible. For example, once a graphics processing pipeline (and its pipeline stages) has been initially configured, that configuration may be provided individually to or otherwise made available to a set of shader cores so that a controller for the shader cores (e.g., a general-purpose / compute shading endpoint that controls the scheduling of tasks to the shader cores) may determine one or more shader programs to execute for the pipeline stage for which a shading request is being issued, e.g., based on an appropriate identifier for the stage for which a shading request is being issued.

[0238] Thus, when a pipeline stage issues a work item packet to a shader core set for processing (shading), the shader core set then executes the corresponding shader program (or set of shader programs) (if any) that has been designated for execution for the pipeline stage in question, e.g., based on the specific configuration of the pipeline stage / graphics processing pipeline.

[0239] The shading request should also, and preferably does, indicate one or more memory locations containing (input) packets to be processed and / or for writing (output) results. It should be understood that this is also done 'generic' so that the shader core set simply receives an indication of the input / output memory locations to be used (e.g., pointers to the input / output memory locations), and these memory locations may contain any desired packets to be processed, but the shader core set does not necessarily know which packets are associated with which pipeline stages. Thus, this can again increase the flexibility / configurability of the processing pipeline.

[0240] Thus, in an embodiment, a shading request issued from a pipeline stage to a set of shader cores also includes identifiers of memory locations for the group of work items to be processed and (optionally) one or more other memory locations for other groups of work items that are available for processing.

[0241] The set of shader cores then executes the specified shader program (or programs) and returns the (shaded) output data to the pipeline stage. Thus, the (shaded) output data is preferably written to the corresponding portion of the memory pool that has been allocated to the pipeline stage of the work item in question.

[0242] Once the packet has been processed (rendered), and corresponding output data is available, the processed packet of the work item is provided for appropriate output (eg, to the next pipeline stage in the graphics processing pipeline, or otherwise).

[0243] To facilitate this, as mentioned above, each (general) pipeline stage preferably maintains a respective “packet” buffer (e.g., a queue) that can be used to store respective indicators of packets that are (currently) being processed within the pipeline stage (i.e., packets that have not yet been passed to the next pipeline stage in the graphics processing pipeline).

[0244] Packets may be added to the buffer (queue) only when the required packet coloring has been performed. However, preferably, at least when memory allocation is performed, packets are added to the buffer (queue) at the point of memory allocation (along with a suitable indicator that the required packet coloring has not yet been performed). Thus, preferably, as incoming packets are received for processing, for each (e.g., sub-)packet determined to be further processed within a pipeline stage, a corresponding portion of the pipeline stage's memory pool is preferably allocated for that packet, and a suitable identifier for that packet is added to the packet buffer (queue). The identifier of a packet is preferably a packet header identifying the packet in question, and may also indicate various other states as desired.

[0245] Once the required packet coloring has been performed, the packet is pushed from the packet buffer (queue), eg, to the next (pipeline) stage for processing.

[0246] For example, for pipeline stages other than the last pipeline stage, packets can and preferably are pushed from the packet buffer (queue) to another pipeline stage. The next pipeline stage (to which the packet is passed) is preferably operable and configured to receive a packet identifier from the head of the packet queue of the previous pipeline stage, and the incoming packet is then processed accordingly by the next pipeline stage. Preferably, the packets are passed to the next pipeline stage in the (same) order in which they were generated for processing (although the actual processing (shading) may be completed out of order). Therefore, in a preferred embodiment, the packet buffer (queue) operates in a "first in, first out" (FIFO) manner to implement the desired packet ordering between pipeline stages.

[0247] The next pipeline stage (to which the packet is passed) is then preferably operable and configured to read the packet identifier from the head of the packet queue from the previous pipeline stage, and as long as the required packet coloring has been performed, the packet is pushed to the next pipeline stage for processing.

[0248] Thus, according to the above operation, a given (general) pipeline stage is operable to issue packets for coloring and maintain a packet queue from which processed packets can then be read and thus pushed to the next processing stage.

[0249] The data for this packet may also be used (and potentially updated) by the next pipeline stage as needed.

[0250] As discussed above, this data flow is preferably facilitated in the following manner: each (general) pipeline stage is able to allocate part of a respective memory pool for temporarily storing (data of) groups of work items generated by the pipeline stage, and subsequent pipeline stages are then able to appropriately access / update the data in that memory pool, where the access permissions of the pipeline stages to the respective memory pools are controlled by a suitable shared memory management system (e.g., as described above).

[0251] When a packet is passed to the next pipeline stage, the next pipeline stage can therefore read the packet identifier (e.g., header) from the packet queue of the previous pipeline stage. If necessary, the next pipeline stage can also potentially read data stored for the packet in the memory pool allocated by the previous pipeline stage, where this memory access is appropriately controlled based on the graphics processing pipeline configuration.

[0252] It will be appreciated from the above that respective portions of a memory pool associated with a (generic) pipeline stage may, and are, temporarily allocated for groupings of work items during use.

[0253] However, at some point, the data for a particular packet will no longer be needed, and so the corresponding portion of the memory pool allocated to that packet can, and therefore should, be deallocated at that point, e.g., to free that portion of the memory pool for subsequent packets being passed along the graphics processing pipeline.

[0254] Therefore, once a group of work items has been completely processed, the allocated memory should therefore eventually be deallocated, e.g., to allow it to be reallocated for a subsequent group. Thus, in an embodiment, after the initial allocation of the corresponding portion of the memory pool for the group of work items, the corresponding (allocated) portion of the memory pool is preferably subsequently deallocated.

[0255] However, in this regard, as mentioned above, applicants recognize that subsequent pipeline stages may also require data stored for a particular packet. For example, as described above, a subsequent pipeline stage may perform processing corresponding to a child (or grandchild, etc.) packet of a particular (parent) packet stored in an earlier pipeline stage.

[0256] Therefore, it is preferable to provide a mechanism to track which pipeline stages potentially need access to which memory pools, and to deallocate the corresponding portion of the memory pool that has been allocated to a packet only when it is possible (and safe) to do so, that is, only when all pipeline stages that can potentially access the memory pool have completed their processing of any corresponding (child, grandchild, etc.) packets that may need access to the data of the packet.

[0257] Therefore, the present invention preferably also provides a mechanism for appropriately invalidating groups when it is possible (and safe) to do so, for example so that their allocated memory areas can be deallocated. For example, after a corresponding portion of memory has been allocated by a pipeline stage for storing data for a particular first group of work items, when it is determined that there are no other groups of work items to be processed within any subsequent pipeline stage in the processing pipeline, the corresponding portion of memory allocated for storing data for the particular first group of work items can and should be deallocated for processing of other groups of work items that potentially use the data stored for the particular first group of work items. Preferably, the reallocation of memory for a particular group can therefore (and is) triggered by the last pipeline stage that can potentially access the memory pool storing data for that group. Therefore, suitable indications of which pipeline stages should deallocate portions of memory allocated to groups can also be included in the pipeline configuration information, as mentioned above.

[0258] In this regard, various arrangements would be possible.

[0259] This packet invalidation / memory deallocation can therefore facilitate sustained packet throughput because a memory pool for a particular (general) pipeline stage can be temporarily allocated and then reallocated as needed when other packets of work items require allocation of corresponding portions of the memory pool for their processing.

[0260] A processing pipeline implemented in accordance with the present invention thus performs a sequence of processing operations to generate an output, at least some of which processing operations are implemented using 'generic' pipeline stages, as discussed above.

[0261] The last (ie, final) stage of the processing pipeline may be any suitable and desired output stage, eg, depending on the graphics processing operation being performed.

[0262] For example, in some preferred embodiments, the processing pipeline is a geometry processing pipeline for a tile-based graphics processing system, and in this case, the geometry processing pipeline can feed into a tiling unit that orders the processed geometry relative to the rendered tiles for which the tile-based graphics processing is being performed (i.e., the geometry processing pipeline can feed into the tiling pipeline).

[0263] However, other arrangements will be possible, and the last (i.e., final) stage of the processing pipeline may generally include any suitable and desired stage that appropriately drains output data from the graphics processing pipeline (e.g., and preferably writes the output data for subsequent use (e.g., for subsequent rendering / fragment processing)).

[0264] Thus, in an embodiment, the processing pipeline may include or may feed a (final) (primitive) group drain stage that drains output groups from the processing pipeline, but this (final) (primitive) group drain stage may generally include any suitable and desired stage operable to drain output (primitive) groups from the processing pipeline. For example, in the context of geometry processing, the (final) (primitive) group drain stage may be operable to perform one or more primitive packing and / or binning operations (e.g., as mentioned above) on the (primitive) groups output by the processing pipeline.

[0265] However, various arrangements would be possible in this regard.

[0266] Output data from the processing pipeline may therefore undergo any suitable and desired further processing to generate the overall graphics processor output (whatever that may be).

[0267] The processing pipeline according to the present invention therefore comprises a plurality of pipeline stages, and these pipeline stages can be configured to perform various different processing operations. Therefore, at least when observed from a logical perspective, the processing pipeline comprises a plurality of different pipeline stages. However, the pipeline stages can and do share at least some physical circuits (hardware) in some preferred embodiments. For example, as discussed above, at least some of the pipeline stages in the pipeline stages can and do be implemented as 'universal' pipeline stages. This then promotes the use of the same physical circuits (hardware) to implement such pipeline stages. Therefore, a plurality of pipeline stages can (and preferably) be implemented at least in part using the same hardware circuits, but the different pipeline stages in the pipeline stages remain logically separated from each other, for example, by the different pipeline stages in the pipeline stages being operable to allocate portions of memories from different associated memory pools, as discussed above.

[0268] Thus, in an embodiment, the number of logical pipeline stages can be, and preferably is, greater than the number of shader stage (hardware) circuits that implement those pipeline stages (e.g., in an embodiment, the different (general) pipeline stages may all be implemented using a single shader stage circuit, where the different (logical) pipeline stages are configured / controlled in software).

[0269] The foregoing describes the major elements and operations of a graphics processor and processing pipeline relevant to operating in the manner of the present invention.

[0270] The present invention can be used for all forms of output that can be generated using a graphics processor and a processing pipeline. Specifically, the present invention can be used to generate graphics processing output, such as a frame for display, rendering to texture output, or for general (non-graphics) output.

[0271] As will be understood by those skilled in the art, a graphics processor may additionally include and execute, and preferably does include and execute, any or one or more, and preferably all, of the pipeline stages and circuits that a graphics processor and graphics processing pipeline may (typically) include.

[0272] Thus, for example, the graphics processor may execute a graphics processing pipeline including one or more geometry pipeline stages (such as vertex shading, task shading, mesh shading, tessellation shading, etc.), and execute one or more rendering stages (such as rasterization and fragment shading stages) and / or appropriate ray tracing stages. In a preferred embodiment, the graphics processor is in the form of a tile-based graphics processor and thus also includes and executes one or more appropriate tiling / binning stages.

[0273] Correspondingly, the graphics processor may include any one or more of the following, and preferably includes a plurality of: one or more geometry processing circuits, one or more primitive assembly circuits, one or more blocking / binning circuits, primitive setup circuits, rasterizer circuits and renderer circuits (preferably in the form of or including programmable fragment shaders), a depth (or depth and stencil) tester, a blender, a tile buffer, write-out circuits, and the like.

[0274] In preferred embodiments, the graphics processor includes and / or communicates with a memory system, one or more memories, and / or memory devices that store data described herein and / or store software for performing the processes described herein. The graphics processor may also communicate with a host microprocessor and / or a display for displaying images based on the output of the graphics processor.

[0275] The output to be generated may include any output that can and is to be generated by the graphics processor and processing pipeline. Thus, the output may include, for example, tiles and / or frames of output fragment data that would be generated in a tile-based graphics processing system. The present invention is applicable to all forms of output that a graphics processor and processing pipeline can generate, such as frames for display, render-to-texture output, etc. In a preferred embodiment, the output is an output frame, and preferably an image. However, in general, the graphics processor (and processing pipeline) of the present invention can be used to perform graphics processing work (such as generating frames for display, etc.) or to perform general (non-graphics) work as needed.

[0276] In a particularly preferred embodiment, the various functions of the present invention are performed on a single graphics processing platform that generates and outputs (rendered) data, which is written, for example, to a frame buffer for a display device.

[0277] The various functions of the present invention can be performed in any desired and suitable manner. For example, unless otherwise specified, the functions of the present invention may be implemented in hardware or software as needed herein. Thus, for example, unless otherwise specified, the various functional elements, levels, and "devices" of the present invention may include suitable one or more processors, one or more controllers, functional units, circuits, processing logic components, microprocessor arrangements, etc., which may be configured to perform various functions, etc., such as appropriate dedicated hardware elements (processing circuits) and / or programmable hardware elements (processing circuits), which may be programmed to operate in a desired manner.

[0278] It should also be noted here that, as will be appreciated by those skilled in the art, the various functions of the present invention may be repeated and / or executed in parallel on a given processor, etc. Likewise, the various pipeline stages may share processing circuitry, etc., if desired.

[0279] Furthermore, unless otherwise indicated, any one or more or all of the pipeline stages of the present invention may be embodied as pipeline stage circuitry, for example, in the form of one or more fixed function units (hardware) (processing circuitry) and / or in the form of programmable processing circuitry that can be programmed to perform desired operations. Likewise, any one or more of the pipeline stages and pipeline stage circuitry of the present invention may be provided as independent circuit elements to any one or more of the other pipeline stages or pipeline stage circuitry, and / or any one or more or all of the pipeline stages and pipeline stage circuitry may be formed, at least in part, from shared processing circuitry.

[0280] The graphics processor may additionally include any one or more or all of the typical functional units included in a graphics processor, etc., provided that any hardware is required to perform the specific functions discussed above.

[0281] It will also be understood by those skilled in the art that all described embodiments of the present invention, as appropriate, can, and in one embodiment do, include any one or more or all of the features described herein.

[0282] The methods according to the present invention may be implemented at least in part using software, such as a computer program. Thus, it can be seen that embodiments of the present invention may provide computer software, particularly adapted to perform the methods described herein when installed on a data processor; a computer program element comprising computer software code portions for performing the methods described herein when the program element is run on a data processor; and a computer program comprising code adapted to perform all steps of one or more methods described herein when the program is run on a data processing system. The data processor may be a microprocessor system, a programmable FPGA (field programmable gate array), or the like.

[0283] The present invention also extends to a computer software carrier comprising such software for operating a display controller or a microprocessor system comprising a data processor, so as to perform the steps of the method of the present invention in conjunction with the data processor, the controller or the system. Such a computer software carrier may be a physical storage medium such as a ROM chip, CD ROM, RAM, flash memory or magnetic disk, or may be a signal such as an electronic signal via a wire, an optical signal or a radio signal such as a signal to a satellite.

[0284] It will also be appreciated that not all steps of the methods of the present invention need be performed by computer software, and therefore according to a broader embodiment, the present invention provides computer software and such software installed on a computer software carrier for performing at least one of the steps of the methods set out herein.

[0285] The present invention may therefore be suitably embodied as a computer program product for use with a computer system. Such a specific implementation may include a series of computer-readable instructions fixed on a tangible, non-transitory medium, such as a computer-readable medium, for example, a disk, CDROM, ROM, RAM, flash memory, or hard disk. It may also include a series of computer-readable instructions that can be transmitted to the computer system via a modem or other interface device through a tangible medium (including but not limited to optical or analog communication lines) or passively using wireless technology (including but not limited to microwave, infrared, or other transmission technology). The series of computer-readable instructions embodies all or part of the functionality previously described herein.

[0286] Those skilled in the art will appreciate that such computer-readable instructions can be written in a variety of programming languages ​​for use with many computer architectures or operating systems. Furthermore, such instructions can be stored using any current or future memory technology (including but not limited to semiconductor, magnetic, or optical technology), or transmitted using any current or future communication technology (including but not limited to optical, infrared, or microwave technology). It is contemplated that such a computer program product can be distributed as a removable medium with accompanying printed or electronic documentation (e.g., shrink-wrapped software), can be pre-loaded with a computer system, for example, on a system ROM or fixed disk, or can be distributed via a network (e.g., the Internet or the World Wide Web) from a server or electronic bulletin board.

[0287] Preferred embodiments of the present invention will now be described, by way of example only, with reference to the accompanying drawings, in which:

[0288] Figure 1 An exemplary data processing system is shown in which the present invention may be implemented;

[0289] Figure 2 An exemplary graphics processing pipeline is shown;

[0290] Figure 3 schematically illustrates a graphics processor operable in accordance with the present invention;

[0291] Figure 4 schematically illustrates another graphics processor operable in accordance with the present invention;

[0292] Figure 5 shows an example of a geometry grouping pipeline that may be performed according to an embodiment;

[0293] Figure 6 illustrates in greater detail general shader stage circuitry within a graphics processing pipeline according to an embodiment;

[0294] Figure 7 is a flow chart illustrating "front-end" processing operations within a general shader stage circuit according to an embodiment;

[0295] Figure 8 is a flow chart illustrating management of a packet queue within a general shader stage circuit according to an embodiment;

[0296] Figure 9 is a flow diagram illustrating "back-end" processing operations within a general shader stage circuit according to an embodiment;

[0297] Figure 10 schematically illustrates the layout of a geometric structure buffer according to an embodiment;

[0298] Figure 11 、 Figure 12 and Figure 13 shows an example of the operation of a geometry grouping pipeline according to an embodiment;

[0299] Figure 14 An example of a host processor preparing a command set for a graphics processor according to an embodiment is shown; and

[0300] Figure 15 A graphics processor is shown executing a set of commands to trigger execution of a geometry grouping pipeline, according to an embodiment.

[0301] Preferred embodiments of the present invention will now be described.

[0302] Figure 1 An exemplary system-on-chip (SoC) graphics processing system 8 is shown, which includes a host processor including a central processing unit (CPU) 1, a graphics processing unit (GPU) 2, a display processor 3, and a memory controller 5. Figure 1 As shown, these units communicate via an interconnect 4 and have access to off-chip memory 6. In this system, a graphics processor 2 will render frames (images) to be displayed, which are then provided by a display processor 3 to a display panel 7 for display.

[0303] In use of this system, an application 9 (such as a game) executing on one or more host processors (CPUs) 1 will, for example, need to display frames on a display panel 7. To do this, the application will submit appropriate commands and data to a driver 10 for, for example, a graphics processor 2 executing on the CPU 1. The driver 10 will then generate appropriate commands and data to cause the graphics processor 2 to render appropriate frames for display and store them in an appropriate frame buffer, such as in main memory 6. The display processor 3 will then read these frames into a buffer for display, and then read the frames from the buffer and display them on the display panel 7 of the display.

[0304] In the present embodiment, graphics processor 2 executes a graphics processing pipeline that processes graphics primitives such as triangles when generating output such as images for display.

[0305] Figure 2 The processing sequence of the graphics processing pipeline executed by the graphics processor 2 when generating output in this embodiment is schematically shown.

[0306] Figure 2 As will be appreciated by those skilled in the art, there may be multiple components of the graphics processor and the processing pipeline. Figure 2 Other components not shown in FIG. It should also be noted here that Figure 2 is schematic only, and in practice, for example, even if the pipeline stages shown are Figure 2 Although schematically shown as separate stages, they may also share important hardware circuits. It should also be understood that Figure 2 Each of the stages, elements, units, etc. of the processing pipeline shown (unless otherwise indicated) may be implemented as desired and will accordingly include, for example, appropriate circuits, circuits and / or processing logic components, etc. for performing the required operations and functions.

[0307] like Figure 2 As shown, for an output to be generated, a set of, for example, scene data 11 is provided to the graphics processor, for example and in an embodiment is provided to the graphics processor by storing it in a memory 6, the set of scene data for example including, in particular, a set of vertices (each vertex having one or more attributes associated with it, such as position, color, etc.), a set of indices referencing the vertices in the vertex set, and primitive configuration information indicating how the vertex indices are to be assembled into primitives for processing when generating the output, and the set of scene data can then be read from the memory by the graphics processor 2.

[0308] This scene data may be provided by an application that needs to generate output (and / or a driver in response to commands from an application), and may, for example, include a complete set of vertices, indices, etc. for the output in question, or, for example, a corresponding different set of vertices, set of indices, etc. for a corresponding draw call to be processed for the output in question. Of course, other arrangements will be possible.

[0309] There are then one or more geometry pipeline stages 12 that perform appropriate geometry processing on and for the scene data to generate the data required to then render the output. This geometry processing 12 may include any suitable and desired geometry processing that may be performed as part of a graphics processing pipeline.

[0310] In the present embodiment, this geometry processing includes at least performing vertex processing (vertex shading) on ​​the attributes of the vertices of the primitives to be used for the rendered output being generated. Specifically, appropriate vertex position shading is performed to transform the positions of the vertices from, for example, the "model" space in which they were initially defined to, for example, the "screen" space in which the output is being generated. In an embodiment, vertex shading also includes generating and / or processing other non-positional attributes of the vertices (variation / variation shading). If desired, some or all of the variation shading can also be deferred from the geometry processing and, for example, triggered instead at the binning or rendering stage.

[0311] As well as proper vertex shading, geometry processing may include any other desired form of geometry processing, such as one or more of tessellation shading, transform feedback shading, mesh shading, or task shading. The geometry shading may also generate and / or process attributes of vertices, and / or it may also process and generate attributes of primitives.

[0312] Once the desired geometry processing has been performed, in this embodiment, as Figure 2 As shown, there is a binning / blocking stage 13. (In this regard, it is assumed that the graphics processor 2 in this embodiment is a tile-based graphics processor, and therefore generates respective output tiles for an overall output (e.g., a frame) to be generated separately from each other, with the sets of tiles for the overall output then being appropriately combined to provide the final overall output.)

[0313] The binning process operates to generate appropriate data structures for determining which primitives need to be processed for the corresponding rendered tile of the output being generated. For example, it may sort the primitives into an appropriate primitive list that indicates the primitives to be processed for the corresponding tile or set of tiles. Alternatively, it may generate other data structures, such as a hierarchy of bounding boxes, that can then be used at the rendering / fragment pipeline stage to identify those primitives that need to be processed for the corresponding tile.

[0314] The binning / blocking process 13 may also cull primitives that are not visible (eg, fall outside the view frustum, and / or based on the facing direction of the primitive).

[0315] As part of the geometry processing and / or binning / blocking operations, primitives to be processed are "assembled." As discussed above, primitives are assembled from a set of indices that reference vertices in a set of vertices for the render output processing being performed, based on primitive configuration information that indicates how vertex indices are to be assembled into primitives for processing when generating the render output.

[0316] This primitive assembly can be performed as part of geometry processing and at appropriate stages of geometry processing and / or as part of binning / chunking processing, as desired. There can also be two (or more) "primitive assembly" operations if desired. For example, an initial primitive assembly operation can be performed to identify those vertices that will actually be used for the rendered output being generated before any vertex shading of the vertices is performed, but then there is a later primitive assembly stage that provides a sequence of assembled primitives for the binning / chunking stage.

[0317] Once the binning / blocking process has generated the necessary data structures for identifying the primitives to be processed for the corresponding tile of the rendered output, the primitives can then, and indeed then, undergo the appropriate rendering / fragment processing 14. In the present embodiment, this operation is performed on a tile-by-tile basis, using the data structures generated by the blocking / binning process 13 to identify those primitives that need to be processed for the corresponding tile.

[0318] Rendering / fragment processing may include any suitable and desired rendering and fragment processing operations that may be performed. Thus, it may include, for example, first rasterizing primitives to be processed for a tile into fragments, and then processing those fragments accordingly (e.g., and in an embodiment, by performing appropriate fragment shading of the fragments). Rendering / fragment processing may also or instead include performing ray tracing operations, such as performing rendering by tracing rays for corresponding fragments of corresponding sets of one or more sample positions representing the output being generated. Hybrid ray tracing operations are also possible, if desired.

[0319] The output of the rendering / fragment processing (rendered fragments) is written to a tile buffer (not shown). Once processing has completed for the tile in question, the tile is written to the output data array in memory 6, and the next tile is processed, and so on, until a complete output data array 15 has been generated. The process then continues to the next output data array (e.g., frame), and so on.

[0320] The output data array may typically be an image of a frame intended for display on a display device such as a screen or printer, but may also, for example, include intermediate rendering data intended for use in a later rendering pass (also known as "render to texture" output), or for deferred rendering, or for hybrid ray tracing, etc.

[0321] Figure 3 An embodiment of a graphics processing unit (GPU) 2 is shown, which can execute Figure 2 , and can operate in the manner of the techniques described herein.

[0322] like Figure 3 As shown in FIG, the graphics processor 2 includes a plurality of processing (shader) cores 32, each of which is operable to execute a (shader) program to perform processing operations. Figure 3 As shown, to facilitate this, each shader core 32 includes a programmable execution unit (execution core) 33 operable to execute instructions to perform processing operations.

[0323] Each execution core 33 has appropriate access to the memory system 6 of the data processing system of which the graphics processor 2 is a part, via a pair of hardware controlled buffers 35 , 36 .

[0324] In this embodiment, the shader core 32 is operable to execute both "compute" shader programs (to perform so-called compute shading) and fragment shader operations. Figure 3 As shown in , each shader core 32 includes appropriate compute endpoints 37 and fragment endpoints 38, which act as control interfaces for performing compute shading and fragment processing, respectively, and will, for example and in an embodiment, trigger the execution core 33 as needed to perform appropriate compute shading or fragment shading tasks.

[0325] like Figure 3 As shown, the compute endpoint 37 and the fragment endpoint 38 receive appropriate processing tasks from the job control unit 39 of the graphics processor 2. The job control unit 39 includes an appropriate compute scheduler 40 and a fragment iterator 41 for distributing the processing jobs received by the job controller 39 to the shader core 32 as appropriate processing jobs.

[0326] As discussed above, when graphics processing is performed, there will typically be an initial geometry processing pipeline stage that determines the vertices and other data necessary to generate the graphics processing output in question, which will then be followed by a rendering / fragment pipeline for processing (rendering) that geometry.

[0327] In this embodiment, if Figure 3 As shown, geometry processing is performed by a geometry packet pipeline 42 of graphics processor 2. The geometry packet pipeline is operable to trigger the execution of one or more "geometry" shader stages (which themselves will be executed by shader core 32 under the control of the geometry packet pipeline 42).

[0328] For example, Figure 3 As shown in FIG, a geometry grouping pipeline 42 includes an input grouper 43 that can trigger position shading and vertex shading 50 by the shader core 32. The geometry grouping pipeline also includes other shader stage circuits 44, 45, 46 that can be operated to trigger the compute shader 5 for performing geometry processing, such as task shaders, mesh shaders, tessellation shaders, etc. (which will again be executed by the shader core 32).

[0329] like Figure 3 As shown in FIG, the geometry packet pipeline 42 has an appropriate interface 47 to the compute scheduler 40 of the job control unit 39, via which the geometry packet pipeline can control and trigger the shader core 32 to perform appropriate geometry shading operations.

[0330] The overall operation of the geometry grouping pipeline 42 is controlled by the job control unit 39 (by the geometry iterator 48 of the job control unit 39 ), which distributes the appropriate geometry processing jobs and tasks to the geometry grouping pipeline 42 .

[0331] Figure 3 The graphics processor 2 is configured to perform rendering in a tile-based manner (as discussed above). To facilitate this, Figure 3 As shown in , each shader core 32 also includes a distributed binning core 49 that is operable to generate appropriate data structures for determining which primitives need to be processed for the corresponding rendering tile of the output being generated.

[0332] In this embodiment, the distributed binning core 49 generates a hierarchy of bounding boxes for primitives and primitive groups containing the primitives to be rendered (which are then used at the rendering / fragment pipeline stage to identify those primitives that need to be processed for the corresponding tile).

[0333] The distributed binning core 49 may also cull primitives that are not visible (eg, fall outside the viewing frustum, and / or based on the facing direction of the primitive).

[0334] Distributed binning core 49 may operate in any suitable and desired manner for this purpose.

[0335] like Figure 3 As shown in , distributed binning core 49 of shader core 32 may trigger vertex shading, such as variation shading, as part of its operation (eg, where variation shading is not performed by an input grouper as part of input grouper 43 operation).

[0336] In the present embodiment, rendering / fragment processing is performed by executing appropriate fragment processing operations on the shader core 32 under the control of the fragment front end 38. To facilitate this, as Figure 3 As shown in , the fragment endpoint 38 of each shader core is operable to trigger the appropriate fragment shader operation of the shader core.

[0337] As should be understood from the above, in operation of the present embodiment, the geometry grouping pipeline 42 performing geometry processing will generate appropriate geometry data, such as (transformed) vertex positions, vertex variances, and primitive attributes (which data may be viewed as corresponding data elements (e.g., positions or variances in the case of vertices), respectively) for corresponding work items (e.g., vertices), which will then be used, for example, by binning / blocking and rendering / fragment processing at later stages of the graphics processing pipeline.

[0338] In this embodiment, the geometry packet pipeline 42 operates to generate corresponding geometry packets containing the data it generates. In this embodiment, these geometry packets are then processed by the distributed binning core 49 to generate corresponding primitive packets, which are then used by the fragment processing (fragment shader).

[0339] Thus, in this embodiment, the geometry grouping pipeline 42 will generate work item groups in the form of geometry groups that store data elements (attributes) for work items (such as vertices and primitives), which will then be read and used by the distributed binning core 49. Correspondingly, the distributed binning core 49 will generate appropriate primitive groups that store data elements (attributes) for work items (such as vertices and primitives), which will then be read and used by the fragment processing 38.

[0340] Various other arrangements are of course possible. For example, the geometry grouping pipeline 42 may interface and provide the geometry groupings to the tiling unit 59, which then performs more traditional tiling operations using the geometry groupings, for example, in a normal (serialized) manner for tile-based graphics processing, rather than as Figure 3 The geometry grouping pipeline 42 shown in generates geometry groups that are then read and used by the distributed binning core 49. An example of this is shown in Figure 4 It is schematically shown in FIG.

[0341] Figure 5 An example of a geometry grouping pipeline 42 that may be performed according to the present embodiment is shown in more detail.

[0342] like Figure 5 As shown in , in this embodiment, the geometry grouping pipeline 42 includes (can trigger execution of) six shader stages, an input grouper 43 (can trigger vertex shading (VS)), and the six shader stages are: the next shader stage 60 that can trigger tessellation control shading or task shading; the next shader stage 61 that can trigger tessellation shading or mesh shading; the next shader stage 62 that can trigger further tessellation shading; the next stage or stage 63 that can trigger tessellation evaluation shading; the next stage or stage 64 that can trigger geometry shading; and the final shader stage 65 that can trigger feedback shading of the transform.

[0343] In operation, each shader stage of the geometry grouping pipeline 42 will configure a compute context for the shader running from the stage in question.

[0344] In this embodiment, as will be explained further below, when executing the geometry grouping pipeline for rendering output (e.g., for a draw call), the Figure 5 In other words, not every execution of the geometry grouping pipeline 42 will include Figure 5 Rather than all of the shader stages shown in , selective shader stages may be omitted from the geometry grouping pipeline 42 being executed.

[0345] Thus, the geometry processing pipeline 42 may include a plurality of pipeline stages of different types, namely, an input grouper 43, one or more shader stages 60-61-62-63-64-65 that may be implemented using general purpose shader stage circuits 44, 45, 46, and optionally a grouped primitive drain unit (e.g., implemented as Figure 4 ).

[0346] As described above, the input grouper 43 reads the index array and creates groups that can be used by the rest of the pipeline. Thus, in this embodiment, the only shading that can be invoked by the input grouper 43 is vertex shading (which can be position-only vertex shading or combined position and variation shading). The input grouper 43 can also be selectively disabled and / or enabled without shading and filled with (pre-colored) input vertices. In this regard, various arrangements will be possible, depending on the specific processing operations to be performed.

[0347] Once the packet has been fully filled by the input packetizer 43 (when this is completed), the packet is sent to the next stage in the geometry processing pipeline 42, which then processes the incoming packet and performs any desired shading, such as described above. Thus, as described above, the geometry processing pipeline 42 also includes a plurality of shader stages 60-61-62-63-64-65 implemented using general shader stage circuitry 44, 45, 46 that can and does dynamically configure the corresponding shader stages to perform the desired pipeline operations prior to execution of the geometry processing pipeline 42.

[0348] Figure 6 The shader stage circuits 44, 45, 46 of the geometry grouping pipeline 42 are shown in greater detail. Specifically, Figure 6 Two of the shader stage circuits 44 , 45 , 46 are shown connected together to illustrate how data may flow along the geometry packet pipeline 42 through the shader stage circuits and onto the next shader stage circuit.

[0349] like Figure 6As shown in FIG, the shader stage circuits 44, 45, 46 are operable to receive incoming packets / state changes to be processed (either from the input packetizer 43 or from a previous shader stage circuit in the geometry packet pipeline 42). The incoming packets / stage changes are then processed within the shader stage front-end circuits 450, 460, which interface and communicate with the memory manager 70 and the general shading interface 47 of the geometry packet pipeline 42, as will be further explained below. The shader stage front-end circuits 450, 460 are operable to output packets into respective packet queues 452, 462 maintained by each shader stage circuit 44, 45, 46, and the packets may be processed from the respective packet queues 452, 462 by the shader stage back-end circuits 454, 464, which may be further explained below. Figure 5 , for example, is operable and configured to pass packets to the next shader stage circuitry within the geometry packet pipeline 42 .

[0350] Thus, the packet / state change may pass through the shader stage circuits 44 , 45 , 46 and onto the next shader stage circuit 44 , 45 , 46 and so on until it has reached the end of the geometry packet pipeline 42 .

[0351] like Figure 6 As shown in , each shader stage circuit 44, 45, 46 can be, and in this embodiment is, 'generic,' i.e., it is generally operable to perform the same underlying basic processing operations (but with different shader stage circuits 44, 45, 46 being configured to perform different processing operations to perform different shader stages). This means, then, that the shader stage circuits 44, 45, 46 can be generally implemented in hardware, with the different processing operations being controlled according to appropriate software configuration of the shader stage circuits 44, 45, 46 based on the overall (desired) configuration of the geometry grouping pipeline 42.

[0352] Thus, as will be explained further below, there can be an initial configuration of the geometry grouping pipeline 42 in which the respective shader stage circuits 44, 45, 46 are configured to perform the desired processing operations (and this initial configuration can be performed in advance (e.g., per render pass). Subsequent state changes can also be passed down to the geometry grouping pipeline 42 to update / set state as needed, such as between draw calls).

[0353] like Figure 6 As shown in , each shader stage circuit 44 , 45 , 46 may therefore access a local copy of a state vector 456 , 466 that stores the configuration state of that shader stage circuit, including, for example, an indication of the type of shading request to be triggered by that shader stage circuit.

[0354] Thus, this may provide a more flexible approach for supporting different types of shader operations that are required.

[0355] In this regard, it should be understood that although the various shader stage circuits 44, 45, 46 are depicted as separate stages and, at least from a logical perspective, are considered to define separate stages of the geometry grouping pipeline 42, the shader stage circuits 44, 45, 46 can, and in some embodiments do, share physical hardware circuitry. That is, in general, there can be (and typically will be) fewer physical stages implemented in hardware than there are logical stages within the geometry grouping pipeline 42, with the same hardware being configured / reconfigured to implement different logical stages as needed. In one embodiment, there are at least two separate physical circuits that can be used to implement the different pipeline stages (to allow for some parallelism / overlap of pipeline stages), but in principle there can be only a single physical circuit that supports all pipeline stages, with data flow between pipeline stages being appropriately managed, for example, based on memory pool allocations, etc.

[0356] The geometry processing pipeline 42 may also include a suitable packet drain unit at the end of the geometry processing pipeline 42 that drains fully processed packets from the geometry processing pipeline 42 .

[0357] For example, Figure 4 As shown in , the geometry processing pipeline 42 can interface with and be connected to a blocking unit 59 that pulls fully processed packets from memory, writes the fully processed packets to an on-chip payload storage device, drains the packets, and assembles primitives from the processed packets. The blocking unit 59 can perform visibility culling of primitives, but any visible primitives can then (and do) be drained from the packets in order and sent to a blocker pipeline (not shown). The blocker pipeline can then perform bounding box culling and binning of the primitives, for example, in the normal manner for such blocking operations, and output the vertex data and polygon lists necessary for fragment shading.

[0358] Alternatively, if Figure 3 As shown in and described above, draining of packets may be performed by a distributed binning core 49.

[0359] In this regard, various arrangements for draining fully processed packets from the geometry processing pipeline 42 would be possible.

[0360] When work is to be performed using the geometry grouping pipeline 42, in one embodiment this is triggered by executing a suitable instruction (e.g., a 'RUN_PIPELINE' instruction, as will be explained further below), and execution of such an instruction causes work to be started on the first enabled stage in the geometry processing pipeline 42. This first stage may be the input grouper 43 or a subsequent shader stage, depending on the particular operation to be performed (e.g., and specifically, whether the input grouper 43 is present / enabled).

[0361] The first stage requests an allocation of a packet from the memory manager 70 that is bound to the first stage's corresponding memory pool. If the allocation is successful, the first stage issues a shading request for the packet to the compute scheduler 40 within the job control unit 39 of the graphics processor 2 via its general shading interface 47. The compute scheduler 40 then schedules the corresponding one or more processing tasks to the corresponding compute endpoints 37 of the shader core 32. In this embodiment, the shader program that runs on the packet issued by a particular stage is defined by a unique shader program descriptor for that stage, which is configured as part of the initial pipeline configuration.

[0362] Thus, successive packets issued for shading are distributed to the available shader cores 32 in this manner, with packet shading being controlled via the compute shader scheduler 40 (and compute endpoints 37).

[0363] Figure 7 is a flow chart illustrating in more detail the shader stage front-end operations that may be performed by the shader stage. Figure 7 As shown in , both the grouping of pending work items and the grouping of states pass through the pipeline stages in a similar manner. Thus, the shader stage front end waits to receive a new grouping (step 700) and then determines whether the grouping includes a grouping of pending work items or whether the grouping includes a state update (step 701). For a state update, the relevant state is updated (step 702) and then the group is added to the group queue (step 703) so that the state update can be passed to the next pipeline stage. This then allows the state update to be propagated through the pipeline stages to allow the graphics processing pipeline to be appropriately updated / reconfigured for different instances of the graphics processing pipeline execution.

[0364] For work item grouping, the shader stage front end first checks whether the job size is defined (step 704), that is, whether the shader stage has the information required to process the grouping of work items. If not (step 704-No), the shader stage front end can wait for other groups of the current job (step 705). If a group containing an appropriate 'end command' indicating that the current job is complete (that is, all groups of all draw calls for the job have been processed) is received (step 706-Yes), the group can be added to the group queue (step 707) so that the 'end command' can be passed to the next pipeline stage. Otherwise, once the job size is defined (step 704-Yes), or as long as no 'end command' is received so that there are other groups to be processed for the current job (step 706-No), the shader stage front end continues to process other groups of the current job (step 708). Group processing in the shader stage front end is performed as follows.

[0365] First, the shader stage front end determines from the packet header (ie, including the packet metadata) how many (if any) output packets should be generated from the incoming packet, and creates a corresponding (first) output packet (step 709).

[0366] The output packet is then processed by the shader stage front end, which sends a message to the memory management system to allocate the corresponding portion of the memory pool bound to the current pipeline stage (step 710), and writes the corresponding packet header to the portion of the memory pool (step 711). The packet is then issued for shading (step 712) and added to the packet queue of the current pipeline stage (step 713). Specifically, when a packet is issued for shading (i.e., at step 712), this is accomplished by issuing an appropriate shading request via the general shading interface 47, which should indicate to the shader core set the corresponding shader program to be executed for the packet in question (if any) and the memory location of the input / output packet for which shading is to be performed.

[0367] This is then repeated until all desired output packets have been created and added to the packet queue (ie, following the 'step 714 - no' loop).

[0368] Once all output packets created from the corresponding incoming packets have been processed in this manner (step 714-Yes), the shader stage front end then waits for the next incoming packet from the current job (step 705), and then processes the next incoming packet in the same manner. Once all packets of the current job have been processed (i.e., an 'end command' is received (step 706)), the job is completed, and the shader stage front end waits for the next packet (step 700) (i.e., the next job).

[0369] Thus, the shader stage front end is configured to issue packets for shading (ie, step 712) and maintain a corresponding packet queue comprising packets currently being processed by the shader stage in question.

[0370] Figure 8 is a flow chart showing how packets are updated in the packet queue. Note that this process is asynchronous with the shader stage front-end operations. Therefore, shading of packets can be completed out of order, but packets are still kept in the packet queue in order (and provided in this same order for output to the next pipeline stage).

[0371] Therefore, if Figure 8 As shown in , after a packet has been issued for shading, the pipeline stage should then wait to receive a shading response (step 800). If the response is that shading has failed (step 801 - Failed), the packet is marked as having failed in the packet queue, and processing of the packet by the current shader stage is completed accordingly (step 802).

[0372] On the other hand, when the shading response indicates that the requested shading has been performed (step 801-completed), the corresponding entry for the packet in question is selected from the packet queue (step 803), and the packet header for the entry is then read from memory (step 804), and once the packet header data has been read in step (step 805), the queue entry is updated with the packet header data (step 806) (e.g., based on the result of shading). The packet queue entry is then marked as valid, and processing of the packet by the current shader stage is completed accordingly (step 807).

[0373] like Figure 8 As shown, each packet queue entry is therefore processed in the same manner. Thus, completed packets are queued in the packet queue for output to the next shader stage in the geometry packet pipeline 82.

[0374] Thus, the next shader stage in the geometry packet pipeline 82 receives the shaded packet from the packet queue of the previous shader stage and then treats the shaded packet as an incoming packet to that next shader stage (and thus as Figure 7 ).

[0375] like Figure 7 As shown in , a given shader stage may thus receive an incoming packet from a previous shading stage in the pipeline, assign a corresponding output packet based on the incoming packet, and process the incoming / output packet as needed (including handling any amplification and issuing shading requests, etc.). Any metadata resulting from the processing of the input / output packet may then be written to the corresponding packet header in the allocated memory pool portion of the packet, and the packet may then be propagated to the next stage in the geometry packet pipeline 82.

[0376] It will be appreciated that when processing a given (child) packet, subsequent shader stages may also need to use output data generated by processing the corresponding (parent) packet in an earlier pipeline stage. Thus, the data for a packet may need to remain in its corresponding allocated memory pool portion until all subsequent shader stages that may require that data have completed processing any corresponding child packets that may require that data. Consequently, these packets may be deallocated in the last stage of the geometry packet pipeline 82 that requires their data. In one embodiment, packet deallocation is performed by the shader stage back end.

[0377] Figure 9 is a flowchart showing the backend operations of the shader stage in more detail. Figure 9 As shown in , the shader stage backend waits for the packet at the head of the packet queue to be complete and valid (i.e., Figure 8 Before pushing the packet to the next shader stage (step 902), the shader stage backend checks whether the current shader stage should deallocate the corresponding parent (or grandparent, etc.) packet of the packet currently being processed (step 901). This is determined based on whether the current shader stage is the last shader stage that potentially needs to access the data stored for the parent packet. If not (step 901-No), the packet is output to the next stage (step 902), and the next packet at the head of the packet queue is processed in the same manner.

[0378] However, if the current shader stage should trigger deallocation of the parent group (step 901-yes), then a check is performed to see if the current group is the last child (grandchild, etc.) of the parent group to be deallocated. If not (step 903-no), the group is output to the next stage (step 902), and the next group at the head of the group queue (which in this case should be another child (grandchild, etc.) of the same parent group) is processed in the same manner. Once the last child (grandchild, etc.) of the parent group to be allocated has been processed (step 903-yes), the shader stage backend can then trigger invalidation of the parent group so that its corresponding memory pool allocation can be deallocated (step 904).

[0379] In the present embodiment, this is accomplished by the shader stage back end sending a message to the memory manager 70 to trigger the deallocation of the corresponding memory pool portion previously allocated to the parent packet.

[0380] Will refer to Figure 10 Describes memory allocation and deallocation in more detail. For example, Figure 3 (and Figure 4), the geometry packet pipeline 42 also has a shared memory manager 70 that manages the allocation and deallocation of memory for temporary packet data for each pipeline stage (e.g., as described above).

[0381] In this regard, Figure 10 As shown in , each shader stage circuit 44, 45, 46 is allocated its own memory pool for storing its corresponding data. Figure 10 As shown, the memory pool resides in a defined overall geometry buffer for the geometry grouping pipeline 42, which is divided into multiple contiguous memory pools for use by the corresponding pipeline stages. In this regard, various arrangements are of course possible, and the geometry buffer can reside in any suitable and desired memory.

[0382] Figure 10 Therefore, the layout of the geometric structure buffer in this embodiment is shown schematically. Figure 10 As shown, the geometry buffer contains several memory pools (implementation-defined). Figure 10 In, for Figure 5 The six shader stages shown in define four memory pools (Mempool#0, Mempool#1, Mempool#2, Mempool#3), but other arrangements are of course possible. In general, the memory pools can be of different sizes, but in Figure 10 In the example shown in , each memory pool has the same size. Figure 10 As shown, each memory pool has a corresponding head pointer and tail pointer pair, where the head pointer points to the next allocated address and the tail pointer points to the next deallocated address.

[0383] Since allocations and deallocations in a memory pool always occur sequentially, this avoids any need to track individual allocations. When an allocation reaches the end of a memory pool, the pointer moves to the beginning of the memory pool. As described above, the allocated portion of the memory pool should therefore be deallocated to free up memory in the memory pool for future packet allocations (and this memory deallocation is as described above with respect to Figure 9 proceed as described).

[0384] For each memory pool, a corresponding memory pool access bit mask is generated during the initial pipeline configuration to indicate which pipeline stages access the memory pool. For example, the first shader stage to access a given memory pool always allocates a packet to that memory pool (and therefore the corresponding bit for that shader stage should be set accordingly in the memory pool access bit mask for that memory pool to indicate that it is the first shader stage to access that memory pool). The last shader stage to access a given memory pool (and for that shader stage, a bit is set in the memory pool access bit mask for that memory pool) can then operate to trigger the deallocation of packets for that memory pool. Any intermediate shader stage can only access the memory pool (but cannot perform any memory allocation / deallocation), for example, by reading and / or writing allocated packets.

[0385] Therefore, for any shader stage accessing a given memory pool, the memory pool configuration should set the corresponding bit in the memory pool access mask, and the memory pool access mask defines the access permissions to the memory pool in question.

[0386] In this regard, in this embodiment, any shader stage except the packet primitive drain unit can make a request to the memory manager to allocate a packet, depending on the specific configuration of the shader stage, but the stage can only allocate packets from the memory pool designated for the stage for the current instance of the graphics processing pipeline 42 (note that access permissions can be reconfigured between instances of the graphics processing pipeline 42). Similarly, all stages except the input packetizer 43 can deallocate one or more parent packets, depending on the specific configuration of the shader stage request from the memory manager (deallocation of a parent packet is triggered by the last shader stage that potentially needs the data of the parent packet).

[0387] This means that a given stage can only allocate within the memory pool assigned to that stage (i.e., a memory pool cannot be shared by multiple stages for allocations). Because all packet payloads allocated by a given stage will be allocated in the same memory pool, this means that all packets should share the same size (at least for the current instance of execution of graphics processing pipeline 42).

[0388] Therefore, as mentioned above, and as Figure 7 As shown in FIG, in the geometry packet pipeline 42, when a shader stage in the geometry packet pipeline 42 requests a packet, the memory manager 70 allocates the packet. Once the corresponding portion of the designated memory pool is allocated, the packet can be issued for shading. Each stage in the geometry packet pipeline 42 contains an internal packet queue that buffers and tracks the allocated packet payloads. The packet queue operates in a 'first in, first out' manner, so that packets are maintained in the strict order in which the associated packet payloads were allocated.

[0389] like Figure 8 As shown in , when the shading completion message for a shaded packet is returned to the shader stage that issued the request, the corresponding packet entry in the packet queue for that packet is marked as completed. The shader will typically write some packet metadata to memory (i.e., the results of the packet shading), and this may need to be sent back and communicated to the shader stage. The shader stage is therefore operable to issue an appropriate memory read for the packet payload and copy the contents of the packet header to the corresponding portion of the designated memory pool allocated for the packet.

[0390] like Figure 9 As shown, the completed packets at the front of the packet queue are then pushed to the next stage in the geometry packet pipeline 42. The contents of the packet are typically used by the next shader stage in front-end processing to determine if / how the parent packet must be expanded into multiple child packets and to allocate new packet payloads based on parameters from the parent packet.

[0391] Thus, packets flow down the geometry packet pipeline 82 in order from one pipeline stage to the next enabled pipeline stage, and so on, with each stage in the geometry packet pipeline 82 processing the packets in the order in which they were assigned.

[0392] The geometry packet pipeline 82 may therefore implement certain waits to ensure that strict packet ordering requirements are enforced as packets are passed down the geometry packet pipeline 82. For example, a given shader stage should stall while waiting for a shading completion response for any packet being shaded. Similarly, a given shader stage should stall when a shader stage requests memory allocation for a packet, but the memory allocation is stalled by the memory manager 70 (this may typically occur when there are outstanding allocation requests for the same memory pool or when the memory pool is full). Finally, the geometry packet pipeline 82 may stall waiting for a fully processed packet to drain from the last shader stage.

[0393] Now refer to Figure 11 A specific example of the operation of the geometry grouping pipeline according to an embodiment is described. Specifically, in this example, tasks and mesh shaders are enabled, where Figure 12 shows the operation of the task shader stage, and Figure 13 The operation of the next mesh shader stage is shown.

[0394] Figure 11 Thus schematically shown is an example of processing within the geometry grouping pipeline 42 for a draw call with task and mesh shaders enabled.

[0395] Figure 11Thus the commands and groupings at the interface of the task and mesh shader stages are shown. Figure 11 As shown in and described above, commands are passed down through the front end, packet queue, and back end of each shader stage and output to the next shader stage. For example, as described above, incoming packets are processed in the front end, and new packets may be created as part of these front end processing operations. These packets are then inserted between the corresponding pair of START_DRAWCALL and END_DRAWCALL commands that define the current draw call.

[0396] Figure 12 The flow through the shader stages processing a task shader is shown in more detail.

[0397] Therefore, if Figure 12 As shown in , incoming commands begin with one or more commands (collectively 'GSV_SET_STATE' commands) that set the state of the current draw call. These GSV_SET_STATE commands are appropriately processed within the front-end state tracker circuitry of the shader stage front-end and used to update any relevant state in the state vector stored for that shader stage.

[0398] The START_DRAWCALL command defines the job size, and the job is iterated by the group calculation iterator at the front end of the shader stage to create the corresponding output group (header) when necessary. In this example, there are three calls to the task shader. The first task shader output mesh call count = (1, 1, 1). The second output mesh call count = (0, 0, 0). The last output mesh call count = (1, 1, 2).

[0399] For each output packet created for the job, the memory allocator in the shader stage front end then allocates the corresponding portion of the specified memory pool for the shader stage in question and writes the packet (header) to the allocated memory. The packet request is then shaded and the packet is added to the packet queue, which is then updated as described above when a shaded response is received.

[0400] The GSV_SET_STATE command also triggers an update of the state vector when reaching the back end of the shader stage.

[0401] This package is then output to the mesh shader stage. Figure 13 The flow through the shader stages that process the mesh shader is shown in more detail. The mesh shading is then performed, as Figure 13 shown (and as described above).

[0402] In this example, the main difference between task and mesh shading is that the job size is defined for the shader stage that handles the task shader. This means that the task shader does not receive any input packets, but instead generates packets based on the defined job size. However, the shader stage that handles the mesh shader does not have a job size defined for each draw call, but instead receives the job size from the incoming packets.

[0403] Each incoming packet may define a different job size. This may be specified, for example, in the packet metadata (header), which may indicate the number of sub-packets to be called, etc.

[0404] So, in this example, the input to shader stage #0 (the task shader) is:

[0405] - One or more commands to set the graphics state vector

[0406] - Start of draw call

[0407] - End of draw call

[0408] Correspondingly, the input to shader stage #1 (mesh shader) is:

[0409] - Same command as input to shader stage #0 used to set the graphics state vector

[0410] - The same draw call command starts

[0411] - Three groups of output from three invocations of the task shader

[0412] - End of draw call

[0413] The output from shader stage #1 (the mesh shader) is therefore:

[0414] - Same command as input to shader stage #0 used to set the graphics state vector

[0415] - The same draw call command starts

[0416] -Five output groups created in shader stage #1 (mesh shader).

[0417] - End of draw call

[0418] The output from shader stage #1 (mesh shader) will then in turn be provided to the next enabled pipeline stage (e.g., see Figure 5 ), where the command will propagate through the pipeline stages, with additional packets being created / processed in each pipeline stage as necessary as part of the geometry packet pipeline 42 execution.

[0419] The geometry grouping pipeline 42 is therefore a new hardware block within the graphics processor 2 that serves as a single entry point for the entire geometry flow, feeding either the blocker or the distributed binning core as appropriate.

[0420] As will be appreciated from the above, the geometry grouping pipeline 42 enables programmable group shading and configures several general-purpose shader stage circuits. Thus, the geometry grouping pipeline 42 can be implemented using one or more general-purpose (in hardware) programmable shader stage circuits, where these shader stage circuits are configured in software to implement the desired logical stages of the geometry grouping pipeline 42.

[0421] Therefore, another aspect of the present invention is the initial configuration (and subsequent reconfiguration) of the geometry grouping pipeline 42.

[0422] For example, the geometry grouping pipeline 42 in this embodiment is configured in software at a render pass granularity before any work (i.e., draw calls) is pushed into the geometry grouping pipeline 42. Thus, an initial configuration is performed to map the logical stages in the geometry flow (e.g., vertex shading, geometry shading, task and mesh shading, tessellation, transform feedback, or any valid geometry flow combination) to one or more stages in the geometry grouping pipeline 42.

[0423] Thus, the initial pipeline configuration in this embodiment may involve any of the following, and in some embodiments involves all of the following: (i) enabling one or more stages of the geometry grouping pipeline; (ii) configuring shader program descriptors for each enabled stage; (iii) configuring the workgroup dimensions for each stage; (iv) configuring one or more memory pools and binding each memory pool to a unique stage responsible for allocating groups in the memory pool; (v) configuring the group size and layout for each memory pool; and (vi) setting a memory pool access mask for each memory pool to indicate which shader stages can access the memory pool (where the first stage to access a given memory pool is always the stage that allocates part of that memory pool, and the last stage to access that memory pool is always the stage that deallocates part of that memory pool).

[0424] Once the geometry grouping pipeline 42 is configured, processing work may be issued to the geometry grouping pipeline 42 .

[0425] In the present embodiment, this is accomplished by the graphics processor using a corresponding 'RUN_PIPELINE' command, which may be included in a command set for the graphics processor to trigger execution of one or more instances of the geometry grouping pipeline 42 .

[0426] The command set for the graphics processor will typically be prepared by the CPU 1 . Figure 14 An example is shown in which CPU 1 prepares a command set for a graphics processor according to an embodiment.

[0427] Therefore, if Figure 14 As shown in FIG, in response to CPU 1 receiving a request from application 9 executing on CPU 1 for processing to be performed using graphics processor 2, and specifically a request to perform processing that can advantageously use geometry grouping pipeline 42 (step 1400), CPU 1 then prepares a suitable command set for graphics processor 2, including one or more commands that trigger execution of geometry grouping pipeline 42 (step 1401). This can be done, for example, by driver 10 for graphics processor 2.

[0428] The driver 10 of the graphics processor 2 then issues a command set to the graphics processor 2 for execution (step 1402). Specifically, the command set will be received and processed by the job control unit 39 of the graphics processor 2, for example as described above. The job control unit 39 is therefore operable to identify commands that perform processing work for the geometry grouping pipeline 42 and distribute these commands to the geometry grouping pipeline 42 accordingly.

[0429] Figure 15 Corresponding graphics processor operations in response to receiving such a command set are shown, according to an embodiment.

[0430] Therefore, if Figure 15 As shown in FIG, the job control unit 39 will see in the command set that it is processing a command to trigger execution of the geometry grouping pipeline 42 with a set of one or more draw calls (step 1500). The job control unit 39 then adds the appropriate RUN_PIPELINE command to the command buffer for the geometry grouping pipeline 42 (step 1501).

[0431] It will be understood here that the command seen by the job control unit 39 may be the RUN_PIPELINE command itself, or may be another higher level command that carries the RUN_PIPELINE command to a command buffer for the geometry packet pipeline 42 .

[0432] In this regard, various arrangements would be possible.

[0433] The geometry grouping pipeline 42 will then execute the commands from its command buffer in sequence, i.e., cause the commands to be executed and issued from the command buffer into the geometry grouping pipeline 42. Thus, when the command buffer execution reaches a RUN_PIPELINE command, the RUN_PIPELINE command will be executed accordingly, and this will trigger execution of the geometry grouping pipeline 42 for the corresponding draw call (or multiple draw calls) for which the RUN_PIPELINE command was prepared (step 1502).

[0434] That is, in this embodiment, what triggers the execution of the geometry packet pipeline 42 is the execution of a specific RUN_PIPELINE command included in the command set that has been prepared for the graphics processor.

[0435] In this embodiment, execution of the RUN_PIPELINE command also triggers relevant pipeline configuration information for executing the geometry grouping pipeline 42 to be transferred to a local storage device associated with and accessible by the geometry grouping pipeline 42 (i.e., this is also accomplished as part of step 1502). This local storage device may include, for example, a storage device associated with each shader stage circuit 44, 45, 46 that stores a local copy of the state vector 456, 466 for the shader stage circuit in question, but the local storage device may also include a 'global' pipeline storage device that is operable to store, for example, configuration information that applies to all shader stages.

[0436] In this regard, it will be appreciated from the above that the initial pipeline configuration will typically be performed in software, such as on CPU 1. The pipeline configuration information may thus be written to memory and subsequently transferred to the graphics processor as required, preferably by the job control unit 39 (e.g., by CPU 1 including appropriate commands in a command set to move such pipeline configuration information from its location in memory to a corresponding register file of a register set resident in the job control unit 39 of the graphics processor 2).

[0437] Thus, in this embodiment, when executed from the command buffer, the RUN_PIPELINE command retrieves several input scratch register values ​​directly from such a register file. For example, one register in the register pair contains a pointer to a pipeline state configuration descriptor, which encapsulates configuration parameters that apply to one or more draw calls. Thus, the configuration parameters can be transferred from such a register file to a local storage device associated with and accessible by the geometry grouping pipeline 42.

[0438] The pipeline configuration information transferred to the local storage device in response to executing the RUN_PIPELINE command thus controls the corresponding execution of the geometry grouping pipeline 42 for the draw call to which the RUN_PIPELINE command relates.

[0439] For example, the pipeline configuration information transferred to a local storage device associated with and accessible by the geometry grouping pipeline 42 may include any (and all) information that may be needed to configure / execute the geometry grouping pipeline 42.

[0440] Thus, the pipeline configuration information may include, but is not limited to: (i) an indication of which stages of the geometry grouping pipeline are enabled; (ii) a shader program descriptor for each shader stage; (iii) a workgroup dimension for each shader stage (e.g., for controlling the expansion of a group into sub-groups); (iv) a group size and layout for each memory pool; and (v) a memory pool access mask for each memory pool, which indicates which shader stages can access the memory pool (and therefore also indicates the first stage that can access the memory pool (which should therefore be allowed to allocate portions of the pool) and the last stage that can access the memory pool (which can trigger deallocation of portions of the pool), etc.

[0441] Once the RUN_PIPELINE command has been executed with respect to a draw call, and the relevant pipeline configuration information has been transferred to the local storage associated with the geometry grouping pipeline 42, the geometry grouping pipeline 42 is executed for the draw call in question. Then, depending on the specific configuration of the geometry grouping pipeline 42 specified by the pipeline configuration information, e.g. Figure 6 Execution of the geometry grouping pipeline 42 is performed as described above. The geometry grouping pipeline 42 thus processes the draw call, and when this has completed, processing of that draw call (ie the current instance of execution of the geometry grouping pipeline 42) is complete (step 1503).

[0442] although Figure 14, but a typical command set for a graphics processor may therefore include a RUN_PIPELINE command sequence to trigger execution of the geometry grouping pipeline 42 for a corresponding sequence of draw calls (e.g., within a particular rendering pass). Execution of the geometry grouping pipeline 42 execution for each draw call is thus preferably accomplished in the same manner as described above, i.e., by executing a corresponding RUN_PIPELINE command, which causes the relevant pipeline configuration information for the next instance of the geometry grouping pipeline 42 execution to be transferred to the local storage associated with the geometry grouping pipeline 42, and the geometry grouping pipeline 42 to be executed accordingly to process the draw call.

[0443] In this regard, it should be appreciated that use of the RUN_PIPELINE command allows pipeline configuration information to be appropriately updated between instances of geometry grouping pipeline 42 execution (eg, between draw calls), ie, reconfiguring geometry grouping pipeline 42 as needed.

[0444] In some cases, the geometry grouping pipeline 42 may therefore also need to be stopped between instances of the graphics processing pipeline execution, for example and specifically when a reconfiguration affects a memory pool currently in use. In this case, the geometry grouping pipeline 42 should ensure that all packets are drained from the geometry grouping pipeline 42 and deallocated from the memory pool in question, effectively flushing all work for the previous instance of the graphics processing pipeline execution before the memory pool is reconfigured. This then helps ensure correct (safe) behavior between different instances of the geometry grouping pipeline 42 execution.

[0445] Thus, the present invention, at least in its preferred embodiments, provides improved graphics processor operation, particularly through the use of a configurable graphics processing pipeline that can be used to support a variety of different graphics processing flows using a 'generic' set of shader stage circuits.

[0446] The above specific embodiments are presented for the purpose of illustration and description. It is not intended to be exhaustive or to limit the invention to the precise form disclosed. In light of the above teachings, many modifications and variations are possible. The embodiments are selected to best explain the principles of the invention and its practical application, thereby enabling others skilled in the art to best utilize the technology in the various embodiments and with various modifications suitable for the specific use envisioned. The scope of the invention is intended to be defined by the appended claims.

Claims

1. A method for operating a graphics processor, the graphics processor comprising: one or more processing circuits operable to implement a set of general pipeline stages, wherein respective ones of the general pipeline stages in the set of general pipeline stages are configurable as respective different shader stages to be executed as part of a processing pipeline, The method comprises: obtaining, for one or more instances of execution of a processing pipeline, a set of pipeline configuration information, the set of pipeline configuration information comprising an indication of a respective set of one or more shader stages to be executed for the processing pipeline; transmitting the obtained set of pipeline configuration information to a storage device associated with the processing pipeline; and The stored set of pipeline configuration information is used to control operation of the one or more processing circuits to execute the processing pipeline for the one or more instances of the processing pipeline execution. 2 . The method of claim 1 , wherein the set of pipeline configuration information further comprises an indication of which shader program or shader programs should be executed by which of the shader stages to be executed for the graphics processing pipeline.

3. The method of claim 1 , wherein the pipeline configuration information set further includes an indication of which of the shader stages to be executed for the graphics processing pipeline are permitted to allocate portions of memory for groups of work items being processed by the shader stages, and which shader stages are permitted to access portions of memory allocated by other shader stages. 4 . The method of claim 3 , wherein the set of pipeline configuration information further comprises an indication of which shader stages are able to deallocate portions of memory allocated by other shader stages.

5. The method of claim 1 , wherein a shader stage to be executed for the processing pipeline is operable to generate, from an incoming group of work items, a corresponding plurality of sub-groups to be further processed within the shader stage, and wherein the set of pipeline configuration information further comprises a set of one or more parameters for controlling the generation of sub-groups from the incoming group of work items for one or more of the shader stages to be executed for the processing pipeline.

6. A method according to claim 1 or 2, wherein the transfer of the obtained pipeline configuration information set to the storage device associated with the processing pipeline is triggered by executing a corresponding command for performing processing using the processing pipeline from a command buffer for the processing pipeline, and the command for performing processing using the processing pipeline also indicates that the pipeline configuration information set will be transferred to the storage device associated with the processing pipeline.

7. The method according to claim 1 or 2, comprising: obtaining a new set of pipeline configuration information comprising an indication of a corresponding set of one or more shader stages to be executed for one or more further instances of execution of a graphics processing pipeline; and subsequently storing the new set of pipeline configuration information in the storage device associated with the processing pipeline; and using the new set of pipeline configuration information to control operation of the one or more processing circuits to execute the processing pipeline for the one or more additional instances of execution of the processing pipeline.

8. A method of operating a data processing system, the data processing system comprising: Main processor; and A graphics processor, wherein the graphics processor comprises a set of one or more processing circuits operable to implement a set of general pipeline stages, wherein respective ones of the general pipeline stages in the set of general pipeline stages are configurable as respective different shader stages to be executed as part of a processing pipeline, the method comprising: In response to a request from an application executing on a host processor for processing to be performed by the graphics processor, preparing, on the primary host processor, a command set including commands that trigger one or more instances of execution of a processing pipeline, wherein the commands to trigger one or more instances of execution of the processing pipeline, when executed, will cause: A set of pipeline configuration information indicating a respective set of shader stages to be executed for the processing pipeline is transferred to a storage device associated with the processing pipeline; as well as The graphics processor uses the stored pipeline configuration information to control operation of the one or more processing circuits to execute the processing pipeline for the one or more instances of the processing pipeline execution.

9. The method of claim 8 , wherein the set of pipeline configuration information is initially transferred to the graphics processor via command processing circuitry of the graphics processor, the command processing circuitry providing commands to a command buffer for the processing pipeline, and wherein when the commands to trigger one or more instances of execution of the processing pipeline are executed from the command buffer, the commands cause pipeline configuration information to be transferred from a storage device associated with the command processing circuitry to the storage device associated with the processing pipeline.

10. The method of claim 9, wherein the set of pipeline configuration information is initially transferred to a set of registers associated with the command processing circuitry of the graphics processor, and wherein the command used to trigger one or more instances of processing pipeline execution indicates which register values ​​are to be transferred to the storage device associated with the processing pipeline.

11. The method of any one of claims 8, 9 or 10, wherein the set of pipeline configuration information further comprises an indication of which shader program or shader programs should be executed by which of the shader stages to be executed for the graphics processing pipeline.

12. The method of any one of claims 8, 9 or 10, wherein the pipeline configuration information set further comprises an indication of which of the shader stages to be executed for the graphics processing pipeline are permitted to allocate portions of memory for groups of work items being processed by the shader stages, which shader stages are permitted to access portions of memory allocated by other shader stages, and optionally which shader stages are able to deallocate portions of memory allocated by other shader stages.

13. A method according to any one of claims 8, 9 or 10, wherein a shader stage to be executed for the processing pipeline is capable of generating a corresponding plurality of sub-groups to be further processed within the shader stage from an incoming group of work items, and wherein the pipeline configuration information set further includes a set of one or more parameters for controlling the generation of sub-groups from the incoming group of work items for one or more of the shader stages to be executed for the processing pipeline.

14. A method of operating a graphics processor, the graphics processor comprising: one or more processing circuits operable to implement a set of general pipeline stages, wherein respective ones of the general pipeline stages in the set of general pipeline stages are configurable as respective different shader stages to be executed as part of a processing pipeline, The method comprises: In response to the graphics processor receiving a command to perform processing using the processing pipeline: transferring a set of pipeline configuration information indicating a respective set of shader stages to be executed for the processing pipeline to a storage device associated with the processing pipeline; and The graphics processor uses the stored pipeline configuration information to control operation of the one or more processing circuits to execute the processing pipeline for the one or more instances of the processing pipeline execution.

15. The method of claim 14 , wherein the set of pipeline configuration information is initially transferred to the graphics processor via command processing circuitry of the graphics processor, the command processing circuitry providing commands to a command buffer for the processing pipeline, and wherein execution of the commands from the command buffer to trigger one or more instances of execution of the processing pipeline causes pipeline configuration information to be transferred from a storage device associated with the command processing circuitry to the storage device associated with the processing pipeline.

16. The method of claim 15 , wherein the set of pipeline configuration information is initially transferred to a set of registers associated with the command processing circuitry of the graphics processor, and wherein the command used to trigger one or more instances of processing pipeline execution indicates which register values ​​are to be transferred to the storage device associated with the processing pipeline.

17. The method of any one of claims 14, 15 or 16, wherein the set of pipeline configuration information further comprises an indication of which shader program or shader programs should be executed by which of the shader stages to be executed for the graphics processing pipeline.

18. A method according to any one of claims 14, 15 or 16, wherein the pipeline configuration information set further includes an indication of which of the shader stages to be executed for the graphics processing pipeline are permitted to allocate portions of memory for groups of work items being processed by the shader stages, and which shader stages are permitted to access portions of memory allocated by other shader stages, and optionally which shader stages can deallocate portions of memory allocated by other shader stages.

19. A method according to any one of claims 14, 15 or 16, wherein a shader stage to be executed for the processing pipeline is capable of generating a corresponding plurality of sub-groups to be further processed within the shader stage from an incoming group of work items, and wherein the pipeline configuration information set further includes a set of one or more parameters for controlling the generation of sub-groups from the incoming group of work items for one or more of the shader stages to be executed for the processing pipeline.

20. A computer program product comprising instructions which, when executed by one or more processors, cause the one or more processors to perform the method according to any one of claims 1, 8 or 14.

Images