GR20180200014U - Discarding of threads processed by a warp processing unit - Google Patents

Abstract

A warp processing unit controls, in dependence on a warp program counter shared between a plurality of threads processing respective graphics fragments, fetching of a next instruction to be executed for at least some of the plurality of threads. In response to a determination that a given subset of threads is to be discarded when at least one other subset of threads is to continue, the warp processing unit processes the given subset of threads in a discarded state. For a thread processed in the discarded state, execution of instructions continues for the discarded thread, and at least one of: generation of data access messages triggered by the discarded thread is suppressed; and at least one processing operation, which would be deferred until completion of the discarded thread had the thread not been discarded, is enabled to be commenced independently of an outcome of the discarded thread.

Description

DROP THREADS PROCESSED BY A PROCESSING UNIT

WARP

The present technique relates to the field of graphics processing.

A graphics processing arrangement may require a number of processing threads to run on respective graphics sections. For example each thread can be a shader thread that performs shader processing on a portion of graphics to be drawn at a given pixel position within the image frame to be rendered. Some graphics processors may have a warp processing unit, which processes a number of threads depending on a warp program counter, which is shared by the threads, by providing a next command to execute for at least some of those threads which are controlled based on the warp program counter. Since processing threads for nearby pixel locations may be similar and may require the same operations to be applied to different data inputs, controlling the execution of instructions based on a shared program counter can be efficient as it allows the overhead of fetching and decoding commands among the batch of threads as a whole.

At least some examples provide a graphics processing arrangement that includes:

a warp processing unit for processing a plurality of processing threads into corresponding graphics sections;

wherein the warp processing unit is configured to control, in dependence on a warp program counter shared among the plurality of threads, the presentation of a next command to be executed for at least some of the plurality of threads;

the warp processing unit includes registers to store architectural state data for the number of threads;

in response to a determination that a given subset of threads is to be discarded when at least one other subset of threads from the plurality of threads is to continue, the warp processing unit is configured to process the given subset of threads into a discarding state, and for a processed thread in the abort state, the warp processor is configured to continue executing commands for the aborted thread, and at least one of the following:

the warp processor is configured to suppress the generation of data access messages triggered by the discarded thread, said data access messages including messages requesting access to data other than said architecture state data stored in its registers warp processing unit, and

the graphics processor is configured to allow at least one processing operation, which would delay until completion of the discarded thread if the thread had not been discarded, to be initiated independently of a result of the discarded thread.

At least some examples provide a graphics processing arrangement that includes:

processing means of a plurality of processing threads in respective graphics sections;

wherein the processing means is configured to control, in dependence on a warp program counter shared among the plurality of threads, the presentation of a next instruction to be executed for at least some of the plurality of threads;

the processing means includes means for storing architectural state data for the plurality of threads;

in response to a determination that a given subset of threads is to be discarded when at least one other subset of threads from the plurality of threads is to continue, the processing means is configured to process the given subset of threads in a discarded state, and

for an aborted thread in the aborted state, the processing means are configured to continue executing commands for the aborted thread and at least one of the following:

the processing means is configured to suppress the generation of data access messages triggered by the aborted thread, said data access messages including messages requesting access to data other than said architecture state data stored in means for storing processing media, and

the graphics processor is configured to allow at least one processing operation, which would be delayed until completion of the aborted thread if the thread had not been aborted, to start regardless of an outcome of the aborted thread.

At least some examples provide a method of processing graphics, which includes:

processing a plurality of processing threads in respective graphics sections using a warp processing unit configured to control, in dependence on a warp program counter shared among the plurality of threads, providing a subsequent command to be executed for at least some threads by the plurality of threads, the warp processing unit including registers for storing architectural state data for the plurality of threads, and

in response to a determination that a given subset of threads is to be discarded when at least one other subset of threads from the plurality of threads is to continue, the warp processing unit to process the given subset of threads in a discarded state;

where for a dropped thread in the dropped state, the warp processor continues executing commands for the dropped thread, and at least one of the following:

the warp processor suppresses the generation of data access messages triggered by the rejected thread, said data access messages including messages requesting access to data other than said architecture state data stored in the warp processor registers; and

at least one processing operation, which would delay until the aborted thread's completion if the thread had not been aborted, is allowed to start regardless of an outcome of the aborted thread.

Further issues, features and advantages of the present technique will become apparent from the following description of the examples, which should be read in conjunction with the accompanying drawings, in which:

Figure 1 schematically illustrates an example of a graphics processing pipeline for processing graphics fundamentals for display,

Figure 2 shows an example rendering on graphics fundamentals tiles,

Figure 3 shows an example of creating rasters to create graphics parts that correspond to graphics fundamentals,

Figure 4 illustrates an example in which a processing thread for a particular graphics part may be discarded because the graphics part does not contribute to the final frame rendered because it is hidden by another graphics part,

Figure 5 illustrates an example of a portion of a shader core for implementing shader processing threads, the shader core including at least one warp processing unit,

Figure 6 schematically illustrates an example of a shading kernel warp processing unit,

Figure 7 illustrates an example of multiple thread execution in a warp controlled by a warp program counter in the warp processing unit, Figures 8 and 9 show two examples of divergence between threads of the same warp,

Figure 10 shows an example clause execution from the warp processor,

Figure 11 shows an example of different yarn states for yarns processed by the yarn processing unit, and

Figure 12 is a flow chart showing a method of checking the state of threads depending on whether the threads need to be discarded.

Sometimes, after a number of threads have started processing a warp in the warp processing unit, it may be determined that some threads may be discarded, for example because the corresponding graphics sections may not contribute to the final rendered image. When only some warp threads are to be discarded and other threads are to continue processing, then due to the reliance on the common warp program counter to control command rendering, it is possible to assign different threads to the warp processing unit sections which previously processed the discarded yarns. So, in general, warp execution can continue. Although some implementations may have the ability to suppress command execution for parts of the warp processor that correspond to discarded threads, it may not always be immediately practical to do so if this functionality is provided.

The present technique provides a discard state for yarns processed by the warp processing unit, which may be used for a subset of yarns to be discarded when at least one other subset of yarns in the warp is to continue. When a thread is processing in the aborted state, execution of commands for the aborted thread may continue, but at least one of the following actions may occur. In one case, the warp processing unit may suppress the generation of data access messages triggered by the discarded thread. These data access messages may include messages that request access to data other than architecture state data stored in warp processor registers. Therefore, even if instruction execution continues for the discarded threads, by suppressing the generation of data access messages, bandwidth to access the storage units that store this non-architectural data can be saved for other operations or threads, and the energy spent on redundant access to this other data can be saved. In another option, for a thread processing the aborted state the graphics processor may allow at least one processing operation, which would delay until the aborted thread's completion if the threads had not been aborted, to continue regardless of an outcome of the aborted thread. Therefore, although the execution of instructions on the discarded thread continues, a subsequent operation, which would normally have to wait until the discarded thread has completed, can start without waiting for the discarded thread to complete, to improve the performance of these other functions. In some implementations, only one of the options of suppressing message generation or initiating other processing operations could be implemented. Other implementations may provide both of these improvements for the discarded thread. Therefore, in general even if it is not possible to suppress the execution of the instructions themselves for the aborted thread, there are still performance improvements and/or energy savings that can be achieved by suppressing effects that the thread might otherwise have has in operations performed outside the warp processing unit. This can result in a performance improvement for the graphics editor as a whole.

