Profiler Data

This week I've been busy setting up my environment messing about with APP Profiler session data, GPU ShaderAnalyzer output and trying out the client/server design of GPU PerfStudio2.  These tools provide detailed data sheets, tons of command line options and more raw info than I know what to do with.

Offline Data from CS in VS2010 and *.hlsl files in ShaderAnalyzer

The GPU PerfStudio2 was very impressive as it profiles an application while the application is running through the PerfStudio server and can be set in a similar way to setting break points and captures a full frame.  This is where the fun begins...

Benchmark in GPU PerfStudio2, on a single draw call at the VS stage

 So far I have been able to dissect the deferred lighting benchmark through time comparisons and resource consumption.  This tool allows me to step through each call and provides an easy to read graph (bottom of image) that visualizes the overall frame time device call by call. It also allows for on the fly shader editing which I think will really speed up the shader iterations during the production stage.  These tool provide so much information however that I need a way to collect and manage the outputs in an automated way.  Each tool provides methods for invoking the application from the command line and saving out images, CSVs and application specific files. Hopefully I will come up with a reasonable way to make order out of all of this information in the next week or so.


As far as progress on coding, I wrote another sample program that utilizes the compute shader as well as a basic render path this time based off of the directX addition sample.  This difference from the example (or my previous post) is that I wanted to take a closer look at the interactions between the shader and the resource views, as well as set up my custom build steps for effects as well as individual shader functions. This time I did not use any of the pipeline set up from the baseline but rather manually created the required buffers and used the context pointer to switch between shaders as needed. I then removed any calls that created a complete effect with the technique in the shader and created the component shader stages individually and set them in the *.cpp.  I think this will give me a lot of flexibility in the next few weeks so that I do not have to duplicate my shaders just because they are linked in file specific technique.  I will probably use a bit of both, but it was good to implement the idea quickly with this simple example.

Simple use of multiple SRV, UAV and structured buffers

Lastly, I have been trying out a few different optimization flavors using the FXC.exe tool.  I am currently setting a custom build step for my *.hlsl / *.fx files so that I will get syntax errrors at compile time rather than runtime.  Currently, I am including the step depending on what type of shader it is and stating the entry point in the param list. I would like to automate this more so that every time I draft a shader it will apply the correct steps.  Maybe I will use a different suffix for each type of shader.