Graphics processor

Abstract

A command for causing a graphics processor to perform processing work for a graphics processing pipeline executable by the graphics processor. A command to perform a processing job for a graphics processing pipeline includes a first portion having a generic opcode interpretable by command processing circuitry of a graphics processor to identify that the command is a command to perform a processing job for a graphics processing pipeline, and a command not used by the command processing circuitry but to the graphics processing pipeline A second portion of the particular processing operation to be performed is identified. The first portion also includes information indicating a set of zero or more data values to be used for one or more processing operations for the graphics processing pipeline.

Description

[0001] The present invention relates to a data processing system including a graphics processor, and more particularly to submitting processing tasks from a main (eg, host) processor of the data processing system to a graphics processor that is part of the data processing system.

[0002] Many data processing systems include processing resources, such as graphics processors (graphics processing units (GPUs)), which can perform processing tasks for applications executing on, for example, a main (eg, host) processor (CPU) of the data processing system.

[0003] By providing a stream of commands (instructions) to be executed by the graphics processor to the graphics processor, the graphics processor can be caused to perform processing tasks for an application executing on the primary (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 the command set to the graphics processor. The graphics processor then executes the commands in the command set (the operations indicated by the commands).

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

[0005] An appropriate command processing unit of the graphics processor (eg, a "command stream front end" / job manager) will then process the commands from start to finish, eg, executing the commands sequentially.

[0006] Therefore, when a graphics processor receives a command from a host processor (e.g., a CPU) that is executing an application requiring graphics processing, the graphics processor's command processing unit (e.g., a command stream front-end / job manager) typically processes the command to identify the processing to be performed. This is accomplished by the graphics processor's command processing unit (e.g., a command stream front-end / job manager) identifying the type of command. For example, each different type of command supported by the graphics processor may have a corresponding (unique) operation code ("opcode") that can be identified by the graphics processor's command processing unit (e.g., a command stream front-end / job manager) and used to determine the processing to be performed.

[0007] However, applicants believe that there is still room for improvement in submitting processing tasks to graphics processors for execution.

[0008] According to a first aspect of the present invention, there is provided a method of operating a data processing system, the data processing system comprising:

[0009] The main (e.g., host) processor; and

[0010] a graphics processor operable to perform processing work for an application executing on a host processor, wherein the graphics processor is operable and configured to perform the processing work by executing a processing pipeline, and wherein the graphics processor includes command processing circuitry operable to process commands received from the primary processor to perform the processing work,

[0011] The method comprises:

[0012] In response to a request from an application executing on the host processor for processing to be performed by the graphics processor, preparing on the primary host processor a set of commands including commands for performing processing work for the processing pipeline, the commands for performing processing work for the processing pipeline including:

[0013] (i) having a first portion having an operation code ("opcode") identifying that the command is a command for performing processing work for the processing pipeline, the first portion also including information indicating a set of zero or more data values ​​to be used for one or more processing operations for the processing pipeline; and

[0014] (ii) a second portion indicating one or more specific processing operations to be performed for the processing pipeline,

[0015] The method further comprises:

[0016] In response to receiving the command for executing the processing work for the processing pipeline:

[0017] processing, by command processing circuitry of the graphics processor, the first portion of the command to determine that the command is a command for performing processing work for the processing pipeline;

[0018] providing (at least) the second portion of the command to the processing pipeline; and

[0019] The second portion of the command is used to determine one or more processing operations to be performed for the processing pipeline.

[0020] According to a second aspect of the present invention, there is provided a data processing system, the data processing system comprising:

[0021] The main (e.g., host) processor; and

[0022] a graphics processor operable to perform processing work for an application executing on a host processor, wherein the graphics processor is operable and configured to perform the processing work by executing a processing pipeline, and wherein the graphics processor includes command processing circuitry operable to process commands received from the primary processor to perform the processing work,

[0023] The host processor is operable and configured to prepare commands for the graphics processor in response to a request from an application executing on the host processor for processing to be performed by the graphics processor, wherein a set of commands for the graphics processor can include commands for performing processing work for the processing pipeline, the commands for performing processing work for the processing pipeline comprising:

[0024] (i) having a first portion having an operation code ("opcode") identifying that the command is a command for performing processing work for the processing pipeline, the first portion also including information indicating a set of zero or more data values ​​to be used for one or more processing operations for the processing pipeline; and

[0025] (ii) a second portion indicating one or more specific processing operations to be performed for the processing pipeline,

[0026] The command processing circuitry of the graphics processor is operable and configured to, in response to receiving a command for performing processing work for the processing pipeline:

[0027] processing the first portion of the command to determine that the command is a command for performing processing work for the processing pipeline;

[0028] providing (at least) the second portion of the command to the processing pipeline; and

[0029] The second portion of the command is used to determine one or more processing operations to be performed for the processing pipeline.

[0030] The present invention relates to an arrangement in which a graphics processor is operable to execute commands (instructions) to perform processing tasks for applications executing on a primary (eg host) processor, the graphics processor thereby acting as a processing resource for the primary (eg host) processor.

[0031] Thus, in response to a request from an application executing on the host processor for processing to be performed by the graphics processor, the primary (e.g., host) processor (e.g., CPU) is operable and configured to prepare one or more command sets for the graphics processor. The command sets prepared by the primary (e.g., host) processor (CPU) are then appropriately processed by the corresponding command processing circuitry (job manager / command stream front end) of the graphics processor, which processes the commands included in the received command sets and provides the commands (or tasks derived therefrom) to other processing circuitry / circuitry of the graphics processor as appropriate to perform the operations indicated by the commands.

[0032] According to the present invention, the graphics processor, when performing processing work, is operable to execute a processing pipeline. Operation of the processing pipeline can therefore be, and preferably is, triggered by the host (e.g., host) processor (CPU) including an appropriate command (or commands) in a command set for the graphics processor to execute processing work for (i.e., associated with and / or using) the processing pipeline.

[0033] Such commands, when encountered by the command processing circuitry (job manager / command stream front end) of the graphics processor, are therefore preferably provided from the command processing circuitry (job manager / command stream front end) of the graphics processor into an appropriate command buffer for the processing pipeline, from which such commands can then be executed, and the corresponding (pipeline) processing operation indicated by the command is then performed accordingly.

[0034] More particularly, the present invention relates to a novel format for such commands used to control a graphics processor when using its processing pipeline to perform processing work.

[0035] In particular, according to the present invention, a command for executing a processing job for a processing pipeline comprises two (separate) parts, namely:

[0036] (i) having a first portion having an operation code (opcode) identifying that the command is a command for performing processing work for the processing pipeline, the first portion also including information indicating a set of zero or more data values ​​to be used for one or more processing operations for the processing pipeline; and

[0037] (ii) comprising a second portion of processing pipeline command information indicating corresponding one or more processing operations to be performed for said processing pipeline (said processing operations can and preferably (and typically) will use the set of data values ​​indicated by said first portion of said command),

[0038] (And when describing embodiments of the present invention, commands in this format may be referred to as "RENDER_OP" commands).

[0039] By providing commands for performing processing work for a processing pipeline in this format (i.e. comprising the separate first and second parts discussed above), the command format according to the present invention thus allows the data values ​​identifying one or more processing operations for the processing pipeline (i.e. as indicated within the first part of the command) to be separated from, and thus extracted from, the indication of the one or more processing pipeline processing operations to be performed using the indicated data values. This can then provide various benefits.

[0040] For example, the effect and benefit of this command format according to the present invention is that the processing pipeline command information (i.e., the information about which processing operations are to be performed, included in the second portion of the command) is effectively made "opaque" to the command processing circuitry (job manager / command stream front end). The second portion of the command therefore does not need to be, and preferably is not, processed by the graphics processor command processing circuitry (job manager / command stream front end), but is instead passed to the processing pipeline by the command processing circuitry (job manager / command stream front end) for processing.

[0041] Therefore, when a command is provided in a format according to the present invention, the command processing circuit (job manager / command stream front end) is preferably capable of and configured to process only the first part of the command, i.e., to determine that the command is a command for performing processing work for the processing pipeline, and the second part of the command can then be (and is) provided to the processing pipeline to determine the actual processing operation to be performed.

[0042] This then means that, at least from the perspective of the command processing circuitry (job manager / command stream front-end), the operation code (opcode) included in the first part of the command can be (and is) a single identical ("universal") operation code (opcode) for performing multiple different processing operations on the processing pipeline, because the operation code (opcode) included in the first part of the command only needs to indicate to the command processing circuitry (job manager / command stream front-end) that the command is a command of this format (type) and that the command should therefore be provided to the processing pipeline for further processing (the second part of the command then indicates the actual processing operation to be performed on the processing pipeline).

[0043] This then simplifies the processing of commands within the command processing circuitry (job manager / command stream front end) because the host (main) processor (CPU) is operable to encode multiple different types of processing pipeline processing operations using a single (identical) command format, and the command processing circuitry (job manager / command stream front end) therefore only needs to process commands in this single (identical) command format for any / all of the different types of processing pipeline processing operations that can be encoded in this manner. This can therefore be done in a more consistent or universal manner for multiple different types of processing pipeline processing operations (e.g., rather than the command processing circuitry (job manager / command stream front end) having to process a respective separate command for each different type of processing pipeline processing operation that can be supported, as is the case in some more traditional graphics processor arrangements).

[0044] As mentioned above, according to the present invention, the first portion of the command also includes information indicating a set of zero or more data values ​​to be used for one or more processing operations for the processing pipeline. Preferably and typically, the first portion will indicate at least one and preferably multiple data values ​​to be used for the one or more processing operations.

[0045] This then means that data values ​​to be used for one or more processing operations for the processing pipeline may also be provided to the processing pipeline as part of the command (i.e. using the first part of the command), but this is done independently of the processing pipeline command information included in the second part of the command which indicates the actual processing operations to be performed for the processing pipeline using these data values.

[0046] This may be particularly beneficial since the data values ​​to be used, or at least the amounts of data to be used, may need to, and preferably therefore, be made visible to the command stream processing circuitry (task manager / command stream front end) (however, as discussed above, it is advantageous for the processing pipeline command information to be opaque to the command processing circuitry (task manager / command stream front end)).

[0047] For example, the command processing circuitry (job manager / command stream front end) may need this information for job control / tracking purposes, as will be explained further below.

[0048] Indicating data values ​​to be used in the first portion of the command (i.e., the portion visible to the command processing circuitry (job manager / command stream front end)) also facilitates the transfer of such data values ​​to the processing pipeline via the command processing circuitry (job manager / command stream front end). For example, as will be explained further below, the data values ​​are preferably transferred via a set of registers associated with the command processing circuitry (job manager / command stream front end), and so it is beneficial for the command processing circuitry (job manager / command stream front end) to have visibility of these data values ​​(even in the event that the command processing circuitry (job manager / command stream front end) does not have visibility into what the data values ​​are to be used for).

[0049] Thus, an indication that a command is a command for performing processing work for a processing pipeline and an indication of a set of data values ​​to be used for one or more processing operations for the processing pipeline can be (and is) accomplished using the first part of the above-described command format and these indications are provided independently of indications of specific processing operations to be performed for the processing pipeline using these data values.

[0050] Furthermore, preferably only this information is included in the first part of the command that is visible to / processed by the command processing circuitry (job manager / command stream front end) (so that the command processing circuitry (job manager / command stream front end) does not have visibility into the specific processing operations to be performed by the processing pipeline using the indicated data values).

[0051] Therefore, once the command processing circuitry (job manager / command stream front end) has identified from the first part of a given such command that the command is a command for performing processing for a processing pipeline, and subject to any further job control / tracking operations that the command processing circuitry (job manager / command stream front end) may desirably perform at that time, the command should then (and therefore) be provided from the command processing circuitry (job manager / command stream front end) to the processing pipeline for further processing.

[0052] The processing pipeline is then operable to use the second portion of the command to determine the actual processing operation to be performed for the processing pipeline. That is, after being processed by the graphics processor's command processing circuitry (job manager / command stream front end), the second portion of the command is then provided to the processing pipeline. This is preferably accomplished by adding the command to an appropriate command buffer for the processing pipeline, from which the command can be processed to determine the processing operation to be performed, for example, in the normal manner for operating such a command buffer.

[0053] The processing pipeline is then operable and configured to accordingly perform the processing operations indicated by the second portion of the command. As mentioned above, these processing operations are preferably (and typically) performed using the data values ​​indicated by the first portion of the command, and therefore these data values ​​are preferably also provided to the processing pipeline or otherwise made available to the processing pipeline along with (the second portion of) the command at this time.

[0054] For example, in some embodiments, only the second portion of the command may be provided to the processing pipeline. However, in other preferred embodiments, the second portion of the command may be, and preferably is, provided to the processing pipeline along with other information (such as information identifying the data values ​​to be used). For example, this can be accomplished by the command processing circuitry passing the complete command (i.e., including both the first and second portions of the command) to the processing pipeline.

[0055] Alternatively, and in some preferred embodiments, the second portion of the command can be passed to the processing pipeline along with some information indicating the first portion of the command or otherwise derived from the first portion of the command (rather than passing the first portion of the command itself (in its entirety). For example, the second portion of the command can be passed to the processing pipeline along with information indicating the data values ​​to be used (as indicated in the first portion) and / or information indicating association with the set of flags included in the first portion of the command, which information can be used by the processing pipeline. However, the processing pipeline will typically not need an operation code included in the first portion that identifies the command as a command for performing processing work.

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

[0057] Thus, the second portion of the command preferably indicates the actual processing operations to be performed on the processing pipeline, and these processing operations may then and preferably be performed accordingly using the data values ​​indicated by the first portion of the command. However, the first portion of the command indicates the set of data values ​​to be used, and allows these to be transferred to the processing pipeline, but the first portion of the command does not include any information indicating the specific processing operations to be performed using these data values ​​(other than indicating that the command is generally associated with a processing pipeline).

[0058] The command format according to the present invention thus allows the operation of the processing pipeline within the graphics processor to be decoupled from the operation of the command processing circuitry (job manager / command stream front end) of the graphics processor.

[0059] An effect and benefit of this command format is that it can then more easily update the processing pipeline, for example so that it can support new / additional processing operations, without this necessarily having any impact on the operation of the graphics processor command processing circuitry (job manager / command stream front end). For example, according to the present invention, any new / additional processing operations that are desired to be supported by the processing pipeline can then be appropriately indicated in the second part of the command so that the processing pipeline can interpret these appropriately, but this will have no impact on the processing of such commands by the command processing circuitry (job manager / command stream front end) as the corresponding first part of the command can and will still be processed in the same manner, i.e., independently of the specific processing operation indicated in the second part.

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

[0061] As mentioned above, the present invention relates to a specific novel format for executing commands for / using a processing pipeline. Therefore, these commands can be included in a set of commands for a graphics processor as needed to control the operation of the graphics processor's processing pipeline.

[0062] Thus, a given command set for a graphics processor may therefore include one or more, and typically a plurality of, such commands to perform corresponding one or more, and preferably a plurality of processing operations for the processing pipeline.

[0063] The processing operations to be performed on the processing pipeline may include any suitable and desired operations on the processing pipeline, including, for example, processing operations for setting state for the processing pipeline / configuring the processing pipeline and processing operations for performing processing using the processing pipeline (i.e., processing operations for executing the processing pipeline).

[0064] For example, a command set for a graphics processor may generally include one or more such commands for initializing or configuring a processing pipeline for one or more instances of execution of the processing pipeline, followed by one or more such commands for executing the processing pipeline.

[0065] According to the present invention, therefore, any and all of these such commands for performing processing operations for a processing pipeline may be encoded using the same basic command format (eg, as described above).

[0066] Thus, from the perspective of the command processing circuit (job manager / command stream front end), a sequence of commands associated with the operation of a processing pipeline may appear as a sequence of multiple identical (RENDER_OP) commands. The respective second parts of these commands will then encode the different processing operations to be performed on the processing pipeline, but these second parts will be "opaque" to the command processing circuit (job manager / command stream front end), and thus the operation of the command processing circuit (job manager / command stream front end) can be simplified in this way.

[0067] A given command set for a graphics processor may of course contain commands in other formats as desired (and typically will do so).

[0068] For example, a command sequence associated with a processing pipeline will preferably also include several commands (e.g., several (register) MOVE commands) for transferring data values ​​to an appropriate set of registers associated with the command stream processing circuitry (job manager / command stream front end) (this will be discussed further below).

[0069] In this regard, the set of data values ​​indicated in the first portion of a command according to the present invention is preferably indicated by reference to a set of registers associated with the command stream processing circuitry (job manager / command stream front end). That is, the first portion of the command preferably indicates which registers in the set of registers are to be read by the processing pipeline (i.e., which register values, if any, are to be read and used by the processing operations to be performed on the processing pipeline).

[0070] Therefore, prior to commands being used to configure and execute the processing pipeline, the relevant data values ​​can and preferably are transferred to the corresponding registers, and this is preferably done using appropriate (e.g. (register) MOVE) commands processed by the command processing circuitry (job manager / command stream front end).

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

[0072] For example, the first portion of the command format can indicate zero or more data values ​​to be used by the graphics processor when executing the processing pipeline. The first portion of the (RENDER_OP) command preferably includes one or more fields dedicated to this purpose (although these fields may indicate a zero value).

[0073] However, in another example, in addition to the above command format, there may be another type of command that is also a command for performing processing work for the processing pipeline, and which preferably includes a second part similar to the above (RENDER_OP) command, that is, a second part that includes processing pipeline command information indicating one or more specific processing operations to be performed for the processing pipeline, but the second part also directly encodes zero or more data values ​​to be used by the graphics processor when executing the processing pipeline (these other commands may be referred to as "RENDER_OP_IMMEDIATE" commands in this article).

[0074] These other (RENDER_OP_IMMEDIATE) commands may therefore include a first portion having another unique operation code (opcode) that is different from the operation code (opcode) used for the above-described (RENDER_OP) commands, but in contrast to the described (RENDER_OP) commands, the first portions of these commands do not (and cannot) indicate any data values ​​in their respective first portions (although data values ​​may instead be encoded directly into the second portion of the command - and this may, for example, be suitable for simpler operations in which less data needs to be transferred). Again, therefore, the processing pipeline command information can be (and is) made "opaque" to the command processing circuitry (job manager / command stream front end), with the same benefits mentioned above, and so these (RENDER_OP_IMMEDIATE) commands may be used in a similar manner to the above-described (RENDER_OP) commands.

[0075] These commands may therefore be particularly useful in conjunction with the (RENDER_OP) commands described above, as this may then provide increased flexibility with respect to the commands that may be used to perform processing operations for the processing pipeline, while still maintaining the benefits described above.

[0076] It is believed that the idea of ​​using a command that includes a "generic" operation code (opcode) that identifies that the command is a command for performing processing work for a processing pipeline to be used / interpreted by the command processing circuitry (job manager / command stream front end) and then includes one or more operation codes (opcodes) specific to the processing pipeline operation in a separate second part may be novel and advantageous in itself.

[0077] Therefore, according to another aspect of the present invention, a command for performing processing work for a processing pipeline may generally include: a first part having an operation code (opcode) identifying that the command is a command for performing processing work for a processing pipeline; and a second part indicating one or more specific processing operations to be performed for the processing pipeline, wherein the same operation code (opcode) is included in the first part for multiple different specific processing operations to be performed for the processing pipeline (the second part therefore preferably includes one or more additional operation codes (opcodes) that are specific to the processing pipeline and are accordingly used / interpreted by the processing pipeline but not used / interpreted by the command processing circuit (job manager / command stream front end)).

[0078] The above commands are therefore preferably used to control the graphics processor when performing processing work for the processing pipeline, and preferably these commands are used to control any and all processing work for the processing pipeline.

[0079] The commands provided to the graphics processor can, and typically will, include several other commands as needed, for example, to perform other processing tasks (i.e., processing tasks other than those directed to the processing pipeline). The other commands will therefore have their own corresponding operation codes (opcodes), which can be interpreted by the command processing circuitry (job manager / command stream front end), for example, to use the appropriate processing unit (circuitry) of the graphics processor as needed to perform the relevant processing operation.

[0080] In this regard, various arrangements will of course be possible.

[0081] As described above, these commands are preferably included into the command sets by the primary (host) processor (CPU) which is preparing one or more command sets for the graphics processor.

[0082] The command set is then received by appropriate command processing circuitry (command stream front end / job manager) of the graphics processor and processed thereby, for example as described above.The command set may generally take any suitable and desired form.

[0083] The invention also extends to a graphics processor and a method of operating the graphics processor itself.

[0084] Therefore, according to a further aspect of the present invention, there is provided a method of operating an image processor,

[0085] The graphics processor is operable and configured to perform processing work by executing a processing pipeline, and wherein the graphics processor includes command processing circuitry operable to process commands to perform the processing work,

[0086] The method comprises:

[0087] In response to the graphics processor receiving a command for executing a processing task for the processing pipeline, the command for executing the processing task for the processing pipeline includes:

[0088] (i) having a first portion having an operation code ("opcode") identifying that the command is a command for performing processing work for the processing pipeline, the first portion also including information indicating a set of zero or more data values ​​to be used for one or more processing operations for the processing pipeline; and

[0089] (ii) a second portion indicating one or more specific processing operations to be performed for the processing pipeline,

[0090] processing, by command processing circuitry of the graphics processor, the first portion of the command to determine that the command is a command for performing processing work for the processing pipeline;

[0091] providing (at least) the second portion of the command to the processing pipeline; and

[0092] The second portion of the command is used to determine one or more processing operations to be performed for the processing pipeline.

[0093] According to yet another aspect of the present invention, there is provided an image processor,

[0094] The graphics processor is operable and configured to perform processing work by executing a processing pipeline, and wherein the graphics processor includes command processing circuitry operable to process commands received from a primary processor to perform the processing work,

[0095] The graphics processor is further operable and configured to,

[0096] In response to receiving a command for executing a processing job for the processing pipeline, the command for executing the processing job for the processing pipeline includes:

[0097] (i) having a first portion having an operation code ("opcode") identifying that the command is a command for performing processing work for the processing pipeline, the first portion also including information indicating a set of zero or more data values ​​to be used for one or more processing operations for the processing pipeline; and

[0098] (ii) a second portion indicating one or more specific processing operations to be performed for the processing pipeline,

[0099] processing, by command processing circuitry of the graphics processor, the first portion of the command to determine that the command is a command for performing processing work for the processing pipeline;

[0100] providing (at least) the second portion of the command to the processing pipeline; and

[0101] The second portion of the command is used to determine one or more processing operations to be performed for the processing pipeline.

[0102] As will be appreciated by those skilled in the art, these additional aspects of the invention relating to the operation of the graphics processor itself may optionally include, and in one embodiment, do include, any one or more or all of the features of the invention described above.

[0103] Under the conditions of the specific requirements of the present invention, the first part and the second part of the (RENDER_OP) command according to the present invention may contain any other appropriate (data) fields as needed.

[0104] For example, as mentioned above, the first portion of the command includes a corresponding operation code (opcode) that identifies the command as being in this particular format.

[0105] The command processing circuitry (command stream front end / job manager) identifies the corresponding operation code (opcode) and then triggers specific processing of the command in the manner of the present invention.

[0106] The first portion of the command also includes information indicating zero or more data values ​​to be used by the graphics processor in executing the processing pipeline. The data values ​​may be indicated in any suitable and desired manner, but this is preferably accomplished by reference to a set of registers associated with the command processing circuitry (command stream front end / job manager), as previously mentioned.

[0107] These registers may be configured in any suitable and desired manner, such as in the normal manner for such registers.

[0108] Thus, the first portion of the command may indicate a specific register set containing data values ​​to be used by the graphics processor when executing the processing pipeline. Preferably, this is an indication of a group of contiguous registers. In this case, the first portion of the command may indicate this register set using an indication of a starting register and a register count (i.e., the number of registers in the sequence).

[0109] The first part of the command therefore preferably indicates, relative to a set of registers associated with the command processing circuitry (command stream front end / job manager), which data values ​​are to be used by the processing pipeline (e.g., so that these data values ​​can be read by / transferred into the processing pipeline as appropriate).

[0110] In this regard, various other arrangements would of course be possible.

[0111] The first part of the command may also, and preferably does, include various other control information (eg, flags) to be used by the command processing circuitry (job manager / command stream front end).

[0112] For example, in more traditional graphics processor operation, command processing circuitry (a job manager / command stream front end) may perform job tracking / control based on the processing operations to be performed.

[0113] However, according to the present invention, because the processing pipeline command information indicating the processing operations to be performed for the processing pipeline is "opaque" to the command processing circuitry (job manager / command stream front end), this means that a different tracking / control mechanism may be required.

[0114] Therefore, in a preferred embodiment, one or more flags may be included in a first portion of a command, which may be used by command processing circuitry (job manager / command stream front end) to perform one or more job control / tracking operations.

[0115] For example, a corresponding flag may be included in the first part of a given command, the corresponding flag being used to indicate when a processing operation specified by the processing pipeline command information included in the second part of the given command requires the execution of a shader program. This flag may therefore be used (i.e. set) as appropriate for scheduling purposes, for example to try to ensure that a shader core is available to execute those shader programs, but this is done without the command processing circuitry (job manager / command stream front end) having any explicit indication of which processing operations are to be performed or, therefore, which shader programs may need to be executed.

[0116] As another example, a corresponding flag may be included in the first part of a given command, indicating that instruction "tracing" should be performed. If such a flag is present and set, this may therefore trigger an instruction tracing operation (which may then be performed in any suitable and desired manner, such as as usual).

[0117] For example, another flag may be used to indicate whether the command processing circuitry should be signaled when the processing operation indicated in the second part of the command has been completed.

[0118] Thus, in an embodiment, the first portion of the command includes additional job control information that is used by the command processing circuitry to control the scheduling of processing into the processing pipeline.

[0119] For example, such additional job control information included in the first portion of the command may include one or more flags for indicating one or more of: (i) whether the processing operation indicated in the second portion of the command requires execution of a shader program; (ii) whether an instruction trace operation should be performed; and / or (iii) whether the overall command processing circuitry (job manager / command stream front end) of the graphics processor should be signaled when the processing operation indicated in the second portion of the command has been completed.

[0120] In a preferred embodiment, the command processing circuitry is further operable to track the completion status of processing jobs being executed by the processing pipeline.The first part of the command may therefore, and preferably does, also include information for performing such tracking.

[0121] For example, and in particular, the command processing circuitry may (and preferably is) operable to track when a particular rendering pass has completed. In this regard, in the context of graphics processing, it will be understood that fragment shading should generally not be performed for any draw call within a particular rendering pass until geometry processing for the entire rendering pass has completed. The completion status of the rendering pass may therefore be tracked, for example, using a suitable scoreboard or reference counter maintained by the command processing circuitry (job manager / command stream front end), and the first portion of the command may accordingly include a flag for controlling the incrementing and / or decrementing of the scoreboard or reference counter as required.

[0122] Thus, when such a scoreboard is provided, a scoreboard increment flag may be used to increment the corresponding scoreboard entry. A corresponding scoreboard decrement flag may be used to decrement the corresponding scoreboard entry (although this should generally not be done before the associated operation has completed).

[0123] For example, a scoreboard decrement flag may be appropriately set within the first portion of the command corresponding to the last processing operation to be performed for the rendering traversal. That is, the first portion of the command may include an appropriate flag to indicate that the processing operation indicated in the second portion of the command is the last processing operation to be performed for the rendering traversal. Upon receipt of such a command, where such a flag is set to indicate that the processing operation indicated in the second portion of the command is the last processing operation to be performed for the rendering traversal, this may then trigger the appropriate decrementing of the corresponding scoreboard entry to signal that the rendering traversal has concluded. However, this is preferably not performed until the last processing operation has completed.

[0124] That is, when the first part of the command indicates that the processing operation indicated in the second part of the command is the last processing operation to be performed for the rendering pass, after the processing pipeline has finished processing the command: this is preferably signaled to the command processing circuitry to indicate the end of the rendering pass (i.e. the scoreboard may be decremented).

[0125] In this regard, various other examples may be possible.

[0126] It should also be understood that a particular command in accordance with the format of the present invention may be associated with multiple underlying commands, and as discussed above, this may not be "transparent" to the command processing circuitry (job manager / command stream front end). Thus, there may not be a one-to-one correspondence between commands in accordance with the format of the present invention and the commands that are then included in the command buffer for the processing pipeline.

[0127] Therefore, a credit-based system is preferably used to avoid overfilling any command buffer. For example, in a preferred embodiment, the command processing circuitry is operable to maintain a corresponding "credit" counter. When a processing pipeline is first activated, the processing pipeline may therefore pass a number of credits corresponding to the size of the command buffer for the processing pipeline to the command processing circuitry so that the credit counter can be set accordingly. The credit counter may therefore be initially set based on the size of the command buffer for the processing pipeline, but this is preferably done by the processing pipeline issuing an appropriate number of credits, and so is preferably done without the command processing circuitry needing to know the actual size of the command buffer (again, this helps to further decouple the processing pipeline operation from the command processing circuitry (job manager / command stream front end) operation).

[0128] As the command processing circuitry issues commands to the processing pipeline, the credit counter may be decremented accordingly. At some point, the credit counter may be decremented to zero, at which point the command processing circuitry should stop issuing new commands to the processing pipeline (because the command processing circuitry has run out of credits and therefore, based on its tracking, will determine that the command buffer for the processing pipeline is full).

[0129] The processing pipeline should therefore return credits to the command processing circuitry to ensure sustained throughput as commands are processed from the command buffer for the processing pipeline. To facilitate this, the processing pipeline can, and preferably does, signal the command processing circuitry when it has space in its command buffer, allowing the credit counter to be incremented appropriately. To reduce internal bandwidth, this is not done every time a command is processed from the command buffer, but rather can be done periodically or in response to a threshold amount of space being available in the command buffer, for example. Thus, the processing pipeline can be operated and configured to return batches of credits to the command processing circuitry. In this regard, various arrangements are possible.

[0130] Thus, in an embodiment, the command processing circuitry is operable to track how many commands it has issued to the processing pipeline and to stop issuing new commands to the processing pipeline when the command processing circuitry determines, based on its tracking, that the command buffer for the processing pipeline is full. This tracking is preferably performed using a credit-based system as described above.

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

[0132] After being processed by the command processing circuitry (command stream front end / job manager), the command may then be provided to the processing pipeline. This is preferably accomplished by adding the command to the command buffer of the processing pipeline (e.g., as long as there is available space (i.e., there are sufficient credits to do so)). Any other information included in the first portion of the command, such as data values ​​(register contents), flags, etc., may also be simultaneously provided to the processing pipeline or otherwise made available to the processing pipeline as needed.

[0133] The command may then be processed from such a command buffer, for example by a suitable controller for a processing pipeline, to perform the desired processing operation as indicated by the second portion of the command.

[0134] The second part of the command may therefore, and preferably does, include a suitable identifier for the particular processing operation to be performed by the processing pipeline, which identifier may be interpreted accordingly by the processing pipeline to determine the processing operation to be performed.

[0135] This can be, and preferably is, done using an appropriate set of operation codes (opcodes) that identify specific processing operations that can be performed on the processing pipeline (the operation codes (opcodes) therefore correspond to a further set of operation codes (opcodes) that are specific to and supported by the processing pipeline (but the further operation codes (opcodes) therefore need not be, and are typically not, supported by the command stream processing circuitry (command stream front end / job manager), as discussed above)).

[0136] Thus, the processing pipeline may be, and preferably is, operable to use and support a different set of operation codes (opcodes) than that used and supported by the command stream processing circuitry (command stream front end / job manager).

[0137] The processing operation indicated by the second part of a given command may then, and preferably will, use the data value indicated as being used by the corresponding first part of that (same) command.

[0138] For example, a command set for controlling a graphics processor to perform processing work using a processing pipeline may include an initial command for indicating the start of a new rendering pass.

[0139] According to the present invention, this initial command may therefore be encoded as a first (RENDER_OP) command having the format of the present invention, the second part of which indicates to the processing pipeline that this is the start of a new rendering pass.

[0140] (In this case, the first part of the command may only need to indicate the operation code (opcode) of this command, as there may be no data values ​​to be used at this time (and so the RENDER_OP_IMMEDIATE command can also / alternatively be used for this initial command, as mentioned above)).

[0141] The initial command for indicating the start of a new rendering pass (i.e., the first (RENDER_OP) command) may therefore, and preferably, be followed in a set of commands by a suitable set of commands to transfer the relevant data for the new rendering pass into the graphics processor (e.g., and preferably, into a set of registers of the command processing circuitry (command stream front end / job manager), as described above) (the commands may therefore, for example, and preferably do include conventional MOVE commands that can be processed by the command processing circuitry (command stream front end / job manager) in the normal manner for such MOVE commands).

[0142] Once this is done, the command set can, and preferably (typically) will, include one or more further commands to set some configuration state for the processing pipeline and transfer that configuration state to appropriate local storage associated with the processing pipeline.

[0143] According to the present invention, therefore, these further commands may also be encoded as further (RENDER_OP) commands having the same format of the present invention, but with the second part of these commands indicating to the processing pipeline that these further commands will set a certain configuration state for the processing pipeline.

[0144] Once the configuration state has been set and the relevant configuration data values ​​have been loaded into the (local) storage associated with the processing pipeline, another command may then be included to trigger execution of the processing pipeline, for example for an individual draw call. Again, in accordance with the present invention, this command may be encoded as another (RENDER_OP) command having the (same) format of the present invention, but with the second portion of the command indicating to the processing pipeline that this is a command for triggering execution of the processing pipeline.

[0145] Further commands may then be included as needed to set configuration state for the processing pipeline and trigger execution of the processing pipeline, such as for further draw calls within the same rendering pass (these are preferably all encoded as (RENDER_OP) commands having the (same) format of the present invention).

[0146] Finally, a command may be included to indicate the end of the rendering pass, which is also preferably encoded as another (RENDER_OP) command having the (same) format of the present invention. A similar sequence of commands may then be included for the next rendering pass as needed, and so on.

[0147] Thus, the different types of processing operations that may be encoded using a given (RENDER_OP) command according to the present invention and that may be indicated in the second portion of the command may, for example, include one or more processing operations for: (i) indicating the start of a new rendering pass; (ii) setting a local processing pipeline configuration state; (iii) triggering execution of the processing pipeline configuration; and (iv) indicating the end of a rendering pass, and these are the actual processing operations indicated to and performed on the processing pipeline. However, from the perspective of the command processing circuitry (job manager / command stream front end), these different processing operations are all encoded in the same way, i.e., the command processing circuitry (job manager / command stream front end) sees a corresponding sequence of the same (RENDER_OP) commands all having the same (same) basic format according to the present invention.

[0148] Thus, in an embodiment, a graphics processor may receive a command sequence for performing processing work for a processing pipeline, wherein a plurality of different ones of the commands in the command sequence for performing processing work using the processing pipeline include, in their respective first portions, the same operation code identifying that the command is a command for performing processing work using the processing pipeline, but wherein respective second portions of the commands indicate different specific processing operations to be performed for the processing pipeline.

[0149] Various other information may be included in the second portion of the command as desired. For example, in general, the second portion of the command may be used to provide any suitable and desired information to the graphics processor.

[0150] For example, even when the first portion of a command can indicate data values ​​to be used by the graphics processor in executing the processing pipeline (e.g., the command format includes appropriate fields for storing this information in the first portion), as is the case with (RENDER_OP) commands according to the present invention, it may still be desirable in some cases to also encode some data values ​​directly into the second portion (e.g., as is done for the other (RENDER_OP_IMMEDIATE) commands mentioned above), and so this may be done in embodiments.

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

[0152] The data processing system / graphics processor may be operated and configured in any suitable and desired manner subject to the particular requirements of the present invention.

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

[0154] As will be appreciated 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 processing stages and circuits that a graphics processor and (graphics) processing pipeline may (typically) include.

[0155] Thus, for example, the graphics processor may execute a graphics processing pipeline that preferably includes 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 a tile-based graphics processor and so also includes and executes one or more tiling / blocking stages as appropriate.

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

[0157] 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.

[0158] 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 (graphics) processing pipeline) of the present invention can be used to perform both graphics processing work (such as generating frames for display, etc.) or to perform general (non-graphics) work, as needed.

[0159] 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.

[0160] 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 can be implemented as needed in hardware or software herein. Therefore, 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, circuit systems, circuits, processing logic components, microprocessor arrangements, etc., which can be configured to perform various functions, etc., such as appropriate dedicated hardware elements (processing circuits / circuitry) and / or programmable hardware elements (processing circuits / circuitry), which can be programmed to operate in a desired manner.

[0161] 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 / circuits, etc., if desired.

[0162] Furthermore, unless otherwise indicated, any one or more or all of the pipeline stages of the present invention may be embodied as processing 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 separate 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.

[0163] 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.

[0164] It will also be understood by those skilled in the art that all described embodiments of the present invention may optionally include any one, more, or all of the features described herein in a single embodiment.

[0165] 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.

[0166] 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.

[0167] 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.

[0168] 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.

[0169] 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.

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

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

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

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

[0174] Figure 4 schematically illustrates a novel command format according to an embodiment;

[0175] Figure 5 Schematically shows the use of Figure 4 A sample command set for a graphics processor in the command format of

[0176] Figure 6A and Figure 6B schematically illustrates scoreboard operations that may be used in accordance with an embodiment;

[0177] Figure 7A and Figure 7B schematically illustrates a credit system that may be used in accordance with an embodiment;

[0178] Figure 8 This is an example based on Figure 4 A flowchart of command processing in the command format;

[0179] Figure 9 Schematically illustrates features for preparing a command set for a graphics processor;

[0180] Figure 10schematically illustrates another novel command format that may be used in accordance with an embodiment; and

[0181] Figure 11 This is an example based on Figure 10 Flowchart of how to process commands in the command format.

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

[0183] 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.

[0184] 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.

[0185] 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.

[0186] 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.

[0187] Figure 2 As will be appreciated by those skilled in the art, there may be multiple graphics processors and processing pipelines. Figure 2 Other elements not shown in the example. 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 shown schematically as individual stages, they may also share important hardware circuits. It should also be understood that Figure 2Each of the stages, elements, units, etc. of the illustrated processing pipeline (unless otherwise indicated) may be implemented as desired and will accordingly include, for example, appropriate circuitry, circuits, and / or processing logic components, etc. for performing the required operations and functions.

[0188] 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 preferably by storing it in a memory 6, the set of scene data for example and in particular comprising 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 by the graphics processor 2 from the memory.

[0189] 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.

[0190] 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 that will then be required for rendered output. This geometry processing 12 may comprise any suitable and desired geometry processing that may be performed as part of a graphics processing pipeline.

[0191] In the present embodiment, this geometry processing includes performing vertex processing (vertex shading) on ​​at least the attributes of the vertices to be used by the primitives for the rendered output being generated. In particular, appropriate vertex position shading is performed to transform the positions for the vertices from, for example, the "model" space in which they were originally defined, to, for example, the "screen" space in which the output is being generated. In a preferred embodiment, vertex shading also includes generating and / or processing other non-positional attributes of the vertices (variation / variation shading). As desired, some or all of the variation shading will also be able to be deferred from geometry processing and, for example, be triggered instead at the tile or render level.

[0192] As well as appropriate 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. This geometry shading may also generate and / or process attributes for vertices, and / or it may also process and generate attributes for primitives.

[0193] Once the desired geometric processing has been performed, in this embodiment, as Figure 2 As shown, there is then a blocking / tiling 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.)