Some implementations may allow threads to be placed in the discard state at any resolution, for example by allowing each individual thread to be independently placed in the discard state or transitioned out of the discard state.

However, in practice the burden associated with individual thread disposal may not be justified. In some cases the threads processed by the warp processing unit using the shared warp program counter may include at least two thread groups. The warp processing unit can prevent a thread in a given group from switching from a non-discarding state to a partially discarding state by executing that thread when at least one other thread in the given group continues in a non-discarding state. Therefore, the transition of threads to the discard state could be controlled per thread group, rather than per individual thread.

Thread groups could vary in size. However, a particularly useful implementation may be one in which each thread group includes four threads that correspond to a 2-by-2 grid of graphics segments (ie, four segments that correspond to a pixel array 2 pixels high and 2 pixels wide). It is common for plots to be grouped into boxes so that the differences between values associated with plots in the same box can be calculated to calculate derivatives which can be useful for testing the performance of gradients for example . Therefore, in practice even if it is required to drop a thread corresponding to a given square, it may not be worth dropping that thread unless all other active threads in the same square also need to be dropped, because if the other threads in the same box are still active then they may rely on values provided by associated threads in the same box. Therefore, in some cases each thread group includes a thread block.

In one example, in response to a determination that all yarns of a given group are to be discarded while yarns of at least one other group processed by the same warp processing unit are to continue, the warp processing unit may switch the yarns of the given group from the no rejection state to the rejection state.

However, sometimes the warp processor may also transition threads to the discard state even if all the threads in the group are to be discarded. For example, it may sometimes have been determined from the start that a certain thread is not required in a block and therefore the warp processor could start with some threads inactive from the start. In this case, it is not necessary to drop the threads that were always inactive to justify dropping the other active threads as well.

The warp processor may maintain an active mask indicative of the threads that are active and about to execute the next instruction rendering depending on the warp counter. The warp processing unit may also maintain a pending mask which indicates threads which were previously active but are now inactive due to the deviation between the control flow followed by the corresponding warp threads. The pending mask can be used to distinguish between threads that have been inactive since the warp processing authority and threads that have become inactive due to a deviation in the control flow followed by the corresponding threads.

Therefore, in some cases if it is determined that all active threads for a given group (eg square) are to be dropped, the pending mask indicates that there are no pending threads for the given group and that at least one group's threads are to continue , then the warp processing unit can transition all active threads of the given group from the non-discarding state to the discarding state. This allows the discard state to be used when some threads have been inactive since warp processing started.

The technique discussed above can be particularly useful in cases where the warp processor responds to command clauses within a common program executed for the thread in the warp, so that each command clause is executed as a cascade of commands with sequential control flow. The warp processor can restrict non-consecutive changes of control flow to the boundaries between clauses. This approach can be useful in reducing the overhead of determining the control flow for the warp because it means that comparisons of individual thread counters to determine the next warp counter to use can be limited to the boundaries between clauses and not be performed after each command. In practice, for many graphics processing routines, the size of the key steps between successive conditional branches can be relatively large to achieve significant energy savings by using clauses, where once a clause is entered then the statements are executed sequentially until end of clause and cannot branch to a non-consecutive command in the middle of a clause.

When the warp processor supports such clause-based execution, the warp processor may not be able to update an active mask partially through the processing of a given clause, where the active mask as discussed above indicates the active threads which are to execute the next command served depending on the warp program counter. That is, as the program flow continues sequentially within each clause, the conditional branch statements would be placed at the clause boundary and therefore within a clause there would be no change in thread grouping since it is not possible for threads to diverge from each other within a clause. clause. Therefore, it is possible to reduce the overhead by preventing updates to the active mask that indicates the current grouping of threads converging in the middle of the clause. Since it is not possible to update the active mask partially in a clause, then this also means that it may not be possible to suppress command execution itself partially in a clause, even if it is partially specified in the clause that the thread should be dropped. In such an implementation, the technique of providing the abort state as discussed above, which allows instructions to continue executing but suppressing some of the thread's effects on other threads, can be particularly useful. As some clauses can be relatively lengthy, in the absence of such an abort state the aborted thread may continue to generate messages that result in access to memory or temporary memories outside the warp processor for some time after determining that thread is not required, which would waste energy and may impact the execution of other threads as well. Similarly, in cases where a dropped thread might allow a subsequent dependent operation to continue, this makes it possible to improve performance for such dependent operations. Therefore, by switching a thread from a non-dismissing (active) state to a partially-dismissing state while processing the given clause, performance can be improved.

When a given thread transitions from the non-discarding state to the discarding state partway through processing the given clause, then once the given clause is finished processing, the warp processing unit can then transition the given thread to a terminal state. For threads in the terminal state, the warp processor may suppress execution of the command.

For example, transitioning the thread to the terminal state may correspond to zeroing the bits in the active mask so that commands will not be executed for that thread by the warp processing unit in subsequent clauses. Therefore, the dump state can be used between the point at which the thread was specified to dump and the end of the current clause, which in some shaders could be a relatively long time.

The drop state can be used in cases where the threads of a given group or block are determined to be dropped, but at least one other group or block must still continue. On the other hand, in cases where all threads processed by the warp processing unit are to be discarded (including all groups or squares), then the warp processing unit can simply stop processing the warp threads part way through processing a current clause. In this case it would not be necessary to wait until the end of the clause, because there are no threads that still need to execute commands.

The discard state may also be used for some threads other than those identified as requiring discard after warp has already started processing them. For example, a helper thread may be processing in the discard state from the beginning of the helper thread's processing. Sometimes the warp processing unit may be assigned to process certain helper threads that in practice do not correspond to an actual piece of graphics that will end up contributing to the rendering of the rendered image frame, but are instead processed to provide data values that they can be used by other threads that actually correspond to the actual graphics sections. For example, such helper threads can be used in situations where a raster generation software maps a graphic element to a number of graphics segments but the boundary of the underlying element passes through a particular box so that at least some of the segments for the box on the boundary of the fundamental element are outside the boundary of the fundamental element and therefore do not need to be drawn. However, in order to be able to calculate the derivatives for those threads which correspond to segments inside the fundamental element boundary, auxiliary threads can still be issued for those parts of the square which are outside the fundamental element boundary. These helper threads can run in the discard state from the start of helper thread processing, so that the helper thread does not produce messages, or other threads at the same pixel location can issue without waiting for the helper thread to complete.

