Method and hardware logic for loading ray tracing data into a shader processing unit of a graphics processing unit

Abstract

The present invention relates to a method and hardware logic for loading ray tracing data into a shader processing unit of a graphics processing unit. A shader processing unit for a graphics processing unit is configured to execute one or more ray tracing shaders, the one or more ray tracing shaders processing ray data associated with one or more rays. The ray data for the rays includes a plurality of ray data elements. The shader processing unit includes a storage device and loading logic. The loading logic is configured to receive a ray load instruction as part of a ray tracing shader, the ray load instruction including: (i) information identifying a load group in a plurality of load groups, each load group in the plurality of load groups including one or more ray data elements in the plurality of ray data elements, and (ii) information identifying one or more ray data elements of the identified load group to be retrieved from an external unit.

Description

Technical Field

[0001] The present application relates to methods and hardware logic for loading ray tracing data into a shader processing unit of a graphics processing unit. Background Art

[0002] A graphics processing unit (GPU) is hardware designed to accelerate the generation of rendered output (e.g., an image). Many GPUs today generate rendered output (e.g., an image) by processing graphics data according to one or more programmable shaders. In the case of a GPU supporting ray tracing, the GPU may 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 associated with one or more rays (e.g., origin coordinates, direction coordinates, maximum / minimum intersection distances, acceleration structures). The ray data associated with a ray can be quite large, so the ray data or portions thereof associated with the ray currently being processed by the ray tracing shader can be dynamically loaded into and / or dynamically written out of the shader processing unit when needed or when generated. The ability to efficiently load ray data into and / or write ray data from the shader processing unit can improve the performance of the shader processing unit, and therefore improve the performance of the GPU.

[0003] The embodiments described below are provided by way of example only and are not limited to specific implementations that address any or all of the shortcomings of known shader processing units capable of executing ray tracing shaders. Summary of the Invention

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

[0005] A shader processing unit for a graphics processing unit is described herein, the shader processing unit being configured to execute one or more ray tracing shaders that process ray data associated with one or more rays. The ray data for the rays includes a plurality of ray data elements. The shader processing unit includes a local storage device and load logic. The load logic is configured to receive a ray load instruction as part of a ray tracing shader, the ray load instruction including: (i) information identifying a load group from a plurality of load groups, each load group from the plurality of load groups including one or more ray data elements from the plurality of ray data elements, and (ii) information identifying one or more ray data elements from the identified load group to be retrieved from an external unit. In response to receiving the ray load instruction, the load logic sends one or more load requests to the external unit, the one or more load requests causing the external unit to retrieve the identified ray data elements from the identified load group for the one or more rays. The received ray data elements are then stored in the local storage device of the shader processing unit for processing by the ray tracing shader.

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

[0007] The information identifying the one or more ray data elements of the identified load group may identify individual ray data elements of the identified load group.

[0008] The one or more ray data elements of each load group can be divided into one or more ray data element sets, and the information identifying the one or more ray data elements of the identified load group can include information identifying one or more ray data element sets in the one or more ray data element sets of the identified load group.

[0009] The information identifying one or more ray data elements of the identified load group may include a mask comprising a bit for each of the one or more ray data element sets, the bit identifying the associated ray data element set when set to a certain value.

[0010] When at least one of the identified ray data element sets includes two or more ray data elements, for each ray data element set in the at least one identified ray data element set including two or more ray data elements, the information identifying one or more ray data elements of the identified loading group may also include information identifying one ray data element of the ray data element set.

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

[0012] When the identified load group is of the first type, each load transaction may include a ray data element associated with a same ray of the one or more rays.

[0013] The ray data elements of each load group of the first type may be divided into one or more ray data element blocks, and each load transaction may include ray data elements in the same ray data element block.

[0014] Each block of ray data elements for a load group may include one or more sets of ray data elements of the one or more sets of ray data elements of the load group.

[0015] A set of ray data elements associated with a contiguous block of mask bits of the load group may be included.

[0016] When the identified load group is of the first type, each load transaction request may include information identifying the load group identified in the ray load instruction, information identifying a block of the load group, information identifying the ray data elements identified in the ray load instruction of the block, and information identifying a ray in the one or more rays.

[0017] The load logic may be configured to, when the identified load group is of the first type, divide the identified ray data elements of the one or more rays into the plurality of load transactions by, for each ray of the one or more rays, determining whether each block of ray data elements includes the identified ray data element, and for each block of ray data elements that includes the identified ray data element, generating a load transaction request to retrieve the identified ray data element in the block for the ray.

[0018] When the identified load group is of the second type, each load transaction of the plurality of load transactions includes a same ray data element of the one or more rays.

[0019] The ray load instructions may be associated with a plurality of rays divided into one or more ray blocks, and when the identified load group is of the second type, each load transaction includes the same ray data element of one or more rays in the same ray block.

[0020] The load logic may be configured to, when the identified load group is of the second type, divide the identified ray data elements of the one or more rays into the plurality of load transactions by, for each of the identified ray data elements, determining which ray block includes an active ray, and, for each ray block including active rays, generating a load transaction request to retrieve the ray data elements of the active ray in the ray block.

[0021] When the identified load group is of the second type, each load transaction request may include information identifying the load group identified in the ray load instruction and information identifying one or more rays.

[0022] The information identifying the one or more rays may include information identifying a block of rays and information identifying active rays in the block of rays.

[0023] The ray load instruction may be associated with a plurality of rays, and the one or more rays for which the ray data element identified by the request is targeted may be active rays of the plurality of rays.

[0024] The ray load instruction may further include information identifying a location in the storage device at which the received ray data element is to be stored, and the load logic may be configured to store the received ray data element at the identified location.

[0025] Each load group in the plurality of load groups may be associated with a unique identifier, and the information identifying the load group may include the unique identifier associated with the load group.

[0026] The shader processing unit may also include storage logic configured to: receive a ray storage instruction, the ray storage instruction including (i) information identifying a storage group in a plurality of storage groups, each storage group in the plurality of storage groups including one or more ray data elements from 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; in response to receiving the ray storage instruction, retrieve the identified ray data elements of the one or more rays from the storage device; and send one or more storage requests to the external unit, the one or more storage requests causing the external unit to store the identified ray data elements of the identified storage group for the one or more rays.

[0027] At least one load group of the plurality of load groups may be different from each of the memory groups of the plurality of memory groups.

[0028] A second aspect provides a method for 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, the one or more shaders including one or more ray tracing shaders processing ray data associated with one or more rays, the ray data for the rays including a plurality of ray data elements, the method comprising: receiving a ray load instruction at the shader processing unit, the ray load instruction including (i) information identifying a load group of a plurality of load groups, each load group of the plurality of load 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 load group to be retrieved from an external unit; in response to receiving the ray load instruction, sending one or more load requests from the shader processing unit to the external unit, the one or more load requests causing the external unit to retrieve the identified ray data elements of the identified load group for the one or more rays; receiving, at the shader processing unit, the identified ray data elements for the one or more rays from the external unit; and storing the received ray data elements in a storage device of the shader processing unit for processing by the ray tracing shader.

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

[0030] A fourth aspect provides a graphics processing unit, which includes the shader processing unit of the first aspect or the third aspect.

[0031] The graphics processing unit may further include an external unit that may include one or more local storage units and is configured to map the ray data elements of each load group to locations in the one or more local storage units.

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

[0033] An integrated circuit manufacturing system may be provided, comprising: a non-transitory computer-readable storage medium having stored thereon a computer-readable description of a shader processing unit, a load unit, a storage unit, or a graphics processing unit described herein; a layout processing system configured to process the computer-readable description to generate a circuit layout description of an integrated circuit embodying the shader processing unit, the load unit, the storage unit, or the graphics processing unit; and an integrated circuit generation system configured to manufacture the shader processing unit, the load unit, the storage unit, or the graphics processing unit based on the circuit layout description.

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

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

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

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

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

[0039] Figure 3 is a diagram of an example format of a ray loading instruction;

[0040] Figure 4 is a flow chart of an example method for processing a ray load instruction;

[0041] Figure 5 is a flow chart of a first example method of converting a ray load instruction into a plurality of load transaction requests;

[0042] Figure 6 is a diagram of an example format of a load transaction request;

[0043] Figure 7 is a flow chart of a second example method of converting a ray load instruction into multiple load transactions;

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

[0045] Figure 9 is a schematic diagram of an example format of a ray storage instruction;

[0046] Figure 10 is a flow chart of an example method of processing a ray storage instruction;

[0047] Figure 11 is a flow chart of an example method for converting a ray storage instruction into a plurality of storage transaction requests;

[0048] Figure 12 is a diagram of an example format of a storage transaction request;

[0049] Figure 13 is a block diagram of an example computer system in which the shader processing unit, load unit, store unit, and / or graphics processing unit described herein may be implemented; and