[0194] The tiling 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, the tiling process 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, the tiling process may generate other data structures, such as a hierarchy of bounding boxes, which can then be used at the rendering / fragment pipeline stage to identify those primitives that need to be processed for the corresponding tile.

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

[0196] As part of geometry processing and / or blocking / tiling 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 assembled into primitives for processing when generating render output.

[0197] This primitive assembly can be performed as part of geometry processing and at the appropriate level of geometry processing and / or as part of blocking / tiling processing, as desired. There can also be two (or more) "primitive assembly" operations, as 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 level that provides the assembled primitive sequence for the blocking / tiling level.

[0198] Once the blocking / tiling process has generated the necessary data structures for identifying the primitives to be processed for a corresponding tile of rendered output, the primitives may then be subjected to 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 tiling / blocking process 13 to identify those primitives that need to be processed for the corresponding tile.

[0199] Rendering / fragment processing may include any suitable and desired rendering and fragment processing operations that may be performed. Thus, rendering / fragment processing may include, for example, first rasterizing primitives to be processed for a tile into fragments, and then processing those fragments accordingly (e.g., and preferably, 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 for corresponding sets of one or more sample positions representing the output being generated. Hybrid ray tracing operations will also be possible, as desired.

[0200] The output of the rendering / fragment processing (rendered fragments) is written to a tile buffer (not shown). Once processing of the tile in question has been completed, the tile is written to an 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.

[0201] 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.

[0202] Figure 3 Shows the executable Figure 2 The illustrated form of a graphics processing pipeline is an embodiment of a graphics processing unit (GPU) 2 operable in the manner of the present invention.

[0203] like Figure 3 As shown, 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 that is operable to execute program instructions to perform processing operations.

[0204] Each execution core 33 has appropriate access to the memory system of the data processing system of which graphics processor 2 is a part.

[0205] 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, each shader core 32 includes appropriate compute endpoints 37 and fragment endpoints 38, which serve as control interfaces for performing compute shading and fragment processing, respectively, and will, for example and preferably, trigger the execution core 33 to perform appropriate compute shading or fragment shading tasks as needed.

[0206] 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, which 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.

[0207] 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.

[0208] In this embodiment, if Figure 3 As shown, geometry processing is performed by a geometry grouping pipeline 42 of graphics processor 2. This geometry grouping 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 geometry grouping pipeline 42).

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

