HK40040381A - Techniques for displaying a shader table associated with raytracing images - Google Patents

Description

Techniques for displaying shader tables associated with ray traced images

Background

Today, the use of computing devices is becoming more and more common. Computing devices range from standard desktop computers to wearable computing technologies, and the like. One area of computing devices that has grown in recent years is in the context of image rendering, such as the rendering of games, video streams, etc., which typically rely on a Graphics Processing Unit (GPU) to render graphics from a computing device to a display device based on rendering instructions received from the computing device. Ray tracing (raytracing) of images is being developed as another solution to generate images via applications and request display of images via GPUs. In ray tracing, an application may define an image to be displayed and may define an acceleration structure to facilitate efficient generation of images on a display.

The acceleration structure is used to quickly determine which objects a particular ray may intersect in the scene and to reject one or more objects that the ray will not strike. The determined object may be drawn on the display based on information about the rays that intersect the object. Further, in ray tracing, an application may define a shader table that specifies shaders to be invoked when a ray intersects or otherwise interacts with other objects in a ray tracing scene. When a ray intersects or interacts with other objects in a ray traced scene, the GPU may draw objects of the scene based on the ray and may invoke the appropriate shader based on the shader table.

Disclosure of Invention

The following presents a simplified summary of one or more examples in order to provide a basic understanding of such examples. This summary is not an extensive overview of all contemplated examples, and is intended to neither identify key or critical elements of all examples nor delineate the scope of any or all examples. Its sole purpose is to present some concepts of one or more examples in a simplified form as a prelude to the more detailed description that is presented later.

In one example, a computer-implemented method for displaying shader table information used in ray tracing an image is provided. The method includes intercepting, from a Graphics Processing Unit (GPU) or a graphics driver, a buffer specifying one or more shader records of a shader table to be used when generating an image using ray tracing, determining, by a computing device, a layout of the one or more shader records based at least in part on identifiers of the one or more shader records, interpreting, by the computing device, additional data in the buffer based at least in part on the layout to determine one or more parameters corresponding to the one or more shader records, and displaying, via an application executing on the computing device, an indication of the one or more parameters on an interface.

In another example, a computing device for displaying shader table information used in ray tracing an image is provided. The computing device includes: a memory storing one or more parameters or instructions for executing an operating system and one or more applications including a diagnostic application; and at least one processor coupled to the memory. The at least one processor is configured to intercept, from a GPU or a graphics driver, a buffer specifying one or more shader records of a shader table to be used in generating an image using ray tracing, determine a layout of the one or more shader records based at least in part on identifiers of the one or more shader records, interpret additional data in the buffer based at least in part on the layout to determine one or more parameters corresponding to the one or more shader records, and display, via a diagnostic application, an indication of the one or more parameters on an interface.

In another example, a computer-readable medium is provided that includes code executable by one or more processors to display shader table information used in ray tracing an image. The code includes code for: the method includes intercepting, from a GPU or a graphics driver, a buffer specifying one or more shader records of a shader table to be used in generating an image using ray tracing, determining a layout of the one or more shader records based at least in part on identifiers of the one or more shader records, interpreting additional data in the buffer based at least in part on the layout to determine one or more parameters corresponding to the one or more shader records, and displaying, via an application, an indication of the one or more parameters on an interface.

To the accomplishment of the foregoing and related ends, the one or more examples comprise the features hereinafter fully described and particularly pointed out in the claims. The following description and the annexed drawings set forth in detail certain illustrative features of the one or more examples. These features are indicative, however, of but a few of the various ways in which the principles of various examples may be employed and the description is intended to include all such examples and their equivalents.

Drawings

Fig. 1 is a schematic diagram of an example of a computing device for determining and displaying shader table information for an image that may be raytraced by a Graphics Processing Unit (GPU) according to examples described herein.

Fig. 2 is a flow diagram of an example of a method for determining and displaying shader table information according to examples described herein.

Fig. 3 illustrates an example of a data flow for intercepting image data to determine and display shader table information according to examples described herein.

Fig. 4 illustrates an example of an interface for displaying shader table information according to examples described herein.

Fig. 5 illustrates an example of an interface for displaying an error indication of a root argument in shader table information according to examples described herein.

Fig. 6 illustrates an example of an interface for displaying an error indication of a shader record in shader table information according to examples described herein.

Fig. 7 illustrates an example of an interface for displaying an error indication of root signature association in shader table information according to examples described herein.

Fig. 8 is a schematic diagram of an example of a computing device for performing the functions described herein.

Detailed Description

