Graphics processing systems

Abstract

A graphics processing system comprises a programmable processing unit operable to execute processing programs for execution threads corresponding to work items to be processed, and storage (74) in which a respective storage region can be allocated for temporary use by a respective group of execution threads corresponding to a group of work items being executed by the programmable processing unit while the group of execution threads are being executed. The graphics processing system further comprises a clear operation circuit (33) controllable to write a clear value to all entries of a region of the storage.

Description

Graphics Processing SystemsBACKGROUNDThe technology described herein relates to graphics processors, and in particular to the operation of graphics processors when using local storage to (temporarily) store data for a group of execution threads.Many graphics processors include one or more processing (shader) cores, that execute, inter alia, programmable processing stages, commonly referred to as “shaders”, of a graphics processing pipeline that the graphics processor implements. For example, a graphics processing pipeline may include one or more of, and typically all of: a geometry shader, a vertex shader and a fragment (pixel) shader. These shaders are programmable processing stages that execute shader programs on input data values to generate a desired set of output data, such as appropriately shaded and rendered fragment data in the case of a fragment shader, for processing by the rest of the graphics processing pipeline and / or for output.It is also known to use graphics processors and graphics processing pipelines, and in particular the shader operation of a graphics processor and graphics processing pipeline, to perform more general computing tasks, e.g. in the case where a similar operation needs to be performed in respect of a large volume of plural different input data values. These operations are commonly referred to as “compute shading” operations, and a number of specific compute APIs, such as OpenCL and Vulkan, have been developed for use when it is desired to use a graphics processor and a graphics processing pipeline to perform general computing operations. Compute shading is used for computing arbitrary information. It can be used to process graphics-related data, if desired, but is also used for tasks not directly related to performing graphics processing.When performing “shader” processing, a graphics processor shader core will execute a (typically small) program for each “work item” in an output to be generated. In the case of generating a graphics output, such as a render target, such as a frame to be displayed, a “work item” in this regard is usually a vertex or a sampling position (e.g. in the case of a fragment shader). In the case of compute shading operations, each “work item” in the output being generated will be, for example, the data instance (item) in the work “space” that the compute shading operation is being performed on.In graphics processor shader operation, including in compute shading, each “work item” will be processed by means of an execution thread which will execute the instructions in the shader program in question for the work item in question.In such arrangements, the work load of the graphics processor is commonly subdivided into respective groups of work items (and correspondingly execution threads), which are correspondingly referred to as “work groups”. A work group is typically a collection of a few dozen to a few hundred execution threads (corresponding to respective work items), that are all guaranteed to exist at the same time (i.e. having the same lifetime) and are able to perform communication and synchronisation with each other (for example using work group-wide barriers). These execution threads are normally but not necessarily, short-lived, with typical lifetimes being dozens to thousands of instructions.In order to facilitate data sharing between the threads within a work group, a given (and each) work group will typically be allocated a memory region known as “work group local storage” that the threads in the work group can read from and write to. This memory region may be allocated from either normal system memory or from an on-chip resource, and remains available to all threads of the work group for the lifetime of the work group as a whole. When a work group reaches the end of its lifetime, the work group’s “local storage” memory region is normally deallocated, making it available for use by another work group.The Applicants believe that there remains scope for improved graphics processor operation when performing processing for work groups in the above manner.BRIEF DESCRIPTION OF THE DRAWINGSEmbodiments of the technology described herein will now be described by way of example only and with reference to the accompanying drawings, in which:Figure 1 shows an exemplary graphics processing system;Figure 2 shows schematically an embodiment of a graphics processor that can be operated in the manner of the technology described herein;Figure 3 shows the work group local storage shared memory in an embodiment of the technology described herein in more detail;Figure 4 shows the clear operation in an embodiment of the technology described herein;Figure 5 shows an example of a memory region being cleared in an embodiment of the technology described herein;Figure 6 shows a first embodiment of handling external memory accesses when performing a clear operation;Figure 7 shows another embodiment of handling external memory accesses when performing a clear operation;Figure 8 illustrates the handling of external memory accesses when performing a clear operation in an embodiment of the technology described herein;Figure 9 shows another embodiment of the work group local storage shared memory unit; andFigure 10 shows an embodiment of a shader program compilation process in an embodiment of the technology described herein.Like reference numerals are used for like elements in the Figures where appropriate.DETAILED DESCRIPTIONA first embodiment of the technology described herein comprises a graphics processing system, the graphics processing system comprising: a programmable processing unit operable to execute processing programs for execution threads corresponding to work items to be processed by the graphics processing system; storage in which a respective storage region (“work group local storage”) can be allocated for temporary use by a respective group of execution threads corresponding to a group of work items being executed by the programmable processing unit while the group of execution threads are being executed; and a clear operation circuit (“Clear Daemon”) controllable to write a clear value to all entries of a region of the storage.A second embodiment of the technology described herein comprises a method of operating a graphics processing system, the graphics processing system comprising: a programmable processing unit operable to execute processing programs for execution threads corresponding to work items to be processed by the graphics processing system; storage in which a respective storage region can be allocated for temporary use by a respective group of execution threads corresponding to a group of work items being executed by the programmable processing unit while the group of execution threads are being executed; anda clear operation circuit (“Clear Daemon”) controllable to write a clear value to all entries of a region of the storage; the method comprising: sending a “clear” command to the clear operation circuit to cause the clear operation circuit to write a clear value to all entries of a region of the storage; and the clear operation circuit, in response to the “clear” command, writing a clear value to all entries of the region of the storage.The technology described herein relates to graphics processing systems that include a programmable processing unit (a “shader core”), that has access to storage that can be allocated for use by “work groups” executing on the programmable processing unit (as discussed above) (“work group local storage”).The graphics processing system in the technology described herein further comprises a clear operation circuit that is controllable to write a “clear” value to all entries of a region of the (work group local) storage.As will be discussed in more detail below, the Applicants have recognised that such a clear operation circuit can, for example, be used to clear respective regions of the (work group local) storage (to act as a “Clear Daemon”), for example (and in an embodiment) when a region of the storage is to be reallocated to a different work group. This may then enhance the security of the use of the work group (local) storage, for example by ensuring that data from a previous work group is cleared before a new work group starts to use the region of the storage in question.Similarly, the Applicants have recognised that there may be situations where it is desirable to load some or all of the storage region allocated to a work group with the same initial value (e.g. for use then by all threads of the work group).Again, the clear operation circuit and process of the technology described herein, as will be discussed further below, facilitates performing such operations in an efficient manner.The Applicants correspondingly believe therefore that the technology described herein provides an improved arrangement and operation for graphics processing systems, in particular when using “work group local storage” as shared storage for execution threads in a respective work group.The programmable processing unit of the graphics processing system can be any suitable and desired programmable processing unit (“core”) that is operable to execute (shader) programs.The programmable processing unit is in an embodiment part of a graphics processor of the graphics processing system. Thus, the system in an embodiment comprises a graphics processor comprising the programmable processing unit. The graphics processor can be any suitable and desired graphics processor that includes a programmable processing unit that can execute program instructions.The technology described herein also extends to the operation a graphics processor that can be used as part of a graphics processing system as described above.Thus, a further embodiment of the technology described herein comprises a graphics processor, the graphics processor comprising: a programmable processing unit operable to execute processing programs for execution threads corresponding to work items to be processed by the graphics processor; and a clear operation circuit controllable to write a clear value to all entries of a region of storage in which a storage region can be allocated for temporary use by a respective group of execution threads corresponding to a group of work items being executed by the programmable processing unit while the group of execution threads are being executed.The graphics processor / system may comprise a single programmable processing unit, or may have plural such units. Where there are a plural programmable processing units, each processing unit can, and in an embodiment does, operate in the manner of the technology described herein.Where there are plural programmable processing units, each unit may be provided as a separate circuit to other programmable processing units of the graphics processor / system, or the programmable processing units may share some or all of their circuits (circuit elements).The (and each) programmable processing unit should, and in an embodiment does, comprise appropriate circuits (processing circuits / logic) for performing the operations required of the programmable processing unit.Thus, the (and each) programmable processing unit will, for example, and in an embodiment does, comprise an instruction execution circuit (execution engine) operable to, and configured to, execute program instructions for execution threads. This instruction execution circuit (engine) should, and in an embodiment does, comprise a set of at least one functional unit (circuit) operable to perform data processing operations for an instruction being executed by an execution thread. Anexecution unit (engine) may comprise only a single functional unit, or could comprise plural functional units, depending on the operations the execution unit (engine) is to perform.In an embodiment, the graphics processor / system and the programmable processing unit is operable to execute (shader) programs for sets (“warps”) of plural execution threads together, e.g. in lockstep, one instruction at a time.In this case the functional units, etc., of a given execution unit are in an embodiment configured and operable so as to facilitate such thread warp arrangements. Thus, for example, the functional units are in an embodiment arranged as respective execution lanes, one for each thread that a thread warp may contain.The (programmable processing unit of the) graphics processor / system in an embodiment also comprises any other appropriate and desired units and circuits required for the operation of the programmable processing unit(s), such as appropriate control circuits (control logic) for controlling the execution unit(s) (engine) to cause and to perform the desired and appropriate processing operations.Thus the (programmable processing unit of the) graphics processor / system in an embodiment also comprises an appropriate thread (warp (set)) manager (controller) circuit (a “warp manager”) that is operable to issue sets (warps) of threads to the execution unit (engine) for execution and to control the scheduling of sets (warps) of threads on / to the execution unit (engine) for execution.The thread (warp) manager in an embodiment comprises an execution thread generator (spawner) circuit that generates (spawns) (warps of) threads for execution; and an execution thread scheduler circuit that schedules (warps of) threads for execution (this may be part of the thread generator).The graphics processor / system in an embodiment also comprises and / or has access to appropriate (local) storage, such as registers / register file, caches, etc., and an appropriate interface to, and communication with memory (a memory system) of or accessible to the graphics processor / system (e.g., and in an embodiment, via an appropriate cache hierarchy), together with appropriate load / store units and communication paths for transferring data between the local storage and memory system of or accessible to the graphics processor / system.The memory and memory system is in an embodiment a main memory of or available to the graphics processor / system, such as a memory that is dedicated tothe graphics processor / system, or a main memory of a data processing system that the graphics processor / system is part of.The storage that is used to (temporarily) store data for execution threads for work groups in the technology described herein (and that the clear operation circuit can be controlled to “clear”) (the storage that is used for “work group local storage”) can be any suitable and desired storage of or available to execution threads when executing on the programmable processing unit (of the graphics processor / system).This storage is intended to be storage (memory) via which execution threads for respective work groups can communicate values to other threads in the work group, but which is to be allocated for use by threads of a work group temporarily (and so will be reused from one work group and / or process to another).It is different therefore, for example, to storage (e.g. system memory) that is to be used to “transfer” data values between different work groups, processes, and / or components of the overall data processing system. Rather, it is intended to be, and is, local and temporary storage (memory) that is used for work groups and that can be allocated for use by work groups, but which then will be de-allocated from a work group in question (and available for use by another work group) once a work group has terminated.Thus the storage that is used for “work group local storage” and that can be cleared by the clear operation circuit is intended to be, and to act and to be used as, a “scratch pad memory”, for use by work groups executing on the programmable processing unit.The allocation of storage regions within the “work group local storage” to respective work groups being executed by the programmable processing unit of the graphics processor can be performed in any suitable and desired manner. In an embodiment, this is done in the normal manner for the allocation of work group local storage for the graphics processor and graphics processing system in question.In an embodiment, respective regions of the storage may be (and are) allocated to plural different work groups at the same time, i.e. such that there will be plural different “work group local storage” regions allocated to different work groups in the storage at the same time. It could also, e.g., be the case that any given work group’s work group local storage in the storage comprises plural distinct (separate) regions in the storage, if desired.The storage that is used for the “work group local storage” may comprise storage that is dedicated to and specifically set aside for the purposes of providing “work group local storage” (and in one embodiment that is the case), or it may comprise storage that as well as being intended to be used as “work group local storage”, is also available to be used for other purposes, such as by other processes that the graphics processor / system may perform (and in another embodiment this is the case).In the latter case, the storage that is to provide the “work group local storage” and that the clear operation circuit / process can be controlled to “clear” will accordingly have plural “requesters” (“masters”) able to access it, comprising at least execution threads and the corresponding processes and circuits that are using the “shared” storage for “work group local” storage, and other processes and circuits that are using the storage for other purposes.The storage that provides the work group local storage may be configured as desired, e.g. as a single bank of storage. In an embodiment, the storage is configured as multiple, independently accessible (memory) banks (e.g. to allow more than one memory access per clock cycle).In the case where storage (whether dedicated to work group local storage or otherwise) is configured across multiple (memory) banks, then in an embodiment, a separate clear operation can be (and is) performed and configured for each memory bank (i.e. such that each storage (memory) bank has its own clear operation process, with each clear operation (in an embodiment) operable and configured to operate independently for its respective storage bank (once started)).In this case, the clear process for each (storage) bank is in an embodiment initially activated at the same time (for a given overall clear operation), but then the clear processes are allowed to run independently for each storage bank once started. The clear process for each different storage bank should be configured appropriately to clear the desired (appropriate) region of the bank in question.The storage that provides the work group local storage (and that the clear operation is controllable to clear) can be provided as desired in the graphics processing system.In an embodiment, it is storage that is local to (on-chip with) the graphics processor, and in an embodiment local to and on-chip with the programmable processing unit of the graphics processor / system. Thus, the storage is in an embodiment storage that provides a faster, more efficient and higher bandwidthpath from (the instruction execution circuit of) the programmable processing unit, than, for example, memory of the (main) memory system or available to the graphics processor / system.Correspondingly, in an embodiment, the system comprises a graphics processor that comprises both the programmable processing unit and the storage that is used for (that provides) the “work group local storage”.Correspondingly, the storage in an embodiment does not form (is not) part of a cache hierarchy or (main) memory (system), and in an embodiment does not require communication over any communication buses external to the graphics processor and / or programmable processing unit to be accessed by / for a work group executing on the programmable processing unit.Other arrangements would, of course, be possible.The clear operation circuit that is controllable to write a clear value to all of a region of the (work group local) storage can be any suitable and desired circuit that can be controlled to perform and perform such an operation, and can be arranged in any suitable and desired configuration and location relative to the storage. It should at least have appropriate access to the storage so as to be able to perform a clear operation on the storage, and have appropriate control interfaces to allow appropriate elements and components of the graphics processor and / or graphics processing system to trigger and control the clear operation when required.In an embodiment, the clear operation circuit is associated with, and in an embodiment part of, the overall storage (memory) unit that provides the work group local storage (and that the clear operation circuit / process is controllable to clear). Thus, in an embodiment, the storage, as well as comprising appropriate storage elements (e.g. memory banks), also comprises the clear operation circuit.In an embodiment, the clear operation circuit / process that is operable to write a clear value to a region of the storage used as (local storage) for work groups is located (at least logically) intermediate the programmable processing unit and the (work group local) storage. It is in an embodiment located at an appropriate point along the “access” path between the (instruction execution circuit (execution engine) of the) programmable processing unit and the (work group local) storage.In an embodiment, the clear operation circuit is part of, and / or comprises, a circuit that controls access to the (local) storage (i.e. such that any access requests from the (instruction execution circuit of the) programmable processing unit to the(local) storage will pass through and be controlled by a (local) storage access circuit, of which the clear operation circuit is (at least) part.Correspondingly, in an embodiment, the clear operation circuit is part of a / the graphics processor (the graphics processor comprises the clear operation circuit). Thus, in an embodiment, the system comprises a graphics processor that comprises the programmable processing unit, the storage that provides the “work group local storage”, and the clear operation circuit.Thus, a yet further embodiment of the technology described herein comprises a graphics processor, the graphics processor comprising: a programmable processing unit operable to execute processing programs for execution threads corresponding to work items to be processed by the graphics processor; storage in which a respective storage region (“work group local storage”) can be allocated for temporary use by a respective group of execution threads corresponding to a group of work items being executed by the programmable processing unit while the group of execution threads are being executed; and a clear operation circuit (“Clear Daemon”) controllable to write a clear value to all entries of a region of the storage.As will be appreciated by those skilled in the art, these further embodiments of the technology described herein can and in an embodiment do include any one or more or all of the features of the technology described herein described herein, as appropriate.The clear operation circuit can be implemented in any suitable and desired manner. For example, the clear operation circuit may comprise two registers to track the current start and end addresses of a region to be cleared, two comparators to check for accesses within the region to be cleared, and some control logic. Other arrangements would, of course, be possible.The clear operation circuit / process that is operable to write a clear value to a region of the (local) storage can operate in any suitable and desired manner. In an embodiment, it is configured to operate as, and operates as, a background process (a “Daemon”) (once activated / triggered).The clear operation circuit / process may be controlled to write a clear (data) value to a region of the (local) storage in any suitable and desired manner.In an embodiment, the clear operation circuit (and process) is provided with an indication of the region of the (local) storage to which a clear value is to bewritten (which is to be “cleared”). Thus, the “clear” command that triggers the clear operation in an embodiment indicates the region of the (local) storage to which a clear value is to be written (which is to be “cleared”). Such an indication can be provided in any suitable and desired manner, and in an embodiment indicates a range of storage entries (a range of (memory) addresses), to be cleared, for example, and in an embodiment, in the form of a start entry / address and an end entry / address for the region. The end entry / address for a region to be cleared may, for example, be indicated explicitly, or indirectly, e.g. as an offset from the start / entry address, and / or as a size of the region to be cleared (starting at the start entry / address).The region to be cleared by a given clear operation may, and in one embodiment does, correspond to the entirety of a region of the storage that has been allocated to a work group.However, this need not be the case, and the Applicants have recognised, for example, that in some circumstances it may be appropriate for a clear operation to “clear” only some but not all of the entirety of a region of the storage that has been allocated to a work group. This may be appropriate where, for example, it can be determined that part of the region of the storage that has been allocated for a group will always be written unconditionally, or the clear operation is being used to clear a particular data structure for a work group (which data structure does not occupy the entirety of the region of the storage that has been allocated to the work group).Thus, in other embodiments, the region to be cleared by a given clear operation is some but not all (is only part) of a region of the storage that has been allocated to a work group. Correspondingly, the region of the storage that a clear operation is controlled to write a clear value to all entries of need not correspond (exactly) to a storage region that has been allocated to a work group.Similarly, in the case where the storage includes plural separate regions allocated to the same work group, it could be that multiple clear operations are triggered, so as to clear each respective separate region that has been allocated to the work group in question.The clear value that is written to all the entries of a region of the storage when performing a clear operation can be any suitable and desired value that has the effect of “clearing” the storage region. Thus it should be, and in an embodiment is, a value or values that is not (is other than) dependent upon what was already stored in the entry (region) in question. For example, the clear operation couldsimply write a random value to each entry (address) that is being cleared, or write the address of the entry that is being cleared to the entry.It an embodiment, the clear operation operates to (and the clear operation circuit is correspondingly controllable to) write a same clear value (a common value) to all entries of a region of the storage.In this case, the same data value (the “clear” value) that is written to (all entries of) the indicated region by the “clear” process can be any suitable and desired data value. It could be the case (and in one embodiment is the case) that the clear operation circuit / process is configured to and operable to always write the same (predefined) data value to the indicated region of the (local) storage when operating, such as all zeros. This would be appropriate where, for example, the operation is (only) intended to be used to “clear” a region of the (local) storage after use by a work group.In an embodiment, it is possible to specify the same clear value that is to be written to all entries (addresses) in the indicated (local) storage region. (Thus in an embodiment, the clear command that triggers the clear operation can (and does) indicate the “clear” value that is to be written to the region to be cleared.)This will then allow the clear process to be used to write values other than zero to a region of the (local) storage, if desired. This may be appropriate where, for example, it is desired to populate a region of local storage being used for a work group with a particular, in an embodiment selected, and in an embodiment predefined, value (but which value may be different for different instances of this operation, for example when being used for different work groups).Thus, in an embodiment, the control parameters (state) for a clear operation (for the clear operation circuit and process) comprise both an indication of the (local) storage region to be written to (to be “cleared”), together with an indication of the (single and common, same) data value (the “clear” value) to be written to that region of the (local) storage.The clear operation circuit (process) can operate to write a clear value to an (indicated) region of the (local) storage in any suitable and desired manner. In an embodiment, the clear operation circuit and process operates to write a clear value to the indicated region incrementally, e.g. one storage entry (address) at a time. This is in an embodiment done starting from one end of the region to be cleared, and in an embodiment from the bottom up (at the lowest entry (address) in the region), in a (progressively) increasing (or decreasing) entry (address) order.In an embodiment one “clear” write operation is performed in each “memory access” cycle (where the clear write operation is not stalled for any reason (this will be discussed further below)).Thus, in each storage access cycle, the clear process should write a clear value to an appropriate entry or entries (address or addresses) in the storage. In the case where a given storage access can simply access one entry (address) in the local storage in a given cycle, then the clear process should write a clear value to a single entry (address) in the local storage in a given memory access cycle.However, where the storage access configuration is such that multiple entries (addresses) in the local storage can be accessed in a given (memory) access cycle, then in an embodiment the clear process is configured to and operates to write to plural, and in an embodiment to the (maximum) permitted plural number of, entries (addresses) in the local storage that can be written in a given memory access (i.e. to perform “wide” writes for its operation, rather than writes that match the size of the writes that may be performed by individual execution threads when accessing the local storage for a work item of a work group). This will allow the local storage writing (clearing) process to be performed more quickly (in a reduced number of cycles), thereby, for example, reducing power cost for that operation.A clear operation should be, and is in an embodiment, continued, until a clear value has been written to all entries (addresses) in the region of the (work group local) storage (that the clear operation is to “clear”).In the case where, as discussed above, the storage is arranged as multiple banks, then while it would be possible for each bank simply to have the same start and end addresses (and clear value) if desired, in an embodiment, particularly in the case where each bank has its own independent clear process, a separate set of state (control) information is provided and used for the clear operation for each storage (memory) bank independently.Thus in an embodiment, each bank of the storage has its own specified region (start address and end address) (and where appropriate clear value) specified for it when the clear operation is to be performed. The start and end addresses for the different memory banks should indicate the region within the respective memory bank to be cleared, and so may differ as between the different memory banks, e.g. where the overall storage region to be cleared is not evenly distributed across the banks.In an embodiment in this case a single, “clear” command that controls the clear operation that indicates a “global” (overall) region to be cleared (and where appropriate a clear value) is in an embodiment used to trigger the clear operation, with the particular regions within each memory bank to be cleared then being determined as part of the clear operation process (by the clear operation circuit), e.g. to provide a region (range) to be cleared for each (memory) bank, with the per-bank regions then being conveyed to the per-bank clearing processes in an appropriate manner. Alternatively, the “clear” command could specify the relevant control parameters for each memory bank individually, or a different “clear” command could be sent for each memory bank.In an embodiment, the clear operation circuit and process supports the performing of plural (separate) clear operations in parallel (at the same time). For example, there may be multiple regions of the storage being cleared at the same time, each via a respective clear operation. In this case, the different clear operations may start and finish at different times, and use different clear values, etc., as desired.In an embodiment, access to a region of the storage (to regions of the local storage) that are currently being cleared (being written to by a clear operation) is controlled, for example and in an embodiment, to at least prevent any access that is directed to a region of the (local) storage that has still to be written to (cleared) by a clear operation (and the system is correspondingly configured to operate in this manner).This access control operation can be provided by any suitable and desired element (circuit) of the system (e.g. graphics processor).In an embodiment, this is done by the clear operation circuit and process, i.e. the clear operation circuit and process is also operable to and configured to control access to a region of the local storage (to regions of the local storage) that it is currently writing to (clearing).Thus, in an embodiment, the system, e.g. clear operation circuit / process is configured to, and does, check any (memory) access to the local storage (at least) from execution threads that are part of work groups executing on the programmable processing unit to determine whether the access is to a local storage region (address) that is undergoing a clear operation (and to handle, and handles, the access accordingly).This operation may be achieved in any suitable and desired manner. In an embodiment, the graphics processor and system is configured such that all accesses to the local storage (at least) from execution threads that are part of work groups executing on the programmable processing unit pass to (access) the local storage via the clear operation circuit / process, such that the clear operation circuit / process receives every (each) such (memory) access.This operation could comprise, for example, determining whether the entry ((memory) address) being accessed is within the initial range of addresses (entries) indicated as needing to be cleared or not, and handling appropriately (e.g., and in an embodiment, stalling) all accesses to an (initially indicated) region to be “cleared”, until the entire region has been “cleared”.In an embodiment, this access control (the clear operation circuit and process) is configured to and operates to handle appropriately (and prevent) any access that is directed to a region of the local storage that has still to be written to (cleared) by a clear process, but permits accesses that are directed to a region of the local storage that has already been written to (cleared) by a clear process (rather than, e.g., simply blocking all accesses to the initial region to be cleared until the clearing process has been completed).In this case, an access to a region of the local storage that is still to be cleared is in an embodiment handled appropriately (in an embodiment by stalling the access) until the clear process has written a clear value to the entry (address) in question (has cleared the local storage entry (address) in question) (but an access to a region of local storage that has already been written to (cleared) will be, and is in an embodiment, allowed to proceed).In this case, the system (the clear operation circuit / process) is correspondingly in an embodiment configured to, and operates to, check any memory access that it receives to determine whether the access is to a local storage region (address) that is waiting to be cleared (that is still to be cleared) or not (and to handle the access accordingly).This determination can be performed in any suitable and desired manner, for example by determining whether the (memory) address (entry) being accessed is within the range of addresses (entries) still to be cleared or not.To facilitate this operation, the system (e.g., and in an embodiment, the clear operation circuit and process) in an embodiment keeps track of those local storage entries (addresses) that are still to be cleared, for example, and in anembodiment, by tracking the next (the current) entry (address) to be cleared, in an embodiment by updating (e.g., and in an embodiment, progressively incrementing) the “start” entry (address) for the region to be cleared as entries (addresses) in the region to be cleared are written to. It can then be, and is in an embodiment, determined whether a given access is to an entry (address) between the “current” entry to be cleared (the current “start” of the region still to be cleared) and the end entry (address) for the region to be cleared, or not.As discussed above, in the case that a memory access is attempted inside the region still to be cleared, then the, e.g., clear operation circuit / process, should and in an embodiment does handle (e.g. stall) that (memory) access until it has written to (cleared) the entry (address) in question.On the other hand, in the case of a memory access to an entry (address) in the local storage that is outside a region currently to be cleared, then the, e.g. clear operation circuit / process, in an embodiment permits that memory access to proceed (in the normal manner) (without stalling it). If necessary, the clearing process (the writing of a data value to an entry or entries (address or addresses) in the region to be cleared) is stalled while (and so as to permit) the memory access to proceed. The clearing process in an embodiment then attempts to continue (resume) in the next memory access cycle (unless again “blocked” by another memory access to a region that is not waiting to be cleared).In other words, the, e.g. clear operation circuit / process, in an embodiment permits accesses to local storage regions (addresses) that have already been cleared or that are outside the region to be cleared, but prevents accesses to any “yet-to-be-cleared” local storage regions. This is in an embodiment achieved by appropriate checking of the address (entry) to be accessed by the memory access to the range of addresses (entries) that are still to be cleared (when there is a clearing process in operation).Such checking is in an embodiment done in respect of, and for, every clear operation that is in progress at the time of the memory access.Thus, in an embodiment, the clear operation circuit is configured to (and the clear operation process correspondingly operates to) check whether a memory access from the (instruction execution unit of the) programmable processing unit is to a memory address that is within a region still to be written to by the clear operation circuit / process as part of an existing clear operation / process, and to, when so, handle the memory access appropriately (by at least preventing thememory access from accessing the storage entry (or entries) (address or addresses) in question (but when not, to permit the memory access to proceed (and if necessary stall the write operation of the clear process)).As discussed above, in an embodiment, the memory access control operation operates to stall a memory access that is within a region still to be written to as part of an existing clear operation / process (or an access to an initial region to be cleared, as desired).However, it would instead be possible to allow a read access at least to an entry to be cleared to be allowed to pass instead of stalling, but with such a read having its result overwritten to return a clear value (rather than whatever entry may be present in the still to be cleared storage entry that the access is to read). In other embodiments, this is how (read) memory accesses to still to be cleared regions are handled.In the case where the storage that is being used as work group local storage is provided as multiple separate banks, with a clear operation being performed in each bank independently, then it will be appreciated that the “clearing” of each memory bank may run at different speeds, and may not be performed completely in parallel, for example depending upon the extent to which there are conflicting memory accesses to a given memory bank while the clearing process is proceeding.Where a memory access has been stalled, e.g. by the clear operation circuit / process, in this manner, then that memory access should be, and is in an embodiment, appropriately resumed and performed after the corresponding entry (address) in the local storage has been “cleared” by the clear process.This can be achieved in any suitable and desired manner. For example, stalled memory accesses could be retried periodically to see if their addresses have been cleared, and / or a record of pending memory accesses and their addresses could be maintained, together with tracking the progress of the clearing of storage entries (addresses), so it can be identified when a storage entry (address) relating to a stalled memory access has been cleared, for the memory access then to be retried.Other arrangements would, of course, be possible.When a memory access is stalled in this manner, then later memory accesses (that are not to still to be cleared storage regions) could still be permitted to proceed (and in one embodiment that is what is done), or all following memoryaccesses (whether to a yet-to-be-cleared region or not) could be stalled until the first memory access has successfully proceeded (and in another embodiment, this is what is done). The former operation will have the effect of permitting memory accesses to be performed out-of-order, whereas the latter operation will constrain all the memory accesses to be performed in order (and so should be used where the order of memory accesses needs to be preserved, irrespective of whether or not they are to still to be cleared regions or not).In the case where the (work group local) storage is also shared with another unit or units (or process or processes) that is able to use the storage (in addition to the storage being used for work group local storage for work groups being executed by the programmable processing unit), then in an embodiment, the system (e.g. graphics processor) includes an appropriate) arbitration circuit(s) and process(es) to arbitrate between accesses to the storage that relate to its use as work group local storage (e.g. that proceed via the clear operation circuit(s)) and access requests coming from other “requesters” to the storage. Again, in the case where the storage is comprised of multiple banks, this is in an embodiment done and provided on a bank-by-bank basis.In this case, the system in an embodiment comprises one or more arbitration circuits / processes, that are operable to and configured to receive both storage access requests relating to work group local storage regions and work group local storage, and access requests from other requester(s) (master(s)), and to arbitrate between those requests.The arbiters (arbitration process) can be configured to operate as desired, for example to always prioritise memory access requests from “another” requester, or to always prioritise requests relating to work groups (from the clear operation circuits), as desired. There could equally be multiple other requesters able to access the storage, with appropriate arbitration (priority) policies in place accordingly.It would also be possible for the relative priorities of different access requests to the storage to be selectively set in use, for example by setting appropriate state (control) information for the arbitration process.In such arrangements, in an embodiment in the case where a higher priority request from another requester is received, the clear operation or work group memory access (e.g. from the corresponding clear operation circuit) is appropriatelystalled until the other request has been serviced, and may then be resumed (as discussed above).Correspondingly, in the case where access requests for work groups (and the clear operation circuits) have priority, then any memory access from another requester is in an embodiment appropriately stalled until the work group request (e.g. via the clear operation circuit) has been serviced (and is in an embodiment then resumed).The arbitration circuit / process could be separate to the clear operation circuit / process (and, e.g., follow the clear operation circuit / process in the (logical) path to the storage bank(s)).In an embodiment, the graphics processor and storage is configured such that access requests from other requesters also pass via the storage access control process / circuits (e.g. clear operation circuit(s)), with the, e.g. clear operation circuit(s) then acting to appropriately arbitrate between the various different requests (as desired) (i.e. the storage access control / clear operation circuits also include the arbitration circuits and act as and perform the arbitration process).In this case, the storage access control, e.g. clear operation, circuits in an embodiment handle any memory access requests from other requesters (subject to any priority ranking) in the same way as they do for other memory access requests from the execution engine, i.e. to determine whether the memory access request from another requester is to a region that is still to be cleared, and then, if so, to appropriately stall that memory access request from another requester until the region has been cleared.In an embodiment, a (in an embodiment hardware-based) “bounds check” is performed on memory accesses from any “another” requester, to determine whether its memory access is being made to a region of the storage that has already been allocated to a work group for use as work group local storage or not (and to prevent any accesses from another requester that is to a region of a memory bank that has already been allocated to a work group). This would then avoid other memory accesses from other requesters being able to interfere with the work group local storage region. Such (hardware-based) memory region bounds checks could be implemented in any suitable and desired manner, for example in the normal manner for the graphics processor and graphics processing system in question.The clear operation of the technology described herein can be invoked and triggered in any suitable and desired manner. As discussed above, this is in an embodiment done by sending an appropriate “clear command” (message) to the clear operation circuit, which clear command in an embodiment specifies (indicates) the required parameters for the clear operation.In an embodiment, the clear operation is (at least) triggered (and performed) when a storage region for a work group in the (local) storage is to be de-allocated (on work group de-allocation). In this case, in an embodiment, the clear operation is triggered upon the work group region de-allocation event (which may be triggered in any suitable and desired manner, such as, and in an embodiment, in the normal manner for the graphics processor and graphics processing system in question), but with the de-allocation itself then not being performed until the clear operation has finished (clearing the region that is being de-allocated). This should then ensure that the region allocated to the work group (that is being de-allocated) will be cleared before that region is made available by use by another work group. In this case, it would also be possible, for example, to provide a user-space control to allow the programmer (e.g.) to indicate whether a work group local storage region should be “post-cleared” when it is de-allocated, or not.(The de-allocation of a region of the local storage after / from use by a work group (which may trigger a clearing operation) can be performed in any suitable and desired manner, and is in an embodiment performed in the normal manner for de-allocating work group local storage in the graphics processor and graphics processing system in question.)In an embodiment, the clear operation can also or instead (and in an embodiment also), and in an embodiment is, (at least) triggered (and performed) when a new allocation of a storage region for a new work group is made in the (local) storage in question. Thus, in an embodiment, when a new local storage region allocation for a (new) work group is made, the clearing process is correspondingly and in an embodiment triggered to clear the (newly allocated) local storage region in question before it is used by (execution threads for) the work group in question.(The allocation of a region of the local storage to a work group (for use by a work group) (which may then trigger the clearing operation) can be performed in any suitable and desired manner, and is in an embodiment performed in the normalmanner for allocating work group local storage to a work group in the graphics processor and graphics processing system in question.)The clear operation in this case could be triggered by any suitable and desired element of the graphics processor and graphics processing system. For example, the circuit and process that allocates / de-allocates local storage regions for work groups could also be configured to communicate appropriately with the clear operation circuit / process to trigger the clear operation when it allocates / de-allocates a storage region for a work group.In an embodiment, the clear operation that is performed when a local storage region allocation / de-allocation for a work group is made is triggered by the process and circuit that generates the execution threads for work groups in question (which thread creation process / circuit then, in an embodiment, correspondingly sends an appropriate “clear” command to the clear operation circuit to trigger the clearing operation).Thus, in an embodiment, the thread (warp) manager (management circuit) is configured to and operable to send clear operation commands to the clear operation circuit / process to trigger a clear operation.The clear operation in the case of an “allocation” operation could be triggered (the clear command sent) at any appropriate point in the allocation process. For example, it could be triggered directly following a point when the work group local storage gets allocated. Alternatively, the clear operation could be triggered when the first access to the work group local storage region is made (with the access correspondingly being stalled appropriately). The allocation of the work group local storage can correspondingly be performed at any suitable and desired point in the process, for example when it is known that the work group will be run (at some point) or, for example, once threads for the work group start to be created, or after thread creation.Thus, the clear operation could in this regard be triggered (the command sent) at any appropriate point in the work group “creation” process, for example once the thread group manager is aware that a new work group is to be created, or once the work group has been created but before the necessary execution threads have been issued for execution, etc., as desired.In an embodiment, the clearing process (in these cases) is triggered before (and in an embodiment immediately prior to launching) execution of the main work group threads.In an embodiment, the clearing process (in these cases) is triggered as execution of the main work group threads is commenced (but before, and in an embodiment immediately prior to), launching execution of the main work group threads. Correspondingly, the execution of the main work group threads is in an embodiment launched (the main work group threads are in an embodiment issued for execution to the instruction execution circuit) after the clearing process has been initiated (triggered), but without waiting for the clearing process to have been completed before launching execution of any of the main work group threads (before issuing any of the main work group threads for execution), i.e. such that execution of the main work group threads will commence and be happening while the clearing process is proceeding (and has not yet finished).The Applicants have recognised in this regard that a (very) common usage pattern for work group local storage is to have a work group load content from external memory into the work group local storage in an increasing address order. By having the clearing process of the technology described herein iterate over the addresses in the same order, the clearing process will effectively run in parallel with the external memory loading but ahead of the arrival of the data from external memory. For example, in the case where the external memory loading is done in linear access order and is not fast enough to maintain more than 50% utilisation of the work group local storage’s write data ports, the entire clear operation may be performed in parallel with the start of the work group’s work with no loss of overall system performance.A clearing operation could be triggered whenever there is local storage allocation for a new work group (and in one embodiment that is what is done).However, the Applicants have recognised that it may not be necessary to first “clear” local storage to be used for a work group in the case where the storage region was previously used by a work group from the same trust domain as the new work group (e.g. for the same process and / or virtual machine, etc., as the previous work group).Thus, in an embodiment, a clearing operation is triggered in response to allocation of a region in the local storage for a new work group when the storage region in question is being allocated (all or in part) to a work group from a different trust domain, but is not triggered (is other than triggered) when the (entirety of the) storage region in question is being allocated to another work group from the same trust domain.In an embodiment this check and the triggering of the clearing process is done in a conservative manner, i.e. such that the clearing process will be triggered when it cannot be proven that the new work group that the local storage region is being allocated to comes from the same trust domain (i.e. such that the clearing process will be triggered unless and only when it can be determined with certainty that the new work group that the local storage region has been allocated to comes from the same trust domain as the previous work group that used that region).In these arrangements, a change of trust domain between work groups can be determined / identified in any suitable and desired manner, for example, and in an embodiment, in the normal manner for identifying and / or assuming trust domain changes in the graphics processor and graphics processing system in question.In an embodiment, it is also possible for the clear operation of the technology described herein to be triggered during execution of a work group. In this case, the clearing process is in an embodiment triggered to clear some or all (and in an embodiment all) of the region of the local storage that is allocated to the work group in question.The Applicants have recognised in this regard that for some shading operations to be performed by graphics processors, it may be desirable for a region of storage being used by a respective work group as work group local storage to be set to a known value. For example, a work group that computes a histogram may want to zero out the storage used for the histogram before the main part of the histogram computation. Being able to trigger the clearing process of the technology described herein during work group execution would facilitate such operation.Such triggering of the clearing process during work group execution can be achieved in any suitable and desired manner. In an embodiment this is achieved by including an appropriate “clear-region” instruction in the program to be executed by the (threads of the) work group, which instruction when executed will trigger the clearing operation.Such a clear-region instruction can be configured in any suitable and desired manner. It should be, and in an embodiment is, at least, operable to trigger the clear process when executed, and should, and in an embodiment does, also, indicate the region of the local storage (e.g. a start address and end address (or offset or size, etc., of the region to be cleared)) that is to be cleared, and, where appropriate, the “clear” value that is to be written to the region to be cleared.In response to executing such an instruction, the programmable processing unit (and in an embodiment the instruction execution circuit (execution engine) (that is executing the instructions for the execution threads) of the programmable processing unit) is in an embodiment correspondingly caused to and triggered to send an appropriate message (command) to the clear operation circuit / process to perform the clearing operation (for the indicated storage region).Correspondingly, in an embodiment, there is an appropriate communication path between the programmable processing unit (and in an embodiment an instruction execution circuit (execution engine) of the programmable processing unit) and the clear operation circuit / process, whereby the programmable processing unit (execution engine) can command the clear operation circuit to perform a clear operation in response to executing a “clear-region” instruction.The Applicants believe that the use of such a “clear region” instruction (and the corresponding clear operation) may be useful and advantageous in its own right, for example to be able to set a region of work group local storage to a desired “clear” value during work group execution (as discussed above).Thus, another embodiment of the technology described herein comprises a method of operating a graphics processing system, the graphics processing system comprising: a programmable processing unit operable to execute processing programs for execution threads corresponding to work items to be processed by the graphics processing system, the programmable processing unit comprising an instruction execution circuit configured to execute program instructions for execution threads; storage in which a respective storage region can be allocated for temporary use by a respective group of execution threads corresponding to a group of work items being executed by the programmable processing unit while the group of execution threads are being executed; and a clear operation circuit controllable to write a clear value to all entries of a region of the storage; the method comprising: when the programmable processing unit is executing a program to perform processing for a group of execution threads corresponding to a group of work items, the instruction execution circuit of the programmable processing unit, in response to executing an instruction in the program for an execution thread of the group of execution threads:sending a “clear” command to the clear operation circuit to cause the clear operation circuit to write a clear value to all entries of a region of the storage.A yet further embodiment of the technology described herein comprises a graphics processor, the graphics processor comprising: a programmable processing unit operable to execute processing programs for execution threads corresponding to work items to be processed by the graphics processor, the programmable processing unit comprising an instruction execution circuit configured to execute program instructions for execution threads; wherein the instruction execution circuit of the programmable processing unit is configured to, in response to executing an instruction in a program for an execution thread of a group of execution threads: send a clear command to a clear operation circuit controllable to write a clear value to all entries of a region of a storage in which a respective storage region can be allocated for temporary use by a respective group of execution threads corresponding to a group of work items being executed by the programmable processing unit while the group of execution threads are being executed, to cause the clear operation circuit to write a clear value to all entries of a region of the storage.As will be appreciated by those skilled in the art, these embodiments of the technology described herein can, and in an embodiment do, include any one or more or all of the features of the technology described herein described herein, as appropriate.Thus, for example, the clear command that is sent to trigger the clear operation in an embodiment indicates the appropriate parameters for the clear operation, as discussed above.In the case where a (shader) program includes a clear-region instruction, it is in an embodiment checked whether the clear region instruction applies only to a region of the storage that is allocated to (that is in the trust region of) the work group in question (that executes the instruction) or not, with the clear operation not (other than) being performed in the event that it is indicated as applying to a region of the storage that is outside a region of the storage that is allocated to (that is in the trust region of) the work group in question (and, e.g., with an error process then being performed / reported instead).This can be checked in any suitable and desired manner, for example by performing an appropriate “bounds check” on the region to be cleared indicated bythe instruction. Such a bounds check is in an embodiment a hardware implemented bounds check, that is triggered by (and in response to) execution of the clear region instruction. Such (hardware-based) memory region bounds checks could be implemented in any suitable and desired manner, for example in the normal manner for the graphics processor and graphics processing system in question.The Applicants have recognised that where a (shader) program to be executed for a work group includes such a “clear-region” instruction, then each and every execution thread in the work group should, and in an embodiment does, reach and execute the clear-region instruction in and during its program execution. However, the clear operation that is triggered by the clear-region instruction need only be, and is in an embodiment only, performed once (rather than each time an execution thread in the work group executes the clear-region instruction).Accordingly the work group program execution is in an embodiment controlled and configured such that only a single clear operation will be triggered in response to the execution of a (respective) “clear-region” instruction by a work group. This can be achieved in any suitable and desired manner.In one embodiment, the operation is configured such that the first execution thread of the work group to reach the (respective) clear-region instruction in its program execution executes that instruction to trigger a clear operation, with all other threads in the work group when reaching (executing) that instruction not (other than) also triggering the clear operation. For example, it could be tracked whether the clear operation (in question) has already been triggered for the work group, such that any later threads that reach / execute the clear region instruction do not trigger a further clear operation.It would also be possible to, for example, configure the operation such that only a (single) particular, in an embodiment selected, in an embodiment predetermined, execution thread (e.g. the first thread) in a work group will trigger the clear operation, for example by making the clear operation conditional (wrapping the clear region instruction in a conditional) so that it is only executed by one thread (e.g. a thread having a particular thread ID).In one embodiment, the clear operation is preceded by a “barrier”, such that the program execution will wait until all the execution threads in the work group have reached the barrier, before the clear operation is proceeded with. This can then be used to ensure that only a single clear operation will be triggered by a workgroup for a given instance of a clear region instruction, and also ensure some work group-wide synchronisation for the program execution around the clear-region instruction. The use of such a “pre-barrier” for the clear operation may be particularly useful where there are accesses to the region being cleared prior to the clear operation, as the barrier will thereby ensure that all those accesses have been completed before the clear operation is started.Such an instruction execution barrier may operate in any suitable and desired manner, and in an embodiment operates in the normal manner for the graphics processor and graphics processing system in question (e.g., and in an embodiment, to stop all execution thread execution for the work group at the barrier, until all the execution threads for the work group have reached the barrier).Thus, in an embodiment, when a clear-region instruction is included in a program to be executed for a work group, that clear-region instruction is associated with a barrier prior to the clear operation, and in an embodiment (immediately) preceded by an (execution) barrier, such that the clear-region instruction will only be executed once all threads in the work group have reached the barrier (and will only be executed once at that point). This will then ensure that all work before the clear operation is completed before the clear operation is started (and that the clear operation will be performed only once).This said, the Applicants have further recognised that it may not be necessary to always use such an execution barrier prior to the clear operation, for example in situations where there aren’t any earlier accesses to the region / data being cleared, such that starting the clear operation before all the execution threads in the work group have reached the clear-region instruction should not have any detrimental effect on those threads and their processing. In such cases there may be no need for a barrier prior to the clear operation. Thus in other embodiments, the clear operation (the clear-region instruction) is not (is other than) associated with a preceding barrier (a “pre-barrier”).It would also be possible to include a second barrier after (immediately after) the clear-region instruction, to ensure that no further program execution (work) starts using the memory region until the clear operation has been completed (and in one embodiment, this is what is done).However, the Applicants have recognised in this regard that, in particular in the arrangement where the clear operation circuit / process is also operable to control accesses to a region that it is clearing (as discussed above), the operationof the clear operation circuit / process will prevent any memory accesses to the region still to be cleared in any event, such that there is in practice no need to have an (explicit) second barrier after the clear-region instruction (i.e. the clear operation process itself effectively provides the necessary “barrier” to follow the clear-region instruction in any event).Thus, in an embodiment, where a clear-region instruction is used to trigger a clear operation in the manner of the technology described herein, that clear-region operation is not (is other than) “guarded” by a following an execution barrier (but may be preceded by an execution barrier).Thus, in the case where the clear operation is preceded by a barrier, work group execution will proceed until all execution threads have reached the (preceding) barrier (at which execution for a given execution thread will stop), then once all threads in the work group have reached the barrier, the clear-region operation will be triggered and the barrier will be released (thereby permitting execution threads to continue their execution past the clear-region instruction).This will then reduce the number of barriers needed whilst still ensuring work group-wide synchronisation from two to one, thereby helping to improve performance.It would be possible in this regard for the “pre-barrier” (where used) to be included as an explicit barrier (barrier instruction) in the program being executed.In an embodiment, the clear-region instruction itself is used to indicate that an execution barrier should be enforced before the clear operation (rather than explicitly including an additional and separate barrier instruction in the program). This may be done, for example, as a modifier on the clear region instruction.Thus, in an embodiment, a single instruction that sets (acts as) the (preceding) barrier and triggers the clear-region operation as one “fused” operation can be, and is, used.In an embodiment, the clear-region instruction can selectively indicate whether a barrier is to be enforced prior to the clear operation or not (such that a same form of clear-region instruction can be used whether a pre-barrier is desired or not). In this case, the clear-region instruction correspondingly and in an embodiment includes an appropriate indication (e.g. modifier) that can be set to indicate that a (pre-)barrier is required or that a (pre-)barrier is not required. This would then allow an application programmer / compiler to include a pre-barrier for a clear operation as desired.Thus, in an embodiment, the clear-region instruction can indicate the region of the memory that is to be cleared (e.g. in the form a start address and a size to clear), the “clear” value that is to be written to the region to be cleared, and whether a barrier should be enforced prior to the clear operation. Other arrangements would, of course, be possible.The inclusion of a clear region instruction in a program to be executed by the programmable processing unit of the graphics processor can be performed in any suitable and desired manner.In an embodiment, such clear region instructions are included in programs to be executed by the (shader) compiler for the graphics processor (and thus the processing circuit operable to include a clear region instruction in a program comprises a compiler for (shader) programs (of the overall graphics processing system)).Thus, a further embodiment of the technology described herein comprises a method of compiling a (shader) program to be executed by a programmable processing unit operable to execute processing programs for execution threads corresponding to work items to be processed of a graphics processor, the programmable processing unit comprising an instruction execution circuit configured to execute program instructions for execution threads; the method comprising: including in a shader program to be executed by a programmable processing unit of a graphics processor, a clear region instruction that when executed by an instruction execution circuit of a programmable processing unit of a graphics processor, will cause the instruction execution circuit to: send a clear command to a clear operation circuit controllable to write a clear value to all entries of a region of a storage in which a respective storage region can be allocated for temporary use by a respective group of execution threads corresponding to a group of work items being executed by the programmable processing unit while the group of execution threads are being executed, to cause the clear operation circuit to write a clear value to all entries of a region of the storage.As will be appreciated by those skilled in the art, these embodiments of the technology described herein can, and in an embodiment do, include any one or more or all of the features of the technology described herein described herein, as appropriate.The generated shader program can then be issued to the programmable processing unit of the graphics processor for execution thereby.In an embodiment, the compiler can (and does) include a clear region instruction of the technology described herein in a program in response to an explicit instruction to that effect in a (shader) program to be compiled.In an embodiment, the compiler additionally or alternatively (and in an embodiment additionally) can (and does) include a clear region instruction of the technology described herein in a program in response to identifying program expressions that relate to and / or that require appropriate clear region operations in a program to be compiled.Thus, in an embodiment, the overall data processing system operation allows an application programmer to explicitly specify that a clear region operation in the manner of the technology described herein is to be performed, e.g. by including an appropriate program expression for the clear region operation in an application program to be executed in a (shader) program to be executed by the graphics processor.This could be achieved, for example, and in an embodiment, by providing an API extension that includes one or more specific program expressions for clear region operations in the manner of the technology described herein (such that an application program can include a specific program expression when a clear region operation in the manner of the technology described herein is desired). In this case, the appropriate (shader) compiler should be operable to recognise the specific clear region operation program expression(s) and compile those expression(s) to binary instruction(s) for the (execution engine of the) programmable processing unit so as to cause a clear region operation to be performed using the clear operation circuit / process of the graphics processor in line with the technology described herein.In an embodiment, clear region instructions in the form of the technology described herein can be, and in an embodiment are, included in the (compiled) (shader) program code that is sent to the graphics processor by the compiler without the need for an “explicit” program expression to that effect, such as, and in an embodiment, in response to (appropriate) program expressions for operations in a program being compiled (but which are not (specifically) for clear region operations in the manner of the technology described herein). In this case, the clear region instructions in the manner of the technology described herein may notbe directly exposed to an application programmer, but the compiler will be, and is in an embodiment, operable to include such clear region instructions in a (shader) program to be executed (where it is appropriate to do that).In this case, the compiler is in an embodiment operable to identify program expression(s) in a (shader) program provided to the compiler that are writing a same value to a region of (work group local) storage, and then replace that expression(s) with a single clear region instruction (or a clear region instruction together with a preceding barrier) in the manner of the technology described herein.The compiler can operate as desired, e.g., and in an embodiment, as part of the driver for the graphics processor that is, e.g., and in an embodiment, executing on a host processor of the overall data (graphics) processing system that the graphics processor is part of or associated with. Correspondingly, the compiler may identify the presence of appropriate clear region operations in a program to be executed at any desired stage of the compilation process, such as from application program expressions, intermediate (partially compiled) instructions, and / or compiled (binary) instructions.Other arrangements would, of course, be possible.The graphics processing system may further include a host processor that executes applications that can require data or graphics processing by the graphics processor and that instruct the graphics processor accordingly (e.g. via a driver for the graphics processor). The system may further include appropriate storage (e.g. memory), caches, etc..The graphics processing system and / or graphics processor may also comprise, and / or be in communication with, one or more memories and / or memory devices that store data, and / or that store software for performing the processes described herein. The graphics processing system and / or graphics processor may also be in communication with a host microprocessor, and / or with a display for displaying images based on the data generated.The graphics processor may include (implement) any one or more or all of the processing stages that a graphics processor (processing pipeline) can normally include. Thus, for example, the graphics processor may include a primitive setup stage, a rasteriser, and / or Tenderer (in an embodiment in the form of a fragment shader).The graphics processor (processing pipeline) may comprise one or more other programmable shading stages, such as one or more or all of, a vertexshading stage, a hull shader, a tessellation stage (e.g. where tessellation is performed by executing a shader program), a domain (evaluation) shading stage (shader), and a geometry shading stage (shader), as well as a fragment shader.The graphics processor (processing pipeline) may also contain any other suitable and desired processing stages that a graphics processing pipeline may contain such as a depth (or depth and stencil) tester(s), a blender, a tile buffer or buffers, a write out unit etc..The technology described herein can be used in and with any suitable and desired graphics processing system and processor. In one embodiment, the graphics processor (processing pipeline) is a tiled-based graphics processor (processing pipeline).The technology described herein can be used for any form of output that a graphics processor may be used to generate. In one embodiment it is used when a graphics processor is being used to generate images for display, but it can be used for any other form of graphics processing output, such as (e.g. post-processed) graphics textures in a render-to-texture operation, etc., that a graphics processor may produce, as desired. It can also be used when a graphics processor is being used to generate other (e.g. non-image or non-graphics) outputs.In one embodiment, the various functions of the technology described herein are carried out on a single data or graphics processing platform that generates and outputs the required data, such as processed image data that is, e.g., written to a frame buffer for a display device.The technology described herein can be implemented in any suitable system, such as a suitably operable micro-processor based system. In some embodiments, the technology described herein is implemented in a computer and / or micro-processor based system.The various functions of the technology described herein can be carried out in any desired and suitable manner. For example, the functions of the technology described herein can be implemented in hardware or software, as desired. Thus, for example, the various functional elements, stages, units, and "means" of the technology described herein may comprise a suitable processor or processors, controller or controllers, functional units, circuitry, circuits, processing logic, microprocessor arrangements, etc., that are operable to perform the various functions, etc., such as appropriately dedicated hardware elements (processingcircuits / circuitry) and / or programmable hardware elements (processing circuits / circuitry) that can be programmed to operate in the desired manner.It should also be noted here that the various functions, etc., of the technology described herein may be duplicated and / or carried out in parallel on a given processor. Equally, the various processing stages may share processing circuits / circuitry, etc., if desired.Furthermore, any one or more or all of the processing stages or units of the technology described herein may be embodied as processing stage or unit circuits / circuitry, e.g., in the form of one or more fixed-function units (hardware) (processing circuits / circuitry), and / or in the form of programmable processing circuits / circuitry that can be programmed to perform the desired operation. Equally, any one or more of the processing stages or units and processing stage or unit circuits / circuitry of the technology described herein may be provided as a separate circuit element to any one or more of the other processing stages or units or processing stage or unit circuits / circuitry, and / or any one or more or all of the processing stages or units and processing stage or unit circuits / circuitry may be at least partially formed of shared processing circuit / circuitry.It will also be appreciated by those skilled in the art that all of the described embodiments of the technology described herein can include, as appropriate, any one or more or all of the features described herein.The methods in accordance with the technology described herein may be implemented at least partially using software e.g. computer programs. Thus, further embodiments of the technology described herein comprise computer software specifically adapted to carry out the methods herein described when installed on a data processor, a computer program element comprising computer software code portions for performing the methods herein described when the program element is run on a data processor, and a computer program adapted to perform all the steps of a method or of the methods herein described when the program is run on a data processing system. The data processing system may be a microprocessor, a programmable FPGA (Field Programmable Gate Array), etc.The technology described herein also extends to a computer software carrier comprising such software which when used to operate a graphics processor, renderer or other system comprising a data processor causes in conjunction with said data processor said processor, renderer or system to carry out the steps of the methods of the technology described herein. Such a computer software carriercould be a physical storage medium such as a ROM chip, CD ROM, RAM, flash memory, or disk, or could be a signal such as an electronic signal over wires, an optical signal or a radio signal such as to a satellite or the like.It will further be appreciated that not all steps of the methods of the technology described herein need be carried out by computer software and thus further embodiments of the technology described herein comprise computer software and such software installed on a computer software carrier for carrying out at least one of the steps of the methods set out herein.The technology described herein may accordingly suitably be embodied as a computer program product for use with a computer system. Such an implementation may comprise a series of computer readable instructions fixed on a tangible, non-transitory medium, such as a computer readable medium, for example, diskette, CD ROM, ROM, RAM, flash memory, or hard disk. It could also comprise a series of computer readable instructions transmittable to a computer system, via a modem or other interface device, over a tangible medium, including but not limited to optical or analogue communications lines, or intangibly using wireless techniques, including but not limited to microwave, infrared or other transmission techniques. The series of computer readable instructions embodies all or part of the functionality previously described herein.Those skilled in the art will appreciate that such computer readable instructions can be written in a number of programming languages for use with many computer architectures or operating systems. Further, such instructions may be stored using any memory technology, present or future, including but not limited to, semiconductor, magnetic, or optical, or transmitted using any communications technology, present or future, including but not limited to optical, infrared, or microwave. It is contemplated that such a computer program product may be distributed as a removable medium with accompanying printed or electronic documentation, for example, shrink wrapped software, pre-loaded with a computer system, for example, on a system ROM or fixed disk, or distributed from a server or electronic bulletin board over a network, for example, the Internet or World Wide Web.The present embodiments relate to the operation of a graphics processor, when performing “work group” processing.Figure 1 shows an exemplary system on-chip (SoC) graphics processing system 8 that comprises a host processor in the form of a central processing unit(CPU) 1 , a graphics processor (GPU) 2, a display processor 3 and a memory controller 5.As shown in Figure 1, these units communicate via an interconnect 4 and have access to off-chip memory 6. In this system, the graphics processor 2 will render frames (images) to be displayed, and the display processor 3 will then provide the frames to a display panel 7 for display.In use of this system, an application 13 such as a game, executing on the host processor (CPU) 1 will, for example, require the display of frames on the display panel 7. To do this, the application will submit appropriate commands and data to a driver 11 for the graphics processor 2 that is executing on the CPU 1. The driver 11 will then generate appropriate commands and data to cause the graphics processor 2 to render appropriate frames for display and to store those frames in appropriate frame buffers, e.g. in the main memory 6. The display processor 3 will then read those frames into a buffer for the display from where they are then read out and displayed on the display panel 7 of the display.Figure 2 shows schematically the relevant elements and components of a graphics processor (GPU) 60 of the present embodiments.As shown in Figure 2, the GPU 60 includes one or more programmable processing units (shader (processing) cores) 61, 62 together with a memory management unit 63 and a level 2 cache 64 which is operable to communicate with an off-chip memory system 68 (e.g. via an appropriate interconnect and (dynamic) memory controller).Figure 2 shows schematically the relevant configuration of one shader core 61, but as will be appreciated by those skilled in the art, any further shader cores of the graphics processor 60 will be configured in a corresponding manner.(The graphics processor (GPU) shader cores 61 , 62 are programmable processing units (circuits) that perform processing operations by running small programs for each “item” in an output to be generated such as a render target, e.g. frame. An “item” in this regard may be, e.g. a vertex, one or more sampling positions, a compute shader “work item”, etc.. The shader cores will process each “item” by means of one or more execution threads which will execute the instructions of the shader program(s) in question for the “item” in question. Typically, there will be multiple execution threads each executing at the same time (in parallel).)Figure 2 shows the main elements of the graphics processor 60 that are relevant to the operation of the present embodiments. As will be appreciated by those skilled in the art there may be other elements of the graphics processor 60 that are not illustrated in Figure 2. It should also be noted here that Figure 2 is only schematic, and that, for example, in practice the shown functional units may share significant hardware circuits, even though they are shown schematically as separate units in Figure 2. It will also be appreciated that each of the elements and units, etc., of the graphics processor as shown in Figure 2 may, unless otherwise indicated, be implemented as desired and will accordingly comprise, e.g., appropriate circuits (processing logic), etc., for performing the necessary operation and functions.As shown in Figure 2, each shader core of the graphics processor 60 includes an appropriate instruction execution unit (execution engine) 65 that is operable to execute shader programs for execution threads to perform processing operations.The shader core 61 also includes an instruction cache 66 that stores instructions to be executed by the instruction execution unit 65 to perform processing operations. The instructions to be executed will, as shown in Figure 7, be fetched from the memory system 68 via an interconnect 69 and a micro-TLB (translation lookaside buffer) 70.The shader core 61 also includes an appropriate load / store unit 76 in communication with the instruction execution unit 65, that is operable, e.g., to load into an appropriate cache, data, etc., to be processed by the instruction execution unit 65, and to write data back to the memory system 68 (for data loads and stores for programs executed in the instruction execution unit). Again, such data will be fetched / stored by the load / store unit 76 via the interconnect 69 and the micro-TLB 70.In order to perform graphics processing operations, the instruction execution unit 65 will execute graphics shader programs (sequences of instructions) for respective execution threads.Accordingly, as shown in Figure 2, the shader core 61 further comprises a warp manager 72 operable to generate execution threads for execution by the instruction execution unit 65, and to issue such threads to the instruction execution unit 65 and to control the scheduling of threads on / to the instruction unit 65, for execution.The present embodiments are particularly concerned with the operation of the graphics processor (and in particular the shader cores of the graphics processor) when processing so-called “work groups” (e.g. when performing compute shading), i.e. collections of execution threads (corresponding to respective work items) that are handled and treated as a “group” as a whole, and that are all accordingly guaranteed to exist at the same time (have the same lifetime) and are able to perform communication and synchronisation with each other. Accordingly, the warp manager 72 is correspondingly operable to generate respective work groups of execution threads (which may be made up, and executed as, plural respective “warps” of threads) and issue and schedule such work groups of threads on and to the instruction execution unit 65.To facilitate such work group operation, and in particular in order to facilitate data sharing between the threads within a work group, as shown in Figure 2, the shader core 61 also includes a shared memory unit (SMU) 74, which is in communication with the instruction execution unit (execution engine) 65 and the warp manager 72.This shared memory unit 74 is operable to provide “work group local storage” for execution threads in respective work groups, that the execution threads can read from and write to whilst the work group is being executed (while the work group is in existence), in order to allow data sharing between the threads within the work group.In particular, respective work groups can be allocated respective memory regions within the shared memory unit for use as “work group local storage” whilst the work group is executing. When a work group reaches the end of its lifetime, the work group’s “local storage” memory region in the shared memory unit 74 is deallocated, making it available for use by another work group.In the present embodiments, as shown in Figure 2, the shared memory unit that provides the work group local storage is local to and on-chip with the shader core 61. Other arrangements for this would, of course, be possible.(The allocation of regions of the shared memory unit 74 to respective work groups can be performed in any suitable and desired manner, for example in the normal manner for the graphics processor and graphics processing system in question.)Figure 3 shows the work group local storage shared memory unit 74 in more detail.As shown in Figure 3, it is assumed that the work group local storage shared memory unit 74 comprises a plurality of memory (SRAM) banks 31. Figure 3 shows four memory banks 31, but other numbers and arrangements of memory banks would, of course, be possible.As shown in Figure 3, the work group local storage shared memory unit 74 is operable to receive clear commands from the warp manager 72, and also 75 clear commands, and read and write operations, and atomic operations from the execution engine 65.As shown in Figure 3, the work group local storage shared memory unit 74 also includes a set of memory bank access control units (circuits) 32, one for each memory bank 31. As will be discussed in more detail below, these accessor units (circuits) 32 control accesses to the memory banks 31.As shown in Figure 3, each accessor unit 32 includes, in accordance with the technology described herein, a respective clear operation circuit (clear Daemon) 33. As discussed above, these clear operation circuits are configured to and controllable to write a “clear” value (such as all zeros) to respective addresses (entries) in the memory banks 31 , in the present embodiments in response to “clear” commands from the warp manager 72 or from the execution engine 65. This operation will be discussed in more detail below.Figure 4 shows the basic operation of the clear operation circuits 33 in the present embodiments. As shown in Figure 4, the clear operation will be triggered in response to receiving an appropriate clear command to the work group local storage shared memory unit, which clear command will indicate the start address and end address of the memory region to be cleared, and the clear value (such as all zeros) to be written to that memory region (step 40).In response to such a clear command, the clear operation sets its current address (which is the address next to be cleared) to the indicated start address (step 41), and then writes the clear value to that (current) address in the memory bank (step 42).The clear operation will then increment the current address by 1 (to indicate the next address to be cleared) (step 43) and then check if the end address has been reached (passed) (indicating that the clear operation has been finished) (step 44).As shown in Figure 4, when the end address has not been reached (passed), the clear operation writes the clear value to the current address, andincrements the current address by 1 , and so on, so as to incrementally work its way through, writing the clear value, to all the addresses between (and including) the start address and the end address for the region to be cleared.In the case of the present embodiments where, as shown in Figure 3, there are multiple memory banks, the clear operation for each memory bank will proceed in the manner shown in Figure 4, but with its own respective clear operation state, including a start address, end address and clear value. In this regard, while it may be the case that each memory bank has a similar set of addresses (region) to clear for a given clear operation, it may be the case that different memory banks have different configurations of region to be cleared, for example in the case where the region to be cleared is not evenly distributed across the memory banks.The clear value that is indicated in the clear command can be any suitable and desired value that should be written to all of the addresses (entries) in the indicated region to be cleared. The clear value may typically be all zeros, but need not be, and could be another “clear” value if desired. This may be useful where, for example, it is desired to pre-populate a given memory region with a value (that is not zero).As will be appreciated from Figure 4, when performing a clear operation, the clear operation keeps track of which address the clear operation has reached (and accordingly of the region that has been cleared and region that is still to be cleared for the clear operation).Figure 5 illustrates this for an exemplary memory bank 31 , and shows for example the indicated initial start address 50, end address 51 and the current “start” address 52 that the clearing operation has reached. In this example, the addresses 53 have been cleared, but the addresses 54 are still to be cleared.Figure 4 shows the clear operation when there is a clear operation being performed. As shown in Figure 3, as well as clear commands being sent to the work group local storage shared memory unit 74, the execution engine 65 can also send 75 other memory accesses to the work group local storage shared memory unit, such as reads, writes or atomic operations. Such other accesses to the work group local storage shared memory unit 74 in the present embodiments also pass via the clear operation units (the clear Daemons) 33, so that the clear operation can take account of any other work group local storage shared memory unit accesses that occur while a clear operation is in progress.Figure 6 shows a first embodiment of the operation of a respective clear operation circuit in response to a memory access.Figure 6 shows the operation for a respective memory access cycle, and will be repeated for each memory access cycle where there is an incoming memory access to the memory bank in question. In the case of a memory access cycle where there is not an incoming memory access, then the respective clear operation (i.e. writing the clear value to the “current” clear address) as shown in Figure 4 will be performed.As shown in Figure 6, in response to a memory access (whether a read, write or atomic access) being received in a given memory access cycle (step 60), the respective clear operation circuit first determines whether there is presently a clear operation in progress (step 61).If not, then the memory access can proceed in the normal manner (step 62).When there is a clear operation in progress, it is then checked whether the memory access is to a region (address) that is still to be cleared by the clear operation (step 63). This may be determined, for example, by comparing the address for the memory access to the current address and end address of the clear operation to determine whether the address for the memory access lies within the still to be “cleared” region between the current address and the end address for the clear operation.When the incoming memory access does not overlap with the uncleared region for the clear operation, then as shown in Figure 6, the clear operation is stalled (step 64) and the memory access is performed (step 62). This allows the memory access to take priority over the clear operation. The clear operation will then be resumed in the next memory access cycle (unless there is again a conflicting other memory access).On the other hand, as shown in Figure 6, when the incoming memory access is to the uncleared region, then the clear operation unit operates to stall the memory access (step 65) (so that it will not be performed), and instead the next clear operation is performed (step 66).As shown in Figure 6, in this embodiment it is assumed that if a memory access is stalled because it is to an uncleared region, then all following memory accesses (for the work group in question) are also stalled (step 65) until the initially stalled memory access has proceeded. This ensures that all memory accesses for the work group will be performed in order.As shown in Figure 6, the stalled memory access is periodically retried 67, until it is found that the address that it is accessing has been cleared, in which case that memory access can then proceed. Any following stalled memory accesses may also then be correspondingly retried.It will be appreciated that various arrangements may be used for allowing a stalled memory access to proceed. For example, the memory access could simply periodically be retried. Alternatively, a record of stalled memory accesses together with the address that they are waiting to be cleared could be maintained, with each address that is cleared then being signalled (broadcast) to that record so that it can be checked whether an address that a memory access is waiting on has been cleared.Other arrangements would, of course, be possible.As discussed above, Figure 6 shows the clear operation stalling all memory accesses after a memory access to a region still to be cleared is made. This permits the order of the memory accesses to be preserved.Figure 7 shows an alternative embodiment for handling incoming memory accesses when performing a clear operation, which facilitates performing stalled memory accesses “out of order” (and avoids having to stall all memory accesses that follow a memory access to a to be cleared region).As can be seen from Figure 7, the initial operation in response to a memory access is similar to the operation shown in Figure 6 (and so will not be described again in detail here).However, in this embodiment, as shown in Figure 7, when an incoming memory access is to part of an uncleared region (at step 63), that memory access, but only that memory access, is stalled and parked (step 70), and the next clear operation is performed (step 71).However, as shown in Figure 7, rather than stalling all memory accesses in this event, the operation proceeds with picking another memory access (if any) to try (step 72). Another memory access that is tried in this regard could be a previously parked memory access, or a new incoming memory access, as desired. As can be seen from Figure 7, if the another memory access can then be serviced (i.e. is not to a memory region still to be cleared), then it will proceed in this embodiment, such that memory accesses may proceed out of order.The parked memory accesses may be parked as desired, for example in a suitable “parking” buffer, which maintains a record of memory accesses that havebeen parked, together with, for example, the memory address that they relate to. Then, as discussed above, parked accesses can be permitted to proceed, e.g., as discussed above, by periodically retrying them, or by retrying them once the address they relate to has been cleared.A clear operation circuit could be configured to operate only in the manner of Figure 6 or only in the manner of Figure 7, or could, for example, be configured to be selectively operable either in the manner of Figure 6 or in the manner of Figure 7, as desired. In the latter case, appropriate clear operation state could be set and signalled to the clear operation circuit or circuits, for example on a work group by work group basis, so as to control the particular operation that is performed in relation to incoming memory accesses when a clear operation is in process, for example on a work group by work group basis.Other arrangements would, of course, be possible.Figure 8 shows schematically an example of handling incoming memory accesses to different memory banks in the work group local storage shared memory unit while a clear operation is proceeding in each memory bank.In the example instance shown in Figure 8, for the first memory bank 81 , it is assumed that there is, as shown in Figure 8, an incoming memory access that is to an address that has already been cleared. In this case, as shown in Figure 8, the memory access will be allowed to proceed, and no clearing will be done in the memory access cycle in question.For the second memory bank 82 it is assumed that there is a memory access to an address that is yet to be cleared by the clearing process. In this case, as shown in Figure 8, the memory access will be stored, and the clearing operation will be performed in the memory access cycle in question.For the third memory bank 83, there is no incoming memory transaction, and so the clearing operation can simply proceed as normal.Finally, for the fourth memory bank 84, it is again assumed that the incoming memory access is to a location that has been cleared, so the memory access will be allowed to proceed and no clear operation will be performed in the memory access cycle in question.In the present embodiments, the clear operation for a region of the shared memory unit 74 is triggered by the sending of an appropriate “clear” command to the shared memory unit (to the clear operation circuits 33 of the shared memoryunit). As shown in Figure 3, such clear commands in the present embodiments can be sent either by the warp manager 72 or by the execution engine 65.In the present embodiments, each clear command that is sentwill identify the appropriate memory region to be cleared, by indicating a start address and an end address (e.g. size) for the region of the memory to be cleared (as discussed above), together with the “clear” data value that is to be written to the cleared region (which may be, and typically will be, all zeros, but could be another value if desired).In the present embodiments, the warp manager 72 operates to send a clear command to trigger an appropriate clear operation when a storage region for a work group in the work group local storage shared memory unit 74 is to be de-allocated. Thus, when a local storage region for a work group is de-allocated, the clearing process is correspondingly triggered to clear the (de-allocated) storage region in question before it is de-allocated.In the present embodiments, the warp manager 72 also operates to send a clear command to trigger an appropriate clear operation when a new allocation of a storage region for a new work group is made in the work group local storage shared memory unit 74. Thus, when a new local storage region allocation for a (new) work group is made, the clearing process is correspondingly triggered to clear the (newly allocated) storage region in question before it is used by (execution threads for) the (new) work group in question.Such a clearing operation could be triggered whenever there is a local storage allocation for a new work group or the clearing process could be triggered (only) when it cannot be proven that the new work group that the local storage region is being allocated to comes from the same trust domain (as was previously using the storage region in question).In the present embodiments, the clearing process is triggered by the warp manager immediately prior to launching execution of the main work group threads, with the execution of the main work group threads being launched after the clearing process has been initiated (triggered), but without waiting for the clearing process to have been completed.Other arrangements would, of course, be possible.As well as the warp manager 72 being able to send an appropriate clear command to clear a region of the work group local storage shared memory unit 74,as discussed above and shown in Figure 3, the execution engine 65 is also able to send such clear commands.In the present embodiments, the execution engine 65 is operable to send an appropriate clear command in response to an execution thread for a work group executing a “clear-region” instruction in a (shader) program being executed. Thus in the present embodiments, (shader) programs to be executed for work groups can include an appropriate clear-region instruction or instructions, in response to which instruction the execution engine will send an appropriate clear command to the clear operation circuits 33 to perform the desired clear operation. Again, such an instruction should include, or, for example, point to, the required clear operation parameters, such as a start and end address and clear value to be used.This operation may be used, for example, to set a region of the local storage for a work group to a desired value, before being used by the work group.In the present embodiments, the instruction that is included in a shader program to trigger a clear operation can specify whether the clear operation is preceded by an instruction execution barrier or not (i.e. whether all execution threads in the work group should reach the clear operation “barrier” before the clear operation is triggered or not). For example, in the case where the shader program includes prior to the clear region instruction instructions that will access the region that is being cleared, it may be desirable to include a barrier prior to the clear operation to ensure that all required accesses to that storage region have been made before it is cleared.The pseudo code below is an example instruction sequence where such “pre-barrier” behaviour is invoked:I I Workgroup local store data shared int shared_data

[0256] ;I I Layout of workgroup: 256 threads.Iayout(local_size_x = 256, local_size_y = 1 , local_size_z = 1) in; void kernel() { int threadjndex = gl_Locallnvocationlndex; / / Perform some computation using the shared data allocation int result = perform_some_computation(shared_data); / / Invoke clear operation. / / Here there are previous accesses to the data being cleared,11 so we need s pre-barrier. invoke_clear_operation(shared_data, / / Start address256, / / Size to clear0, / / Clear to value true / / Pre-barrier enabled); / / Perform some computation using the other shared data allocation int other_result = perform_some_other_computation(shared_data);}On the other hand, where there are no previous accesses to the region being cleared (such that it does not matter if an execution thread attempts to access the region being cleared after it has been cleared), then there would be no need to include a “pre-barrier”, and in that case that need not be done (which may therefore facilitate faster triggering and completion of the clear operation).The following pseudo code correspondingly shows an example instruction sequence where the clear operation is triggered without invoking a “pre-barrier”: / / Workgroup local store data shared int shared_data

[0256] ; shared int other_shared_data

[0256] ;11 Layout of workgroup: 256 threads.Iayout(local_size_x = 256, local_size_y = 1, local_size_z = 1) in; void kernel(){ int threadjndex = gl_Locallnvocationlndex; / / Perform some computation using the shared data allocation int result = perform_some_computation(shared_data);11 Invoke clear operation. / / Here there are no previous accesses to the data being cleared, / / so we do not need the pre-barrier.c invoke_clear_operation(other_shared_data, / / Start address256, / / Size to clear 0, / / Clear to valuefalse / / Pre-barrier enabled); / / Perform some computation using the other shared data allocation int other_result = perform_some_other_computation(other_shared_data);}In the present embodiments, when a clear operation is triggered by the instruction execution circuit in response to a clear-region instruction, it may be further checked that the region that is to be cleared by the clear operation is a region of the work group local storage that belongs to the work group in question, so as to, for example, check that the clear operation is not attempting to clear a region that is outside of the trust region available to the work group (and / or a shader program) invoking the clear operation. This could be done in any suitable and desired manner, for example by performing an appropriate “bounds” check in relation to the region to be cleared. This could be done in the normal manner for the graphics processor and graphics processing system in question or performing such memory region “bounds” checks.The inclusion of a clear region instruction in a program to be executed by the programmable processing unit of the graphics processor can be performed in any suitable and desired manner.In an embodiment, such clear region instructions are included in programs to be executed by the (shader) compiler for the graphics processor.In the present embodiments, the compiler (the shader compiler) 12 for the graphics processor 60 executes on the central processing unit (CPU) 1 , host processor, of the graphics processing system (and in an embodiment as part of the driver 11 operation for the graphics processor).The compiler (driver) will receive the high level shader program or programs to be executed from the application 13 that requires the processing in question, and then compile that program or programs into appropriate shader programs for execution by the graphics processor, and, as part of this processing, will, as discussed above, include in one or more of the compiled shader programs to be executed by the graphics processor, appropriate clear-region instructions to cause the execution engine of the programmable processing unit to send a clear command to the clear operation circuits to perform the desired clear operations.The compilation process (the compiler) can use any suitable and desired compiler techniques for this.Figure 10 shows an exemplary embodiment of a compiler operation for including clear-region instructions in (shader) programs to be executed by a graphics processor.As shown in Figure 10, the compiler for the graphics processor will receive a program or programs for compiling (step 100).The compiler will then analyse the shader program code that is provided, to identify instances of work group local storage “clear” operations in that shader program code (step 101), and insert corresponding clear-region instruction(s) at the appropriate point(s) in the compiled shader program(s) (step 102).In the present embodiments, the compiler can include a clear region instruction in a program either in response to an explicit instruction to that effect in a (shader) program to be compiled, or in response to identifying program expressions that relate to and / or that require appropriate clear region operations in a program to be compiled (for example in response to identifying program expression(s) in a (shader) program provided to the compiler that are writing a same value to a region of (work group local) storage).The compiler correspondingly and in an embodiment also determines whether a “pre-barrier” should be used for a given clear operation, and configures the clear operation instruction accordingly.The compiled shader program will then be issued to the graphics processor for execution (e.g. stored in appropriate memory of and / or accessible to the graphics processor, so that the graphics processor can fetch the required shader programs for execution as required) (step 103).Figure 3 shows an arrangement in which the work group local storage shared memory unit 74 is exclusively used for and available for work group local storage for work groups executing on the execution engine 65.Figure 9 shows an alternative arrangement and embodiment, in which the work group local storage shared memory unit 90 is shared with another unit 91 that is able to make accesses to the memory banks of the shared memory unit 90.In this case, accordingly, the shared memory unit 90 also includes a set of arbiters (arbitration circuits) 92 that are operable to arbitrate between memory access requests coming from the other requester 91 and from the work group localstorage accessor units 32 (the clear operation circuits 33 of those accessor units 32).In this arrangement, the arbiters 92 can be configured to operate as desired, for example to always prioritise memory access requests from the “other” requester” 91 , or to always prioritise requests from the clear operation circuits, as desired. There could equally be multiple other requesters able to access the memory, with appropriate arbitration (priority) policies in place accordingly.In this arrangement, in the case where a higher priority request from another requester 91 is received, the clear operation or memory access from the corresponding clear operation circuit will be appropriately stalled until the other request has been serviced, and may then be resumed (and vice-versa).Although Figure 9 shows the use of arbiter circuits 92 to control access conflicts between other requesters and the clear operation circuits, it would also be possible for any access requests from other requesters to pass 93 via the clear operation circuits if desired. Again, the clear operation circuits could be configured to prioritise requests from other requesters (or not), if desired.In this case, the clear operation circuits in an embodiment handle any memory access requests from other requesters (subject to any priority ranking) in the same way as they do for other memory access requests from the execution engine, i.e. to determine whether the memory access request from another requester is to a region that is still to be cleared, and then, if so, to appropriately stall that memory access request from another requester until the region has been cleared (as discussed above in relation to Figures 6 and 7, for example).It would also or instead be possible to perform a “bounds check” on memory accesses from another requester 91, to determine whether they are being made to a region of the shared memory unit of a memory bank that has already been allocated to a particular work group (and to prevent any accesses from another requester that is to a region of a memory bank that has already been allocated to a work group), if desired. This would then avoid other memory accesses from other requesters being able to interfere with the work group local storage region. Such memory region bounds checks could be implemented in any suitable and desired manner, for example in the normal manner for the graphics processor and graphics processing system in question.It can be seen from the above, that the technology described herein, in its embodiments at least, can provide improved operations and implementation whenusing work group local storage for work groups being executed by a programmable processing unit of a graphics processor. This is achieved, in the embodiments of the technology described herein at least, by providing a clear operation circuit / process that can be, and is, controlled to write a same data value to all of a respective region of the work group local storage.The foregoing detailed description has been presented for the purposes of illustration and description. It is not intended to be exhaustive or to limit the technology to the precise form disclosed. Many modifications and variations are possible in the light of the above teaching. The described embodiments were chosen in order to best explain the principles of the technology and its practical application, to thereby enable others skilled in the art to best utilise the technology in various embodiments and with various modifications as are suited to the particular use contemplated. It is intended that the scope be defined by the claims appended hereto.

Claims

Claims1. A graphics processing system, the graphics processing system comprising: a programmable processing unit operable to execute processing programs for execution threads corresponding to work items to be processed by the graphics processing system; storage in which a storage region can be allocated for temporary use by a respective group of execution threads corresponding to a group of work items being executed by the programmable processing unit while the group of execution threads are being executed; and a clear operation circuit controllable to write a clear value to all entries of a region of the storage.

2. The system of claim 1 , wherein the storage is configured as multiple, independently accessible banks, and each storage bank has its own clear operation process that is operable independently of the clear operation process for any other bank once a clear operation has started.

3. The system of claim 1 or 2, wherein the storage is local to the programmable processing unit.

4. The system of any one of the preceding claims, wherein the control parameters for a clear operation comprise both an indication of the storage region to be written to, and an indication of the clear value to be written to that region of the storage.

5. The system of any one of the preceding claims, wherein the clear operation circuit is configured to write a clear value to a region of the storage incrementally, starting from one end of the region to be written to.

6. The system of any one of the preceding claims, wherein the system is configured to: determine whether an access to the storage for an execution thread executing on the programmable processing unit is to an entry in a region of the storage that is still to be written to by a clear operation that is in progress; andwhen it is determined that an access to the storage for an execution thread executing on the programmable processing unit is to an entry in a region of the storage that is still to be written to by a clear operation that is in progress, cause the access to the storage to be stalled at least until the clear operation has written a clear value to the entry in the region of the storage.

7. The system of any one of the preceding claims, wherein the storage is available to be used for other purposes as well as storage in which a respective storage region can be allocated for temporary use by a respective group of execution threads corresponding to a group of work items being executed by the programmable processing unit while the group of execution threads are being executed; and the system further comprises: one or more arbitration circuits configured to receive both storage access requests relating to work group storage regions, and access requests from other requester(s), and to arbitrate between those requests.

8. The system of any one of the preceding claims, wherein a clear operation is triggered prior to de-allocating a region in the storage for a work group.

9. The system of any one of the preceding claims, wherein the programmable processing unit is configured to trigger a clear operation in response to an execution thread executing an instruction in a program being executed.

10. The system of claim 9, further comprising a circuit configured to enforce a barrier prior to the triggering of a clear operation in response to an execution thread executing an instruction in a program being executed, such that all execution threads for a work group must reach the barrier before the clear operation is triggered.

11. A graphics processor, the graphics processor comprising: a programmable processing unit operable to execute processing programs for execution threads corresponding to work items to be processed by the graphics processor, the programmable processing unit comprising an instruction execution circuit configured to execute program instructions for execution threads;wherein the instruction execution circuit of the programmable processing unit is configured to, in response to executing an instruction in a program for an execution thread of a group of execution threads: send a clear command to a clear operation circuit controllable to write a clear value to all entries of a region of a storage in which a storage region can be allocated for temporary use by a respective group of execution threads corresponding to a group of work items being executed by the programmable processing unit while the group of execution threads are being executed, to cause the clear operation circuit to write a clear value to all entries of a region of the storage.

12. A graphics processor, the graphics processor comprising: a programmable processing unit operable to execute processing programs for execution threads corresponding to work items to be processed by the graphics processor; and a clear operation circuit controllable to write a clear value to all entries of a region of storage in which a storage region can be allocated for temporary use by a respective group of execution threads corresponding to a group of work items being executed by the programmable processing unit while the group of execution threads are being executed.

13. A method of operating a graphics processing system, the graphics processing system comprising: a programmable processing unit operable to execute processing programs for execution threads corresponding to work items to be processed by the graphics processing system; storage in which a storage region can be allocated for temporary use by a respective group of execution threads corresponding to a group of work items being executed by the programmable processing unit while the group of execution threads are being executed; and a clear operation circuit controllable to write a clear value to all entries of a region of the storage; the method comprising: sending a clear command to the clear operation circuit to cause the clear operation circuit to write a clear value to all entries of a region of the storage; andthe clear operation circuit, in response to the clear command, writing a clear value to all entries of the region of the storage.

14. The method of claim 13, wherein the clear command indicates both the storage region to be written to, and a clear value to be written to that region of the storage.

15. The method of any one of claims 13 to 14, wherein the clear operation circuit writes a clear value to a region of the storage incrementally, starting from one end of the region to be written to.

16. The method of any one of claims 13 to 15, further comprising: determining whether an access to the storage for an execution thread executing on the programmable processing unit is to an entry in a region of the storage that is still to be written to by a clear operation that is in progress; and when it is determined that an access to the storage for an execution thread executing on the programmable processing unit is to an entry in a region of the storage that is still to be written to by a clear operation that is in progress, causing the access to the storage to be stalled at least until the clear operation has written a clear value to the entry in the region of the storage.

17. The method of any one of claims 12 to 16, comprising sending a clear command to the clear operation circuit in response to and prior to de-allocation of a region in the storage from a work group.

18. The method of any one of claims 12 to 17, comprising: sending a clear command to the clear operation circuit in response to allocation of a region in the storage to a work group from a different trust domain; and launching execution of the main work group threads after the clearing process has been initiated, without waiting for the clearing process to have been completed before launching execution of any of the main work group threads.

19. The method of any one of claims 12 to 18, comprising sending a clear command to the clear operation circuit in response to an execution thread executing an instruction in a program being executed.

20. A method of compiling a program to be executed by a programmable processing unit operable to execute processing programs for execution threads corresponding to work items to be processed of a graphics processor, the programmable processing unit comprising an instruction execution circuit configured to execute program instructions for execution threads; the method comprising: including in a program to be executed by a programmable processing unit of a graphics processor, a clear region instruction that when executed by an instruction execution circuit of a programmable processing unit of a graphics processor, will cause the instruction execution circuit to: send a clear command to a clear operation circuit controllable to write a clear value to all entries of a region of a storage in which a storage region can be allocated for temporary use by a respective group of execution threads corresponding to a group of work items being executed by the programmable processing unit while the group of execution threads are being executed, to cause the clear operation circuit to write a clear value to all entries of a region of the storage.

21. The method of claim 20, comprising including a clear region instruction in a program in response to at least one of: an explicit instruction to that effect in a program to be compiled; and identifying program expressions that write a same value to a region of the storage.

22. The method of claim 20 or 21 , comprising associating the clear region instruction with a preceding program execution barrier, such that the clear command will only be sent once all threads in a work group have reached the barrier.

23. The method of claim 22, wherein the clear region instruction itself is used to indicate that an execution barrier should be enforced before the clear command is sent.

24. The method of any one of claims 20 to 23, further comprising not following the clear region instruction with an associated execution barrier, such that once the clear command has been sent, execution threads will be permitted to continue their execution past the clear region instruction without waiting for the clear region operation to be completed.

25. A computer program comprising computer software code for performing the method of any one of claims 12 to 24 when the program is run on one or more data processors.

Images