[0210] like Figure 3 As shown, the geometry grouping pipeline 42 has an appropriate interface 47 to the compute scheduler 40 of the job control unit 39 via which it can control and trigger the execution of appropriate geometry shading operations by the shader cores 32 .

[0211] 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 .

[0212] 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, each shader core 32 also includes a distributed tiling 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.

[0213] In this embodiment, the distributed tiling 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).

[0214] The distributed tiling 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).

[0215] The distributed tile core 49 may operate in any suitable and desired manner for this purpose.

[0216] like Figure 3 As shown, distributed tile 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 the input packetizer as part of the operation of input packetizer 43).

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

[0218] As will be appreciated 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 considered to be corresponding data elements (e.g., position or variance in the case of a vertex) for the corresponding work item (e.g., vertex), respectively), which data will then be used, for example, by blocking / tiling and rendering / fragment processing at later stages of the graphics processing pipeline.

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

[0220] Thus, in this embodiment, the geometry grouping pipeline 42 will generate groups of work items 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 tile core 49. Accordingly, the distributed tile 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.

[0221] The present embodiment specifically relates to submitting processing tasks from a central processing unit (CPU) 1 to a graphics processing unit (GPU) 2 .

[0222] As will be described below, this is accomplished in this embodiment by the central processing unit (CPU) 1 issuing appropriate commands to the graphics processing unit (GPU) 2. Figure 3 , these commands are issued to the job control unit 39, which then processes the commands accordingly to identify the processing jobs to be performed and distributes these jobs to the appropriate processing units of the graphics processing unit (GPU) 2. Therefore, when a command related to the geometry grouping pipeline 42 is received, this is first processed by the job control unit 39 to identify that the command is related to the geometry grouping pipeline 42, and the geometry iterator 48 of the job control unit 39 then schedules and distributes the appropriate geometry processing jobs and tasks to the geometry grouping pipeline 42 accordingly.