The detailed description set forth below in connection with the appended drawings is intended as a description of various configurations and is not intended to represent the only configurations in which the concepts described herein may be practiced. The detailed description includes specific details for the purpose of providing a thorough understanding of the various concepts. It will be apparent, however, to one skilled in the art that these concepts may be practiced without these specific details. In some instances, well-known components are shown in block diagram form in order to avoid obscuring such concepts.

Described herein are various examples related to displaying parameters related to shader tables defined in a ray traced image. The shader table may specify which shader to invoke when a ray interacts with something in the ray tracing scene. For example, a shader table may include an array of shader records, where each record includes an identifier of a shader and a set of parameters that are passed to the shader when invoked. When a scene is raytraced and a ray encounters a surface, the shader table can be indexed to select the shader to execute (as well as the input parameters provided by the ray, object, and shader records). Shader tables are typically stored and/or communicated in sets of bytes and may not be intuitive. In this regard, based on performing corresponding ray tracing of the image (e.g., as opposed to displaying or otherwise obtaining only the raw bytes of the shader table), buffer data corresponding to the shader table may be intercepted and interpreted to provide for display of the data in a more intuitive format. For example, data from various buffers may be intercepted to determine shader records being used, parameters related to shader records, and so forth, and the parameters may be displayed to allow developers to visualize the parameters when ray tracing an image and thus identify possible errors in ray tracing.

In a particular example, a buffer representing at least a portion of a shader table can be intercepted (e.g., from a Graphics Processing Unit (GPU)). The buffer can include data indicating one or more shader records based on a shader record identifier, and corresponding data following the identifier. For example, the data in the buffer may indicate one or more shader records that are used at some point during the ray tracing image. In this example, the buffer or another buffer may indicate an association between the shader record identifier and the root signature or other construct. Further, in this example, the buffer or another buffer may indicate an association between the root signature and the data layout of the shader records. Thus, shader records may be interpreted to determine one or more relevant parameters, and data may be displayed in a format that indicates the one or more relevant parameters for a given shader record, and the data may represent the shader records at some point during ray tracing. In one example, the buffer may also indicate a span (stride) value between shader records to allow for the determination of where each shader record begins in the buffer.

Additionally, in one example, possible errors in shader records may be detected and identified to allow developers to visualize possible errors and/or correct instructions causing the errors. For example, an error may be detected in the event that an expected value cannot be determined from the buffer and/or in the event that the buffer data is otherwise determined to be at least partially corrupted. Thus, the concepts described herein are used to display information of shader tables and/or corresponding shader records that may otherwise be difficult to interpret, to allow developers to quickly and efficiently identify possible errors in ray tracing and/or to apply corresponding shaders to certain rays when performing ray tracing.

1-8, examples are depicted with reference to one or more components and one or more methods that may perform the actions or operations described herein, where the components and/or actions/operations in dashed lines may be optional. Although the operations described below in fig. 2 are presented in a particular order and/or performed by example components, in some examples, the order of the actions and the components performing the actions may be varied depending on the implementation. Further, in some examples, one or more of the following acts, functions and/or described components may be performed by a specially programmed processor, a processor executing specially programmed software or computer readable media, or by any other combination of hardware components and/or software components capable of performing the described acts or functions.

FIG. 1 is a schematic diagram of an example of a computing device 100 and/or related components for determining and displaying shader table information for an image drawn using a GPU. For example, computing device 100 may include processor 104 and/or memory 106, or may be otherwise coupled with processor 104 and/or memory 106, where processor 104 and/or memory 106 may be configured to execute or store instructions or other parameters related to determining or displaying shader table information, as described herein. The computing device 100 may execute an operating system 108 (e.g., via the processor 104 and/or memory 106) to provide an environment for executing one or more applications. Computing device 100 may also include a GPU114, the GPU114 for processing drawing instructions and/or communicating associated commands to a display interface 116 to cause display of one or more images on a display, which may be coupled to the computing device 100 via a display port 118.

In one example, the display interface 116 may be communicatively coupled with the processor 104 and/or the memory 106 to communicate with a display (not shown) via a display port 118. The displayport 118 as referred to herein may include one or more of various types of ports, including a High Definition Multimedia Interface (HDMI) port, a displayserial interface (DSI) port, a Mobile Industry Processor Interface (MIPI) DSI port, a Universal Serial Bus (USB) port, a firewire port, or other embedded or external wired or wireless displayport, which may enable communication between the computing device 100 and a display.

In one example, GPU114 may be part of display interface 116 (e.g., a processor on a circuit board of display interface 116). In another example, the GPU114, the display interface 116, and the like, may be integrated with the processor 104. Substantially any combination of hardware is possible such that the GPU114, display interface 116, etc., may communicate with the processor 104 via a bus to facilitate providing the drawn instructions to the GPU 114. The GPU114 may process the draw instructions to draw an image and may initiate display of at least a portion of the image on the display by transmitting an associated signal to the display via a display port 118 of the display interface 116.

