My studio has asked me to look at GPA for use in our automated testing pipeline. The use case we would like to implement is as follows:
Run GPA monitor on test machine
Launch our game and run through some automated tests
Use GPA Triggering to capture CPU/GPU traces, eg - when FPS < 25
It appears that the way to implement this case is to use the "Auto-detect launched applications" option in GPA Monitor. Unfortunately, it does not seem to be the case that trigger settings in the selected profile are honored in this mode. Are there any steps I can take to use the triggering feature in this scenario? If not, I can say that we would welcome such an addition in a future release :-)
Another difficulty I find myself facing is that, when I manually start the game through GPA Monitor, a stall is introduced, such that the game stops until I manually go and stop the fxc.exe (DirectX shader compiler) process in task manager. (Our game, at least at this stage in development, compiles shaders on the fly). I was able to avoid this problem using the InjectionList.txt file in the auto-detect scenario, but there appears to be no way around it in the manual case. Are there any recommendations in this case? It would be useful for me, anyway, to have the manual-launch case honor the InjectionSkipList.txt file.
As far as I know, "auto-detect" mode should work with triggers. Is this only with your game, or does this fail for other processes like "gpasample.exe" as well? In any case, I'll try testing this myself to see what happens. Also, can you tell me which trigger options you are using, and also provide some info on your environment by right-clicking the Intel GPA Monitor in the notification tray and selecting "About..."?
For "manual" mode, I'm assuming that your game spawns the shader compiler as a sub-process -- is this correct?
And my last question: in the title you mention "ITT API", but nothing in your posting talks about this. Is there something special about your game and the use of ITT, such as the issues only started happening when you added ITT calls?
I just tried a simple test with gpasample.exe and a sample trigger that dumps a frame capture file after frame 95, and all seems to work ok. So do you have multiple profiles defined, or is there something else you can think of about this that's "different" from usual?
You are right - I forgot to mention how this all was related to the API! Sorry about that.
If I run my app without any API calls, "manual mode" works exactly as expected, triggers, not locking up on the fxc process, etc. "Auto-detect" mode does not cause the triggers to work, but otherwise seems fine. As a note - gpasample doesn't cause my triggers to execute either.
I don't believe I've done anything dramatically out of line in my use of the API. All I've done is create a domain, and call __itt_begin_task and __itt_task_end so that my CPU trace has the various task scopes included. I learned in the process that I must wait until after our engine creates the D3D Device before creating the domain, otherwise frame capture and the GPA HUD would be non-functional. Other than that, I can't think of anything special I have done.
With the API in use, manual mode hangs on FXC, which, as you say, is created as an external process by the game process.
My trigger settings are "When FPS < 30, Create Trace & Frame Capture". As I say, they work properly in the un-instrumented build.
I just have the single 'default' profile. As the gpasample app runs very well on my system, I changed the trigger to IF FPS BECOMES > 30 DO Frame and Trace Capture AND Nothing. Retrigger delay is 30 seconds, and the "Trigger enabled even when HUD state override enabled" is checked.
I saw something in your previous reply that I think needs to be looked at first:
IfI run my app without any API calls, "manual mode" works exactly as expected... "Auto-detect" mode does not cause the triggers to work, but otherwise seems fine. As a note - gpasample doesn't cause my triggers to execute either.
In particular, you mention that "auto-detect" mode doesn't work with triggers -- either for your application or for even gpasample. Could you first of all try a very simple trigger that should always be executed, such as the following:
Try this for both your game and for gpasample, and let me know what you see. I would like to tackle the "auto-detect" issue first, since it'll be much easier than trying to debug anything with ITT (as this may involve getting access to your source code in order to duplicate it).
Hey, Neal. I've discovered what was causing my triggers not to fire. It seems I must run my game application (or gpasample) as Administrator to get the triggering to work. In that case, it seems to work fine, otherwise, no. I wasn't aware of this being a documented requirement, but it's perfectly acceptable in my use case.
I'll continue on with implementing the API - I'm sure I'll get there soon enough. I'm a bit hamstrung, insofar as I am integrating with a 3rd party game engine SDK, which may be complicating things for me in terms of what I would like to be able to do.
That said, in our research, we've found this set of apps to be the most comprehensive and useful for our needs, particularly as they give us access to details on both CPU and GPU. Thank you for making them available to our community.
You are not alone here, as I didn't realize that these needed to be run with Admin priv's... I'll check this myself and work with the development team to see if we need to change the code or the documentation or both.
And thanks for your kind words about your usage of the product!
I just did some testing with gpasample on a non-admin account, and though I get a message saying that "ETW tracing data" cannot be collected when starting up the GPA Monitor, everything seemed to work ok with a simple trigger (frame number = 100). When setting this trigger, both frame and trace captures seemed to be created ok, so I'm at a loss as to why this is an issue on your system.
However, note that this testing was using the "manual" startup
method, since it is documented that you need "admin" rights to enable "auto detect"
mode -- this is documented here.
One last comment on this issue. The development team is looking at this, and will probably document these limitations further and/or print a message in the Intel GPA Monitor when running with a non-admin account.
I got curious about the admin issue. It appears that Windows 7 UAC is actually the deciding factor. I believe I may be in the minority, particularly among programmer types, but I have never completely disabled UAC on my machine. Once I did, the triggering worked exactly as expected, even in auto-detect mode. I hope that information proves useful in your investigation.
One last thing, as a follow up: is there anything we might be able to try regarding the hang up when our app launches fxc as a separate process? With our game still in development, there is quite a bit a churn in the shader code and materials setups, and we depend on runtime shader compilation. If there is nothing to be done in the current release, perhaps a future release could provide a means of specifying apps never to attach to, ala InjectionSkipList.txt for auto-detect mode, but also honor it for the manual-start case? I believe that the discrimination between process names is what is allowing the auto-detect case to work, since the monitor doesn't attach to apps not specifically named in the InjectionList.txt file.
I am filling in for Neal this week while he takes a well deserved vacation. :)
I belive that the InjectionSkipList.txt should work for both auto-detect mode as well as the manual-start case, so there is not a likely workaround other than the steps you are currently taking. The functionality you are encounterting is incorrect and makes me believe this is a defect. I have also been able to reproduce the skip list not working with the manual-start case as well. If this is problem is indeed a defect I will let you know within a day or so, and if it isn't I will come back with hopefully a more elegant solution to your problem.
Thank you very much for your input and desire for us to improve our tool!