Graphics processing systems

Abstract

Programmable processing unit (65) executes graphics processing programs for execution threads corresponding to work items. A storage region (work group local storage) (31) can be allocated for temporary use by a respective group of threads corresponding to a group of work items being executed by the processing unit while the threads are being executed. A clear operation circuit (Clear Daemon) (33) can write (e.g. incrementally) a clear value to all entries of a storage region (which can include the region). A command can be sent from the processor to the clear circuit to write a clear value. Clear operation control parameters may 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. Access to a storage may be stalled (paused) until clear values have been written in that region. Arbitration circuits may decide between storage access requests relating to regions from execution threads or other requesters. Clear operation may be triggered before de-allocating a region for a work group, or in response to a thread executing an instruction. Enforcing a barrier may ensure all threads reach the barrier before triggering a clear operation.

Description

The present invention 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. xocessor 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. According to a first aspect of the present invention, there is provided 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 aspect of the present invention, there is provided 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; and a 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 present invention 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 present invention 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 preferably) 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 present invention, as will be slow, facilitates performing such operations in an efficient manner. The Applicants correspondingly believe therefore that the present invention 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 preferably part of a graphics processor of the graphics processing system. Thus, the system preferably 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 present invention also extends to the operation a graphics processor that can be used as part of a graphics processing system as described above. Thus, according to a further aspect of the present invention, there is provided 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 preferably does, operate in the manner of the present invention. 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). ch) programmable processing unit should, and preferably 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 preferably 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 preferably 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. An execution 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 a preferred 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 preferably configured and operable so as to facilitate such thread warp arrangements. Thus, for example, the functional units are preferably arranged as respective execution lanes, one for each thread that a thread warp may contain. The (programmable processing unit of the) graphics processor / system preferably 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 preferably 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 preferably 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). s processor / system preferably 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 preferably, 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 preferably a main memory of or available to the graphics processor / system, such as a memory that is dedicated to the 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 present invention (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 a preferred embodiment, this is done in the normal manner for the allocation of work for the graphics processor and graphics processing system in question. In a preferred 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 preferred 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 preferred 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 a particularly preferred 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 a particularly preferred 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 (preferably) operable and configured to operate independently for its respective storage bank (once started)). In this case, the clear process for each (storage) bank is preferably 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. or 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 a particularly preferred embodiment, it is storage that is local to (on-chip with) the graphics processor, and preferably local to and on-chip with the programmable processing unit of the graphics processor / system. Thus, the storage is preferably storage that provides a faster, more efficient and higher bandwidth path 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 a preferred 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 preferably does not form (is not) part of a cache hierarchy or (main) memory (system), and preferably 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 a particularly preferred embodiment, the clear operation circuit is associated with, and preferably 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 a particularly preferred embodiment, the storage, as well as comprising appropriate storage elements (e.g. memory banks), also comprises the clear operation circuit. arly preferred 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 preferably 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. Most preferably, 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 a particularly preferred embodiment, the clear operation circuit is part of a / the graphics processor (the graphics processor comprises the clear operation circuit). Thus, in a particularly preferred 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, according to a yet further aspect of the present invention, there is provided 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 aspects and embodiments of the present invention can and preferably do include any one or more or all of the preferred and optional features of the present invention 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 irt 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 a particularly preferred 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 a particularly preferred 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 be written (which is to be “cleared”). Thus, the “clear” command that triggers the clear operation preferably 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 preferably indicates a range of storage entries (a range of (memory) addresses), to be cleared, for example, and preferably, 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 preferred 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 ed 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 preferably 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 could simply 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 a particularly preferred 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 preferred 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 a preferred 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, preferably selected, and preferably predefined, value (but which value may be different for different instances of this operation, for example when being used for different work groups). •eferred 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 a preferred 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 preferably done starting from one end of the region to be cleared, and preferably from the bottom up (at the lowest entry (address) in the region), in a (progressively) increasing (or decreasing) entry (address) order. Preferably 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 preferably the clear process is configured to and operates to write to plural, and preferably 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 forthat operation. A clear operation should be, and is preferably, 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 clear value) if desired, in a particularly preferred 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 a preferred 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 a preferred 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 preferably 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 a particularly preferred 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 a particularly preferred 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 preferably, 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). arly preferred 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 a preferred 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 a preferred 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 preferably, stalling) all accesses to an (initially indicated) region to be “cleared”, until the entire region has been “cleared”. In a particularly preferred 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 preferably handled appropriately (preferably 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 preferably, allowed to proceed). the system (the clear operation circuit / process) is correspondingly preferably 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 preferably, the clear operation circuit and process) preferably keeps track of those local storage entries (addresses) that are still to be cleared, for example, and preferably, by tracking the next (the current) entry (address) to be cleared, preferably by updating (e.g., and preferably, 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 preferably, 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 preferably 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, preferably 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 preferably 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, preferably 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 preferably achieved by appropriate checking of the address (entry) to be accessed by the memory access esses (entries) that are still to be cleared (when there is a clearing process in operation). Such checking is preferably done in respect of, and for, every clear operation that is in progress at the time of the memory access. Thus, in a particularly preferred 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 the memory 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 a preferred 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 preferably, appropriately resumed and performed after the corresponding entry (address) in the local storage has been “cleared” by the clear process. 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 memory accesses (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 a particularly preferred 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 preferably done and provided on a bank-by-bank basis. In this case, the system preferably 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, >e 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 a preferred 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 appropriately stalled 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 preferably appropriately stalled until the work group request (e.g. via the clear operation circuit) has been serviced (and is preferably 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 a particularly preferred 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 preferably 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 a preferred embodiment, a (preferably hardware-based) “bounds check” is performed on memory accesses from any “another” requester, to determine ' 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 present invention can be invoked and triggered in any suitable and desired manner. As discussed above, this is preferably done by sending an appropriate “clear command” (message) to the clear operation circuit, which clear command preferably specifies (indicates) the required parameters for the clear operation. In a particularly preferred 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 a particularly preferred 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 preferably, 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 preferably performed in the normal manner for de-allocating work group local storage in the graphics processor and graphics processing system in question.) In a particularly preferred embodiment, the clear operation can also or instead (and preferably also), and preferably is, (at least) triggered (and performed) on of a storage region for a new work group is made in the (local) storage in question. Thus, in a preferred embodiment, when a new local storage region allocation for a (new) work group is made, the clearing process is correspondingly and preferably 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 preferably performed in the normal manner 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 a particularly preferred 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, preferably, correspondingly sends an appropriate “clear” command to the clear operation circuit to trigger the clearing operation). Thus, in a particularly preferred 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 'or 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 a particularly preferred embodiment, the clearing process (in these cases) is triggered before (and preferably immediately prior to launching) execution of the main work group threads. In a particularly preferred such embodiment, the clearing process (in these cases) is triggered as execution of the main work group threads is commenced (but before, and preferably immediately prior to), launching execution of the main work group threads. Correspondingly, the execution of the main work group threads is preferably launched (the main work group threads are preferably 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 present invention 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 preferred embodiment that is what is done). e 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 a particularly preferred 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. Preferably 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 preferably, in the normal manner for identifying and / or assuming trust domain changes in the graphics processor and graphics processing system in question. In a particularly preferred embodiment, it is also possible for the clear operation of the present invention to be triggered during execution of a work group. In this case, the clearing process is preferably triggered to clear some or all (and preferably 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 present invention during work group execution would facilitate such operation. ing of the clearing process during work group execution can be achieved in any suitable and desired manner. In a particularly preferred 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 preferably is, at least, operable to trigger the clear process when executed, and should, and preferably 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 preferably the instruction execution circuit (execution engine) (that is executing the instructions for the execution threads) of the programmable processing unit) is preferably 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 a particularly preferred embodiment, there is an appropriate communication path between the programmable processing unit (and preferably 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, according to another aspect of the present invention there is provided 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; hich 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. According to a yet further aspect of the present invention there is provided 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 aspects and embodiments of the present invention can, and preferably do, include any one or more or all of the preferred and optional features of the invention described herein, as appropriate. ample, the clear command that is sent to trigger the clear operation preferably 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 preferably 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 by the instruction. Such a bounds check is preferably 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 preferably 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 preferably 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 preferably 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 preferred 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 y 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, preferably selected, preferably 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 preferred 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 work group 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 preferably operates in the normal manner for the graphics processor and graphics processing system in question (e.g., and preferably, 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 a particularly preferred 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 preferably (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 ave 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 operation of 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 a particularly preferred embodiment, where a clear-region instruction is used to trigger a clear operation in the manner of the present invention, 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 a particularly preferred 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 Dgram). This may be done, for example, as a modifier on the clear region instruction. Thus, in a particularly preferred 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 a particularly preferred 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 preferably 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 a particularly preferred 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 a preferred 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, according to a further aspect of the present invention, there is provided 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 ruction 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 aspects and embodiments of the present invention can, and preferably do, include any one or more or all of the preferred and optional features of the invention 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 a preferred embodiment, the compiler can (and does) include a clear region instruction of the present invention in a program in response to an explicit instruction to that effect in a (shader) program to be compiled. In a preferred embodiment, the compiler additionally or alternatively (and preferably additionally) can (and does) include a clear region instruction of the present invention 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 present invention 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 preferably, by providing an API extension that includes one or more specific program expressions for clear region operations in the manner of the present invention (such that an application program can include a specific program expression when a clear region operation in the manner of the present invention is desired). In this case, the appropriate (shader) compiler should be operable to recognise the specific clear region operation i(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 present invention. In a preferred embodiment, clear region instructions in the form of the present invention can be, and preferably 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 preferably, 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 present invention). In this case, the clear region instructions in the manner of the present invention may not be directly exposed to an application programmer, but the compiler will be, and is preferably, 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 preferably 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 present invention. The compiler can operate as desired, e.g., and preferably, as part of the driver for the graphics processor that is, e.g., and preferably, 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.. s 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 renderer (preferably 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 vertex shading 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 present invention 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 present invention 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 present invention 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. invention can be implemented in any suitable system, such as a suitably operable micro-processor based system. In some embodiments, the present invention is implemented in a computer and / or micro-processor based system. The various functions of the present invention can be carried out in any desired and suitable manner. For example, the functions of the present invention can be implemented in hardware or software, as desired. Thus, for example, the various functional elements, stages, units, and "means" of the present invention 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 (processing circuits / 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 present invention 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 present invention 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 present invention 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 present invention can include, as appropriate, any one or more or all of the optional features described herein. The methods in accordance with the present invention may be implemented at least partially using software e.g. computer programs. Thus, further embodiments of the present invention comprise computer software specifically adapted to carry rein described when installed on data processing means, a computer program element comprising computer software code portions for performing the methods herein described when the program element is run on data processing means, and a computer program comprising code means 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 present invention also extends to a computer software carrier comprising such software which when used to operate a graphics processor, renderer or other system comprising data processing means causes in conjunction with said data processing means said processor, renderer or system to carry out the steps of the methods of the present invention. Such a computer software carrier could 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 present invention need be carried out by computer software and thus further embodiments of the present invention 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 present invention 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 nagnetic, 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, shrinkwrapped 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. Embodiments of the present invention 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 present invention; Figure 3 shows the work group local storage shared memory in an embodiment of the present invention in more detail; Figure 4 shows the clear operation in an embodiment of the present invention; Figure 5 shows an example of a memory region being cleared in an embodiment of the present invention; 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 present invention; Figure 9 shows another embodiment of the work group local storage shared memory unit; and Figure 10 shows an embodiment of a shader program compilation process in an embodiment of the present invention. Like reference numerals are used for like elements in the Figures where appropriate. 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 ; 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).) >ws 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. 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. 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 present invention, 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, and ent 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. >ws 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. 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 have ler 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 memory -igure 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 sent will 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, ; 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: II Workgroup local store data shared int shared_data

[256] ; II 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; II Perform some computation using the shared data allocation int result = perform_some_computation(shared_data); / / Invoke clear operation. sre are previous accesses to the data being cleared, / / so we need s pre-barrier. invoke_clear_operation(shared_data, / / Start address 256, / / Size to clear 0, / / Clear to value true II 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”: II Workgroup local store data shared int shared_data

[256] ; shared int other_shared_data

[256] ; II Layout of workgroup: 256 threads. Iayout(local_size_x = 256, local_size_y = 1, local_size_z = 1) in; void kernel() { int thread_index = gl_Locallnvocationlndex; / / Perform some computation using the shared data allocation int result = perform_some_computation(shared_data); / / 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 address 256, / / Size to clear 0, / / Clear to value false II 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 a preferred 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. tion 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 preferably 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 local nits 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 preferably 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 present invention, in its preferred embodiments at least, can provide improved operations and implementation when cal storage for work groups being executed by a programmable processing unit of a graphics processor. This is achieved, in the preferred embodiments of the present invention 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 5 respective region of the work group local storage.

Claims

1. 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; anda 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; anda 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; anda 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; 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, 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; andlaunching 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.5 24. The method of any one of claims 20 to 23, further comprising not followingthe 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.1025. 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 data processing means.

Images