In one example, the GPU114 may support ray tracing and, thus, may include a ray tracing component 120, the ray tracing component 120 operable to receive a proprietary structure 134 that may be generated by the graphics driver 122 and perform ray tracing based on the proprietary structure 134 to draw graphics via the display interface 116. The graphics driver 122 may be specific to the manufacturer of the GPU114 and/or provided by the manufacturer of the GPU114 to generate a proprietary structure 134 to instruct the ray tracing component 120 to perform ray tracing to display an image.

In one example, the application 124 may operate (e.g., via the operating system 108) to generate images for display via the display interface 116. The application 124 may generate an acceleration structure 130, which acceleration structure 130 may define geometry data (geometry) for the image related to ray tracing, which may include information about one or more objects in the image, locations corresponding to the one or more objects in the image, and so on, such that a GPU with ray tracing capabilities (e.g., GPU 114) may simulate photons emitted via rays, determine where the light is reflected, trace points where rays return from the scene, and so on to generate the image. In one example, the application 124 may generate the acceleration structure 130 in a standardized format that may be provided to the graphics driver 122. The graphics driver 122 may generate a proprietary structure 134 based on the acceleration structure 130 to optimize the acceleration structure 130 for ray tracing on the GPU114, where the proprietary structure 134 may be in a proprietary format, may include efficiencies, etc. that are known to the graphics driver 122 but not necessarily known to the application 124, the diagnostic application 126, etc.

In one example, the GPU114 may optionally include a shader invocation component 136 for invoking shaders in ray tracing. For example, shader invocation component 136 may invoke a shader based on one or more detected events associated with the shader (e.g., as defined by application 124), such as detecting that a ray interacted with something in a ray tracing scene. For example, based on detecting a ray interacting with a structure in a ray tracing scene, a shader table 160 may be defined (e.g., by application 124) that specifies parameters related to a shader for execution. In one example, the application-defined shader table 160 may be a byte array stored in GPU memory (e.g., a portion of memory 106 allocated to GPU114, memory physically on or near GPU114, where GPU114 is independent of processor 104, etc.) that is used by a runtime (e.g., operating system 108) and/or driver (e.g., graphics driver 122) to determine which shader to invoke when a ray interacts with something in a ray tracing scenario. Shader table 160 can also specify which resources (e.g., buffers, textures, etc.) are to be bound to or otherwise associated with each shader.

The operating system 108 may also include a diagnostic application 126, the diagnostic application 126 for determining and displaying certain diagnostic information related to the ray traced image, which may allow a developer to view and analyze parameters, memory states, etc. as the image is ray traced. For example, the diagnostic application 126 may determine and display shader table information related to shaders invoked during ray tracing, and may do so when shaders are invoked and/or utilized during ray tracing. For example, the diagnostic application 126 may include an intercept component 138, the intercept component 138 for intercepting data related to shaders that the GPU114 initializes or uses when performing ray tracing, which may include invoking intercept data from an Application Programming Interface (API) from the GPU114 to obtain data related to shader tables 160 of the shaders being invoked, intercepting data from the processor 104 to provide shader information to the GPU114, and so forth. For example, the diagnostic application 126 may be executed while the application 124 is executing and rendering images via ray tracing, and/or may allow the application 124 to be paused to analyze ray tracing data at a desired time. In this regard, the diagnostic application 126 can further include an interpretation component 140 and/or a display component 142, the interpretation component 140 for interpreting the intercepted data as additional shader table information associated with the intercepted data, and the display component 142 for displaying or otherwise drawing the shader table information via the interface.

For example, shader table information may be displayed via display interface 116. In one example, the diagnostic applications 126 may execute on the same computing device 100, or may execute as diagnostic applications 156 running on different computing devices 150 (where the different computing devices 150 may have separate processors, memories, operating systems, etc., to execute the diagnostic applications 156), so long as the diagnostic applications 126, 156 may communicate with at least the GPU114 (or related components) to determine and/or receive shader table information, related buffers, etc., as described herein. In displaying shader table information, the diagnostic applications 126, 156 may provide some other context to allow interaction with the shader table information, more simplified identification of possible errors represented in the shader table information, and so forth.

FIG. 2 is a flow diagram of an example of a method 200 for determining and displaying shader table information related to shaders invoked by a GPU when tracing or otherwise drawing an image. For example, the method 200 may be performed by the computing device 100, and thus is described with reference to FIG. 1, as a non-limiting example of an environment for performing the method 200.

