Falcor application GPU Capture with PIX


I’ve been working with Austin Kinross at Microsoft to debug an issue when attempting to profile my Falcor-based DXR application in Microsoft PIX using v1.3 of the DXR binaries. (Technically my application is based on Chris Wyman’s dxrTutors.code project, but that is, of course, using Falcor underneath.)

My application builds and runs as expected under VS2017, and launches from PIX on my local machine without issue. Each time I attempt the GPU Capture, however, I receive the following message:

Error 0x80070057 (The parameter is incorrect.)
Details: Error Code: E_INVALIDARG (0x80070057)

After some debugging with Austin’s help, he has concluded the following:

This issue is related to the application’s shader tables set via D3D12_DISPATCH_RAYS_DESC when it
calls DispatchRays(). For some shader tables, it looks like the application is setting a valid GPU
virtual address for ‘StartAddress’ but 0 for its ‘SizeInBytes’.

This is technically valid API usage and I’ll file a bug on PIX to handle this correctly. However, I
would guess that this probably isn’t what the application intends to do: I’d guess that the
application is trying to use a shader table of size > 0 and has forgotten to set ‘SizeInBytes’ to a
non-zero value.

If the application intends to set an empty shader table then I’d recommend setting ‘StartAddress’ to 0
instead of ‘SizeInBytes’-- that should allow PIX capture to avoid this issue for now, until we improve
PIX to handle this scenario more gracefully.

Because all of the shader table handling in my application is ultimately controlled by Falcor, I’m wondering what information I can provide to workaround (or resolve) this issue. I’d really like to profile my application with Microsoft PIX, and while Austin indicates the API usage described above is technically valid, I’m wondering if he’s correct in his guess that there’s actually an issue at the Falcor level—and if not in Falcor proper, then in my use of it via Chris’s dxrTutors.code interface.

Thanks for considering this issue.


Christian Gribble
SURVICE Engineering