Masked load / store instruction for gpu

Abstract

A graphics processing unit (GPU) comprises instruction decoding circuitry configured to decode instructions according to a GPU instruction set architecture and processing circuitry configured to perfo

Description

The present technique relates to the field of graphics processing units (GPUs). A graphics processing unit (GPU) is a type of processor designed to support graphics processing. Compared to a central processing unit (CPU), a GPU typically supports much higher parallelism, e.g. using a number of shader cores provided within the GPU to execute respective threads of shader processing in parallel. For graphics processing, such parallelism can be useful to allow respective pixels or pixel groups of a graphics frame to be processed in parallel, but the GPU could also be used for other non-graphics-related tasks where parallelism is helpful, such as in machine learning training or inference algorithms. Shader programs executed on the GPU may be written using instructions defined in a GPU instruction set architecture (ISA). At least some examples of the present technique provide a graphics processing unit (GPU) comprising: instruction decoding circuitry configured to decode instructions according to a GPU instruction set architecture; and processing circuitry configured to perform data processing in response to instructions decoded by the instruction decoding circuitry; in which: in response to a masked load / store instruction specifying an address operand and a register bitmask operand specifying a plurality of mask bitfields, each mask bitfield corresponding to a register group of one or more registers and indicating whether that register group is masked or non-masked: the instruction decoding circuitry is configured to control the processing circuitry to perform a load / store operation in respect of each register within a target set of registers identified based at least on the register bitmask operand, the register bitmask operand indicating which register groups are masked register groups which are permitted to be excluded from the target set of registers, and the load / store operation for a given register in the target set of registers comprising transferring data between the given register and a memory system location determined based on the address operand. At least some examples of the present technique provide a system comprising: the GPU described above, implemented in at least one packaged chip; at least one system component; and a board, wherein the at least one packaged chip and the at least one system component are assembled on the board. At least some examples of the present technique provide a chip-containing product comprising the system described above, wherein the system is assembled on a further board with at least one other product component. At least some examples of the present technique provide computer-readable code for fabrication of a GPU as described above. The computer-readable code may be stored on a computer-readable storage medium. The computer-readable storage medium may be a transitory storage medium. At least some examples of the present technique provide a computer program comprising instructions which, when executed by a host data processing apparatus, control the host data processing apparatus to provide an instruction execution environment for execution of target program code, the computer program comprising: instruction decoding program logic configured to decode instructions of the target program code according to a GPU instruction set architecture; and processing program logic configured to control the host data processing apparatus to perform data processing corresponding to the instructions decoded by the instruction decoding program logic; in which: in response to a masked load / store instruction specifying an address operand and a register bitmask operand specifying a plurality of mask bitfields, each mask bitfield corresponding to a register group of one or more registers and indicating whether that register group is masked or non-masked: the instruction decoding program logic is configured to control the processing program logic to perform a simulated load / store operation in respect of each register within a target set of registers identified based at least on the register bitmask operand, the register bitmask operand indicating which register groups are masked register groups which are permitted to be excluded from the target set of registers, and the simulated load / store operation for a given register in the target set of registers comprising a simulated data transfer between the given register and a simulated memory system location determined based on the address operand. The computer program may be stored on a computer-readable storage medium. The computer-readable storage medium may be a transitory storage medium. At least some examples provide a method comprising: obtaining, as a function argument for callee function code executed on a GPU supporting a GPU instruction set architecture, a register liveness argument specifying which registers of the GPU instruction set architecture need to be preserved by the callee function code; and executing a masked load / store instruction specifying an address operand and specifying a value dependent on the register liveness argument as a register bitmask operand, the register bitmask operand specifying a plurality of mask bitfields, each mask bitfield corresponding to a register group of one or more registers and indicating whether that register group is masked or non-masked; wherein the masked load / store instruction controls the GPU to perform a load / store operation in respect of each register within a target set of registers identified based at least on the register bitmask operand, the register bitmask operand indicating which register groups are masked register groups which are permitted to be excluded from the target set of registers, and the load / store operation for a given register in the target set of registers comprising transferring data between the given register and a memory system location determined based on the address operand. At least some examples provide a computer program comprising instructions which, when executed by a GPU, control the GPU to perform the method described above. Further aspects, features and advantages of the present technique will be apparent from the following description of examples, which is to be read in conjunction with the accompanying drawings, in which: Figure 1 illustrates an example of a system comprising a GPU; Figure 2 illustrates an example of a GPU; Figure 3 illustrates an example of a shader core of a GPU; Figures 4A and 4B illustrate examples of processing corresponding to a masked load / store instruction; Figure 5 illustrates a method comprising steps for processing a masked load / store instruction; Figure 6 illustrates an example use case where the masked load / store instruction is used in callee program code to select a target set of registers based on a register bitmask operand dependent on a register liveness argument passed by caller program code; Figure 7 illustrates a system and a chip-containing product; and Figure 8 illustrates a simulation example. A graphics processing unit (GPU ) comprising: instruction decoding circuitry configured to decode instructions according to a GPU instruction set architecture (ISA); and processing circuitry configured to perform data processing in response to instructions decoded by the instruction decoding circuitry. In the examples discussed below, the GPU ISA supports a masked load / store instruction specifying an address operand and a register bitmask operand specifying a plurality of mask bitfields. Each mask bitfield corresponds to a register group of one or more registers and indicates whether that register group is masked or non-masked. In response to the masked load / store instruction, the instruction decoding circuitry controls the processing circuitry to perform a load / store operation in respect of each register within a target set of registers identified based at least on the register bitmask operand. The register bitmask operand indicates which register groups are masked register groups which are permitted to be excluded from the target set of registers. The load / store operation for a given register in the target set of registers comprises transferring data between the given register and a memory system location determined based on the address operand. Such an instruction can be particularly useful for improving efficiency of GPU register state saving / restoration within a function call. A problem that arises on GPUs is that GPUs can have relatively large register files, and may frequently need to execute function calls where caller program code calls a function to be performed by callee program code. The caller and callee code may be based on program code written by different software developers, so each piece of code may be written without any knowledge of which registers are used by the other. It can be common for function calling conventions to be established which logically divide the register set into three: (i) function argument registers used to pass parameters between the caller and callee; (ii) caller-saved registers which are registers that can be overwritten by the callee and so if the caller needs to preserve the state in those registers, they should be saved by the caller prior to calling the callee function; and (iii) callee-saved registers which are registers that should be preserved by the callee and so if the callee needs to use those registers in the function body, the callee should execute a store operation to store register state from those registers to memory before starting the function body and a load operation to restore the saved register state to the registers just before returning to the caller. However, a problem specific to GPUs is that the GPU can often be executing graphics library code for which the call graph (sequence / nesting of function calls made by the software) cannot be statically determined at compile time, e.g. because the executed shader programs are called dynamically based on a shader binding table. Therefore, compilers compiling software for GPUs are unable to make any assumptions on which registers may be likely to be used by caller and callee code either side of a function call, and it can be difficult to establish an efficient function calling convention. Hence, the callee may be forced to conservatively save state from a large number of callee-saved registers to memory, even though it may be that these registers do not actually contain any state that needs to be preserved for the caller. The inventors have recognised that there can be a significant number of register state save / restore operations performed on a GPU where a given register did not actually need to be saved / restored. This has profound performance implications on GPUs since the additional instruction slots and memory bandwidth consumed by unneeded memory operations reduces bandwidth available for other operations. By providing the masked load / store instruction in the GPU ISA, the register bitmask operand provides additional information indicating which register groups can be excluded from the target set of registers. This information can be used by GPU hardware implementations to limit which registers have their state stored to memory or loaded from memory in response to a given instance of the masked load / store instruction. This makes it much more efficient for the GPU to consider, when performing state saving / restoration for callee code, information passed by the caller indicating which registers are in use by the caller, so that unneeded memory operations can be avoided. For example, when in use, the bitmask can be generated based on an argument passed by the caller indicating the live registers which would need to be preserved by the callee. While inclusion of the masked load / store instruction in the GPU ISA can be particularly useful to support improved efficiency of register state saving / restoration in callee function code, it will be appreciated that software developers or compilers may also find other use cases for the instruction, so use of the instruction for callee function state saving / restoration is not essential. Nevertheless, a GPU ISA supporting the masked load / store instruction is a better GPU than an ISA not comprising this instruction, as a GPU lacking the support for the masked load / store instruction would be forced to either use much less efficient sequences of operations to identify which registers are to be saved / restored in a function call (e.g. long sequences of conditional branches which select which load / store instructions are to be executed) or to simply assume conservatively that a wider set of registers could be required to be saved, which harms performance by performing unneeded memory operations. Hence, a GPU ISA supporting the masked load / store instruction can be particularly attractive to software developers by providing more efficient support for function code. While the masked load / store instruction defines a register bitmask operand defining masked register groups which are permitted to be excluded from the target set of registers for which load / store operations are performed in response to the instruction, the GPU ISA may permit some GPU hardware implementations to load / store more registers that are not architecturally required to be loaded / stored (e.g. because of limitations in the granularity with which memory operations can be performed, which might be more coarse-grained in some implementations so that omitting a load / store operation for a given masked register might not necessarily save bandwidth if that register is in the same memory block as another register which is not masked). Hence, it is not excluded that some GPU hardware implementations may partially ignore the masked status for some register groups and perform additional load / store operations corresponding to masked registers. Nevertheless, by supporting the masked load / store instruction in the GPU ISA, this provides a better GPU ISA for software developers, because at least when the software using the masked load / store instruction is executed on a GPU implementation which more precisely follows the masking indicated by the register bitmask operand, the software can execute with greater performance due to avoiding unneeded memory operations. The provision of the register bitmask operand enables the hardware implementation to be given information which would not otherwise be available, to enable greater filtering of unneeded memory operations than would be possible if the register bitmask operand was not supported. Variants of the masked load / store instruction may be provided corresponding to load and store operations respectively. For a masked load instruction, the load / store operation performed for a given register in the target set of registers comprises a load operation to transfer data from a corresponding memory system location determined based on the address operand to the given register. For a masked store instruction, the load / store operation performed for a given register in the target set of registers comprises a store operation to transfer data from the given register to a corresponding memory system location determined based on the address operand. The register bitmask operand can be encoded in different ways. If there is sufficient encoding space within the instruction encoding of the masked load / store instruction, the register bitmask operand could be specified as an immediate value directly indicated by the instruction encoding of the masked load / store instruction. However, in some examples, the masked load / store instruction specifies a register identifier indicating a register providing the register bitmask operand. Use of a register to provide the register bitmask operand can help support larger register sets and / or finer granularity of selection of masked and unmasked registers, by enabling the register bitmask operand to have more bits than would be possible to encode as an immediate value within the instruction encoding. In some example implementations, the register bitmask operand could be the only register selection operand supported by the masked load / store instruction, so that the target set of registers comprises those registers indicated as non-masked by the register bitmask operand. However, in some examples, the masked load / store instruction may also support a further register selection operand, and in response to the masked load / store instruction, the processing circuitry is configured to identify the target set of registers based on the further register selection operand and the register range operand. While it may seem redundant to provide two orthogonal register selection operands, in practice it can be extremely useful to support the further register selection operand in addition to the register bitmask operand, as this allows the selection of the target set of registers to depend on operands set by the caller program code and callee program code respectively. Although an alternative option would be to combine operands set by caller and callee code into a single operand defining the register bitmask operand using instructions preceding the masked load / store instruction, that would introduce additional instructions which harms code density and processing performance as those additional instructions consume additional space in memory, instruction fetch bandwidth and instruction slots in processing pipelines which could otherwise be used for other instructions. By providing a masked load / store instruction which selects the registers for which load / store data transfers are to be performed based on both the register bitmask operand and a further register selection operand, a single instruction may easily consider information provided by both caller and callee code to identify the target set of registers, making it more feasible to implement software routines with reduced memory bandwidth overhead incurred for register state saving / restoration operations for a function call. Of course, the instruction may also be useful for other purposes other than saving / restoration of register state when entering / exiting function code, but this can be a particularly useful use case as the frequency of function calls being made means that performance improvements associated with this use case can be achieved many times in a given piece of software being executed, giving a significant performance improvement to justify the encoding space used to include such an instruction in a GPU instruction set. In examples where a further register selection operand is provided, the further register selection operand may distinguish which registers are selected registers (indicated as selected by the further register selection operand) and which registers are unselected registers (indicated as not selected by the further register selection operand). The target set of registers may correspond to an intersection of the selected registers indicated by the further register selection operand and the non-masked registers indicated as not being masked by the register bitmask operand. Hence, each register in the target set of registers may comprise a register for which a corresponding register group is indicated as non-masked by the register bitmask operand and which is indicated as being a selected register by the further register selection operand. A register in a masked register group may be excluded from the target set of registers even if it is indicated as selected by the further register selection operand. A register indicated as unselected by the further register selection operand may be excluded from the target set of registers even if it is indicated as being in a non-masked register group by the register bitmask operand. By providing two orthogonal operands each defining which registers should be selected for the target set of registers and which registers are allowed to be excluded from the target set of registers (e.g. with the target set of registers corresponding to a logical AND combination of the two sets of registers selected based on the register bitmask operand and further register selection operand respectively), this provides good ISA support for an efficient register state save / restore operation at function call entry / exit, as the two operands may be defined based on callee-provided and caller-provided information respectively to narrow down the set of registers saved to those that (a) the caller code requires to be preserved, and (b) the callee code is going to overwrite within the function code body. Rather than imposing a single pre-agreed calling convention across every instance of caller-to-callee function calls in a set of software being executed, the masked load / store instruction with the register bitmask operand and at least one further register selection operand effectively enables bespoke calling conventions to be defined for each specific callercallee pair within the set of software. The further register selection operand could be encoded in a wide variety of ways. In some examples, the further register selection operand could be a further bitmask operand which is encoded in a similar way to the register bitmask operand (e.g. with the further register selection operand comprising a register selection bitfield per register group, each register selection bitfield indicating whether the one or more registers in the corresponding register group are selected registers or unselected registers). However, in some examples, the further register selection operand comprises a register range operand indicating a range of register identifiers. For example, the register range operand may specify a start register identifier and an end register identifier, the start register identifier and end register identifier indicating the start and end of a contiguous range of register identifiers that correspond to selected registers. Hence, in this case the target set of registers may be those registers indicated as being in a non-masked register group by the register bitmask operand and whose register identifiers fall within the range of register identifiers indicated by the register range operand. Encoding the selected registers using a range can be an efficient way of encoding the selected registers, as the start / end points of the range may be encoded with fewer bits than a bitmask. In practice, an encoding restriction that constrains the selected registers to fall in a contiguous range of register identifier space between the start / end register identifiers may not be a problem for a compiler generating the callee function code, because the choice of which registers are to be used for function body operands may be relatively arbitrary and so the compiler can adapt the mapping of registers to operands accordingly to use registers from a contiguous range of register identifier space. In contrast, which registers are to be preserved for the caller code may be more likely to involve an arbitrary selection of isolated registers at non-contiguous portions of the register identifier space, so it can be beneficial to use a bitmask for the register bitmask operand. Hence, an implementation in which the masked load / store instruction uses a register range operand as a further register selection operand, in addition to the bitmask offered by the register bitmask operand, can be a particularly effective encoding for supporting more efficient use of memory bandwidth in function entry / exit routines. In some examples, a mapping between the plurality of mask bitfields of the register bitmask operand and register identifiers of registers in register groups corresponding to the plurality of mask bitfields may be an absolute mapping which is independent of a value of the further register selection operand. Hence, the bitmask operand is defined in absolute terms, not relative to the registers selected by the further register selection operand. For example, where the further register selection operand is encoded as a register range as discussed above, a given bit of the bitmask refers to a specific register group regardless of which range is encoded by the further register selection operand (as opposed to a relative mapping in which, say, a first bitfield of the bitmask corresponds to the register group having the lowest register identifier(s) of any register group indicated as selected by the range operand, a second bitfield of the bitmask corresponds to the register group having the next lowest register identifier(s) of any register group indicated by the range, and so on). It can be beneficial for the bitmask to be defined with an absolute mapping, so that a given bitfield corresponds to the same group of one or more registers irrespective of what is indicated by the further register selection operand. When the instruction is in use within program code, the use of an absolute mapping for the bitmask allows the further register selection operand and register bitmask operand to be defined independently by caller and callee program code respectively, with no need for one of the caller / callee to understand which registers are being selected by the other. This makes it much simpler to provide interoperability between caller / callee program code supplied by different providers. The load / store operation for a given register comprises transferring data between the given register and a memory system location having an address determined based on the address operand. There can be different ways of determining the address of the memory system location to / from which the data for the given register is transferred in the load / store operation. One option could be for the addresses of the memory system locations to / from which data is transferred for each of the target set of registers to be at contiguous locations in memory address space, with those addresses determined based on the register bitmask operand to access adjacent memory addresses for each of the registers. Condensing the data for the target set of registers into a smaller space (eliminating gaps in address space corresponding to registers not selected in the target set of registers) can be more efficient for memory usage. However, it may make it harder for software to access selected information from the saved memory locations, as identifying which data relates to which register would then require knowledge of the register bitmask operand. Therefore, some implementations may instead choose to implement the instruction so that the address of the memory system location (to / from which data for the given register is transferred in the load / store operation) is determined by the processing circuitry independent of the register bitmask operand. With this approach, the address, relative to a base address computed from the address operand, at which data for a given register is stored or loaded does not vary depending on how many register groups are masked / unmasked, but has a fixed offset relative to the base regardless of the masking control. For example, the offset may correspond to a product of the register identifier of the given register and a multiple corresponding to the size of data in one register. By determining the address for the data transfer of a given register independent of the register bitmask operand, this can make it much simpler to write or compile callee function program code using the masked load / store instruction (with less need to reference the register bitmask operand every time the memory region associated with the masked load / store instruction is accessed). Also, with the address offset at which information for a given register is mapped remaining static regardless of the bitmask, this opens up opportunities for other performance optimisations which rely on the memory address offset between one item of saved register state and another being statically fixed at compile time. In examples where the address is statically determined independent of the register bitmask operand, there can be different ways of handling operations for “skipped” addresses for which the load / store operation is suppressed because the associated register is not one of the target set of registers selected based on the register bitmask operand. For example, for a masked store operation, the memory locations corresponding to the skipped addresses may either be left untouched (continuing to store their previous values), or could be architecturally undefined (giving more flexibility to allow hardware to handle those skipped addresses in any way chosen by the system designer - the architectural “undefined” status meaning that software cannot rely on the skipped addresses having any previous value stored in those locations). For masked load operations, the memory locations corresponding to the skipped addresses may be unread. The register bitmask operand can be encoded in different ways. As mentioned above, in general the register bitmask operand comprises a number of mask bitfields, with each bitfield corresponding to a register group comprising one or more registers and indicating whether that register group is masked or non-masked. In some examples, each bitfield could comprise a single bit. For example, a bitfield encoding of a first bit value may indicate that the corresponding register group is non-masked and an encoding of a second bit value may indicate that the corresponding register group is masked. For example, the first bit value may be 1 and the second bit value may be 0, or vice versa. In some examples, each bitfield could comprise more than one bit. This could allow the masked / non-masked status of each register group to be encoded alongside other information. Hence, the bitfield may have a plurality of encodings for two or more bits of the bitfield, and a first subset of those encodings may indicate that the corresponding register group is non-masked while a second subset of those encodings may indicate that the corresponding register group is masked. In some examples, each register group comprises a single register. Hence, the register bitmask operand may comprise a bitfield per register, within a given set of registers. This approach provides the finest granularity of selection of individual masked / non-masked registers within the given set of registers. However, in other examples, each register group comprises at least two registers. Providing a bitfield per group of two or more registers reduces the granularity with which registers are indicated as masked or non-masked, but reduces the total number of bits required for the register bitmask operand. In some examples with large register sets but limited encoding space for the register bitmask operand, it may be desirable to share a bitfield between a group of two or more registers to conserve encoding space. Nevertheless, by supporting the ability to mask out load / stores to masked groups of registers, this still enables a saving of memory bandwidth compared to that which would be practical to achieve on a GPU which did not support any masked load / store instruction at all. Although the masked load / store instruction could also be used for GPUs supporting smaller register sets, the masked load / store instruction can be particularly useful in cases where the register bitmask operand has an encoding capable of indicating, for each register in a register set comprising at least 64 registers, whether that register is masked or unmasked. GPUs having large register sets of 64 registers or greater may be common to reduce the likelihood of register pressure forcing additional load / store operations (outside of function call entry / exit) which are required to save / restore register state to memory because of the need to reuse a given register identifier for a different operand when there are no more available register identifiers left that have not already been used. However, with such a large register set, there is a risk that the memory bandwidth overhead of state saving / restoration at function entry / exit becomes high. By supporting the masked load / store instruction, the target set of registers can be reduced in scope to reduce the number of unneeded memory load / stores triggered during function entry / exit. Note that where the register set comprises 64 of more registers, while the register bitmask operand is capable of indicating whether each of those registers is masked or unmasked, as mentioned above this does not necessarily need the masked / unmasked status of each register to be identified at single-register granularity. The register bitmask operand may indicate masked / unmasked registers at granularity of groups of two or more registers in some examples. While the GPU ISA may be generic to a range of GPU hardware implementations, so a wide variety of hardware designs of GPU (including those not supporting ray tracing circuitry) may be used in conjunction with the same GPU ISA version, GPUs which comprise raytracing circuitry implemented in hardware to perform ray tracing may particularly benefit from a GPU ISA supporting the masked load / store instruction. Ray tracing is a technique used in graphics processing to render a frame based on modelling light transport to determine what geometry of a frame to be rendered is visible along the path of a given ray of light. Modern ray tracing pipeline libraries may define a shader binding table used to dynamically select which shader algorithms are executed, which poses a problem for compilers as it means the call graph cannot be statically determined at compile-time. This problem can be addressed by using the masked load / store instruction to support use of a bitmask dependent on a function call argument passed from caller to callee to limit which registers need their register state saved, to improve performance for ray tracing workloads. Hence, the GPU ISA supporting the masked load / store instruction is expected to enable particularly high performance savings when used in conjunction with ray tracing circuitry. As mentioned above, one compelling use case for the masked load / store instruction is in state saving / restoration for callee program code called by a function call from caller program code. Hence, in some examples, a method may be provided comprising: obtaining, as a function argument for callee function program code executed on a GPU supporting a GPU instruction set architecture, a register liveness argument specifying which registers of the GPU instruction set architecture need to be preserved by the callee function program code; and executing a masked load / store instruction specifying an address operand and specifying a value dependent on the register liveness argument as a register bitmask operand. The register bitmask operand comprises bitfields as described above and the masked load / store instruction controls the GPU to perform a load / store operation in respect of each register within a target set of registers identified based at least on the register bitmask operand, where the target set of registers excludes registers of register groups indicated as masked by the register bitmask operand, and the load / store operation for a given register in the target set of registers comprises transferring data between the given register and a memory system location determined based on the address operand. By defining the register bitmask operand based on the register liveness argument passed by the caller program code to the callee program code, this enables the target set of registers to be limited based on information from the caller expressing which registers need preserving, to reduce the memory bandwidth incurred in state saving / restoration operations at function entry / exit. The technique can be particularly useful where the callee function program code comprises shader program code, and in particular where the callee function program code comprises ray tracing processing, given the difficulty in a compiler identifying call-graphs for shader function calling in ray tracing workloads as mentioned above. However, it will be appreciated that the same type of instruction can also be used for other use cases. Hence, the specific use case made of the instruction may depend on software design goals, and is not an essential feature of the GPU hardware. The GPU itself comprises the instruction decoding circuitry and processing circuitry which processes the masked load / store instruction based on its register bitmask operand (and if provided the further register selection operand) as discussed above, but the particular way those operands are defined based on earlier instruction is a matter for the software developer or compiler to select, and is not an essential feature of the GPU hardware. Specific examples are now described with reference to the drawings. Figure 1 schematically illustrates an example of a data processing system 2. The system 2 comprises a number of memory access initiators 4, 6, 8, which share access to memory storage 12 accessed via a system interconnect 10. In this example, the memory access initiators include a CPU (central processing unit) 4, GPU (graphics processing unit) 6 and a hardware accelerator 8. While only one initiator of each type (CPU, GPU and hardware accelerator) is shown in the example of Figure 1, it will be appreciated that there could be more than one initiator of a given type. Figure 2 illustrates in more detail some components of the GPU 6. It will be appreciated that this is just one example, so other GPUs 6 could have a different configuration, and also that Figure 2 is a simplified diagram and so the GPU could also have other components not illustrated in Figure 2 for conciseness. As shown in Figure 2, the GPU 6 has a number of shader cores 20 for performing processing operations in parallel. For example, for a graphics processing algorithm, the shader cores 20 can be used to carry out graphics computation tasks such as vertex processing, geometry processing and fragment shading. When a GPU is used for other non-graphics workloads (e.g. for machine learning processing or other workloads where highly parallel processing is useful), other tasks may be performed by each shader core 20. The tasks to be performed may be defined by the software instructions executed by each shader core 20. A job manager 28 may manage the allocation of tasks to particular shader cores 20. The shader cores 20 can access GPU caches 30 via the GPU’s control fabric 24, as well as triggering memory access requests for accessing system memory 12. While not illustrated in Figure 2, the shader cores 20 may also have local caches 48 (shown in Figure 3), for caching data closer to the shader core. The GPU 6 comprises a memory management unit (MMU) 26 for performing memory address translation and access permission checking for the memory access requests issued by the shader cores 20 for accessing the caches 30 and / or system memory 12. The address translation mappings used to carry out virtual-to-physical address translation and the associated access permissions (e.g. read / write / execute permissions) are obtained by the MMU 26 from translation table data structures stored in the memory system 12, e.g. by performing a “page table walk” to traverse multi-level translation table structures to obtain the address translation information and access permissions. Once obtained, the address translation mapping information and access permissions can be cached in one or more TLBs (translation lookaside buffers) 22 for faster access, so that the slow page table walk can be avoided on subsequent accesses to addresses in the same page (a “page” being a block of addresses which share the same entry in the translation table structure providing the address translation mapping I permissions data). In the example of Figure 2, a distributed set of TLBs 22 is provided, with each individual shader core 20 being associated with its own local TLB 22 so that its corresponding TLB can cache information from translation table entries relating to the addresses recently accessed by that shader core 20. Hence, when a shader core 20 needs to issue a memory access request, the target virtual address of that request is looked up in the TLB 22 associated with that shader core 20, and if the address hits in the TLB 22, the target virtual address can be translated to a physical address using the cached address translation mapping obtained from the TLB 22. A local access permission checking unit associated with the TLB 22 may check the access permissions defined for the target virtual address, and if the permissions are violated (e.g. a write request has been issued to an address associated with a read-only permission) then a fault can be signalled. If the access passes the relevant permissions checks then the memory access request can be issued to the caches 30 or to other parts of the memory system 12, without needing the MMU 26 to perform any translation table walk operations. If the request misses in the TLB 22 then a translation request is sent to the MMU 26 which uses a translation table structure base address (defined in registers of the MMU 26) and various portions of the target virtual address to construct memory addresses of locations in memory 20 from which translation table entries can be obtained. Figure 3 illustrates an example of a shader core 20 of the GPU 6. The shader core 20 comprises a set of registers 40 for storing instruction operands and results. An instruction decoder 42 decodes GPU instructions (defined in a GPU instruction set architecture supported by the GPU 6) fetched from memory 12, to control processing circuitry 44 to perform corresponding processing operations with reference to operands obtained from registers 40. Load / store operations processed by the processing circuitry 44 in response to load / store instructions cause access requests to be issued to access data in the shader core’s local cache 48, the GPU caches 30 and / or memory 12, with addresses for the load / store operations being translated based on the local TLB 22 and / or MMU 26 as described above. A control fabric interface 50 is provided to handle issuing of requests to other GPU components or the wider processing system 2 via the GPU control fabric 24 and handle receipt of responses to those requests or commands from other GPU components. In this example, the shader core 20 includes a ray tracing unit 46, which provides specialized hardware for supporting ray tracing operations, for determining properties of a rendered frame based on modelling light transport of rays of light. Any known ray tracing technique may be used for the ray tracing circuitry. The instruction decoder 42 and processing circuitry 44 in the shader core 20 support a GPU ISA, which defines, among other features, an instruction set defining the set of instructions available for execution by the processing circuitry 44 under control of the instruction decoder 42, and a set of architectural registers which can be referenced by the instructions. As shown in Figure 4A, one class of instruction supported in the GPU ISA may be a masked load / store instruction, which specifies, using a register bitmask operand, a set of target registers for which data transfers to / from memory system locations are to be performed. In this example, a masked load instruction LOADW and a masked store instruction STOREW are shown as two examples of such a masked load / store instruction. The masked load and masked store instructions each specify as operands: at least one address operand, ADDR, defining a base address #A for a region of memory address space to / from which data transfers are to be performed (for conciseness, Figure 4A shows an example with a single address operand, ADDR, but other examples could define #A using more than one address operand, e.g. a base address and an offset parameter); the register bitmask operand, MASK, which specifies a bitmask comprising a set of bitfields each corresponding to a corresponding register group comprising one or more registers and indicating whether the corresponding register group should be considered masked or non-masked. at least one further register selection operand, in this example expressed as one or more source register range operands (SRC_RANGE) for the STOREW instruction or destination register range operands (DST_RANGE) for the LOADW instruction, both of which indicate a start register identifier X and an end register identifier Y representing range boundaries of a continuous range of registers identifiers corresponding to a set of selected registers. Other examples could represent selected registers in a different format, such as using a second bitmask similar to the bitmask operand MASK. In this particular example, for the bitmask operand MASK, each bitfield comprises a single bit and corresponds to a register group comprising a single register, with an encoding of a bit of 1 indicating a non-masked register and an encoding of a bit of 0 indicating a masked register. However, other examples could group registers in groups of two or more registers corresponding to a single bitfield, in which case a given bitfield of the MASK operand would indicate whether each of the registers in the corresponding group of two or more registers is masked or nonmasked. Also, it is possible to use bitfields with more than one bits, so that the masked / non-masked status can be indicated for the corresponding register group as well as other information concerning that register group being encoded using the same bitfield. Also, the mapping of 1 for non-masked register groups and 0 for masked register groups could be inverted, and other examples could use 0 or another encoding of a bitfield to represent non-masked register groups and 1 or another encoding of a bitfield to represent masked register groups. Hence, there are a wide variety of encoding options for the bitmask operand MASK. However, in general the bitmask operand provides the flexibility to encode any arbitrary selection of whether each register group is either masked or non-masked. The register bitmask operand, MASK, and the further register selection operand(s), SRC_RANGE or DST_RANGE, together define a minimum set of target registers for which data transfers are to be performed. A given register is a target register for a data transfer if it (i) is in a non-masked register group indicated by the register bitmask operand MASK, and (ii) is indicated as a selected register by the further register selection operand(s) (e.g. in the case of SRC_RANGE or DST_RANGE, this is satisfied if the register identifier of the given register is within the range X to Y inclusive). Registers which are masked or which are not indicated as selected by the further register selection operand(s) do not need to be considered part of the target set of registers. If a given register is selected as a target register for which a data transfer is to be performed, then for the masked store instruction STOREW, the data transfer is a store operation to store data read from the given register to a memory system location having an address calculated from the address #A derived from the address operand ADDR, and for the masked load instruction LOADW, the data transfer is a load operation to load the given register with data read from the memory system location having an address calculated from the address #A derived from the address operand ADDR. In either case, the address of the memory system location to / from which the data for the given register (with register identifier i) is transferred is computed as an address #A+offset[i] which corresponds to the sum of the base address #A and an offset, offset[i] specific to that given register i. The offset[i] for the given register i is computed independent of the register bitmask operand, MASK (so MASK does not influence the selection of the offset at all). Hence, the mapping of the offset used for a particular register stays static regardless of which registers are masked or unmasked by the MASK operand. In this particular example, the offset[i] corresponding to the register with register identifier i is computed as (i-X)*size, where X is the start register identifier for the range indicated by the range operand (SRC_RANGE or DST_RANGE) and “size” is a size multiple indicating the size of the data corresponding to a single register (e.g. 32 bits, 64 bits, or greater). Hence, as shown schematically in Figure 4A for one particular example of the instruction where X=0, Y=4 and the MASK operand indicates a bitmask of [1,0, 0, 1,0, ... ], with the left hand element of the mask recited here denoting the bitfield corresponding to register 0 and subsequent elements corresponding to register ID 1, 2, 3, 4, etc., this would cause a data transfer between non-masked register ID 0 and the memory system location having address #A and a data transfer of data between non-masked register ID 3 and the memory system location having the address #A+3*size. The intervening memory locations with addresses #A+size and #A+2*size are skipped over and do not require corresponding load / store operations to be performed, and so load / store requests for these locations can be omitted (at least in some micro-architectural hardware implementations). Meanwhile, as the range operand indicates that the end of the selected register range is register Y=4, then registers with register IDs 5 onwards are not required to be selected within the target register set. In some examples, the GPU ISA may leave flexibility for system designers to decide how store operations are handled for addresses corresponding to the non-target registers, by allowing for the memory system locations corresponding to non-target registers for a STOREW instruction to become undefined following execution of the STOREW instruction. For example, some memory system implementations may find it more efficient to implement load / store requests in blocks of a certain minimum size (e.g. cache line size), so if that size is larger than the data corresponding to one register, it may be simpler to request a store to the full block regardless of whether all the locations in the block are architecturally required to be updated based on the contents of corresponding registers selected as being within the target set of registers. Hence, although indicated as masked in the STOREW example of Figure 4A, some implementations may nevertheless cause memory writes to take place to the locations at addresses #A+size and #A+2*size. This may simplify hardware implementation in some examples. Other GPU ISA implementations may be more restrictive in requiring that the STOREW instruction leaves the memory system locations corresponding to masked or non-selected registers unchanged, which places more onus on a system implementation to mask out the unneeded data transfer operations. Either way, by providing the architectural encoding of the operands MASK, SRC_RANGE / DST_RANGE, this gives information to the processor implementation which would not otherwise be available, enabling some system implementations, if they choose to, to make more efficient use of memory bandwidth by eliminating at least some unneeded memory transfer operations which relate to registers not indicated as target registers by the MASK and SRC_RANGE / DST_RANGE operands. In contrast, a GPU ISA not supporting the MASK operand would be forced to perform data transfers for all of the register with IDs in the range X to Y, regardless of whether any such registers are likely to need preserving or restoring. Figure 4B shows another example, based on the same encoding of the instructions STOREW, LOADW, but with different values for the range X = 2 to Y = 4 indicated by the further register selection operand. Although the range of selected registers now starts at X = 2, the mapping of the bitmask fields to respective register groups remains the same as in Figure 4A, so the bitmask is treated as an absolute mask, not a mask relative to the range selected by X and Y. Hence, the first field in the bitmask still corresponds to register 0, even though register 0 is not within the selected range. The masked / non-masked status indicated by bitfields of the MASK operand which correspond to register groups entirely outside the selected range X to Y does not influence the result of the instruction. Hence, with the bitmask set in the same way as in Figure 4A (with values [1, 0, 0, 1, 0, ...]), in Figure 4B the first non-masked register, register 0, does not have a corresponding data transfer performed as it is not within the selected range X=2 to Y=4. Although the mapping of the MASK operand does not change with the selected range, the addresses selected for data transfers of any registers in the target set of registers do vary based on the parameter X defining the start of the range, as the offset[i] is computed as (i-X)*size, to make more efficient use of memory space by skipping over offsets corresponding to the registers with IDs less than X. A reason why it can be desirable for the offset[i] to depend on the further register selection parameter(s), e.g. SRC_RANGE / DST_RANGE, but be independent of the bitmask parameter, MASK, is that, when in use, it is anticipated that the bitmask parameter, MASK, would be set by caller program code and the further register selection parameter(s) would be set by the callee program code which includes the masked load / store instruction, and so to ensure a compiler of the callee program code can be compiled with statically determinable memory addresses representing the locations to which each target register is stored (irrespective of information provided by the callee program code), it may be preferable to make the offset[i] independent of the MASK operand. Figure 5 illustrates a method comprising steps for processing a masked load / store instruction. At step 100, the instruction decoding circuitry 42 decodes an instruction of the GPU ISA supported by the GPU 6. At step 102, the instruction decoding circuitry 42 determines whether the decoded instruction is a masked load / store instruction, and if not then at step 100 for another type of instruction is processed. If the instruction is a masked load / store instruction, then at step 106 the processing circuitry 44, under control of the instruction decoding circuitry 42, identifies a target set of registers based at least on a register bitmask operand specified by the masked load / store instruction (and as noted above, optionally also based on at least one further register selection operand, such as one or more operands defining a register ID range X to Y). At step 108, for each register in the target set of registers, a load / store operation is performed to transfer data between that register and the memory system location having an address determined based on an address operand of the masked load / store instruction. A specific use case for the masked load / store instruction is now described. It will be appreciated that this is just one use case for the instruction, and the same instruction may also be used for other scenarios. However, this use case addresses a problem which commonly arises in GPUs, which is sufficiently frequently occurring that the addition of the masked load / store instruction to a GPU ISA can justify the encoding space and hardware implementation complexity associated with introducing that instruction. It will be appreciated that when designing an ISA, there can be a significant design challenge in determining the set of processing operations to be supported in the ISA and the encoding of the instructions to represent those operations. In principle there may be a wide variety of different types of processing operation which may be useful to the support for some program applications, but within the encoding space available it may not be possible to represent every possible data processing operation which could be useful to a particular programmer or compiler. There may be a restriction on the number of bits available for encoding each instruction, because increasing the instruction bit width would incur additional circuit area and power consumption each time the instruction is stored anywhere within the processing system or is transferred over wired processing paths between logic elements. To limit hardware and power costs, an instruction bit width may be selected which, when taking account of the need to encode operand values through register specifiers and / or immediate values, leaves an opcode space which is insufficient to represent every possible data processing operation which could be desired. Therefore, a design decision would need to be made as to which subset of operations are the most important to support, and any operations which cannot be supported in a single instruction would then have to be performed using sets of multiple instructions with equivalent functionality when executed together. Hence, the design decisions made by the ISA designer when planning the instruction encoding of the ISA may have a significant effect on the real world performance achieved by processing hardware when executing a particular program, depending upon whether the instructions are available to support the operations desired. The limited encoding space means it is not typically possible to include every possible instruction that could conceivably be useful to a subset of users, so careful decisions are needed as to which instructions are most likely to be of benefit, especially as the consequences of a decision to introduce a new instruction which turns out to be rarely used and / or very difficult for hardware system designers to implement may be long lasting. Once legacy software has been written to make use of that instruction it can be very difficult, if not impossible, for an ISA designer to subsequently remove the instruction from the instruction set again - this would cause a significant loss of functionality for legacy software when executing on newer systems not supporting the instruction. Hence, the rarely used instruction may in practice need to be retained, using up scarce encoding space which then is not available if other more compelling instructions are desired to be introduced. Therefore, ISA designers can be understandably cautious at introducing new instruction types to an ISA, and a particular use case which is sufficiently frequently occurring that the instruction can be demonstrated to be of benefit is typically needed before ISA designers will consider adding that instruction. For the masked load / store instruction, such a use case has been identified, in that the masked load / store instruction helps address a GPU-specific problem which arises where it can otherwise be very difficult to identify which registers are to be preserved at function call entry and restored at function call exit, due to the use of dynamically determined function call nesting patterns (call graphs) when various graphics libraries commonly in use are executed. For example, the Vulkan ray-tracing pipeline implementation defines the concept of a pipeline library which is a collection of shaders that can be dynamically called as part of the raytracing pipeline according to what is defined in a shader binding table. This poses a problem for the compiler as the call-graph cannot be statically determined, and the possibility for link-time optimizations (LTO) are limited, due to the runtime / CPU overhead and the fact the ray-tracing pipeline supports recursion. Therefore, callers (program code that calls a function) and callees (the function code called by the caller), which may be developed by different providers, may establish a calling convention defining how the caller and callee use register state, to ensure that register state which needs to be preserved for the caller is not accidentally overwritten by the callee. A calling convention typically specifies at least: a working set of registers used to pass parameters; a set of “caller-saved” registers that can be clobbered (overwritten) by the callee, so would need the caller to preserve data from those registers by saving to memory prior to calling the callee, if the caller still needs the information after the return from the callee function; a set of “callee-saved” registers that the caller will assume will be preserved by the callee, so that on return from the callee those registers will have the same value as stored in those registers when the callee function was called. If the callee needs to use those registers, the callee is responsible for saving state from those registers to memory at function entry and restoring state from those registers at function exit. It is noted that such a calling convention is a protocol agreed between software developers of the caller and callee program code, and is not a feature of the hardware platform. If the callee has no information regarding which registers are live on the caller side, the compiler of the callee program code would need to statically generate program code that saves / restores to / from memory the intersection between the set of callee-saved registers and the registers used by the function body of the callee program code. However, this has profound performance implications, particularly on architectures with a large number of registers available like GPUs (e.g. register sets with 64+ architectural registers). This is something that is typically solved by LTO, but, as explained above, it is not always possible to use these techniques due to added runtime / CPU overhead, given dynamically varying call-graph patterns. Therefore, it can be very difficult to establish an appropriate calling convention which would handle all possible call-graph patterns, and so often the callee program code has to resort to saving / restoring many registers as a precaution in case they were being used by the caller, even though often many of such callee-saved registers may not actually have been live at the caller and so could have been clobbered by the callee without state saving / restoration being needed. The masked load / store instruction discussed above proposes a GPU ISA extension to enable hardware system designers, if they wish to, to avoid unneeded memory operations, and therefore reduce bandwidth, by allowing a mask to be provided from the caller that defines the register liveness at the call-site. The instructions are proposed as wide memory load / store instructions encoded as shown in Figure 4A using a format such as: • 'LOADWdst-range, addr, mask' • 'STOREW src-range, addr, mask' The mask is a bitset that is interpreted by the GPU hardware such that a bit set at position 'n' means that the 'n-th' register (i.e. 'rn') will be updated by the 'LOADW and stored by the 'STOREW' opcodes if 'rn' is part of the 'dst' and 'src' register ranges. If the 'n-th' bit is unset, the memory operation won't affect the state of the 'rn' or the memory location mapped at the corresponding location. Note that depending on the number of registers in the architecture or other operand restrictions, one could decide to map one bit in the mask to a group of registers (e.g. mapping to cache-line width) so that beside avoiding updating the register, full fetches from memory can be avoided if none of the registers in a group are live. In use, this instruction can be used to improve efficiency of function calls with fixed ABI (application binary interface), such as ray-tracing pipelines. On the caller side the compiler may compute register liveness when jumping into another shader in the pipeline library and provide that as an additional parameter to the callee. This can be easily determined at compile time, for example: MOVrO, Oxe / / [r1:r2:r3] live JUMP #callee-addr (in this example, the callee does not need any additional arguments other than the liveness mask rO). On the callee side, whhen entering / exiting the function, assuming the liveness mask is passed in rO', the callee can generate code in the form: AND rO, rO, callee-used-regisers STOREWrX:rY, stackO, rO STOREWrY:rZ, stackl, rO ... callee-code (rO-preserved)... LOADWrY:rZ stackl, rO LOADW rX:rY stackO, rO Depending of what is specified in the register ranges YX:rY', YY:rZ', these operations can be effectively be ignored by the hardware if the intersection of range with the provided mask yield a 0. Hence, Figure 6 shows an example use case for the masked load / store instruction, used within callee program code to mask out load / store operands based on a register bitmask operand derived from a register liveness argument passed from the caller. It will be appreciated that Figure 6 shows steps performed by specific software that could be executed on the GPU 6, so these steps are not features that are required by the GPU hardware itself (note that the software executing on the GPU 6 is supplied by the user at runtime and so is not a platform feature supplied in the hardware platform - different software may execute on the same platform). Also, Figure 6 divides the steps into steps performed by the caller and callee respectively. As the caller and callee program code may be supplied as separate commercial products by different software suppliers, it is not essential for a single marketed software product to include both the caller and callee steps. In some examples, the callee steps may be provided as an independent product, separate from the caller steps which are performed by other software which may at runtime operate in conjunction with the callee program code. Therefore, steps 200, 202, 214 shown in Figure 6 are not essential features of a computer program written to implement the callee program code. As shown in Figure 6, at step 200 the caller program code sets a register liveness argument specifying which registers are masked registers which do not need to be preserved by callee function code. For example, the register liveness argument could have a similar encoding to the MASK operand described above, which indicates various register groups as either masked or non-masked. At step 202 the caller program code calls the callee function program code (it is assumed for conciseness in Figure 6 that any saving of caller-saved register state to memory has already taken place before the method of Figure 6 is performed). At step 204, the callee program code determines the register bitmask operand, MASK, for a subsequent masked store instruction, based on the register liveness argument passed by the caller. For example, the register liveness argument may be combined in a logical AND operation with a value defining which registers will be used in the function body of the callee program code, so that the callee program code can add additional masked register groups to the set of masked registers for which state save / restore operations can be suppressed. In other examples, the register bitmask operand, MASK, may equal the register liveness argument with no other changes applied by the callee program code prior to use of the register bitmask operand for a masked load / store instruction. At step 206, at least one masked store instruction is executed by the callee program code, to preserve callee-saved register state information from a target set of registers selected based on the register bitmask operand (with any masked register groups being allowed to be excluded from the target set of registers). At step 208, the callee program code continues with the function body of the callee function. For example, the function body may comprise a shader program including ray tracing processing. The register liveness argument and / or register bitmask operand is preserved during processing of the function body (either by leaving that register unchanged or by saving the register liveness argument and / or register bitmask operand to memory and subsequently restoring it after completing the function body). This enables one or more masked load instructions executed at step 210 to once more identify the target set of registers based on the register bitmask operand (expected to correspond to the target set of registers that were identified at step 206), so that the previously saved callee-register state information can be restored to the target set of registers ready for the function return operation to be performed at step 212 (again, with masked registers not being required to be restored at this step). The function return causes a branch back to the caller program code, which then continues with caller processing at step 214, with any callee-saved register state being preserved by the callee program code so that the caller program code can proceed without any explicit state restoration operations being required for those callee-saved registers (the caller program code may still need to perform state restoration operations for caller-saved registers). Hence, by supporting the masked load / store instructions in the GPU ISA, this provides hints to the hardware that some unneeded load / store operations can be suppressed at steps 206 and 210 of Figure 6, to conserve memory system bandwidth. This can represent a significant memory bandwidth saving given the frequency with which such function calls are executed in typical graphics libraries such as ray tracing pipeline libraries. Concepts described herein may be embodied in a system comprising at least one packaged chip. The GPU 6 described earlier is implemented in the at least one packaged chip (either being implemented in one specific chip of the system, or distributed over more than one packaged chip). The at least one packaged chip is assembled on a board with at least one system component. A chip-containing product may comprise the system assembled on a further board with at least one other product component. The system or the chip-containing product may be assembled into a housing or onto a structural support (such as a frame or blade). As shown in Figure 7, one or more packaged chips 400, with the GPU 6 described above implemented on one chip or distributed over two or more of the chips, are manufactured by a semiconductor chip manufacturer. In some examples, the chip product 400 made by the semiconductor chip manufacturer may be provided as a semiconductor package which comprises a protective casing (e.g. made of metal, plastic, glass or ceramic) containing the semiconductor devices implementing the GPU 6 described above and connectors, such as lands, balls or pins, for connecting the semiconductor devices to an external environment. Where more than one chip 400 is provided, these could be provided as separate integrated circuits (provided as separate packages), or could be packaged by the semiconductor provider into a multi-chip semiconductor package (e.g. using an interposer, or by using three-dimensional integration to provide a multilayer chip product comprising two or more vertically stacked integrated circuit layers). In some examples, a collection of chiplets (i.e. small modular chips with particular functionality) may itself be referred to as a chip. A chiplet may be packaged individually in a semiconductor package and / or together with other chiplets into a multi-chiplet semiconductor package (e.g. using an interposer, or by using three-dimensional integration to provide a multilayer chiplet product comprising two or more vertically stacked integrated circuit layers). The one or more packaged chips 400 are assembled on a board 402 together with at least one system component 404 to provide a system 406. For example, the board may comprise a printed circuit board. The board substrate may be made of any of a variety of materials, e.g. plastic, glass, ceramic, or a flexible substrate material such as paper, plastic or textile material. The at least one system component 404 comprise one or more external components which are not part of the one or more packaged chip(s) 400. For example, the at least one system component 404 could include, for example, any one or more of the following: another packaged chip (e.g. provided by a different manufacturer or produced on a different process node), an interface module, a resistor, a capacitor, an inductor, a transformer, a diode, a transistor and / or a sensor. A chip-containing product 416 is manufactured comprising the system 406 (including the board 402, the one or more chips 400 and the at least one system component 404) and one or more product components 412. The product components 412 comprise one or more further components which are not part of the system 406. As a non-exhaustive list of examples, the one or more product components 412 could include a user input / output device such as a keypad, touch screen, microphone, loudspeaker, display screen, haptic device, etc.; a wireless communication transmitter / receiver; a sensor; an actuator for actuating mechanical motion; a thermal control device; a further packaged chip; an interface module; a resistor; a capacitor; an inductor; a transformer; a diode; and / or a transistor. The system 406 and one or more product components 412 may be assembled on to a further board 414. The board 402 or the further board 414 may be provided on or within a device housing or other structural support (e.g. a frame or blade) to provide a product which can be handled by a user and / or is intended for operational use by a person or company. The system 406 or the chip-containing product 416 may be at least one of: an end-user product, a machine, a medical device, a computing or telecommunications infrastructure product, or an automation control system. For example, as a non-exhaustive list of examples, the chipcontaining product could be any of the following: a telecommunications device, a mobile phone, a tablet, a laptop, a computer, a server (e.g. a rack server or blade server), an infrastructure device, networking equipment, a vehicle or other automotive product, industrial machinery, consumer device, smart card, credit card, smart glasses, avionics device, robotics device, camera, television, smart television, DVD players, set top box, wearable device, domestic appliance, smart meter, medical device, heating / lighting control device, sensor, and / or a control system for controlling public infrastructure equipment such as smart motorway or traffic lights. Concepts described herein may be embodied in computer-readable code for fabrication of an apparatus that embodies the described concepts. For example, the computer-readable code can be used at one or more stages of a semiconductor design and fabrication process, including an electronic design automation (EDA) stage, to fabricate an integrated circuit comprising the apparatus embodying the concepts. The above computer-readable code may additionally or alternatively enable the definition, modelling, simulation, verification and / or testing of an apparatus embodying the concepts described herein. For example, the computer-readable code for fabrication of an apparatus embodying the concepts described herein can be embodied in code defining a hardware description language (HDL) representation of the concepts. For example, the code may define a register-transfer-level (RTL) abstraction of one or more logic circuits for defining an apparatus embodying the concepts. The code may define a HDL representation of the one or more logic circuits embodying the apparatus in Verilog, SystemVerilog, Chisel, or VHDL (Very High-Speed Integrated Circuit Hardware Description Language) as well as intermediate representations such as FIRRTL. Computer-readable code may provide definitions embodying the concept using system-level modelling languages such as SystemC and SystemVerilog or other behavioural representations of the concepts that can be interpreted by a computer to enable simulation, functional and / or formal verification, and testing of the concepts. Additionally or alternatively, the computer-readable code may define a low-level description of integrated circuit components that embody concepts described herein, such as one or more netlists or integrated circuit layout definitions, including representations such as GDSII. The one or more netlists or other computer-readable representation of integrated circuit components may be generated by applying one or more logic synthesis processes to an RTL representation to generate definitions for use in fabrication of an apparatus embodying the invention. Alternatively or additionally, the one or more logic synthesis processes can generate from the computer-readable code a bitstream to be loaded into a field programmable gate array (FPGA) to configure the FPGA to embody the described concepts. The FPGA may be deployed for the purposes of verification and test of the concepts prior to fabrication in an integrated circuit or the FPGA may be deployed in a product directly. The computer-readable code may comprise a mix of code representations for fabrication of an apparatus, for example including a mix of one or more of an RTL representation, a netlist representation, or another computer-readable definition to be used in a semiconductor design and fabrication process to fabricate an apparatus embodying the invention. Alternatively or additionally, the concept may be defined in a combination of a computer-readable definition to be used in a semiconductor design and fabrication process to fabricate an apparatus and computer-readable code defining instructions which are to be executed by the defined apparatus once fabricated. Such computer-readable code can be disposed in any known transitory computer-readable medium (such as wired or wireless transmission of code over a network) or non-transitory computer-readable medium such as semiconductor, magnetic disk, or optical disc. An integrated circuit fabricated using the computer-readable code may comprise components such as one or more of a central processing unit, graphics processing unit, neural processing unit, digital signal processor or other components that individually or collectively embody the concept. Figure 8 illustrates a simulator implementation that may be used. Whilst the earlier described embodiments implement the present invention in terms of apparatus and methods for operating specific processing hardware supporting the techniques concerned, it is also possible to provide an instruction execution environment in accordance with the embodiments described herein which is implemented through the use of a computer program. Such computer programs are often referred to as simulators, insofar as they provide a software based implementation of a hardware architecture. Varieties of simulator computer programs include emulators, virtual machines, models, and binary translators, including dynamic binary translators. Typically, a simulator implementation may run on a host processor 730, optionally running a host operating system 720, supporting the simulator program 710. In some arrangements, there may be multiple layers of simulation between the hardware and the provided instruction execution environment, and / or multiple distinct instruction execution environments provided on the same host processor. Historically, powerful processors have been required to provide simulator implementations which execute at a reasonable speed, but such an approach may be justified in certain circumstances, such as when there is a desire to run code native to another processor for compatibility or re-use reasons. For example, the simulator implementation may provide an instruction execution environment with additional functionality which is not supported by the host processor hardware, or provide an instruction execution environment typically associated with a different hardware architecture. An overview of simulation is given in “Some Efficient Architecture Simulation Techniques”, Robert Bedichek, Winter 1990 IISENIX Conference, Pages 53 - 63. To the extent that embodiments have previously been described with reference to particular hardware constructs or features, in a simulated embodiment, equivalent functionality may be provided by suitable software constructs or features. For example, particular circuitry may be implemented in a simulated embodiment as computer program logic. Similarly, memory hardware, such as a register or cache, may be implemented in a simulated embodiment as a software data structure. In arrangements where one or more of the hardware elements referenced in the previously described embodiments are present on the host hardware (for example, host processor 730), some simulated embodiments may make use of the host hardware, where suitable. The simulator program 710 may be stored on a computer-readable storage medium (which may be a non-transitory medium), and provides a program interface (instruction execution environment) to the target code 700 (which may include applications, operating systems and a hypervisor) which is the same as the interface of the hardware architecture being modelled by the simulator program 710. Thus, the program instructions of the target code 700 described above, including masked load / store instructions as discussed earlier, may be executed from within the instruction execution environment using the simulator program 710, so that a host computer 730 which does not actually have the hardware features of the apparatus 2 discussed above can emulate these features. For example, the simulator code 710 may include instruction decoding program logic 712 configured to decode instructions of the target program code according to a GPU instruction set architecture; and processing program logic 714 configured to control the host data processing apparatus to perform data processing corresponding to the instructions decoded by the instruction decoding program logic 712. The instruction decoding program logic 712 could for example include instructions defining “if-then-else” or conditional branch instruction functionality which selects which subsequent instructions of the simulator code 710 are executed based on analysis of the encoding of an instruction of the target code 700. The processing program logic 714 may correspond to function routines selected by the instruction decoding program logic 712 based on the instruction encoding. The simulator code 710 can also include register emulating program logic 716 and simulated memory access program logic 718 which map simulated accesses to registers and a simulated memory address space, respectively, onto corresponding storage provided by the host hardware 730 (e.g. mapping simulated register state and memory onto the virtual address space supported by the host operating system 720 and hardware 730). Hence, in response to a masked load / store instruction specifying an address operand and a register bitmask operand specifying a plurality of mask bitfields, each mask bitfield corresponding to a register group of one or more registers and indicating whether that register group is masked or non-masked, the instruction decoding program logic 712 controls the processing program logic 714 (with assistance from the register emulating program logic 716 and / or simulated memory access program logic 718) to perform a simulated load / store operation in respect of each register within a target set of registers identified based at least on the register bitmask operand (the target set of registers being permitted to exclude registers of register groups indicated as masked by the register bitmask operand, and the simulated load / store operation for a given register in the target set of registers comprising a simulated data transfer between the given register and a simulated memory system location determined based on the address operand). Such a simulator program 710 can be helpful during software development for a GPU ISA which is still in development, to enable the software intended to run on hardware supporting that GPU ISA to be developed and tested before any real hardware is ready yet. This can allow software development for the new GPU ISA version to be developed in parallel with ongoing development of hardware supporting the new GPU ISA. In the present application, the words “configured to...” are used to mean that an element of an apparatus has a configuration able to carry out the defined operation. In this context, a “configuration” means an arrangement or manner of interconnection of hardware or software. For example, the apparatus may have dedicated hardware which provides the defined operation, or a processor or other processing device may be programmed to perform the function. “Configured to” does not imply that the apparatus element needs to be changed in any way in order to provide the defined operation. In the present application, lists of features preceded with the phrase “at least one of’ mean that any one or more of those features can be provided either individually or in combination. For example, “at least one of: [A], [B] and [C]” encompasses any of the following options: A alone (without B or C), B alone (without A or C), C alone (without A or B), A and B in combination (without C), A and C in combination (without B), B and C in combination (without A), or A, B and C in combination. 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 those precise embodiments, and that various changes and modifications can be effected therein by one skilled in the art without departing from the scope of the invention as defined by the appended claims.

