Path: blob/main_old/src/tests/restricted_traces/README.md
1693 views
ANGLE Restricted Traces
The files in this directory are traces of real applications. We host them internally because they may contain third party IP which we don't want to share publicly.
Accessing the traces
In order to compile and run with these, you must be granted access by Google, then authenticate with CIPD. Googlers, use your @google account.
Add the following to ANGLE's .gclient file:
Then use gclient to pull down binary files from CIPD.
This should result in a number of directories created in src/tests/restricted_traces
that contain the trace files listed in restricted_traces.json:
Building the trace tests
To build for Android, follow the steps in DevSetupAndroid.md (Recommend using the Performance
arguments for best performance)
To build for Desktop, follow the steps in DevSetup.md
When that is working, add the following GN arg to your setup:
To build the angle_perftests:
Run them like so:
Capturing and adding new Android traces
Generally we want to use a Debug setup for recording new traces. That allows us to see asserts and errors if the tracer needs to be improved. Add the following GN arg to your Debug setup:
After building and installing the APK with the above arg, we're ready to start capturing.
Determine the target app
We first need to identify which application we want to trace. That can generally be done by looking at the web-based Play Store entry for your app. For instance, Angry Birds 2 is listed here: https://play.google.com/store/apps/details?id=com.rovio.baba
If there is no Play Store entry for your app, there are a couple of ways you can determine the app's name.
If you have a userdebug build of Android, you can check logcat when you launch the application. You should see an entry like this:
If you just have an APK, you can use the following command to find the package name:
You can also just guess at the package name, then check your device to see if it is installed. Keep trying combinations until you find it:
Track the package name for use in later steps:
Choose a trace name
Next, we need to chose a name for the trace. Choose something simple that identifies the app, then use snake case. This will be the name of the trace files, including the trace directory. Changing this value later is possible, but not recommended.
Opt the application into ANGLE
Next, opt the application into using your ANGLE with capture enabled by default:
Set up some Capture/Replay properties
We also need to set some debug properties used by the tracer.
Ensure frame capture is enabled. This might be redundant, but ensure the property isn't set to zero, which disables frame capture.
Empty the start and end frames. Again, this might be redundant, but it is less confusing.
Set the label to be used in the trace files
Set a trigger value to be used by the tracer. This should be set to the number of frames you want to capture. We typically use 10 to get an idea of how a scene is running, but some workloads require more. Use your discretion here:
Create output location
We need to write out the trace file in a location accessible by the app. We use the app's data storage on sdcard, but create a subfolder to isolate ANGLE's files:
Start the target app
From here, you can start the application. You should see logcat entries like the following, indicating that we've succesfully turned on capturing:
Trigger the capture
When you have reached the content in your application that you want to record, set the trigger value to zero:
In logcat we'll see another entry corresponding to this:
The app may pause briefly when the capture is completing. You can check its progress by looking at the file system:
Allow the app to run until the *angledata.gz
file is non-zero and no longer growing. The app should continue rendering after that:
Note, you may see multiple contexts captured in the output. When this happens, look at the size of the files. The larger files should be the context you care about it. You should move or delete the other context files.
Pull the trace files
Next, we want to pull those files over to the host and run some scripts.
Add the new trace to the JSON list
The list of traces is tracked in restricted_traces.json. Manually add your new trace to this list. Use version "1" for the trace version.
You can also use a tool called jq
to update the list. This ensures we get them in alphabetical order with no duplicates. It can also be done by hand if you are unable to install it, for some reason.
Then run the following command:
Run code auto-generation
We use two scripts to update the test harness so it will compile and run the new trace:
After this you should be able to git diff
and see your new trace added to the harness files:
Note the absence of the traces themselves listed above. They are automatically .gitignored since they won't be checked in directly to the repo.
Upload your trace to CIPD
Once you feel good about your trace, you can upload it to our collection of traces. This can only be done by Googlers with write access to the trace CIPD prefix. If you need write access contact someone listed in the OWNERS
file.
Upload your CL
Ensure your current working directory is up-to-date, and upload:
You're now ready to run your new trace on CI!