There can be a number of reasons why the warp processor may determine that a given thread is to be discarded. In one example, the warp processor may determine that a thread is to be discarded in response to a termination signal indicating that the graphics segment would be hidden in the rendered image by another graphics segment processed by the layout. For example, the termination signal may be received from a pixel termination front-end stage that is earlier in the graphics processing pipeline than the warp processing unit, while the termination signal may be produced in cases where the termination front-end stage has determined that a segment that fetched later will hide the earlier fetched part which is currently being processed by the given warp processor thread. By suppressing unnecessary processing operations for the hidden parts that would not contribute to the rendered image, the computational workload of the graphics processing pipeline as a whole can be reduced and thus performance improved.

Also, in some cases a processing thread performed by the warp processing unit may itself determine that it needs to be discarded. For example, sometimes based on the depth value for a given thread, it may be determined that a certain portion of the thread corresponds to a completely transparent pixel, and therefore in that case that portion could be discarded. Therefore, sometimes the shader running for each thread of the warp may have some conditional functions which if executed may include a drop command which means that the corresponding thread should be dropped. Therefore, when the warp processor encounters a discard command within an active thread then it can determine that the corresponding thread should be discarded. Depending on whether the other threads in the same block or group are also to be discarded the warp processor can determine whether to put the discarded yarn into the discard state.

Data access messages that are suppressed in some examples for threads in the discard state may include requests to load data from or save data to a storage location outside of the warp processor. For example, the storage location could include a tile cache or a frame cache that stores previously calculated pixel values for at least a portion of a rendered image frame, a depth buffer for storing depth values for the pixels at least one portion of the rendered image frame, a texture cache that stores texture data that references processing threads performed by the warp processing unit, and/or a feature data store for storing features computed for a given graphics portion before issuing a corresponding processing thread to the warp processing unit. For example these attributes could specify parameters such as pixel position, color, depth, transparency or opacity, etc.

In examples that allow at least one other processing operation to continue without waiting for the result of a discarded thread, that other operation may be any operation performed within the graphics processor that depends on a result of the discarded thread or is blocked continue until the discarded thread completes. In some cases, the at least one processing operation may include another processing thread that is executed for another graphics segment that corresponds to the same location in the rendered image as the graphics segment for the thread in the discard state. For example, to ensure that subsequent operations, such as alpha blending or depth testing, examine each corresponding segment for the same pixel position in turn, the scheduler that allocates processing threads to the module warp processing or in other warp processing units within a shader core may delay issuing threads for a given pixel location until every previous thread for the same location has already completed. When a thread is in the discard state it is not necessary to wait for that thread to complete, and the other processing thread for a different graphics segment at the same location can be issued to execute in its place. Specifically, in cases where thread rejection is handled per group or tile as discussed above, then a different tile may be allowed to be issued for the same pixel location for earlier thread processing.

Although some implementations could provide a single warp processing unit, in some cases the arrangement may include two or more separate warp processing units, each of which has a separate warp program counter. Therefore, threads processing within the same warp use a common warp program counter and thus the rendering and decoding of instructions is shared between the corresponding warp threads, but threads in one warp processing unit can execute independently of threads in another warp processing unit, with different warp program counters controlling parallel rendering and decoding of different commands for respective warps.

Figure 1 illustrates an example of a graphics processing pipeline 2 for processing graphics fundamentals for displaying a frame of image data. Geometry data 4 that defines a number of basic graphics elements to be drawn on the rendered image is inserted into the pipeline. Foundation elements can correspond to triangles or other polygons to be drawn, for example. The geometry input can specify coordinates of the vertices of each foundation element, and could also specify other properties of the foundation element, such as a color, transparency, or depth associated with a given vertex.

A tiling stage 6 takes the geometry input and assigns each ground element to one or more tiles within the frame to be rendered. As shown in Figure 2, the frame 8 can be divided into a grid of smaller tiles 10 of a certain size (eg 16 x 16 pixels or 32 x 32 pixels). Some foundation elements 11 may span more than one tile and thus may be assigned to more than one tile by the tiling step 6. It is not necessary for the tiles to be square, and in some examples rectangular tiles could be used. The remaining stages of pipeline 2 use tile-based rendering, in which pixel drawing operations on a given tile are completed before moving to the next image tile. Therefore, the tiling stage 6 is repeated on each successive tile of the frame 8, for each tile that sends information on the set of fundamentals to be drawn on that tile to the arranging stage of fundamentals 12 and which moves to the next tile once all the fundamentals have been sent. elements of the previous tile, while continuing to iterate until all tiles in the frame are complete, at which point geometry input 4 can be obtained and processed for a subsequent frame.

The core arrangement stage 12 performs various core arrangement operations on the group of cores assigned to a given tile. For example, foundation arrangement functions may specify additional foundation properties that are not clearly indicated by the geometry data. For example, the foundation element arrangement step 12 may derive one or more edge functions that represent the locations of edges connecting the respective vertices of the foundation elements, a depth function that represents the variation of depth along the foundation element, or a interpolation function which represents the variation of properties such as color, shading, or transparency/opacity values along the underlying element. The properties determined by the foundation arrangement storage step 12 may be stored in a property store 13.

As shown in Figure 3, the primitives 11 are passed to a raster generation software stage 14 which converts the vertices and any additional primitive arrangement information for a given primitive into graphics segments 15 representing properties (x-y position, depth, color, transparency/opacity, etc.) of corresponding pixels of the area occupied by the underlying element. In the embodiment discussed below, the segments generated by the raster generation software 14 are processed by some downstream stages (eg, the shading stage 26) into units of 2x2 pixel gradients called squares 16 (with the processing occurring in parallel for each section in the same square). However, this is not necessary and other implementations could process each segment individually or in groups of different number of segments. If a square intersects a foundation element boundary, then in addition to the conventional processing threads performed for segments within the boundary, the pipeliner may also perform auxiliary threads for segment locations 15' outside the boundary that will not end up being drawn, but they are used as an aid in the calculations of other parts of the same square which are within the limit of fundamental elements.

As shown in Figure 4, different fundamentals associated with different depth values may include opaque segments 15 or squares 16 at the same x-y position so that only the most forward segment or square is visible in the final image. Segments generated by the raster generation software 14 are subject to an early depth test stage 18 which tests whether the depth associated with a later captured segment is such that the later segment will be obscured by an earlier segment that has already been drawn in tile caches 20 to store the latest pixel values of the scene being rendered. Tile caches 20 may include one cache per tile, and each tile may include a number of records each corresponding to a pixel of that tile. The pipeline may maintain a Z stencil buffer 22 which stores, on a per-pixel basis, a Z-depth value indicating the depth of the frontmost portion assigned to a given pixel location so far in the current tile. Accordingly, the early depth test stage 18 may compare the depth associated with a last received segment with the depth indicated for a corresponding pixel coordinate in the Z stencil buffer 22 and suppress processing of the received segment when it is determined that the depth location of the subsequently obtained part is behind the depth position of the already drawn part whose depth is represented in the Z stencil buffer 22.