[0223] Figure 4 An example of a novel command format for commands associated with the geometry grouping pipeline 42 according to the present embodiment is shown, which commands will be referred to herein as "RENDER_OP" commands.

[0224] like Figure 4 As shown, the RENDER_OP command includes a "job control" portion 401 and a "pipeline command" portion 402. Figure 4 As shown, and as will be further explained below, the "Job Control" portion 401 and the "Pipeline Commands" portion 402 are separate from one another, and this allows the information contained within each portion to be processed separately and processed / interpreted by different processing units as required.

[0225] For example, Figure 4 As shown, the job control portion 401 includes an operation portion that includes a corresponding (unique) operation code 403 that identifies the command as a RENDER_OP command. The operation portion also includes information about any data values ​​that may need to be transferred to the geometry grouping pipeline 42. In particular, Figure 4 As shown, this information is identified with reference to a contiguous set of registers 390 residing in the job control unit 39, and the operation portion thus indicates the number of registers to be transferred 404 and the starting register 405. The operation portion thus identifies that the command is a RENDER_OP command that should be passed to the geometry grouping pipeline 42, and also identifies the data (which may be zero data) that may need to be transferred to the geometry grouping pipeline 42 with reference to the appropriate registers 309.

[0226] The opcode 403 identifying the command as a RENDER_OP command may therefore be processed by the job control unit 39 to identify that the command should be passed to the geometry grouping pipeline 42, but does not specify any particular processing operation to be performed for the geometry grouping pipeline 42, but is instead generic to multiple different processing operations.