In method 200, at act 202, a buffer specifying one or more shader records of a shader table to be used in generating an image using ray tracing may be intercepted from a GPU or graphics driver. In one example, an intercept component 138 (e.g., in conjunction with the processor 104, memory 106, diagnostic application 126, 156, etc.) may intercept a buffer from the GPU114 or graphics driver 122 (e.g., or communications therebetween) that specifies one or more shader records of a shader table to be used in generating an image using ray tracing. For example, the intercept component 138 may intercept a buffer from the shader call component 136 that calls a shader to execute (e.g., when a ray interacts with another object in a ray tracing scene). For example, the intercept component 138 may intercept a buffer in an API call for calling a shader by fetching a portion of the memory 106 based on detecting a shader call or the like, where the API call may be received from the GPU 114.

In one example, the buffer may include a byte array having data related to a plurality of shader records in a shader table. Each shader record can start from a memory location represented by a span (e.g., number of bytes) in the buffer, and/or the initial shader record can start from a known memory location (e.g., the start of the buffer, a known offset from the start of the buffer, etc.). In one example, the span may be indicated in a buffer or in another intercepted or received information. In one example, the intercept component 138 can intercept span information when a shader or shader table is initialized as part of intercepting or otherwise receiving (e.g., via API calls to/from the GPU 114) shader table information. In another example, the intercept component 138 can determine span information from the intercepted buffer (e.g., which can be indicated in the first n bytes or other known location in the buffer, etc.). In addition, each shader record within the buffer may include a shader identifier in a known portion of bytes (e.g., the first n bytes of the shader record or other known location). In this regard, given a span and identifier length, shader records and corresponding identifiers can be determined from the buffer and used to obtain additional shader record information, as further described herein.

In method 200, at act 204, a layout of one or more shader records may be determined based at least in part on identifiers of the one or more shader records. In one example, interpretation component 140 (e.g., in conjunction with processor 104, memory 106, diagnostic application 126, 156, etc.) can determine a layout of one or more shader records based at least in part on identifiers of the one or more shader records. For example, the interpretation component 140 may also receive an indication of a relationship between a given shader record and a value associated with the layout of the shader record.

In one example, determining the layout at act 204 may optionally include identifying the layout in the prior buffer as being associated with the root signature of the one or more shader records at act 206. In one example, the interpretation component 140 (e.g., in conjunction with the processor 104, memory 106, diagnostic applications 126, 156, etc.) can identify the layout in the prior buffer as being associated with the root signature of one or more shader records. For example, interpretation component 140 may receive the prior buffer based on application 124 initializing shaders corresponding to one or more shader records, based on application 124 providing shader information corresponding to one or more shader records to GPU114 (e.g., by intercepting or otherwise receiving shader information from application 124 and/or GPU114, such as once GPU114 receives and builds shader and/or corresponding shader tables), and so forth. For example, the interpretation component 140 can determine a list of root signatures and corresponding layouts of shader records based on data in prior buffers. For example, a root signature may define a parameter layout whose concept is similar to a functional signature in a general programming language. For example, in the case of ray tracing, the root signature may be used to define the parameter layout of the shaders within the shader record. For example, a prior buffer may be received as part of initializing a shader or shader table.

Additionally, in this example, interpretation component 140 can determine a root signature associated with the identifier of the shader record, which can be based on additional data in the buffer (e.g., data in the shader record that follows the shader identifier). In another example, interpretation component 140 may receive an indication of a layout from application 124, GPU114, or the like, where the layout may indicate, for a given root signature, fields defined for shader records having the root signature. The interpretation component 140 can then match the root signature of a given received shader record with the appropriate layout. For example, the layout may define other fields (e.g., field names, byte lengths, etc.) in the shader record data to facilitate interpretation of the data.

In method 200, at act 208, additional data in the buffer may be interpreted based at least in part on the layout to determine one or more parameters corresponding to the one or more shader records. In one example, interpretation component 140 (e.g., in conjunction with processor 104, memory 106, diagnostic application 126, 156, etc.) can interpret the additional data in the buffer based at least in part on the layout to determine one or more parameters corresponding to the one or more shader records. For example, the interpretation component 140 can determine a layout associated with the root signature as described above, and can accordingly determine one or more relevant parameters, such as a root constant, root descriptor, or root descriptor handle, based on the layout. For example, the layout can indicate a number of bytes for each parameter, and the interpretation component 140 can read the parameter values after an initial byte corresponding to the identifier, root signature, and the like.