The early depth test stage 18 helps to eliminate segment processing in cases where the most forward segment at a given pixel location is obtained before the most posterior segment and therefore processing of the later received segment may be inhibited because it will be obscured by an already designed section. However, it is also possible for the rearmost part to be taken before the frontmost part. Therefore, segments that pass the early depth test stage 18 are provided to a forward pixel kill (FPK) stage 24 which identifies cases in which an earlier received segment would be obscured by a later received segment. Upon receiving a given segment (a later received segment), the FPK step 24 tests whether an earlier received segment still pending at the FPK stage 24 or a later segment of the pipeline 2 would be hidden by the given later received segment. In this case, the FPK stage 24 generates a termination request which requests the suppression of further processing of the earlier received segment, to avoid consuming further processing resources to process a segment that would not contribute to the final image.

Segments that are not terminated by the FPK stage 24 are passed to a segment shading stage 26 which includes a thread processing circuit for performing segment shading processing threads for each segment. For example, the part shader can access texture data stored in a texture buffer 27 that defines functions representing a pattern or texture to render within a given underlying element and can use it to determine the exact color to assign to a given pixel (the colors initially assigned by the fundamental and rasterization stages 12, 14 may be initial values for the shader threads). The segment shader stage may execute in parallel a number of processing threads corresponding to corresponding segments of the same tile 16. The segment shader core may also have resources for parallel processing of multiple tiles 16. Segment shading execution is relatively processor intensive and so it may be useful for the FPK stage 24 to have the ability to suppress a target thread from performing segment shading if it is found that a later fetched segment will obscure the earlier segment corresponding to the target thread. The segment shading kernel 26 is described in more detail below.

The shaded portions are provided to a late depth test stage 28 which tests whether the depth associated with the shaded portion is such that the portion is obscured by an already rendered portion as indicated by the depth in the Z stencil buffer 22. The late depth test stage 28 is provided because there are some segments for which the depth value may not be available in time for the early depth test stage 18 or for which the depth may change when segment shading is performed. Late depth testing also allows for the detection of overdesigned sections in cases where, by the time the downstream section is at the early depth test stage 18, the earlier section that would conceal that downstream section is still pending in the pipeline and has not still update the Z stencil cache 22 (but will do so until the later part reaches the late depth test stage 28). Also, the late depth test stage 28 allows handling of transparent objects whose transparency can only become apparent when performing part shading. If any segments are found by the late stage of depth testing 28 to be hidden by already drawn segments, they are suppressed and prevented from being drawn on the corresponding tile. The remaining segments are passed to a blending stage 30 which performs blending to blend the properties of the transparent segments with the next most forward segments at corresponding pixel positions and writes the resulting pixel values to corresponding entries of a currently active tile buffer. For opaque objects, the blending stage 30 may simply replace the previous pixel values in the tile buffer. When all segments for a tile have been processed, processing moves to the next tile represented by a different tile buffer.

Although Figure 1 shows an example that uses tile-based rendering, which can be beneficial in reducing the required cache capacity and memory bandwidth, other examples may use on-the-fly rendering, in which the fundamentals for the entire frame are passed down the pipeline in any order without first being grouped into tiles. Although Figure 1 shows various temporary memories 13, 22, 27, 20 implemented as storage units in pipeline 2, in practice these may be implemented as storage structures accessed from memory by general purpose load/store commands. Writes of cache structures can be cached locally in pipeline 2. Using tile-based rendering can help improve caching performance since grouping processing pixels of a given tile together increases the chance the required cache data should be in the cache since it is more likely that neighboring pixels will need similar data.

The segment shader stage 26 includes one or more shader cores that implement threads of segment shader execution. Figure 5 shows a section of a shading core. It will be appreciated that Figure 5 is highly simplified and in practice the shader core may have many other elements not shown in Figure 5. Each shader core may include a number of warp processing units 40 and a warp manager 42. Each warp processing unit 40 may process a number of segment shader execution threads as a warp under the control of a shared warp program counter 44. In the example of Figure 5, each warp processor 40 processes eight threads, corresponding to two squares 16, but other examples will could process a larger number of squares within the same warp. Within a warp 40, threads process according to a single instruction multiple thread (SIMT) model in which the execution of a common program by a number of threads acting on different data inputs is controlled based on a single shared program counter warp 44. The warp manager 42 controls the scheduling of specific block threads to the respective warp processing units 40.

Figure 6 shows an example of a warp processing unit 40 in greater detail. The warp processing unit 40 includes a number of execution pipelines 50, one for each thread of the warp. Therefore, in this example since two blocks are processed by the warp there are eight execution pipelines 50. Each execution pipeline 50 has access to a corresponding set of thread states 52 stored in architecture state registers 54. Each execution pipeline 50 executes commands from a common shader program , but using different data inputs as defined by thread state 52. Common command rendering/decoding logic 56 is provided and shared by respective warp execution units 50 so that in each cycle the same command is issued for parallel execution to at least one subset of the yarn execution pipelines 50 (therefore different commands cannot be issued to the execution pipeline 50 of the same warp 76 in the same cycle). Warp program counter 44 represents the instruction address of the current execution point in the shared program accessed by the warp as a whole and controls fetch logic 56 to fetch the instruction indicated by warp program counter 44. Each thread state includes a corresponding thread program counter 58 which represents the next instruction to be executed by the respective execution unit 50 for the respective thread. Each thread program counter 58 is incremented (or updated non-sequentially in the case of a branch) based on the result of the corresponding thread's processing. A program counter polling logic 72 is provided for selecting, based on the individual thread program counters 58 for each warp thread, the value to be set in the global warp program counter 44 which controls which command is served in the next cycle.

This type of processing can be referred to as single instruction multiple thread (SIMT) processing. Since corresponding pixels in a box are likely to have similar input values, they are likely to follow similar paths through the thread shader, and therefore it can be effective to control the execution of corresponding threads using SIMT to reduce the overhead of presenting/decoding the commands. Similarly, neighboring squares are more likely to follow similar paths than squares further apart, so by scheduling threads for neighboring squares on the same warp, processing efficiency can be improved.