[0227] like Figure 4 As shown, the specific opcodes for the processing operations to be performed by the geometry grouping pipeline 42 are therefore included in the pipeline command portion 402. The pipeline command portion 402 is opaque to the job control unit 39, such that the job control unit 39 does not process / use any information in the pipeline command portion 402. Instead, the job control unit 39 simply passes the pipeline command portion 402 to the geometry grouping pipeline 42 (e.g., via its appropriate job control network interface 420 into a command buffer 422 for the geometry grouping pipeline 42), and the information in the pipeline command portion 402 is then processed / used by the geometry grouping pipeline 42 to determine the specific processing operations to be performed.

[0228] Figure 5 An example command set for a graphics processor as seen by job control unit 39 is schematically shown, according to an embodiment.

[0229] In this example, a first command is included to indicate the start of a rendering pass (RENDERPASS_BEGIN). This is followed by a sequence of MOVE commands to load the relevant data for that rendering pass into the corresponding registers 390 of the job control unit 39. This is followed by a sequence of four (GSV_SET) commands to transfer data from the registers 390 to local storage associated with the geometry grouping pipeline 42, followed by a command to execute the geometry grouping pipeline 42 for the first draw call (RUN_PIPELINE command). This is followed by a further sequence of commands to set state and execute the geometry grouping pipeline 42 for the second and third draw calls, and a final command to indicate the end of the rendering pass (RENDERPASS_END).