Claims

1. A graphics processing unit (GPU) comprising:instruction decoding circuitry configured to decode instructions according to a GPU instruction set architecture; andprocessing circuitry configured to perform data processing in response to instructions decoded by the instruction decoding circuitry; in which:in response to a masked load / store instruction specifying an address operand and a register bitmask operand specifying a plurality of mask bitfields, each mask bitfield corresponding to a register group of one or more registers and indicating whether that register group is masked or non-masked:the instruction decoding circuitry is configured to control the processing circuitry to perform a load / store operation in respect of each register within a target set of registers identified based at least on the register bitmask operand, the register bitmask operand indicating which register groups are masked register groups which are permitted to be excluded from the target set of registers, and the load / store operation for a given register in the target set of registers comprising transferring data between the given register and a memory system location determined based on the address operand.

2. The GPU according to claim 1, in which the masked load / store instruction specifies a register identifier indicating a register providing the register bitmask operand.

3. The GPU according to any of claims 1 and 2, in which the masked load / store instruction also specifies a further register selection operand, and in response to the masked load / store instruction, the processing circuitry is configured to identify the target set of registers based on the further register selection operand and the register range operand.

4. The GPU according to claim 3, in which each register in the target set of registers comprises a register for which a corresponding register group is indicated as non-masked by the register bitmask operand and which is indicated as being a selected register by the further register selection operand.