In method 200, at act 210, an indication of one or more parameters may be displayed on an interface via an application. In one example, the display component 142 (e.g., in conjunction with the processor 104, memory 106, diagnostic applications 126, 156, etc.) may display an indication of one or more parameters on an interface via an application (e.g., diagnostic application 126, 156). Other depictions may also be possible, such as audio rendering, virtual reality display, and the like. Further, examples of possible interfaces are depicted and described herein. In one example, a table of shader records in the buffer data may be displayed. In another example, detected potential errors may also be indicated on the interface. Additionally, the method may continue to act 204 to determine, interpret, and display other shader records in the buffer data (e.g., based on subsequent shader records that advance the pointer to a subsequent memory location based on the stride value).

In another example, at act 212, links to additional parameters may be displayed. In one example, the display component 142 (e.g., in conjunction with the processor 104, memory 106, diagnostic applications 126, 156, etc.) may display links to additional parameters, which may include displaying parameter values as links. For example, the link may indicate an offset in a data buffer corresponding to a given shader record, and activating the link may cause display of the actual bytes of data in the buffer corresponding to the shader record. In another example, the link may indicate a root structure, and activating the link may cause display of a parameter (such as a layout) related to the root structure itself.

In method 200, optionally, at act 214, a potential error may be detected in one or more parameters. In one example, the interpretation component 140 (e.g., in conjunction with the processor 104, memory 106, diagnostic applications 126, 156, etc.) may detect potential errors in one or more parameters. For example, the interpretation component 140 can detect invalid memory locations represented by data in a buffer, empty values in a buffer, partial corrupt records that detect values in a buffer other than expected values at one or more locations, and the like. In this example, display component 142 may display an indication of a potential error to alert a developer. For example, detecting a potential error may include detecting a value in one or more parameters that is not within a memory location boundary, detecting a null value (e.g., a null value of a root signature), detecting an invalid value (e.g., an invalid value of a root signature, such as where the invalid value is not indicated in a mapping of the root signature to a layout), and so forth.

In other examples, displaying the indication of the one or more parameters may also include mapping the parameter values to other values indicated by the application 124 (e.g., in intercepted API calls). For example, the interception component 138 can intercept an API call that associates a root signature with a tag. In this example, while interpreting the data, interpretation component 140 can determine a tag associated with the root signature, and display component 142 can display the tag instead of (or in addition to) the root signature while displaying the shader recorded data.

Fig. 3 shows an example of a data flow 300 from image geometry data 302 created by an application (e.g., application 124) to image data of a depicted scene 310. In this example, an application, such as application 124, may generate image geometry data 302 to be drawn on a display. The application 124 may combine the image geometry data 302 with the context information 304 to construct the acceleration structure 130 representing the image geometry data 302. For example, the context information 304 may include a location of an object within an image, a color of an object within an image, one or more shaders used to generate an image, and so on. In any case, the application 124 may build the acceleration structure 130, which may include calling an API or other mechanism to generate the standardized acceleration structure 130. In one example, if the acceleration structure 130 is generated to include a bounding box, one or more shader tables 160 may also be created or otherwise determined or employed to define certain parameters of the image, such as object shape/orientation, shading parameters, intersection points, and the like, as described above.

The acceleration structure 130 may be used to generate a proprietary structure 134 (e.g., via a graphics driver) for instructing the GPU to ray trace the image of the rendered scene 310. For example, the proprietary fabric 134 may be used to schedule rays to a GPU (e.g., GPU 114) to perform ray tracing to generate the depicted scene 310. In another example, a shader table 160 may also be provided to invoke a shader to generate the drawn scene 310 based on the proprietary structure 134. Additionally, for example, the shader table 160 and/or related information, calls, parameters, etc. may be intercepted by the diagnostic applications 126, 156, such as being received via API calls to/from the GPU114, application 124, etc. As described above, the diagnostic applications 126, 156 may interpret this information to determine parameters related to shader tables, corresponding shader records, and the like, which may be displayed for diagnostic purposes while the image is being raytraced, as described above. Further, as described above, application 124 may provide image geometry data 302, and diagnostic application 126 may allow pausing application 124 or a corresponding ray trace to step through ray traces to analyze shader table 160 at a given time.

FIG. 4 illustrates an example of an interface 400 for displaying shader records interpreted according to intercepted shader table buffer data, as described herein. For example, interface 400 may display shader table information for a shader invoked at the time the image is traced. In one example, the diagnostic applications 126, 156 may execute when performing ray tracing and may display an interface such as the interface 400 or other interfaces described below when ray tracing occurs. In one example, the diagnostic applications 126, 156 may include a pause function to pause ray tracing to allow shader table data to be examined, and/or may log shader table data for subsequent viewing, and so forth.