[0230] Therefore, if Figure 5 As shown on the right hand side of FIG, these RENDER_OP commands will perform a series of different processing operations on the geometry grouping pipeline 42. However, as Figure 5 As shown on the left hand side of , the job control unit 39 sees only a series of RENDER_OP commands (and various MOVE commands for transferring data between registers 390), and so from the perspective of the job control unit 39, these commands can all be (and are) processed in the same way.

[0231] The job control unit 39 therefore does not need to support separate operations for each different processing operation, e.g. does not need to determine whether these operations use shaders etc., because the specific processing operations are abstracted from the job control unit 39. However, this means that the RENDER_OP command may need to indicate such information directly to the job control unit 39. To facilitate this, as Figure 4 As shown, the operations section also contains several flags that can be used by the job control unit 39 to perform its various job tracking / scheduling operations.

[0232] For example, Figure 4 As shown, a "uses_shader" flag 408 may be set to indicate whether the processing operation indicated in the pipeline command portion 402 will run a shader program. This information may then be used by the job control unit 39 for scheduling purposes, such as to avoid allocating computer jobs that would prevent the desired shader program from running.

[0233] Similarly, a "trace" flag 409 may be set to indicate to the job control unit 39 whether instruction tracing should be performed.

[0234] In this embodiment, corresponding "scoreboard_increment" 406 and "scoreboard_decrement" 407 flags are also included. These flags can then be used to increment / decrement the scoreboard 392 managed by the job control unit 39 in order to track the completion status of the processing job (e.g., for a rendering traversal). For example, fragment shading should generally not be run on any draw call until geometry processing has completed for the entire rendering traversal, and this can be tracked using the scoreboard 392 in this embodiment. However, again, because the job control unit 39 is unaware of the actual underlying processing operation indicated in the command pipeline portion 402 of the RENDER_OP command, the job control unit 39 cannot see when the RENDERPASS_END command is issued. Therefore, this is communicated to the job control unit 39 using the scoreboard 392.