[0050] Figure 14 is a block diagram of an example integrated circuit fabrication system for producing an integrated circuit embodying a shader processing unit, a load unit, a store unit, and / or a graphics processing unit as described herein.

[0051] The accompanying drawings illustrate various examples. It will be appreciated by those skilled in the art that the element boundaries (e.g., boxes, groups of boxes, or other shapes) shown in the accompanying drawings represent one example of boundaries. In some examples, it may be the case 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 accompanying drawings to indicate similar features. DETAILED DESCRIPTION

[0052] The following description is presented by way of example to enable one skilled in the art to make and use the invention. The invention 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.

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

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

[0055] Shaders used to implement rasterization techniques include, but are not limited to, vertex shaders, which are used to transform attributes of vertices of geometric shapes (e.g., primitives), such as color, texture, position, and orientation; geometry shaders, which are capable of dynamically creating new geometric shapes; and pixel shaders or fragment shaders, which are configured to operate on individual pixels or fragments to achieve complex visual effects.

[0056] In contrast to rasterization, where the effect of light on an image can only be approximated, ray tracing simulates how light works in the real world. Specifically, ray tracing sends light from the user's viewpoint into the scene, onto objects, and from there to light sources. As the light interacts with objects, it is blocked, reflected, or refracted by them, depending on their material properties, resulting in shadows and reflections.

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

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

[0059] 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 that includes a plurality of scalable processing units (SPUs) 102, each of which includes a plurality of shader processing units 104. Figure 1 In the example of FIG104, each shader processing unit is implemented as a unified shading cluster (USC), but this is merely an example. Each USC 104 can execute multiple different types of shader tasks supported by GPU 100. Specifically, each USC 104 receives a shader task from scheduler 106. Each shader task specifies data to be processed and a shader (e.g., a program) to be used to process the data. In response to receiving a shader task, USC 104 executes the identified shader for the identified data. Executing a shader may include executing an instruction set that forms the shader.

[0060] Each USC 104 may include a plurality of arithmetic logic units (ALUs) 108 that may be configured to execute specific 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 may be used by the USC 104. The USC 104 may typically execute multiple shader tasks simultaneously, and each of those shader tasks shares the local storage 110. If the GPU 100 supports ray tracing, the USC 104 may be capable of executing ray tracing shaders. Ray tracing shaders generally execute on ray data (i.e., data associated with rays) and / or generate ray data. However, because there may be many rays in flight (i.e., being processed), and each ray may 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 rays in flight in the local storage 110 may not leave sufficient space in the local storage 110 to run other shader tasks, which may reduce the efficiency of the USC 104. Therefore, all of the ray data may be stored in a storage unit of an external unit (i.e., a unit external to the USC 104), and portions thereof may be loaded into the USC 104 when needed by the USC 104, or written out of the USC 104 when generated thereby.

[0061] For example, Figure 1 As shown in FIG, the GPU 100 may include an external unit 112 (which is implemented as an example) Figure 1 In the embodiment of the present invention, the external unit includes one or more storage units 114, 116 for storing ray data, and the USC 104 and RAC 112 can be connected by one or more interfaces 118, 120 that allow 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 storage interface 120 that allows data to be transferred from the USC 104 to the RAC 112. Figure 1In the example shown in FIG, RAC 112 includes an interface module 122, which may be referred to as a USC-RAC interface (URI) 122, which is configured to (i) receive a request for ray data from USC 104 and provide the requested data from RAC 112 storage units 114, 116 to USC 104 via a load interface 118; and (ii) receive a request from USC 104 via a storage interface 120 to write ray data to one or more of RAC storage units 114, 116 and write the received data to one or more of RAC 112 storage units 114, 116. In some cases, RAC 112 may also include Figure 1 For example, RAC 112 may include one or more components to accelerate certain ray tracing operations.

[0062] To enable retrieval of ray tracing data from the RAC 112 storage units 114, 116, each USC 104 may include load logic 124 configured to receive a load instruction identifying ray data to be loaded into the USC 104 and to send a read request to the RAC 112 to retrieve the identified ray data. To enable storage of ray tracing data generated by the USC 104 in the RAC 112 storage units 114, 116, each USC 104 may include store logic 126 configured to receive a store instruction identifying ray data to be stored in the RAC 112 storage units 114, 116 and to send a write request to the RAC 112 to store the identified ray data in the RAC 112 storage units 114, 116. However, with Figure 1 A GPU of the structure shown in (or similar structure) (which is known to the applicant, but no admission is made that they are well known or known outside the applicant company) is configured to receive and process load and store instructions that identify a single memory block (e.g., a doubleword (dword), 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.

[0063] In this type of configuration, 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, because portions of ray data used and / or generated by different ray tracing shaders are typically scattered across the RAC 112 memory cells 114, 116 along with other ray data, 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 results in inefficient use of the load interface 118 and storage interface 120 between the USC 104 and RAC 112. Furthermore, while requesting / writing individual ray data blocks allows only the required ray data to be transferred between the RAC 112 and USC 104, thereby making more efficient use of the load interface 118 and storage interface 120 between the USC 104 and RAC 112, this comes at the expense of the USC 104 having to store, fetch, and execute multiple instructions.

[0064] Thus, described herein is a shader processing unit (e.g., USC) having: (i) load logic 124 configured to receive and process load instructions that allow ray data to be more efficiently loaded from RAC 112 to USC 104; and / or (ii) store logic 126 configured to receive and process store instructions that allow ray data to be more efficiently written from USC 104 to RAC 112. Specifically, in the examples described herein, ray data includes a plurality of ray data elements, and a plurality of groups of ray data elements are defined, wherein each group of ray data elements includes a set of related ray data elements. Ray tracing elements may be "related" if they are often retrieved from or written to RAC 112 storage units 114, 116 together by a ray tracing shader. USC 104 (i.e., load logic 124 and / or store logic 126) is then configured to (i) receive and process load instructions that allow a combination of ray data elements in the same group to be retrieved from an external unit (e.g., RAC 112 storage 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., RAC 112 storage units 114, 116) using a single instruction. As described in more detail below, the grouping of ray data elements for load instructions can be different from the grouping of ray data elements for store instructions.

[0065] Because related ray data elements (those in a group) that may be scattered 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 related but scattered ray data elements. Furthermore, because different combinations of ray data elements in a group can be identified, time and resources are not wasted transferring ray data elements that will not be used by the ray tracing shader, thereby making more efficient use of the load interface 118 between the USC 104 and the RAC 112. Similarly, because related ray data elements (those in a group) that may be scattered 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 related but scattered ray data elements.

[0066] although Figure 1 Load logic 124 configured to receive and process load instructions and separate store logic 126 configured to receive and process store instructions are shown, but in other embodiments, USC 104 may include common load / store logic configured to process both load and store instructions.

[0067] Ray load (RLOAD) instruction

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

[0069] Specifically, 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, ray data elements may have different maximum sizes. Examples of ray data elements are 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 may be fewer ray data elements, more ray data elements, and / or different combinations of ray data elements.

[0070] Table 1

[0071]

[0072]

[0073] In the examples described herein, multiple load groups (which may also be referred to as load spaces) of ray data elements are defined. Each load group of ray data elements includes a subset of ray data elements that may be associated with a ray. Load groups can be defined such that each load group includes ray data elements that are likely to be requested together by one or more ray tracing shaders. For example, a shader that performs intersection queries may use only geometric information (e.g., the origin and direction of the ray), so a load group may be defined that includes ray data elements representing the geometric information; and a shader that processes intersections between rays and primitives (e.g., to determine color) may use additional ray data elements, so a different load group may be defined that includes ray data elements representing the geometric information and one or more additional ray data elements. Thus, the specific ray data elements that form a load group may depend on the configuration of the ray tracing shader.

[0074] Now refer to Figure 2, which shows an example set of load groups formed by 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 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 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 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 a combination of NCM_T, NCM_INST_IN, NCM_PRIM_IN, NCM_GEOM_IN, MISS_INDEX, SBT_OFFSET and SBT_STRIDE ray data elements. It can be seen that the ray data element can form the part of only one load group, or the ray data element can form the part of more than one load group. For example, the FLAGS ray data element forms the part of both the tracking load group and the query load group. Therefore, a load group may not include disjoint subsets of ray data elements. In other words, two or more load groups in a load group may include overlapping subsets of ray data elements.

[0075] Now refer 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 may optionally include one or more other fields, some of which are discussed below.

[0076] The load group identifier field 302 (also referred to as the SPACE field or group field) includes information that identifies one of a plurality of load groups. In some cases, each load group may be associated with a unique numeric identifier, and a particular load group may be 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 may be selected based on the number of load groups. For example, the minimum number of bits for the SPACE field 302 may be Where Y is the number of loading groups. Table 2 shows Figure 2 . In this example, there are seven load groups, so the SPACE field 302 may include three bits. It will be apparent to those skilled in the art that this is merely an example.

[0077] Table 2

[0078]

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

[0080] In contrast, the ray data elements of a 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, when a trace load group is identified, 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.

[0081] In some cases, a set of ray data elements for a load group may include only one ray data element, or multiple mutually exclusive ray data elements for the load group. The term "mutually exclusive ray data elements of a load group" is used herein to mean ray data elements that are not requested simultaneously by shaders associated with the load group (e.g., shaders that are expected to reference the load group). For example, if one ray data element is to be used at one point in the ray tracing process and another ray data element is to be used at another point in the ray tracing process, then both ray data elements may not be requested simultaneously. For example, a shader may process either candidate data or submitted data, but not both. Therefore, a candidate ray data element (CD_T) and a corresponding submitted ray data element (e.g., CM_T) may 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 may exist, and that there may be other reasons why ray data elements may be mutually exclusive. In some cases, two ray data elements may be mutually exclusive for one load group, and the same two ray data elements may not be mutually exclusive for another load group.

[0082] In some cases, the ray data element set identifier field 304 can be implemented by a mask comprising multiple bits, and each ray data element set in the load group is associated with one of these bits. In these cases, the ray data element set identifier field 304 can be referred to as a MASK field. In some cases, when a ray data element in an associated set is to be retrieved, the bit can be set to one value (e.g., '1'), and if no ray data element in the associated set is to be retrieved, the bit can be set to a different value (e.g., '0'). In the case where the identified set includes only one ray data element, the corresponding bit in the MASK field is set to specifically identify 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 simultaneously.

[0083] It may be predefined 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 the mask. 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, and 6 of the mask, respectively. Thus, if the SPACE field identifies a primary load group and bits 0, 1, and 2 of the MASK field are set, the PAYLOAD_0, PAYLOAD_1, and PAYLOAD_2 ray data elements will be retrieved from an external unit (e.g., RAC 112) and loaded into USC 104.

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

[0085] As described above, in some cases, a set may include more than one ray data element (such a set may be referred to herein as a multi-ray data element set). In such cases, setting the corresponding mask bit does not identify a specific ray data element to be retrieved from the external unit (e.g., RAC 112). In such cases, RLOAD instruction 300 may include a space control field 308 (which may also be referred to as a SPACE_CTRL field) that includes information identifying which ray data element of the multi-ray data element set is to be retrieved. For example, in Figure 2 , set 7 of trace groups is a multiple-ray data element set that includes CM_T ray data elements and CD_T ray data elements. In this example, when the SPACE field identifies a trace load group and the seventh bit of the MASK field is set, the SPACE_CTRL field can be used to identify whether CM_T ray data elements or CD_T ray data elements are to be retrieved. For example, the SPACE_CTRL field can include a single bit that, when the SPACE and MASK fields are set as described, identifies whether CM_T ray data elements or CD_T ray data elements are to be retrieved. For example, if CM_T ray data elements are to be retrieved, the SPACE_CTRL field can be set to '1', and if CD_T ray data elements are to be retrieved, the field can be set to '0'. Allowing multiple 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.

[0086] exist Figure 2 In the example load groups shown in FIG, only one load group (i.e., the tracking load group) has multiple ray data element sets, and only one multiple 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, more than one load group may have at least one multiple ray data element set, and one or more load groups may have more than one multiple ray data element set. In some cases, where at least one load group includes more than one multiple 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 multiple ray data element set. For example, if a load group includes a first set including ray data element 0 and ray data element 1, and a second set including ray data element 2 and ray data element 3, the SPACE_CTRL field may include a first bit that can be used to select between ray data element 0 and ray data element 1, and a second bit that can be used to select between ray data element 2 and ray data element 3. In other cases, where a load group includes more than one set of multiple ray data elements, a single bit in the SPACE_CTRL field 308 may be used to select one element of each set of multiple ray data elements. For example, if the load group includes a first set including ray data element 0 and ray data element 1 and a second set including ray data element 2 and ray data element 3, the SPACE_CTRL field may include a first bit that, when set to one value (e.g., '0'), selects the first ray data element in each set of multiple ray data elements (i.e., ray data elements 0 and 2), and, when set to another value (e.g., '1'), selects the second ray data element in each set of multiple ray data elements (i.e., ray data elements 1 and 3).

[0087] 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., a program) to be used to process the data. In response to receiving the 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 can be applied to one or more of the multiple rays. Thus, an RLOAD instruction executed as part of a shader task is said to be associated with multiple rays associated with the shader task, and wherein the identified ray data elements are to be retrieved from an external unit (e.g., RAC 112) for one or more of the rays associated with the RLOAD instruction.