5. The GPU according to any of claims 3 and 4, in which the further register selection operand comprises a register range operand indicating a range of register identifiers.

6. The GPU according to any of claims 3 to 5, in which a mapping between the plurality of mask bitfields of the register bitmask operand and register identifiers of registers in register groupscorresponding to the plurality of mask bitfields is an absolute mapping which is independent of a value of the further register selection operand.

7. The GPU according to any preceding claim, in which the processing circuitry is configured to determine an address of the memory system location to or from which the data for the given register is transferred in the load / store operation, wherein said address of the memory system location is independent of the register bitmask operand.

8. The GPU according to any preceding claim, in which each register group comprises a single register.

9. The GPU according to any of claims 1 to 7, in which each register group comprises at least two registers.

10. The GPU according to any preceding claim, in which the register bitmask operand has an encoding capable of indicating, for each register in a register set comprising at least 64 registers, whether that register is masked or unmasked.

11. The GPU according to any preceding claim, comprising ray tracing circuitry configured to perform ray tracing.

12. A system comprising:the GPU according to any preceding claim, implemented in at least one packaged chip;at least one system component; anda board, wherein the at least one packaged chip and the at least one system component are assembled on the board.

13. A chip-containing product comprising the system of claim 12, wherein the system is assembled on a further board with at least one other product component.