[0235] The scoreboard 392 can therefore be (and is) incremented whenever the job control unit 39 sees a RENDER_OP command with the scoreboard_increment flag 406 set.

[0236] On the other hand, when a RENDER_OP command is set with the scoreboard_decrement flag 407, the job control unit 39 should not (and does not) immediately decrement the scoreboard 392, but instead waits until the operation has been processed by the final stage of the geometry grouping pipeline 42, at which point the job control unit 39 is notified of this and the scoreboard 392 is decremented accordingly.

[0237] This is depicted in the diagram showing the scoreboard decrement signal 4070 being passed from the last shader stage 46 back to the job control unit 39. Figure 6A middle. Figure 6B is a flow chart showing this operation. Figure 6B As shown, in response to receiving the scoreboard decrement signal 4070 (step 600 —yes), the job control unit 39 is operable to decrement its scoreboard 392 (step 601 ).

[0238] Another effect of extracting the processing operations from the commands in the manner described above is that the job control unit 39 may see only a single RENDER_OP command, but this single RENDER_OP command may cause multiple commands to be added to the command buffer 422 for the geometry grouping pipeline 42. For example, as mentioned above, the job control portion 401 of the RENDER_OP command may indicate (using a corresponding flag 404) the number of registers to be transferred to the geometry grouping pipeline 42. So, a RENDER_OP command that instructs the job control unit 39 to transfer four registers to the geometry grouping pipeline 42 then effectively has five commands to be passed to the geometry grouping pipeline 42 (i.e., the actual commands in the command set for the geometry grouping pipeline 42 indicated within the corresponding command pipeline portion 402 of the RENDER_OP command, as well as the four "data" commands).

[0239] There is therefore a risk that the job control unit 39 may issue what it sees as a single RENDER_OP command to the geometry grouping pipeline 42, but this single RENDER_OP command causes multiple commands to be added to the command buffer 422 for the geometry grouping pipeline 42, which, if not managed appropriately, can lead to overfilling of the command buffer 422. To avoid this, a credit scheme is preferably used to avoid overfilling the command buffer 422.

[0240] Thus, when the geometry grouping pipeline 42 is activated (or, e.g., reactivated, e.g., after it has previously been suspended), the geometry grouping pipeline 42 issues to the job control unit 39 1 credit equal to the number of spaces in its command buffer 422 for commands, and the credit counter 394 is updated accordingly to include the corresponding number of credits. As the job control unit 39 issues commands / data to the geometry grouping pipeline 42, the job control unit 39 decrements its version of the credit counter 394 appropriately (and when the credit counter 394 maintained by the job control unit 39 reaches zero, the job control unit 39 stops passing commands (as, from the perspective of the tracing performed by the job control unit 39, the job control unit 39 will determine that the command buffer 422 must then be full)).

[0241] As commands are drained from the command buffer 422, the command buffer 422 of the geometry grouping pipeline 42 should and does therefore pass credits back to the job control unit 39. However, rather than passing back individual credits, the command buffer 422 preferably batches the credits to be returned and returns them one at a time. This can be done, for example, once a certain threshold number of credits are available, or periodically, for example. Various arrangements are possible in this regard.

[0242] exist Figure 7A and Figure 7B This credit scheme is depicted in . For example, Figure 7B As shown, in response to the job control unit 39 receiving a batch of credits from the geometry grouping pipeline 42 (step 700—yes), the credit counter 394 is incremented by a corresponding amount. Otherwise, if the credit counter 394 reaches zero, the job control unit 39 must suspend issuing commands to the geometry grouping pipeline 42 until further credits are received.

[0243] Figure 8 2 is a flowchart illustrating the overall processing of the RENDER OP command by the job control unit 39.

[0244] Therefore, in response to the job control unit 39 receiving the RENDER OP command (step 800 —YES), it checks whether the scoreboard_increment flag 406 is set, and if so (step 801 —YES), the scoreboard 392 is incremented (step 802).

[0245] If the job control unit 39 does not have sufficient credit available (step 803 - No), the job control unit 39 stops until appropriate credit has been returned.

[0246] As long as the job control unit 39 has enough credits available (step 803—yes), it then checks whether the uses_shader flag 408 is set. If so (step 805—yes), the appropriate shader slot is reserved (step 806).

[0247] Once these checks have been completed, the pipeline command portion 402 of the RENDER OP command is then issued to the geometry packet pipeline 42 along with an indication of any registers and / or flags to be used / transferred to the geometry packet pipeline 42 (step 807).

[0248] Various other arrangements are possible.

[0249] It will therefore be appreciated from the above that the RENDER_OP command advantageously allows the actual pipeline command information, and hence the operation of the geometry grouping pipeline 42, to be decoupled from the operation of the job control unit 39, as a single (identical) RENDER_OP command format can be used to encode multiple different pipeline commands.