[0088] As described in more detail below, for an RLOAD instruction executed as part of a shader task, not all of the rays associated with the ray tracing shader task are 'active,' and preferably, only 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 applies. Accordingly, in the method described below, a determination is made as to which of a plurality of rays associated with an RLOAD instruction are active for the RLOAD instruction, and ray data elements identified in the RLOAD instruction are retrieved only for the active rays. However, in other examples, rather than determining which of the rays associated with the RLOAD instruction are active, it may be simpler to simply load the identified ray data elements for all of the rays associated with the RLOAD instruction.

[0089] The active rays for an RLOAD instruction may be set at the shader task level or the instruction level. Specifically, some rays may be inactive for a ray tracing shader task such that these rays will be inactive for any RLOAD instruction executed as part of that ray tracing shader task. However, different RLOAD instructions executed as part of the same ray tracing shader task may have different active rays. For example, rays 1 and 2 associated with a ray tracing shader task may 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 may be active for a second, different RLOAD instruction executed as part of the ray tracing shader task.

[0090] Now refer to Figure 4 , which illustrates an example method 400 for executing an RLOAD instruction at the USC 104. The method begins at block 402, where the USC 104 (e.g., load logic 124) receives an RLOAD instruction, such as for Figures 2 to 3 As described above, the RLOAD instruction identifies a predefined load group of ray data elements (e.g. Figure 2116) and the particular ray data elements of the load group to be retrieved from the external unit (e.g., RAC 112). After receiving the RLOAD instruction, method 400 proceeds to block 404, where USC 104 (e.g., load logic 124) sends one or more load requests to the external unit (e.g., RAC 112) that cause, for each ray of the one or more rays associated with the RLOAD instruction (e.g., all or a subset of the plurality of rays associated with the RLOAD instruction), the identified ray data elements of the identified load group to be retrieved from storage of the external unit (e.g., RAC 112 storage units 114, 116) and send the identified ray data elements to USC 104 (e.g., load logic 124). The method 400 then proceeds to blocks 406 and 408 , where the USC 104 (eg, the load logic 124 ) receives the identified ray data elements for each of the one or more rays via the load interface 118 and stores the received ray data elements in the USC 104 storage 110 .

[0091] The load interface 118 between an external unit (e.g., RAC 112) and the USC 104 may not be large enough to receive all of the requested ray data elements in the same cycle. Therefore, the USC 104 may receive the requested ray data elements over multiple cycles. The set of one or more ray data elements received in a cycle may 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 simultaneously. 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).

[0092] In some cases, USC 104 may be configured to implement this by converting a received RLOAD instruction into multiple load transactions and sending a separate load transaction request to an external unit (eg, RAC 112) for each load transaction. Figure 44. Block 404 of 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 transferring the ray data elements identified in the RLOAD instruction from the external unit (e.g., RAC 112) to the USC 104 would take four load transactions, the USC 104 (e.g., load logic 124) can generate and transmit four load transaction requests to the external unit (e.g., RAC 112). The USC 104 then receives the four load transactions with the identified ray data elements.

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

[0094] Having a load transaction include ray data elements from the same ray may allow for more efficient transfer of ray data elements over the load interface 118, compared to a load transaction having the same ray data elements from one or more rays (where, for example, active rays for multiple rays associated with an RLOAD instruction are spread across the multiple rays). For example, as described in more detail below, a ray generation shader task may be associated with multiple rays (e.g., a ray generation shader task may generate multiple rays), and after generating those rays, a hierarchical search may be performed to determine which rays are "hit" and which are "miss." A miss shader task may then be associated with the multiple rays, but the miss shader task may only need to operate on those rays of the multiple rays that "missed" (these rays may be referred to as active rays for an RLOAD instruction executed as part of the miss shader task). Similarly, a hit shader task is associated with multiple rays, but the hit shader task may only need to operate on those rays of the multiple rays that are "hit" (for RLOAD instructions executed as part of the hit shader task, these rays may be referred to as active rays). If the multiple rays are divided into blocks, and load transactions can only include the same ray data element for rays in the same block, then if only one ray in each ray block is active, then each load transaction will only include one ray data element (which is not an efficient use of the load interface 118). This means that if there are many ray data elements to be loaded into the USC 104 per ray, then many load transactions may be required to load all of the required ray data elements.

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