Figure 7 shows an example of executing a simple sequence of commands using SIMT processing for a warp comprising 4 threads. For the sake of brevity, 4 threads are shown, but it will be appreciated that other numbers of threads (e.g.

8 in the example of Figure 6) could also be processed in a SIMT fashion. A common sequence of instructions is executed synchronously by each thread of the warp (group of threads). Warp program counter 44 indicates the address of the current instruction being processed by warp as a whole. The warp program counter 44 is derived from the thread program counters 58 (tPCO-tPC3) of the individual threads in the warp (for example, by polling program counters). For example, the warp program counter 44 may correspond to the smallest address indicated by any thread program counter 58 for the group of threads processing in the warp. For each thread within the group, the command indicated by the warp program counter 44 is executed in the current processing cycle if the thread program counter 58 for that thread matches the warp program counter 44. If the thread program counter 58 for a given thread does not match warp program counter 44, the corresponding warp execution unit 50 is idle for one cycle (although it will be appreciated that instruction execution from each warp execution unit 50 may be piped so that when a portion of an execution unit 50 is idle, the other stages may nevertheless perform functions related to an instruction issued in an earlier or a later cycle).

Therefore, in the example of Figure 7:

• In cycle 0, warp program counter 44 points to address #add and all thread program counters 58 for threads 0 through 3 also point to address #add. Therefore, all threads execute the ADD command at address #add. Different threads may execute the ADD instruction using different operators so that a number of different additions are performed in parallel for the respective threads.

· In cycle 1 , a CMP comparison instruction is executed at address #add+4 to compare the r2 result of the ADD instruction with an immediate value of 19. For threads 0, 1, and 3, the r2 result was not equal to 19, while for thread 2 the result τ2 was equal to 19.

• In cycle 2, a BNE branch instruction is moved to address #add+16 if the result of the CMP instruction in cycle 1 was not equal (NE). For threads 0, 1, and 3, the branch is followed, so the thread program counters 58 for these threads are set to #add+16. However, for thread 2 the result of the CMP instruction was equal (EQ) and therefore the branch is not followed and the thread program counter 58 for thread 2 is incremented to #add+12. Therefore, there are now threads with different values of thread program counter 58 and there is different behavior between threads.

• In cycle 3, the warp program counter 44 is set to #add+12 to match the lowest of the thread program counters 58 (in this case, the thread program counter for thread 2). For thread 2, the MUL multiply instruction at address #add+12 is executed. However, no instruction is executed in cycle 3 for threads 0, 1, and 3 because the thread program counters 58 for these threads do not match the warp program counter 44. These threads wait until the warp program counter 58 reaches # add+16 before they continue executing the command.

• In cycle 4, the warp program counter 44 is incremented to #add+16 and so now threads 0 to 3 reconverge and execute the STR instruction at address #add+16 to store a value at a memory address determined based on a base address and pointer, with different threads using different pointers to determine the target address. Memory accesses for at least some of the threads can be combined into a single memory access if the pointers are such that the accesses target the same area of memory (e.g. the same cache line or the same page of space addresses).

Therefore, in the example of Figure 7, since threads require execution of the same instructions on different data values, they can be efficiently processed as a group because this allows a single instruction fetch to be amortized across the thread group and the accesses to be combined to memory. However, branch instructions, for example, may cause different behavior, such as when thread 2 requires a different instruction than the other threads. Although in Figure 7 this only resulted in a single cycle bubble in the pipelines for threads 0, 1 and 3, in other cases the deviation could last longer. There may be events outside the disciplines that cause similar differences in behavior. When the yarns in a warp diverge, there can be a significant number of cycles in which the yarns cannot perform their next operation because they have to wait while other yarns perform different operations, and this reduces performance. Therefore, processing performance can depend on how the threads are grouped. In practice, by assigning the yarns for segments in the same square (2x2 pixel step) in the same warp, the possibility of yarn deviation in the warp can be reduced.

As shown in Figure 6, the warp processing unit 40 may maintain an active mask 60 and a pending mask 62 to track the convergence or divergence between the paths taken by the respective warp threads. The use of active mask 60 and pending mask 62 is shown in greater detail in Figure 8. Active mask 60 includes a number of bit flags 64 each corresponding to a thread, which indicate whether the respective thread is active. Similarly, pending mask 62 includes per-thread bit flags 66 that indicate whether the corresponding thread is pending (a pending thread is a pending thread that has become inactive due to divergence with other active threads). Initially, when the shader program starts execution, all eight threads Q0T0 through Q1T3 are active and thus all bits 64 of the active mask 60 are equal to 1 and all bits 66 of the pending mask 62 are equal to 0. In a given point, the shader reaches a conditional branch instruction, and the results of the instruction differ for different threads, so there is divergence in the control flow. Two of the threads Q0T0 and Q1T1 follow a first path 68 through the program and therefore when the pipelines execute instructions from this branch then the active mask has 1 bits corresponding to these two threads and O' bits corresponding to the other threads, while the pending mask 62 has the opposite value of the active mask, since all other threads are pending and waiting for the warp program counter 44 to return to an address of an instruction to be executed by those threads. On the other hand, in a second branch of the program the remaining threads are active and threads Q0T0 and Q1T2 are inactive, as indicated by the active and pending masks respectively. As shown in the example of Figure 8, if the threads later converge again then the active mask may return to all 1's and the pending mask may return to all 0's.

In cases where all threads were initially active and none of the threads have yet terminated, then all threads may have a bit active in either the active mask 60 or the pending mask 62, so that a bit-level OR of the active and of the pending mask will always produce a result with all bits equal to 1. However, as shown in Figure 9 this is not necessary and sometimes the warp manager 42 can assign threads to a given warp so that at least one thread is inactive by the start of warp processing and in this case at least one bit of the active mask 60 may start from 0 even when there are no pending threads. Therefore, in the example of Figure 9 if a deviation occurs again in those threads which are active in a given branch 68, 70 of the control flow, their active mask bits are equal to 1 while in the other threads which were previously active, but are suppressed due to the deviation their pending mask bits are equal to 1. In threads which were never active because they were inactive from the beginning, the corresponding bits 64, 66 will be equal to 0 in both active and pending mask 60 , 62. Similarly, if the execution of a thread terminates then both the active and pending masks may equal 0 for a given thread.

As shown in Figure 6, active mask 60 and pending mask 62 may take the value 1 as a result of program counter voting performed by program counter voting logic 72 based on the individual thread program counters 58 of each warp thread. . Once the new value for the warp program counter 44 is determined, the program counter polling logic 72 can set the bits of the active mask 60 to the value 1 for any previously active or pending threads that have a thread program counter 58 that matches the warp program counter 44 , while it may set the pending mask bits 62 to the value 1 for any previously active or pending threads whose respective thread program counters 58 do not match the value of the warp program counter 44 just determined.

Figure 10 shows an example of clause-based execution that may be performed by the warp processing unit 40. The schedule counter polling operation can be relatively expensive in terms of power consumption due to the fact that multiple thread schedule counters 58 may have to be compared to determine the value to which the warp program counter 44 will be set. In practice, large parts of program execution within a shadow program can be carried out sequentially without any conditional branch instruction, and thus in these cases the warp program counter 44 can simply increase from cycle to cycle because there is no danger of threads converging or diverging during these successive sequences of program instructions. In this sense, sequential instructions are instructions that are stored in consecutive (contiguous and interspersed) memory addresses that follow some predetermined step interval.