For example, interface 400 may display shader record identifiers 402, root signatures 404, root argument values or constants 406, offsets 408, etc. of corresponding shader records, as described by diagnostic application 126 via its various subcomponents, as described above. Additionally, for example, as described above, the root signature 404 may be a link that causes display of information about the root signature. Additionally, offset 408 can be a link that causes data in the buffer to be displayed at a specified offset. In this example, the interface 400 may present a user-friendly display of the shader table 160 to help developers understand how the runtime/driver interprets its base bytes. In this regard, the diagnostic applications 126, 156 employ additional context provided by the application 124 at capture, such as span/size parameters, root signatures, and capture-time shader identifier mappings related to the shader table 160 to show how the runtime/driver interprets each byte of the shader table. This may enable developers to easily diagnose problems in their shader tables. Further, it may enable the diagnostic applications 126, 156 to display automatic alerts that may notify developers of potential problems with their shader tables, such as invalidating shader identifiers or null descriptor handles, as further described and illustrated herein.

Additionally, although shown and described with respect to shader table 160, the concepts described herein may be used with other data that helps GPU114 understand how to ray trace or otherwise draw a scene. One such example may be data used by GPU114 when performing "indirection drawing" (also known as "ExecuteIndrect"). This may involve an "argument buffer" in GPU memory whose contents specify the draw commands that GPU114 should execute and the parameters used. For example, the concepts described herein for viewing shader tables can be applied to visualize the contents of an indirect argument buffer. In these examples, as well as other examples to which these techniques may be applied, the diagnostic applications 126, 156 may similarly interpret and provide representations of data (e.g., as a list of records).

FIG. 5 illustrates an example of an interface 500 for displaying shader records interpreted according to intercepted shader table buffer data, as well as possible error indications, as described herein. For example, interface 500 may display icon 502 indicating the error byte of parameter 1 at bytes 24 through 31. For example, the diagnostic application 126, 156 may have expected that this is a pointer to a resource in the GPU memory corresponding to the root CBV, but may have detected that the byte in the buffer dataset corresponding to the parameter (e.g., by the interpretation component 140, as described above) is invalid (e.g., outside of the range of memory locations for the parameter, etc.). Interpretation component 140 may detect the potential error and display component 142 may display indicator icon 502 at the corresponding root argument value.

FIG. 6 illustrates an example of an interface 600 for displaying shader records interpreted according to intercepted shader table buffer data, as well as possible error indications, as described herein. For example, interface 600 may display an icon 602, which icon 602 indicates that the last four shader records in the table have no data. For example, this may be intentional (e.g., if the developer knows they will not use these shader records at runtime), but it may be an error. Interpretation component 140 can detect the potential error as empty data in the table of expected records (e.g., based on multiple records and/or span values), and display component 142 can display indicator icon(s) 602 at the corresponding record layout.

FIG. 7 illustrates an example of an interface 700 for displaying shader records and possible error indications interpreted according to intercepted shader table buffer data, as described herein. For example, interface 700 may display icon 702, which icon 702 indicates that the developer has not associated a root signature with a shader record. Interpretation component 140 can detect the potential error (e.g., based on detecting a shader record but failing to determine a root signature (or determining a null value for the root signature)), and display component 142 can display indicator icon 702 at the corresponding root signature.

FIG. 8 shows an example of a computing device 100 that includes additional optional component details as shown in FIG. 1. In one example, computing device 100 may include a processor 104 to perform processing functions associated with one or more components and functions described herein. The processor 104 may include a single or multiple sets of processors or multi-core processors. Further, the processor 104 may be implemented as an integrated processing system and/or a distributed processing system.

The computing device 100 may also include memory 106, such as for storing local versions of applications, related instructions, parameters, and the like, that are executed by the processor 104. Memory 106 may include computer usable memory types such as Random Access Memory (RAM), Read Only Memory (ROM), magnetic tape, magnetic disk, optical disk, volatile memory, non-volatile memory, and any combination thereof. Additionally, the processor 104 and memory 106 may include and execute an operating system executing on the processor 104, one or more applications (such as a graphics driver 122, a diagnostic application 126 and/or components thereof, a display driver, and/or the like, as described herein), and/or other components of the computing device 100.

Further, computing device 100 can include a communications component 802 for utilizing the hardware, software, and services described herein to provide for establishing and maintaining communications with one or more other devices, parties, entities, and the like. The communication component 802 can communicate between components on the computing device 100 and between the computing device 100 and external devices, such as devices located on a communication network and/or devices connected serially or locally to the computing device 100. For example, communications component 802 can include one or more buses, and can also include transmit chain components and receive chain components associated with wireless or wired transmitters and receivers, respectively, operable for interfacing with external devices. For example, the communication component 802 may communicate between the diagnostic application 126 and a GPU on another device, between distributed components of the diagnostic application 126, and so forth.

