Method and hardware logic for writing ray tracing data from a shader processing unit of a graphics processing unit

Abstract

The invention relates to methods and hardware logic for writing ray tracing data from a shader processing unit of a graphics processing unit. A shader processing unit for a graphics processing unit, the shader processing unit configured to execute one or more ray tracing shaders, the one or more ray tracing shaders generating ray data associated with one or more rays. The ray data for a ray comprises a plurality of ray data elements. The shader processing unit comprises local storage and storage logic. The storage logic is configured to receive, as part of a ray tracing shader, a ray storage instruction, the ray storage instruction comprising: (i) information identifying a storage group of a plurality of storage groups, each storage group of the plurality of storage groups comprising one or more ray data elements of the plurality of ray data elements, and (ii) information identifying one or more ray data elements of the identified storage group to be stored in an external unit.

Description

TECHNICAL FIELD

[0001] The present application relates to methods and hardware logic for writing ray tracing data from a shader processing unit of a graphics processing unit. BACKGROUND

[0002] A graphics processing unit (GPU) is hardware designed to accelerate the generation of rendered output (e.g., images). Many GPUs today generate rendered output (e.g., images) by processing graphics data according to one or more programmable shaders. In cases where a GPU supports ray tracing, the GPU can include one or more shader processing units capable of executing one or more ray tracing shaders to perform various functions such as, but not limited to, generating rays, determining intersections, and processing intersections. As known to those skilled in the art, a ray tracing shader operates on and / or generates ray data (e.g., origin coordinates, direction coordinates, intersection max / min distances, acceleration structures) associated with one or more rays. The ray data associated with a ray can be quite large, and thus, the ray data or portions thereof associated with a ray that a ray tracing shader is currently processing can be dynamically loaded into and / or written out of the shader processing unit as needed or as generated, respectively. Being able to efficiently load ray data into and / or write ray data out of a shader processing unit can improve the performance of the shader processing unit, and thus, the GPU.

[0003] The implementations described below are provided solely for the purpose of providing examples and do not limit or restrict the particular implementation that addresses any or all of the shortcomings of known shader processing units capable of executing ray tracing shaders. SUMMARY

[0004] This summary is provided to introduce some concepts of the disclosure, which is further described below in the detailed description. This summary is not intended to identify key or essential features of the claimed subject matter, nor is it intended to be used in limiting the scope of the claimed subject matter.

[0005] Described herein are shader processing units for graphics processing units configured to execute one or more ray tracing shaders that generate ray data associated with one or more rays. The ray data for a ray includes a plurality of ray data elements. The shader processing unit includes a local storage and storage logic. The storage logic is configured to receive, as part of a ray tracing shader, a ray store instruction that includes (i) information that identifies a storage group of a plurality of storage groups, each storage group of the plurality of storage groups including one or more ray data elements of the plurality of ray data elements, and (ii) information that identifies one or more ray data elements of the identified storage group to be stored in an external unit. In response to receiving the ray store instruction, the storage logic retrieves the identified ray data elements for one or more rays from the storage. The storage logic then sends one or more store requests to the external unit that cause the external unit to store the identified ray data elements for the one or more rays.

[0006] A first aspect provides a shader processing unit for a graphics processing unit configured to execute one or more shaders, the one or more shaders including one or more ray tracing shaders that generate ray data associated with one or more rays, the ray data for a ray including a plurality of ray data elements, the shader processing unit comprising: a storage; and storage logic configured to: receive a ray store instruction that includes (i) information that identifies a storage group of a plurality of storage groups, each storage group of the plurality of storage groups including one or more ray data elements of the plurality of ray data elements, and (ii) information that identifies one or more ray data elements of the identified storage group to be stored in an external unit; in response to receiving the ray store instruction, retrieve the identified ray data elements for one or more rays from the storage; and send one or more store requests to the external unit that cause the external unit to store the identified ray data elements for the one or more rays.

[0007] The information that identifies the one or more ray data elements of the identified storage group can identify a block of ray data elements of the identified storage group.

[0008] The one or more ray data elements of each storage group can be divided into one or more sets of ray data elements, and the information that identifies the one or more ray data elements of the identified storage group can include information that identifies one or more of the sets of ray data elements of the identified storage group.

[0009] Each set of ray data elements of a storage group can be associated with an offset indicating an ordering of the set of ray data elements relative to other sets of ray data elements in the storage group, and the information identifying one or more sets of ray data elements can identify sets of ray data elements associated with contiguous blocks of offsets.

[0010] The information identifying one or more ray data elements of the identified storage group can include information identifying a starting offset of a contiguous block of offsets and information identifying a number of offsets in the contiguous block of offsets.

[0011] When at least one of the identified sets of ray data elements includes two or more ray data elements, the information identifying one or more ray data elements of the identified storage group can include information identifying a ray data element of each of the at least one of the identified sets of ray data elements that includes two or more ray data elements.

[0012] The identified ray data elements of the one or more rays can be sent to the external unit in a plurality of storage transactions, each storage transaction including up to a predetermined maximum number of ray data elements; the storage logic can be configured to divide the identified ray data elements of the one or more rays into the plurality of storage transactions; and the one or more storage requests sent from the storage logic to the external unit can include a storage transaction request for each of the plurality of storage transactions.

[0013] Each storage transaction can include ray data elements associated with a same ray of the one or more rays.

[0014] The ray data elements of each storage group can be divided into one or more blocks of ray data elements, and each storage transaction can include ray data elements in a same block of ray data elements.

[0015] Each block of ray data elements for a storage group can include one or more of the one or more sets of ray data elements of the storage group.

[0016] Each block of ray data elements for a storage group can include a set of ray data elements of the storage group associated with a contiguous block of offsets.

[0017] Each storage transaction request can include information identifying a storage group identified in the ray storage instruction, information identifying a block of ray data elements of the storage group, information identifying a ray data element of the block identified in the ray storage instruction, information identifying a ray of the one or more rays, and the identified ray data element.

[0018] The storage logic can be configured to divide the identified ray data elements of the one or more rays into the plurality of storage transactions by, for each ray of the one or more rays, determining which blocks of ray data elements of the identified storage group include the identified ray data elements, and for each block of ray data elements that includes an identified ray data element, generating a storage transaction request to store the identified ray data elements in the block for the ray.

[0019] The ray storage instruction can be associated with a plurality of rays, and the one or more rays for which the identified ray data elements are to be stored are active rays of the plurality of rays.

[0020] The ray storage instruction can further include information identifying a location in a storage device to store the identified ray data elements, and the storage logic can be configured to retrieve the identified ray data elements from the identified location.

[0021] Each storage group of the plurality of storage groups can be associated with a unique identifier, and the information identifying the storage group can include the unique identifier associated with the storage group.

[0022] A second aspect provides a method of processing a ray tracing shader at a shader processing unit of a graphics processing unit, the shader processing unit being configured to execute one or more shaders including one or more ray tracing shaders that generate ray data associated with one or more rays, the ray data of a ray including a plurality of ray data elements, the method comprising: receiving, at the shader processing unit, a ray storage instruction including (i) information identifying a storage group of a plurality of storage groups, each storage group of the plurality of storage groups including one or more ray data elements of the plurality of ray data elements, and (ii) information identifying one or more ray data elements of the identified storage group to be stored in an external unit; responsive to receiving the ray storage instruction, retrieving, from a storage device of the shader processing unit, identified ray data elements of one or more rays; and sending, from the shader processing unit to the external unit, one or more storage requests that cause the external unit to store the identified ray data elements of the one or more rays.

[0023] A third aspect provides a shader processing unit configured to perform the method of the second aspect.

[0024] A fourth aspect provides a graphics processing unit including the shader processing unit of the first or third aspect.

[0025] The graphics processing unit can further include an external unit that can include one or more local memory units and be configured to map the ray data elements of each load group to locations in the one or more local memory units.

[0026] The shader processing units, load units, memory units, and graphics processing units described herein can be embodied in hardware on an integrated circuit. A method of manufacturing the shader processing units, load units, memory units, and / or graphics processing units described herein at an integrated circuit manufacturing system can be provided. An integrated circuit definition data set that, when processed in an integrated circuit manufacturing system, configures the system to manufacture the shader processing units, load units, memory units, and / or graphics processing units described herein can be provided. A non-transitory computer readable storage medium having stored thereon a computer readable description of the shader processing units, load units, memory units, and / or graphics processing units described herein that, when processed in an integrated circuit manufacturing system, causes the integrated circuit manufacturing system to manufacture an integrated circuit embodying the shader processing units, load units, memory units, or graphics processing units can be provided.

[0027] An integrated circuit manufacturing system can be provided that includes: a non-transitory computer readable storage medium having stored thereon a computer readable description of the shader processing units, load units, memory units, or graphics processing units described herein; a layout processing system configured to process the computer readable description in order to generate a circuit layout description of an integrated circuit embodying the shader processing units, load units, memory units, or graphics processing units; and an integrated circuit generation system configured to manufacture the shader processing units, load units, memory units, or graphics processing units from the circuit layout description.

[0028] Computer program code for performing a method as described herein can be provided. A non-transitory computer readable storage medium having stored thereon computer readable instructions that, when executed at a computer system, cause the computer system to perform a method as described herein can be provided.

[0029] As will be apparent to those skilled in the art, the above features can be combined as appropriate, and can be combined with any of the aspects of the examples described herein. BRIEF DESCRIPTION OF DRAWINGS

[0030] Examples will now be described in detail with reference to the accompanying drawings, in which:

[0031] Figure 1 is a block diagram of an example graphics processing unit having multiple shader processing units;

[0032] Figure 2This is a schematic diagram of an example loading group of ray data elements;

[0033] Figure 3 This is a schematic diagram illustrating an example format of the ray loading instruction;

[0034] Figure 4 This is a flowchart of an example method for processing ray loading instructions;

[0035] Figure 5 This is a flowchart of the first example method for converting a ray loading instruction into multiple loading transaction requests;

[0036] Figure 6 This is a schematic diagram illustrating an example format for loading transaction requests;

[0037] Figure 7 This is a flowchart of a second example method for converting ray loading instructions into multiple loading transactions;

[0038] Figure 8 This is a schematic diagram of an example storage group for ray data elements;

[0039] Figure 9 This is a schematic diagram of an example format for optical storage instructions;

[0040] Figure 10 This is a flowchart of an example method for processing optical storage instructions;

[0041] Figure 11 This is a flowchart illustrating an example method for converting optical storage instructions into multiple storage transaction requests;

[0042] Figure 12 This is a schematic diagram illustrating an example format for storing transaction requests;

[0043] Figure 13 This is a block diagram of an example computer system in which the shader processing unit, loading unit, storage unit, and / or graphics processing unit described herein can be implemented; and

[0044] Figure 14 This is a block diagram of an example integrated circuit manufacturing system used to generate an integrated circuit, which embodies the shader processing unit, loading unit, storage unit and / or graphics processing unit described herein.

[0045] The accompanying drawings illustrate various examples. Those skilled in the art will understand that the element boundaries (e.g., boxes, groups of boxes, or other shapes) shown in the drawings represent one example of a boundary. In some examples, it may be that one element can be designed as multiple elements, or multiple elements can be designed as one element. Where appropriate, common reference numerals are used throughout the drawings to indicate similar features. Detailed Implementation

[0046] The following description presents examples by way of example so that those skilled in the art can practice and use the present application. The present application is not limited to the embodiments described herein and various modifications to the disclosed embodiments will be apparent to those skilled in the art. The embodiments are described by way of example only.

[0047] As described above, many GPUs today generate rendering output (e.g., images) by processing graphics data according to one or more programmable shaders. As known to those skilled in the art, shaders are programs that are run by the GPU, which are generally but not necessarily used to implement rendering effects. They are called shaders because they traditionally control lighting and shading effects, but they can also be used to implement other effects. The shaders that are applied to the graphics data depend on the rendering technique used to generate the rendering output.

[0048] Two example rendering techniques used to generate rendering output are rasterization and ray tracing. In rasterization, the geometry of each object is constructed using a mesh of primitives (e.g., triangles), and then shaded to determine its appearance. In rasterization, the geometry data can be processed in two stages - a geometry processing stage and a rasterization stage. In the geometry processing stage, geometry data (e.g., vertices defining primitives or patches) received from an application program is transformed into rendering space (e.g., screen space). Other functions such as clipping and culling can also be performed in the geometry processing stage to remove geometry (e.g., primitives or patches) that falls outside a view frustum, and / or lighting attribute processing can be performed. During the rasterization stage, the transformed primitives are mapped to pixels and a color is identified for each pixel. This can include rasterizing the transformed geometry data (e.g., by performing scan conversion) to generate primitive fragments. Hidden (e.g., hidden by other fragments) primitive fragments can then be removed by a process known as hidden surface removal. Texturing and / or shading can then be applied to the unhidden primitive fragments to determine pixel values for the rendering output (image).

[0049] Shaders used to implement the rasterization technique include, but are not limited to, vertex shaders, which are used to transform properties of geometry (e.g., primitive) vertices, such as color, texture, position, and direction; geometry shaders, which can dynamically create new geometry; and pixel or fragment shaders, which are configured to operate on individual pixels or fragments to implement complex visual effects.

[0050] Unlike rasterization, where the effect of light on an image is only an approximation, ray tracing simulates how light works in the real world. Specifically, ray tracing sends light rays from the user's viewpoint into the scene, onto objects, and from there to light sources. As the light interacts with objects, depending on the object's material properties, the light rays are blocked, reflected, or refracted by objects along their path, creating shadows and reflections.

[0051] Shaders used to implement ray tracing techniques can be used for, for example, to generate rays, determine intersections, and process intersections.

[0052] Rasterization and ray tracing can be used independently or in combination.

[0053] While some GPUs have different hardware to implement or execute different shaders, many GPUs implement a unified shading architecture, where the GPU includes common or unified shader hardware that can implement or execute multiple different shaders supported by the GPU. For example, Figure 1 An example GPU 100 is shown, comprising multiple scalable processing units (SPUs) 102, each of which includes multiple shader processing units 104. Figure 1 In the example, each shader processing unit is implemented as a Unified Shading Cluster (USC), but this is merely an example. Each USC 104 can execute several different types of shader tasks supported by the GPU 100. Specifically, each USC 104 receives shader tasks from the scheduler 106. Each shader task specifies data to be processed and a shader (e.g., a program) to be used to process that data. In response to receiving a shader task, the USC 104 executes the identified shader for the identified data. Executing a shader may include executing the instruction set that forms the shader.