To avoid the need to invoke the program counter polling logic 72 after each instruction, the instructions can be grouped by a programmer or compiler into clauses 80 as shown in Figure 10. Each clause can be marked in some way within the program code, e.g. .x. prefixing the commands of a given clause with a clause header 82. It will be appreciated that in other examples clauses could instead be broken up by a clause footer following the corresponding clause, or by both a clause header and a clause footer, or by some other techniques such as marking the first statement of the clause in some way or using a predefined statement type (eg a branch) to mark the boundary between clauses. As shown in Figure 10, the length of each clause can vary depending on the branch locations within the program being executed and the program can contain any number of clauses. Regardless of how the clause boundaries are identified in the program code served by the statement presentation logic 56, by breaking the execution of the statements into clauses in this way, the programmer or compiler can choose the locations of the clause boundaries to correspond to branch statements that may lead to non-sequential changes of program flow, so that within a clause, statement execution may continue completely sequentially. This means that the invocation of program counter polling logic 72 is only required at the end of a clause before the warp program counter to be used for the next clause is determined. Within a clause, the warp program counter 44 can instead simply be incremented by an adder 86 based on a certain step value corresponding to the length of the instructions, which consumes much less power than the program counter polling operation. Since program counter polling occurs at clause boundaries, this means that active mask 60 and pending mask 62 cannot be changed in the middle of a clause, but can only be updated at the end of a clause before the start of the next clause.

In some implementations, clause-based execution in this manner may also allow other performance or energy-saving optimizations to be made within pipelines 50 or access to architectural state registers 54. For example, a clause may be thought of as an individual set of operations which are generally carried out as a whole. Therefore, at an intermediate point the clause may not guarantee that the state of the thread 52 within the architecture state registers 54 for a given thread is in a stable state. For example, to reduce the overhead of writing to the architecture state registers 54 and reading from the architecture state registers, where two instructions issued in sequence within the same clause are such that the first instruction writes to a given register and the next instruction to read from the same register, while that register will then be replaced by a subsequent instruction in the clause, then the register write may not need to be done at all since the value read from the second instruction could simply be held within the pipeline after the first instruction is executed since it will be forwarded directly to the inputs for the processing element that executes the second instruction. By reducing the number of required register reads and writes, this can improve performance and save energy. Therefore, the correctness of the current architectural state stored in the registers may not be partially guaranteed through a clause.

As shown in Figure 6, the warp processing unit may have logic 90 to determine whether some processing threads performed by the warp can be discarded. There can be a number of reasons why threads can be discarded. In some cases the pixel termination stage 24 of pipeline 2 may determine that a thread already in progress within the segment shading stage 26 would be overdrawn by a later fetched segment which follows that earlier segment through the pipeline, and in this case may issue the termination signal 92 which may be passed by the warp manager to the associated warp processing unit 40 which manages the processing of that segment thread. The rejection logic 90 may compare the position coordinates of a pixel specified by the termination signal 92 with the coordinates specified in warp state information 94 indicating the pixel positions corresponding to the segments processed by each warp thread in order to determines whether this termination signal is applied to the current warp and if so, which thread.

Also, in some cases the shader itself could include a drop instruction on a particular branch of the control flow, which if executed for a given thread results in that thread being dropped once it is determined that that thread is no longer needed. Accordingly, if the instruction fetch and decode stage 56 encounters a discard instruction then this can be signaled to the discard logic 90 and, in conjunction with the active mask 60, this can determine which threads should be discarded (the pending threads denoted by the pending mask 62 would not be discarded since these would override the discard command since they are not currently active).

Regardless of the reason for discarding a given yarn, the warp processing unit 40 can handle yarn discard at the granularity of squares rather than individual threads. Therefore, either an entire block of threads can be discarded, or those threads can continue. This is because the threads of a given tile may have interdependencies in which one thread of the tile references values computed by another thread of the tile, as this may be useful for computing derivative functions used to determine gradients to render on the image . Therefore, even if a thread in the block must be dropped, if other threads in the blocks have not yet been dropped then the block as a whole can continue.

If all threads in the entire warp (ie, all squares) are to be discarded, then the processing of commands by each of the threads can simply terminate immediately regardless of whether the end of a clause has been reached. This can free up the warp 40 processor to handle other tiles sooner.

However, if only one tile (or two or more tiles, but less than all tiles in cases where the warp processor processes more than two tiles) is to be discarded then the execution of the commands for the non-discarded tiles should continues.

Since the execution of commands for the warp as a whole is controlled based on a common warp program counter 44, this means that it would not be possible to completely redistribute the various squares in the warp until the squares that continue are completed.

Therefore, conversely, when all threads of a given tile are about to be discarded but another tile continues, those threads can be marked as inactive by setting the corresponding bits to zero in both the active and pending masks 60 and 62. For example, each execution pipeline 50 may include power gates that isolate portions of the pipeline from a power or clock supply so that they can be placed in a power-saving state to save power when the corresponding threads become inactive or are terminated. However, due to the clause-based execution described with respect to Figure 10, the active and pending masks 60, 62 may not be allowed to partially change within a clause and thus when the rejection logic 90 determines that all threads of a given box are to be partially rejected through a clause, the corresponding statements may need to be executed until the end of the clause. Since some clauses may be relatively lengthy, some time may be required, and in the meantime the threads may have some effects on parts of the graphics processing pipeline to the outside of the warp processing unit 40. For example, as shown in Figure 5, each warp processing unit 40 may have a message passing interface 100 for passing messages to other pipeline components or to memory to enable access to data required by a given processing thread performed on data of warp 40 (data otherwise from the architectural state 52 of the thread which is stored in the architectural state registers 54 of the warp processing unit 40). For example, the messages 100 may be load/store requests to perform load or store operations on data within the feature store 13 , the texture cache 27 , the depth cache 22 , or the tile cache 20 shown in FIG. 1. Messages could also be generic load/store operations performed in main memory. If, during the time period between the determination that the threads of a given box are to be discarded and the time when the threads are actually suppressed at the end of a clause, such messages 100 are triggered by commands of the discarded threads, then this will result in the triggering unnecessary load or save operations to data storage elements outside of the warp processor. In addition to consuming unnecessary power to read or write to these storage locations, this can have an impact on the execution of other threads that may be waiting for bandwidth in the memory or buffer being read from.

Thus, in one example the warp processor 40 may support the placement of threads in a discard state in which the execution of instructions still continues, but the generation of messages 100 which request access to data other than the architectural state of the warp processor is suppressed to save power and improve the execution of other threads. A discard mask 102 can keep track of which threads are in the discard state, and corresponding bits of the discard mask can be provided to the respective pipelines 50 to check whether they trigger the generation of messages 100. Once the end of the current clause is reached then any threads have been set to the discard state within the clause, they can then be transitioned to the inactive state by setting the respective bits of the active and pending masks 60, 62 to zero so that subsequent clauses can use power gates to suppress instruction execution and saving more energy. However, in the time period until the end of the clause in which the discarded threads were identified, the use of the discard mask and message suppression allows for greater energy savings and improved performance.