14. Computer-readable code for fabrication of a GPU according to any of claims 1 to 11.

15. A computer program comprising instructions which, when executed by a host data processing apparatus, control the host data processing apparatus to provide an instruction execution environment for execution of target program code, the computer program comprising:instruction decoding program logic configured to decode instructions of the target program code according to a GPU instruction set architecture; andprocessing program logic configured to control the host data processing apparatus to perform data processing corresponding to the instructions decoded by the instruction decoding program logic; in which:in response to a masked load / store instruction specifying an address operand and a register bitmask operand specifying a plurality of mask bitfields, each mask bitfield corresponding to a register group of one or more registers and indicating whether that register group is masked or non-masked:the instruction decoding program logic is configured to control the processing program logic to perform a simulated load / store operation in respect of each register within a target set of registers identified based at least on the register bitmask operand, the register bitmask operand indicating which register groups are masked register groups which are permitted to be excluded from the target set of registers, and the simulated load / store operation for a given register in the target set of registers comprising a simulated data transfer between the given register and a simulated memory system location determined based on the address operand.

16. A method comprising:obtaining, as a function argument for callee function program code executed on a GPU supporting a GPU instruction set architecture, a register liveness argument specifying which registers of the GPU instruction set architecture need to be preserved by the callee function program code; andexecuting a masked load / store instruction specifying an address operand and specifying a value dependent on the register liveness argument as a register bitmask operand, the register bitmask operand specifying a plurality of mask bitfields, each mask bitfield corresponding to a register group of one or more registers and indicating whether that register group is masked or non-masked;wherein the masked load / store instruction controls the GPU to perform a load / store operation in respect of each register within a target set of registers identified based at least on the register bitmask operand, the register bitmask operand indicating which register groups are masked register groups which are permitted to be excluded from the target set of registers, and the load / store operation for a given register in the target set of registers comprising transferring data between the given register and a memory system location determined based on the address operand.

17. The method according to claim 16, in which the callee function program code comprises shader program code.

18. The method according to any of claims 16 and 17, in which the callee function program code comprises ray tracing processing.5 19. A computer program comprising instructions which, when executed by a GPU, control the GPU to perform the method of any of claims 16 to 18.

Images