[0250] Figure 9 In this regard, the corresponding preparation of a suitable set of commands by the central processing unit (CPU) 1 for submission to the graphics processing unit (GPU) 2 is illustrated. Figure 9 As shown, aliases can be used so that software can be added to different operations (such as Figure 9 When preparing a set of commands for output, these operations are all output as the same RENDER OP command, with the compiler filling in the corresponding pipeline command sections 402 and flags appropriately for the different operations to be performed.

[0251] As described above, the operation portion of the RENDER_OP command according to this embodiment includes various flags and information indicating the registers to be transferred. In some cases, it may be possible and desirable to use the pipeline command portion 402 to transfer data directly to the geometry grouping pipeline 42. This can be accomplished by setting the relevant status / flags in the operation portion of the RENDER_OP command to zero / default values. In an embodiment, although another command format may be used in such cases, such as Figure 10 As shown, but this will be referred to as the RENDER_OP_IMMEDIATE command in this document.

[0252] like Figure 10 As shown, the job control portion 1001 of the RENDER_OP_IMMEDIATE command contains only an opcode identifying the command as a RENDER_OP_IMMEDIATE command. Any other information, including the actual processing operations to be performed by the geometry grouping pipeline 42 and any data values ​​to be directly transferred for use in performing those operations, is contained in the pipeline command portion 1002 and is therefore not transparent to the job control unit 39.

[0253] Figure 11 FIG. 4 is a flowchart showing the corresponding processing of such RENDER_OP_IMMEDIATE command in the job control unit 39. Figure 11 As shown, in response to the job control unit 39 receiving the RENDER_OP_IMMEDIATE command (step 1100—yes), the pipeline command portion 1002 of the RENDER_OP_IMMEDIATE command is immediately passed to the geometry grouping pipeline 42 (step 1101), i.e., without further processing by the job control unit 39.

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

[0255] The present invention, at least in its preferred embodiment, thus provides a graphics processor with a novel command format for executing processing for a graphics processing pipeline.

[0256] 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 of operating a graphics processor, The graphics processor is operable and configured to perform processing work by executing a processing pipeline, and wherein the graphics processor includes command processing circuitry operable to process commands to perform the processing work, The method comprises: In response to the graphics processor receiving a command for executing a processing task for the processing pipeline, the command for executing the processing task for the processing pipeline includes: (i) having a first portion of an operation code identifying that the command is a command for performing processing work for the processing pipeline, the first portion also including information indicating a set of zero or more data values ​​to be used for one or more processing operations for the processing pipeline; and (ii) a second portion indicating one or more specific processing operations to be performed for the processing pipeline: processing, by command stream processing circuitry of the graphics processor, the first portion of the command to determine that the command is a command for performing processing work for the processing pipeline; providing the second portion of the command to the processing pipeline; and The second portion of the command is used to determine one or more processing operations to be performed for the processing pipeline.

2. A method according to claim 1, wherein the second portion of the command is provided to the processing pipeline together with at least an indication of any data values ​​indicated by the first portion of the command to be used for the one or more specific processing operations indicated by the second portion of the command.

3. The method of claim 1 or 2, wherein the first portion of the command includes additional job control information, the command processing circuit using the additional job control information included in the first portion of the command to control scheduling of processing to the processing pipeline.

4. A method according to claim 3, wherein the additional job control information included in the first part of the command includes one or more flags for indicating one or more of the following: (i) whether the processing operation indicated in the second part of the command requires execution of a shader program; (ii) whether an instruction tracking operation should be performed; and / or (iii) whether a signal should be sent to the command processing circuit when the processing operation indicated in the second part of the command has been completed.

5. The method of claim 1 , wherein the command processing circuitry is operable to track the completion status of processing jobs being executed by the processing pipeline, and wherein the first portion of the command further includes information for performing such tracking.

6. The method of claim 5 , wherein the command processing circuitry is operable to track when a rendering pass ends, and wherein the first portion of the command is capable of indicating that the processing operation indicated in the second portion of the command is a last processing operation to be performed for a rendering pass.

7. The method of claim 6, wherein when the first portion of the command indicates that the processing operation indicated in the second portion of the command is a last processing operation to be performed for a rendering traversal, the method comprises: After the processing pipeline has finished processing the command: signaling this to the command processing circuitry to indicate the end of the rendering pass.

8. The method of claim 1 , wherein the command processing circuitry is operable to track how many commands it has issued to the processing pipeline and to stop issuing new commands to the processing pipeline when the command processing circuitry determines, based on its tracking, that a command buffer for the processing pipeline is full.

9. The method of claim 1 , wherein the one or more specific processing operations to be performed for the processing pipeline indicated in the second portion of the command include one or more processing operations for: (i) indicating the start of a new rendering pass; (ii) setting a local processing pipeline configuration state; (iii) triggering execution of the processing pipeline configuration; and (iv) indicating the end of a rendering pass.

10. The method of claim 1 , comprising receiving, by the graphics processor, a command sequence for performing processing work for the processing pipeline, wherein a plurality of different ones of the commands in the command sequence for performing processing work using the processing pipeline include, in respective first portions thereof, identical operation codes identifying the commands as commands for performing processing work using the processing pipeline, but wherein respective second portions of the commands indicate different specific processing operations to be performed for the processing pipeline.

11. A method of operating a data processing system, the data processing system comprising: Main processor; as well as a graphics processor operable to perform processing work for an application executing on a host processor, wherein the graphics processor is operable and configured to perform the processing work by executing a processing pipeline, and wherein the graphics processor includes command processing circuitry operable to process commands received from the primary processor to perform the processing work, The method comprises: In response to a request from an application executing on the host processor for processing to be performed by the graphics processor, preparing on the primary host processor a set of commands including commands for performing processing work for the processing pipeline, the commands for performing processing work for the processing pipeline including: (i) having a first portion of an operation code identifying that the command is a command for performing processing work for the processing pipeline, the first portion also including information indicating a set of zero or more data values ​​to be used for one or more processing operations for the processing pipeline; and (ii) a second portion indicating one or more specific processing operations to be performed for the processing pipeline, The method further comprises: In response to receiving the command for executing the processing work for the processing pipeline: processing, by command processing circuitry of the graphics processor, the first portion of the command to determine that the command is a command for performing processing work for the processing pipeline; providing the second portion of the command to the processing pipeline; and The second portion of the command is used to determine one or more processing operations to be performed for the processing pipeline.

12. A graphics processor operable and configured to perform processing work by executing a processing pipeline, wherein the graphics processor includes command processing circuitry operable to process commands received from a main processor to perform the processing work, the graphics processor further operable and configured to, In response to receiving a command for executing a processing job for the processing pipeline, the command for executing the processing job for the processing pipeline includes: (i) having a first portion of an operation code identifying that the command is a command for performing processing work for the processing pipeline, the first portion also including information indicating a set of zero or more data values ​​to be used for one or more processing operations for the processing pipeline; as well as (ii) a second portion indicating one or more specific processing operations to be performed for the processing pipeline, processing, by command processing circuitry of the graphics processor, the first portion of the command to determine that the command is a command for performing processing work for the processing pipeline; providing the second portion of the command to the processing pipeline; and The second portion of the command is used to determine one or more processing operations to be performed for the processing pipeline.

13. The graphics processor of claim 12 , wherein the second portion of the command is provided to the processing pipeline along with at least an indication of any data values ​​indicated by the first portion of the command to be used for the one or more specific processing operations indicated by the second portion of the command.

14. The graphics processor of claim 12 or 13, wherein the first portion of the command includes additional job control information, the command processing circuit being operable and configured to control scheduling of processing to the processing pipeline using the additional job control information included in the first portion of the command.

15. The graphics processor of claim 14 , wherein the additional job control information included in the first portion of the command includes one or more flags for indicating one or more of: (i) whether the processing operation indicated in the second portion of the command requires execution of a shader program; (ii) whether an instruction trace operation should be performed; and / or (iii) whether a notification should be signaled to the command processing circuitry when the processing operation indicated in the second portion of the command has completed.

16. The graphics processor of claim 12, wherein the command processing circuitry is operable to track the completion status of processing jobs being executed by the processing pipeline, and wherein the first portion of the command further includes information for performing such tracking.

17. The graphics processor of claim 16, wherein the command processing circuitry is operable to track when a rendering pass ends, and wherein the first portion of the command is capable of indicating that the processing operation indicated in the second portion of the command is a last processing operation to be performed for the rendering pass.

18. The method of claim 17 , wherein when the first portion of the command indicates that the processing operation indicated in the second portion of the command is a last processing operation to be performed for a rendering pass, after the processing pipeline has finished processing the command, the processing pipeline is operable and configured to signal to the command processing circuitry to indicate the end of the rendering pass.

19. The graphics processor of claim 12, wherein the command processing circuitry is operable to track how many commands it has issued to the processing pipeline and to stop issuing new commands to the processing pipeline when the command processing circuitry determines, based on its tracking, that a command buffer for the processing pipeline is full.

20. The graphics processor of claim 12, wherein the one or more specific processing operations to be performed for the processing pipeline indicated in the second portion of the command include one or more processing operations for: (i) indicating the start of a new rendering pass; (ii) setting a local processing pipeline configuration state; (iii) triggering execution of the processing pipeline configuration; and (iv) indicating the end of a rendering pass.

21. A data processing system, comprising: Main processor; as well as a graphics processor operable to perform processing work for an application executing on a host processor, wherein the graphics processor is operable and configured to perform the processing work by executing a processing pipeline, and wherein the graphics processor includes command processing circuitry operable to process commands received from the primary processor to perform the processing work, The host processor is operable and configured to prepare commands for the graphics processor in response to a request from an application executing on the host processor for processing to be performed by the graphics processor, wherein a set of commands for the graphics processor can include commands for performing processing work for the processing pipeline, the commands for performing processing work for the processing pipeline comprising: (i) having a first portion of an operation code identifying that the command is a command for performing processing work for the processing pipeline, the first portion also including information indicating a set of zero or more data values ​​to be used for one or more processing operations for the processing pipeline; and (ii) a second portion indicating one or more specific processing operations to be performed for the processing pipeline, The command processing circuitry of the graphics processor is operable and configured to, in response to receiving a command for performing processing work for the processing pipeline: processing the first portion of the command to determine that the command is a command for performing processing work for the processing pipeline; providing the second portion of the command to the processing pipeline; and The second portion of the command is used to determine one or more processing operations to be performed for the processing pipeline.

22. 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 claim 1 or 11.

Images