Additionally, computing device 100 may include a data store 804, which data store 504 may be any suitable combination of hardware and/or software, which data store 804 provides mass storage of information, databases, and programs used in connection with the examples described herein. For example, data store 804 may be or may include a data store for applications and/or related parameters that are not currently being executed by processor 104. Further, data store 804 may be a data store for an operating system, applications (such as graphics driver 122 executing on processor 104, diagnostic application 126 and/or components thereof, display driver, and/or the like, and/or one or more other components of computing device 100).

Computing device 100 may also include a user interface component 806, the user interface component 806 operable to receive input from a user of the computing device 100 and further operable to generate output for presentation to the user (e.g., via display interface 116 to a display device). User interface component 806 may include one or more input devices, including but not limited to a keyboard, a numeric keypad, a mouse, a touch-sensitive display, navigation keys, function keys, a microphone, a voice identification component, a gesture identification component, a depth sensor, a gaze tracking sensor, any other mechanism capable of receiving input from a user, or any combination thereof. Further, the user interface component 806 may include one or more output devices, including but not limited to the display interface 116, speakers, haptic feedback mechanisms, printers, any other mechanism capable of presenting output to a user, or any combination thereof. In one example, the user interface component 806 may display or may include an interface 400, 500, 600, 700, or similar interface to display memory usage information, as described herein.

Computing device 100 may also include a GPU114 for drawing images based on ray tracing instructions received from processor 104, as described herein. The GPU114 may additionally send signals via the display interface 116 to cause the drawn image to be displayed on a display (not shown). Additionally, computing device 100 may include a graphics driver 122 for providing ray tracing instructions (e.g., in a proprietary architecture) to GPU114 as described herein. Additionally, computing device 100 may include a diagnostic application 126 for determining and displaying shader table information as described herein.

For example, an element or any portion of an element or any combination of elements may be implemented with a "processing system" that includes one or more processors. Examples of processors include microprocessors, microcontrollers, Digital Signal Processors (DSPs), Field Programmable Gate Arrays (FPGAs), Programmable Logic Devices (PLDs), state machines, gated logic, discrete hardware circuits, and other suitable hardware configured to perform the various functions described throughout this disclosure. One or more processors in the processing system may execute software. Software should be construed broadly to mean instructions, instruction sets, code segments, program code, programs, subroutines, software modules, applications, software packages, routines, subroutines, objects, executables, threads of execution, procedures, functions, etc., whether referred to as software, firmware, middleware, microcode, hardware description language, or otherwise.

Thus, in one or more examples, one or more of the functions described may be implemented in hardware, software, firmware, or any combination thereof. If implemented in software, the functions may be stored or encoded as one or more instructions or code on a computer-readable medium. Computer readable media includes computer storage media. A storage media may be any available media that can be accessed by a computer. By way of example, and not limitation, such computer-readable media can comprise RAM, ROM, EEPROM, CD-ROM or other optical disk storage, magnetic disk storage or other magnetic storage devices, or any other medium that can be used to carry or store desired program code in the form of instructions or data structures and that can be accessed by a computer. Disk and disc, as used herein, includes Compact Disc (CD), laser disc, optical disc, Digital Versatile Disc (DVD), and floppy disk wherein disks usually reproduce data magnetically, while discs reproduce data optically with lasers. Combinations of the above should also be included within the scope of computer-readable media.

The previous description is provided to enable any person skilled in the art to practice the various examples described herein. Various modifications to these examples will be readily apparent to those skilled in the art, and the generic principles defined herein may be applied to other examples. Thus, the claims are not intended to be limited to the examples shown herein, but is to be accorded the full scope consistent with the language claims, wherein reference to an element in the singular is not intended to mean "one and only one" unless specifically so stated, but rather "one or more. The term "some" means one or more unless specifically stated otherwise. All structural and functional equivalents to the elements of the various examples described herein that are known or later come to be known to those of ordinary skill in the art are intended to be encompassed by the claims. Furthermore, nothing disclosed herein is intended to be dedicated to the public regardless of whether such disclosure is explicitly recited in the claims. Any claim element should not be construed as a means plus function unless the element is explicitly recited using the phrase "means for … …".

Claims (15)

1. A computer-implemented method for displaying shader table information used in ray tracing an image, comprising:

intercepting, from a Graphics Processing Unit (GPU) or a graphics driver, a buffer specifying shader table information, the shader table information comprising one or more shader records of a shader to be used in generating the image using ray tracing;