In another example, the warp manager 42 may have a pixel dependency tracker 106 that keeps track of the pixel positions of the squares/segments currently being processed within each of the warp units 40. In some examples, the pixel dependency tracker 106 could instead be implemented in a different part of the pipeline outside of the warp manager 42. When a thread for a given pixel location is running within one of the warp processing units 40 then the warp manager 42 can prevent any further threads from being allocated for another graphics segment corresponding to the same pixel location. This means that while threads are in motion, other threads may be delayed until those threads are done for the same pixel location. To speed up the processing of such other threads, when a tile is discarded and the corresponding threads are placed in the discarded state, those threads can be removed from the pixel dependency tracer 106 so that those threads are no longer indicated as being in motion, and therefore each subsequent a thread processing segments at the same pixel location within the final image frame can then continue and be assigned to a given warp processing unit 40. Again this enables a performance improvement by allowing other squares to be processed earlier than would otherwise be possible if they had to wait for the warp to complete.

Figure 11 provides a table summarizing various states in which the yarns of a given warp can be put. In an idle or terminated state the bits of both the active and pending masks 64, 66 may be 0 and a bit of the discard mask 102 may also be 0. The idle state may be used in cases where a certain thread has been allocated in the warp processing unit 40 in the inactive state or in a case where a thread was previously active but was terminated, for example after the corresponding thread was dropped once the end of the clause in which the drop was detected was reached. When a thread is in the inactive or terminated state, the corresponding processing pipeline 50 may use power gates to suppress instruction execution and save power.

In an active state, the active mask bit from thread 64 is 1 , the corresponding bit of pending mask 66 is 0 , and the discard mask bit is 0 , in which case the instruction fetched and decoded by the fetch/decode stage 56 is executed for the thread. In a pending state, the active mask bit 64 is 0, the pending mask bit 66 is 1 and the corresponding discard mask bit 102 is 0 and in this case as long as the thread remains pending and therefore can become active again later depending on the polling of program counter 72, execution of instructions presented by fetch/decode stage 56 is suppressed for that thread, although the corresponding thread state is held in registers 54 ready for when the thread becomes active again.

In the discard state, the discard mask bit in discard mask 102 for this thread is 1 and the active and pending mask bits 64, 66 may take any value. In this case, the execution of instructions can continue in the same way as if the thread were active, since the active mask 60 cannot be partially changed through a clause. However the discard mask bit controls the pipeline of the associated thread 50 to either suppress the generation of data access messages 100 outside the warp processing unit 40 or remove the thread from the pixel dependency tracer 106 or both. This makes it possible to save energy and improve performance even in cases where it is not yet possible to suppress the actual execution of the thread's instructions.

Figure 12 is a flow diagram illustrating a method of yarn processing in warp processing unit 40. It will be appreciated that this shows the steps taken by a single warp processing unit 40, however other warp processing units 40 could be performing similar operations in parallel .

At step 200 the warp processing unit begins execution of the instructions from the next clause of the program being executed. If no previous clauses have been executed then this is the first clause of the program. In step 202 the discard logic 90 determines whether all active threads in the entire warp are to be discarded and that there are no outstanding threads. If this is the case, then in step 204 the entire warp is terminated and this frees the warp processing unit 40 for redistribution to other squares by the warp manager 42. The method then ends.

If there is at least one active thread in the warp that has not been discarded, or there was at least one pending thread that has not been discarded, then at step 206 the discard logic 90 determines whether all threads in a given box within the warp are to be discarded. These can include either active or pending threads. If all four threads of the same square are to be discarded (and because of the NO determination in step 202 there is at least one other square that has not been discarded), then in step 208 all threads of that square are transitioned to the discard state by setting the value 1 the corresponding bits in discard mask 102. This means that for the remainder of the clause these threads cannot trigger message generation 100 and/or can be removed from pixel dependency tracer 106.

On the other hand, if it is determined in step 206 that not all threads of the square are to be discarded, then in step 210 it is determined whether all active threads of the square are to be discarded and that there are no pending threads in that square. For example, this may be determined based on active mask 60 and pending mask 62 so that all threads with a 1 in the active mask are to be discarded and there is no 1 bit for that square in pending mask 62. If these criteria are met, then again at step 208 all threads in the block are transitioned to the discard state, or at least all active threads in the block are transitioned to the discard state (since the pending threads will not execute commands in this clause, they cannot trigger the creation messages anyway).

In step 212 it is determined whether the end of the clause has been reached and if not, the method returns to step 202 to continue checking to discard threads. When the end of the clause is reached, then in step 214 it is determined whether there are any other clauses to execute. If there are no other clauses, then in step 216 the warp is terminated and the results of the warp are forwarded to subsequent stages of the pipeline to perform subsequent depth testing, alpha blending, and so on.

If there is at least one more clause to be executed, then at step 216 any threads that were not transitioned to the discard state during the execution of the most recently terminated clause are then transitioned to the terminated state so that during the subsequent clause execution of statements is suppressed for saving more energy. In step 218 the warp program counter 44 is determined by the program counter polling logic 72 based on the individual program counters of the threads 58, while in step 220 the active and pending masks 60, 62 are updated based on the result of the program counter poll , while the method then returns to step 200 to begin the next clause.

In summary, when one tile is completely discarded the warp can continue to run and the other tile is not discarded, and it is possible to save energy and improve performance by partially terminating the warp and releasing pixel dependencies. A square is suppressed if all four threads of the square are discarded, or if all active threads of the square are discarded and the threads are non-divergent (ie, there are no outstanding threads). If these conditions hold then for that cell we can suppress messages to save power, at the end of the clause enable a mask and terminate the cell to save significant power via power gates, and also remove the cell from the pixel dependency system rather than waiting for the warp to fully complete, to improve performance by allowing other squares to be rendered at that pixel location.

In the present application, the words "configured for..." are used to mean that an element of a device has a configuration capable of performing the specified function. In this context, a “configuration” means an arrangement or way of interconnecting hardware or software. For example, the device may have dedicated hardware that provides the specified function or a processor or other processing device that can be programmed to perform the function. The words “configured for” do not imply that the layout element must be changed in any way to provide the specified function.

Although illustrative embodiments of the invention have been described in detail herein with reference to the accompanying drawings, it is to be understood that the invention is not limited to these precise embodiments and that various changes and modifications may be made therein by those skilled in the art without departing from the object and spirit of the invention as defined by the appended claims.

Claims (19)