[0054] Each USC 104 can include a number of arithmetic logic units (ALUs) 108 that can be configured to execute particular shader instructions and local storage (e.g., registers) 110 for storing data to be processed by the USC 104, data generated by the USC 104, and / or any other data that can be used by the USC 104. The USC 104 can typically execute multiple shader tasks concurrently, and each of those shader tasks shares the local storage 110. If the GPU 100 supports ray tracing, the USC 104 can be capable of executing a ray tracing shader. Ray tracing shaders generally execute on and / or generate ray data (i.e., data associated with a ray). However, because there can be many in-flight rays (i.e., rays that are being processed), and each ray can have a large amount of data associated with it (e.g., origin coordinates, direction coordinates, intersection min / max distances, and acceleration structures), saving all of the ray data for all in-flight rays in the local storage 110 can not leave sufficient space in the local storage 110 to run other shader tasks, which can reduce the efficiency of the USC 104. Thus, all of the ray data can be stored in storage units of an external unit (i.e., a unit external to the USC 104), and portions are loaded into the USC 104 when needed by the USC 104 or written out of the USC 104 when generated thereby.

[0055] For example, as shown in Figure 1 The GPU 100 can include an external unit 112 (implemented as, by way of example, a ray acceleration cluster (RAC) in Figure 1 The USC 104 and the RAC 112 can be connected by one or more interfaces 118, 120 that allow the ray data to be transferred between the USC 104 and the RAC 112. For example, there can be a load interface 118 that allows data to be transferred from the RAC 112 to the USC 104, and there can be a separate store interface 120 that allows data to be transferred from the USC 104 to the RAC 112. In Figure 1In the example shown in FIG. 1, RAC 112 includes an interface module 122, which can be referred to as a USC-RAC interface (URI) 122, that is configured to (i) receive requests for ray data from USC 104 and provide requested data from RAC 112 storage units 114, 116 to USC 104 via a load interface 118; and (ii) receive requests from USC 104 via a store interface 120 to write ray data into one or more of RAC storage units 114, 116 and write the received data into one or more of RAC 112 storage units 114, 116. In some cases, RAC 112 can also include other components not shown in FIG. 1. For example, RAC 112 can include one or more components to accelerate certain ray tracing operations. Figure 1

[0056] To enable retrieval of ray tracing data from RAC 112 storage units 114, 116, each USC 104 can include load logic 124 that is configured to receive a load instruction that identifies ray data to be loaded into USC 104 and send a read request to RAC 112 to retrieve the identified ray data. To enable storage of ray tracing data generated by USC 104 in RAC 112 storage units 114, 116, each USC 104 can include store logic 126 that is configured to receive a store instruction that identifies ray data to be stored in RAC 112 storage units 114, 116 and send a write request to RAC 112 to store the identified ray data in RAC 112 storage units 114, 116. However, having Figure 1 GPUs of the architecture shown in FIG. 1 (or similar architectures) that are known to the applicant, but do not admit that they are well known or known outside the applicant’s company, are configured to receive and process load and store instructions that identify a single memory block (e.g., a doubleword, where a doubleword is defined as a doubleword, or 32 bits) or a contiguous block of N memory blocks (e.g., four doublewords) to be read or written at a time.

[0057] ​In such configurations, ray data can be loaded into or written out of the USC 104 one memory block at a time, or individual ray data blocks can be loaded via individual instructions. However, since the portions of ray data used and / or generated by different ray tracing shaders are often interspersed with other ray data in the RAC 112 memory units 114, 116, if ray data is requested / written on a memory block basis, this can result in a large amount of unwanted or unnecessary data being transferred between the RAC 112 and the USC 104. This leads to inefficient use of the load interface 118 and the store interface 120 between the USC 104 and the RAC 112. Moreover, while requesting / writing individual ray data blocks can allow only the needed ray data to be transferred between the RAC 112 and the USC 104, thereby more efficiently using the load interface 118 and the store interface 120 between the USC 104 and the RAC 112, this comes at the cost of the USC 104 having to store, fetch, and execute multiple instructions.

[0058] Accordingly, described herein are shader processing units (e.g., USC) having (i) load logic 124 configured to receive and process load instructions that allow ray data to be more efficiently loaded into the USC 104 from a RAC 112; and / or (ii) store logic 126 configured to receive and process store instructions that allow ray data to be more efficiently written to a RAC 112 from the USC 104. Specifically, in examples described herein, ray data includes a plurality of ray data elements, and a plurality of groups of ray data elements are defined, where each group of ray data elements includes a related set of ray data elements. Ray tracing elements can be “related” if they are often retrieved together by a ray tracing shader from or written to the RAC 112 memory units 114, 116. The USC 104 (i.e., the load logic 124 and / or the store logic 126) is then configured to (i) receive and process load instructions that allow a combination of individual ray data elements in the same group to be retrieved from an external unit (e.g., the RAC 112 memory units 114, 116) using a single instruction; and / or (ii) receive and process store instructions that allow ray data in the same group to be efficiently stored in an external unit (e.g., the RAC 112 memory units 114, 116) using a single instruction. As described in more detail below, the grouping of ray data elements for the load instructions can be different than the grouping of ray data elements for the store instructions.

[0059] Because the relevant ray data elements (those in a group) that can be dispersed throughout the storage units 114, 116 of the external unit 112 can be identified by a single load instruction, a single load instruction can be used to efficiently retrieve multiple relevant but dispersed ray data elements. Moreover, because different combinations of ray data elements in a group can be identified, time and resources are not wasted to transfer ray data elements that the ray tracing shader will not use, thereby more efficiently using the load interface 118 between the USC 104 and the RAC 112. Similarly, because the relevant ray data elements (those in a group) that can be dispersed throughout the storage of the external unit can be identified using a single store instruction, a single store instruction can be used to efficiently store multiple relevant but dispersed ray data elements.

[0060] Although Figure 1 Although the load logic 124 configured to receive and process load instructions and the separate store logic 126 configured to receive and process store instructions are shown, in other embodiments, the USC 104 can include common load / store logic configured to process both load instructions and store instructions.

[0061] Ray Load (RLOAD) Instruction

[0062] In examples described herein, the USC 104 (e.g., the load logic 124) is configured to receive and process a ray load instruction that allows for efficient retrieval of ray data from an external unit (e.g., the RAC 112). In particular, the USC 104 (e.g., the load logic 124) is configured to receive and process a ray load instruction that includes information identifying a load group of a plurality of load groups (where each load group includes a plurality of relevant ray data elements) and information identifying the ray data elements of the load group to be retrieved from the external unit (e.g., the RAC 112). Each load group is predefined to include ray data elements that are typically requested together by a ray tracing shader. Such an instruction allows the ray tracing shader to use a single instruction to efficiently load multiple ray data elements into the USC 104 storage 110.

[0063] In particular, as described above, each ray in ray tracing is associated with ray data comprising a plurality of individual ray data elements. In some cases, each ray data element is the same size (or has the same maximum size). In the examples described herein, each ray data element has a maximum size of a double word (e.g. 32 bits). However, it will be apparent to those skilled in the art that this is merely an example, and in other examples the ray data elements can have different maximum sizes. An example of ray data elements is shown in Table 1. It will be apparent to those skilled in the art that the ray data elements of Table 1 are merely examples of ray data elements, and in other examples there can be fewer ray data elements, more ray data elements and / or different combinations of ray data elements.

[0064] Table 1

[0065]

[0066] In the examples described herein, a plurality of load groups (which can also be referred to as load spaces) of ray data elements are defined. Each load group of ray data elements comprises a subset of ray data elements that can be associated with a ray. The load groups can be defined such that each load group comprises ray data elements that are likely to be requested together by one or more ray tracing shaders. For example, a shader performing an intersection query can use only the geometric information (e.g. the origin and direction of the ray), so a load group comprising ray data elements representing the geometric information can be defined; and a shader for processing an intersection between a ray and a primitive (e.g. to determine a colour) can use additional ray data elements, so a different load group comprising ray data elements representing the geometric information and one or more additional ray data elements can be defined. Thus, the particular ray data elements forming a load group can depend on the configuration of the ray tracing shaders.

[0067] Reference is now made to Figure 2which shows an example set of load groups formed from the ray data elements of Table 1. In this example, there are seven load groups labeled RID, Primary, Launch Size, Trace, Query, Call, and Debug. Each load group includes one or more ray data elements that can be requested using a single RLOAD instruction. For example, the Primary load group includes the PAYLOAD_0, PAYLOAD_1, PAYLOAD_2, LAUNCH_ID_X, LAUNCH_ID_Y, and LAUNCH_ID_Z ray data elements. This means that the ray tracing shader can use a single RLOAD instruction to request the combination of the PAYLOAD_0, PAYLOAD_1, PAYLOAD_2, LAUNCH_ID_X, LAUNCH_ID_Y, and LAUNCH_ID_Z ray data elements. Similarly, the Debug load group includes the NCM_T, NCM_INST_IN, NCM_PRIM_IN, NCM_GEOM_IN, MISS_INDEX, SBT_OFFSET, and SBT_STRIDE ray data elements. This means that the shader can use a single RLOAD instruction to request the combination of the NCM_T, NCM_INST_IN, NCM_PRIM_IN, NCM_GEOM_IN, MISS_INDEX, SBT_OFFSET, and SBT_STRIDE ray data elements. As can be seen, a ray data element can form part of only one load group, or a ray data element can form part of more than one load group. For example, the FLAGS ray data element forms part of both the Trace load group and the Query load group. Thus, a load group can not include a disjoint subset of ray data elements. In other words, two or more of the load groups can include an overlapping subset of ray data elements.

[0068] Reference is now made to Figure 3 which shows an example format of a ray load (RLOAD) instruction 300. The RLOAD instruction 300 includes a load group identifier field 302 and a ray data element set identifier field 304. The RLOAD instruction 300 can optionally include one or more other fields, some of which will be discussed below.

[0069] The load group identifier field 302 (which can also be referred to as a SPACE field or a group field) includes information that identifies one of a plurality of load groups. In some cases, each load group can be associated with a unique numeric identifier, and a particular load group is identified in an RLOAD instruction by setting the SPACE field 302 to the unique numeric identifier associated with the particular load group. In these cases, the number of bits used for the SPACE field 302 can be selected based on the number of load groups. For example, the minimum number of bits for the SPACE field 302 can be where Y is the number of load groups. Table 2 shows an example set of unique identifiers for the load groups shown in Figure 2 In this example, there are seven load groups, so the SPACE field 302 can include three bits. It will be apparent to those skilled in the art that this is merely an example.

[0070] Table 2

[0071]

[0072] The light data element set identifier field 304 includes information that identifies the light data element of the identified load group to be loaded into the USC 104. In some cases, the light data elements of a load group can be divided into sets, where each set includes one or more light data elements, and each RLOAD instruction can only load one light data element of each set of the load group into the USC 104. This means that if a load group has ten sets of light data elements, each RLOAD instruction can only load ten light data elements of that load group into the USC 104. Figure 2 Table 2 shows how the light data elements of each load group therein are divided into sets. For example, Figure 2 The light data elements of the primary load group of Table 2 are divided into six sets of light data elements, where each set has only one light data element. Specifically, set 0 includes the PAYLOAD_0 light data element, set 1 includes the PAYLOAD_1 light data element, set 2 includes the PAYLOAD_2 light data element, set 4 includes the LAUNCH_ID_X light data element, set 5 includes the LAUNCH_ID_Y light data element, and set 6 includes the LAUNCH_ID_Z light data element. Since the primary load group has six sets of light data elements, up to six light data elements of the primary load group can be loaded into the USC 104 using a single RLOAD instruction.

[0073] In contrast, the ray data elements of the trace load group are divided into 18 sets, and all of the sets, except set 7, include only a single ray data element. Specifically, set 7 includes both a CM T ray data element and a CD T ray data element. Since only one ray data element from a set can be loaded into the USC 104 using a single RLOAD instruction, only one of the CM T ray data element and the CD T ray data element can be loaded into the USC 104 using a single RLOAD instruction when identifying the trace load group.

[0074] In some cases, a set of ray data elements for a load group can include only one ray data element, or multiple mutually exclusive ray data elements of that load group. The term “mutually exclusive ray data elements of a load group” is used herein to mean ray data elements that will not be requested at the same time by a shader associated with that load group (e.g., a shader that is expected to reference that load group). For example, if one ray data element is to be used at one point in a ray tracing process, and another ray data element is to be used at another point in the ray tracing process, both ray data elements can not be requested at the same time. For example, a shader can process candidate data or committed data, but not both. Thus, a candidate ray data element (CD T) and a corresponding committed ray data element (e.g., CM T) can be considered mutually exclusive. It will be apparent to those skilled in the art that this is merely an example, and that other mutually exclusive ray data elements can exist, and that other reasons why ray data elements can be mutually exclusive can exist. In some cases, two ray data elements can be mutually exclusive for one load group, and the same two ray data elements can not be mutually exclusive for another load group.

[0075] In some cases, the ray data element set identifier field 304 can be implemented by a mask that includes multiple bits, and each ray data element set in the load group is associated with one of the bits. In these cases, the ray data element set identifier field 304 can be referred to as a MASK field. In some cases, a bit can be set to one value (e.g., ‘1’) when a ray data element in the associated set is to be retrieved, and the bit can be set to a different value (e.g., ‘0’) if no ray data element in the associated set is to be retrieved. In cases where the identified set includes only one ray data element, then setting the corresponding bit in the MASK field specifically identifies that ray data element. In this way, the MASK field allows a combination of individual ray data elements in the same load group to be requested / retrieved at the same time.

[0076] How the ray data elements of a load group are divided into ray data element sets, and which ray data element sets are associated with which bits of a mask, can be predefined.Figure 2 An example mapping of sets to MASK bits is shown. Specifically, sets 0, 1, 2, 4, 5, and 6 of the primary load group are associated with bits 0, 1, 2, 4, 5, 6 of the mask, respectively. Thus, if the SPACE field identifies the primary load group, and bits 0, 1, and 2 of the MASK field are set, then PAYLOAD_0, PAYLOAD_1, and PAYLOAD_2 ray data elements will be retrieved from an external unit (e.g., RAC 112) and loaded into the USC 104.

[0077] In some cases, the RLOAD instruction 300 can also include a destination (DST) field 306 that is used to identify which USC 104 storage 110 locations (e.g., registers) the identified ray data elements will be stored in when retrieved from an external unit (e.g., RAC 112). In some cases, the DST field 306 can identify a USC 104 storage 110 location (e.g., register) that the first identified ray data element will be written to, and the identified ray data elements are written to contiguous memory locations (e.g., registers) starting with the identified memory location.

[0078] As described above, in some cases, a set can include more than one ray data element (such a set can be referred to herein as a multi-ray data element set). In such cases, setting a corresponding mask bit does not identify a particular ray data element to be retrieved from an external unit (e.g., RAC 112). In such cases, the RLOAD instruction 300 can include a space control field 308 (which can also be referred to as a SPACE_CTRL field) that includes information identifying which ray data element of the multi-ray data element set will be retrieved. For example, in Figure 2 In the example, set 7 of the trace group is a multi-ray data element set that includes a CM_T ray data element and a CD_T ray data element. In this example, when the SPACE field identifies the trace load group and the seventh bit of the MASK field is set, the SPACE_CTRL field can be used to identify whether the CM_T ray data element will be retrieved or the CD_T ray data element will be retrieved. For example, the SPACE_CTRL field can include a single bit that identifies whether the CM_T ray data element or the CD_T ray data element will be retrieved when the SPACE and MASK fields are set as described. For example, if the CM_T ray data element will be retrieved, the SPACE_CTRL field can be set to ‘1’, and if the CD_T ray data element will be retrieved, the field can be set to ‘0’. Allowing multi-ray data element sets increases the number of combinations of ray data elements that can be retrieved using a single RLOAD instruction without increasing the number of mask bits.

[0079] exist Figure 2 In the example load groups shown, only one load group (i.e., the tracking load group) has a multi-ray data element set, and only one multi-ray data element set. However, it will be apparent to those skilled in the art that this is merely an example, and in other examples, there may be more than one load group having at least one multi-ray data element set, and one or more load groups may have more than one multi-ray data element set. In some cases, where at least one load group includes more than one multi-ray data element set, the SPACE_CTRL field 308 may include more than one bit. For example, the SPACE_CTRL field 308 may include one bit for each multi-ray data element set. For example, if the load group includes a first set containing ray data elements 0 and ray data elements 1 and a second set containing ray data elements 2 and ray data elements 3, the SPACE_CTRL field may include a first bit for selecting between ray data elements 0 and ray data elements 1, and a second bit for selecting between ray data elements 2 and ray data elements 3. In other cases, where the load group comprises more than one set of multi-ray data elements, a single bit in the SPACE_CTRL field 308 can be used to select one element from each set of multi-ray data elements. For example, if the load group comprises a first set containing ray data elements 0 and ray data elements 1 and a second set containing ray data elements 2 and ray data elements 3, the SPACE_CTRL field may include a first bit that, when set to a value (e.g., '0'), selects the first ray data element (i.e., ray data elements 0 and 2) from each set of multi-ray data elements, and when set to another value (e.g., '1'), selects the second ray data element (i.e., ray data elements 1 and 3) from each set of multi-ray data elements.

[0080] As described above, USC 104 receives shader tasks from the scheduler. Each shader task specifies the data to be processed and the shader (e.g., a program) to be used to process that data. In response to receiving a shader task, USC 104 executes the identified shader for the identified data. A ray tracing shader task can be associated with multiple rays, and the identified ray tracing shader can be applied to one or more rays. Therefore, an RLOAD instruction that runs as part of a shader task is said to be associated with multiple rays associated with the shader task, and the identified ray data element is retrieved from an external unit (e.g., RAC 112) for one or more rays associated with the RLOAD instruction.

[0081] As described in more detail below, for RLOAD instructions executed as part of a shader task, not all of the rays associated with the ray tracing shader task are ‘active’ and preferably only the ray data for the active rays is loaded into the USC 104 to avoid loading unnecessary data. The ‘active’ rays for an instruction are the rays to which the instruction is applied. Thus, in the method described below, it is determined which of the plurality of rays associated with the RLOAD instruction are active for the RLOAD instruction and only the ray data elements identified in the RLOAD instruction are retrieved for the active rays. However, in other examples, rather than determining which of the rays associated with the RLOAD instruction are active, it can be simpler to simply load the identified ray data elements for all of the rays associated with the RLOAD instruction.

[0082] The active rays for an RLOAD instruction can be set at the shader task level or the instruction level. In particular, some rays can be inactive for a ray tracing shader task such that these rays will be inactive for any RLOAD instructions executed as part of the ray tracing shader task. However, different RLOAD instructions executed as part of the same ray tracing shader task can have different active rays. For example, rays 1 and 2 associated with a ray tracing shader task can be active for a first RLOAD instruction executed as part of the ray tracing shader task and rays 3 and 4 associated with the ray tracing shader task can be active for a second, different RLOAD instruction executed as part of the ray tracing shader task.

[0083] Reference is now made to Figure 4 which shows an example method 400 of executing an RLOAD instruction at the USC 104. The method begins at block 402 where the USC 104 (e.g. the load logic 124) receives an RLOAD instruction, such as for Figure 2 to Figure 3 The cases described. As described above, the RLOAD instruction identifies a predefined load group of ray data elements (e.g. the ray data elements for the rays 1 and 2 in the example described above) to be loaded into the USC 104. The method then proceeds to block 404 where the USC 104 determines which of the rays associated with the RLOAD instruction are active for the RLOAD instruction. In the example described above, the rays 1 and 2 are active for the RLOAD instruction and the rays 3 and 4 are inactive for the RLOAD instruction. Thus, in this example, the ray data elements for the rays 1 and 2 are loaded into the USC 104 and the ray data elements for the rays 3 and 4 are not loaded into the USC 104. Figure 2the identified load group from the storage of the external unit (e.g., RAC 112) and send the identified ray data elements to the USC 104 (e.g., load logic 124). The method 400 then proceeds to blocks 406 and 408, in which the USC 104 (e.g., load logic 124) receives the identified ray data elements for each of the one or more rays through the load interface 118 and stores the received ray data elements in the USC 104 storage 110.

[0084] The load interface 118 between the external unit (e.g., RAC 112) and the USC 104 can not be large enough to receive all of the requested ray data elements in the same cycle. Thus, the USC 104 can receive the requested ray data elements over multiple cycles. The set of one or more ray data elements received in a cycle can be referred to as a load transaction. In some cases, the number of ray data elements that can be received in the same cycle (e.g., as part of the same load transaction) is based on the size of the load interface 118 and the size of the ray data elements. The size of the load interface 118 is defined as the amount of data that can be transferred at the same time. For example, if the load interface 118 is 128 bits wide and each ray data element is a double word (i.e., 32 bits), then four ray data elements can be received in the same cycle (e.g., in the same load transaction).

[0085] In some cases, the USC 104 can be configured to implement the RLOAD instruction by converting the received RLOAD instruction into multiple load transactions and sending an independent load transaction request to the external unit (e.g., RAC 112) for each load transaction. Figure 4block 404 of the method 400 (i.e., sending one or more load requests to the external unit to retrieve the identified ray data elements). In other words, the USC 104 can be configured to expand the received RLOAD instruction into multiple load transactions. For example, if it would take four load transactions for the external unit (e.g., the RAC 112) to transfer the ray data elements identified in the RLOAD instruction to the USC 104, the USC 104 (e.g., the load logic 124) can generate and transmit four load transaction requests to the external unit (e.g., the RAC 112). The USC 104 then receives the four load transactions with the identified ray data elements.

[0086] In some cases, there can be one or more types of load groups, and the techniques for converting the RLOAD instruction into multiple load transactions can be based on the type of load group identified in the RLOAD instruction. For example, the one or more types of load groups can include one or more of a per-ray (or per-instance) load group and a per-ray-block load group. The load transactions for a per-ray load group can include only ray data elements associated with the same ray (e.g., different ray data elements associated with one ray). In contrast, the load transactions for a per-ray-block load group can include the same ray data element for multiple rays. For example, the load transactions for a per-ray-block load group can include the same ray data element for a first ray and a second ray. Figure 5 An example method of converting an RLOAD instruction related to a per-ray load group into multiple load transactions is described, and for a per-ray-block load group. Figure 7 An example method of converting an RLOAD instruction related to a per-ray load group into multiple load transactions is described, and for a per-ray-block load group.

[0087] Compared to a load transaction that has light data elements from the same light ray packed together (and skipping non-active light rays), the load transaction can include more light data elements, meaning that the light data elements can be transferred across the load interface 118 with fewer load transactions (which is a more efficient use of the load interface 118). However, if there are only a few light data elements in a load group (e.g., less than the maximum number of light data elements per load transaction), this approach is not as efficient because the load transaction will never be full. Thus, in some cases, the per-light load groups can be those load groups that have more than a predetermined number (e.g., 1 or 2) of light data elements, and the per-light block load groups can be those load groups that have a predetermined number or less than a predetermined number of light data elements.

[0088] However, if the light data elements for the same light ray can be packed together in a load transaction (and skipping non-active light rays), each load transaction can include more light data elements, meaning that the light data elements can be transferred across the load interface 118 with fewer load transactions (which is a more efficient use of the load interface 118). However, if there are only a few light data elements in a load group (e.g., less than the maximum number of light data elements per load transaction), this approach is not as efficient because the load transaction will never be full. Thus, in some cases, the per-light load groups can be those load groups that have more than a predetermined number (e.g., 1 or 2) of light data elements, and the per-light block load groups can be those load groups that have a predetermined number or less than a predetermined number of light data elements.

[0089] As described above, each load transaction of each ray load group can include only ray data elements related to the same ray. For example, the load transactions of each ray load group can include the ORIGIN X, ORIGIN Y, and ORIGIN Z ray data elements of the same ray. In contrast, the load transactions of each ray load group can not include the CM T ray data element of the first ray and the CM T ray data element of the second ray. In some cases, the ray data elements of each ray load group are divided into one or more blocks, and the load transactions can include only ray data elements in the same block. In these cases, when the USC 104 (e.g., the load logic 124) receives an RLOAD instruction in which a ray load group is identified, the USC 104 (e.g., the load logic 124) can be configured to convert the received RLOAD instruction into multiple load transactions by determining which blocks of the identified load group include at least one identified ray data element, and for each block that includes at least one identified ray data element, generating and transmitting a load transaction request for the identified ray data elements in that block (for each (active) ray associated with the RLOAD instruction). Thus, in this RLOAD conversion technique, no load transaction request is issued for a null block of the identified load group - i.e., no load transaction request is generated for a block of the identified load group that does not include at least one identified ray data element. However, for each ray of one or more rays, for each block that includes at least one identified ray data element, a load transaction request is generated.

[0090] For example, assume Figure 2 Each of the example load groups shown in FIG. 4B, except for the RID load group, is a per-ray load group. In Figure 2 As can be seen in FIG. 4B, the ray data elements of each of these load groups have been divided into blocks, where the ray data elements in a block can form part of the same load transaction. For example, the ray data elements of the primary load group have been divided into two blocks (blocks 0 and 1), the ray data elements of the emission size load group form one block (block 0), the ray data elements of the tracking load group have been divided into five blocks (blocks 0, 1, 2, 3, and 4), and the ray data elements of the query load group have been divided into three blocks (blocks 0, 1, and 2), etc.

[0091] Since the maximum number of ray data elements that can be transmitted as part of a single load transaction is M, only M ray data elements in a block can be transmitted as part of a single transaction. Thus, each block can include up to M ray data element sets, where each ray data element set includes a single ray data element or a mutually exclusive set of ray data elements. This means that a transaction can include ray data elements from each set associated with a block. In the examples described herein, M is four (i.e., four ray data elements can be transmitted as part of a single load transaction), and thus Figure 2 Each of the blocks shown in FIG. 6 includes up to four ray data element sets. For example, the first block of the trace load group includes four ray data element sets (sets 0-3), where each set includes a single ray data element— i.e., set 0 includes only ORIGIN X ray data elements, set 1 includes only ORIGIN Y ray data elements, set 2 includes only ORIGIN Z ray data elements, and set 3 includes only DIRECTION X ray data elements; and the second block of the trace load group includes four ray data element sets (sets 4-7), where three of the sets include a single ray data element, and the fourth set includes two mutually exclusive ray data elements— i.e., set 4 includes only DIRECTION Y ray data elements, set 5 includes only DIRECTION Z ray data elements, set 6 includes only TMIN ray data elements, and set 7 includes the mutually exclusive CM T and CD T ray data elements.

[0092] As described above, in some cases the ray data element set identifier field 304 can be implemented as a mask (i.e., a MASK field) that includes a plurality of bits, and the ray data element sets of each load group are associated with particular bits of the mask. In such cases, the ray data elements in a block can be the ray data element sets associated with a contiguous set of mask bits (e.g., M mask bits). For example, as shown in FIG. 6, the first block of each load group can include ray data element sets associated with the first four mask bits (e.g., bits 0-3), the second block of each load group can include ray data element sets associated with the next four mask bits (e.g., bits 4-7), the third block of each load group can include ray data element sets associated with the next four mask bits (e.g., bits 8-11), and so on. As described in more detail below, this can allow the USC 104 (e.g., the load logic 124) to quickly and efficiently determine which blocks of an identified load group include at least one ray data element that has been requested / identified— and thus for which blocks to generate load transaction requests— based on the MASK field bits of the RLOAD instruction. Figure 3

[0093] ​As described above, in some cases, the external unit (RAC 112) can have multiple storage units 114, 116, and / or one or more of the storage units 114, 116 can be subdivided into multiple sections, and different ray data elements can be stored in different storage units and / or different sections of storage units. In some cases, the sets of ray data elements for a load group can be arranged into blocks such that the ray data elements stored in the same storage unit 114, 116 and / or the same section of that storage unit are in the same block to enable the remote unit (e.g., RAC 112) to more efficiently generate load transactions. In particular, load transactions that include ray data elements in the same storage unit and / or the same section thereof are faster and easier to generate than load transactions that include ray data elements from different storage units and / or sections thereof. For example, because the LAUNCH ID X, LAUNCH ID Y, LAUNCH ID Z ray data elements are stored in the same storage unit 114, 116 and the same section thereof, these ray data elements are placed in the same block of the primary load group. As shown in Figure 2 This can mean that there are gaps in the numbering of the sets of ray data elements - e.g., no set of ray data elements 3 in the primary load group - however, this can improve the efficiency and speed at which the remote unit (e.g., RAC 112) can generate load transactions.

[0094] Reference is now made to Figure 5 which shows an example method 500 that can be implemented by the USC 104 (e.g., the load logic 124) to convert the RLOAD instruction that identifies a per-ray load group into multiple load transactions. The method 500 begins at block 502, where the USC 104 (e.g., the load logic 124) initializes a current ray identifier. The current ray identifier identifies one of the multiple rays associated with the RLOAD instruction. The ray identified by the current ray identifier can be referred to as the current ray. The current ray identifier can be initialized to identify the first ray associated with the RLOAD instruction. In some cases, each of the multiple rays associated with the RLOAD instruction can be identified by a unique value. In some cases, the current ray identifier can be a counter that is initialized to a predetermined value (e.g., 0). Once the current ray identifier has been initialized, the method 500 proceeds to block 504.

[0095] At block 504, the USC 104 (e.g., load logic 124) determines whether the current ray is active. In some cases, the USC 104 can receive information identifying which rays associated with the RLOAD instruction are active along with the RLOAD instruction. If it is determined that the current ray is active, the method 500 proceeds to block 506. However, if it is determined that the current ray is not active, the method 500 proceeds directly to block 508.

[0096] At block 506, the USC 104 (e.g., load logic 124) initializes a current block identifier to identify a block (e.g., a first block) of the identified load group. The block identified by the current block identifier can be referred to as the current block. In some cases, the current block identifier can take the form of a counter, and the counter can be initialized to a predetermined value (e.g., 0). Once the current block identifier has been initialized, the method 500 proceeds to block 510.

[0097] At block 510, the USC 104 (e.g., load logic 124) analyzes the RLOAD instruction to determine whether at least one ray data element in the current block has been requested / identified. In cases where the RLOAD instruction includes a MASK field 304 and the blocks of the load group correspond to contiguous blocks of mask bits, the USC 104 (e.g., load logic 124) can be configured to analyze the mask bits corresponding to the identified block to determine whether any of the mask bits are set. In cases where RT USC DATA WIDTH is the width of the load interface 118 in bits, RAY DATA ELEMENT WIDTH is the width of each ray data element in bits, BLOCK is the current block, and MASK is the mask field of the RLOAD instruction, the bits related to the current block can be bits ((RT USC DATA WIDTH / RAY DATA ELEMENT WIDTH)*(BLOCK+1)-1) to (RT USC DATA WIDTH / RAY DATA ELEMENT WIDTH)*(BLOCK). If it is determined that at least one ray data element in the current block has been requested / identified, the method 500 proceeds to block 512, where a load transaction request is generated and sent to an external unit (e.g., RAC 112). However, if it is determined that no ray data elements in the current block have been requested, the method proceeds to block 514.

[0098] At block 512, the USC 104 (e.g., the load logic 124) generates and sends, to the external unit (e.g., the RAC 112), a load transaction request for the requested / identified ray data elements in the current block for the identified load group for the current ray. In some cases, the load transaction request can include (i) information identifying the current ray; (ii) information identifying the load group; (iii) information identifying the current block; and (iv) information identifying the requested / identified ray data elements for the block.

[0099] Figure 6 An example format of a load transaction request 600 is shown when the identified load group is a per-ray load group. The example load transaction request 600 includes a ray identifier field 602, a block identifier field 604, a ray data element set identifier field 606, and a load group identifier field 608. The ray identifier field 602 (which can also be referred to as an INSTANCE field) identifies the ray to which the request relates, and can be set to the value of the current ray identifier. The block identifier field 604 (which can also be referred to as an ADDR field) identifies the block (of the identified load group) to which the request relates. The block identifier field 604 can be set to the value of the current block identifier. The ray data element set identifier field 606 (which can be referred to as a MASK field when implemented as a mask) identifies the set of ray data elements in the block from which the ray data elements are to be retrieved. The ray data element set identifier field 606 can include the bits of the RLOAD MASK field (e.g., bits ((RT USC DATA WIDTH / RAY DATA ELEMENT WIDTH)*(BLOCK+1)-1) to (RT USC DATA WIDTH / RAY DATA ELEMENT WIDTH)*(BLOCK)) that relate to the identified block. The load group identifier field 608 (which can also be referred to as a SPACE field) identifies the load group. The load group identifier field 608 can be configured to include the load group identifier information in the RLOAD instruction. In cases where the RLOAD instruction includes a SPACE CTRL field, the load transaction request 600 can also include a SPACE CTRL field 610 that includes the SPACE CTRL information from the RLOAD instruction. It will be apparent to those skilled in the art that this is merely an example, and in other examples, the load transaction request can take a different form.

[0100] Returning to Figure 5Upon receiving the load transaction request, the external unit (e.g., RAC 112) determines the location of the requested ray data element in the storage (e.g., RAC 112 storage units 114, 116) from the load group, chunk, and ray data element information, retrieves the requested ray data element from the storage, and transmits the requested ray data element to the USC 104 as part of the load transaction. In particular, the external unit (e.g., RAC 112) can include information that maps the load group and its individual ray data elements to storage locations.

[0101] Once the USC 104 has generated and sent the load transaction request to the external unit (e.g., RAC 112), the method 500 proceeds to block 514.

[0102] At block 514, the USC 104 (e.g., load logic 124) determines whether the current chunk is the last chunk (i.e., whether the load logic 124 has checked all chunks). In the case where the chunk identifier is implemented as a counter initialized to 0, the USC 104 can determine whether the current chunk is the last chunk by comparing the chunk counter to (the maximum number of chunks per load group - 1). In the case where the ray data element set identifier field is implemented as a MASK field, the maximum number of chunks per load group can be equal to the maximum number of bits in the MASK field divided by the maximum number of ray data elements per load transaction (e.g., RT USC DATA WIDTH / RAY DATA ELEMENT WIDTH). For example, in the case where the MASK field includes 20 bits and there are a maximum of 4 ray data elements per load transaction, there will be a maximum of 5 chunks per load group. If it is determined that the current chunk is the last chunk, the method 500 proceeds to block 508. However, if it is determined that the current chunk is not the last chunk, the method 500 proceeds to block 516.

[0103] At block 516, the USC 104 (e.g., load logic 124) updates (e.g., increments) the current chunk identifier to identify another (e.g., next) chunk. Once the current chunk identifier has been updated, the method 500 proceeds back to block 510, where the USC 104 (e.g., load logic 124) determines whether any of the ray data elements associated with the new current chunk have been requested.

[0104] At block 508, the USC 104 (e.g., the load logic 124) determines whether the current ray is the last ray associated with the RLOAD instruction (e.g., whether all rays associated with the RLOAD instruction have been evaluated). In cases where the current ray identifier is implemented as a counter initialized to 0, the USC 104 (e.g., the load logic 124) can determine whether the current ray is the last ray by comparing the current ray counter to (the maximum number of rays associated with the RLOAD instruction - 1). In some cases, the maximum number of rays associated with the RLOAD instruction can be 128. However, it will be apparent that this is merely an example, and in other examples, there can be a different number of rays associated with the RLOAD instruction. If it is determined that the current ray is the last ray associated with the RLOAD instruction, the method 500 ends 518. However, if it is determined that the current ray is not the last ray associated with the RLOAD instruction, the method 500 proceeds to block 520.

[0105] At block 520, the current ray identifier is updated (e.g., the current ray counter is incremented) to identify another (e.g., next) ray. Once the current ray identifier has been updated, the method 500 proceeds back to block 504.

[0106] As described above, each load transaction of each rayblock load group can include only the same ray data element of multiple rays. For example, the load transactions of each rayblock load group can include the CM_T ray data element of the first ray and the CM_T ray data element of the second ray. In contrast, the load transactions of each rayblock load group can not include the ORIGIN_X, ORIGIN_Y, and ORIGIN_Z ray data elements of a ray. In some cases, the rays associated with the RLOAD instruction can be divided into blocks, and the load transactions of each rayblock load group can include only the ray data elements related to the rays in the same block. The number of rays in a block can be based on the maximum number of ray data elements in a load transaction. For example, if a load transaction can include up to four ray data elements, the rays associated with the RLOAD instruction can be divided into four blocks. In these cases, when the USC 104 (e.g., the load logic 124) receives the RLOAD instruction in which each rayblock load group is identified, the USC 104 (e.g., the load logic 124) can be configured to convert the received RLOAD instruction into multiple load transactions by determining which rayblocks include at least one active ray and, for each block that includes at least one active ray, generating and transmitting a load transaction request for the ray data elements identified in the RLOAD instruction. This process can be repeated for each identified ray data element in the RLOAD instruction. Thus, in this RLOAD conversion technique, no load transaction request can be generated and transmitted for inactive rayblocks - i.e., no load transaction is generated for a rayblock that does not include any active rays.

[0107] Reference is now made to Figure 7 which shows an example method 700 that can be implemented by the USC 104 (e.g., the load logic 124) to convert an RLOAD instruction that identifies each rayblock load group into multiple load transactions. In this example, it is assumed that each rayblock load group includes a single ray data element. However, if each rayblock load group includes multiple ray data elements, the method 700 can be repeated for each ray data element identified in the RLOAD instruction. The method 700 begins at block 702, in which the USC 104 (e.g., the load logic 124) initializes a current rayblock identifier. The current rayblock identifier identifies a rayblock associated with the RLOAD instruction. The rayblock identified by the current block identifier can be referred to herein as the current rayblock. The current rayblock identifier can be initialized to identify the first rayblock associated with the RLOAD instruction. In some cases, each of the multiple rayblocks can be identified by a unique value. In some cases, the current rayblock identifier can be a counter that is initialized to a predetermined value (e.g., 0). Once the current rayblock identifier has been initialized, the method 700 proceeds to block 704.

[0108] At block 704, USC 104 (e.g., load logic 124) determines whether the current ray block includes at least one active ray. As noted above, along with the RLOAD instruction, USC 104 (e.g., load logic 124) can receive information indicating which rays are active for the RLOAD instruction. If it is determined that the current ray block includes at least one active ray, method 700 proceeds to block 706. However, if it is determined that the current ray block does not include any active rays, method 700 proceeds directly to block 708.

[0109] At block 706, USC 104 (e.g., load logic 124) generates and sends a load transaction request for each active ray in the current ray block to an external unit (e.g., RAC 112) for a specific ray data element (i.e., a ray data element in the identified load group). In some cases, the load transaction request includes (i) information identifying the ray block; (ii) information identifying the active ray in the ray block; and (iii) information identifying the load group (where the load group contains only one ray data element, which also identifies the ray data element).

[0110] Loading transaction requests can be done by Figure 6 The form shown is used. However, in this case, the ray identifier field 602 can be used to identify a ray block by, for example, the first ray in the block. The ray identifier field 602 can be set to the current ray block identifier * the number of rays per block. The block identifier field 604 can be left unused or can be set to zero. The ray data element set identifier field 606 can be used to identify the active rays in the identified ray block. In some cases, the ray data element set identifier field 606 can be implemented as a mask with bits for each ray in the ray block. When the corresponding ray is active, the bit can be set to a value (e.g., '1'), and when the corresponding ray is inactive, the bit can be set to a different value (e.g., '0'). Similar to the per-ray load group load transaction request, the load group identifier field 608 identifies the load group identified in the RLOAD instruction. The load group identifier field 608 can be configured to include load group identifier information from the RLOAD instruction. When the RLOAD instruction includes the SPACE_CTRL field, the load transaction request may also include the SPACE_CTRL field 610, which includes SPACE_CTRL information from the RLOAD instruction.

[0111] Upon receiving a load transaction request, the external unit (e.g., RAC 112) determines the location of the requested ray data element in storage (e.g., RAC 112 storage units 114, 116) from the ray bin, ray activity, and load group information, retrieves the requested ray data element from storage, and transmits the requested ray data element to the USC 104 as part of the load transaction. In particular, the external unit (e.g., RAC 112) can include information that maps load groups and their individual ray data elements to storage locations.

[0112] Once the USC 104 has sent a load transaction request to the external unit (e.g., RAC 112), the method 700 proceeds to block 708.

[0113] At block 708, the USC 104 (e.g., load logic 124) determines whether the current ray bin is the last ray bin (e.g., whether all ray bins have been evaluated). In the case where the ray bin identifier is implemented as a counter initialized to 0, the USC 104 can determine whether the current ray bin is the last ray bin by comparing the ray bin counter to (the maximum number of ray bins - 1). If it is determined that the current ray bin is the last ray bin, the method 700 ends 710. However, if it is determined that the current ray bin is not the last ray bin, the method 700 proceeds to block 712.

[0114] At block 712, the current ray bin identifier is updated (e.g., incremented) to identify another (e.g., the next) ray bin. Once the current ray bin identifier has been updated, the method 700 proceeds back to block 704.

[0115] In some cases, after performing a load transaction, the USC 104 (e.g., load logic 124) can perform a store transaction to store the ray data element in the ray bin identified by the current ray bin identifier. In particular, the USC 104 can determine the location of the ray data element in storage (e.g., RAC 112 storage units 114, 116) from the ray bin, ray activity, and store group information, store the ray data element in storage, and transmit the ray data element to the external unit (e.g., RAC 112) as part of the store transaction. Figure 4Prior to block 404 of method 400 (i.e., prior to sending one or more load requests to an external unit (e.g., RAC 112) to retrieve the ray data elements identified in the RLOAD instruction), the USC 104 (e.g., load logic 124) can be configured to perform one or more safety checks on the RLOAD instruction. For example, prior to sending the load transaction request to the external unit (e.g., RAC 112), the USC 104 (e.g., load logic 124) can be configured to verify that sufficient USC 104 storage 110 has been allocated for storing the ray data elements identified in the RLOAD instruction. This verification is performed to ensure that the USC 104 storage 110 is not corrupted by writing to addresses outside of the allocated region. In some cases, the USC 104 can be configured to receive (in addition to the RLOAD instruction) information indicating the amount of storage allocated per ray / instance, and the USC 104 can be configured to determine whether sufficient USC 104 storage 110 has been allocated by comparing the amount of storage allocated per ray / instance 110 to the number of ray data elements requested per ray / instance. In cases where the ray data element set identifier field is implemented as a mask, the USC 104 (e.g., load logic 124) can determine the number of ray data elements requested per ray by counting the number of bits in the MASK field of the RLOAD instruction that indicate that a ray data element has been requested. If the number of ray data elements requested per ray is greater than the amount of storage allocated per ray 110, then there is an error, and an exception can be raised.

[0116] Ray Store (RSTORE) Instruction

[0117] In examples described herein, the USC 104 (e.g., store logic 126) is configured to receive and process a ray store instruction that allows efficient writing of ray data to an external unit (e.g., RAC 112). In particular, the USC 104 (e.g., store logic 126) is configured to receive and process a ray store instruction that includes information identifying a storage group of a plurality of storage groups (where each storage group includes a subset of ray data elements) and information identifying the ray data elements of that storage group to be written to the external unit (e.g., RAC 112). Such an instruction allows a ray tracing shader to efficiently identify multiple potentially scattered ray data elements to be written to the external unit (e.g., RAC 112) using a single instruction.

[0118] Each storage group of ray data elements includes a subset of ray data elements that can be associated with a ray. The storage groups can be defined such that each storage group includes ray data elements that are likely to be generated and stored together by a ray tracing shader.

[0119] Reference is now made to Figure 8which shows an example set of storage groups formed from the ray data elements of Table 1. In this example, there are three storage groups labeled trace, query, and call. Each storage group includes one or more ray data elements that can be stored in an external unit (e.g., RAC 112) using a single RSTORE instruction. For example, the trace storage group includes ORIGIN_X, ORIGIN_Y, ORIGIN_Z, DIRECTION_X, DIRECTION_Y, DIRECTION_Z, ACC_STRUCT, NCM_T, TMIN, CM_T, CD_T, FLAGS, SBT_OFFSET, SBT_STRIDE, MISS_INDEX, PAYLOAD_0, PAYLOAD_1, and PAYLOAD_2 ray data elements. This means that the shader can use a single RSTORE instruction to write the combination of these ray data elements to an external unit (e.g., RAC 112). Similarly, the call storage group includes MISS_INDEX, PAYLOAD_0, PAYLOAD_1, PAYLOAD_2, ORIGIN_X, ORIGIN_Y, ORIGIN_Z, DIRECTION_X, DIRECTION_Y, DIRECTION_Z, NCM_T, CM_T, TMIN, CD_T, ACC_STRUCT, U, and V ray data elements. This means that the shader can use a single RSTORE instruction to write the combination of these ray data elements to an external unit (e.g., RAC 112). As can be seen, a ray data element can form part of only one storage group, or a ray data element can form part of more than one storage group. For example, the U and V ray data elements are only part of the call storage group, and the ORIGIN_X ray data element belongs to the trace, query, and call storage groups. Thus, multiple storage groups can include overlapping subsets of ray data elements.

[0120] As can be seen, in the examples shown herein, the load groups (shown in Figure 2 ) are different than the store groups (shown in Figure 8 ). This can be beneficial when the ray data elements generated by the ray tracing shader are different than the ray data elements consumed or processed by the ray tracing shader. However, it will be apparent to those skilled in the art that this is merely an example, and in other examples, there can be a single set of ray data element groups for the RLOAD and RSTORE instructions.

[0121] Reference is now made to Figure 9which shows an example format of a ray store (RSTORE) instruction 900 for storing ray data elements in an external unit (e.g., RAC 112). The RSTORE instruction 900 includes a store group identifier field 902, a length (LENGTH) field 904, and an offset (OFFSET) field 906. The RSTORE instruction 900 can optionally include one or more other fields, some of which are discussed below.

[0122] The store group identifier field 902 of the RSTORE instruction 900 (which can also be referred to as a SPACE field or group field) includes information that identifies one of a plurality of predefined store groups. In some cases, each store group can be associated with a unique numeric identifier, and a particular store group is identified in the RSTORE instruction 900 by setting the SPACE field 902 to the unique numeric identifier associated with the particular store group. In these cases, the number of bits used for the SPACE field 902 can be selected based on the number of store groups. For example, the minimum number of bits for the SPACE field 302 can be where S is the number of store groups. Table 3 shows Figure 8 an example set of unique identifiers for store groups shown in Table 2. In this example, there are three store groups, so the SPACE field can include two bits. It will be apparent to those skilled in the art that this is merely an example.

[0123] Table 3

[0124]

[0125] The offset field 906 and the length field 904 together identify the ray data elements of the identified store group that are to be stored in the external unit (e.g., RAC 112). While the above describes the length field 904 as identifying the number of ray data elements in the identified store group, it will be apparent to those skilled in the art that the length field 904 can alternatively identify the number of bytes of ray data elements in the identified store group. Figure 3 The ray data element set identifier field 304 of the example RLOAD instruction described above allows the identification (and thus retrieval from the external unit) of a combination of individual ray data elements in the identified load group, but in the example RSTORE instruction 900 shown in Table 2, only contiguous groups of ray data elements in the store group can be identified. Figure 9

[0126] ​In particular, the ray data elements of a storage group can be divided into sets, where each set includes one or more ray data elements, and for each RSTORE request only one ray data element in a set can be written to the external unit. This means that if a storage group has ten sets of ray data elements, then each ray store instruction can only store ten ray data elements of that storage group. In some cases, a set of ray data elements can include only one ray data element, or multiple mutually exclusive ray data elements of that storage group. Mutually exclusive ray data elements for a storage group are ray data elements that are not to be written together by a shader that is intended to use that storage group. Note that ray data elements can be mutually exclusive for some storage groups, but not for other storage groups.

[0127] Each set of ray data elements of a storage group is then associated with information (e.g., a value or an offset) that indicates the order or location of the set in the storage group. An adjacent group of ray data elements in a storage group can then be identified by identifying a first set of ray data elements that includes the ray data element to be written to the external unit, and the total number of ray data elements to be written. In some cases, the first set of ray data elements can be identified by a value or offset that identifies the first set of ray data elements in the storage group. Figure 9 In the example shown in FIG. 9, the offset field 906 includes information that identifies the location (e.g., offset) of the first set of ray data elements that includes the ray data element to be written to the external unit, and the length field 904 includes information that indicates the number of ray data elements to be written.

[0128] How the ray data elements of a storage group are divided into sets of ray data elements, and which sets of ray data elements are associated with which location values or offset values, can be predefined. Figure 8An example partitioning of the ray data elements of the illustrated storage group into sets and a mapping between the sets and offset values is shown. For example, for the call storage group, its ray data elements are partitioned into seventeen ray data element sets, each of which includes a single ray data element. Specifically, the first set includes the MISS INDEX ray data element, the second set includes the PAYLOAD 0 ray data element, the third set includes the PAYLOAD 1 ray data element, and so on. Each set is associated with an offset value. Specifically, the first set (including the MISS INDEX ray data element) is associated with offset value 0, the second set (including the PAYLOAD 0 ray data element) is associated with offset value 1, the third set (including the PAYLOAD 1 ray data element) is associated with offset value 2. In this example, to write the ORIGIN X, ORIGIN Y, ORIGIN Z, DIRECTION X, DIRECTION Y, and DIRECTION Z ray data elements to an external unit (e.g., RAC 112) using a single RSTORE instruction, the storage group identifier field 902 can be set to identify the call storage group, the offset field 906 can be set to the offset of the first set of ray data elements to be written (i.e., set to offset 4 (decimal)), and the length field can be set to 6 (decimal) to indicate that 6 ray data elements are to be written.

[0129] Similarly, in Figure 8As can be seen, the trace store group is divided into sixteen sets of ray data elements. Except for two sets, each set includes only a single ray data element. Specifically, one set includes both the NCM T ray data element and the TMIN ray data element, and another set includes both the CM T ray data element and the CD T ray data element. This means that the NCM T or TMIN ray data element, but not both, can be written to an external unit using a single RSTORE instruction that identifies the trace store group. Similarly, the CM T or CD T data element, but not both, can be written to an external unit (e.g., RAC 112) using a single RSTORE instruction that identifies the trace store group. Similar to the call store group, each set of ray data elements is associated with an offset value that indicates its position / location within the store group. For example, the first set (the set that includes the ORIGIN X ray data element) is associated with an offset value of 0, the second set (the set that includes the ORIGIN Y ray data element) is associated with an offset value of 1, and so on. In this example, to write the PAYLOAD 0, PAYLOAD 1, and PAYLOAD 2 ray data elements to an external unit (e.g., RAC 112) using a single RSTORE instruction, the store group identifier field 902 can be set to identify the trace store group, the offset field 906 can be set to the offset of the first set of ray data elements to be written (i.e., offset 13 (decimal)), and the length field 905 can be set to 3 (decimal) to indicate that 3 ray data elements are to be written.

[0130] In some cases, the RSTORE instruction 900 can also include a source (SRC) field 908 that includes information identifying a location in the USC 104 storage 110 (e.g., a register) where the identified ray data element is stored. In some cases, the ray data element to be written is stored in an adjacent storage location (e.g., a register). In such cases, the SRC field 908 can identify the USC 104 storage 110 location (e.g., a register) where the first ray data element to be written to an external unit (e.g., RAC 112) is located.

[0131] As described above, the ray data elements of each storage group are divided into sets, and each set is associated with offset or location information. Each set can include only one ray data element or more than one ray data element. In the case where a ray data element set includes only a single ray data element, then the offset information associated therewith explicitly identifies which ray data element is to be written to the external unit. However, if a ray data element set includes multiple ray data elements (which is referred to as a multi-ray data element set), then the offset information associated with the set does not explicitly identify the particular ray data element to be written to the external unit (e.g., RAC 112). Thus, in the case where there is at least one storage group with a multi-ray data element set, the RSTORE instruction can include additional information that indicates which ray data element of the set is to be written to the external unit when the set is identified. For example, as shown in Figure 9 RSTORE instruction 900 can include a SPACE_CTRL field 910 that is used to indicate which ray data element of an identified multi-ray data element set is to be written.

[0132] For example, in the example storage groups shown in Figure 8 , both the trace storage group and the query storage group have multi-ray data element sets. Specifically, the trace storage group includes: (i) a ray data element set that includes the NCM_T ray data element and the TMIN ray data element; and (ii) a ray data element set that includes the CM_T ray data element and the CD_T ray data element. The query storage group has seven multi-ray data element sets. In this example, when any of these multi-ray data element sets is identified (by the offset field and the length field), the SPACE_CTRL field 910 can include information that indicates which ray data element of each identified multi-ray data element set is to be written.

[0133] In this example, the bits of the SPACE_CTRL field 910 can be used differently depending on whether a trace storage group or a query storage group is identified (and the SPACE_CTRL field 910 can not be used if a call storage group is identified, as the call storage group does not have any multi-ray data element sets (i.e., each set includes only a single ray data element)). For example, the SPACE_CTRL field 910 can include four bits, and Table 4 shows how these bits can be used to identify which particular ray data elements are to be written to the external unit when the group identifier field identifies the trace storage group and at least one of the multi-ray data element sets is identified by the offset field 906 and the length field 904.

[0134] Table 4 - Trace Storage Group

[0135]

[0136] It can be seen that for a trace storage group, the two multi-ray data element sets include four unique ray data elements (TMIN, NCM T, CD T, and CM T), and each bit of the SPACE_CTRL field 910 is associated with one of those ray data elements. Specifically, bit 0 is associated with the TMIN ray data element, bit 1 is associated with the NCM T ray data element, bit 2 is associated with the CD T ray data element, and bit 3 is associated with the CM T ray data element. When a bit of the SPACE_CTRL field 910 is set to one value (e.g., '1'), the corresponding ray data element will be written to the external unit, and when the bit is set to another value (e.g., '0'), the corresponding ray data element will not be written to the external unit. Since TMIN and NCM T are in the same set, they cannot be written to the external unit using the same RSTORE instruction (in the case that the storage group is a trace storage group), so only one of bits 0 and 1 can be set at a time. Similarly, since CD T and CM T are in the same set, they cannot be written to the external unit using the same RSTORE instruction (in the case that the storage group is a trace storage group), so only one of bits 2 and 3 can be set at a time.

[0137] Table 5 shows how the bits of the SPACE_CTRL field 910 can be used to identify which particular ray data elements will be written to the external unit when the group identifier field identifies a query storage group and at least one of its multi-ray data element sets is identified by the offset field and the length field.

[0138] Table 5 - Query Storage Group

[0139]

[0140] As described above, a query storage group includes the multi-ray data element sets shown in Table 6.

[0141] Table 6

[0142] Collection Data element 0 Data element 1 8 CM T CD T 10 CM INST IN NCM INST IN 11 CM PRIM IN NCM PRIM IN 12 CM GEOM IN NCM GEOM IN 13 CM INST IN CD INST IN 14 CM PRIM IN CD PRIM IN 15 CM GEOM IN CD GEOM IN

[0143] The following combinations of ray data elements from these sets have been determined to potentially be written together, which is reflected in Table 5.

[0144] • NCM INST IN, NCM PRIM IN, NCM GEOM IN

[0145] • CM INST IN, CM PRIM IN, CM GEOM IN

[0146] • CD T, CD INST IN, CD PRIM IN, CD GEOM IN

[0147] • CM T, CM INST IN, CM PRIM IN, CM GEOM IN

[0148] Thus, as shown above, the bits of the SPACE_CTRL field 910 can be used to identify individual ray data elements of a multi-ray data element set by (i) having one bit associated with a particular ray data element that is used to identify that particular ray data element, (ii) having one bit associated with a particular multi-ray data element set that includes two ray data elements, the bit being used to identify one of the ray data elements in the set, and (iii) having one or more bits associated with a plurality of multi-ray data element sets, the one or more bits being used to identify one ray data element in each set (e.g., the first ray data element of each set, or the second ray data element of each set, or a particular combination of ray data elements in the set). It will be apparent to those of skill in the art that any combination of these techniques or approaches can be used to identify individual ray data elements of a multi-ray data element set. It will be apparent to those of skill in the art that these are merely examples of how the bits of the SPACE_CTRL field 910 can be used to identify individual ray data elements of a multi-ray data element set, and that the bits of the SPACE_CTRL field 910 can identify the ray data elements of a multi-ray data element set in any suitable manner.

[0149] In the example storage groups shown in Figure 8 , there are two storage groups that have multi-ray data element sets. However, it will be apparent to those of skill in the art that this is merely an example, and that no storage group can have multi-ray data element sets (i.e., each data element set can include only a single ray data element), or that one, two, or more than two storage groups can include multi-ray data element sets. Furthermore, in the example storage groups shown in Figure 8 , one storage group has two multi-ray data element sets, and another storage group includes seven multi-ray data element sets. It will be apparent to those of skill in the art that this is merely an example, and that a storage group can include any number of multi-ray data element sets.

[0150] As described above, the USC 104 receives shader tasks from the scheduler. Each shader task specifies data to be processed and a shader (e.g., program) to be used to process the data. In response to receiving a shader task, the USC 104 executes the identified shader for the identified data. A ray tracing shader task can be associated with multiple rays, and the identified ray tracing shader is applied to one or more of the multiple rays. Thus, the RSTORE instruction running as part of the shader task is said to be associated with the multiple rays associated with the shader task, and the identified ray data element is to be stored in the external unit (e.g., RAC 112) for one or more of the rays associated with the RSTORE instruction.

[0151] For RSTORE instructions executed as part of a shader task, not all of the rays associated with the ray tracing shader task are ‘active’, and preferably only the ray data for the active rays of the RSTORE instruction is stored in the external unit (e.g., RAC 112) to avoid writing unnecessary data to the external unit. Thus, in the method described below, it is determined which of the multiple rays associated with the RSTORE instruction are active for the RSTORE instruction, and the identified ray data element is stored in the external unit (e.g., RAC 112) only for the active rays. However, in other examples, it can be simpler to simply store the identified ray data element for all of the rays associated with the RSTORE instruction, rather than determining which of the rays associated with the RSTORE instruction are active.

[0152] The active rays of the RSTORE instruction can be set at the shader task level or the instruction level. In particular, some rays can be inactive for a ray tracing shader task, such that these rays will be inactive for any RSTORE instructions executed as part of the ray tracing shader task. However, different RSTORE instructions executed as part of the same ray tracing shader task can have different active rays. For example, only rays 1 and 2 associated with the ray tracing shader task can be active for a first RSTORE instruction executed as part of the ray tracing shader task, and only rays 3 and 4 associated with the ray tracing shader task can be active for a second, different RSTORE instruction executed as part of the ray tracing shader task.

[0153] Reference is now made to Figure 10which shows an example method 1000 of executing an RSTORE instruction at a USC 104 (e.g., storage logic 126). The method 1000 begins at block 1002, where the USC 104 (e.g., storage logic 126) receives an RSTORE instruction, such as for Figure 9 the described case. As described above, the RSTORE instruction identifies a predefined storage group of ray data elements (e.g., one of the storage groups shown in Figure 8 FIG. 6) and a particular ray data element of the storage group to be written to an external unit (e.g., RAC 112). After receiving the RSTORE instruction, the method 1000 proceeds to block 1004, where the USC 104 (e.g., storage logic 126) retrieves the identified ray data elements from the USC 104 local storage 110. The method 1000 then proceeds to block 1006, where the USC 104 sends one or more store requests to the external unit (e.g., RAC 112) that cause the identified ray data elements of the identified storage group to be written to the storage of the external unit (e.g., RAC 112 storage units 114, 116) for each ray of one or more rays associated with the RSTORE instruction.

[0154] The storage interface 120 between the external unit (e.g., RAC 112) and the USC 104 used to send data from the USC 104 to the external unit (e.g., RAC 112) can not be large enough to transfer all of the identified ray data elements to the external unit (e.g., RAC 112) in the same cycle. Thus, the USC 104 can transfer the identified ray data elements to the external unit (e.g., RAC 112) over multiple cycles. One or more ray data elements transferred in a cycle can be referred to as a store transaction. In some cases, the number of ray data elements that can be transferred in the same cycle (e.g., as part of the same store transaction) is based on the size of the storage interface 120 and the size of the ray data elements. The size of the storage interface 120 is defined as the amount of data that can be transferred across the storage interface 120 at the same time. For example, if the storage interface 120 is 128 bits wide and each ray data element is a doubleword (i.e., 32 bits), then four ray data elements can be transferred in the same cycle (e.g., in the same store transaction).

[0155] In some cases, the USC 104 can be configured to implement the RSTORE instruction by converting the RSTORE instruction into multiple store transactions and sending an independent store transaction request to the external unit (e.g., RAC 112) for each store transaction. Figure 10block 1006 of method 1000 (i.e., sending one or more store requests to an external unit to cause the identified ray data elements to be stored in the external unit). In other words, the USC 104 can be configured to expand the received RSTORE instruction into multiple store transactions. This can also be described as serializing the RSTORE instruction. For example, if four store transactions are to be used to transfer the ray data elements identified in the RSTORE instruction from the USC 104 to an external unit (e.g., the RAC 112), the USC 104 (e.g., the store logic 126) can generate and transmit four store transaction requests to the external unit (e.g., the RAC 112). In response to receiving the store transaction requests, the external unit (e.g., the RAC 112) stores the received ray data elements in the correct locations in its storage units 114, 116 according to the type of ray data element.

[0156] In some cases, there can be one or more types of storage groups, and the techniques for converting the RSTORE instruction into multiple transactions can be based on the type of storage group identified in the RSTORE instruction. For example, the one or more types of storage groups can include one or more of a per-ray (or per-instance) storage group and a per-ray-block storage group. Transactions for a per-ray storage group can include only ray data elements associated with the same ray (e.g., different ray data elements associated with the same ray). Transactions for a per-ray-block storage group can include only the same ray data element for multiple rays. In a similar manner to how RLOAD instructions related to a per-ray-block load group are converted into multiple load transactions, RSTORE instructions related to a per-ray-block storage group can be converted into multiple store transactions. It will be apparent to those skilled in the art that these are merely example types of storage groups, and that there can be other types of storage groups that can be converted into multiple store transactions in different manners. Figure 11 An example method of converting RSTORE instructions related to a per-ray storage group into multiple store transactions is described. Transactions for a per-ray-block storage group can include only the same ray data element for multiple rays. In a similar manner to how RLOAD instructions related to a per-ray-block load group are converted into multiple load transactions, RSTORE instructions related to a per-ray-block storage group can be converted into multiple store transactions. It will be apparent to those skilled in the art that these are merely example types of storage groups, and that there can be other types of storage groups that can be converted into multiple store transactions in different manners.

[0157] As described above, each storage transaction per ray storage group can include only ray data elements related to the same ray. For example, a storage transaction per ray storage group can include ORIGIN_X, ORIGIN_Y, and ORIGIN_Z ray data elements of the same ray. In contrast, a storage transaction per ray storage group may not include CM_T ray data elements of a first ray and CM_T ray data elements of a second different ray. In some cases, the ray data elements of each ray storage group are divided into one or more blocks, and a storage transaction per ray storage group can include only ray data elements within the same block. In these cases, when USC 104 (e.g., storage logic 126) receives an RSTORE instruction that identifies a per-ray storage group, USC 104 (e.g., storage logic 126) can be configured to convert the received RSTORE instruction into multiple storage transactions by: determining which blocks in the identified storage group include at least one identified ray data element, and for each block that includes at least one identified ray data element, issuing a storage transaction request for each ray of one or more rays associated with the RSTORE instruction, containing the identified ray data element in that block. Therefore, in this RSTORE conversion technique, storage transaction requests are not issued for empty blocks in the identified storage group—that is, storage transactions are not generated for blocks in the identified storage group that do not contain at least one identified ray data element.

[0158] For example, suppose Figure 8 Each storage group in the example storage groups shown is a per-ray storage group. Figure 8 As can be seen, the ray data elements of each storage group have been divided into blocks, where the ray data elements in a block can form a part of the same storage transaction. For example, the ray data elements of the tracking storage group have been divided into four blocks (blocks 0, 1, 2, and 3), the ray data elements of the query storage group have been divided into four blocks (blocks 0, 1, 2, and 3), and the ray data elements of the calling storage group have been divided into five blocks (blocks 0, 1, 2, 3, and 4).

[0159] Since the maximum number of ray data elements that can be transferred as part of a single storage transaction is N, only N ray data elements in a block can be transferred as part of a single storage transaction. Therefore, each block can include at most N sets of one or more ray data elements, where, as described above, each set of ray data elements includes a single ray data element or multiple mutually exclusive ray data elements. This means that a storage transaction can include ray data elements from each set associated with the block. In the example described in this paper, N is four (i.e., four ray data elements can be transferred as part of a single storage transaction), therefore... Figure 8Each block shown contains a maximum of four sets of ray data elements.

[0160] As described above, each set of ray data elements in the storage group can be associated with an offset (or other similar information) indicating the location of the ray data element set within the storage group. In some cases, such as Figure 8 As shown, the ray data elements in a block are ray data elements associated with a set of adjacent offsets (e.g., N offsets). For example, as... Figure 8 As shown, the first block of each storage group may include a set of ray data elements associated with the first four offsets (e.g., offsets 0 to 3), the second block of each storage group may include a set of ray data elements associated with the next four offsets (e.g., offsets 4 to 7), and so on.

[0161] Now for reference Figure 11 The diagram illustrates an example method 1100, which can be implemented by USC 104 (e.g., storage logic 126) to translate an RSTORE instruction (which identifies a per-ray storage group) into multiple storage transactions. Method 1100 begins at block 1102, where USC 104 (e.g., storage logic 126) initializes a current ray identifier (which may also be called an instance identifier). The current ray identifier identifies one of the multiple rays associated with the RSTORE instruction. The ray identified by the current ray identifier may be referred to as the current ray. The current ray identifier may be initialized to identify the first ray associated with the RSTORE instruction. In some cases, each of the multiple rays associated with the RSTORE instruction may be identified by a unique value. In some cases, the current ray identifier may be a counter initialized to a predetermined value (e.g., 0). Once the current ray identifier has been initialized, method 1100 proceeds to block 1104.

[0162] At block 1104, USC 104 (e.g., storage logic 126) determines whether the current ray is active. USC 104 can be configured to receive information, along with the RSTORE instruction, indicating which of the multiple rays associated with the RSTORE instruction are active. If it is determined that the current ray is active, method 1100 proceeds to block 1106. However, if it is determined that the current ray is not active, method 1100 proceeds directly to block 1108.

[0163] At block 1106, the USC 104 (e.g., the storage logic 126) initializes a current block identifier to identify a block of the identified storage group. The block identified by the current block identifier can be referred to as the current block. In some cases, the current block identifier can be initialized to identify the first block of the identified storage group. In some cases, the current block identifier can take the form of a counter, and the counter can be initialized to a predetermined value (e.g., 0). Once the current block identifier has been initialized, the method 1100 proceeds to block 1110.

[0164] At block 1110, the USC 104 (e.g., the storage logic 126) analyzes the RSTORE instruction to determine whether at least one ray data element in the current block is to be written to the external unit (e.g., the RAC 112). In cases where the RSTORE instruction includes an offset (OFFSET) field and a length (LENGTH) field as described above, the range of the block that includes the at least one ray data element can be determined as to In such cases, the USC 104 (e.g., the storage logic 126) can be configured to determine that at least one ray data element in the current block is to be written to the external unit (e.g., the RAC 112) if the value of the current block identifier falls within this range. If it is determined that at least one ray data element in the current block is to be written to the external unit (e.g., the RAC 112), the method 1100 proceeds to block 1112. However, if it is determined that no ray data elements in the current block are to be stored in the external unit (e.g., the RAC 112), the method 1100 proceeds to block 1114.

[0165] At block 1112, the USC 104 (e.g., the storage logic 126) generates and sends a storage transaction request to the external unit (e.g., the RAC 112) to store the identified ray data elements in the current block for the current ray. In some cases, the storage transaction request includes (i) information identifying the current ray; (ii) information identifying the storage group; (iii) information identifying the current block; (iv) information identifying the relevant ray data elements of the current block; and (v) the identified ray data elements (i.e., the data to be stored).

[0166] Reference is now made to Figure 12which shows an example format of a store transaction request 1200. The example store transaction request 1200 includes a ray identifier field 1202, a block identifier field 1204, a ray data element set identifier field 1206, a storage group identifier field 1208, and a plurality of data fields 1210, 1212, 1214, 1216. The ray identifier field 1202 (which can also be referred to as an INSTANCE field) identifies the ray with which the request is related, and can be set to the value of the current ray identifier. The block identifier field 1204 (which can also be referred to as an ADDR field) identifies the block (of the identified storage group) with which the request is related, and can be set to the value of the current block identifier.

[0167] The ray data element set identifier field 1206 (which can be referred to as a MASK field when implemented as a mask) identifies the set of ray data elements in the identified block that are to be stored in the external unit from the identified block. The ray data element set identifier field 1206 can be generated from the length information and the offset information in the RSTORE instruction. For example, if the RSTORE instruction identifies the tracking storage group of Figure 8 , and the offset field is set to 2, the length field is 6, and the current block is block 0, then it is known that the ray data elements in each of sets 2 through 7 are to be stored. Thus, for block 0, the MASK field can be set to '0011' (binary) to indicate that the ray data elements from the last two sets in the block are to be stored.

[0168] The storage group identifier field 1208 (which can be referred to as a SPACE field) identifies the relevant storage group, and can include the storage group identifier information from the RSTORE instruction. In cases where the RSTORE instruction includes a SPACE_CTRL field, the store transaction request 1200 can also include a SPACE_CTRL field 1218, which includes the SPACE_CTRL information from the RSTORE instruction. It will be apparent to those skilled in the art that this is merely an example, and in other examples, the store transaction request can take a different form, and / or have different and / or additional fields.

[0169] The data fields 1210, 1212, 1214, 1216 include the ray data elements to be stored in the storage of the external unit (e.g., the RAC 112 storage units 114, 116). The number of data fields is equal to the number of ray data elements that can be sent as part of a single store transaction request. In this example, four ray data elements can be sent as part of a single store transaction request, so there are four data fields. The identified ray data elements are placed in the data field corresponding to their location in the block. For example, if the RSTORE instruction identifiesFigure 8 If the tracking storage group is set to 2 and the offset field is set to 2, the length field is 6, and the current chunk is chunk 0, then it is known that the ray data elements in each of sets 2 through 7 will be stored. Thus, for the storage transaction request for chunk 0, the ORIGIN_Z ray data element is placed in the third data field 1214, the DIRECTION_X ray data element is placed in the fourth data field 1216, and the first data field 1210 and the second data field 1212 can be left empty (or can contain any data, as they will be ignored by the external unit).

[0170] Upon receiving a storage transaction request, the external unit (e.g., RAC 112) determines from the storage group, chunk, and ray data element set identifier information which ray data elements are being received and where those ray data elements are to be stored in the external unit storage (e.g., RAC 112 storage units 114, 116). Specifically, for each storage group, the external unit (e.g., RAC 112) can have a mapping between each ray data element in that group and the location of that ray data element in the storage units 114, 116.

[0171] Returning to Figure 11 Once the USC 104 has sent a storage transaction request to the external unit (e.g., RAC 112), the method 1100 proceeds to block 1114.

[0172] At block 1114, the USC 104 (e.g., storage logic 126) determines whether the current chunk is the last chunk (e.g., whether all possible chunks for the storage group have been evaluated). In cases where the current chunk identifier is implemented as a counter initialized to 0, the USC 104 can determine whether the current chunk is the last chunk by comparing the chunk counter to (the maximum number of chunks per storage group - 1). If it is determined that the current chunk is the last chunk, the method 1100 proceeds to block 1108. However, if it is determined that the current chunk is not the last chunk, the method 1100 proceeds to block 1116.

[0173] At block 1116, the USC 104 (e.g., storage logic 126) updates the current chunk identifier (e.g., increments the current chunk counter) to identify another chunk (e.g., the next chunk). Once the current chunk identifier has been updated, the method 1100 proceeds back to block 1110, where the USC 104 (e.g., storage logic 126) determines whether to store any of the ray data elements associated with the new current chunk.

[0174] At block 1108, the USC 104 (e.g., the store logic 126) determines whether the current ray is the last ray associated with the RSTORE instruction (i.e., whether all of the rays associated with the RSTORE instruction have been analyzed). In cases where the current ray identifier is implemented as a counter initialized to 0, the USC 104 (e.g., the store logic 126) can determine whether the current ray is the last ray by comparing the current ray counter to (the maximum number of rays associated with the RSTORE instruction - 1). In some cases, the maximum number of rays associated with the RSTORE instruction can be 128. However, it will be apparent that this is merely an example, and in other examples, there can be a different number of rays associated with the RSTORE instruction. If it is determined that the current ray is the last ray associated with the RSTORE instruction, the method 1100 ends 1118. However, if it is determined that the current ray is not the last ray associated with the RSTORE instruction, the method 1100 proceeds to block 1120.

[0175] At block 1120, the current ray identifier is updated (e.g., the current ray counter is incremented) to identify another ray (e.g., the next ray). Once the current ray identifier has been updated, the method 1100 proceeds back to block 1104.

[0176] Examples of use of RLOAD and RSTORE instructions

[0177] Examples of use of RLOAD and RSTORE instructions Figure 2 and Figure 8Example uses of the RLOAD and RSTORE instructions described herein when implementing ray tracing with the described load and store groups. In some cases, ray tracing can begin with a ray generation shader. The ray generation shader can need the x and y launch ID and the x and y launch size of the rays to generate its x, y, z origin. To load the needed data into the USC 104, the ray generation shader can include RLOAD instructions requesting the LAUNCH_ID_X and LAUNCH_ID_Y ray data elements from the primary load group (e.g., per Table 2, the load group identifier field can be set to “001” (binary), and the mask field can be set to “00000000000000110000” (binary, least significant index of rightmost position)) and RLOAD instructions requesting the LAUNCH_SZ_X and LAUNCH_SZ_Y ray data elements from the launch size load group (e.g., per Table 2, the load group identifier field can be set to “010” (binary), and the mask field can be set to “00000000000000000111” (binary, least significant index of rightmost position)). The ray generation shader can then define all the ray settings and then store this data in an external unit (e.g., the RAC 112). To store this data in an external unit (e.g., the RAC 112), the ray generation shader can include RSTORE instructions to store all the ray data elements in the trace store group except for the third payload ray data element (e.g., per Table 3, the store group identifier can be set to “00” (binary), the offset can be set to “0” (binary), and the length can be set to 15 (decimal), and per Table 4, the SPACE_CTRL field can be set to “1001” (binary, least significant index of rightmost position) to indicate that the TMIN and CM_T ray data elements are to be stored). After the RSTORE instruction hierarchy search is executed, the process of finding intersections (which can also be referred to as ray traversal) begins, and the ray generation shader is suspended.

[0178] After the hierarchical search, a miss shader can be run on rays that are considered "misses." The miss shader can need the x, y launch ray data elements and all three payload ray data elements that point to the memory hierarchy (MH) address of each ray. To get this data, the miss shader can include an RLOAD instruction that requests the PAYLOAD_0, PAYLOAD_1, PAYLOAD_2, LAUNCH ID X, and LAUNCH ID Y ray data elements in the primary load group (e.g., the load group identifier field can be set to "001" (binary) and the mask field can be set to "00000000000000110111" (binary, least bit index in rightmost position)). The miss shader can determine the pixel result from the launch ID and then store the pixel result for each ray at the associated MH address via a different instruction.

[0179] In addition to running the miss shader, a hit shader can also be run on rays that are considered "hits." The hit shader can need the first two payload ray data elements that point to the MH address, the flags ray data element, and data in the u ray data element and the v ray data element. To get this data, the hit shader can include an RLOAD instruction that requests the FLAGS, U, V, PAYLOAD_0, and PAYLOAD_1 ray data elements from the trace load group (e.g., the load group identifier field can be set to "010" (binary) and the mask field can be set to "00110000011100000000" (binary, bit index in rightmost position)). The U ray data element and the V ray data element can then be used to derive the pixel result, which can be stored to the associated MH address via a different instruction.

[0180] The ray generation shader can then resume, where the ray generation shader reads the per ray result (e.g., pixel result) from the MH address to manipulate the output texture.

[0181] In the examples described above, the individual ray data elements in the load group can be identified in the RLOAD instruction via, for example, a mask (and optionally a SPACE_CTRL field), and the contiguous block of ray data elements in the store group can be identified in the RSTORE instruction by a combination of offset information and length information (and optionally a SPACE_CTRL field). This difference between the RSTORE instruction and the RLOAD instruction has arisen because the inventors have found that ray tracing shaders that generate ray data elements and thus write ray data elements to an external unit (such as the RAC 112) tend to write blocks of information into the store group, while ray tracing shaders that process ray data elements tend to read non-contiguous subsets of the load group. Thus, as opposed to a mask, the RSTORE instruction can be simplified by using an offset and a length. This also allows the storage logic 126 to be simplified. However, it will be apparent to those skilled in the art that the RLOAD approach of identifying ray data elements (such as a mask field) can be used to identify ray data elements in the RSTORE instruction, and the RSTORE approach of identifying ray data elements (such as offset and length information) can be used to identify ray data elements in the RLOAD instruction.

[0182] Figure 13 A computer system in which the shader processing units, load logic, store logic, and graphics processing units described herein can be implemented is shown. The computer system includes a CPU 1302, a GPU 1304 (which can be implemented as the GPU 100 described herein), a memory 1306, and other devices 1314 such as a display 1316, speakers 1318, and a camera 1320. The shader processing units 104 described herein can be implemented on the GPU 1304. The components of the computer system can communicate with each other over a communications bus 1322.

[0183] While Figure 13 A specific implementation of a graphics processing system is shown, but it will be understood that a similar block diagram can be drawn for an artificial intelligence accelerator system - for example by replacing the CPU 1302 or GPU 1304 with a neural network accelerator (NNA), or by adding an NNA as a standalone unit. In such cases, the shader processing units 104 can likewise be implemented in the NNA.

[0184] Figure 1The graphics processing units, shader processing units, load logic, and store logic described herein can be embodied in hardware on an integrated circuit. The graphics processing units, shader processing units, load logic, and store logic described herein can be configured to perform any of the methods described herein. Generally, any of the functions, methods, techniques, or components described above can be implemented in software, firmware, hardware (e.g., fixed logic circuitry), or any combination thereof. The terms “module,” “functionality,” “component,” “element,” “unit,” “block,” and “logic” can be used generically herein to represent software, firmware, hardware, or any combination thereof. In the case of a software implementation, the module, functionality, component, element, unit, block, or logic represents program code that performs specified tasks when executed on a processor. The algorithms and methods described herein can be executed by one or more processors executing code that causes the processor(s) to perform the algorithms / methods. Examples of computer-readable storage media include random access memory (RAM), read only memory (ROM), optical disc drive, flash memory, hard drive, and other storage devices that can use magnetic, optical, and other technologies to store instructions or other data and that can be accessed by a machine.

[0185] The graphics processing units, shader processing units, load logic, and store logic described herein can be embodied in hardware on an integrated circuit. The graphics processing units, shader processing units, load logic, and store logic described herein can be configured to perform any of the methods described herein. Generally, any of the functions, methods, techniques, or components described above can be implemented in software, firmware, hardware (e.g., fixed logic circuitry), or any combination thereof. The terms “module,” “functionality,” “component,” “element,” “unit,” “block,” and “logic” can be used generically herein to represent software, firmware, hardware, or any combination thereof. In the case of a software implementation, the module, functionality, component, element, unit, block, or logic represents program code that performs specified tasks when executed on a processor. The algorithms and methods described herein can be executed by one or more processors executing code that causes the processor(s) to perform the algorithms / methods. Examples of computer-readable storage media include random access memory (RAM), read only memory (ROM), optical disc drive, flash memory, hard drive, and other storage devices that can use magnetic, optical, and other technologies to store instructions or other data and that can be accessed by a machine.

[0186] The terms computer program code and computer readable instructions as used herein refer to any kind of executable code, including code expressed in machine language, interpreted language, or scripting language, for a processor. Executable code includes binary code, machine code, byte code, code that defines integrated circuits such as a hardware description language or netlist, and code expressed in a programming language such as C, Java, or OpenCL. Executable code can be, for example, any kind of software, firmware, script, module, or library that, when executed, processed, interpreted, compiled, run in a virtual machine or other software environment, causes a processor of a computer system supporting the executable code to perform tasks specified by the code.

[0187] A processor, computer, or computer system can be any kind of device, machine, or special-purpose circuit, or portions thereof, having processing capability to cause a collection or portion of its instructions to be executed. A processor can be any kind of general- or special-purpose processor, such as a CPU, GPU, NNA, system-on-a-chip, state machine, media processor, application-specific integrated circuit (ASIC), programmable logic array, field-programmable gate array (FPGA), etc. A computer or computer system can include one or more processors.

[0188] The present application is also intended to cover software, such as hardware description language (HDL) software, which defines the configuration of hardware as described herein, for designing, fabricating, or configuring integrated circuits or for configuring programmable chips to perform desired functions. That is, a computer readable storage medium can be provided having encoded thereon a computer readable program code in the form of an integrated circuit definition data set, which, when processed (i.e., run) in an integrated circuit fabrication system, configures the system to fabricate a graphics processing unit, shader processing unit, load logic, and / or store logic configured to perform any of the methods described herein, or to fabricate a graphics processing unit, shader processing unit, load logic, and / or store logic described herein. The integrated circuit definition data set can be, for example, an integrated circuit description.

[0189] Accordingly, a method of fabricating a graphics processing unit, shader processing unit, load logic, and / or store logic as described herein at an integrated circuit fabrication system can be provided. Further, an integrated circuit definition data set, which when processed in an integrated circuit fabrication system, causes the method of fabricating a graphics processing unit, shader processing unit, load logic, and / or store logic to be performed, can be provided.

[0190] An integrated circuit definition data set can be in the form of computer code, for example as a netlist, code for configuring a programmable chip, as a hardware description language defining hardware suitable for fabrication in an integrated circuit at any level, including as register transfer level (RTL) code, as a high level circuit representation such as Verilog or VHDL, and as a low level circuit representation such as OASIS (RTM) and GDSII. A higher level representation of hardware suitable for fabrication in an integrated circuit, such as RTL, can be processed at a computer system configured to generate a fabrication definition of an integrated circuit in the context of a software environment including definitions of circuit elements and rules for combining these elements to generate a fabrication definition of an integrated circuit as defined by the representation. As is typical for software execution at a computer system to define a machine, one or more intermediate user steps (e.g. providing commands, variables, etc.) can be required to configure the computer system to generate a fabrication definition of an integrated circuit to execute code defining an integrated circuit to generate a fabrication definition of that integrated circuit.

[0191] Examples will now be described with respect to Figure 14 Examples are described of processing an integrated circuit definition data set at an integrated circuit fabrication system to configure the system to fabricate a shader processing unit or a graphics processing unit.

[0192] Figure 14 An example of an integrated circuit (IC) fabrication system 1402 is shown, configured to fabricate a graphics processing unit, a shader processing unit, load logic, and / or store logic as described in any of the examples herein. In particular, the IC fabrication system 1402 includes a layout processing system 1404 and an integrated circuit generation system 1406. The IC fabrication system 1402 is configured to receive an IC definition data set (e.g. defining a graphics processing unit, a shader processing unit, load logic, and / or store logic as described in any of the examples herein), process the IC definition data set, and generate an IC (e.g. embodying a graphics processing unit, a shader processing unit, load logic, and / or store logic as described in any of the examples herein) from the IC definition data set. The processing of the IC definition data set configures the IC fabrication system 1402 to fabricate an integrated circuit embodying a graphics processing unit, a shader processing unit, load logic, and / or store logic as described in any of the examples herein.

[0193] The layout processing system 1404 is configured to receive and process the IC definition data set to determine a circuit layout. Methods of determining a circuit layout from an IC definition data set are known in the art and can involve, for example, synthesizing RTL code to determine a gate level representation of the circuit to be generated, e.g. in terms of logic components (e.g. NAND, NOR, AND, OR, MUX and FLIP-FLOP components). By determining the position information of the logic components, a circuit layout can be determined from the gate level representation of the circuit. This can be done automatically or with user involvement in order to optimize the circuit layout. When the layout processing system 1404 has determined the circuit layout, it can output a circuit layout definition to the IC generation system 1406. The circuit layout definition can be, for example, a circuit layout description.

[0194] As is known in the art, the IC generation system 1406 generates an IC from the circuit layout definition. For example, the IC generation system 1406 can implement a semiconductor device manufacturing process for generating an IC, which can involve a multi-step sequence of photolithographic and chemical processing steps during which an electronic circuit is gradually formed on a wafer made of semiconductor material. The circuit layout definition can be in the form of a mask which can be used in a photolithographic process to generate an IC according to the circuit definition. Alternatively, the circuit layout definition provided to the IC generation system 1406 can be in the form of computer readable code which the IC generation system 1406 can use to form appropriate masks for generating an IC.

[0195] The different processes performed by the IC manufacturing system 1402 can all be implemented at one location, e.g. by one party. Alternatively, the IC manufacturing system 1402 can be a distributed system such that some of the processes in the process can be performed at different locations and can be performed by different parties. For example, some of the following stages can be performed at different locations and / or by different parties: (i) synthesizing RTL code representing the IC definition data set to form a gate level representation of the circuit to be generated; (ii) generating a circuit layout based on the gate level representation; (iii) forming a mask from the circuit layout; and (iv) using the mask to manufacture an integrated circuit.

[0196] In other examples, the processing of an integrated circuit definition data set at an integrated circuit manufacturing system can configure the system to manufacture a graphics processing unit, a shader processing unit, load logic and / or store logic without the need to process the IC definition data set in order to determine a circuit layout. For example, the integrated circuit definition data set can define a configuration of a reconfigurable processor such as an FPGA and the processing of the data set can configure the IC manufacturing system to generate a reconfigurable processor having the defined configuration, e.g. by loading configuration data to the FPGA.

[0197] In some embodiments, when processed in an integrated circuit fabrication system, the integrated circuit fabrication definition data set can cause the integrated circuit fabrication system to generate an apparatus as described herein. For example, by the integrated circuit fabrication definition data set, the integrated circuit fabrication system can be configured in the manner described above with reference to Figure 14 The described manner of configuring the integrated circuit fabrication system can result in the manufacture of an apparatus as described herein.

[0198] In some examples, the integrated circuit definition data set can include software that runs on hardware defined at the data set, or in combination with hardware defined at the data set. In Figure 14 In the example shown in FIG. 1, the IC generation system can be further configured by the integrated circuit definition data set to load firmware onto an integrated circuit being manufactured according to program code defined at the integrated circuit definition data set, or otherwise provide program code for use with the integrated circuit, when the integrated circuit is manufactured.

[0199] Compared to known implementations, the concepts set forth in this application can result in performance improvements in the implementation of apparatuses, devices, modules, and / or systems (and in the methods implemented herein). Performance improvements can include one or more of improved computational performance, reduced latency, increased throughput, and / or reduced power consumption. During the manufacture of such apparatuses, devices, modules, and systems (e.g., in integrated circuits), a tradeoff can be made between performance improvements and physical implementation, improving the manufacturing method. For example, a tradeoff can be made between performance improvements and layout area, matching the performance of known implementations but using less silicon. For example, this can be done by reusing functional blocks in a serial manner or sharing functional blocks between elements of the apparatus, device, module, and / or system. Conversely, the concepts set forth in this application that result in improvements in the physical implementation of the apparatuses, devices, modules, and systems, such as a reduction in silicon area, can be traded off for performance improvements. This can be done, for example, by manufacturing multiple instances of a module within a predefined area budget.

[0200] The applicant hereby expressly incorporates by reference the entire contents of all listed patent and non-patent literature cited above. The applicant hereby expressly incorporates by reference the entire contents of all patent and non-patent literature cited above. The applicant hereby expressly incorporates by reference the entire contents of all patent and non-patent literature cited above. The applicant hereby expressly incorporates by reference the entire contents of all patent and non-patent literature cited above. The applicant hereby expressly incorporates by reference the entire contents of all patent and non-patent literature cited above. The applicant hereby expressly incorporates by reference the entire contents of all patent and non-patent literature cited above. The applicant hereby expressly incorporates by reference the entire contents of all patent and non-patent literature cited above. The applicant hereby expressly incorporates by reference the entire contents of all patent and non-patent literature cited above. The applicant hereby expressly incorporates by reference the entire contents of all patent and non-patent literature cited above. The applicant hereby expressly incorporates by reference the entire contents of all patent and non-patent literature cited above. The applicant hereby expressly incorporates by reference the entire contents of all patent and non-patent literature cited above. The applicant hereby expressly incorporates by reference the entire contents of all patent and non-patent literature cited above. The applicant hereby expressly incorporates by reference the entire contents of all patent and non-patent literature cited above. The applicant hereby expressly incorporates by reference the entire contents of all patent and non-patent literature cited above. The applicant hereby expressly incorporates by reference the entire contents of all patent and non-patent literature cited above. The applicant hereby expressly incorporates by reference the entire contents of all patent and non-patent literature cited above. The applicant hereby expressly incorporates by reference the entire contents of all patent and non-patent literature cited above. The applicant hereby expressly incorporates by reference the entire contents of all patent and non-patent literature cited above. The applicant hereby expressly incorporates by reference the entire contents of all patent and non-patent literature cited above. The applicant hereby expressly incorporates by reference the entire contents of all patent and non-patent literature cited above. The applicant hereby expressly incorporates by reference the entire contents of all patent and non-patent literature cited above. The applicant hereby expressly incorporates by reference the entire contents of all patent and non-patent literature cited above. The applicant hereby expressly incorporates by reference the entire contents of all patent and non-patent literature cited above. The applicant hereby expressly incorporates by reference the entire contents of all patent and non-patent literature cited above. The applicant hereby expressly incorporates by reference the entire contents of all patent and non-patent literature cited above. The applicant hereby expressly incorporates by reference the entire contents of all patent and non-patent literature cited above. The applicant hereby expressly incorporates by reference the entire contents of all patent and non-patent literature cited above. The applicant hereby expressly incorporates by reference the entire contents of all patent and non-patent literature cited above. The applicant hereby expressly incorporates by reference the entire contents of all patent and non-patent literature cited above. The applicant hereby expressly incorporates by reference the entire contents of all patent and non-patent literature cited above. The applicant hereby expressly incorporates by reference the entire contents of all patent and non-patent literature cited above. The applicant hereby expressly incorporates by reference the entire contents of all patent and non-patent literature cited above.

Claims

1. A shader processing unit (104) for a graphics processing unit (100), the shader processing unit (104) configured to execute one or more shaders, the one or more shaders including one or more ray tracing shaders that generate ray data associated with one or more rays, the ray data of a ray including a plurality of ray data elements, the shader processing unit (104) comprising: a storage device (110); and storage logic (126) configured to: receive a ray storage instruction (900), the ray storage instruction including: (i) information (902) that identifies a storage group of a plurality of storage groups, each storage group of the plurality of storage groups including one or more ray data elements of the plurality of ray data elements, and (ii) information (904, 906, 910) that identifies one or more ray data elements of the identified storage group to be stored in an external unit (112); in response to receiving the ray storage instruction (900), retrieve the identified ray data elements of one or more rays from the storage device (110); and send one or more storage requests to the external unit (112), the one or more storage requests causing the external unit (112) to store the identified ray data elements for the one or more rays.

2. The shader processing unit (104) of claim 1, wherein the information (904, 906, 910) that identifies the one or more ray data elements of the identified storage group identifies a block of ray data elements of the identified storage group.

3. The shader processing unit (104) of claim 1, wherein the one or more ray data elements of each storage group are partitioned into one or more sets of ray data elements, and the information (904, 906, 910) that identifies the one or more ray data elements of the identified storage group includes information (904, 906) that identifies one or more of the sets of ray data elements of the identified storage group.

4. The shader processing unit (104) of claim 3, wherein each set of ray data elements of a storage group is associated with an offset, the offset indicating an ordering of the set of ray data elements relative to other sets of ray data elements in the storage group, and the information (904, 906, 910) that identifies one or more sets of ray data elements identifies a set of ray data elements associated with an adjoining block of offsets.

5. The shader processing unit (104) of claim 4, wherein the information (904, 906, 910) that identifies the one or more ray data elements of the identified storage group includes information (906) that identifies a starting offset of the adjoining block of offsets and information (904) that identifies a number of offsets in the adjoining block of offsets.

6. The shader processing unit (104) of claim 3, wherein when at least one of the identified sets of ray data elements includes two or more ray data elements, the information (904, 906, 910) identifying one or more ray data elements of the identified storage group includes information (910) identifying a ray data element of each of the at least one of the identified sets of ray data elements that includes two or more ray data elements.

7. The shader processing unit (104) of any one of claims 1 to 6, wherein: the identified ray data elements of the one or more rays are sent to the external unit (112) in a plurality of store transactions, each store transaction including up to a predetermined maximum number of ray data elements; the store logic (126) is configured to divide the identified ray data elements of the one or more rays into the plurality of store transactions; and the one or more store requests sent from the store logic (126) to the external unit (112) include a store transaction request (1200) for each of the plurality of store transactions.

8. The shader processing unit (104) of claim 7, wherein each store transaction includes ray data elements associated with a same ray of the one or more rays.

9. The shader processing unit (104) of claim 7, wherein the ray data elements of each storage group are divided into one or more blocks of ray data elements, and each store transaction includes ray data elements in a same block of ray data elements.

10. The shader processing unit (104) of claim 9, wherein: the one or more ray data elements of each storage group are divided into one or more sets of ray data elements, and the information (904, 906, 910) identifying one or more ray data elements of the identified storage group includes information (904, 906) identifying one or more of the one or more sets of ray data elements of the identified storage group; and each block of ray data elements for a storage group includes one or more of the one or more sets of ray data elements of the storage group.

11. The shader processing unit (104) of claim 10, wherein: each set of ray data elements of a storage group is associated with an offset that indicates an ordering of the set of ray data elements relative to other sets of ray data elements in the storage group, and the information (904, 906, 910) identifying one or more sets of ray data elements identifies a set of ray data elements associated with an adjacent block of offsets; and each block of ray data elements for a storage group includes a set of ray data elements of the storage group associated with an adjacent block of offsets.

12. The shader processing unit (104) of claim 11, wherein: the one or more sets of ray data elements of each storage group are divided into one or more blocks of ray data elements, and each block of ray data elements includes ray data elements in a same block of ray data elements.

13. The shader processing unit (104) of claim 12, wherein: each set of ray data elements of a storage group is associated with an offset that indicates an ordering of the set of ray data elements relative to other sets of ray data elements in the storage group, and the information (904, 906, 910) identifying one or more sets of ray data elements identifies a set of ray data elements associated with an adjacent block of offsets; and each block of ray data elements for a storage group includes a set of ray data elements of the storage group associated with an adjacent block of offsets.

14. The shader processing unit (104) of claim 13, wherein: the one or more blocks of ray data elements of each set of ray data elements are divided into one or more blocks of ray data elements, and each block of ray data elements includes ray data elements in a same block of ray data elements.

15. The shader processing unit (104) of claim 14, wherein: each set of ray data elements of a storage group is associated with an offset that indicates an ordering of the set of ray data elements relative to other sets of ray data elements in the storage group, and the information (904, 906, 910) identifying one or more sets of ray data elements identifies a set of ray data elements associated with an adjacent block of offsets; and each block of ray data elements for a storage group includes a set of ray data elements of the storage group associated with an adjacent block of offsets.

12. The shader processing unit (104) of claim 10, wherein each store transaction request (1200) includes information (1208) identifying the store group identified in the ray store instruction (900), information (1204) identifying a block of ray data elements of the store group, information (1206, 1218) identifying the ray data element of the block identified in the ray store instruction (900), information (1202) identifying a ray of the one or more rays, and the identified ray data element (1210, 1212, 1214, 1216).

13. The shader processing unit (104) of claim 7, wherein the store logic (126) is configured to divide the identified ray data element of the one or more rays into the multiple store transactions by, for each ray of the one or more rays, determining which blocks of ray data elements of the identified store group include the identified ray data element, and for each block of ray data elements that includes the identified ray data element, generating a store transaction request to store the identified ray data element in the block for the ray.

14. The shader processing unit (104) of any one of claims 1 to 6, wherein the ray store instruction (900) is associated with a plurality of rays, and the one or more rays for which the identified ray data element is to be stored are active rays of the plurality of rays.

15. The shader processing unit (104) of any one of claims 1 to 6, wherein the ray store instruction (900) further includes information (908) identifying a location in the storage (110) to store the identified ray data element, and the store logic (126) is configured to retrieve the identified ray data element from the identified location.

16. The shader processing unit (104) of any one of claims 1 to 6, wherein each store group of the multiple store groups is associated with a unique identifier, and the information (902) identifying a store group includes the unique identifier associated with the store group.

17. A method (1000) of processing ray tracing shaders at a shader processing unit of a graphics processing unit, the shader processing unit configured to execute one or more shaders, the one or more shaders including one or more ray tracing shaders that generate ray data associated with one or more rays, the ray data of a ray including a plurality of ray data elements, the method (1000) comprising: receiving (1002), at the shader processing unit, a ray store instruction, the ray store instruction including: (i) information identifying a store group of a plurality of store groups, each store group of the plurality of store groups including one or more ray data elements of the plurality of ray data elements, and (ii) information identifying one or more ray data elements of the identified store group to be stored in an external unit; in response to receiving the ray storage instruction, retrieving (1004) the identified ray data elements for the one or more rays from a storage device of the shader processing unit; and sending (1006) one or more storage requests from the shader processing unit to an external unit, the one or more storage requests causing the external unit to store the identified ray data elements for the one or more rays.

18. A shader processing unit (104) configured to perform the method of claim 17.

19. A graphics processing unit (100) comprising a shader processing unit (104) as claimed in any one of claims 1 to 6.

20. A computer readable storage medium having stored therein an integrated circuit definition data set that, when processed in an integrated circuit manufacturing system, configures the integrated circuit manufacturing system to manufacture a shader processing unit (104) as claimed in any one of claims 1 to 6.

Images