determining, by a computing device, a parameter layout within the buffer for one or more shaders corresponding to the one or more shader records based at least in part on identifiers of the one or more shader records;

interpreting, by the computing device, additional data in the buffer based at least in part on the parameter layout to determine one or more parameters corresponding to the one or more shader records;

performing at least one of: detecting an invalid memory location in the one or more parameters or a null root signature associated with the one or more shader records based on the layout; and

displaying, via an application executing on the computing device, an indication of the one or more parameters on an interface and displaying an indicator of at least one of the invalid memory location or the empty root signature.

2. The computer-implemented method of claim 1, further comprising intercepting a prior buffer from the GPU or the graphics driver, the prior buffer specifying a root signature and the layout, wherein determining the layout comprises:

associating the identifier of the one or more shader records with the root signature; and

identifying the layout corresponding to the root signature in the prior buffer.

3. The computer-implemented method of claim 2, wherein associating the identifier of the one or more shader records with the root signature comprises identifying the root signature from the buffer.

4. The computer-implemented method of claim 1, further comprising:

intercepting, from the GPU or the graphics driver, a prior buffer specifying a span between shader records in the shader table;

identifying a second shader record based on a location of the span from the one or more shader records;

determining a second layout of the second shader record based at least in part on a second identifier of the second shader record of the one or more shader records detected in the buffer;

interpreting additional second data in the buffer based at least in part on the second layout to determine one or more second parameters corresponding to the second shader record; and

displaying, via the application executing on the computing device, a second indication of the one or more second parameters on the interface.

5. The computer-implemented method of claim 1, wherein the one or more parameters comprise at least one of: root constants, root descriptors, or root descriptor handles.

6. The computer-implemented method of claim 1, wherein displaying the indication of the one or more parameters comprises displaying a link to a root signature associated with the one or more shader records, wherein the link is associated with displaying additional parameters related to the root signature.

7. The computer-implemented method of claim 1, wherein displaying the indication of the one or more parameters comprises displaying a link to a byte offset in the buffer associated with the one or more shader records, wherein the link is associated with displaying bytes associated with the one or more shader records.

8. A computing device for displaying shader table information used in ray tracing an image, comprising:

a memory storing one or more parameters or instructions for executing an operating system and one or more applications including a diagnostic application; and

at least one processor coupled to the memory, wherein the at least one processor is configured to:

intercepting, from a Graphics Processing Unit (GPU) or a graphics driver, a buffer specifying information comprising one or more shader records of a shader to be used in generating the image using ray tracing;

determining a parameter layout within the buffer for one or more shaders corresponding to the one or more shader records based at least in part on identifiers of the one or more shader records;

interpreting additional data in the buffer based at least in part on the parameter layout to determine one or more parameters corresponding to the one or more shader records; and

displaying, via the diagnostic application, an indication of the one or more parameters on an interface.

9. The computing device of claim 8, wherein the at least one processor is further configured to intercept a prior buffer from the GPU or the graphics driver, the prior buffer specifying a root signature and the layout, wherein the at least one processor is configured to determine the layout at least in part by:

associating the identifier of the one or more shader records with the root signature; and

identifying the layout corresponding to the root signature in the prior buffer.

10. The computing device of claim 9, wherein the at least one processor is configured to associate the identifier of the one or more shader records with the root signature at least in part by identifying the root signature from the buffer.

11. The computing device of claim 8, wherein the at least one processor is further configured to:

intercepting, from the GPU or the graphics driver, a prior buffer specifying a span between shader records in the shader table;

identifying a second shader record based on a location of the span from the one or more shader records;

determining a second layout of the second shader record based at least in part on a second identifier of the second shader record of the one or more shader records detected in the buffer;

interpreting additional second data in the buffer based at least in part on the second layout to determine one or more second parameters corresponding to the second shader record; and

displaying, via the diagnostic application, a second indication of the one or more second parameters on the interface.

12. The computing device of claim 8, wherein the at least one processor is configured to detect an invalid memory location among the one or more parameters, wherein the at least one processor is configured to display the indication of the one or more parameters as an indicator associated with the invalid memory location.

13. The computing device of claim 8, wherein the at least one processor is configured to detect a bare root signature associated with the one or more shader records based on the layout, wherein the at least one processor is configured to display the indication of the one or more parameters as an indicator of the bare root signature.

14. The computing device of claim 8, wherein the one or more parameters include at least one of: root constants, root descriptors, or root descriptor handles.

15. A computer-readable medium comprising code executable by one or more processors for performing the computer-implemented method of one or more of claims 1-7.