Assemble Information Dossier 2018-00364 User D. Stafylas Date 11-04-2018 Document 1: CLMS 28-12-2017 Page Source 1 - 4 CLMS 28-12-2017 1 - 4 5 - 6 CLMS 02-04-2018 1 - 2 CLAIMS 1. An arrangement for processing graphics, which includes: a warp processing unit for processing a plurality of processing threads into respective graphics sections; wherein the warp processing unit is configured to control, in dependence on a warp program counter shared among the plurality of threads, the presentation of a next command to be executed for at least some of the plurality of threads; the warp processing unit includes registers to store architectural state data for the number of threads; in response to a determination that a subset of threads is to be discarded when at least one other subset of threads of the plurality of threads is to continue, the warp processing unit is configured to process the subset of threads in a discard state, and for a thread processed in the discard state, the warp processor is configured to continue executing instructions for the discarded thread, and at least one of the following: the warp processor is configured to suppress generation of data access messages triggered by the discarded thread, said data access messages including messages requesting access to data other than said architecture state data stored in registers of the warp processing unit, and the graphics processing arrangement is configured to allow at least one processing operation, which would be delayed until the completion of the aborted thread if the thread had not been aborted, to be initiated regardless of an outcome of the aborted thread. 2. The arrangement according to any preceding claim, wherein the plurality of threads comprises at least two groups of threads, and the warp processing unit is configured to prevent a thread of a given group from switching from a non-discarded state to a partially-discarded state during execution of that thread when at least one other thread in the given group is about to continue in the no-discard state. 3. The device according to claim 2, wherein each group of threads comprises four threads corresponding to a 2x2 grid of graphics segments. 4. The arrangement according to any one of claims 2 and 3, wherein the warp processing unit is configured to transition the yarns of a given group from the no discard state to the discard state in response to a determination that all yarns for the given group are to be to be discarded while at least one other group's threads are to continue. 5. The arrangement according to any preceding claim, wherein the warp processing unit is configured to maintain an active mask indicative of which threads of the plurality of threads are active threads which are to execute the next command presented in dependence on the counter warp program, and a pending mask indicative of which threads of the plurality of threads were previously active but are inactive due to divergence between the control flow followed by the corresponding threads of the plurality of threads. 6. The arrangement according to any one of claims 2 to 4, wherein the warp processing unit is configured to maintain an active mask indicative of which threads of the plurality of threads are active threads which are to execute the next command presented to dependence on the warp program counter, and a pending mask indicative of which threads of the thread count were previously active but are inactive due to the divergence between the control flow followed by the corresponding threads of the thread count, and the warp processing unit is configured to transition all active threads indicated by the active mask for a given group from the no discard state to the discard state in response to a determination that all active threads for the given group are to be discarded, when the pending mask indicates that there are no pending threads for the given group and the threads of at least one other group are about to continue. 7. The arrangement according to any one of the preceding claims, wherein the warp processing unit is responsive to command clauses within a common program executed for the plurality of threads, to execute each command clause as a cascade of commands with sequential control flow. 8. The arrangement according to claim 7, wherein the warp processing unit is not capable of updating an active mask partially during the processing of a given clause, the active mask indicating which threads of the plurality of threads are active threads to execute the next command served depending on the warp program counter. 9. The arrangement according to any one of claims 7 and 8, wherein the warp processing unit is capable of switching a thread from a non-discarding state to a partially discarding state during processing of a given clause. 10. The apparatus according to claim 9, wherein in response to completion of processing of the given clause when a given thread has been transitioned from the no discard state to the discard state partially during the processing of the given clause, with the warp processing unit configured to transition the given thread into a terminated state, where the warp processor is configured to suppress the execution of commands for threads in the terminated state. 11. The arrangement according to any one of claims 7 to 10, wherein in response to a determination that all yarns of the plurality of yarns processed by the warp processing unit are to be discarded, the processing unit is configured to terminate processing of thread count partially while processing a current clause. 12. The arrangement according to any one of the preceding claims, wherein the warp processing unit is configured to process a helper yarn in the discard state from the start of helper yarn processing. 13. The arrangement according to any one of the preceding claims, wherein the warp processing unit is configured to determine that a given thread is to be discarded in response to a termination signal indicating that the graphics portion corresponding to the given thread is to be hidden in a rendered image from another graphics part processed by the layout. 14. The arrangement according to any preceding claim, wherein the warp processing unit is configured to determine that a given thread is to be discarded in response to the execution of a discard command for the given thread. 15. The arrangement according to any preceding claim, wherein said data access messages include requests to load data from, or store data in, at least one of: a tile cache or a frame cache for storing previously calculated pixel values for at least a portion of a rendered image frame; a depth buffer for storing depth values for the pixels of at least a portion of the rendered image frame; a texture cache for storing texture data referenced by processing threads performed by the warp processing unit, and a feature store to store features calculated for a given graphics segment before issuing a corresponding processing thread to the warp processing unit. 16. The arrangement according to any preceding claim, wherein said at least one processing operation comprises a processing thread performed for another graphics segment at the same position in a rendered image as the graphics segment corresponding to the thread in the discard state. 17. The arrangement according to any preceding claim, comprising a plurality of said warp processing units, each having a separate warp program counter. 18. A graphics processing device, comprising: processing means of a plurality of processing threads in respective graphics sections; wherein the processing means is configured to control, in dependence on a warp program counter shared by the plurality of threads, the presentation of a next instruction to be executed for at least some threads of the plurality of threads; the processing means includes means for storing architectural state data for the plurality of threads; in response to a determination that a given subset of threads is to be discarded when at least one other subset of threads of the plurality of threads is to continue, the processing means being configured to process the given subset of threads in a discarded state, and for a discarded thread in the aborted state, the processing means are configured to continue executing commands for the aborted thread, and at least one of the following: the processing means is configured to suppress the generation of data access messages triggered by the aborted thread, said data access messages including messages requesting access to data other than said architecture state data stored in processing media storage media, and the graphics processor is configured to allow at least one processing operation, which would be delayed until completion of the aborted thread if the thread had not been aborted, to be initiated regardless of an outcome of the aborted thread. 19. A graphics processing method, comprising*; the -processing of a plurality of processing threads in respective graphics sections using a warp processing unit configured to control, -cc dependency on a warp program counter which is used by -common among the plurality of threads, presenting -a next command to be executed for at least some threads from the plurality of -threads, with the -worp processing unit including registers for storing the architecture state data- yw the plurality of threads, and<■■> q8 response of a determination that a given subset of threads is caused to be dropped when at least one other subset of threads of the plurality of threads is to continue, with. the warp processor to process the given subset of threads in a discard state; where-for-a-discarded-thread-in-discard-state, the warp processor continues execution of the instructions for the discarded thread, and at least one of >a sys. the — warp — processing — unit — suppresses — the — generation of — data access messages generated by the rejected thread, with said data access messages including messages denying access to data other than cv due to architecture data state stored in the warp-processing unit-registers, and — at least OE a Processing operation, which will be suspended until the rejected is completed. thread in -case the -don thread was aborted, — is allowed to start independently; of a result of the aborted thread.