[0096] As described above, each load transaction of a per-ray load group may include only ray data elements associated with the same ray. For example, a per-ray load group load transaction may include the ORIGIN_X, ORIGIN_Y, and ORIGIN_Z ray data elements of the same ray. In contrast, a per-ray load group load transaction may not include the CM_T ray data elements of the first ray and the CM_T ray data elements of the second ray. In some cases, the ray data elements of the per-ray load group are divided into one or more blocks, and a load transaction may include only ray data elements in the same block. In these cases, when USC 104 (e.g., load logic 124) receives an RLOAD instruction with a per-ray load group identified, USC 104 (e.g., load logic 124) may 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 the block (for each (active) ray associated with the RLOAD instruction). Therefore, in this RLOAD conversion technique, no load transaction requests are issued for empty blocks of the identified load group—that is, no load transaction requests are generated for blocks of the identified load group that do not include at least one identified ray data element. However, for each ray in the one or more rays, a load transaction request is generated for each block that includes at least one identified ray data element.

[0097] For example, suppose Figure 2 Each of the example load groups shown in , except the RID load group, is a per-ray load group. Figure 2 As can be seen in Figure 2, 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.

[0098] Since the maximum number of ray data elements that can be transferred as part of a single load transaction is M, only M ray data elements in a block can be transferred as part of a single transaction. Therefore, each block can include at most 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 the block. In the example described herein, M is four (i.e., four ray data elements can be transferred as part of a single load transaction), so Figure 2 Each of the blocks shown in includes up to four sets of ray data elements. For example, a first block of a trace load group includes four sets of ray data elements (sets 0 to 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 a second block of the trace load group includes four sets of ray data elements (sets 4 to 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 mutually exclusive CM_T and CD_T ray data elements.

[0099] As described above, in some cases, the ray data element set identifier field 304 may be implemented as a mask comprising multiple bits (i.e., a MASK field), and each ray data element set of a load group is associated with a particular bit of the mask. In such cases, the ray data elements in a block may be a set of ray data elements associated with a contiguous set of mask bits (e.g., M mask bits). For example, Figure 3 , the first block of each load group may include a set of ray data elements associated with the first four mask bits (e.g., bits 0 through 3), the second block of each load group may include a set of ray data elements associated with the next four mask bits (e.g., bits 4 through 7), the third block of each load group may include a set of ray data elements associated with the next four mask bits (e.g., bits 8 through 11), etc. As described in more detail below, this may allow USC 104 (e.g., 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, therefore, for which blocks to generate load transaction requests—based on the MASK field bits of the RLOAD instruction.

[0100] As described above, in some cases, the external unit (RAC 112) may have multiple storage units 114, 116, and / or one or more of the storage units 114, 116 may be subdivided into multiple buckets, and different ray data elements may be stored in different storage units and / or different buckets of a storage unit. In some cases, the set of ray data elements for a load group may be arranged into blocks such that ray data elements stored in the same storage unit 114, 116 and / or the same bucket of that storage unit are in the same block, allowing the remote unit (e.g., RAC 112) to generate load transactions more efficiently. Specifically, load transactions that include ray data elements from the same storage unit and / or the same bucket thereof are faster and easier to generate than load transactions that include ray data elements from different storage units and / or buckets thereof. For example, since the LAUNCH_ID_X, LAUNCH_ID_Y, and LAUNCH_ID_Z ray data elements are stored in the same memory cells 114 and 116 and in the same section thereof, these ray data elements are placed in the same block of the primary load group. Figure 2 As shown in , this may mean that there are gaps in the numbering of ray data element sets—eg, there is no ray data element set 3 in the primary load group—however, this may improve the efficiency and speed with which a remote unit (eg, RAC 112) can generate load transactions.

[0101] Now refer to Figure 5 , which illustrates an example method 500 that may be implemented by the USC 104 (e.g., the load logic 124) to convert an 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 (which may also be referred to as an instance identifier). The current ray identifier identifies one of a plurality of rays associated with the RLOAD 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 RLOAD instruction. In some cases, each of the plurality of rays associated with the RLOAD 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, the method 500 proceeds to block 504.

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

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

[0104] 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 the event that the RLOAD instruction includes the 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 blocks to determine whether any of the mask bits are set. Where RT_USC_DATA_WIDTH is the width (in bits) of the load interface 118, RAY_DATA_ELEMENT_WIDTH is the width (in bits) of each ray data element, BLOCK is the current block, and MASK is the mask field of the RLOAD instruction, the bits associated with the current block may be bits ((RT_USC_DATA_WIDTH / RAY_DATA_ELEMENT_WIDTH)*(BLOCK+1)-1) through (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.

[0105] At block 512, USC 104 (e.g., load logic 124) generates and sends a load transaction request for the requested / identified ray data element in the current block of the identified load group to an external unit (e.g., RAC 112) for the current ray. In some cases, the load transaction request may 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 element of the block.

[0106] Figure 6 6 shows an example format for a load transaction request 600 when the identified load group is a per-ray load group. Example load transaction request 600 includes a ray identifier field 602, a chunk identifier field 604, a ray data element set identifier field 606, and a load group identifier field 608. Ray identifier field 602 (which may also be referred to as an INSTANCE field) identifies the ray associated with the request and may be set to the value of the current ray identifier. Chunk identifier field 604 (which may also be referred to as an ADDR field) identifies the chunk (of the identified load group) associated with the request. Chunk identifier field 604 may be set to the value of the current chunk identifier. Ray data element set identifier field 606 (which may be referred to as a MASK field when implemented as a mask) identifies the set of ray data elements in the chunk from which ray data elements are to be retrieved. The ray data element set identifier field 606 may include bits of the RLOAD MASK field that are relevant to the identified block (e.g., bits ((RT_USC_DATA_WIDTH / RAY_DATA_ELEMENT_WIDTH)*(BLOCK+1)-1) to (RT_USC_DATA_WIDTH / RAY_DATA_ELEMENT_WIDTH)*(BLOCK)). A load group identifier field 608 (which may also be referred to as a SPACE field) identifies the load group. The load group identifier field 608 may be configured to include load group identifier information in the RLOAD instruction. In the event that the RLOAD instruction includes a SPACE_CTRL field, the load transaction request 600 may also include a SPACE_CTRL field 610 that includes 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 may take a different form.

[0107] Back to Figure 5Upon receiving a load transaction request, the external unit (e.g., RAC 112) determines the location of the requested ray data elements in a storage device (e.g., RAC 112 storage units 114, 116) based on the load group, block, and ray data element information, retrieves the requested ray data elements from the storage device, and transmits the requested ray data elements as part of the load transaction to USC 104. Specifically, the external unit (e.g., RAC 112) may include information that maps the load group and its individual ray data elements to storage locations.

[0108] Once the USC 104 has generated and sent a load transaction request to an external unit (eg, the RAC 112 ), the method 500 proceeds to block 514 .

[0109] At block 514, the USC 104 (e.g., load logic 124) determines whether the current block is the last block (i.e., whether the load logic 124 has checked all blocks). If the block identifier is implemented as a counter initialized to 0, the USC 104 can determine whether the current block is the last block by comparing the block counter to (maximum number of blocks per load group - 1). If the ray data element set identifier field is implemented as a MASK field, the maximum number of blocks 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, if 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 blocks per load group. If it is determined that the current block is the last block, the method 500 proceeds to block 508. However, if it is determined that the current block is not the last block, the method 500 proceeds to block 516.

[0110] At block 516, the USC 104 (e.g., the 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., the load logic 124) determines whether any of the ray data elements associated with the new current chunk have been requested.

[0111] At block 508, the USC 104 (e.g., 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 the event that the current ray identifier is implemented as a counter initialized to 0, the USC 104 (e.g., load logic 124) may 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 may be 128. However, it will be apparent that this is merely an example, and in other examples, a different number of rays may be 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 at 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.

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

[0113] As described above, each load transaction per ray block load group may include only the same ray data elements for multiple rays. For example, a load transaction per ray block load group may include the CM_T ray data element for a first ray and the CM_T ray data element for a second ray. In contrast, a load transaction per ray block load group may not include the ORIGIN_X, ORIGIN_Y, and ORIGIN_Z ray data elements for a ray. In some cases, the rays associated with an RLOAD instruction may be divided into blocks, and the load transactions per ray block load group may include only ray data elements associated with rays in the same block. The number of rays in a block may be based on the maximum number of ray data elements in the load transaction. For example, if a load transaction may include up to four ray data elements, the rays associated with the RLOAD instruction may be divided into four blocks. In these cases, when the USC 104 (e.g., the load logic 124) receives an RLOAD instruction in which a per-ray block 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 ray blocks include at least one active ray, and for each block including at least one active ray, generating and transmitting a load transaction request for the ray data element identified in the RLOAD instruction. This process can be repeated for each ray data element identified in the RLOAD instruction. Therefore, in this RLOAD conversion technique, load transaction requests may not be generated and transmitted for inactive ray blocks—that is, load transactions may not be generated for ray blocks that do not include any active rays.

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

[0115] At block 704, the 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, the USC 104 (e.g., load logic 124) may 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, the method 700 proceeds to block 706. However, if it is determined that the current ray block does not include any active rays, the method 700 proceeds directly to block 708.

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

[0117] Load transaction requests can take Figure 6 . However, in this case, the ray identifier field 602 can be used to identify a ray block by, for example, identifying 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 unused or 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 having a bit for each ray in the ray block. When the corresponding ray is active, the bit can be set to one 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 a 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. In the event that the RLOAD instruction includes a SPACE_CTRL field, the load transaction request may also include a SPACE_CTRL field 610 that includes the SPACE_CTRL information from the RLOAD instruction.

[0118] Upon receiving a load transaction request, the external unit (e.g., RAC 112) determines the location of the requested ray data elements in storage (e.g., RAC 112 storage units 114, 116) based on the ray block, ray activity, and load group information, retrieves the requested ray data elements from the storage, and transmits the requested ray data elements as part of the load transaction to USC 104. Specifically, the external unit (e.g., RAC 112) may include information that maps the load group and its individual ray data elements to storage locations.

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

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

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

[0122] In some cases, when executing 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) may be configured to perform one or more safety checks on the RLOAD instruction. For example, prior to sending a load transaction request to an external unit (e.g., RAC 112), the USC 104 (e.g., load logic 124) may be configured to verify that sufficient USC 104 storage devices 110 have been allocated to store the ray data elements identified in the RLOAD instruction. This verification is performed to ensure that the USC 104 storage devices 110 are not corrupted by writing to addresses outside of the allocated area. In some cases, the USC 104 may be configured to receive (in addition to the RLOAD instruction) information indicating the amount of storage allocated per ray / instance, and the USC 104 may be configured to determine whether sufficient USC 104 storage 110 has been allocated by comparing the amount of storage allocated per ray / instance 110 with the number of ray data elements requested per ray / instance. In the case where the ray data element set identifier field is implemented as a mask, the USC 104 (e.g., load logic 124) may determine the number of ray data elements requested per ray by counting the number of bits in the MASK field of the RLOAD instruction indicating that ray data elements have been requested. If the number of ray data elements requested per ray is greater than the amount of storage allocated per ray 110, then an error exists and an exception may be generated.

[0123] Ray Store (RSTORE) instruction

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

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

[0126] Now refer to Figure 8, which shows an example set of storage groups formed by the ray data elements of Table 1. In this example, there are three storage groups marked as 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 a shader can write a combination of these ray data elements to an external unit (e.g., RAC 112) using a single RSTORE instruction. 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 a shader can write a combination of these ray data elements to an external unit (e.g., RAC 112) using a single RSTORE instruction. 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 ray data element and the V ray data element 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.

[0127] It can be seen that in the example shown in this article, the loading group ( Figure 2 ) is different from the storage group ( Figure 8 ). This may be beneficial when the ray data elements generated by the ray tracing shader are different from 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 may be a single set of ray data element groups for RLOAD and RSTORE instructions.

[0128] Now refer to Figure 9, which shows an example format of a ray store (RSTORE) instruction 900 for storing ray data elements in an external location, such as RAC 112. RSTORE instruction 900 includes a storage group identifier field 902, a length (LENGTH) field 904, and an offset (OFFSET) field 906. RSTORE instruction 900 may optionally include one or more other fields, some of which are discussed below.

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

[0130] Table 3

[0131]

[0132] The offset field 906 and the length field 904 together identify the ray data element of the identified storage group to be stored in the external location (eg, RAC 112). Figure 3 The ray data element set identifier field 304 of the depicted example RLOAD instruction allows for identification (and thus retrieval from an external unit) of a combination of individual ray data elements in the identified load group, but in Figure 9 In the example RSTORE instruction 900 shown in FIG, only contiguous groups of ray data elements in a storage group may be identified.

[0133] Specifically, 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 the set can be written to the external unit. This means that if a storage group has ten ray data element sets, only ten ray data elements of that storage group can be stored per ray store instruction. In some cases, a ray data element set may include only one ray data element, or multiple mutually exclusive ray data elements of the storage group. Mutually exclusive ray data elements for a storage group are ray data elements that are not written together by the shader that is intended to use that storage group. It should be noted that ray data elements may be mutually exclusive for some storage groups, but not for other storage groups.

[0134] Each set of ray data elements of the storage group is then associated with information (e.g., a value or offset) indicating the order or position of the set in the storage group. A contiguous group of ray data elements in the storage group can then be identified by identifying a first set of ray data elements that includes the ray data elements to be written to the external unit and the total number of ray data elements to be written. Figure 9 In the example shown in , the offset field 906 includes information identifying the location (e.g., offset) of a first set of ray data elements that includes ray data elements to be written to the external unit, and the length field 904 includes information indicating the number of ray data elements to be written.

[0135] How the ray data elements of the storage group are divided into ray data element sets and which ray data element sets are associated with which position values ​​or offset values ​​may be predefined. Figure 81 . An example partitioning of the ray data elements of the storage group shown therein into sets and the mapping between sets and offset values ​​is shown. For example, for a calling storage group, its ray data elements are divided 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 an offset value of 0, the second set (including the PAYLOAD_0 ray data element) is associated with an offset value of 1, and the third set (including the PAYLOAD_1 ray data element) is associated with an offset value of 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 may be set to identify the calling storage group, the offset field 906 may be set to include the offset of the first set of ray data elements to be written (i.e., to an offset of 4 (decimal)), and the length field may be set to 6 (decimal) to indicate that 6 ray data elements will be written.

[0136] Similarly, in Figure 8As can be seen in the figure, the tracking storage group is divided into sixteen sets of ray data elements. Except for two sets, each set only includes a single ray data element. Specifically, one set includes both the NCM_T ray data element and the TMIN ray data element, and the other set includes both the CM_T ray data element and the CD_T ray data element. This means that a single RSTORE instruction that identifies the tracking storage group can be used to write NCM_T or TMIN ray data elements to an external unit, but not both. Similarly, a single RSTORE instruction that identifies the tracking storage group can be used to write CM_T or CD_T data elements to an external unit (such as RAC 112), but not both. Similar to calling a storage group, each set of ray data elements is associated with an offset value that indicates its position (position / location) within the storage group. For example, the first set (the set including the ORIGIN_X ray data element) is associated with an offset value of 0, the second set (the set including 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 storage group identifier field 902 may be set to identify the tracking storage group, the offset field 906 may be set to include the offset of the first set of ray data elements to be written (i.e., offset 13 (decimal)), and the length field 905 may be set to 3 (decimal) to indicate that 3 ray data elements will be written.

[0137] In some cases, the RSTORE instruction 900 may also include a source (SRC) field 908 that includes information identifying the 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 elements to be written are stored in contiguous storage locations (e.g., registers). In such cases, the SRC field 908 may identify the USC 104 storage 110 location (e.g., a register) where the first ray data element to be written to the external unit (e.g., RAC 112) is located.

[0138] As described above, the ray data elements of each storage group are divided into sets, and each set is associated with offset or position information. Each set may 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 specific ray data element to be written to the external unit (e.g., RAC 112). Therefore, in the presence of at least one storage group with a multi-ray data element set, the RSTORE instruction may include additional information indicating which ray data element of the set is to be written to the external unit when the set is identified. For example, if Figure 9 As shown in FIG, RSTORE instruction 900 may include a SPACE_CTRL field 910 for indicating which ray data element of the identified set of multiple ray data elements is to be written.

[0139] For example, in Figure 8 In the example storage group shown in , both the tracking storage group and the query storage group have multiple ray data element sets. Specifically, the tracking storage group includes: (i) a ray data element set including an NCM_T ray data element and a TMIN ray data element; and (ii) a ray data element set including a CM_T ray data element and a CD_T ray data element. The query storage group has seven multiple ray data element sets. In this example, when any of these multiple ray data element sets is identified (by the offset field and the length field), the SPACE_CTRL field 910 may include information indicating which ray data element of each identified multiple ray data element set is to be written.

[0140] In this example, the bits of SPACE_CTRL field 910 may be used differently depending on whether a tracking storage group or a query storage group is identified (and if a call storage group is identified, SPACE_CTRL field 910 may not be used because 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, SPACE_CTRL field 910 may include four bits, and Table 4 shows how these bits may be used to identify which specific ray data elements are to be written to the external unit when the group identifier field identifies the tracking 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.

[0141] Table 4 – Tracking Storage Groups

[0142]

[0143] As can be seen, for a tracking storage group, the two sets of multiple ray data elements 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 location, and when the bit is set to another value (e.g., '0'), the corresponding ray data element will not be written to the external location. Since TMIN and NCM_T are in the same set, they cannot be written to the external location using the same RSTORE instruction (in the case of a tracking storage group), so only one of bits 0 and 1 can be set simultaneously. Similarly, since CD_T and CM_T are in the same set, they cannot be written to the external location using the same RSTORE instruction (in the case where the storage group is a tracking storage group), so only one of bits 2 and 3 can be set at the same time.

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

[0145] Table 5 – Query Storage Groups

[0146]

[0147] As described above, the query storage group includes the set of multi-ray data elements shown in Table 6.

[0148] Table 6

[0149] gather 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

[0150] It has been determined that the following combinations of ray data elements from these sets are likely to be written together, which are reflected in Table 5.

[0151] ·NCM_INST_IN, NCM_PRIM_IN, NCM_GEOM_IN

[0152] ·CM_INST_IN, CM_PRIM_IN, CM_GEOM_IN

[0153] ·CD_T, CD_INST_IN, CD_PRIM_IN, CD_GEOM_IN

[0154] ·CM_T, CM_INST_IN, CM_PRIM_IN, CM_GEOM_IN

[0155] 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 for identifying that particular ray data element; (ii) having one bit associated with a particular multi-ray data element set comprising two ray data elements for identifying one of the ray data elements in that set; and (iii) having one or more bits associated with a plurality of multi-ray data element sets for identifying 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 sets). It will be apparent to those skilled in the art that any combination of these techniques or methods can be used to identify individual ray data elements in a multi-ray data element set. It will be apparent to those skilled 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 be used to identify ray data elements of a multi-ray data element set in any suitable manner.

[0156] exist Figure 8 In the example storage groups shown in , there are two storage groups with multiple ray data element sets. However, it will be apparent to those skilled in the art that this is merely an example, and that no storage group may have multiple ray data element sets (i.e., each data element set may include only a single ray data element), or that one, two, or more than two storage groups may include multiple ray data element sets. In addition, in Figure 8 In the example storage groups shown in , 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 skilled in the art that this is merely an example, and a storage group may include any number of multi-ray data element sets.

[0157] 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., a program) to be used to process the data. In response to receiving the shader task, the USC 104 executes the identified shader on 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, an RSTORE instruction executed as part of a shader task is said to be associated with the multiple rays associated with the shader task, and the identified ray data elements are stored in an external unit (e.g., RAC 112) for one or more of the rays associated with the RSTORE instruction.

[0158] For an RSTORE instruction 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. Therefore, in the method described below, it is determined which of a plurality of rays associated with the RSTORE instruction are active for the RSTORE instruction, and ray data elements identified in the RSTORE instruction are stored in the external unit (e.g., RAC 112) only for the active rays. However, in other examples, rather than determining which of the rays associated with the RSTORE instruction are active, it may be simpler to simply store the identified ray data elements for all of the rays associated with the RSTORE instruction.

[0159] The active rays for an RSTORE instruction may be set at the shader task level or the instruction level. Specifically, some rays may be inactive for a ray tracing shader task such that these rays will be inactive for any RSTORE instruction executed as part of that ray tracing shader task. However, different RSTORE instructions executed as part of the same ray tracing shader task may have different active rays. For example, only rays 1 and 2 associated with a ray tracing shader task may 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 may be active for a second, different RSTORE instruction executed as part of the ray tracing shader task.

[0160] Now refer to Figure 10, which illustrates an example method 1000 for 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 As described above, the RSTORE instruction identifies a predefined storage group of ray data elements (e.g. Figure 8 ) and the particular ray data elements of the storage group to be written to the external unit (e.g., RAC 112). After receiving the RSTORE instruction, 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. Method 1000 then proceeds to block 1006, where the USC 104 sends one or more storage 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 of the one or more rays associated with the RSTORE instruction.

[0161] The storage interface 120 between an 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) may 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. Therefore, the USC 104 may transfer the identified ray data elements to the external unit (e.g., RAC 112) over multiple cycles. The one or more ray data elements transferred in a cycle may be referred to as a storage 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 storage 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 simultaneously across the storage interface 120. 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 storage transaction).

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

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

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

[0165] For example, suppose Figure 8 Each of the example storage groups shown in is a per-ray storage group. Figure 8 As can be seen in Figure 2, the ray data elements of each of these storage groups have been divided into blocks, where the ray data elements in a block can form part of the same storage transaction. For example, the ray data elements of the trace 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 call storage group have been divided into five blocks (blocks 0, 1, 2, 3, and 4).

[0166] 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 up to N sets of one or more ray data elements, where each set of ray data elements includes a single ray data element or multiple mutually exclusive ray data elements, as described above. This means that a storage transaction can include ray data elements from each set associated with the block. In the example described herein, N is four (i.e., four ray data elements can be transferred as part of a single storage transaction), so Figure 8Each of the blocks shown in comprises a maximum of four sets of ray data elements.

[0167] As described above, each set of ray data elements in a storage group may be associated with an offset (or other similar information) that indicates the position of the ray data element set in the storage group. Figure 8 As shown in , a ray data element in a block is a ray data element associated with a set of contiguous offsets (e.g., N offsets). Figure 8 As shown in , the first block of each storage group may include sets 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 sets of ray data elements associated with the next four offsets (e.g., offsets 4 to 7), and so on.

[0168] Now refer to Figure 11 , which illustrates an example method 1100 that may be implemented by the USC 104 (e.g., the storage logic 126) to convert an RSTORE instruction (which identifies a per-ray storage group) into multiple storage transactions. The method 1100 begins at block 1102, where the USC 104 (e.g., the storage logic 126) initializes a current ray identifier (which may also be referred to as an instance identifier). The current ray identifier identifies one of a plurality of 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 plurality of 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, the method 1100 proceeds to block 1104.

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

[0170] At block 1106, the USC 104 (e.g., 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 may be referred to as the current block. In some cases, the current block identifier may be initialized to identify the first block of the identified storage group. In some cases, the current block identifier may take the form of a counter, and the counter may be initialized to a predetermined value (e.g., 0). Once the current block identifier has been initialized, the method 1100 proceeds to block 1110.

[0171] At block 1110, USC 104 (e.g., 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 an external location (e.g., RAC 112). In the event that the RSTORE instruction includes an offset (OFFSET) field and a length (LENGTH) field as described above, the range of the block including the at least one ray data element may be determined as to In such cases, USC 104 (e.g., storage logic 126) may be configured to determine that at least one ray data element in the current block is to be written to an external location (e.g., 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 an external location (e.g., RAC 112), 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 an external location (e.g., RAC 112), method 1100 proceeds to block 1114.

[0172] At block 1112, USC 104 (e.g., storage logic 126) generates and sends a storage transaction request to an external unit (e.g., RAC 112) to store the identified ray data element 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 associated ray data element for the current block; and (v) the identified ray data element (i.e., the data to be stored).

[0173] Now refer to Figure 12, which shows an example format of a storage transaction request 1200. The example storage 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, and 1216. The ray identifier field 1202 (which may also be referred to as the INSTANCE field) identifies the ray associated with the request and may be set to the value of the current ray identifier. The block identifier field 1204 (which may also be referred to as the ADDR field) identifies the block (of the identified storage group) associated with the request and may be set to the value of the current block identifier.

[0174] The ray data element set identifier field 1206 (which may be referred to as a MASK field when implemented as a mask) identifies the set of ray data elements in the identified block from which the ray data elements are to be stored in the external location. The ray data element set identifier field 1206 may be generated from the length information and offset information in the RSTORE instruction. For example, if the RSTORE instruction identifies Figure 8 If the tracking storage group is 0, 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 ray data elements from each of sets 2 to 7 will be stored. Therefore, for block 0, the MASK field may be set to '0011' (binary) to indicate that ray data elements from the last two sets in the block will be stored.

[0175] A storage group identifier field 1208 (which may be referred to as a SPACE field) identifies the associated storage group and may include the storage group identifier information in the RSTORE instruction. Where the RSTORE instruction includes a SPACE_CTRL field, the storage transaction request 1200 may also include a SPACE_CTRL field 1218 that 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 that in other examples, the storage transaction request may take a different form and / or have different and / or additional fields.

[0176] Data fields 1210, 1212, 1214, 1216 include ray data elements to be stored in the storage device of the external unit (e.g., 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 storage transaction request. In this example, four ray data elements can be sent as part of a single storage transaction request, so there are four data fields. The identified ray data element is placed in the data field corresponding to its position in the block. For example, if the RSTORE instruction identifies Figure 8 1214, the DIRECTION_X ray data element is placed in fourth data field 1216, and first data field 1210 and second data field 1212 may be left blank (or may contain any data as they will be ignored by external units).

[0177] Upon receiving a storage transaction request, the external unit (e.g., RAC 112) determines from the storage group, block, 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) may have a mapping between each ray data element in the group and the location of the ray data element in the storage units 114, 116.

[0178] Back to Figure 11 Once the USC 104 has sent the storage transaction request to the external unit (eg, RAC 112 ), the method 1100 proceeds to block 1114 .

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

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

[0181] At block 1108, the USC 104 (e.g., storage logic 126) determines whether the current ray is the last ray associated with the RSTORE instruction (i.e., whether all rays in the rays associated with the RSTORE instruction have been analyzed). In the event that the current ray identifier is implemented as a counter initialized to 0, the USC 104 (e.g., storage logic 126) may 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 may be 128. However, it will be apparent that this is merely an example, and in other examples, a different number of rays may be 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.

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

[0183] Examples of using the RLOAD and RSTORE instructions

[0184] Now, the USC 104 will be described as being used to Figure 2 and Figure 8The described load and store groups are example uses of the RLOAD and RSTORE instructions described herein to implement ray tracing. In some cases, ray tracing can begin with a ray generation shader. The ray generation shader may require the x and y emission IDs and x and y emission sizes of a ray to generate its x, y, and z origins. To load the required data into the USC 104, the ray generation shader may include an RLOAD instruction requesting the LAUNCH_ID_X and LAUNCH_ID_Y ray data elements from the primary load group (e.g., the load group identifier field may be set to "001" (binary) and the mask field may be set to "00000000000000110000" (binary, the lowest bit index of the rightmost position) according to Table 2); and an RLOAD instruction requesting the LAUNCH_SZ_X and LAUNCH_SZ_Y ray data elements from the launch size load group (e.g., the load group identifier field may be set to "010" (binary) and the mask field may be set to "00000000000000000111" (binary, the lowest bit index of the rightmost position) according to Table 2). The ray generation shader may then define all 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., RAC 112), the ray generation shader may include an RSTORE instruction to store all ray data elements except the third payload ray data element in the trace storage group (e.g., according to Table 3, the storage group identifier may be set to "00" (binary), the offset may be set to "0" (binary), and the length may be set to 15 (decimal), and according to Table 4, the SPACE_CTRL field may be set to "1001" (binary, the lowest bit index of the rightmost position) to indicate that the TMIN and CM_T ray data elements are to be stored). After executing the RSTORE instruction hierarchy search, the process of finding intersections (which may also be called a ray traversal) begins, and the ray generation shader is suspended.

[0185] After the hierarchical search, a miss shader may be run for rays that are considered "misses". The miss shader may require the x, y emission ray data elements and all three payload ray data elements pointing to the memory hierarchy (MH) address for each ray. To obtain this data, the miss shader may 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 may be set to "001" (binary), and the mask field may be set to "00000000000000110111" (binary, the lowest bit index of the rightmost position)). The miss shader may determine the pixel result from the emission ID and then store the pixel result for each ray at the associated MH address via different instructions.

[0186] In addition to running the miss shader, the hit shader may also be run for rays that are considered "hits". The hit shader may require data from the first two payload ray data elements, the flag ray data element, and the u ray data element and the v ray data element pointing to the MH address. To obtain this data, the hit shader may 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 may be set to "010" (binary), and the mask field may be set to "00110000011100000000" (binary, bit index of the rightmost position)). The U ray data element and the V ray data element may then be used to derive a pixel result, which may be stored to the associated MH address via different instructions.

[0187] The ray generation shader may then resume, where the ray generation shader reads per-ray results (eg, pixel results) from the MH address to manipulate the output texture.

[0188] In the examples described above, individual ray data elements in a load group can be identified in an RLOAD instruction via, for example, a mask (and optionally a SPACE_CTRL field), and contiguous blocks of ray data elements in a storage group can be identified in an 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 arises because the inventors have discovered that ray tracing shaders that generate ray data elements and therefore write them to external units (e.g., RAC 112) tend to write blocks of information into storage groups, while ray tracing shaders that process ray data elements tend to read non-contiguous subsets of load groups. Therefore, the RSTORE instruction can be simplified by using offsets and lengths as opposed to masks. This also allows for simplification of the storage logic 126. However, it will be apparent to those skilled in the art that the RLOAD method of identifying ray data elements (e.g., a mask field) can be used to identify ray data elements in an RSTORE instruction, and that the RSTORE method of identifying ray data elements (e.g., offset and length information) can be used to identify ray data elements in an RLOAD instruction.

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

[0190] Although 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 the NNA as a standalone unit. In such cases, the shader processing unit 104 can also be implemented in the NNA.

[0191] Figure 1The graphics processing unit, shader processing unit, load logic, and store logic of the graphics processing unit are shown as including multiple functional blocks. This is merely illustrative and is not intended to define a strict division between different logical elements of such entities. Each functional block may be provided in any suitable manner. It will be understood that intermediate values ​​described herein as being formed by a unit or particular logic need not be physically generated by the unit or logic at any point, and may simply represent logical values ​​that conveniently describe the processing performed by the logic or unit between its input and output.

[0192] The graphics processing unit, shader processing unit, load logic, and storage logic described herein can be embodied in hardware on an integrated circuit. The graphics processing unit, shader processing unit, load logic, and storage logic described herein can be configured to perform any of the methods described herein. Generally speaking, 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" may be used herein to generally refer to software, firmware, hardware, or any combination thereof. In the case of a software implementation, a module, functionality, component, element, unit, block, or logic represents program code that, when executed on a processor, performs a specified task. The algorithms and methods described herein can be performed by one or more processors executing code that causes the processor to perform the algorithm / method. Examples of computer-readable storage media include random access memory (RAM), read-only memory (ROM), optical disks, flash memory, hard disk storage, and other memory devices that can use magnetic, optical, and other technologies to store instructions or other data and can be accessed by a machine.

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

[0194] A processor, computer, or computer system may be any kind of device, machine, or specialized circuit, or a collection or portion thereof that has processing capabilities so that it can execute instructions. A processor may be any kind of general-purpose or specialized 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 may include one or more processors.

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

[0196] Thus, a method of manufacturing a graphics processing unit, a shader processing unit, load logic, and / or storage logic as described herein at an integrated circuit manufacturing system may be provided. Furthermore, an integrated circuit definition dataset may be provided that, when processed at an integrated circuit manufacturing system, enables the method of manufacturing a graphics processing unit, a shader processing unit, load logic, and / or storage logic to be performed.

[0197] The integrated circuit definition data set may be in the form of computer code, for example, as a netlist, code for configuring a programmable chip, as a hardware description language that defines hardware suitable for fabrication at any level in the integrated circuit, 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). Higher-level representations that logically define hardware suitable for fabrication in the integrated circuit (such as RTL) may be processed at a computer system configured to generate a manufacturing definition of the integrated circuit in the context of a software environment that includes definitions of circuit elements and rules for combining these elements to generate a manufacturing definition of the integrated circuit so defined by the representation. As is typically the case when software is executed at a computer system to define a machine, one or more intermediate user steps (e.g., providing commands, variables, etc.) may be required to configure the computer system to generate a manufacturing definition of the integrated circuit in order to execute the code that defines the integrated circuit in order to generate the manufacturing definition of the integrated circuit.

[0198] Now it will target Figure 14 An example of processing an integrated circuit definition dataset at an integrated circuit manufacturing system to configure the system to manufacture a shader processing unit or a graphics processing unit is described.

[0199] Figure 14 An example of an integrated circuit (IC) manufacturing system 1402 is shown that is configured to manufacture graphics processing units, shader processing units, load logic, and / or storage logic as described in any of the examples herein. Specifically, the IC manufacturing system 1402 includes a layout processing system 1404 and an integrated circuit generation system 1406. The IC manufacturing system 1402 is configured to receive an IC definition dataset (e.g., defining a graphics processing unit, shader processing unit, load logic, and / or storage logic as described in any of the examples herein), process the IC definition dataset, and generate an IC (e.g., which embodies a graphics processing unit, shader processing unit, load logic, and / or storage logic as described in any of the examples herein) based on the IC definition dataset. Processing of the IC definition dataset configures the IC manufacturing system 1402 to manufacture an integrated circuit that embodies a graphics processing unit, shader processing unit, load logic, and / or storage logic as described in any of the examples herein.

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

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

[0202] The different processes performed by IC manufacturing system 1402 can all be implemented in a single location, e.g., by one party. Alternatively, IC manufacturing system 1402 can be a distributed system such that some of the processes can be performed at different locations and 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 an IC definition data set to form a gate-level representation of a circuit to be generated; (ii) generating a circuit layout based on the gate-level representation; (iii) generating a mask based on the circuit layout; and (iv) using the mask to manufacture the integrated circuit.

[0203] In other examples, processing of an integrated circuit definition data set at an integrated circuit manufacturing system may configure the system to manufacture a graphics processing unit, a shader processing unit, load logic, and / or storage logic without processing the IC definition data set to determine a circuit layout. For example, an integrated circuit definition data set may define a configuration of a reconfigurable processor (such as an FPGA), and processing of the data set may configure the IC manufacturing system to generate a reconfigurable processor having the defined configuration (e.g., by loading the configuration data into the FPGA).

[0204] In some embodiments, when processed in an integrated circuit manufacturing system, the integrated circuit manufacturing definition data set can cause the integrated circuit manufacturing system to generate a device as described herein. Figure 14 An integrated circuit manufacturing system can be configured in the manner described to manufacture the device described herein.

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

[0206] Compared to known implementations, the implementation of the concepts set forth in this application in devices, equipment, modules and / or systems (and in the methods implemented herein) can result in performance improvements. Performance improvements can include one or more of improved computing performance, reduced latency, increased throughput and / or reduced power consumption. During the manufacture of such devices, devices, modules and systems (e.g., in integrated circuits), a trade-off can be made between performance improvement and physical implementation, thereby improving the manufacturing method. For example, a trade-off can be made between performance improvement and layout area, thereby matching the performance of known embodiments, but using less silicon. For example, this can be accomplished by reusing functional blocks in a serial manner or sharing functional blocks between elements of a device, device, module and / or system. In contrast, the concepts of improvements (such as silicon area reduction) that bring about physical implementations of devices, devices, modules and systems set forth in this application can be weighed against performance improvement. This can be accomplished, for example, by manufacturing multiple instances of a module within a predefined area budget.

[0207] Applicants hereby independently disclose each individual feature described herein, as well as any combination of two or more such features, to the extent that such feature or combination can be implemented according to the common general knowledge of a person skilled in the art based on the present specification as a whole, regardless of whether such feature or combination of features solves any problem disclosed herein. In view of the foregoing description, it will be clear to those skilled in the art that various modifications can be made within the scope of the present invention.

Claims

1. A shader processing unit (104) for a graphics processing unit (100), the shader processing unit (104) being configured to execute one or more shaders, the one or more shaders including one or more ray tracing shaders processing ray data associated with one or more rays, the ray data for the rays including a plurality of ray data elements, the shader processing unit (104) comprising: a storage device (110); as well as Loading logic (124) configured to: receiving a ray load instruction (300), the ray load instruction comprising: (i) information (302) identifying a load group of a plurality of load groups, each load group of the plurality of load groups comprising one or more ray data elements of the plurality of ray data elements, and (ii) information (304, 308) identifying one or more ray data elements of the identified load group to be retrieved from an external unit (112); In response to receiving the ray load instruction (300), sending one or more load requests to the external unit (112), the one or more load requests causing the external unit (112) to retrieve the identified ray data elements of the identified load group for one or more rays; receiving, from the external unit (112), the identified ray data elements for the one or more rays; and The received ray data elements are stored in the storage device (110) for processing by a ray tracing shader of the one or more ray tracing shaders.

2. The shader processing unit (104) of claim 1, wherein the information (304, 308) identifying one or more ray data elements of the identified load group identifies individual ray data elements of the identified load group.

3. The shader processing unit (104) of claim 1 , wherein the one or more ray data elements of each load group are divided into one or more ray data element sets, and the information (304, 308) identifying the one or more ray data elements of the identified load group includes information (304) identifying one or more ray data element sets of the one or more ray data element sets of the identified load group.

4. The shader processing unit (104) of claim 3, wherein the information (304, 308) identifying the one or more ray data elements of the identified load group comprises a mask (304), the mask comprising a bit for each of the one or more ray data element sets, the bit that, when set to a value, identifies the associated ray data element set.

5. The shader processing unit (104) of claim 3 , wherein when at least one of the identified ray data element sets includes two or more ray data elements, for each ray data element set in the at least one of the identified ray data element sets that includes two or more ray data elements, the information (304, 308) identifying one or more ray data elements of the identified load group further includes information (308) identifying one ray data element of the ray data element set.

6. The shader processing unit (104) of any one of claims 1 to 5, wherein: receiving the identified ray data elements of one or more rays from the external unit (112) in a plurality of load transactions, each load transaction including up to a predetermined maximum number of ray data elements; The load logic (124) is further configured to divide the identified ray data elements of the one or more rays into the plurality of load transactions; as well as The one or more load requests sent from the load logic (124) to the external unit (112) include a load transaction request (600) for each load transaction in the plurality of load transactions.

7. The shader processing unit (104) of claim 6, wherein when the identified load group is of the first type, each load transaction includes ray data elements associated with a same ray of the one or more rays.

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

9. The shader processing unit (104) of claim 8, wherein: The one or more ray data elements of each load group are divided into one or more ray data element sets, and the information (304, 308) identifying the one or more ray data elements of the identified load group includes information (304) identifying one or more ray data element sets of the one or more ray data element sets of the identified load group; and Each ray data element block for a load group includes one or more ray data element sets of the one or more ray data element sets of the load group.

10. The shader processing unit (104) of claim 9, wherein: the information (304, 308) identifying the one or more ray data elements of the identified load group comprises a mask (304) comprising, for each of the one or more ray data element sets, a bit that, when set to a value, identifies the associated ray data element set; and Each block of ray data elements for a load group includes a set of ray data elements of the load group associated with a contiguous block of mask bits.

11. The shader processing unit (104) of claim 9, wherein when the identified load group is of the first type, each load transaction request (600) includes information (608) identifying the load group identified in the ray load instruction, information (604) identifying a block of the load group, information (606) identifying the ray data elements identified in the ray load instruction of the block, and information (602) identifying a ray in the one or more rays.

12. The shader processing unit (104) of claim 7 , wherein the load logic (124) is configured to, when the identified load group is of the first type, divide the identified ray data elements of the one or more rays into the plurality of load transactions by, for each ray of the one or more rays, determining whether each block of ray data elements includes the identified ray data element, and for each block of ray data elements that includes the identified ray data element, generating a load transaction request to retrieve the identified ray data element in the block for the ray.

13. The shader processing unit (104) of claim 7, wherein when the identified load group is of the second type, each load transaction in the plurality of load transactions includes a same ray data element for one or more rays.

14. The shader processing unit (104) of claim 13 , wherein the ray load instruction (300) is associated with a plurality of rays divided into one or more ray blocks, and when the identified load group is of the second type, each load transaction includes the same ray data element for one or more rays in the same ray block.

15. The shader processing unit (104) of claim 14, wherein the load logic (124) is configured to, when the identified load group is of the second type, divide the identified ray data elements of the one or more rays into the plurality of load transactions by: for each ray data element in the identified ray data elements, determining which ray block includes active rays, and for each ray block that includes active rays, generating a load transaction request to retrieve the ray data elements for the active rays in the ray block.

16. The shader processing unit (104) of any one of claims 1 to 5, wherein the ray load instruction (300) is associated with a plurality of rays, and the one or more rays for which the identified ray data element is requested are active rays of the plurality of rays.

17. The shader processing unit (104) of any one of claims 1 to 5, further comprising storage logic (126) configured to: A light storage instruction (900) is received, wherein the light storage instruction includes: (i) information (902) 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 (906, 904, 910) identifying the one or more ray data elements of the identified storage group to be stored in the external unit (112); in response to receiving the ray storage instruction, retrieving the identified ray data elements for one or more rays from the storage device (110); as well as One or more storage requests are sent to the external unit (112), the one or more storage requests causing the external unit (112) to store the identified ray data elements of the identified storage group for the one or more rays.

18. A method (400) of processing a ray tracing shader, the ray tracing shader processing ray data associated with one or more rays at a shader processing unit of a graphics processing unit, the shader processing unit being configured to execute one or more shaders, the one or more shaders including the ray tracing shader, the ray data for the rays including a plurality of ray data elements, the method (400) comprising: receiving (402) a ray load instruction at the shader processing unit, the ray load instruction comprising: (i) information identifying a load group of a plurality of load groups, each load group of the plurality of load 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 load group to be retrieved from an external unit; In response to receiving the ray load instruction, sending (404) one or more load requests from the shader processing unit to the external unit, the one or more load requests causing the external unit to retrieve the identified ray data elements of the identified load group for one or more rays; receiving (406) at the shader processing unit from the external unit the identified ray data elements for the one or more rays; and The received ray data elements are stored (408) in a storage device of the shader processing unit for processing by the ray tracing shader.

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

20. A computer-readable storage medium having an integrated circuit definition dataset stored therein, which, when processed in an integrated circuit manufacturing system, configures the integrated circuit manufacturing system to manufacture the shader processing unit (104) of any one of claims 1 to 5.

Images